I found the problem. Its not the MAX Filters. And yes I knew that max
filters is a transaction based setting and not for the entire escalation.
But because it was stopping only after processing a certain number of
records I was wondering if that had anything to do with it.
The reason it wasn't processing was a violation of a unique index on City
and Zip/Code.
The data we are feeding from, doesn't have a very clean and organized postal
information. So as a result some of the data there has Country, City and Zip
Code but missing state. Others have state for what should have been the same
record.
As a result it sees data like
India, HARYANA, Gurgaon, 122002 and India, '', Gurgaon, 122002 on the load
form as two separate records that pass the duplicate test from the defined
out of the box workflow, but when the second record was being set with z1D
Action of VALIDATELOAD and DL_Status of Validated, it failed the rest of the
transaction as the system encountered a violation of a unique index.
I think it's a workflow bug in the load form that should have been checking
for violation of that unique index, but it does not.
Since it's a BMC out of the box workflow, I'll raise a ticket with them.
Cheers
Joe
_
From: Action Request System discussion list(ARSList)
[mailto:arslist@ARSLIST.ORG] On Behalf Of Charlie Lotridge
Sent: Wednesday, September 24, 2014 11:28 AM
To: arslist@ARSLIST.ORG
Subject: Re: Escalation does not seem to complete its run over all the
records..
**
First, and FYI, the filter counter that's used by the system to determine if
a transaction exceeds the filtering limit set for the system is reset for
every record process during an escalation. It is NOT cumulative across the
entire run of the escalation. So unless one of the records being
processed exceeds your 500K limit, your correct that it can't be the filter
limit.
I don't know anything about the specific forms or data you're dealing with
here, but is it possible that those 209 records only come to meet the
inclusion condition after the escalation begins its operation? Just like
many other things in the AR system, an escalation performs its query when it
first wakes up, and only operates on the records it finds with that initial
query. If any records subsequently come to meet the condition they won't be
processed (until the next run of the escalation).
Hope this helps.
-charlie
On Wed, Sep 24, 2014 at 7:34 AM, Joe D'Souza jdso...@shyle.net wrote:
**
I have a simple escalation that triggers on the form CTM:LoadPostalCodes
with a condition
'DL_Status' = Unvalidated
During an initial run if there was no data in CTM:LoadPostalCodes, all
records meet that condition.
The escalation sets two fields in that form, z1D Action to VALIDATELOAD
and DL_Status to Validated
This triggers a bunch of out of the box data load filters, designed to
validate and load the data in this form to the CTM:Postal Codes form.
It works fine on almost all the records, except for 209 records in the end
that do not get modified despite the fact they meet the condition on the
Escalation.
I have looked through the data in these 209 records, and nothing jumps up at
me why this might be happening. The Error Flag is not set and the Last
Modified Date does not change indicating that the Escalation did not even
attempt to modify these records.
I have a slight suspicion on max number of filters in an operation but
somehow I doubt with just a little over 4000K records in that form to
process, I would run over 50 filters as I doubt that there are over 100
filters for each record even if it were promoted. Also if max filter limit
was the case, the system should have handled the unprocessed records of the
first run on the second run of the escalation, but that does not happen
either.
Any alternate theories as to what may be happening?
I have not yet activated any logs but will later if I can't determine what
is causing this behavior just by comparing the data with the workflow.
Joe
_ARSlist: Where the Answers Are and have been for 20 years_
_ARSlist: Where the Answers Are and have been for 20 years_
___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Where the Answers Are, and have been for 20 years
