What jumped out at me after reading LJ's response is pushing back the the next run by 1 minute. Has the record count in the table built up over the years and now it takes more than a minute to execute this process? Maybe a large record count in combination with a recent change (not necessarily related to the paging process) has lengthened the time it takes for this process to run over a minute? These are the kind of variables that come to mind when a problem just pops up out of nowhere. This and making sure your business time calendars have not expired.
I don't remember what version but I think it was around 7.5 where the old business time process was replaced with a newer one (from memory business time 2). They both still worked in parallel but maybe you have hit the end of life of the old business time process? Jason On Dec 3, 2014 7:40 AM, "LJ LongWing" <[email protected]> wrote: > ** > Well..I can't answer why it 'suddenly' started happening....but, it > doesn't appear that your qualifications are mutually exclusive. > > Filter fires on 'Status != Closed and Field set to pending approval' > > The Escalation is setting fields: > Time1 = NULL > Setfield Notify= yes > > So....the Escalation is not setting any values that would cause the filter > to NOT fire, and being the Filter is setting fields that would cause the > Escalation to fire...I can see how a loop would form.... > > Now....if you changed the Run-If for the filter to only fire if Setfield > Notify = No, or something like that...then the Escalation wouldn't cause > the filter to fire...but as it's custom, I don't know your system, so I > don't know if that would be appropriate or not. > > Now...one thing that may need to be looked into is what value is coming > out of > > $PROCESS$ Application-Bus-Time-Add "$TIMESTAMP$" "1" "2" "holiday" > "Change" > > According to the Docs > > Application-Bus-Time-Add "<s*tartTime>*" ["<a*mount>*" ["<a*mountUnits>*" > ["<*holidayScheduleName>*" [HTMLUATarsadministering1030:"< > *workdayScheduleName>*"]]]] > > So, according to your command, you are adding 1 minute to 'now', based on > the holiday schedule named 'holiday', and the workday schedule named > 'Change' > > So, again, I don't know your system...but I don't know if you are > intending to add '1 business minute' or not...but...that does seem to be > what's happening, which is causing the escalation to fire again on it's > next run.... > > You may also want to check with your holiday and Change calendars to > ensure they are still accurate. > > On Wed, Dec 3, 2014 at 8:05 AM, ddussie <[email protected]> wrote: > >> Hello List, >> >> This is our scenario, we have had remedy since 1.x... but since since >> conversion at 6.3x mark we have steadily upgraded - as we are a custom >> shop >> no modules. That being said, since the day light saving time change, >> filters and escalation have been acting weird; from all investigation it >> is >> not a result of timing issue; but possible a coincidence with Time change. >> This is what we are experiencing, >> >> A change request in the custom change system, on creation of the ticket >> will >> notify a group if this filter is met. >> >> on Execution Submit & Modify >> qualification = Status != Closed and Field set to pending approval >> Then >> Setfield to Time1 = $PROCESS$ Application-Bus-Time-Add "$TIMESTAMP$" "1" >> "2" >> "holiday" "Change" Setfield Notify=No >> Runprocess to call telalert to email. >> >> Then an escalation >> On 4 min interval >> Qualification: Time1 != $NULL$ and Notify=No and TimeStamp> Time1 >> Then Setfield to Time1 = NULL >> Setfield Notify= yes >> Runprocess to call telalert to text/page. >> >> >> Since yesterday, 3pm this workflow started looping. >> >> So as the filter fires, the escalation fires, looping on Execution action >> modify. >> >> This sent 300 emails and 300 pages to group. >> >> Its wierd as the filter execution on submit and modify has been working >> for >> atleast 7 years i have been managing this tool. >> >> I'm not sure which version of remedy 6.3x to 7.5x that built that >> workflow. >> I have rebuilt in 7.5p4 version; however that didnot resolve. >> >> Can anyone assist with an explanation? >> >> We are behind in upgrading. >> ARS 7.5.00 Patch 004 201002051027 >> Oracle 11.2.0.3.0 - 64bit Production >> UNIX AIX 6.1 >> >> Cluster JVM & Cluster Http & Bigip >> MT Version 7.5.00 Patch 004 201002051027 >> WebSphere IBM WebSphere Application Server/6.1 >> Java Version 1.5.0 >> >> >> >> >> >> >> >> >> >> -- >> View this message in context: >> http://ars-action-request-system.1.n7.nabble.com/Filters-actions-are-firing-wierd-or-correctly-tp119984.html >> Sent from the ARS (Action Request System) mailing list archive at >> Nabble.com. >> >> >> _______________________________________________________________________________ >> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org >> "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"
