If there were thousands of items in the form created every day then I would take another route. But I decided to set the escalation to run off hours so it shouldn't cause performance problems.
Thanks for the thread's talk I forgot about that aspect. JK "Hermann, John N Mr CTR USA TRADOC" <john.herma...@us.army.mil> Sent by: "Action Request System discussion list(ARSList)" <arslist@ARSLIST.ORG> 01/21/2010 12:53 PM Please respond to arslist@ARSLIST.ORG To arslist@ARSLIST.ORG cc Subject Re: Delete entry (UNCLASSIFIED) Classification: UNCLASSIFIED Caveats: NONE "PS: Something tells me this is gonna be a long thread :-)" Speaking as someone who has only just begun to venture into the rabbit hole that is ARS/Remedy... Good :-) This kind of discussion is invaluable and a wonderful insight into the inner workings of ARS. -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Joe D'Souza Sent: Thursday, January 21, 2010 12:48 PM To: arslist@ARSLIST.ORG Subject: Re: Delete entry Lyle, They (filter actions triggered by escalations) do not hold the Escalation thread to ransom.. That's the simplest way to put it Even if there is a process time out, the escalation does what it has to do by setting fields and exits making the Escalation thread available for the next set of escalations to fire.. The filter would time out if there is a time out during the actual delete.. This doesn't cause the escalation to fail.. Even if there is an error during the delete, this error is handled by the Filter thread, and not by the Escalation. That's the whole purpose of using what's known as a 'data driven' Escalation. You let data drive what needs to be done.. Sometimes as in this case its not the best idea to let the Escalation directly do a 2nd or 3rd stage action but let data drive that action and have a modify filter triggered when $USER$ = "AR_ESCALATOR" perform that action. Joe PS: Something tells me this is gonna be a long thread :-) -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org]on Behalf Of Lyle Taylor Sent: Thursday, January 21, 2010 12:30 PM To: arslist@ARSLIST.ORG Subject: Re: Delete entry Joe, Even though the different operations occur in different phases, won't the escalation thread still be held up until all phases have completed? So, even though the set fields can happen in phase 1, the thread won't be released until the filters fire and deletes the marked records. Lyle -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Joe D'Souza Sent: Thursday, January 21, 2010 10:25 AM To: arslist@ARSLIST.ORG Subject: Re: Delete entry Fred, You are right in that calculation-wise it will not really have any benefit. But doing a delete in an escalation is not the best way - Delete is a 2nd phase operation and is queued. You do not want to hold the escalation thread longer than it should for this queue to complete. So having a filter aid the escalation to actually do the delete and the escalation only to mark the record to be deleted is a better approach as set fields is a fast operation that happens on the first phase of the transaction.. Joe -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org]on Behalf Of Grooms, Frederick W Sent: Thursday, January 21, 2010 12:16 PM To: arslist@ARSLIST.ORG Subject: Re: Delete entry Since it is on the right side of the equation and not using any fields from the form the Escalation should only do the calculation once. As for setting a field and having a Filter do the delete, that is my preferred method as well Fred -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Joe D'Souza Sent: Thursday, January 21, 2010 10:51 AM To: arslist@ARSLIST.ORG Subject: Re: Delete entry ** John, Should work but I'd make the process a little more data driven.. Instead of having the escalation calculate all this and chocking an escalation thread, I'd set that delete time to a temp field at the time of submitting the record. For e.g.. create a temp field called ztmpDeleteTime. Set the time $TIMESTAMP$ + 86400 to it using a filter.. Then have the Escalation check 'ztmpDeleteTime' < $TIMESTAMP$ and mark the record for deletion using another temp field that you have that escalation set say 'ztmpDelete' to Y.. Do not have the escalation delete it again for the purpose of not choking the escalation thread. Have a filter that performs that delete when the record is marked for deletion and the $USER$ is the escalation user. It would be more efficient especially over a large number of records.. Joe -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org]on Behalf Of John Kelley Sent: Thursday, January 21, 2010 11:39 AM To: arslist@ARSLIST.ORG Subject: Delete entry Hi All Brain cramp today Can someone confirm that this statement is true! I am performing a delete action in an escalation for deleting all items in a form 24 hours and beyond. Let me rephrase I want to leave items in the form for 24 hours from the submit date. 'Submit Date' < ( $TIMESTAMP$ - 86400) Sys:Action ARS 7.1 Thanks JK ________________________________________________________________________ _______ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: "Where the Answers Are" Classification: UNCLASSIFIED Caveats: NONE _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: "Where the Answers Are" ************************************************************* This e-mail message, including any attachments, is for the sole use of the addressee(s) to whom it has been sent, and may contain information that is confidential or legally protected. If you are not the intended recipient or have received this message in error, you are not authorized to copy, distribute, or otherwise use this message or its attachments. Please notify the sender immediately by return e-mail and permanently delete this message and any attachments. Dunkin' Brands Inc. makes no warranty that this e-mail is error or virus free.
