Re: Application-Query-Delete-Entry
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: arslist@ARSLIST.ORG
Subject: Re: Application-Query-Delete-Entry
Joe,
I know this discussion comes up every once in awhilebut 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:arslist@ARSLIST.ORG] On Behalf Of Joe Martin D'Souza
Sent: Thursday, December 08, 2011 11:33 AM
To: arslist@ARSLIST.ORG
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: arslist@ARSLIST.ORG
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:arslist@ARSLIST.ORG] On Behalf Of Larry Barnes
Sent: Thursday, December 08, 2011 10:23 AM
To: arslist@ARSLIST.ORG
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
Java API Help - StructItemInfo
Ok.I'm working in the API again and I have a question that's not documented.I'm hoping that someone has experience http://www.javasystemsolutions.com/documentation/thirdparty/arapiv71/arapi/c om/bmc/arsys/api/StructItemInfo.html so.you can either use the Constructor StructItemInfo(int type, String name, String[] selectedElements) Or, you can use the setSelectedElements(String[] elements) method But nowhere can I find a definition for what the 'elements' string array should be I'm trying to figure it out, but any help from someone that already has it figured out (or a BMC insider) would be helpful. Thanks ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: Where the Answers Are
Re: Application-Query-Delete-Entry
That shatters a long standing understanding I had about data driven
escalations. I had received this info at a Remedy training facility in
Bracknell in UK years ago, that you ought to help Escalations with Filters
triggered off modifications by the Escalation User in processing 2nd and 3rd
stage actions. I guess they were wrong when they instructed us so then..
That is one of the benefit that they explained of having Filters running
with a Run If of $USER$ = AR_ESCALATOR AND whatever else the rest of the
qualification may be.. The other benefit I'm guessing (I wasn’t told this
but it makes sense) is if you need to override filter phasing during the run
of an escalation..
Joe
-Original Message-
From: Misi Mladoniczky
Sent: Saturday, December 10, 2011 4:04 AM Newsgroups:
public.remedy.arsystem.general
To: arslist@ARSLIST.ORG
Subject: Re: Application-Query-Delete-Entry
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: arslist@ARSLIST.ORG
Subject: Re: Application-Query-Delete-Entry
Joe,
I know this discussion comes up every once in awhilebut 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:arslist@ARSLIST.ORG] On Behalf Of Joe Martin D'Souza
Sent: Thursday, December 08, 2011 11:33 AM
To: arslist@ARSLIST.ORG
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: arslist@ARSLIST.ORG
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 *
Re: SRM Issue
You could a build a Menu based question that queries CTM:People using the keyword $USER$ and have the user chose the value from the drop-down. But if the information is strictly for fulfillment purpose, the forms (Incident, Work Order, Change etc..) already have additional details (apart from what is displayed on Request Entry Console) and if needed, you can add more fields and a simple set fields filter action to populate the information. Thanks Mahesh On Fri, Dec 9, 2011 at 11:33 AM, Veeral Oza veer...@gmail.com wrote: ** Hi All, Need some help to figure out an SRM issue. ARS 7604 SP2 ITSM 7604 SP2 SRM 7604 SP2 As seen in the attached screen shot, the marked red section is the requester details, getting populated from CTM:People. There is a requirement to add few more People attributes in the marked red section. I want to avoid the use of AIFs. The entire submit request screen is a DVF field which is not easy to customize. I would like to know if there is a way to add more attributes in the marked red section and get them populated with CTM:People data of the requester. I also did some research and found that jar files must be modified to achieve this kind of customization. Need to know if there is another way. Regards, Veeral Oza _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
Re: Application-Query-Delete-Entry
From the Filter log (and this is even from Application-Query-Delete-Entry action) FLTR TID: 4027734928 RPC ID: 001637 Queue: Escalation Client-RPC: 390603 USER: AR_ESCALATOR (Pool 1) /* Sat Dec 10 2011 13:27:52.0979 */ Start filter processing (phase 1) -- Operation - DELETE on MyFormName - 5840476 As you can see the filters fire using the Escalation thread. Application-Query-Delete-Entry is a benefit when deleting child form records. Take the example of the order with line items. Instead of pushing a value to each line item for the order, you execute the Application-Query-Delete-Entry in the delete of the order record to delete the child line items. The main reason for using a field to trigger a delete (using a Filter) for me, is I can then manually trigger the same Filters at any time I need to. It makes testing my workflow so much easier than waiting for an Escalation and searching thru the logs. Fred -Original Message- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Joe Martin D'Souza Sent: Saturday, December 10, 2011 12:59 PM To: arslist@ARSLIST.ORG Subject: Re: Application-Query-Delete-Entry That shatters a long standing understanding I had about data driven escalations. I had received this info at a Remedy training facility in Bracknell in UK years ago, that you ought to help Escalations with Filters triggered off modifications by the Escalation User in processing 2nd and 3rd stage actions. I guess they were wrong when they instructed us so then.. That is one of the benefit that they explained of having Filters running with a Run If of $USER$ = AR_ESCALATOR AND whatever else the rest of the qualification may be.. The other benefit I'm guessing (I wasnt told this but it makes sense) is if you need to override filter phasing during the run of an escalation.. Joe -Original Message- From: Misi Mladoniczky Sent: Saturday, December 10, 2011 4:04 AM Newsgroups: public.remedy.arsystem.general To: arslist@ARSLIST.ORG Subject: Re: Application-Query-Delete-Entry 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. -Original Message- 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: arslist@ARSLIST.ORG Subject: Re: Application-Query-Delete-Entry Joe, I know this discussion comes up every once in awhilebut 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:arslist@ARSLIST.ORG] On Behalf Of Joe Martin D'Souza Sent: Thursday, December 08, 2011 11:33 AM To: arslist@ARSLIST.ORG 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
Re: Application-Query-Delete-Entry
On the note of waiting for an Escalation to run have you noticed in recent releases of Dev Studio you can right click on an Escalation and select Run Now? It is there for both Time and Interval escalations. Nice addition! Jason On Sat, Dec 10, 2011 at 11:50 AM, Grooms, Frederick W frederick.w.gro...@xo.com wrote: From the Filter log (and this is even from Application-Query-Delete-Entry action) FLTR TID: 4027734928 RPC ID: 001637 Queue: Escalation Client-RPC: 390603 USER: AR_ESCALATOR (Pool 1) /* Sat Dec 10 2011 13:27:52.0979 */ Start filter processing (phase 1) -- Operation - DELETE on MyFormName - 5840476 As you can see the filters fire using the Escalation thread. Application-Query-Delete-Entry is a benefit when deleting child form records. Take the example of the order with line items. Instead of pushing a value to each line item for the order, you execute the Application-Query-Delete-Entry in the delete of the order record to delete the child line items. The main reason for using a field to trigger a delete (using a Filter) for me, is I can then manually trigger the same Filters at any time I need to. It makes testing my workflow so much easier than waiting for an Escalation and searching thru the logs. Fred -Original Message- From: Action Request System discussion list(ARSList) [mailto: arslist@ARSLIST.ORG] On Behalf Of Joe Martin D'Souza Sent: Saturday, December 10, 2011 12:59 PM To: arslist@ARSLIST.ORG Subject: Re: Application-Query-Delete-Entry That shatters a long standing understanding I had about data driven escalations. I had received this info at a Remedy training facility in Bracknell in UK years ago, that you ought to help Escalations with Filters triggered off modifications by the Escalation User in processing 2nd and 3rd stage actions. I guess they were wrong when they instructed us so then.. That is one of the benefit that they explained of having Filters running with a Run If of $USER$ = AR_ESCALATOR AND whatever else the rest of the qualification may be.. The other benefit I'm guessing (I wasnt told this but it makes sense) is if you need to override filter phasing during the run of an escalation.. Joe -Original Message- From: Misi Mladoniczky Sent: Saturday, December 10, 2011 4:04 AM Newsgroups: public.remedy.arsystem.general To: arslist@ARSLIST.ORG Subject: Re: Application-Query-Delete-Entry 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. -Original Message- 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: arslist@ARSLIST.ORG Subject: Re: Application-Query-Delete-Entry Joe, I know this discussion comes up every once in awhilebut 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:arslist@ARSLIST.ORG] On Behalf Of Joe Martin D'Souza Sent: Thursday, December 08, 2011 11:33 AM To: arslist@ARSLIST.ORG
Re: Application-Query-Delete-Entry
That sure is a cool feature – new addition... Does it work? :-) Yup those logs are indicative that filters run on the same thread. Delete from memory where instructions LIKE ‘%filters use a separate thread%’; commit transaction; Thanks for correcting me.. hopefully my memory wont rollback again to what I was taught :-) Joe From: Jason Miller Sent: Saturday, December 10, 2011 4:49 PM Newsgroups: public.remedy.arsystem.general To: arslist@ARSLIST.ORG Subject: Re: Application-Query-Delete-Entry ** On the note of waiting for an Escalation to run have you noticed in recent releases of Dev Studio you can right click on an Escalation and select Run Now? It is there for both Time and Interval escalations. Nice addition! Jason On Sat, Dec 10, 2011 at 11:50 AM, Grooms, Frederick W frederick.w.gro...@xo.com wrote: From the Filter log (and this is even from Application-Query-Delete-Entry action) FLTR TID: 4027734928 RPC ID: 001637 Queue: Escalation Client-RPC: 390603 USER: AR_ESCALATOR (Pool 1) /* Sat Dec 10 2011 13:27:52.0979 */ Start filter processing (phase 1) -- Operation - DELETE on MyFormName - 5840476 As you can see the filters fire using the Escalation thread. Application-Query-Delete-Entry is a benefit when deleting child form records. Take the example of the order with line items. Instead of pushing a value to each line item for the order, you execute the Application-Query-Delete-Entry in the delete of the order record to delete the child line items. The main reason for using a field to trigger a delete (using a Filter) for me, is I can then manually trigger the same Filters at any time I need to. It makes testing my workflow so much easier than waiting for an Escalation and searching thru the logs. Fred -Original Message- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Joe Martin D'Souza Sent: Saturday, December 10, 2011 12:59 PM To: arslist@ARSLIST.ORG Subject: Re: Application-Query-Delete-Entry That shatters a long standing understanding I had about data driven escalations. I had received this info at a Remedy training facility in Bracknell in UK years ago, that you ought to help Escalations with Filters triggered off modifications by the Escalation User in processing 2nd and 3rd stage actions. I guess they were wrong when they instructed us so then.. That is one of the benefit that they explained of having Filters running with a Run If of $USER$ = AR_ESCALATOR AND whatever else the rest of the qualification may be.. The other benefit I'm guessing (I wasnt told this but it makes sense) is if you need to override filter phasing during the run of an escalation.. Joe -Original Message- From: Misi Mladoniczky Sent: Saturday, December 10, 2011 4:04 AM Newsgroups: public.remedy.arsystem.general To: arslist@ARSLIST.ORG Subject: Re: Application-Query-Delete-Entry 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. -Original Message- 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: arslist@ARSLIST.ORG Subject: Re: Application-Query-Delete-Entry Joe, I know this discussion comes up every once in awhilebut 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
