I also have an ARDBC vendor form against an LDAP query of AD. The Escalation I use runs off of a query to pick up a subset of the records in the Run If, which triggers a Push Fields to a staging form, which then has several filters off of it. I am on 7.6.4 SP2 for everything, and do use the CMDB updates. Minus that, though, I ran the same integration in 7.0, 7.5, and 7.6.4 with just minor changes from time to time. While we use different pieces of workflow I don't see any reason why yours wouldn't process each individual record separately as well since you are using an escalation. I have 69 (soon to be closer to 75) Filters on my staging form that do lots of lookups and also push some data to create things like Sites, Site/Company relationships, Departments, etc in addition to People records.
That being said, I'm about to switch over to using a database table via a view form instead. I think it will help with performance, eliminate AD as the middleman of the HR data, and help on some of the technological issues such as the vendor form's inability to display certain AD attributes correctly. Thanks, Shawn Pierson Remedy Developer | Energy Transfer From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Nathan Aker Sent: Monday, August 20, 2012 1:32 PM To: arslist@ARSLIST.ORG Subject: Re: AD People Integration Choking due to Max Filters for an Operation ** ARDBC Vendor form against AD with a "Process" check box which is a display only field. The only thing the escalation does is every hour come through and check the box. Filter workflow then fires on Modify which determines if any changes have been made to the person and pushes/updates accordingly. This had to be done because of a defect in the ARDBC plugin whereby it can not properly evaluate the lastChanged attribute to identify delta data only. So basically sounds like my workflow is triggering just like yours and just like I've done it in previous versions without issue. What version are you on and do you have the CMDB people CI updates processing as well? Nate. Nathan Aker ITSM Solution Architect McAfee, Inc. From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Pierson, Shawn Sent: Monday, August 20, 2012 1:17 PM To: arslist@ARSLIST.ORG Subject: Re: AD People Integration Choking due to Max Filters for an Operation ** How are you getting the data from AD into Remedy? I have an integration that serves the same purpose and I use Escalations to make the updates on a scheduled basis. As a result, each record triggers the filters in its own action rather than in bulk. I'm processing about 4,000 records daily now, and that should be more than doubled in the next year. The down side of using escalations is that since it's sequential, I expect I will run into issues with it taking too long at some point. Thanks, Shawn Pierson Remedy Developer | Energy Transfer From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG]<mailto:[mailto:arslist@ARSLIST.ORG]> On Behalf Of Nathan Aker Sent: Monday, August 20, 2012 12:51 PM To: arslist@ARSLIST.ORG<mailto:arslist@ARSLIST.ORG> Subject: AD People Integration Choking due to Max Filters for an Operation ** Has anyone had luck due an enterprise size people integration with ITSM 7.6.04 with any sufficient amount of People updates? We've got an AD integration that intakes people data changes, validates/massages the data on a Staging form, then updates CTM:People. The problem we're having is it chokes out and dies while processing a relatively small # of records (~1500) due to Max Filters exceeded for an Operation. Upon further detailed inspection of the logging the following approximate filter counts are run for EVERY record processed: * 20 Filters firing on Staging form to do a range of data validations and lookups. * 254 Filters firing on the CTM:People form. This is OOB workflow * ??? Filters firing at the CMDB layer to maintain the People CI Records. This integration is architected via a control form with an escalation that simply sets a "process" display only field on the Vendor form which triggers all the additional push/update workflow via filters. Despite all my attempts to change the behavior it looks like Remedy is evaluating that since the Escalation initiated the processing all the filters for every record processed are aggregated towards the count to throw the Max Filters for Operation exceeded error. Our current Max Filters for an Operation setting = 500,000. I don't want to increase this. Given this, even the simple math above not even accounting for any filters involved in the CMDB CI Person updates, this integration can only handle about 1800 person updates before dying with the Max Filters Exceeded. I've tested doing a "modify all" to trigger all these records from the user tool and that works fine as it handles each person update as a separate filter stack count.... But when triggered via an escalation to set the process flag it aggregates the count for all records processed. Am I missing something? Is there a way to trigger the processing on a schedule which allows ARS to sum the filter counts on a per record basis instead of as a whole for all records? I'm a bit stuck on this one. Thanks for any help. Nate. Nathan Aker ITSM Solution Architect McAfee, Inc. 5000 Headquarters Drive Plano, TX 75024 Web:www.mcafee.com<http://internal.nai.com/division/marketing/BrandMarketing/templates/www.mcafee.com> [Description: mfe_primary_logo_rgb_small] _attend WWRUG12 www.wwrug.com<http://www.wwrug.com> ARSlist: "Where the Answers Are"_ Private and confidential as detailed here<http://www.sug.com/disclaimers/default.htm#Mail>. If you cannot access hyperlink, please e-mail sender. _attend WWRUG12 www.wwrug.com<http://www.wwrug.com> ARSlist: "Where the Answers Are"_ _attend WWRUG12 www.wwrug.com ARSlist: "Where the Answers Are"_ Private and confidential as detailed here: http://www.sug.com/disclaimers/default.htm#Mail . If you cannot access the link, please e-mail sender. _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are"
<<inline: image001.jpg>>
