Hi,
Filters triggered by an Escalation, either via Set-Fields or Push-Fields,
will ALWAYS be run in the same thread.
This has ALWAYS been the case.
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.
> Now that you remind me, I actually remember discussing this once with
> you..
>
> I'll really need to log the workflow to see what thread processes the
> filter
> workflow when filters are executed triggered by the AR_ESCALATOR user.
>
> I was told this in a performance tuning class years ago (version 4.0 - 4.5
> days so probably 11 or 12 years ago) that you let escalations perform
> first
> stage actions, and leave any 2nd and 3rd stage actions (deletes, push
> fields, notifications) to be performed by filters that are run using the
> admin thread. Maybe the design was different back then? So this is
> obsolete
> now?
>
> I wish I had a server to verify this :-)
>
> Joe
>
> -----Original Message-----
> From: LJ LongWing
> Sent: Thursday, December 08, 2011 2:18 PM Newsgroups:
> public.remedy.arsystem.general
> To: [email protected]
> Subject: Re: Application-Query-Delete-Entry
>
> Joe,
> I know this discussion comes up every once in awhile....but you and I seem
> to differ in our opinions of how it works.
>
> So...based on your statement below, having the escalation set a field, and
> having a filter fire on that field being set, then performing the delete
> will be 'faster' because of a 'fire and forget' type of mechanism?
>
> I would argue that an action of delete within the escalation, and a
> setfield
> causing a filter to fire that causes the delete are 'the same', in that
> the
> escalation thread does not 'go onto the next record' till after the
> filters
> on the current record are done...so, in essence, the performance of either
> action would be the same and the escalation thread would still be tied up
> for exactly the same amount of time regardless
>
> At least, that's my understanding :)
>
> -----Original Message-----
> From: Action Request System discussion list(ARSList)
> [mailto:[email protected]] On Behalf Of Joe Martin D'Souza
> Sent: Thursday, December 08, 2011 11:33 AM
> To: [email protected]
> Subject: Re: Application-Query-Delete-Entry
>
> End Date as Linda pointed out should be a field on that form you are
> searching for, represented by 'End Date' in the qualification and not $End
> Date$..
>
> That being said, LJ's suggestion is right..
>
> The qualification should be in the Run If of the Escalation and the run
> process should be
>
> Application-Delete-Entry $SCHEMA$ $Request ID$
>
> Having an Escalation with no Run If instructs it to be run over the entire
> data table. You do not want to do that in case you have like a million or
> more records in it.. It may probably hang the escalation thread waiting
> for
> it to complete..
>
> Also a faster way to do it would be to 'mark that entry for deletion'
> using
> a tag on a field created for that. This would mean that the Escalation
> would
> do a single update to that table which is a faster operation that multiple
> deletes and be done with it.. Create a filter that runs if the $USER$ is
> AR_ESCALATOR and the flag for delete is set, to delete that entry. So on a
> fairly large set of data, although the deletes are still potentially
> happening triggered by that filter, the escalation thread has already
> finished processing the escalation and is ready to take on a new job..
>
> Joe
>
> -----Original Message-----
> From: LJ LongWing
> Sent: Thursday, December 08, 2011 12:54 PM Newsgroups:
> public.remedy.arsystem.general
> To: [email protected]
> Subject: Re: Application-Query-Delete-Entry
>
> Larry,
> Your approach is a bit ‘off’. An escalation performs a search that
> matches
> your qualification, and then performs your action on ALL records that
> match
> that qualification. So in this case, I would expect your run-if
> qualification to be
>
> ('Status' = "Past") and ($End Date$ < ($TIMESTAMP$ - (86400 * 180)))
>
> Or, whatever qual you want to identify your specific records,
>
> Then, from there, you will be modifying ‘that’ record…so you wouldn’t want
> to then perform an Application-Query-Delete-Entry, you could simply
> perform
> an
>
> Application-Delete-Entry $SCHEMA$ $Request ID$
>
>
>
> From: Action Request System discussion list(ARSList)
> [mailto:[email protected]] On Behalf Of Larry Barnes
> Sent: Thursday, December 08, 2011 10:23 AM
> To: [email protected]
> Subject: Application-Query-Delete-Entry
>
> **
> Hello Listers,
>
> I'm trying to learn how to delete records that are past and the End Date
> is
> more than 6 months prior to todays date. I built the escalation and when
> I
> run it nothing happens. Can someone point in the right directions with
> the
> Run Process syntax.
>
> I'm using SQL 2008 and Windows 2008. ITSM is 7.5
>
> The form I'm deleting from is: AP:Alternate
>
> Run IF Qualification is: 'Status' = "Past" (also tried without
> setting
> a Run If Qualification)
>
> Run Process is: Application-Query-Delete-Entry "AP:Alternate" ('Status'
> =
> "Past") and ($End Date$ < ($TIMESTAMP$ - (86400 * 180)))
>
> I have also tried: Application-Query-Delete-Entry "AP:Alternate"
> ('Status' = "Past") and ($End Date$ < ($DATE$ - (86400 * 180)))
>
>
> Thanks in advance for your time,
>
> Larry B
> _attend WWRUG12 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"
>
> _______________________________________________________________________________
> 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"
>
> _______________________________________________________________________________
> 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"
