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" > _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
