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> [cid:image001.jpg@01CD7ED8.1D3DD680] _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"_ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are"
<<inline: image001.jpg>>
