Hi,
If you use an escalation instead, that triggers on these 1500 records,
each record will be treated as a single transaction. That way it can scale
indefinitely.
Another way is to do a Push-Fields from ACTL:s instead, if a user is
performing some kind of update. Each updated record will be treated as a
single transaction.
If on the other hand you do a Filter-Push, all 1500 records will be
handled within ONE transaction, and it is very easy to hit the Max Filters
roof.
You might also be able to just change the way things work like this:
Current: Filter -> Staging -> CTM:People
Instead: Filter -> Staging, Escalation -> Staging -> CTM:People
Best Regards - Misi, RRR AB, http://www.rrr.se (ARSList MVP 2011)
Products from RRR Scandinavia (Best R.O.I. Award at WWRUG10/11):
* RRR|License - Not enough Remedy licenses? Save money by optimizing.
* RRR|Log - Performance issues or elusive bugs? Analyze your Remedy logs.
Find these products, and many free tools and utilities, at http://rrr.se.
> 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:[email protected]]
>
>
> _______________________________________________________________________________
> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
> attend wwrug12 www.wwrug12.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"
