Going out on a limb here, since this is all new to me. It appears to me that both methods are needed depending on the form you are working with.
The CAI:EventParmsInterface from has a field called "Deleted" which when set to True will trigger workflow to delete the entry. The AP:Alternate form doesn't appear to have a field to set that would trigger backend workflow to delete these records thus the need for the Run Process command line : Application-Delete-Entry "SCHEMA$" $1$ The $1$ is the "Alternate ID" field in this form Larry B -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of Joe Martin D'Souza Sent: Thursday, December 08, 2011 2:06 PM To: [email protected] Subject: Re: Application-Query-Delete-Entry 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"
