RE: Escalation Error
I guess you are making an equal to query on clob data type. What all is on stack on AR? Esclation+API+SQL logs may help find the piece. From: ARSList [mailto:arslist-boun...@arslist.org] On Behalf Of Brittain, Mark Sent: 19 September 2018 02:02 To: ARList (arslist@ARSLIST.ORG) Subject: Escalation Error HI All I am seeing two strange escalation errors that I can't identify based on the logs. An application command failed.ERROR (552): The SQL database operation failed.; ORA-00932: inconsistent datatypes: expected - got CLOB` Error while performing escalation action Both are in pool 1. I have been able to rule out any custom escalations, very few, and am hoping not to have to check each OTB escalation if hopes of finding the bad guys. Has anyone encountered this. ARS 9.1.4. Thanks Mark Mark Brittain | Senior Systems Engineer | 315.634.9337 125 Elwood Davis Road | Syracuse NY 13212 [new_spectrum] -- ARSList mailing list ARSList@arslist.org https://mailman.rrr.se/cgi/listinfo/arslist
Escalation Error
HI All I am seeing two strange escalation errors that I can't identify based on the logs. An application command failed.ERROR (552): The SQL database operation failed.; ORA-00932: inconsistent datatypes: expected - got CLOB` Error while performing escalation action Both are in pool 1. I have been able to rule out any custom escalations, very few, and am hoping not to have to check each OTB escalation if hopes of finding the bad guys. Has anyone encountered this. ARS 9.1.4. Thanks Mark Mark Brittain | Senior Systems Engineer | 315.634.9337 125 Elwood Davis Road | Syracuse NY 13212 [new_spectrum] -- ARSList mailing list ARSList@arslist.org https://mailman.rrr.se/cgi/listinfo/arslist
Log says escalation enabled AND "is turned off"
ARSlisters,
I have an unmodified OOB escalation in ITSM that should run, but is 'turned
off'.
It starts the notification process after a survey is created in "SRM:Survey"
LOG:
/* Checking "SRM:SRV:TriggerSurveyNotification" (enabled) : is turned off
/* Checking "SRM:SRV:TriggerSurveyNotification" (enabled) : going to fire
in 3563
ENVIRONMENT
ARS/ITSM 9.1.x
Single server
Escalations enabled in AR Server Admin console AND in ar.cfg
Escalation threads min = 6, max =6
Pool NULL or 1 (no impact)
All other escalations are running, just this one is 'turned off'.
We built a copy of this escalation ("SRM:SRV:TriggerSurveyNotification2")
and got the same result.
We now have 2 escalations 'turned off'; the unmodified OOB original and our
'custom' duplicate.
Could this be FORM-related?
Anyone have any idea what's stopping these escalations?
TIA,
Joel
Joel Sender * jdsen...@earthlink.net
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
--
ARSList mailing list
ARSList@arslist.org
https://mailman.rrr.se/cgi/listinfo/arslist
RE: [Ext] Help with Escalation on how to Run on Last Record, Only
Thank you to all of you for your great suggestions…I really do appreciate it. For now, I’m going to rely on the “Recovery” settings on the BMC Remedy Email Engine service to restart the service in the event it should stop. In the meantime, I will spend some time going through each of your ideas and see what I can come up with. Thanks again, Susan From: ARSList [mailto:arslist-boun...@arslist.org] On Behalf Of Dave Shellman Sent: June-18-18 4:46 PM To: ARSList Subject: Re: [Ext] Help with Escalation on how to Run on Last Record, Only In the past I created a process that would send out an email that would create a record in another form. This method tested outbound/inbound email. The process would excercise 4 mail accounts that were setup for incoming email. It would also provide us with health info on the email servers. The outbound email would contain a GUID. When the inbound email was received, a filter would set the status field of the record in the sending form to Received that using the GUID. An escalation would run every 20 minutes checking the Status field. If any records matched, an SMS would be sent to the admins. Dave On Mon, Jun 18, 2018 at 4:28 PM pritch via ARSList mailto:arslist@arslist.org>> wrote: What I’ve done in the past on this is if the queue is backing up (I set up a diagnostics form where I can put the number of records that is the threshold) and run an escalation against that form (in this case the ar system email message form for how many are set to ‘Yes’. You can use the ‘lastcount’ keyword into a field after a dummy set field action or something like that. In the case of the emails not going out (as was mentioned) you can’t send an email out as a notification, but you can put some sort of display field on the console that then is displayed to say the service desk folks when they’re in the console or even when they bring up a new incident (have the field display for that group or functional role) if they number of messages are above the threshold. I’ve even set two thresholds in some cases – one for a warning (where the number may be high, but not calling for immediate action and another for an outright error. I’ve done this for emails, DSO actions, sys:action and other transitional forms where a process is run on the records. Hope this helps a bit. - Original Message - From: "Powell, Timothy" mailto:timothy.powe...@nscorp.com>> To: "arslist" mailto:arslist@arslist.org>> Sent: Monday, June 18, 2018 4:00:26 PM Subject: RE: [Ext] Help with Escalation on how to Run on Last Record, Only You don’t mention if your using ITSM or custom apps, but here’s another way to skin the cat which will work if you’re using any kind of console that displays assigned tickets. It will work without a console, but would require “somebody” monitoring for new helpdesk tickets in some manner. Have the escalation run as you described. If it finds a match, create a new helpdesk ticket for the issue and assign it to your Remedy support/administrator team during business hours and maybe your service desk group if it’s after hours. Once it pops up on the console, then somebody will see it and can take action. If you want to add some spice to the recipe, get the list of email messages meeting the criteria in a table, have the escalation do a table walk using a filter guide and you can accomplish the same thing AND get a count of the number of messages meeting the criteria, thus adding some sense of urgency to the ticket. Just some thoughts. Tim Powell From: ARSList [mailto:arslist-boun...@arslist.org<mailto:arslist-boun...@arslist.org>] On Behalf Of Champagne, Susan Sent: Monday, June 18, 2018 3:27 PM To: 'ARSList' mailto:arslist@arslist.org>> Subject: [EXTERNAL] RE: [Ext] Help with Escalation on how to Run on Last Record, Only Thank you Randy, for your quick response. How I missed the obvious is beyond me right now (no notification if the e-mail service isn’t running); so, thank you for pointing that out. I will speak with our server analysts to see if we have any such tools to monitor a server. Much appreciated! Susan From: ARSList [ [ mailto:arslist-boun...@arslist.org<mailto:arslist-boun...@arslist.org> | mailto:arslist-boun...@arslist.org<mailto:arslist-boun...@arslist.org> ] ] On Behalf Of Mckinnish, Randy via ARSList Sent: June-18-18 3:18 PM To: ARSList Cc: Mckinnish, Randy Subject: RE: [Ext] Help with Escalation on how to Run on Last Record, Only Susan, Even if the escalation fired and ran, if the email engine service is down I am thinking the notification would only queue and not send until the mail engine service was online again. Do you use any monitoring tools in-house like scom or zabbix? We have had success using those to monitor a service and if the service stops, the team is notified and it isn’t dependent
Re: [Ext] Help with Escalation on how to Run on Last Record, Only
In the past I created a process that would send out an email that would create a record in another form. This method tested outbound/inbound email. The process would excercise 4 mail accounts that were setup for incoming email. It would also provide us with health info on the email servers. The outbound email would contain a GUID. When the inbound email was received, a filter would set the status field of the record in the sending form to Received that using the GUID. An escalation would run every 20 minutes checking the Status field. If any records matched, an SMS would be sent to the admins. Dave On Mon, Jun 18, 2018 at 4:28 PM pritch via ARSList wrote: > What I’ve done in the past on this is if the queue is backing up (I set up > a diagnostics form where I can put the number of records that is the > threshold) and run an escalation against that form (in this case the ar > system email message form for how many are set to ‘Yes’. You can use the > ‘lastcount’ keyword into a field after a dummy set field action or > something like that. > > In the case of the emails not going out (as was mentioned) you can’t send > an email out as a notification, but you can put some sort of display field > on the console that then is displayed to say the service desk folks when > they’re in the console or even when they bring up a new incident (have the > field display for that group or functional role) if they number of messages > are above the threshold. > > I’ve even set two thresholds in some cases – one for a warning (where the > number may be high, but not calling for immediate action and another for an > outright error. I’ve done this for emails, DSO actions, sys:action and > other transitional forms where a process is run on the records. > > Hope this helps a bit. > > > - Original Message - > From: "Powell, Timothy" > To: "arslist" > Sent: Monday, June 18, 2018 4:00:26 PM > Subject: RE: [Ext] Help with Escalation on how to Run on Last Record, Only > > You don’t mention if your using ITSM or custom apps, but here’s another > way to skin the cat which will work if you’re using any kind of console > that displays assigned tickets. It will work without a console, but would > require “somebody” monitoring for new helpdesk tickets in some manner. > > > > Have the escalation run as you described. If it finds a match, create a > new helpdesk ticket for the issue and assign it to your Remedy > support/administrator team during business hours and maybe your service > desk group if it’s after hours. Once it pops up on the console, then > somebody will see it and can take action. > > > > If you want to add some spice to the recipe, get the list of email > messages meeting the criteria in a table, have the escalation do a table > walk using a filter guide and you can accomplish the same thing AND get a > count of the number of messages meeting the criteria, thus adding some > sense of urgency to the ticket. > > > > Just some thoughts. > > > > > Tim Powell > > > > > > > > From: ARSList [mailto:arslist-boun...@arslist.org] On Behalf Of > Champagne, Susan > Sent: Monday, June 18, 2018 3:27 PM > To: 'ARSList' > Subject: [EXTERNAL] RE: [Ext] Help with Escalation on how to Run on Last > Record, Only > > > > > Thank you Randy, for your quick response. How I missed the obvious is > beyond me right now (no notification if the e-mail service isn’t running); > so, thank you for pointing that out. I will speak with our server analysts > to see if we have any such tools to monitor a server. > > > > Much appreciated! > > > > > Susan > > > > > > From: ARSList [ [ mailto:arslist-boun...@arslist.org | mailto: > arslist-boun...@arslist.org ] ] On Behalf Of Mckinnish, Randy via ARSList > Sent: June-18-18 3:18 PM > To: ARSList > Cc: Mckinnish, Randy > Subject: RE: [Ext] Help with Escalation on how to Run on Last Record, Only > > > > > Susan, > > Even if the escalation fired and ran, if the email engine service is down > I am thinking the notification would only queue and not send until the mail > engine service was online again. Do you use any monitoring tools in-house > like scom or zabbix? We have had success using those to monitor a service > and if the service stops, the team is notified and it isn’t dependent on > ARS services for delivery of the alert that something has gone wrong. > > > > Thanks > > > > > From: ARSList < [ mailto:arslist-boun...@arslist.org | > arslist-boun...@arslist.org ] > On Behalf Of Champagne, Susan > Sent: Monday, June 18, 2018 2:53 PM > To: [ mailto:arslist@arslist.org | arslist@arslist.o
Re: [Ext] Help with Escalation on how to Run on Last Record, Only
What I’ve done in the past on this is if the queue is backing up (I set up a diagnostics form where I can put the number of records that is the threshold) and run an escalation against that form (in this case the ar system email message form for how many are set to ‘Yes’. You can use the ‘lastcount’ keyword into a field after a dummy set field action or something like that. In the case of the emails not going out (as was mentioned) you can’t send an email out as a notification, but you can put some sort of display field on the console that then is displayed to say the service desk folks when they’re in the console or even when they bring up a new incident (have the field display for that group or functional role) if they number of messages are above the threshold. I’ve even set two thresholds in some cases – one for a warning (where the number may be high, but not calling for immediate action and another for an outright error. I’ve done this for emails, DSO actions, sys:action and other transitional forms where a process is run on the records. Hope this helps a bit. - Original Message - From: "Powell, Timothy" To: "arslist" Sent: Monday, June 18, 2018 4:00:26 PM Subject: RE: [Ext] Help with Escalation on how to Run on Last Record, Only You don’t mention if your using ITSM or custom apps, but here’s another way to skin the cat which will work if you’re using any kind of console that displays assigned tickets. It will work without a console, but would require “somebody” monitoring for new helpdesk tickets in some manner. Have the escalation run as you described. If it finds a match, create a new helpdesk ticket for the issue and assign it to your Remedy support/administrator team during business hours and maybe your service desk group if it’s after hours. Once it pops up on the console, then somebody will see it and can take action. If you want to add some spice to the recipe, get the list of email messages meeting the criteria in a table, have the escalation do a table walk using a filter guide and you can accomplish the same thing AND get a count of the number of messages meeting the criteria, thus adding some sense of urgency to the ticket. Just some thoughts. Tim Powell From: ARSList [mailto:arslist-boun...@arslist.org] On Behalf Of Champagne, Susan Sent: Monday, June 18, 2018 3:27 PM To: 'ARSList' Subject: [EXTERNAL] RE: [Ext] Help with Escalation on how to Run on Last Record, Only Thank you Randy, for your quick response. How I missed the obvious is beyond me right now (no notification if the e-mail service isn’t running); so, thank you for pointing that out. I will speak with our server analysts to see if we have any such tools to monitor a server. Much appreciated! Susan From: ARSList [ [ mailto:arslist-boun...@arslist.org | mailto:arslist-boun...@arslist.org ] ] On Behalf Of Mckinnish, Randy via ARSList Sent: June-18-18 3:18 PM To: ARSList Cc: Mckinnish, Randy Subject: RE: [Ext] Help with Escalation on how to Run on Last Record, Only Susan, Even if the escalation fired and ran, if the email engine service is down I am thinking the notification would only queue and not send until the mail engine service was online again. Do you use any monitoring tools in-house like scom or zabbix? We have had success using those to monitor a service and if the service stops, the team is notified and it isn’t dependent on ARS services for delivery of the alert that something has gone wrong. Thanks From: ARSList < [ mailto:arslist-boun...@arslist.org | arslist-boun...@arslist.org ] > On Behalf Of Champagne, Susan Sent: Monday, June 18, 2018 2:53 PM To: [ mailto:arslist@arslist.org | arslist@arslist.org ] Subject: [Ext] Help with Escalation on how to Run on Last Record, Only This email contains a link or attachment. Please make sure it’s from a trusted source before you open the attachment or click on the link Hi folks, I’m hoping one of you will be able to assist me with what I’m trying to accomplish. My goal is to have Remedy send a notification message to the Service Desk whenever our e-mail service stops running. I’m working on an escalation where the Primary Form is “AR System Email Messages”. My problem is with the Run If Qualification. Here’s what I’ve got so far: Run If Qualification (‘Send Message’ = “Yes”) AND (($TIMESTAM$ - ‘Create Date’) > 300) What I wanted to do was to add a condition to have the escalation only check the last record on the form, in order to prevent multiple messages being sent. From my research I found some hits indicating I could use something like “ (‘Email ID’ = “MAX (‘Email ID’))”, but this isn’t working when I try to add it to the qualification. I’m using Developer Studio Version 9.1.03 with Remedy AR System 9.1. Any assistance with this would be greatly appreciated. Thank y
Re: [Ext] Help with Escalation on how to Run on Last Record, Only
What I have done in the past is to create an configuration form where there is a single configuration record for each escalation I wanted to only run on one record. Basically you create a form that stores your configuration with a status (allows you to easily "turn off" this escalation record) and some unique identifier the Run If of your escalations looks for. Let's call our form "SHR:Escalations". In this example have one record in the form with the Name (can use Short Description field if you would like) "CHECK_4_PENDING_EMAIL". You then create an escalation against the SHR:Escalations form with the Run If: 'Status' = "Enabled" and 'Name' = " CHECK_4_PENDING_EMAIL" When you escalation fires (once) it performs a modification to this configuration record (you could use a Display Only field and not modify the record) which then kicks off a filter that will go look for matching AR System Email Messages records (your Run If in your original email) and if there is a match set a field with some data from that transaction (like Email ID of a matching record, let's call the field zTmpPendingEmail_ID). One thing to note if zTmpPendingEmail_ID is a regular field, since it is very likely that same Email Messages record will be found by the Set Fields after the email engine stops sending mail, the transaction will only be different the first time the escalation runs (after the email engine stops sending email). You may or may not want this (example only notify people once when the system stopped sending email). If you want to notify people each time the escalation runs after the email engine stops sending email you can use something like $Email ID$ + "_" + $TIMESTAMP$ in your Set Fields. You then have a filter(s) with Run If like 'Status' = "Enabled" AND 'Name' = "CHECK_4_PENDING_EMAIL" AND 'DB.zTmpPendingEmail_ID' != ' zTmpPendingEmail_ID' that do whatever you want. You could call a script to send an email from the OS instead of using the Email Engine. When I have used this setup in the past to address the email engine not sending email, I found restarting the email engine would usually take care of the issue so there was no manual intervention needed. You can look at this tread for an example batch file that will restart the email engine (Windows) and there is also at least one other idea that uses a .vbs script to monitor email: https://mailman.rrr.se/arslist/1103/msg00794.html The other thing I have see is a scheduled SQL job runs every few minutes that basically does the same thing, looking for older email messages records that have not been sent, and then sends a notification via the DB's mail system. Jason On Mon, Jun 18, 2018 at 2:27 PM, Champagne, Susan wrote: > Thank you Randy, for your quick response. How I missed the obvious is > beyond me right now (no notification if the e-mail service isn’t running); > so, thank you for pointing that out. I will speak with our server analysts > to see if we have any such tools to monitor a server. > > > > Much appreciated! > > > > Susan > > > > *From:* ARSList [mailto:arslist-boun...@arslist.org] *On Behalf Of *Mckinnish, > Randy via ARSList > *Sent:* June-18-18 3:18 PM > *To:* ARSList > *Cc:* Mckinnish, Randy > *Subject:* RE: [Ext] Help with Escalation on how to Run on Last Record, > Only > > > > Susan, > > Even if the escalation fired and ran, if the email engine service is down > I am thinking the notification would only queue and not send until the mail > engine service was online again. Do you use any monitoring tools in-house > like scom or zabbix? We have had success using those to monitor a service > and if the service stops, the team is notified and it isn’t dependent on > ARS services for delivery of the alert that something has gone wrong. > > > > Thanks > > > > *From:* ARSList *On Behalf Of *Champagne, > Susan > *Sent:* Monday, June 18, 2018 2:53 PM > *To:* arslist@arslist.org > *Subject:* [Ext] Help with Escalation on how to Run on Last Record, Only > > > > This email contains a link or attachment. Please make sure it’s from a > trusted source before you open the attachment or click on the link > > Hi folks, > > I’m hoping one of you will be able to assist me with what I’m trying to > accomplish. > > > > My goal is to have Remedy send a notification message to the Service Desk > whenever our e-mail service stops running. I’m working on an escalation > where the Primary Form is “AR System Email Messages”. My problem is with > the Run If Qualification. Here’s what I’ve got so far: > > > > Run If Qualification > > (‘Send Message’ = “Yes”) AND (($TIMESTAM$ - ‘Create D
RE: [Ext] Help with Escalation on how to Run on Last Record, Only
You don’t mention if your using ITSM or custom apps, but here’s another way to skin the cat which will work if you’re using any kind of console that displays assigned tickets. It will work without a console, but would require “somebody” monitoring for new helpdesk tickets in some manner. Have the escalation run as you described. If it finds a match, create a new helpdesk ticket for the issue and assign it to your Remedy support/administrator team during business hours and maybe your service desk group if it’s after hours. Once it pops up on the console, then somebody will see it and can take action. If you want to add some spice to the recipe, get the list of email messages meeting the criteria in a table, have the escalation do a table walk using a filter guide and you can accomplish the same thing AND get a count of the number of messages meeting the criteria, thus adding some sense of urgency to the ticket. Just some thoughts. Tim Powell From: ARSList [mailto:arslist-boun...@arslist.org] On Behalf Of Champagne, Susan Sent: Monday, June 18, 2018 3:27 PM To: 'ARSList' Subject: [EXTERNAL] RE: [Ext] Help with Escalation on how to Run on Last Record, Only Thank you Randy, for your quick response. How I missed the obvious is beyond me right now (no notification if the e-mail service isn’t running); so, thank you for pointing that out. I will speak with our server analysts to see if we have any such tools to monitor a server. Much appreciated! Susan From: ARSList [mailto:arslist-boun...@arslist.org] On Behalf Of Mckinnish, Randy via ARSList Sent: June-18-18 3:18 PM To: ARSList Cc: Mckinnish, Randy Subject: RE: [Ext] Help with Escalation on how to Run on Last Record, Only Susan, Even if the escalation fired and ran, if the email engine service is down I am thinking the notification would only queue and not send until the mail engine service was online again. Do you use any monitoring tools in-house like scom or zabbix? We have had success using those to monitor a service and if the service stops, the team is notified and it isn’t dependent on ARS services for delivery of the alert that something has gone wrong. Thanks From: ARSList mailto:arslist-boun...@arslist.org>> On Behalf Of Champagne, Susan Sent: Monday, June 18, 2018 2:53 PM To: arslist@arslist.org<mailto:arslist@arslist.org> Subject: [Ext] Help with Escalation on how to Run on Last Record, Only This email contains a link or attachment. Please make sure it’s from a trusted source before you open the attachment or click on the link Hi folks, I’m hoping one of you will be able to assist me with what I’m trying to accomplish. My goal is to have Remedy send a notification message to the Service Desk whenever our e-mail service stops running. I’m working on an escalation where the Primary Form is “AR System Email Messages”. My problem is with the Run If Qualification. Here’s what I’ve got so far: Run If Qualification (‘Send Message’ = “Yes”) AND (($TIMESTAM$ - ‘Create Date’) > 300) What I wanted to do was to add a condition to have the escalation only check the last record on the form, in order to prevent multiple messages being sent. From my research I found some hits indicating I could use something like “ (‘Email ID’ = “MAX (‘Email ID’))”, but this isn’t working when I try to add it to the qualification. I’m using Developer Studio Version 9.1.03 with Remedy AR System 9.1. Any assistance with this would be greatly appreciated. Thank you, Susan Health Sciences North's vision is to be globally recognized for patient-centred innovation. The information contained in this e-mail and document(s) attached are for the exclusive use of the addressee and may contain confidential, privileged and non-disclosable information. If the recipient of this e-mail is not the addressee, such recipient is strictly prohibited from reading, photocopying, distributing or otherwise using this e-mail or its content in any way. This email is subject to certain disclaimers, which may be reviewed via the following link. http://www.compass-usa.com/disclaimer/ Health Sciences North's vision is to be globally recognized for patient-centred innovation. -- ARSList mailing list ARSList@arslist.org https://mailman.rrr.se/cgi/listinfo/arslist
RE: [Ext] Help with Escalation on how to Run on Last Record, Only
Thank you Randy, for your quick response. How I missed the obvious is beyond me right now (no notification if the e-mail service isn’t running); so, thank you for pointing that out. I will speak with our server analysts to see if we have any such tools to monitor a server. Much appreciated! Susan From: ARSList [mailto:arslist-boun...@arslist.org] On Behalf Of Mckinnish, Randy via ARSList Sent: June-18-18 3:18 PM To: ARSList Cc: Mckinnish, Randy Subject: RE: [Ext] Help with Escalation on how to Run on Last Record, Only Susan, Even if the escalation fired and ran, if the email engine service is down I am thinking the notification would only queue and not send until the mail engine service was online again. Do you use any monitoring tools in-house like scom or zabbix? We have had success using those to monitor a service and if the service stops, the team is notified and it isn’t dependent on ARS services for delivery of the alert that something has gone wrong. Thanks From: ARSList mailto:arslist-boun...@arslist.org>> On Behalf Of Champagne, Susan Sent: Monday, June 18, 2018 2:53 PM To: arslist@arslist.org<mailto:arslist@arslist.org> Subject: [Ext] Help with Escalation on how to Run on Last Record, Only This email contains a link or attachment. Please make sure it’s from a trusted source before you open the attachment or click on the link Hi folks, I’m hoping one of you will be able to assist me with what I’m trying to accomplish. My goal is to have Remedy send a notification message to the Service Desk whenever our e-mail service stops running. I’m working on an escalation where the Primary Form is “AR System Email Messages”. My problem is with the Run If Qualification. Here’s what I’ve got so far: Run If Qualification (‘Send Message’ = “Yes”) AND (($TIMESTAM$ - ‘Create Date’) > 300) What I wanted to do was to add a condition to have the escalation only check the last record on the form, in order to prevent multiple messages being sent. From my research I found some hits indicating I could use something like “ (‘Email ID’ = “MAX (‘Email ID’))”, but this isn’t working when I try to add it to the qualification. I’m using Developer Studio Version 9.1.03 with Remedy AR System 9.1. Any assistance with this would be greatly appreciated. Thank you, Susan Health Sciences North's vision is to be globally recognized for patient-centred innovation. The information contained in this e-mail and document(s) attached are for the exclusive use of the addressee and may contain confidential, privileged and non-disclosable information. If the recipient of this e-mail is not the addressee, such recipient is strictly prohibited from reading, photocopying, distributing or otherwise using this e-mail or its content in any way. This email is subject to certain disclaimers, which may be reviewed via the following link. http://www.compass-usa.com/disclaimer/ Health Sciences North's vision is to be globally recognized for patient-centred innovation. -- ARSList mailing list ARSList@arslist.org https://mailman.rrr.se/cgi/listinfo/arslist
RE: [Ext] Help with Escalation on how to Run on Last Record, Only
Susan, Even if the escalation fired and ran, if the email engine service is down I am thinking the notification would only queue and not send until the mail engine service was online again. Do you use any monitoring tools in-house like scom or zabbix? We have had success using those to monitor a service and if the service stops, the team is notified and it isn’t dependent on ARS services for delivery of the alert that something has gone wrong. Thanks From: ARSList On Behalf Of Champagne, Susan Sent: Monday, June 18, 2018 2:53 PM To: arslist@arslist.org Subject: [Ext] Help with Escalation on how to Run on Last Record, Only This email contains a link or attachment. Please make sure it’s from a trusted source before you open the attachment or click on the link Hi folks, I’m hoping one of you will be able to assist me with what I’m trying to accomplish. My goal is to have Remedy send a notification message to the Service Desk whenever our e-mail service stops running. I’m working on an escalation where the Primary Form is “AR System Email Messages”. My problem is with the Run If Qualification. Here’s what I’ve got so far: Run If Qualification (‘Send Message’ = “Yes”) AND (($TIMESTAM$ - ‘Create Date’) > 300) What I wanted to do was to add a condition to have the escalation only check the last record on the form, in order to prevent multiple messages being sent. From my research I found some hits indicating I could use something like “ (‘Email ID’ = “MAX (‘Email ID’))”, but this isn’t working when I try to add it to the qualification. I’m using Developer Studio Version 9.1.03 with Remedy AR System 9.1. Any assistance with this would be greatly appreciated. Thank you, Susan Health Sciences North's vision is to be globally recognized for patient-centred innovation. The information contained in this e-mail and document(s) attached are for the exclusive use of the addressee and may contain confidential, privileged and non-disclosable information. If the recipient of this e-mail is not the addressee, such recipient is strictly prohibited from reading, photocopying, distributing or otherwise using this e-mail or its content in any way. This email is subject to certain disclaimers, which may be reviewed via the following link. http://www.compass-usa.com/disclaimer/ -- ARSList mailing list ARSList@arslist.org https://mailman.rrr.se/cgi/listinfo/arslist
Help with Escalation on how to Run on Last Record, Only
Hi folks,
I'm hoping one of you will be able to assist me with what I'm trying to
accomplish.
My goal is to have Remedy send a notification message to the Service Desk
whenever our e-mail service stops running. I'm working on an escalation where
the Primary Form is "AR System Email Messages". My problem is with the Run If
Qualification. Here's what I've got so far:
Run If Qualification
('Send Message' = "Yes") AND (($TIMESTAM$ - 'Create Date') > 300)
What I wanted to do was to add a condition to have the escalation only check
the last record on the form, in order to prevent multiple messages being sent.
From my research I found some hits indicating I could use something like "
('Email ID' = "MAX ('Email ID'))", but this isn't working when I try to add it
to the qualification.
I'm using Developer Studio Version 9.1.03 with Remedy AR System 9.1.
Any assistance with this would be greatly appreciated.
Thank you,
Susan
Health Sciences North's vision is to be globally recognized for patient-centred
innovation.
The information contained in this e-mail and document(s) attached are for the
exclusive use of the addressee and may contain confidential, privileged and
non-disclosable information. If the recipient of this e-mail is not the
addressee, such recipient is strictly prohibited from reading, photocopying,
distributing or otherwise using this e-mail or its content in any way.
--
ARSList mailing list
ARSList@arslist.org
https://mailman.rrr.se/cgi/listinfo/arslist
Re: Delete Through Escalation vs Delete through DB
Misi, I would agree with you if all that my tool did was accept Remedy basked queries, but it accepts SQL queries which can be quite a bit more complex utilizing all of the SQL capabilities to identify which records to removefor example, you can issue an SQL query that tells it to delete all of the orphaned Task recordssomething that a Remedy Query simply wouldn't be able to identify. On Mon, Jul 24, 2017 at 5:26 AM, Misi Mladoniczky wrote: > ** > Hi, > > Converting the LJ delete tool to a filter plugin seems a little bit > pointless as you have the run process equivalents of > Application-Delete-Entry and Application-Query-Delete-Entry already at hand > in filters and escalations. > > Using escalations to search for your records followed by > Application-Delete-Entry > for every row is best in most circumstances where you are dealing with a > lot of data. Using Application-Query-Delete-Entry will process all records > within a single transaction, which might tax your system... > > Best Regards - Misi, RRR AB, http://www.rrr.se (ARSList MVP 2011) > > Ask the Remedy Licensing Experts (Best R.O.I. Award at WWRUG10/11/12/13) > * 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 > > July 22, 2017 2:51 PM, "LJ LongWing" <%22lj%20longwing%22%20%3clj.longw...@gmail.com%3E>> wrote: > > ** > Thomas, > Yes...it could be done as an API Filter PluginI've been thinking about > that since you askedthe only problem I can see with a Filter Plugin > would be the feedback portion. As it is, running it, you get the feedback > in the log about what was attempted, what was executed, etc...I could > output all of that to the plugin log through normal channels if that would > be okI'd just never thought of doing it through a plugin before > On Sat, Jul 22, 2017 at 2:02 AM, Thomas Miskiewicz > wrote: > > ** > LJ, > can we have your tool as a API Filter plugin? > Thomas > > On 21. Jul 2017, at 23:29, LJ LongWing wrote: > > ** > Harsh, > Deleting from the DB will always be faster than deleting from the > applications server because you are removing the overhead of the Remedy > server, that being said however, I always do my deletes against the app > server. I do this for many reasons, but data integrity is one of them. When > you do your deletes through the app server, you get 'all' of the pieces > that you are supposed to get (T, H, B, BNCN)for this reason, deleting > though the app server is preferred, from my perspective at least. With this > thought in mind, I have produced a tool that I have used personally for > several years, and with the assistance of Jason Miller, moved more > mainstream and increased performance from it by making it multi-threaded. > http://remedylegacy.com/tools/delete-requests/ > This tool uses an SQL query to identify the records that need to be > removed, and then uses the api to do the actual removal. Because it's using > the API, it'll make any workflow that fires on delete fire, which can cause > you do have a cascade effect cleaning up parent/child/grandchild/etc > relationships > In general, I recommend not doing anything with the Remedy DB directly at > the DB level, there are of course all sorts of people that do with no > impact at all, or no noticeable impact, but in general, having done Remedy > for as many years a I haveI believe the data should be inserted into, > modified, and removed from the Remedy DB by the Remedy application server... > On Fri, Jul 21, 2017 at 2:56 PM, Harsh wrote: > > ** Hi All, > Today i got into an argument where one of > my colleague was deleting 57K records from custom form through > Escalations. I asked him to better use a delete query on arsystem database. > As it will delete the records faster then escalations. > As per him both will take same amount of time. But i believe escalation > will take more time as it has to make a call to DB everytime and somehow > will add the processing time on the server. > Please let me know your thoughts upon the same. > Thanks, > Harsh > > > -- > *Thanks & regards* > *“Harsh Chaudhary”* > *"Impatience never commanded success**"* > > > _ARSlist: "Where the Answers Are" and have been for 20 years_ > > _ARSlist: "Where the Answers Are" and have been for 20 years_ > > _ARSlist: "Where the Answers Are" and have been for 20 years_ > > _ARSlist: "Where the Answers Are" and have been for 20 years_ > > _ARSlist: "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"
Re: Delete Through Escalation vs Delete through DB
Hi, Converting the LJ delete tool to a filter plugin seems a little bit pointless as you have the run process equivalents of Application-Delete-Entry and Application-Query-Delete-Entry already at hand in filters and escalations. Using escalations to search for your records followed by Application-Delete-Entry for every row is best in most circumstances where you are dealing with a lot of data. Using Application-Query-Delete-Entry will process all records within a single transaction, which might tax your system... Best Regards - Misi, RRR AB, http://www.rrr.se (http://www.rrr.se) (ARSList MVP 2011) Ask the Remedy Licensing Experts (Best R.O.I. Award at WWRUG10/11/12/13) * 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 (http://rrr.se) July 22, 2017 2:51 PM, "LJ LongWing" wrote: **Thomas, Yes...it could be done as an API Filter PluginI've been thinking about that since you askedthe only problem I can see with a Filter Plugin would be the feedback portion. As it is, running it, you get the feedback in the log about what was attempted, what was executed, etc...I could output all of that to the plugin log through normal channels if that would be okI'd just never thought of doing it through a plugin before On Sat, Jul 22, 2017 at 2:02 AM, Thomas Miskiewicz wrote: ** LJ, can we have your tool as a API Filter plugin? Thomas On 21. Jul 2017, at 23:29, LJ LongWing wrote: ** Harsh, Deleting from the DB will always be faster than deleting from the applications server because you are removing the overhead of the Remedy server, that being said however, I always do my deletes against the app server. I do this for many reasons, but data integrity is one of them. When you do your deletes through the app server, you get 'all' of the pieces that you are supposed to get (T, H, B, BNCN)for this reason, deleting though the app server is preferred, from my perspective at least. With this thought in mind, I have produced a tool that I have used personally for several years, and with the assistance of Jason Miller, moved more mainstream and increased performance from it by making it multi-threaded. http://remedylegacy.com/tools/delete-requests/ (http://remedylegacy.com/tools/delete-requests/) This tool uses an SQL query to identify the records that need to be removed, and then uses the api to do the actual removal. Because it's using the API, it'll make any workflow that fires on delete fire, which can cause you do have a cascade effect cleaning up parent/child/grandchild/etc relationships In general, I recommend not doing anything with the Remedy DB directly at the DB level, there are of course all sorts of people that do with no impact at all, or no noticeable impact, but in general, having done Remedy for as many years a I haveI believe the data should be inserted into, modified, and removed from the Remedy DB by the Remedy application server... On Fri, Jul 21, 2017 at 2:56 PM, Harsh wrote:** Hi All, Today i got into an argument where one ofmy colleague was deleting 57K records from custom form through Escalations. I asked him to better use a delete query on arsystem database. As it will delete the records faster then escalations. As per him both will take same amount of time. But i believe escalation will take more time as it has to make a call to DB everytime and somehow will add the processing time on the server. Please let me know your thoughts upon the same. Thanks, Harsh -- Thanks & regards “Harsh Chaudhary” "Impatience never commanded success" _ARSlist: "Where the Answers Are" and have been for 20 years__ARSlist: "Where the Answers Are" and have been for 20 years_ _ARSlist: "Where the Answers Are" and have been for 20 years__ARSlist: "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"
Re: Delete Through Escalation vs Delete through DB
LJ, I see no problem with the feedback channel. Input: delete this and that. Output: it worked / I tried this and that and this portion went wrong. Thomas > On 22. Jul 2017, at 13:47, LJ LongWing wrote: > > ** > Thomas, > Yes...it could be done as an API Filter PluginI've been thinking about > that since you askedthe only problem I can see with a Filter Plugin would > be the feedback portion. As it is, running it, you get the feedback in the > log about what was attempted, what was executed, etc...I could output all of > that to the plugin log through normal channels if that would be okI'd > just never thought of doing it through a plugin before > >> On Sat, Jul 22, 2017 at 2:02 AM, Thomas Miskiewicz >> wrote: >> ** >> LJ, >> >> can we have your tool as a API Filter plugin? >> >> >> Thomas >> >>> On 21. Jul 2017, at 23:29, LJ LongWing wrote: >>> >>> ** >>> Harsh, >>> Deleting from the DB will always be faster than deleting from the >>> applications server because you are removing the overhead of the Remedy >>> server, that being said however, I always do my deletes against the app >>> server. I do this for many reasons, but data integrity is one of them. >>> When you do your deletes through the app server, you get 'all' of the >>> pieces that you are supposed to get (T, H, B, BNCN)for this reason, >>> deleting though the app server is preferred, from my perspective at least. >>> With this thought in mind, I have produced a tool that I have used >>> personally for several years, and with the assistance of Jason Miller, >>> moved more mainstream and increased performance from it by making it >>> multi-threaded. >>> >>> http://remedylegacy.com/tools/delete-requests/ >>> >>> This tool uses an SQL query to identify the records that need to be >>> removed, and then uses the api to do the actual removal. Because it's >>> using the API, it'll make any workflow that fires on delete fire, which can >>> cause you do have a cascade effect cleaning up parent/child/grandchild/etc >>> relationships >>> >>> In general, I recommend not doing anything with the Remedy DB directly at >>> the DB level, there are of course all sorts of people that do with no >>> impact at all, or no noticeable impact, but in general, having done Remedy >>> for as many years a I haveI believe the data should be inserted into, >>> modified, and removed from the Remedy DB by the Remedy application server... >>> >>>> On Fri, Jul 21, 2017 at 2:56 PM, Harsh wrote: >>>> ** Hi All, >>>> >>>> Today i got into an argument where one of >>>> my colleague was deleting 57K records from custom form through >>>> Escalations. I asked him to better use a delete query on arsystem >>>> database. As it will delete the records faster then escalations. >>>> >>>> As per him both will take same amount of time. But i believe escalation >>>> will take more time as it has to make a call to DB everytime and somehow >>>> will add the processing time on the server. >>>> >>>> Please let me know your thoughts upon the same. >>>> >>>> Thanks, >>>> Harsh >>>> >>>> >>>> -- >>>> Thanks & regards >>>> “Harsh Chaudhary” >>>> "Impatience never commanded success" >>>> >>>> >>>> _ARSlist: "Where the Answers Are" and have been for 20 years_ >>> >>> _ARSlist: "Where the Answers Are" and have been for 20 years_ >> >> _ARSlist: "Where the Answers Are" and have been for 20 years_ > > _ARSlist: "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"
Re: Delete Through Escalation vs Delete through DB
Meta-Update has had a delete capability for 17 years. It also comes with Meta-Delete, a stand alone delete tool. Caution. Whilst the delete workflow has gotten better through the releases, it still leaves dangling records. Always delete lower level records first for performance. The delete workflow is basically a delete signal push fields to children records. Ben Chernyswww.softwaretoolhouse.com Sent from my Samsung Galaxy smartphone. Original message From: LJ LongWing Date: 22/07/2017 06:47 (GMT-07:00) To: arslist@ARSLIST.ORG Subject: Re: Delete Through Escalation vs Delete through DB ** Thomas,Yes...it could be done as an API Filter PluginI've been thinking about that since you askedthe only problem I can see with a Filter Plugin would be the feedback portion. As it is, running it, you get the feedback in the log about what was attempted, what was executed, etc...I could output all of that to the plugin log through normal channels if that would be okI'd just never thought of doing it through a plugin before On Sat, Jul 22, 2017 at 2:02 AM, Thomas Miskiewicz wrote: ** LJ, can we have your tool as a API Filter plugin? Thomas On 21. Jul 2017, at 23:29, LJ LongWing wrote: ** Harsh,Deleting from the DB will always be faster than deleting from the applications server because you are removing the overhead of the Remedy server, that being said however, I always do my deletes against the app server. I do this for many reasons, but data integrity is one of them. When you do your deletes through the app server, you get 'all' of the pieces that you are supposed to get (T, H, B, BNCN)for this reason, deleting though the app server is preferred, from my perspective at least. With this thought in mind, I have produced a tool that I have used personally for several years, and with the assistance of Jason Miller, moved more mainstream and increased performance from it by making it multi-threaded. http://remedylegacy.com/tools/delete-requests/ This tool uses an SQL query to identify the records that need to be removed, and then uses the api to do the actual removal. Because it's using the API, it'll make any workflow that fires on delete fire, which can cause you do have a cascade effect cleaning up parent/child/grandchild/etc relationships In general, I recommend not doing anything with the Remedy DB directly at the DB level, there are of course all sorts of people that do with no impact at all, or no noticeable impact, but in general, having done Remedy for as many years a I haveI believe the data should be inserted into, modified, and removed from the Remedy DB by the Remedy application server... On Fri, Jul 21, 2017 at 2:56 PM, Harsh wrote: ** Hi All, Today i got into an argument where one ofmy colleague was deleting 57K records from custom form through Escalations. I asked him to better use a delete query on arsystem database. As it will delete the records faster then escalations. As per him both will take same amount of time. But i believe escalation will take more time as it has to make a call to DB everytime and somehow will add the processing time on the server. Please let me know your thoughts upon the same. Thanks,Harsh -- Thanks & regards “Harsh Chaudhary” "Impatience never commanded success" _ARSlist: "Where the Answers Are" and have been for 20 years_ _ARSlist: "Where the Answers Are" and have been for 20 years_ _ARSlist: "Where the Answers Are" and have been for 20 years_ _ARSlist: "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"
Re: Delete Through Escalation vs Delete through DB
Thomas, Yes...it could be done as an API Filter PluginI've been thinking about that since you askedthe only problem I can see with a Filter Plugin would be the feedback portion. As it is, running it, you get the feedback in the log about what was attempted, what was executed, etc...I could output all of that to the plugin log through normal channels if that would be okI'd just never thought of doing it through a plugin before On Sat, Jul 22, 2017 at 2:02 AM, Thomas Miskiewicz wrote: > ** > LJ, > > can we have your tool as a API Filter plugin? > > > Thomas > > On 21. Jul 2017, at 23:29, LJ LongWing wrote: > > ** > Harsh, > Deleting from the DB will always be faster than deleting from the > applications server because you are removing the overhead of the Remedy > server, that being said however, I always do my deletes against the app > server. I do this for many reasons, but data integrity is one of them. > When you do your deletes through the app server, you get 'all' of the > pieces that you are supposed to get (T, H, B, BNCN)for this reason, > deleting though the app server is preferred, from my perspective at least. > With this thought in mind, I have produced a tool that I have used > personally for several years, and with the assistance of Jason Miller, > moved more mainstream and increased performance from it by making it > multi-threaded. > > http://remedylegacy.com/tools/delete-requests/ > > This tool uses an SQL query to identify the records that need to be > removed, and then uses the api to do the actual removal. Because it's > using the API, it'll make any workflow that fires on delete fire, which can > cause you do have a cascade effect cleaning up parent/child/grandchild/etc > relationships > > In general, I recommend not doing anything with the Remedy DB directly at > the DB level, there are of course all sorts of people that do with no > impact at all, or no noticeable impact, but in general, having done Remedy > for as many years a I haveI believe the data should be inserted into, > modified, and removed from the Remedy DB by the Remedy application server... > > On Fri, Jul 21, 2017 at 2:56 PM, Harsh wrote: > >> ** Hi All, >> >> Today i got into an argument where one of >> my colleague was deleting 57K records from custom form through >> Escalations. I asked him to better use a delete query on arsystem database. >> As it will delete the records faster then escalations. >> >> As per him both will take same amount of time. But i believe escalation >> will take more time as it has to make a call to DB everytime and somehow >> will add the processing time on the server. >> >> Please let me know your thoughts upon the same. >> >> Thanks, >> Harsh >> >> >> -- >> *Thanks & regards* >> *“Harsh Chaudhary”* >> *"Impatience never commanded success**"* >> >> >> >> _ARSlist: "Where the Answers Are" and have been for 20 years_ > > > _ARSlist: "Where the Answers Are" and have been for 20 years_ > > _ARSlist: "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"
Re: Delete Through Escalation vs Delete through DB
Hi, just an additional idea: you could use the (by BMC unsupported) ardelete step for spoon written by Sebastian Schmidt: https://sourceforge.net/projects/arsoutputplugin/?source=navbar When you have PDI7 as stand alone you can download it from the Petaho Plugin Marketplace and it will be installed correctly for use. The "new" PDI 6 version that is shipped with ARS 9.1.3 does not have the Marketplace. my 2 cents Regards Rüdiger ** > Thomas Miskiewicz hat am 22. Juli 2017 um 10:02 > geschrieben: > > > LJ, > > can we have your tool as a API Filter plugin? > > > Thomas > > On 21. Jul 2017, at 23:29, LJ LongWing mailto:lj.longw...@gmail.com > wrote: > > > > > ** > > Harsh, > > Deleting from the DB will always be faster than deleting from the > > applications server because you are removing the overhead of the Remedy > > server, that being said however, I always do my deletes against the app > > server. I do this for many reasons, but data integrity is one of them. > > When you do your deletes through the app server, you get 'all' of the > > pieces that you are supposed to get (T, H, B, BNCN)for this reason, > > deleting though the app server is preferred, from my perspective at least. > > With this thought in mind, I have produced a tool that I have used > > personally for several years, and with the assistance of Jason Miller, > > moved more mainstream and increased performance from it by making it > > multi-threaded. > > > > http://remedylegacy.com/tools/delete-requests/ > > > > This tool uses an SQL query to identify the records that need to be > > removed, and then uses the api to do the actual removal. Because it's > > using the API, it'll make any workflow that fires on delete fire, which can > > cause you do have a cascade effect cleaning up parent/child/grandchild/etc > > relationships > > > > In general, I recommend not doing anything with the Remedy DB > > directly at the DB level, there are of course all sorts of people that do > > with no impact at all, or no noticeable impact, but in general, having done > > Remedy for as many years a I haveI believe the data should be inserted > > into, modified, and removed from the Remedy DB by the Remedy application > > server... > > > > On Fri, Jul 21, 2017 at 2:56 PM, Harsh > mailto:chaudhar...@gmail.com > wrote: > > > > > > > ** Hi All, > > > > > > Today i got into an argument where one of > > > my colleague was deleting 57K records from custom form > > > through Escalations. I asked him to better use a delete query on arsystem > > > database. As it will delete the records faster then escalations. > > > > > > As per him both will take same amount of time. But i believe > > > escalation will take more time as it has to make a call to DB everytime > > > and somehow will add the processing time on the server. > > > > > > Please let me know your thoughts upon the same. > > > > > > Thanks, > > > Harsh > > > > > > > > > -- > > > Thanks & regards > > > “Harsh Chaudhary” > > > "Impatience never commanded success" > > > > > > > > > > > > > > > > > > > > > > > _ARSlist: "Where the Answers Are" and have been for 20 years_ > > > > > > > > > > _ARSlist: "Where the Answers Are" and have been for 20 years_ > > > > > > _ARSlist: "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"
Re: Delete Through Escalation vs Delete through DB
LJ, can we have your tool as a API Filter plugin? Thomas > On 21. Jul 2017, at 23:29, LJ LongWing wrote: > > ** > Harsh, > Deleting from the DB will always be faster than deleting from the > applications server because you are removing the overhead of the Remedy > server, that being said however, I always do my deletes against the app > server. I do this for many reasons, but data integrity is one of them. When > you do your deletes through the app server, you get 'all' of the pieces that > you are supposed to get (T, H, B, BNCN)for this reason, deleting though > the app server is preferred, from my perspective at least. With this thought > in mind, I have produced a tool that I have used personally for several > years, and with the assistance of Jason Miller, moved more mainstream and > increased performance from it by making it multi-threaded. > > http://remedylegacy.com/tools/delete-requests/ > > This tool uses an SQL query to identify the records that need to be removed, > and then uses the api to do the actual removal. Because it's using the API, > it'll make any workflow that fires on delete fire, which can cause you do > have a cascade effect cleaning up parent/child/grandchild/etc > relationships > > In general, I recommend not doing anything with the Remedy DB directly at the > DB level, there are of course all sorts of people that do with no impact at > all, or no noticeable impact, but in general, having done Remedy for as many > years a I haveI believe the data should be inserted into, modified, and > removed from the Remedy DB by the Remedy application server... > >> On Fri, Jul 21, 2017 at 2:56 PM, Harsh wrote: >> ** Hi All, >> >> Today i got into an argument where one of >> my colleague was deleting 57K records from custom form through Escalations. >> I asked him to better use a delete query on arsystem database. As it will >> delete the records faster then escalations. >> >> As per him both will take same amount of time. But i believe escalation will >> take more time as it has to make a call to DB everytime and somehow will add >> the processing time on the server. >> >> Please let me know your thoughts upon the same. >> >> Thanks, >> Harsh >> >> >> -- >> Thanks & regards >> “Harsh Chaudhary” >> "Impatience never commanded success" >> >> >> _ARSlist: "Where the Answers Are" and have been for 20 years_ > > _ARSlist: "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"
Re: Delete Through Escalation vs Delete through DB
Direct deletion through the db will always be faster than an Escalation in Remedy, but the main question I would have is if you need it to trigger additional workflow to push into a secondary form to update data upstream or downstream? If so an Escalation is the way I would go. Sent from my iPhone > On Jul 21, 2017, at 3:56 PM, Harsh wrote: > > ** Hi All, > > Today i got into an argument where one of > my colleague was deleting 57K records from custom form through Escalations. I > asked him to better use a delete query on arsystem database. As it will > delete the records faster then escalations. > > As per him both will take same amount of time. But i believe escalation will > take more time as it has to make a call to DB everytime and somehow will add > the processing time on the server. > > Please let me know your thoughts upon the same. > > Thanks, > Harsh > > > -- > Thanks & regards > “Harsh Chaudhary” > "Impatience never commanded success" > > > _ARSlist: "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"
Re: Delete Through Escalation vs Delete through DB
Harsh, Deleting from the DB will always be faster than deleting from the applications server because you are removing the overhead of the Remedy server, that being said however, I always do my deletes against the app server. I do this for many reasons, but data integrity is one of them. When you do your deletes through the app server, you get 'all' of the pieces that you are supposed to get (T, H, B, BNCN)for this reason, deleting though the app server is preferred, from my perspective at least. With this thought in mind, I have produced a tool that I have used personally for several years, and with the assistance of Jason Miller, moved more mainstream and increased performance from it by making it multi-threaded. http://remedylegacy.com/tools/delete-requests/ This tool uses an SQL query to identify the records that need to be removed, and then uses the api to do the actual removal. Because it's using the API, it'll make any workflow that fires on delete fire, which can cause you do have a cascade effect cleaning up parent/child/grandchild/etc relationships In general, I recommend not doing anything with the Remedy DB directly at the DB level, there are of course all sorts of people that do with no impact at all, or no noticeable impact, but in general, having done Remedy for as many years a I haveI believe the data should be inserted into, modified, and removed from the Remedy DB by the Remedy application server... On Fri, Jul 21, 2017 at 2:56 PM, Harsh wrote: > ** Hi All, > > Today i got into an argument where one of > my colleague was deleting 57K records from custom form through > Escalations. I asked him to better use a delete query on arsystem database. > As it will delete the records faster then escalations. > > As per him both will take same amount of time. But i believe escalation > will take more time as it has to make a call to DB everytime and somehow > will add the processing time on the server. > > Please let me know your thoughts upon the same. > > Thanks, > Harsh > > > -- > *Thanks & regards* > *“Harsh Chaudhary”* > *"Impatience never commanded success**"* > > > > _ARSlist: "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"
Re: Delete Through Escalation vs Delete through DB
Anything at the DB layer will be faster than an escalation which relies on the app stack. As long as you are comfortable that there is no workflow that runs on delete that would otherwise compromise your data integrity Sent from my iPhone > On Jul 21, 2017, at 4:56 PM, Harsh wrote: > > ** Hi All, > > Today i got into an argument where one of > my colleague was deleting 57K records from custom form through Escalations. I > asked him to better use a delete query on arsystem database. As it will > delete the records faster then escalations. > > As per him both will take same amount of time. But i believe escalation will > take more time as it has to make a call to DB everytime and somehow will add > the processing time on the server. > > Please let me know your thoughts upon the same. > > Thanks, > Harsh > > > -- > Thanks & regards > “Harsh Chaudhary” > "Impatience never commanded success" > > > _ARSlist: "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"
Delete Through Escalation vs Delete through DB
Hi All, Today i got into an argument where one of my colleague was deleting 57K records from custom form through Escalations. I asked him to better use a delete query on arsystem database. As it will delete the records faster then escalations. As per him both will take same amount of time. But i believe escalation will take more time as it has to make a call to DB everytime and somehow will add the processing time on the server. Please let me know your thoughts upon the same. Thanks, Harsh -- *Thanks & regards* *“Harsh Chaudhary”* *"Impatience never commanded success**"* ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
Role of signature escalation in change management process
Hello Experts, Can you please help me to understand what us the role of signature escalation in change management ? Use follow path to see understand the question ( Application --- quick links approval administration console process you can see the processes name like change level CI - close down or business or implementation etc... ) Regards, Gajanand ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
Re: remedy 9.0.1 - Unable to clear all records using escalation
No errors in escalation or arerror logs. It just stops after processing few records. Is there any other log file I should check for errors? Thanks! Kaur ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
Re: remedy 9.0.1 - Unable to clear all records using escalation
Max entries returned by getlist is set to 0. -Kaur ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
Re: remedy 9.0.1 - Unable to clear all records using escalation
Is the escalation hitting an error and stopping processing? If so it could be defect SW00500252 - you'll need to raise a support case to confirm and see if there's a hotfix available. Mark -Original Message- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of SUBSCRIBE arslist Anonymous Sent: 15 December 2015 16:49 To: arslist@ARSLIST.ORG Subject: remedy 9.0.1 - Unable to clear all records using escalation Hello! I am having issues clear records from a form using escalation. The form has 15k+ records. Every time I run the esc, it clears 7000 records and then stops. Nothing in the escalation logs. Then I run this again and this time it clears only only 3000. I tried changing the esc pool and increasing the thread. What could be the possible reason? Any idea. This is working fine on v7.6.04. Thanks! ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years" BMC Software Limited Registered Office: Building E2, Eskdale Road, Winnersh, Wokingham, Berkshire, United Kingdom, RG41 5TS Registered in England No. 1927903 The content of this email is confidential. If you are not the addressee, you may not distribute, copy or disclose any part of it. If you receive this message in error, please delete this from your system and notify the sender immediately. ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
Re: remedy 9.0.1 - Unable to clear all records using escalation
Does the server have a Max number of Items returned by GetList value set (in the Administration Console)? -Original Message- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of SUBSCRIBE arslist Anonymous Sent: Tuesday, December 15, 2015 10:49 AM To: arslist@ARSLIST.ORG Subject: remedy 9.0.1 - Unable to clear all records using escalation Hello! I am having issues clear records from a form using escalation. The form has 15k+ records. Every time I run the esc, it clears 7000 records and then stops. Nothing in the escalation logs. Then I run this again and this time it clears only only 3000. I tried changing the esc pool and increasing the thread. What could be the possible reason? Any idea. This is working fine on v7.6.04. Thanks! ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
remedy 9.0.1 - Unable to clear all records using escalation
Hello! I am having issues clear records from a form using escalation. The form has 15k+ records. Every time I run the esc, it clears 7000 records and then stops. Nothing in the escalation logs. Then I run this again and this time it clears only only 3000. I tried changing the esc pool and increasing the thread. What could be the possible reason? Any idea. This is working fine on v7.6.04. Thanks! ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
Re: Is it possible to trigger a BIRT report using an escalation?
Yea...I'm not entirely sure how one would schedule an individual report on specific tickets several times a day so that each report was sent on an individual ticket, instead of a list of them...maybe looking into Jarl's suggestion would be wise :) On Mon, Mar 2, 2015 at 7:34 AM, Hardy, Patrick wrote: > ** > > Looked at this initially though the requirement is an individual email for > each ticket that meets the criteria, not sure that can be met with the > schedule. Wouldn’t it evaluate each time and send the output for all > matching tickets in a single distribution? > > > > *From:* Action Request System discussion list(ARSList) [mailto: > arslist@ARSLIST.ORG] *On Behalf Of *LJ LongWing > *Sent:* Monday, March 02, 2015 8:15 AM > *To:* arslist@ARSLIST.ORG > *Subject:* Re: Is it possible to trigger a BIRT report using an > escalation? > > > > ** > > Patrick, > > In 8.1 there is certainly the ability to schedule reports, you can find > the buttons in the top right corner of the report console if I remember > correctly. > > > > On Mon, Mar 2, 2015 at 6:15 AM, Hardy, Patrick > wrote: > > ** > > Happy Monday! > > > > I’m looking to generate a custom BIRT report on specific incidents. Would > like the report to run individually for each incident and email the report > several times throughout the day. Can a BIRT report be triggered from an > escalation? > > > > ARS/ITSM: 8.1.00 > > OS: Windows > > DB: SQL > -- > > This email and any files transmitted with it are confidential and intended > solely for the use of the addressee. If you are not the intended addressee, > then you have received this email in error and any use, dissemination, > forwarding, printing, or copying of this email is strictly prohibited. > Please notify us immediately of your unintended receipt by reply and then > delete this email and your reply. Tyson Foods, Inc. and its subsidiaries > and affiliates will not be held liable to any person resulting from the > unintended or unauthorized use of any information contained in this email > or as a result of any additions or deletions of information originally > contained in this email. > > _ARSlist: "Where the Answers Are" and have been for 20 years_ > > > > _ARSlist: "Where the Answers Are" and have been for 20 years_ > -- > This email and any files transmitted with it are confidential and intended > solely for the use of the addressee. If you are not the intended addressee, > then you have received this email in error and any use, dissemination, > forwarding, printing, or copying of this email is strictly prohibited. > Please notify us immediately of your unintended receipt by reply and then > delete this email and your reply. Tyson Foods, Inc. and its subsidiaries > and affiliates will not be held liable to any person resulting from the > unintended or unauthorized use of any information contained in this email > or as a result of any additions or deletions of information originally > contained in this email. > _ARSlist: "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"
Re: Is it possible to trigger a BIRT report using an escalation?
Looked at this initially though the requirement is an individual email for each ticket that meets the criteria, not sure that can be met with the schedule. Wouldn’t it evaluate each time and send the output for all matching tickets in a single distribution? From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of LJ LongWing Sent: Monday, March 02, 2015 8:15 AM To: arslist@ARSLIST.ORG Subject: Re: Is it possible to trigger a BIRT report using an escalation? ** Patrick, In 8.1 there is certainly the ability to schedule reports, you can find the buttons in the top right corner of the report console if I remember correctly. On Mon, Mar 2, 2015 at 6:15 AM, Hardy, Patrick mailto:patrick.ha...@tyson.com>> wrote: ** Happy Monday! I’m looking to generate a custom BIRT report on specific incidents. Would like the report to run individually for each incident and email the report several times throughout the day. Can a BIRT report be triggered from an escalation? ARS/ITSM: 8.1.00 OS: Windows DB: SQL This email and any files transmitted with it are confidential and intended solely for the use of the addressee. If you are not the intended addressee, then you have received this email in error and any use, dissemination, forwarding, printing, or copying of this email is strictly prohibited. Please notify us immediately of your unintended receipt by reply and then delete this email and your reply. Tyson Foods, Inc. and its subsidiaries and affiliates will not be held liable to any person resulting from the unintended or unauthorized use of any information contained in this email or as a result of any additions or deletions of information originally contained in this email. _ARSlist: "Where the Answers Are" and have been for 20 years_ _ARSlist: "Where the Answers Are" and have been for 20 years_ -- This email and any files transmitted with it are confidential and intended solely for the use of the addressee. If you are not the intended addressee, then you have received this email in error and any use, dissemination, forwarding, printing, or copying of this email is strictly prohibited. Please notify us immediately of your unintended receipt by reply and then delete this email and your reply. Tyson Foods, Inc. and its subsidiaries and affiliates will not be held liable to any person resulting from the unintended or unauthorized use of any information contained in this email or as a result of any additions or deletions of information originally contained in this email. ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
Re: Is it possible to trigger a BIRT report using an escalation?
Taking a look at this now, was really hoping to have the output as html in the email body will give it a spin. From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Jarl Grøneng Sent: Monday, March 02, 2015 7:27 AM To: arslist@ARSLIST.ORG Subject: Re: Is it possible to trigger a BIRT report using an escalation? ** Hi Take look at the form AR System Publish Report. You can submit into this form, and the result is an attached report. -- J 2015-03-02 14:15 GMT+01:00 Hardy, Patrick mailto:patrick.ha...@tyson.com>>: ** Happy Monday! I’m looking to generate a custom BIRT report on specific incidents. Would like the report to run individually for each incident and email the report several times throughout the day. Can a BIRT report be triggered from an escalation? ARS/ITSM: 8.1.00 OS: Windows DB: SQL This email and any files transmitted with it are confidential and intended solely for the use of the addressee. If you are not the intended addressee, then you have received this email in error and any use, dissemination, forwarding, printing, or copying of this email is strictly prohibited. Please notify us immediately of your unintended receipt by reply and then delete this email and your reply. Tyson Foods, Inc. and its subsidiaries and affiliates will not be held liable to any person resulting from the unintended or unauthorized use of any information contained in this email or as a result of any additions or deletions of information originally contained in this email. _ARSlist: "Where the Answers Are" and have been for 20 years_ _ARSlist: "Where the Answers Are" and have been for 20 years_ -- This email and any files transmitted with it are confidential and intended solely for the use of the addressee. If you are not the intended addressee, then you have received this email in error and any use, dissemination, forwarding, printing, or copying of this email is strictly prohibited. Please notify us immediately of your unintended receipt by reply and then delete this email and your reply. Tyson Foods, Inc. and its subsidiaries and affiliates will not be held liable to any person resulting from the unintended or unauthorized use of any information contained in this email or as a result of any additions or deletions of information originally contained in this email. ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
Re: Is it possible to trigger a BIRT report using an escalation?
Patrick, In 8.1 there is certainly the ability to schedule reports, you can find the buttons in the top right corner of the report console if I remember correctly. On Mon, Mar 2, 2015 at 6:15 AM, Hardy, Patrick wrote: > ** > > Happy Monday! > > > > I’m looking to generate a custom BIRT report on specific incidents. Would > like the report to run individually for each incident and email the report > several times throughout the day. Can a BIRT report be triggered from an > escalation? > > > > ARS/ITSM: 8.1.00 > > OS: Windows > > DB: SQL > -- > This email and any files transmitted with it are confidential and intended > solely for the use of the addressee. If you are not the intended addressee, > then you have received this email in error and any use, dissemination, > forwarding, printing, or copying of this email is strictly prohibited. > Please notify us immediately of your unintended receipt by reply and then > delete this email and your reply. Tyson Foods, Inc. and its subsidiaries > and affiliates will not be held liable to any person resulting from the > unintended or unauthorized use of any information contained in this email > or as a result of any additions or deletions of information originally > contained in this email. > _ARSlist: "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"
Re: Is it possible to trigger a BIRT report using an escalation?
Hi Take look at the form AR System Publish Report. You can submit into this form, and the result is an attached report. -- J 2015-03-02 14:15 GMT+01:00 Hardy, Patrick : > ** > > Happy Monday! > > > > I’m looking to generate a custom BIRT report on specific incidents. Would > like the report to run individually for each incident and email the report > several times throughout the day. Can a BIRT report be triggered from an > escalation? > > > > ARS/ITSM: 8.1.00 > > OS: Windows > > DB: SQL > -- > This email and any files transmitted with it are confidential and intended > solely for the use of the addressee. If you are not the intended addressee, > then you have received this email in error and any use, dissemination, > forwarding, printing, or copying of this email is strictly prohibited. > Please notify us immediately of your unintended receipt by reply and then > delete this email and your reply. Tyson Foods, Inc. and its subsidiaries > and affiliates will not be held liable to any person resulting from the > unintended or unauthorized use of any information contained in this email > or as a result of any additions or deletions of information originally > contained in this email. > _ARSlist: "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"
Is it possible to trigger a BIRT report using an escalation?
Happy Monday! I'm looking to generate a custom BIRT report on specific incidents. Would like the report to run individually for each incident and email the report several times throughout the day. Can a BIRT report be triggered from an escalation? ARS/ITSM: 8.1.00 OS: Windows DB: SQL -- This email and any files transmitted with it are confidential and intended solely for the use of the addressee. If you are not the intended addressee, then you have received this email in error and any use, dissemination, forwarding, printing, or copying of this email is strictly prohibited. Please notify us immediately of your unintended receipt by reply and then delete this email and your reply. Tyson Foods, Inc. and its subsidiaries and affiliates will not be held liable to any person resulting from the unintended or unauthorized use of any information contained in this email or as a result of any additions or deletions of information originally contained in this email. ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
Re: Escalation does not seem to complete its run over all the records..
I found the problem. Its not the MAX Filters. And yes I knew that max filters is a transaction based setting and not for the entire escalation. But because it was stopping only after processing a certain number of records I was wondering if that had anything to do with it. The reason it wasn't processing was a violation of a unique index on City and Zip/Code. The data we are feeding from, doesn't have a very clean and organized postal information. So as a result some of the data there has Country, City and Zip Code but missing state. Others have state for what should have been the same record. As a result it sees data like India, HARYANA, Gurgaon, 122002 and India, '', Gurgaon, 122002 on the load form as two separate records that pass the duplicate test from the defined out of the box workflow, but when the second record was being set with z1D Action of VALIDATELOAD and DL_Status of Validated, it failed the rest of the transaction as the system encountered a violation of a unique index. I think it's a workflow bug in the load form that should have been checking for violation of that unique index, but it does not. Since it's a BMC out of the box workflow, I'll raise a ticket with them. Cheers Joe _ From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Charlie Lotridge Sent: Wednesday, September 24, 2014 11:28 AM To: arslist@ARSLIST.ORG Subject: Re: Escalation does not seem to complete its run over all the records.. ** First, and FYI, the filter counter that's used by the system to determine if a transaction exceeds the filtering limit set for the system is reset for every record process during an escalation. It is NOT cumulative across the entire "run" of the escalation. So unless one of the records being processed exceeds your 500K limit, your correct that it can't be the filter limit. I don't know anything about the specific forms or data you're dealing with here, but is it possible that those 209 records only come to meet the inclusion condition after the escalation begins its operation? Just like many other things in the AR system, an escalation performs its query when it first wakes up, and only operates on the records it finds with that initial query. If any records subsequently come to meet the condition they won't be processed (until the next run of the escalation). Hope this helps. -charlie On Wed, Sep 24, 2014 at 7:34 AM, Joe D'Souza wrote: ** I have a simple escalation that triggers on the form CTM:LoadPostalCodes with a condition 'DL_Status' = "Unvalidated" During an initial run if there was no data in CTM:LoadPostalCodes, all records meet that condition. The escalation sets two fields in that form, z1D Action to "VALIDATELOAD" and DL_Status to "Validated" This triggers a bunch of out of the box data load filters, designed to validate and load the data in this form to the CTM:Postal Codes form. It works fine on almost all the records, except for 209 records in the end that do not get modified despite the fact they meet the condition on the Escalation. I have looked through the data in these 209 records, and nothing jumps up at me why this might be happening. The Error Flag is not set and the Last Modified Date does not change indicating that the Escalation did not even attempt to modify these records. I have a slight suspicion on max number of filters in an operation but somehow I doubt with just a little over 4000K records in that form to process, I would run over 50 filters as I doubt that there are over 100 filters for each record even if it were promoted. Also if max filter limit was the case, the system should have handled the unprocessed records of the first run on the second run of the escalation, but that does not happen either. Any alternate theories as to what may be happening? I have not yet activated any logs but will later if I can't determine what is causing this behavior just by comparing the data with the workflow. Joe _ARSlist: "Where the Answers Are" and have been for 20 years_ _ARSlist: "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"
Re: Escalation does not seem to complete its run over all the records..
First, and FYI, the filter counter that's used by the system to determine if a transaction exceeds the filtering limit set for the system is reset for every record process during an escalation. It is NOT cumulative across the entire "run" of the escalation. So unless one of the records being processed exceeds your 500K limit, your correct that it can't be the filter limit. I don't know anything about the specific forms or data you're dealing with here, but is it possible that those 209 records only come to meet the inclusion condition *after *the escalation begins its operation? Just like many other things in the AR system, an escalation performs its query when it first wakes up, and only operates on the records it finds with that initial query. If any records subsequently come to meet the condition they won't be processed (until the next run of the escalation). Hope this helps. -charlie On Wed, Sep 24, 2014 at 7:34 AM, Joe D'Souza wrote: > ** > > I have a simple escalation that triggers on the form CTM:LoadPostalCodes > with a condition > > > > 'DL_Status' = "Unvalidated" > > > > During an initial run if there was no data in CTM:LoadPostalCodes, all > records meet that condition. > > > > The escalation sets two fields in that form, z1D Action to "VALIDATELOAD" > and DL_Status to "Validated" > > > > This triggers a bunch of out of the box data load filters, designed to > validate and load the data in this form to the CTM:Postal Codes form. > > > > It works fine on almost all the records, except for 209 records in the end > that do not get modified despite the fact they meet the condition on the > Escalation. > > > > I have looked through the data in these 209 records, and nothing jumps up > at me why this might be happening. The Error Flag is not set and the Last > Modified Date does not change indicating that the Escalation did not even > attempt to modify these records. > > > > I have a slight suspicion on max number of filters in an operation but > somehow I doubt with just a little over 4000K records in that form to > process, I would run over 50 filters as I doubt that there are over 100 > filters for each record even if it were promoted. Also if max filter limit > was the case, the system should have handled the unprocessed records of the > first run on the second run of the escalation, but that does not happen > either. > > > > Any alternate theories as to what may be happening? > > > > I have not yet activated any logs but will later if I can’t determine what > is causing this behavior just by comparing the data with the workflow. > > > > Joe > _ARSlist: "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"
Escalation does not seem to complete its run over all the records..
I have a simple escalation that triggers on the form CTM:LoadPostalCodes with a condition 'DL_Status' = "Unvalidated" During an initial run if there was no data in CTM:LoadPostalCodes, all records meet that condition. The escalation sets two fields in that form, z1D Action to "VALIDATELOAD" and DL_Status to "Validated" This triggers a bunch of out of the box data load filters, designed to validate and load the data in this form to the CTM:Postal Codes form. It works fine on almost all the records, except for 209 records in the end that do not get modified despite the fact they meet the condition on the Escalation. I have looked through the data in these 209 records, and nothing jumps up at me why this might be happening. The Error Flag is not set and the Last Modified Date does not change indicating that the Escalation did not even attempt to modify these records. I have a slight suspicion on max number of filters in an operation but somehow I doubt with just a little over 4000K records in that form to process, I would run over 50 filters as I doubt that there are over 100 filters for each record even if it were promoted. Also if max filter limit was the case, the system should have handled the unprocessed records of the first run on the second run of the escalation, but that does not happen either. Any alternate theories as to what may be happening? I have not yet activated any logs but will later if I can't determine what is causing this behavior just by comparing the data with the workflow. Joe ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
Re: Escalation qualification : DSO
I just want to chime in that rrrChive is my favorite utility! THANKS MISI I typically use bat files to run multiple CFG files sequentially. I used to run several at once, but the DB runs faster single threaded. Instead of ‘logfile = rrchivetest’, try AUTO. I had asked Misi to add this feature so that each CFG file produces a log file with the same name. THANKS MISI The naming convention is important to coordinate the CFG, LOGs and BAT files. For example, where the client id is “clnt”: clntgo.bat accepts 2 parameters: CGF-Number and the date/time (be sure the format can be used in a filename.) The command “clntgo 26 140910” runs rrrChive with “clnt_23.cfg” & produces “clnt_23_140910.log” I would also use an ARS escalation to call the bat files, at least to ensure that ARS is up and running. The rrrChive error usually indicates a problem in the source server. Especially with older AR Servers that have been upgraded multiple times, data errors in ‘old’ records are ‘identified’ by rrrChive. If you look at the SQL tables for ‘sourceserver, Form1, entry=1522516’ you may find incomplete pieces of the AR record. It will also produce errors for Selection Field values that are no longer valid, but were when the record was created. The same goes for other field properties like length and min/max values. The first few runs (usually for SYNCTOTARGET) produce errors that require data clean-up in the source server. Once these are fixed rrrChive runs smoothly every time. HTH and THANKS MISI! Joel Joel Senderjdsen...@earthlink.net310.829.5552 From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of LJ LongWing Sent: Wednesday, September 10, 2014 8:42 AM To: arslist@ARSLIST.ORG Subject: Re: Escalation qualification : DSO ** I know that Misi reads and replies to the list, but that is really a support question for RRRChive, and should be asked of the Developer directlyMisi is usually very good at responding on the list, but you may want to go to his website and ask directly there via the support link. On Wed, Sep 10, 2014 at 9:29 AM, MalviyaSaurabh wrote: I have managed to right a batch file which I have scheduled to run every 3 hours in task scheduler in windows VM. And it is working fine. But for few records I could see Deleted source=sourceserver, Form1, entry=1522516 rrrchive: 2014-09-10 12:07:02, type=ARS, level=ERROR, file=rrrchive.cpp, line=1116 ARDeleteEntry(server=sourceserver, form=Form1, entry=1522516) API CALL SEVERITY: AR_RETURN_ERROR, failure, status contains details ARStatusList: contains 1 messages Number: ARERR 302 Message: Entry does not exist in database Append: This might have happened because I closed the command prompt by mistake when I was testing the batch file on task scheduler. My question is if we can ensure in rrrchive config file that during MOVE. deletion from source should not happen until insertion in target form is not completed. I have already shared ny configuration. Urgent response is really appreciated. Regards, Saurabh -- View this message in context: http://ars-action-request-system.1.n7.nabble.com/Escalation-qualification-DSO-tp118847p118898.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" _ARSlist: "Where the Answers Are" and have been for 20 years_ --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
Re: Escalation qualification : DSO
I know that Misi reads and replies to the list, but that is really a support question for RRRChive, and should be asked of the Developer directlyMisi is usually very good at responding on the list, but you may want to go to his website and ask directly there via the support link. On Wed, Sep 10, 2014 at 9:29 AM, MalviyaSaurabh wrote: > I have managed to right a batch file which I have scheduled to run every 3 > hours in task scheduler in windows VM. And it is working fine. But for few > records I could see > > Deleted source=sourceserver, Form1, entry=1522516 > rrrchive: 2014-09-10 12:07:02, type=ARS, level=ERROR, file=rrrchive.cpp, > line=1116 > ARDeleteEntry(server=sourceserver, form=Form1, entry=1522516) > API CALL SEVERITY: AR_RETURN_ERROR, failure, status contains details > ARStatusList: contains 1 messages > Number: ARERR 302 > Message: Entry does not exist in database > Append: > > This might have happened because I closed the command prompt by mistake > when > I was testing the batch file on task scheduler. > > My question is if we can ensure in rrrchive config file that during MOVE. > deletion from source should not happen until insertion in target form is > not > completed. I have already shared ny configuration. > Urgent response is really appreciated. > > Regards, > Saurabh > > > > > -- > View this message in context: > http://ars-action-request-system.1.n7.nabble.com/Escalation-qualification-DSO-tp118847p118898.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"
Re: Escalation qualification : DSO
I have managed to right a batch file which I have scheduled to run every 3 hours in task scheduler in windows VM. And it is working fine. But for few records I could see Deleted source=sourceserver, Form1, entry=1522516 rrrchive: 2014-09-10 12:07:02, type=ARS, level=ERROR, file=rrrchive.cpp, line=1116 ARDeleteEntry(server=sourceserver, form=Form1, entry=1522516) API CALL SEVERITY: AR_RETURN_ERROR, failure, status contains details ARStatusList: contains 1 messages Number: ARERR 302 Message: Entry does not exist in database Append: This might have happened because I closed the command prompt by mistake when I was testing the batch file on task scheduler. My question is if we can ensure in rrrchive config file that during MOVE. deletion from source should not happen until insertion in target form is not completed. I have already shared ny configuration. Urgent response is really appreciated. Regards, Saurabh -- View this message in context: http://ars-action-request-system.1.n7.nabble.com/Escalation-qualification-DSO-tp118847p118898.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"
Re: Escalation qualification : DSO
Thanks Ken and Doug for your valuable inputs. I will work on that. Currently I am planning to use rrrchive for this archival as its big urgent. I am in the process of testing it on my dev environment: I am manually able to run rrrchive tool on command prompt and getting records archived. My config file is as follows source_server = sourceserver source_user = username source_password = password source_form = Form1 target_server = sourceserver target_user = username target_password = password target_form = Form1_Archive qual= ( 'Ticket Closed Date' <= "2/28/2009 11:59:59 PM") AND ( 'Status' = "Closed") AND ( 'Ticket Closed Date' >= "1/1/2009 12:00:00 AM") transfertype= MOVE logfile = rrchivetest loglevel= INFO progressbar = YES logclearonrun = YES maxrecords = 500 multientrychunksize = 100 Running the command below on comand propmt gives me output in rrchivetest file in the same folder. C:\installer\rrrchive_win_dll\rrrchive testrrrchive.cfg Now if anyone could help me in scheduling this command on an windows server2012 VM every 3 hours that would be helpful. Detailed steps would really be helpful. Regards, Saurabh -- View this message in context: http://ars-action-request-system.1.n7.nabble.com/Escalation-qualification-DSO-tp118847p118890.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"
Re: Escalation qualification : DSO
Hi... Thought I would throw a similar idea into the mix: use a control table to hold one of the parameters in the query. You have form A with millions of rows (that's a lac, right?), and you want to archive the oldest of these. In another table, form B, create one row with a date field. Initially set that date to be the very oldest record's submit date. Join this form to your form A so that you can see the date field in form B and the submit date and request ID of form A. Call this form C. Create one escalation which runs against form C every 30 minutes and looks for records older than the date field. If there are any records, perform the DSO operation on the form A record. If there are NO records, use an else action in the escalation to add some number of seconds - say 14400 for 4 hours worth - to the date field in form B. Make sure you add some limit to the else action so that you don't start archiving more recent records that you want - 2009 or 2010 or whatever. You could also make a max date field in form B and use that as a limit. But when this is set up, the escalation runs every 30 minutes and DSO's at most 4 hours worth of tickets, then basically does nothing for about an hour except to change the criteria for the next run. Overall load on the system is modest because of the chunking, and the escalation gets out of the way to allow other processes to run. All of the other suggestions are quite useful - a separate escalation pool, more escalation threads, time restrictions on when the escalation runs, using indexed criteria, etc. You could also run the escalation more or less often, change the added seconds and so forth to get the balance right. Hope this helps... Doug (no, the other, other Doug) -- Doug Blair +1 224-558-5462 Sent from my iPad Air Auto-corrected typos, misspellings and non-sequiturs are gratefully attributed to Steve Jobs :-) > On Sep 9, 2014, at 8:54 AM, Ken Pritchard wrote: > > I have what I call a diagnostic form where I create a record for the form / > query I want to check the number of records on. An escalation runs > periodically to do the query needed and then I move the $LASTCOUNT$ keyword > into a field on that form. The count can then be emailed or acted on by > filters if it's over a threshold (another field on the diagnostic form). > > Just my way of doing it without needing additional software. > > -Original Message- > From: Action Request System discussion list(ARSList) > [mailto:arslist@ARSLIST.ORG] On Behalf Of William Rentfrow > Sent: Tuesday, September 9, 2014 8:28 AM > To: arslist@ARSLIST.ORG > Subject: Re: Escalation qualification : DSO > > I'm not sure what sort of problem you are having at the DB level, but have > you tried putting this escalation into its own escalation pool? > > I'd give that a try and change it to run every 24 hours instead of every 30 > minutes. > > -Original Message- > From: Action Request System discussion list(ARSList) > [mailto:arslist@ARSLIST.ORG] On Behalf Of MalviyaSaurabh > Sent: Tuesday, September 09, 2014 12:49 AM > To: arslist@ARSLIST.ORG > Subject: Re: Escalation qualification : DSO > > Thanks for all your reply. > One more clarification which I am seeking out is that my escalation runs on > every 30 mins, and I can see records coming into the DSO pending queue in > the DSO Pending form, I would want to know from where i can get to how many > records are qualified in each execution of this escalation. From my manual > analysis of Pending form, after an execution the number of records in DSO > Pending form reaches a maximum and then the records goes down to zero as it > gets services by DSO. > > Also if I have to get the same functionality via rrrchive tool (i.e. > automate restricted qualification to new 500 records in ( 'Ticket Closed > Date' <= "2/28/2009 11:59:59 PM") AND ( 'Status' = "Closed") AND ( 'Ticket > Closed Date' >= "1/1/2009 12:00:00 AM") qualification) what parameter I > would be using. > > > qual= ( 'Ticket Closed Date' <= "2/28/2009 11:59:59 PM") AND ( > 'Status' = "Closed") AND ( 'Ticket Closed Date' >= "1/1/2009 12:00:00 AM") > transfertype= MOVE > > Will using below help in my case or do I have to chose any other parameter. > Please help. > multientrychunksize = 500 > > > Regards, > Saurabh > > > > > > -- > View this message in context: > http://ars-action-request-system.1.n7.nabble.com/Escalation-qualification-DS > O-tp118847p118864.html > Sent from the ARS (Action Request System) mailing list archive at
Re: Escalation qualification : DSO
I have what I call a diagnostic form where I create a record for the form / query I want to check the number of records on. An escalation runs periodically to do the query needed and then I move the $LASTCOUNT$ keyword into a field on that form. The count can then be emailed or acted on by filters if it's over a threshold (another field on the diagnostic form). Just my way of doing it without needing additional software. -Original Message- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of William Rentfrow Sent: Tuesday, September 9, 2014 8:28 AM To: arslist@ARSLIST.ORG Subject: Re: Escalation qualification : DSO I'm not sure what sort of problem you are having at the DB level, but have you tried putting this escalation into its own escalation pool? I'd give that a try and change it to run every 24 hours instead of every 30 minutes. -Original Message- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of MalviyaSaurabh Sent: Tuesday, September 09, 2014 12:49 AM To: arslist@ARSLIST.ORG Subject: Re: Escalation qualification : DSO Thanks for all your reply. One more clarification which I am seeking out is that my escalation runs on every 30 mins, and I can see records coming into the DSO pending queue in the DSO Pending form, I would want to know from where i can get to how many records are qualified in each execution of this escalation. From my manual analysis of Pending form, after an execution the number of records in DSO Pending form reaches a maximum and then the records goes down to zero as it gets services by DSO. Also if I have to get the same functionality via rrrchive tool (i.e. automate restricted qualification to new 500 records in ( 'Ticket Closed Date' <= "2/28/2009 11:59:59 PM") AND ( 'Status' = "Closed") AND ( 'Ticket Closed Date' >= "1/1/2009 12:00:00 AM") qualification) what parameter I would be using. qual= ( 'Ticket Closed Date' <= "2/28/2009 11:59:59 PM") AND ( 'Status' = "Closed") AND ( 'Ticket Closed Date' >= "1/1/2009 12:00:00 AM") transfertype= MOVE Will using below help in my case or do I have to chose any other parameter. Please help. multientrychunksize = 500 Regards, Saurabh -- View this message in context: http://ars-action-request-system.1.n7.nabble.com/Escalation-qualification-DS O-tp118847p118864.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" - No virus found in this message. Checked by AVG - www.avg.com Version: 2014.0.4765 / Virus Database: 4015/8175 - Release Date: 09/08/14 ___ 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"
Re: Escalation qualification : DSO
Saurabh, I recently released a tool to analyze Escalation Runtimes http://remedylegacy.com/tools/escalation-runtime/ This tool will provide you the times that the escalation starts, ends, count of how many records it updated, optionally the request id's it updated, duration of the update, etc...check it out and see if it serves a purpose for you :) On Mon, Sep 8, 2014 at 11:49 PM, MalviyaSaurabh wrote: > Thanks for all your reply. > One more clarification which I am seeking out is that my escalation runs on > every 30 mins, and I can see records coming into the DSO pending queue in > the DSO Pending form, I would want to know from where i can get to how many > records are qualified in each execution of this escalation. From my manual > analysis of Pending form, after an execution the number of records in DSO > Pending form reaches a maximum and then the records goes down to zero as it > gets services by DSO. > > Also if I have to get the same functionality via rrrchive tool (i.e. > automate restricted qualification to new 500 records in ( 'Ticket Closed > Date' <= "2/28/2009 11:59:59 PM") AND ( 'Status' = "Closed") AND ( 'Ticket > Closed Date' >= "1/1/2009 12:00:00 AM") qualification) what parameter I > would be using. > > > qual= ( 'Ticket Closed Date' <= "2/28/2009 11:59:59 PM") AND ( > 'Status' = "Closed") AND ( 'Ticket Closed Date' >= "1/1/2009 12:00:00 AM") > transfertype= MOVE > > Will using below help in my case or do I have to chose any other parameter. > Please help. > multientrychunksize = 500 > > > Regards, > Saurabh > > > > > > -- > View this message in context: > http://ars-action-request-system.1.n7.nabble.com/Escalation-qualification-DSO-tp118847p118864.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"
Re: Escalation qualification : DSO
I'm not sure what sort of problem you are having at the DB level, but have you tried putting this escalation into its own escalation pool? I'd give that a try and change it to run every 24 hours instead of every 30 minutes. -Original Message- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of MalviyaSaurabh Sent: Tuesday, September 09, 2014 12:49 AM To: arslist@ARSLIST.ORG Subject: Re: Escalation qualification : DSO Thanks for all your reply. One more clarification which I am seeking out is that my escalation runs on every 30 mins, and I can see records coming into the DSO pending queue in the DSO Pending form, I would want to know from where i can get to how many records are qualified in each execution of this escalation. From my manual analysis of Pending form, after an execution the number of records in DSO Pending form reaches a maximum and then the records goes down to zero as it gets services by DSO. Also if I have to get the same functionality via rrrchive tool (i.e. automate restricted qualification to new 500 records in ( 'Ticket Closed Date' <= "2/28/2009 11:59:59 PM") AND ( 'Status' = "Closed") AND ( 'Ticket Closed Date' >= "1/1/2009 12:00:00 AM") qualification) what parameter I would be using. qual= ( 'Ticket Closed Date' <= "2/28/2009 11:59:59 PM") AND ( 'Status' = "Closed") AND ( 'Ticket Closed Date' >= "1/1/2009 12:00:00 AM") transfertype= MOVE Will using below help in my case or do I have to chose any other parameter. Please help. multientrychunksize = 500 Regards, Saurabh -- View this message in context: http://ars-action-request-system.1.n7.nabble.com/Escalation-qualification-DSO-tp118847p118864.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" - No virus found in this message. Checked by AVG - www.avg.com Version: 2014.0.4765 / Virus Database: 4015/8175 - Release Date: 09/08/14 ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
Re: Escalation qualification : DSO
Thanks for all your reply. One more clarification which I am seeking out is that my escalation runs on every 30 mins, and I can see records coming into the DSO pending queue in the DSO Pending form, I would want to know from where i can get to how many records are qualified in each execution of this escalation. From my manual analysis of Pending form, after an execution the number of records in DSO Pending form reaches a maximum and then the records goes down to zero as it gets services by DSO. Also if I have to get the same functionality via rrrchive tool (i.e. automate restricted qualification to new 500 records in ( 'Ticket Closed Date' <= "2/28/2009 11:59:59 PM") AND ( 'Status' = "Closed") AND ( 'Ticket Closed Date' >= "1/1/2009 12:00:00 AM") qualification) what parameter I would be using. qual= ( 'Ticket Closed Date' <= "2/28/2009 11:59:59 PM") AND ( 'Status' = "Closed") AND ( 'Ticket Closed Date' >= "1/1/2009 12:00:00 AM") transfertype= MOVE Will using below help in my case or do I have to chose any other parameter. Please help. multientrychunksize = 500 Regards, Saurabh -- View this message in context: http://ars-action-request-system.1.n7.nabble.com/Escalation-qualification-DSO-tp118847p118864.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"
Re: Escalation qualification : DSO
No, about the only thing that would help would be to limit the returned result to 500, which would cause TONS of other problems elsewhere in the system. On Mon, Sep 8, 2014 at 10:33 AM, Jayesh wrote: > ** > Will server-side-table-chunk-size = 500 help? > -- > From: MalviyaSaurabh > Sent: 08-09-2014 04:46 PM > To: arslist@ARSLIST.ORG > Subject: Escalation qualification : DSO > > Hi All, > I am in the process of archiving records in remedy. I have written an > escalation with DSO action written which is working. I have the escalation > qualification as > ( 'Ticket Closed Date' <= "2/28/2009 11:59:59 PM") AND ( 'Status' = > "Closed") AND ( 'Ticket Closed Date' >= "1/1/2009 12:00:00 AM") > As over 1 lac record are there in this timespan, there are overhead issues > happening at the db level. > > Is there any way we can have the escalation run in batches of say 500 > records present in this qualification. > > Regards, > Saurabh > > > > -- > View this message in context: > http://ars-action-request-system.1.n7.nabble.com/Escalation-qualification-DSO-tp118847.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" > _ARSlist: "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"
Re: Escalation qualification : DSO
Will server-side-table-chunk-size = 500 help? -Original Message- From: "MalviyaSaurabh" Sent: 08-09-2014 04:46 PM To: "arslist@ARSLIST.ORG" Subject: Escalation qualification : DSO Hi All, I am in the process of archiving records in remedy. I have written an escalation with DSO action written which is working. I have the escalation qualification as ( 'Ticket Closed Date' <= "2/28/2009 11:59:59 PM") AND ( 'Status' = "Closed") AND ( 'Ticket Closed Date' >= "1/1/2009 12:00:00 AM") As over 1 lac record are there in this timespan, there are overhead issues happening at the db level. Is there any way we can have the escalation run in batches of say 500 records present in this qualification. Regards, Saurabh -- View this message in context: http://ars-action-request-system.1.n7.nabble.com/Escalation-qualification-DSO-tp118847.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"
Re: Escalation qualification : DSO
This is one of a few situations I've encountered where global fields at the server level would be useful. If we could create a global field with a lifespan of a transaction (or, in this case, the run of the escalation), that retained its same value across all records (of all forms) across the entire transaction, then you could architect the workflow so that each record increments a global counter and those after the 500th would disregard the operation. There would still be some minimal processing overhead for the the additional records (those over #500), but it should significantly mitigate the issue described. Sorry for the sidetrack. -charlie On Mon, Sep 8, 2014 at 7:58 AM, Vikrant Kulkarni wrote: > ** > > I would suggest look into RRR|Chive from rrr.se it just works fine in > this case. > On Sep 8, 2014 8:25 PM, "LJ LongWing" wrote: > >> ** >> I don't believe so, an escalation will always iterate over all records >> that match the qual. >> >> >> On Mon, Sep 8, 2014 at 8:45 AM, MalviyaSaurabh < >> malviya.saurab...@gmail.com> wrote: >> >>> Hi All, >>> I am in the process of archiving records in remedy. I have written an >>> escalation with DSO action written which is working. I have the >>> escalation >>> qualification as >>> ( 'Ticket Closed Date' <= "2/28/2009 11:59:59 PM") AND ( 'Status' = >>> "Closed") AND ( 'Ticket Closed Date' >= "1/1/2009 12:00:00 AM") >>> As over 1 lac record are there in this timespan, there are overhead >>> issues >>> happening at the db level. >>> >>> Is there any way we can have the escalation run in batches of say 500 >>> records present in this qualification. >>> >>> Regards, >>> Saurabh >>> >>> >>> >>> -- >>> View this message in context: >>> http://ars-action-request-system.1.n7.nabble.com/Escalation-qualification-DSO-tp118847.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" >>> >> >> _ARSlist: "Where the Answers Are" and have been for 20 years_ > > _ARSlist: "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"
Re: Escalation qualification : DSO
I would suggest you create several escalations splitting the date ranges into short segments. On Monday, September 8, 2014 10:59 AM, Vikrant Kulkarni wrote: ** I would suggest look into RRR|Chive from rrr.se it just works fine in this case. On Sep 8, 2014 8:25 PM, "LJ LongWing" wrote: ** >I don't believe so, an escalation will always iterate over all records that >match the qual. > > > >On Mon, Sep 8, 2014 at 8:45 AM, MalviyaSaurabh >wrote: > >Hi All, >>I am in the process of archiving records in remedy. I have written an >>escalation with DSO action written which is working. I have the escalation >>qualification as >>( 'Ticket Closed Date' <= "2/28/2009 11:59:59 PM") AND ( 'Status' = >>"Closed") AND ( 'Ticket Closed Date' >= "1/1/2009 12:00:00 AM") >>As over 1 lac record are there in this timespan, there are overhead issues >>happening at the db level. >> >>Is there any way we can have the escalation run in batches of say 500 >>records present in this qualification. >> >>Regards, >>Saurabh >> >> >> >>-- >>View this message in context: >>http://ars-action-request-system.1.n7.nabble.com/Escalation-qualification-DSO-tp118847.html >>Sent from the ARS (Action Request System) mailing list archive at Nabble.com. >> >>___ >>UNSUBSCRIBE or access ARSlist Archives at http://www.arslist.org/ >>"Where the Answers Are, and have been for 20 years" >> > _ARSlist: "Where the Answers Are" and have been for 20 years_ _ARSlist: "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"
Re: Escalation qualification : DSO
I would suggest look into RRR|Chive from rrr.se it just works fine in this case. On Sep 8, 2014 8:25 PM, "LJ LongWing" wrote: > ** > I don't believe so, an escalation will always iterate over all records > that match the qual. > > > On Mon, Sep 8, 2014 at 8:45 AM, MalviyaSaurabh < > malviya.saurab...@gmail.com> wrote: > >> Hi All, >> I am in the process of archiving records in remedy. I have written an >> escalation with DSO action written which is working. I have the escalation >> qualification as >> ( 'Ticket Closed Date' <= "2/28/2009 11:59:59 PM") AND ( 'Status' = >> "Closed") AND ( 'Ticket Closed Date' >= "1/1/2009 12:00:00 AM") >> As over 1 lac record are there in this timespan, there are overhead issues >> happening at the db level. >> >> Is there any way we can have the escalation run in batches of say 500 >> records present in this qualification. >> >> Regards, >> Saurabh >> >> >> >> -- >> View this message in context: >> http://ars-action-request-system.1.n7.nabble.com/Escalation-qualification-DSO-tp118847.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" >> > > _ARSlist: "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"
Re: Escalation qualification : DSO
I don't believe so, an escalation will always iterate over all records that match the qual. On Mon, Sep 8, 2014 at 8:45 AM, MalviyaSaurabh wrote: > Hi All, > I am in the process of archiving records in remedy. I have written an > escalation with DSO action written which is working. I have the escalation > qualification as > ( 'Ticket Closed Date' <= "2/28/2009 11:59:59 PM") AND ( 'Status' = > "Closed") AND ( 'Ticket Closed Date' >= "1/1/2009 12:00:00 AM") > As over 1 lac record are there in this timespan, there are overhead issues > happening at the db level. > > Is there any way we can have the escalation run in batches of say 500 > records present in this qualification. > > Regards, > Saurabh > > > > -- > View this message in context: > http://ars-action-request-system.1.n7.nabble.com/Escalation-qualification-DSO-tp118847.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"
Escalation qualification : DSO
Hi All, I am in the process of archiving records in remedy. I have written an escalation with DSO action written which is working. I have the escalation qualification as ( 'Ticket Closed Date' <= "2/28/2009 11:59:59 PM") AND ( 'Status' = "Closed") AND ( 'Ticket Closed Date' >= "1/1/2009 12:00:00 AM") As over 1 lac record are there in this timespan, there are overhead issues happening at the db level. Is there any way we can have the escalation run in batches of say 500 records present in this qualification. Regards, Saurabh -- View this message in context: http://ars-action-request-system.1.n7.nabble.com/Escalation-qualification-DSO-tp118847.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"
Re: Escalation Permission Error
Thanks, I didn't even look at it from the aspect that it isn't worded as a system error. Too many things to address at the same time. I will find it now. ARInside to the rescue. And thank you LJ and Tauf for setting me on the right path. Tauf, I knew that it was some action being intiated by the escalation, but I was thinking about it from the aspect that escalations usually had full power and permissions didn't impact them. It not being a system message definitely points to the issue. Thanks again. On Fri, Aug 29, 2014 at 9:08 AM, Tauf Chowdhury wrote: > ** > Yes, usually the out of box errors don't include exclamation points!! <-- > like that :) > > > On Fri, Aug 29, 2014 at 9:07 AM, LJ LongWing > wrote: > >> ** >> Well...one thing is for sure, that's not a system generated message, and >> not ITSM # eitherso, there is some workflow that is firing causing that >> error, so you just need to use something like ARInside to get the error >> messages and you will find your workflow. >> >> >> On Fri, Aug 29, 2014 at 6:59 AM, Brian Goralczyk < >> bgoralczyk.w...@gmail.com> wrote: >> >>> ** >>> All, >>> >>> I am kind of stumped here. I am hoping for some ideas on what to search >>> for. I am getting an error when an escalation runs that it doesn't have >>> permission to update a record. >>> >>> Can anybody give me an idea on what to look for to figure out why this >>> is happening? >>> >>> Filter operation in escalation failed, errno=33049 >>> You don't have sufficient permissions to perform this status >>> change! >>> >>> AR Version 7.6.4 if that helps. >>> >>> TIA, >>> >>> Brian Goralczyk >>> _ARSlist: "Where the Answers Are" and have been for 20 years_ >> >> >> _ARSlist: "Where the Answers Are" and have been for 20 years_ >> > > > > -- > > > *Tauf Chowdhury* > _ARSlist: "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"
Re: Escalation Permission Error
Yes, usually the out of box errors don't include exclamation points!! <-- like that :) On Fri, Aug 29, 2014 at 9:07 AM, LJ LongWing wrote: > ** > Well...one thing is for sure, that's not a system generated message, and > not ITSM # eitherso, there is some workflow that is firing causing that > error, so you just need to use something like ARInside to get the error > messages and you will find your workflow. > > > On Fri, Aug 29, 2014 at 6:59 AM, Brian Goralczyk < > bgoralczyk.w...@gmail.com> wrote: > >> ** >> All, >> >> I am kind of stumped here. I am hoping for some ideas on what to search >> for. I am getting an error when an escalation runs that it doesn't have >> permission to update a record. >> >> Can anybody give me an idea on what to look for to figure out why this is >> happening? >> >> Filter operation in escalation failed, errno=33049 >> You don't have sufficient permissions to perform this status >> change! >> >> AR Version 7.6.4 if that helps. >> >> TIA, >> >> Brian Goralczyk >> _ARSlist: "Where the Answers Are" and have been for 20 years_ > > > _ARSlist: "Where the Answers Are" and have been for 20 years_ > -- *Tauf Chowdhury* ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
Re: Escalation Permission Error
Brian, It looks like this isn't an error with the Escalation but really an error thrown by a filter because of the type of operation you are trying to perform. (Hope that makes sense) For example, as a user, I may try to take a Change request and move it directly from Planning In Progress to Completed using the Status dropdown. When I try to save, a filter throws the error: You don't have sufficient permissions to perform this change. So, I think you need to look at the update you're trying to make, do it manually, see what the error is, and try to work around that. On Fri, Aug 29, 2014 at 8:59 AM, Brian Goralczyk wrote: > ** > All, > > I am kind of stumped here. I am hoping for some ideas on what to search > for. I am getting an error when an escalation runs that it doesn't have > permission to update a record. > > Can anybody give me an idea on what to look for to figure out why this is > happening? > > Filter operation in escalation failed, errno=33049 > You don't have sufficient permissions to perform this status change! > > AR Version 7.6.4 if that helps. > > TIA, > > Brian Goralczyk > _ARSlist: "Where the Answers Are" and have been for 20 years_ -- *Tauf Chowdhury* ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
Re: Escalation Permission Error
Well...one thing is for sure, that's not a system generated message, and not ITSM # eitherso, there is some workflow that is firing causing that error, so you just need to use something like ARInside to get the error messages and you will find your workflow. On Fri, Aug 29, 2014 at 6:59 AM, Brian Goralczyk wrote: > ** > All, > > I am kind of stumped here. I am hoping for some ideas on what to search > for. I am getting an error when an escalation runs that it doesn't have > permission to update a record. > > Can anybody give me an idea on what to look for to figure out why this is > happening? > > Filter operation in escalation failed, errno=33049 > You don't have sufficient permissions to perform this status change! > > AR Version 7.6.4 if that helps. > > TIA, > > Brian Goralczyk > _ARSlist: "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"
Escalation Permission Error
All, I am kind of stumped here. I am hoping for some ideas on what to search for. I am getting an error when an escalation runs that it doesn't have permission to update a record. Can anybody give me an idea on what to look for to figure out why this is happening? Filter operation in escalation failed, errno=33049 You don't have sufficient permissions to perform this status change! AR Version 7.6.4 if that helps. TIA, Brian Goralczyk ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
Re: Wrong escalation execution time
how much data this escalation is suppose to process? Note that you are running it every minute. You can try below approach. 1. Put this escalation on a separate escalation pool.. 2. Try running it during the off peak business hours (when there is less load on the server) 3. Enable Escalation, API/SQL/Filter logs at the scheduled time of the escalation run & see what activity is been performed at that time. HTH, Regards, Mayuresh On Sun, Aug 24, 2014 at 4:26 PM, Mahmoud Mahdy-Mohamed, Vodafone Egypt < mahmoud.mahdy-moha...@vodafone.com> wrote: > ** > > Any updates..?? > > > > *From:* Mahmoud Mahdy-Mohamed, Vodafone Egypt > *Sent:* Tuesday, August 19, 2014 12:05 PM > *To:* arslist@ARSLIST.ORG > *Subject:* Wrong escalation execution time > > > > Dears, > > Kindly help as I’m facing a critical issue, the escalations are running > randomly regardless the execution time that it should execute in. For > example I have escalation that has to run every *minute* however it is > running after *30 min* which causes a delay in other related work flows. > > Note:- I’m using 7.6.04 SP4 > > > > *Thanks,* > > *Best Regards,* > > > > *Mahmoud Mahdy Mohammed,PMP* | Business Process Automation > *Technology | Products & Services Delivery* > *Phone:* +20(0)1004999638 > * Mail:* *mahmoud.mahdy-moha...@vodafone.com > * > > > > > * > > The content of this document is classified as Vodafone Egypt S.A.E. > Confidential and Proprietary Information. > > The recipient hereby is committed to hold in strict confidence the > contents of this (e-mail, document, information) and not to disclose to any > third party without the prior written consent of Vodafone Egypt S.A.E. > Recipient will be held liable for any unauthorized disclosure. > > If you have received this message in error, please notify the sender by > return e-mail and delete the message in its entirety, including any > attachments. > > http://www.vodafone.com.eg > > > * > > _ARSlist: "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"
Re: Wrong escalation execution time
Hi Mahmoud, Please check the escalation pool. May be you might have one escalation pool that has so many filters that needs to be executed. Try to create a new pool and assign this escalation to that. Thanks, Vishal From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Mahmoud Mahdy-Mohamed, Vodafone Egypt Sent: Sunday, August 24, 2014 4:39 PM To: arslist@ARSLIST.ORG Subject: Re: Wrong escalation execution time ** Please ignore last message, it was sent by mistake From: Mahmoud Mahdy-Mohamed, Vodafone Egypt Sent: Sunday, August 24, 2014 1:57 PM To: arslist@ARSLIST.ORG Subject: RE: Wrong escalation execution time Any updates..?? From: Mahmoud Mahdy-Mohamed, Vodafone Egypt Sent: Tuesday, August 19, 2014 12:05 PM To: arslist@ARSLIST.ORG<mailto:arslist@ARSLIST.ORG> Subject: Wrong escalation execution time Dears, Kindly help as I'm facing a critical issue, the escalations are running randomly regardless the execution time that it should execute in. For example I have escalation that has to run every minute however it is running after 30 min which causes a delay in other related work flows. Note:- I'm using 7.6.04 SP4 Thanks, Best Regards, Mahmoud Mahdy Mohammed,PMP | Business Process Automation Technology | Products & Services Delivery Phone: +20(0)1004999638 Mail: mahmoud.mahdy-moha...@vodafone.com<mailto:mohamed.abdel-haf...@vodafone.com> * The content of this document is classified as Vodafone Egypt S.A.E. Confidential and Proprietary Information. The recipient hereby is committed to hold in strict confidence the contents of this (e-mail, document, information) and not to disclose to any third party without the prior written consent of Vodafone Egypt S.A.E. Recipient will be held liable for any unauthorized disclosure. If you have received this message in error, please notify the sender by return e-mail and delete the message in its entirety, including any attachments. http://www.vodafone.com.eg<http://www.vodafone.com.eg/> * _ARSlist: "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"
Re: Wrong escalation execution time
Please ignore last message, it was sent by mistake From: Mahmoud Mahdy-Mohamed, Vodafone Egypt Sent: Sunday, August 24, 2014 1:57 PM To: arslist@ARSLIST.ORG Subject: RE: Wrong escalation execution time Any updates..?? From: Mahmoud Mahdy-Mohamed, Vodafone Egypt Sent: Tuesday, August 19, 2014 12:05 PM To: arslist@ARSLIST.ORG<mailto:arslist@ARSLIST.ORG> Subject: Wrong escalation execution time Dears, Kindly help as I'm facing a critical issue, the escalations are running randomly regardless the execution time that it should execute in. For example I have escalation that has to run every minute however it is running after 30 min which causes a delay in other related work flows. Note:- I'm using 7.6.04 SP4 Thanks, Best Regards, Mahmoud Mahdy Mohammed,PMP | Business Process Automation Technology | Products & Services Delivery Phone: +20(0)1004999638 Mail: mahmoud.mahdy-moha...@vodafone.com<mailto:mohamed.abdel-haf...@vodafone.com> * The content of this document is classified as Vodafone Egypt S.A.E. Confidential and Proprietary Information. The recipient hereby is committed to hold in strict confidence the contents of this (e-mail, document, information) and not to disclose to any third party without the prior written consent of Vodafone Egypt S.A.E. Recipient will be held liable for any unauthorized disclosure. If you have received this message in error, please notify the sender by return e-mail and delete the message in its entirety, including any attachments. http://www.vodafone.com.eg * ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
Recall: Wrong escalation execution time
Mahmoud Mahdy-Mohamed, Vodafone Egypt would like to recall the message, "Wrong escalation execution time". * The content of this document is classified as Vodafone Egypt S.A.E. Confidential and Proprietary Information. The recipient hereby is committed to hold in strict confidence the contents of this (e-mail, document, information) and not to disclose to any third party without the prior written consent of Vodafone Egypt S.A.E. Recipient will be held liable for any unauthorized disclosure. If you have received this message in error, please notify the sender by return e-mail and delete the message in its entirety, including any attachments. http://www.vodafone.com.eg * ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
Re: Wrong escalation execution time
Any updates..?? From: Mahmoud Mahdy-Mohamed, Vodafone Egypt Sent: Tuesday, August 19, 2014 12:05 PM To: arslist@ARSLIST.ORG Subject: Wrong escalation execution time Dears, Kindly help as I'm facing a critical issue, the escalations are running randomly regardless the execution time that it should execute in. For example I have escalation that has to run every minute however it is running after 30 min which causes a delay in other related work flows. Note:- I'm using 7.6.04 SP4 Thanks, Best Regards, Mahmoud Mahdy Mohammed,PMP | Business Process Automation Technology | Products & Services Delivery Phone: +20(0)1004999638 Mail: mahmoud.mahdy-moha...@vodafone.com<mailto:mohamed.abdel-haf...@vodafone.com> * The content of this document is classified as Vodafone Egypt S.A.E. Confidential and Proprietary Information. The recipient hereby is committed to hold in strict confidence the contents of this (e-mail, document, information) and not to disclose to any third party without the prior written consent of Vodafone Egypt S.A.E. Recipient will be held liable for any unauthorized disclosure. If you have received this message in error, please notify the sender by return e-mail and delete the message in its entirety, including any attachments. http://www.vodafone.com.eg * ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
Re: Wrong escalation execution time
I haven't seen it for a while, but we did have multiple copies of logs where this was happening a year or so ago. If (as another poster said) it's a bug that has been fixed, perhaps that's why I haven't seen it for a while. From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Rick Westbrock Sent: Wednesday, August 20, 2014 10:47 AM To: arslist@ARSLIST.ORG Subject: Re: Wrong escalation execution time ** I thought undeclared escalations went into pool 1 by default as well. That being said I would agree that if you are going to the trouble to create separate pools it would be worth the effort IMO to analyze all your escalations and parse them out into separate pools based on scheduled execution time and expected run time to prevent bottlenecks. I have done that myself but only for custom escalations, not any of the ITSM workflow. -Rick From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of LJ LongWing Sent: Wednesday, August 20, 2014 8:22 AM To: arslist@ARSLIST.ORG Subject: Re: Wrong escalation execution time ** William, I have never seen that, I have experienced that any escalation that doesn't have a pool defined runs in pool 1 (legacy style)do you have a workable example of a non-pooled escalation jumping to a pool other than 1? On Wed, Aug 20, 2014 at 8:46 AM, William Rentfrow mailto:wrentf...@stratacominc.com>> wrote: ** There's one other thing that can be really vexing when dealing with this problem. Let's decide you go multi-threaded. You put your escalation that needs to run every minute on a new pool (thread) of #4. You set some of the others to 1, 2, and 3. But...if you leave ANY of the escalations undeclared for which pool they should use, they still CAN use #4, and mess up your escalation. I've seen that happen quite a few times. So basically - if you are going to define a pool for one escalation - you might as well do it for ALL of the escalations. From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG<mailto:arslist@ARSLIST.ORG>] On Behalf Of Brian Goralczyk Sent: Tuesday, August 19, 2014 6:39 PM To: arslist@ARSLIST.ORG<mailto:arslist@ARSLIST.ORG> Subject: Re: Wrong escalation execution time ** One of the tricks that I have found to help is to look at the number of records that are in the table and how many are returned by your escalation. Then decide what is being done to them and does it need to be single threaded? If not, and you just need the escalation to schedule the work it might be something that you can turn multi-threaded in the way it runs by having an escalation for that has one record and performs a push to all the matching records. I can go into this deeper if anyone prefers. But it can definitely improve the performance of escalations. Brian Goralczyk On Tue, Aug 19, 2014 at 1:15 PM, Doug Blair mailto:d...@blairing.com>> wrote: ** Mahmoud, I have done quite a bit of fiddling with just this situation. Simply put, out-of-the-box the Escalation process is single threaded, which means that with no further adjustments only one escalation can operate at any given time. A long running escalation will delay the start of others, and a very long running escalation can cause some cases of the shorter ones to be skipped entirely. To fix this you can add threads to the escalation process (390603). This will allow more than one escalation to run at the same time. This will allow more of your escalations to complete without blocking each other, but still might allow some to be delayed. There is also the chance that some escalations depend on other escalations to be completed before they will do what is expected. The notification engine has a couple cases like this. These sorts of escalations can be grouped together using escalation pools. Please do not be tempted to add one thread or pool for every escalation! That would work, but would waste a lot of resources and potentially slow things down. You will need to turn on escalation logging and see how many escalations are ready too fire each minute, then adjust the number of threads so that more of them will fire and complete. Then group the ones which should not be blocked into unique pools. You can experiment with all of these pools and threads a bit, and remember that each thread, whether in an escalation queue or any other queue will tax the system somewhat. You want those threads to be mostly busy, and for there to be at least one thread/pool combination to be available every minute for your essential one. One way to be certain this happens might be to isolate your critical escalation in a pool by itself (let’s say pool 3), set your escalation threads to 3, and set all the other escalations to either pool NULL (which is the default) or pools 1-2. Anything in pool 1 or 2 will run on one of
Re: Wrong escalation execution time
I think there was a bug that was fixed, but I can’t remember which patch Of course the documentation doesn’t really cover this (It mentions Escalations assigned to a pool with no thread, but not Escalations not assigned to any pool when multiple pools are defined) Escalations can be assigned to pools so the escalations from each pool run in parallel on separate threads within the escalation queue. To use escalation pools, you must first configure multiple threads for the escalation queue as described in AR System server queues. If you assign an escalation to a pool that has no thread configured, the escalation is run by the first thread. Fred From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Rick Westbrock Sent: Wednesday, August 20, 2014 10:47 AM To: arslist@ARSLIST.ORG Subject: Re: Wrong escalation execution time ** I thought undeclared escalations went into pool 1 by default as well. That being said I would agree that if you are going to the trouble to create separate pools it would be worth the effort IMO to analyze all your escalations and parse them out into separate pools based on scheduled execution time and expected run time to prevent bottlenecks. I have done that myself but only for custom escalations, not any of the ITSM workflow. -Rick From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of LJ LongWing Sent: Wednesday, August 20, 2014 8:22 AM To: arslist@ARSLIST.ORG<mailto:arslist@ARSLIST.ORG> Subject: Re: Wrong escalation execution time ** William, I have never seen that, I have experienced that any escalation that doesn't have a pool defined runs in pool 1 (legacy style)do you have a workable example of a non-pooled escalation jumping to a pool other than 1? On Wed, Aug 20, 2014 at 8:46 AM, William Rentfrow wrote: ** There's one other thing that can be really vexing when dealing with this problem. Let's decide you go multi-threaded. You put your escalation that needs to run every minute on a new pool (thread) of #4. You set some of the others to 1, 2, and 3. But...if you leave ANY of the escalations undeclared for which pool they should use, they still CAN use #4, and mess up your escalation. I've seen that happen quite a few times. So basically - if you are going to define a pool for one escalation - you might as well do it for ALL of the escalations. From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG<mailto:arslist@ARSLIST.ORG>] On Behalf Of Brian Goralczyk Sent: Tuesday, August 19, 2014 6:39 PM To: arslist@ARSLIST.ORG<mailto:arslist@ARSLIST.ORG> Subject: Re: Wrong escalation execution time ** One of the tricks that I have found to help is to look at the number of records that are in the table and how many are returned by your escalation. Then decide what is being done to them and does it need to be single threaded? If not, and you just need the escalation to schedule the work it might be something that you can turn multi-threaded in the way it runs by having an escalation for that has one record and performs a push to all the matching records. I can go into this deeper if anyone prefers. But it can definitely improve the performance of escalations. Brian Goralczyk On Tue, Aug 19, 2014 at 1:15 PM, Doug Blair wrote: ** Mahmoud, I have done quite a bit of fiddling with just this situation. Simply put, out-of-the-box the Escalation process is single threaded, which means that with no further adjustments only one escalation can operate at any given time. A long running escalation will delay the start of others, and a very long running escalation can cause some cases of the shorter ones to be skipped entirely. To fix this you can add threads to the escalation process (390603). This will allow more than one escalation to run at the same time. This will allow more of your escalations to complete without blocking each other, but still might allow some to be delayed. There is also the chance that some escalations depend on other escalations to be completed before they will do what is expected. The notification engine has a couple cases like this. These sorts of escalations can be grouped together using escalation pools. Please do not be tempted to add one thread or pool for every escalation! That would work, but would waste a lot of resources and potentially slow things down. You will need to turn on escalation logging and see how many escalations are ready too fire each minute, then adjust the number of threads so that more of them will fire and complete. Then group the ones which should not be blocked into unique pools. You can experiment with all of these pools and threads a bit, and remember that each thread, whether in an escalation queue or any other queue will tax the system somewhat. You want those threads to be mostly busy, and for there to be at l
Re: Wrong escalation execution time
I thought undeclared escalations went into pool 1 by default as well. That being said I would agree that if you are going to the trouble to create separate pools it would be worth the effort IMO to analyze all your escalations and parse them out into separate pools based on scheduled execution time and expected run time to prevent bottlenecks. I have done that myself but only for custom escalations, not any of the ITSM workflow. -Rick From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of LJ LongWing Sent: Wednesday, August 20, 2014 8:22 AM To: arslist@ARSLIST.ORG Subject: Re: Wrong escalation execution time ** William, I have never seen that, I have experienced that any escalation that doesn't have a pool defined runs in pool 1 (legacy style)do you have a workable example of a non-pooled escalation jumping to a pool other than 1? On Wed, Aug 20, 2014 at 8:46 AM, William Rentfrow mailto:wrentf...@stratacominc.com>> wrote: ** There's one other thing that can be really vexing when dealing with this problem. Let's decide you go multi-threaded. You put your escalation that needs to run every minute on a new pool (thread) of #4. You set some of the others to 1, 2, and 3. But...if you leave ANY of the escalations undeclared for which pool they should use, they still CAN use #4, and mess up your escalation. I've seen that happen quite a few times. So basically - if you are going to define a pool for one escalation - you might as well do it for ALL of the escalations. From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG<mailto:arslist@ARSLIST.ORG>] On Behalf Of Brian Goralczyk Sent: Tuesday, August 19, 2014 6:39 PM To: arslist@ARSLIST.ORG<mailto:arslist@ARSLIST.ORG> Subject: Re: Wrong escalation execution time ** One of the tricks that I have found to help is to look at the number of records that are in the table and how many are returned by your escalation. Then decide what is being done to them and does it need to be single threaded? If not, and you just need the escalation to schedule the work it might be something that you can turn multi-threaded in the way it runs by having an escalation for that has one record and performs a push to all the matching records. I can go into this deeper if anyone prefers. But it can definitely improve the performance of escalations. Brian Goralczyk On Tue, Aug 19, 2014 at 1:15 PM, Doug Blair mailto:d...@blairing.com>> wrote: ** Mahmoud, I have done quite a bit of fiddling with just this situation. Simply put, out-of-the-box the Escalation process is single threaded, which means that with no further adjustments only one escalation can operate at any given time. A long running escalation will delay the start of others, and a very long running escalation can cause some cases of the shorter ones to be skipped entirely. To fix this you can add threads to the escalation process (390603). This will allow more than one escalation to run at the same time. This will allow more of your escalations to complete without blocking each other, but still might allow some to be delayed. There is also the chance that some escalations depend on other escalations to be completed before they will do what is expected. The notification engine has a couple cases like this. These sorts of escalations can be grouped together using escalation pools. Please do not be tempted to add one thread or pool for every escalation! That would work, but would waste a lot of resources and potentially slow things down. You will need to turn on escalation logging and see how many escalations are ready too fire each minute, then adjust the number of threads so that more of them will fire and complete. Then group the ones which should not be blocked into unique pools. You can experiment with all of these pools and threads a bit, and remember that each thread, whether in an escalation queue or any other queue will tax the system somewhat. You want those threads to be mostly busy, and for there to be at least one thread/pool combination to be available every minute for your essential one. One way to be certain this happens might be to isolate your critical escalation in a pool by itself (let’s say pool 3), set your escalation threads to 3, and set all the other escalations to either pool NULL (which is the default) or pools 1-2. Anything in pool 1 or 2 will run on one of the first two available threads, and your essential one will be the only thing that runs in thread 3. You might have several escalations which need to fire every minute. As long as those don’t take a long time to run they could be all in the same pool. If you find that running all the escalations assigned to pool 3 takes longer than a minute, you’ll need to look at more threads or more pools. You can also investigate scheduling of the escalations. It is very common
Re: Wrong escalation execution time
William, I have never seen that, I have experienced that any escalation that doesn't have a pool defined runs in pool 1 (legacy style)do you have a workable example of a non-pooled escalation jumping to a pool other than 1? On Wed, Aug 20, 2014 at 8:46 AM, William Rentfrow < wrentf...@stratacominc.com> wrote: > ** > > There's one other thing that can be really vexing when dealing with this > problem. > > > > Let's decide you go multi-threaded. You put your escalation that needs to > run every minute on a new pool (thread) of #4. You set some of the others > to 1, 2, and 3. > > > > But...if you leave ANY of the escalations undeclared for which pool they > should use, they still CAN use #4, and mess up your escalation. I've seen > that happen quite a few times. > > > > So basically - if you are going to define a pool for one escalation - you > might as well do it for ALL of the escalations. > > > > *From:* Action Request System discussion list(ARSList) [mailto: > arslist@ARSLIST.ORG] *On Behalf Of *Brian Goralczyk > *Sent:* Tuesday, August 19, 2014 6:39 PM > *To:* arslist@ARSLIST.ORG > *Subject:* Re: Wrong escalation execution time > > > > ** > > One of the tricks that I have found to help is to look at the number of > records that are in the table and how many are returned by your escalation. > Then decide what is being done to them and does it need to be single > threaded? If not, and you just need the escalation to schedule the work it > might be something that you can turn multi-threaded in the way it runs by > having an escalation for that has one record and performs a push to all the > matching records. > > > > I can go into this deeper if anyone prefers. But it can definitely > improve the performance of escalations. > > > > Brian Goralczyk > > > > On Tue, Aug 19, 2014 at 1:15 PM, Doug Blair wrote: > > ** > > Mahmoud, > > > > I have done quite a bit of fiddling with just this situation. > > > > Simply put, out-of-the-box the Escalation process is single threaded, > which means that with no further adjustments only one escalation can > operate at any given time. A long running escalation will delay the start > of others, and a very long running escalation can cause some cases of the > shorter ones to be skipped entirely. > > > > To fix this you can add threads to the escalation process (390603). This > will allow more than one escalation to run at the same time. This will > allow more of your escalations to complete without blocking each other, but > still might allow some to be delayed. > > > > There is also the chance that some escalations depend on other escalations > to be completed before they will do what is expected. The notification > engine has a couple cases like this. These sorts of escalations can be > grouped together using escalation pools. > > > > Please do not be tempted to add one thread or pool for every escalation! > That would work, but would waste a lot of resources and potentially slow > things down. You will need to turn on escalation logging and see how many > escalations are ready too fire each minute, then adjust the number of > threads so that more of them will fire and complete. Then group the ones > which should not be blocked into unique pools. You can experiment with all > of these pools and threads a bit, and remember that each thread, whether in > an escalation queue or any other queue will tax the system somewhat. You > want those threads to be mostly busy, and for there to be at least one > thread/pool combination to be available every minute for your essential one. > > > > One way to be certain this happens might be to isolate your critical > escalation in a pool by itself (let’s say pool 3), set your escalation > threads to 3, and set all the other escalations to either pool NULL (which > is the default) or pools 1-2. Anything in pool 1 or 2 will run on one of > the first two available threads, and your essential one will be the only > thing that runs in thread 3. > > > > You might have several escalations which need to fire every minute. As > long as those don’t take a long time to run they could be all in the same > pool. If you find that running all the escalations assigned to pool 3 takes > longer than a minute, you’ll need to look at more threads or more pools. > > > > You can also investigate scheduling of the escalations. It is very common > to find that a lot are scheduled to run at :00 in each hour (the default > value). Perhaps some of these can be mored to another time so they do not > all trigger at once. > > > > All that said, there is also the
Re: Wrong escalation execution time
There's one other thing that can be really vexing when dealing with this problem. Let's decide you go multi-threaded. You put your escalation that needs to run every minute on a new pool (thread) of #4. You set some of the others to 1, 2, and 3. But...if you leave ANY of the escalations undeclared for which pool they should use, they still CAN use #4, and mess up your escalation. I've seen that happen quite a few times. So basically - if you are going to define a pool for one escalation - you might as well do it for ALL of the escalations. From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Brian Goralczyk Sent: Tuesday, August 19, 2014 6:39 PM To: arslist@ARSLIST.ORG Subject: Re: Wrong escalation execution time ** One of the tricks that I have found to help is to look at the number of records that are in the table and how many are returned by your escalation. Then decide what is being done to them and does it need to be single threaded? If not, and you just need the escalation to schedule the work it might be something that you can turn multi-threaded in the way it runs by having an escalation for that has one record and performs a push to all the matching records. I can go into this deeper if anyone prefers. But it can definitely improve the performance of escalations. Brian Goralczyk On Tue, Aug 19, 2014 at 1:15 PM, Doug Blair mailto:d...@blairing.com>> wrote: ** Mahmoud, I have done quite a bit of fiddling with just this situation. Simply put, out-of-the-box the Escalation process is single threaded, which means that with no further adjustments only one escalation can operate at any given time. A long running escalation will delay the start of others, and a very long running escalation can cause some cases of the shorter ones to be skipped entirely. To fix this you can add threads to the escalation process (390603). This will allow more than one escalation to run at the same time. This will allow more of your escalations to complete without blocking each other, but still might allow some to be delayed. There is also the chance that some escalations depend on other escalations to be completed before they will do what is expected. The notification engine has a couple cases like this. These sorts of escalations can be grouped together using escalation pools. Please do not be tempted to add one thread or pool for every escalation! That would work, but would waste a lot of resources and potentially slow things down. You will need to turn on escalation logging and see how many escalations are ready too fire each minute, then adjust the number of threads so that more of them will fire and complete. Then group the ones which should not be blocked into unique pools. You can experiment with all of these pools and threads a bit, and remember that each thread, whether in an escalation queue or any other queue will tax the system somewhat. You want those threads to be mostly busy, and for there to be at least one thread/pool combination to be available every minute for your essential one. One way to be certain this happens might be to isolate your critical escalation in a pool by itself (let’s say pool 3), set your escalation threads to 3, and set all the other escalations to either pool NULL (which is the default) or pools 1-2. Anything in pool 1 or 2 will run on one of the first two available threads, and your essential one will be the only thing that runs in thread 3. You might have several escalations which need to fire every minute. As long as those don’t take a long time to run they could be all in the same pool. If you find that running all the escalations assigned to pool 3 takes longer than a minute, you’ll need to look at more threads or more pools. You can also investigate scheduling of the escalations. It is very common to find that a lot are scheduled to run at :00 in each hour (the default value). Perhaps some of these can be mored to another time so they do not all trigger at once. All that said, there is also the possibility that some of your escalations might be poorly written and just be doing things very inefficiently. Look closely at the RUNIF qualifications of those that seem to take a long time to complete, and turn those just as you would an inefficient filter qualification or search for a report or other lookup… Hope this helps! Doug Blair On Aug 19, 2014, at 4:04 AM, Mahmoud Mahdy-Mohamed, Vodafone Egypt mailto:mahmoud.mahdy-moha...@vodafone.com>> wrote: ** Dears, Kindly help as I’m facing a critical issue, the escalations are running randomly regardless the execution time that it should execute in. For example I have escalation that has to run every minute however it is running after 30 min which causes a delay in other related work flows. Note:- I’m using 7.6.04 SP4 Thanks, Best Regards, Mahmoud Mahdy Mohammed,PMP | Business Pr
Re: Wrong escalation execution time
One of the tricks that I have found to help is to look at the number of records that are in the table and how many are returned by your escalation. Then decide what is being done to them and does it need to be single threaded? If not, and you just need the escalation to schedule the work it might be something that you can turn multi-threaded in the way it runs by having an escalation for that has one record and performs a push to all the matching records. I can go into this deeper if anyone prefers. But it can definitely improve the performance of escalations. Brian Goralczyk On Tue, Aug 19, 2014 at 1:15 PM, Doug Blair wrote: > ** > Mahmoud, > > I have done quite a bit of fiddling with just this situation. > > Simply put, out-of-the-box the Escalation process is single threaded, > which means that with no further adjustments only one escalation can > operate at any given time. A long running escalation will delay the start > of others, and a very long running escalation can cause some cases of the > shorter ones to be skipped entirely. > > To fix this you can add threads to the escalation process (390603). This > will allow more than one escalation to run at the same time. This will > allow more of your escalations to complete without blocking each other, but > still might allow some to be delayed. > > There is also the chance that some escalations depend on other escalations > to be completed before they will do what is expected. The notification > engine has a couple cases like this. These sorts of escalations can be > grouped together using escalation pools. > > Please do not be tempted to add one thread or pool for every escalation! > That would work, but would waste a lot of resources and potentially slow > things down. You will need to turn on escalation logging and see how many > escalations are ready too fire each minute, then adjust the number of > threads so that more of them will fire and complete. Then group the ones > which should not be blocked into unique pools. You can experiment with all > of these pools and threads a bit, and remember that each thread, whether in > an escalation queue or any other queue will tax the system somewhat. You > want those threads to be mostly busy, and for there to be at least one > thread/pool combination to be available every minute for your essential one. > > One way to be certain this happens might be to isolate your critical > escalation in a pool by itself (let’s say pool 3), set your escalation > threads to 3, and set all the other escalations to either pool NULL (which > is the default) or pools 1-2. Anything in pool 1 or 2 will run on one of > the first two available threads, and your essential one will be the only > thing that runs in thread 3. > > You might have several escalations which need to fire every minute. As > long as those don’t take a long time to run they could be all in the same > pool. If you find that running all the escalations assigned to pool 3 takes > longer than a minute, you’ll need to look at more threads or more pools. > > You can also investigate scheduling of the escalations. It is very common > to find that a lot are scheduled to run at :00 in each hour (the default > value). Perhaps some of these can be mored to another time so they do not > all trigger at once. > > All that said, there is also the possibility that some of your escalations > might be poorly written and just be doing things very inefficiently. Look > closely at the RUNIF qualifications of those that seem to take a long time > to complete, and turn those just as you would an inefficient filter > qualification or search for a report or other lookup… > > Hope this helps! > > Doug Blair > > > On Aug 19, 2014, at 4:04 AM, Mahmoud Mahdy-Mohamed, Vodafone Egypt < > mahmoud.mahdy-moha...@vodafone.com> wrote: > > ** > Dears, > Kindly help as I’m facing a critical issue, the escalations are running > randomly regardless the execution time that it should execute in. For > example I have escalation that has to run every *minute* however it is > running after *30 min* which causes a delay in other related work flows. > Note:- I’m using 7.6.04 SP4 > > *Thanks,* > *Best Regards,* > > *Mahmoud Mahdy Mohammed,PMP* | Business Process Automation > *Technology | Products & Services Delivery* > *Phone:* +20(0)1004999638 > *Mail:* *mahmoud.mahdy-moha...@vodafone.com > * > > > > * > > The content of this document is classified as Vodafone Egypt S.A.E. > Confidential and Proprietary Information. > > The recipient hereby is committed to hold in strict confidence the > contents of
Re: Wrong escalation execution time
Mahmoud, I have done quite a bit of fiddling with just this situation. Simply put, out-of-the-box the Escalation process is single threaded, which means that with no further adjustments only one escalation can operate at any given time. A long running escalation will delay the start of others, and a very long running escalation can cause some cases of the shorter ones to be skipped entirely. To fix this you can add threads to the escalation process (390603). This will allow more than one escalation to run at the same time. This will allow more of your escalations to complete without blocking each other, but still might allow some to be delayed. There is also the chance that some escalations depend on other escalations to be completed before they will do what is expected. The notification engine has a couple cases like this. These sorts of escalations can be grouped together using escalation pools. Please do not be tempted to add one thread or pool for every escalation! That would work, but would waste a lot of resources and potentially slow things down. You will need to turn on escalation logging and see how many escalations are ready too fire each minute, then adjust the number of threads so that more of them will fire and complete. Then group the ones which should not be blocked into unique pools. You can experiment with all of these pools and threads a bit, and remember that each thread, whether in an escalation queue or any other queue will tax the system somewhat. You want those threads to be mostly busy, and for there to be at least one thread/pool combination to be available every minute for your essential one. One way to be certain this happens might be to isolate your critical escalation in a pool by itself (let’s say pool 3), set your escalation threads to 3, and set all the other escalations to either pool NULL (which is the default) or pools 1-2. Anything in pool 1 or 2 will run on one of the first two available threads, and your essential one will be the only thing that runs in thread 3. You might have several escalations which need to fire every minute. As long as those don’t take a long time to run they could be all in the same pool. If you find that running all the escalations assigned to pool 3 takes longer than a minute, you’ll need to look at more threads or more pools. You can also investigate scheduling of the escalations. It is very common to find that a lot are scheduled to run at :00 in each hour (the default value). Perhaps some of these can be mored to another time so they do not all trigger at once. All that said, there is also the possibility that some of your escalations might be poorly written and just be doing things very inefficiently. Look closely at the RUNIF qualifications of those that seem to take a long time to complete, and turn those just as you would an inefficient filter qualification or search for a report or other lookup… Hope this helps! Doug Blair On Aug 19, 2014, at 4:04 AM, Mahmoud Mahdy-Mohamed, Vodafone Egypt wrote: > ** > Dears, > Kindly help as I’m facing a critical issue, the escalations are running > randomly regardless the execution time that it should execute in. For example > I have escalation that has to run every minute however it is running after 30 > min which causes a delay in other related work flows. > Note:- I’m using 7.6.04 SP4 > > Thanks, > Best Regards, > > Mahmoud Mahdy Mohammed,PMP | Business Process Automation > Technology | Products & Services Delivery > Phone: +20(0)1004999638 > Mail: mahmoud.mahdy-moha...@vodafone.com > > * > > The content of this document is classified as Vodafone Egypt S.A.E. > Confidential and Proprietary Information. > > The recipient hereby is committed to hold in strict confidence the contents > of this (e-mail, document, information) and not to disclose to any third > party without the prior written consent of Vodafone Egypt S.A.E. Recipient > will be held liable for any unauthorized disclosure. > > If you have received this message in error, please notify the sender by > return e-mail and delete the message in its entirety, including any > attachments. > > http://www.vodafone.com.eg > > > * > > _ARSlist: "Where the Answers Are" and have been for 20 years_ Doug -- Doug Blair d...@blairing.com +1 224-558-5462 1208 East Fremont Street Arlington Heights, Illinois 60004 ITILv3 ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
Re: Wrong escalation execution time
Hi, This is presumably caused by a queuing situation where other slow escalations has to complete before the one under scrutiny is executed. 1. Check if other escalations are competing about execution time 2. Check that your escalation executes in less than 1 minute 3. Move your escalation to another, or a new, escalation thread Best Regards - Misi, RRR AB, http://www.rrr.se (ARSList MVP 2011) Ask the Remedy Licensing Experts (Best R.O.I. Award at WWRUG10/11/12/13): * 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. > Dears, > Kindly help as I'm facing a critical issue, the escalations are running > randomly regardless the execution time that it should execute in. For example > I have escalation that has to run every minute however it is running after 30 > min which causes a delay in other related work flows. > Note:- I'm using 7.6.04 SP4 > > Thanks, > Best Regards, > > Mahmoud Mahdy Mohammed,PMP | Business Process Automation > Technology | Products & Services Delivery > Phone: +20(0)1004999638 > Mail: > mahmoud.mahdy-moha...@vodafone.com<mailto:mohamed.abdel-haf...@vodafone.com> > > > * > > The content of this document is classified as Vodafone Egypt S.A.E. > Confidential and Proprietary Information. > > The recipient hereby is committed to hold in strict confidence the contents of > this (e-mail, document, information) and not to disclose to any third party > without the prior written consent of Vodafone Egypt S.A.E. Recipient will be > held liable for any unauthorized disclosure. > > If you have received this message in error, please notify the sender by return > e-mail and delete the message in its entirety, including any attachments. > > http://www.vodafone.com.eg > > * > > ___ > 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"
Wrong escalation execution time
Dears, Kindly help as I'm facing a critical issue, the escalations are running randomly regardless the execution time that it should execute in. For example I have escalation that has to run every minute however it is running after 30 min which causes a delay in other related work flows. Note:- I'm using 7.6.04 SP4 Thanks, Best Regards, Mahmoud Mahdy Mohammed,PMP | Business Process Automation Technology | Products & Services Delivery Phone: +20(0)1004999638 Mail: mahmoud.mahdy-moha...@vodafone.com<mailto:mohamed.abdel-haf...@vodafone.com> * The content of this document is classified as Vodafone Egypt S.A.E. Confidential and Proprietary Information. The recipient hereby is committed to hold in strict confidence the contents of this (e-mail, document, information) and not to disclose to any third party without the prior written consent of Vodafone Egypt S.A.E. Recipient will be held liable for any unauthorized disclosure. If you have received this message in error, please notify the sender by return e-mail and delete the message in its entirety, including any attachments. http://www.vodafone.com.eg * ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
Re: Filter & Escalation
I will take a stab at answering that for you Sweety, I think it is a semantic problem with the meaning of "execute" in the context of an escalation. In my mind the Escalation executes only once, be it on an interval (every 12 hours) or a specific time (2am on Mondays) or even by being called manually from Dev Studio (in newer versions of ARS). Think of "execute" as turning the escalation loose on the form to evaluate every record in that form against its qualification. I think that the statement below "Escalation execute on each matching record" is not quite phrased properly; I think it should read "Escalation executes the If Actions on each matching record" which might make it easier to understand the difference. You could even say that it "fires" the If Actions so as to not use the word escalation at all in that context. -Rick _ Rick Westbrock Remedy Administrator | IT Department 24 Hour Fitness USA, Inc. -Original Message- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Sweety Sent: Tuesday, June 03, 2014 11:35 AM To: arslist@ARSLIST.ORG Subject: Re: Filter & Escalation Hey Misi, hope you are doing well. Looks like you are busy with your work. I would prefer a positive pat ;) I did not understand this statement: Escalation execute on each matching record. But the Escalation itself runs once. Do't you think its a contradictive statement? Both seems to be of same meaning. Execute on each matching request but runs only once - Very confusing. :S ___ 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"
Resolved: Filter & Escalation
Thanks for making me understand that :D. You deserve a pat on your back now ;) Thanks Misi for puttings things simple. ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
Re: Filter & Escalation
Hi, I do not think that my statement was contradictory. But you did not quote me right... The Escalation runs once, meaning it performs a single search to the database. After finding 0-x records, it will perform its Escalation-Actions 0-x times. It is therefore very important to distinguish the execution of the Escalation from the execution of the Escalation-Actions. This is the same thing as a user doing a single Modify-All action that modifying many records. The client (mid-tier/aruser) will call the server 0-x times depending on how many records the user found in the search. Best Regards - Misi, RRR AB, http://www.rrr.se (ARSList MVP 2011) Ask the Remedy Licensing Experts (Best R.O.I. Award at WWRUG10/11/12/13): * 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. > Hey Misi, hope you are doing well. Looks like you are busy with your work. I > would prefer a positive pat ;) > > I did not understand this statement: Escalation execute on each matching > record. But the Escalation itself runs once. Do't you think its a > contradictive statement? Both seems to be of same meaning. > > Execute on each matching request but runs only once - Very confusing. :S > > ___ > 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"
Re: Filter & Escalation
Hey Misi, hope you are doing well. Looks like you are busy with your work. I would prefer a positive pat ;) I did not understand this statement: Escalation execute on each matching record. But the Escalation itself runs once. Do't you think its a contradictive statement? Both seems to be of same meaning. Execute on each matching request but runs only once - Very confusing. :S ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
Re: Filter & Escalation
Hi,
I thought that a pat on the back was a positive/assertive/encouraging action ;-)
No, Escalation-Actions do not execute once, they execute on each matching
record. But the Escalation itself runs once, and then performs zero to many
Action-sequences depending on the number of records it finds.
An escalation doing a Set-Fields action will be equivalent to a user doing a
Modify-All operation. The difference is that the performing user will be
AR_ESCALATOR and that the permissions of the escalation will be that of an
Administrator.
For each matching record the Set-Fields will be performed, and all the Modify
filters will then be executed (once for each record).
The normal way to use escalations is to perform time based stuff without
having a user pressing Save. Typically to find records that match some time
based criteria, for example a ('Priority' = "High" AND 'Status' <
"WorkInProgress" 'Escalated' = $NULL$ AND 'Create Date' < $TIMESTAMP$ - 60*60)
which will find the designated recrods more than an hour old.
The typical action is a Set-Fields which in turn may trigger some filters.
Sometimes you use the Notify action to send notifications as well, maybe in
conjunction with a Set-Fields setting the 'Escalated' field to "Yes".
There are many other uses as well.
Best Regards - Misi, RRR AB, http://www.rrr.se (ARSList MVP 2011)
Ask the Remedy Licensing Experts (Best R.O.I. Award at WWRUG10/11/12/13):
* 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.
> Correct me if any of below statements are wrong else give me a pat on my back
> :)
>
> Active Links/Filters : Executed once for each record hence acts on current
> request. Push fields/set fields can be used to create/update other records but
> they will trigger active links/filters based on the workflow condition.
>
> Escalations: Executed only once for all matching records.
>
> ___
> 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"
Re: Filter & Escalation
Correct me if any of below statements are wrong else give me a pat on my back :) Active Links/Filters : Executed once for each record hence acts on current request. Push fields/set fields can be used to create/update other records but they will trigger active links/filters based on the workflow condition. Escalations: Executed only once for all matching records. ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
Re: Filter & Escalation
Escalations perform a 'query' if you will - thus they will act on all records meeting the run-if qualification. Filters are based on (focus on) the record being submitted / modified, etc. But the focus is the record. If you're doing a modify all action, the filter will fire on each within the modify all. Now the actions within the filter (ie push field or set field from server) will have their own individual 'run if' clause or qualification where it could push fields to a series of records based on the qualification. The action within the filter also gives you the opportunity to define what to do if no records match or multiple match. Hope this helps a bit -Original Message- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Sweety Sent: Monday, June 2, 2014 3:53 PM To: arslist@ARSLIST.ORG Subject: Re: Filter & Escalation Hey LJ :) Good Morning/Afternoon/Evening. What if I am not performing action only on single record? What in case of Modify All option. Imagine I wrote a filter; Run If : 'Submitter' != $Null$ Action : Push Field : Update some entry. In this case filter will act on all records where submitter is not null and will update entries as per push field. It is not just acting on current requests but others also. Filters are acting on all matching requests. Am I overthinking or Am I stupid? Is it too hard for me to understand? ___ 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"
Re: Filter & Escalation
Hey LJ :) Good Morning/Afternoon/Evening. What if I am not performing action only on single record? What in case of Modify All option. Imagine I wrote a filter; Run If : 'Submitter' != $Null$ Action : Push Field : Update some entry. In this case filter will act on all records where submitter is not null and will update entries as per push field. It is not just acting on current requests but others also. Filters are acting on all matching requests. Am I overthinking or Am I stupid? Is it too hard for me to understand? ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
Re: Filter & Escalation
Sweety, When you perform an action on a single record, filters act on that record. They can cause set/push, that affects other records, and those records will have their own filters. Escalations perform a query, and then take actions on any record that matches the query, potentially causing filters that fire on that record to fire. does that make sense? On Mon, Jun 2, 2014 at 1:07 PM, Sweety wrote: > Hi List, > > I was reading the BMC wiki and found something weird in filters and > escalations. Wiki says filters act on current requests and escalations act > on all matching requests. I can modify requests through filters which are > not currently accessed by user. Filters acts on current requests - This > statement is not making any sense to me. Filters can also act on all > matching requests in Run If condition. > > Escalations act on all matching requests - Make sense. All workflows act > on all matching requests even filters and active links. Why there is a need > to mention it. > > Can anybody explain me what BMC is trying to say here? > > > ___ > 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"
Filter & Escalation
Hi List, I was reading the BMC wiki and found something weird in filters and escalations. Wiki says filters act on current requests and escalations act on all matching requests. I can modify requests through filters which are not currently accessed by user. Filters acts on current requests - This statement is not making any sense to me. Filters can also act on all matching requests in Run If condition. Escalations act on all matching requests - Make sense. All workflows act on all matching requests even filters and active links. Why there is a need to mention it. Can anybody explain me what BMC is trying to say here? ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
Re: Self-Terminating/disabling Escalation
The “Run Now” escalation option is also there in the 7.5 Dev Studio (at least in patch 007). David D. David Durling University of Georgia From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Jarl Grøneng Sent: Tuesday, May 06, 2014 7:21 AM To: arslist@ARSLIST.ORG Subject: Re: Self-Terminating/disabling Escalation ** This option was added to 7.6.04 Developer Studio. Using 7.6.04 Develper Studio against 7.5 or lower server version will also enable this option. -- J 2014-05-02 20:03 GMT+02:00 Rick Westbrock mailto:rwestbr...@24hourfit.com>>: ** I think that was in place as of version 7.6.04 since I remember right-clicking to run an escalation last year (but maybe my memory is faulty, I don’t have a 7.6.04 system to reference now). -Rick _ Rick Westbrock Remedy Administrator | IT Department 24 Hour Fitness USA, Inc. From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG<mailto:arslist@ARSLIST.ORG>] On Behalf Of LJ LongWing Sent: Friday, May 02, 2014 9:18 AM To: arslist@ARSLIST.ORG<mailto:arslist@ARSLIST.ORG> Subject: Re: Self-Terminating/disabling Escalation ** Doug, I hate to contradict you, but, if you right click on any escalation, the bottom option is 'Run Now'so, at least in the 8.1 version of the Dev Studio, there is a GUI option that enables this. On Thu, May 1, 2014 at 1:22 PM, Mueller, Doug mailto:doug_muel...@bmc.com>> wrote: ** OK, good news and bad news…… The best way to do this is to create an escalation that is disabled. Then, tell it to run one time. Well, that seems to be perfect and just what you asked for. So, how do you do this??? Well, that is the bad news. While we do have the exact functionality, we have not made it easy for you to get to. You can create an escalation and it can be disabled. NO problem there. Now, there is way using an API call to say to run ANY escalation (enabled or disabled) ONE TIME RIGHT NOW. So, this is good news. The bad news is that we have not exposed a way to call that API call from Dev Studio. This means you have to call it from an API program or use the driver sample program we ship to cause it to run. Using driver, you can create a small script that performs the login, runs the escalation, and terminates and pass the escalation name in as a parameter. Then, you could just run that script directly (or through workflow) to perform the operation. A good enhancement request is to have the ability to say to "run now" for an escalation exposed through dev studio. Other than this feature, you have to enable it so that it triggers and runs and then disable it so that it does not run again. There is no other way to manage this. Doug Mueller From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG<mailto:arslist@ARSLIST.ORG>] On Behalf Of Charlie Lotridge Sent: Thursday, May 01, 2014 10:18 AM To: arslist@ARSLIST.ORG<mailto:arslist@ARSLIST.ORG> Subject: Re: Self-Terminating/disabling Escalation ** Hi Sapna, The bad news is that there is no workflow action that will accomplish this for you. You could potentially try to use a SQL update (in a Direct SQL action) to directly update the Remedy data dictionary, which would look something like this: UPDATE escalation SET enable = 0 WHERE name = 'The Escalation Name' But I'd recommend against this for two reasons. First, any running AR servers would not notice the change until they reload their data dictionary caches. Second, doing this *might* cause the escalation to become invalid in that it would no longer match the checksum (in the safeGuard column of the escalation table). I haven't checked this and don't know offhand if the "enable" is part of that checksum. The only way I can think of would be to write a small API program that performs the action. This would immediately affect the AR server on which it's run, but it would not propagate to any other servers until they reload their caches (I don't know much about server groups...would other servers in the group notice such changes and automatically reload?). I hope this helps. -charlie On Wed, Apr 30, 2014 at 12:06 PM, Sapna Motwani mailto:sapana.motw...@gmail.com>> wrote: Hello Experts, Please suggest is it possible to define a self-terminating escalation. I need to run an escalation just once, and then it should disable itself. I want to know is it possible to define an escalation which triggers some workflow to mark the calling parent escalation as disable. Any help would be highly appreciated. Regards, Sapna ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org<http://www.arslist.org> "Where the Answers Are, and have been for 20 years" _ARSlist: "Where
Re: Self-Terminating/disabling Escalation
This option was added to 7.6.04 Developer Studio. Using 7.6.04 Develper Studio against 7.5 or lower server version will also enable this option. -- J 2014-05-02 20:03 GMT+02:00 Rick Westbrock : > ** > > I think that was in place as of version 7.6.04 since I remember > right-clicking to run an escalation last year (but maybe my memory is > faulty, I don’t have a 7.6.04 system to reference now). > > > > -Rick > > > > *_* > > *Rick Westbrock* > Remedy Administrator | IT Department > 24 Hour Fitness USA, Inc. > > > > *From:* Action Request System discussion list(ARSList) [mailto: > arslist@ARSLIST.ORG] *On Behalf Of *LJ LongWing > *Sent:* Friday, May 02, 2014 9:18 AM > > *To:* arslist@ARSLIST.ORG > *Subject:* Re: Self-Terminating/disabling Escalation > > > > ** > > Doug, > > I hate to contradict you, but, if you right click on any escalation, the > bottom option is 'Run Now'so, at least in the 8.1 version of the Dev > Studio, there is a GUI option that enables this. > > > > On Thu, May 1, 2014 at 1:22 PM, Mueller, Doug > wrote: > > ** > > OK, good news and bad news…… > > > > The best way to do this is to create an escalation that is disabled. > Then, tell it to run one time. > > > > Well, that seems to be perfect and just what you asked for. So, how do > you do this??? > > > > Well, that is the bad news. While we do have the exact functionality, we > have not made it easy for you to > > get to. > > > > You can create an escalation and it can be disabled. NO problem there. > > > > Now, there is way using an API call to say to run ANY escalation (enabled > or disabled) ONE TIME RIGHT NOW. > > So, this is good news. > > > > The bad news is that we have not exposed a way to call that API call from > Dev Studio. This means you have > > to call it from an API program or use the driver sample program we ship to > cause it to run. > > > > Using driver, you can create a small script that performs the login, runs > the escalation, and terminates and pass > > the escalation name in as a parameter. Then, you could just run that > script directly (or through workflow) to > > perform the operation. A good enhancement request is to have the ability > to say to "run now" for an > > escalation exposed through dev studio. > > > > > > Other than this feature, you have to enable it so that it triggers and > runs and then disable it so that it does not > > run again. There is no other way to manage this. > > > > Doug Mueller > > > > *From:* Action Request System discussion list(ARSList) [mailto: > arslist@ARSLIST.ORG] *On Behalf Of *Charlie Lotridge > *Sent:* Thursday, May 01, 2014 10:18 AM > > > *To:* arslist@ARSLIST.ORG > *Subject:* Re: Self-Terminating/disabling Escalation > > > > ** > > Hi Sapna, > > > > The bad news is that there is no workflow action that will accomplish this > for you. You could potentially try to use a SQL update (in a Direct SQL > action) to directly update the Remedy data dictionary, which would look > something like this: > > > > UPDATE escalation > > SET enable = 0 > > WHERE name = 'The Escalation Name' > > > > But I'd recommend against this for two reasons. First, any running AR > servers would not notice the change until they reload their data dictionary > caches. > > > > Second, doing this *might* cause the escalation to become invalid in that > it would no longer match the checksum (in the safeGuard column of the > escalation table). I haven't checked this and don't know offhand if the > "enable" is part of that checksum. > > > > The only way I can think of would be to write a small API program that > performs the action. This would immediately affect the AR server on which > it's run, but it would not propagate to any other servers until they reload > their caches (I don't know much about server groups...would other servers > in the group notice such changes and automatically reload?). > > > > I hope this helps. > > > > -charlie > > > > On Wed, Apr 30, 2014 at 12:06 PM, Sapna Motwani > wrote: > > Hello Experts, > > Please suggest is it possible to define a self-terminating escalation. I > need to run an escalation just once, and then it should disable itself. > I want to know is it possible to define an escalation which triggers some > workflow to mark the calling parent escalation as disable. > > Any help would be highly appreciated. > >
Re: Self-Terminating/disabling Escalation
I think that was in place as of version 7.6.04 since I remember right-clicking to run an escalation last year (but maybe my memory is faulty, I don’t have a 7.6.04 system to reference now). -Rick _ Rick Westbrock Remedy Administrator | IT Department 24 Hour Fitness USA, Inc. From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of LJ LongWing Sent: Friday, May 02, 2014 9:18 AM To: arslist@ARSLIST.ORG Subject: Re: Self-Terminating/disabling Escalation ** Doug, I hate to contradict you, but, if you right click on any escalation, the bottom option is 'Run Now'so, at least in the 8.1 version of the Dev Studio, there is a GUI option that enables this. On Thu, May 1, 2014 at 1:22 PM, Mueller, Doug mailto:doug_muel...@bmc.com>> wrote: ** OK, good news and bad news…… The best way to do this is to create an escalation that is disabled. Then, tell it to run one time. Well, that seems to be perfect and just what you asked for. So, how do you do this??? Well, that is the bad news. While we do have the exact functionality, we have not made it easy for you to get to. You can create an escalation and it can be disabled. NO problem there. Now, there is way using an API call to say to run ANY escalation (enabled or disabled) ONE TIME RIGHT NOW. So, this is good news. The bad news is that we have not exposed a way to call that API call from Dev Studio. This means you have to call it from an API program or use the driver sample program we ship to cause it to run. Using driver, you can create a small script that performs the login, runs the escalation, and terminates and pass the escalation name in as a parameter. Then, you could just run that script directly (or through workflow) to perform the operation. A good enhancement request is to have the ability to say to "run now" for an escalation exposed through dev studio. Other than this feature, you have to enable it so that it triggers and runs and then disable it so that it does not run again. There is no other way to manage this. Doug Mueller From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG<mailto:arslist@ARSLIST.ORG>] On Behalf Of Charlie Lotridge Sent: Thursday, May 01, 2014 10:18 AM To: arslist@ARSLIST.ORG<mailto:arslist@ARSLIST.ORG> Subject: Re: Self-Terminating/disabling Escalation ** Hi Sapna, The bad news is that there is no workflow action that will accomplish this for you. You could potentially try to use a SQL update (in a Direct SQL action) to directly update the Remedy data dictionary, which would look something like this: UPDATE escalation SET enable = 0 WHERE name = 'The Escalation Name' But I'd recommend against this for two reasons. First, any running AR servers would not notice the change until they reload their data dictionary caches. Second, doing this *might* cause the escalation to become invalid in that it would no longer match the checksum (in the safeGuard column of the escalation table). I haven't checked this and don't know offhand if the "enable" is part of that checksum. The only way I can think of would be to write a small API program that performs the action. This would immediately affect the AR server on which it's run, but it would not propagate to any other servers until they reload their caches (I don't know much about server groups...would other servers in the group notice such changes and automatically reload?). I hope this helps. -charlie On Wed, Apr 30, 2014 at 12:06 PM, Sapna Motwani mailto:sapana.motw...@gmail.com>> wrote: Hello Experts, Please suggest is it possible to define a self-terminating escalation. I need to run an escalation just once, and then it should disable itself. I want to know is it possible to define an escalation which triggers some workflow to mark the calling parent escalation as disable. Any help would be highly appreciated. Regards, Sapna ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org<http://www.arslist.org> "Where the Answers Are, and have been for 20 years" _ARSlist: "Where the Answers Are" and have been for 20 years_ _ARSlist: "Where the Answers Are" and have been for 20 years_ _ARSlist: "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"
Re: Self-Terminating/disabling Escalation
LJ, Although it's not a feature that I've found particularly useful, your use case sounds like a perfect candidate for an "error handler" filter. If you use one on the target form (of the push) to catch the individual errors, it should allow the whole transaction to succeed. However, there's another reason the "use a table loop to push to target entries" may not be a good idea...it's not scalable. All of the filters executed in that single run of the escalation's actions count toward the filter limit set for the system. So if the number of target entries might be or grow large, a run of this thing might hit the system limit and abort (and rollback) the entire transaction. If you use the "normal" paradigm and have the escalation running on the target form directly (instead of from a control form), each run of the escalation's actions resets the filter counter, lessening the probability of hitting the limit. -charlie On May 3, 2014 5:48 AM, "LJ LongWing" wrote: > ** > Doug/All, > I'll let you know about a 'problem' I have come across with this approach. > Unfortunately, or fortunately, depending on how you look at it, a Push > action requires that all actions on the push succeed for any to be > committed to the DB...so as long as the push encounters 0 issues, > everything is fine. If however, you are using an escalation to process > some records, lets say 100 of them...and 3 of them will generate an error. > If using a Push action from a control form, as described, the escalation > will fire, kicking off the Filter, the Filter will perform the push, it'll > hit the first record that errors out, and the entire action is rolled back, > thus leaving 100 records needing to be modified by the escalation. If > however, the Escalation was making the changes to that record directly, 97 > of the records would be successfully processed, 3 of the records would drop > an error in the arerror.log file, and you would be left with only the 3 > error records. > > Sothe two are not unfortunately 100% the same...but similar to each > other, with limitations that may or may not make the use of the control > form viable or not. > > > On Thu, May 1, 2014 at 1:13 PM, Tanner, Doug > wrote: > >> ** >> >> We use a table/form (i.e. CMN:System Variables) that has one entry with >> multiple attributes, we have a large number of escalations doing many >> different things that look at the CMN:System Variables, and then runs >> appropriate actions on appropriate tables. Works slick! Doug >> >> >> >> *From:* Action Request System discussion list(ARSList) [mailto: >> arslist@ARSLIST.ORG] *On Behalf Of *Ben Cantatore >> *Sent:* Thursday, May 01, 2014 12:18 PM >> *To:* arslist@ARSLIST.ORG >> *Subject:* Re: Self-Terminating/disabling Escalation >> >> >> >> ** Sapna, >> >> Have a flag field as part of the escalation set the flag to true. Make >> the run if qualification for the escalation run on flag equal false. That >> should ensure it only runs once. Otherwise, I'd just create an escalation, >> run it and then remove it manually. >> >> >> >> *Ben Cantatore* >> *Remedy Architect* >> Bed Bath & Beyond >> 650 Liberty Avenue >> Union NJ 07083-8130 >> Office: (908) 613-5769 >> Cell: (914) 263-6802 >> >> [image: LinkedIn] <http://www.linkedin.com/pub/ben-cantatore/3/220/9a7/> >> >> >> >> From: Sapna Motwani >> To:arslist@ARSLIST.ORG, >> Date:04/30/2014 11:58 PM >> Subject:Self-Terminating/disabling Escalation >> Sent by:"Action Request System discussion list(ARSList)" < >> arslist@ARSLIST.ORG> >> -- >> >> >> >> >> Hello Experts, >> >> Please suggest is it possible to define a self-terminating escalation. I >> need to run an escalation just once, and then it should disable itself. >> I want to know is it possible to define an escalation which triggers some >> workflow to mark the calling parent escalation as disable. >> >> Any help would be highly appreciated. >> >> Regards, >> Sapna >> >> >> ___ >> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org >> "Where the Answers Are, and have been for 20 years" >> >> "-- CONFIDENTIALITY >> NOTICE: This e-mail, and any attachments thereto, is intended only for use >> by th
Re: Self-Terminating/disabling Escalation
Short of creating an API program I bet driver.exe and a small script file can do it. https://docs.bmc.com/docs/display/public/ars81/Using+the+driver+program Jason On Thu, May 1, 2014 at 10:18 AM, Charlie Lotridge wrote: > ** > Hi Sapna, > > The bad news is that there is no workflow action that will accomplish this > for you. You could potentially try to use a SQL update (in a Direct SQL > action) to directly update the Remedy data dictionary, which would look > something like this: > > UPDATE escalation > SET enable = 0 > WHERE name = 'The Escalation Name' > > But I'd recommend against this for two reasons. First, any running AR > servers would not notice the change until they reload their data dictionary > caches. > > Second, doing this *might* cause the escalation to become invalid in that > it would no longer match the checksum (in the safeGuard column of the > escalation table). I haven't checked this and don't know offhand if the > "enable" is part of that checksum. > > The only way I can think of would be to write a small API program that > performs the action. This would immediately affect the AR server on which > it's run, but it would not propagate to any other servers until they reload > their caches (I don't know much about server groups...would other servers > in the group notice such changes and automatically reload?). > > I hope this helps. > > -charlie > > > On Wed, Apr 30, 2014 at 12:06 PM, Sapna Motwani > wrote: > >> Hello Experts, >> >> Please suggest is it possible to define a self-terminating escalation. I >> need to run an escalation just once, and then it should disable itself. >> I want to know is it possible to define an escalation which triggers some >> workflow to mark the calling parent escalation as disable. >> >> Any help would be highly appreciated. >> >> Regards, >> Sapna >> >> >> ___ >> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org >> "Where the Answers Are, and have been for 20 years" >> > > _ARSlist: "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"
Re: Self-Terminating/disabling Escalation
Cool, even better. Always good to know that something that I was told did not make it actually made it in. That makes the option I described an even cleaner match to the use case desired. Thank everyone for clarifying when I did not have the complete answer – and that is where the community comes together to help provide complete answers. Doug Mueller From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Rick Westbrock Sent: Friday, May 02, 2014 11:03 AM To: arslist@ARSLIST.ORG Subject: Re: Self-Terminating/disabling Escalation ** I think that was in place as of version 7.6.04 since I remember right-clicking to run an escalation last year (but maybe my memory is faulty, I don’t have a 7.6.04 system to reference now). -Rick _ Rick Westbrock Remedy Administrator | IT Department 24 Hour Fitness USA, Inc. From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of LJ LongWing Sent: Friday, May 02, 2014 9:18 AM To: arslist@ARSLIST.ORG<mailto:arslist@ARSLIST.ORG> Subject: Re: Self-Terminating/disabling Escalation ** Doug, I hate to contradict you, but, if you right click on any escalation, the bottom option is 'Run Now'so, at least in the 8.1 version of the Dev Studio, there is a GUI option that enables this. On Thu, May 1, 2014 at 1:22 PM, Mueller, Doug mailto:doug_muel...@bmc.com>> wrote: ** OK, good news and bad news…… The best way to do this is to create an escalation that is disabled. Then, tell it to run one time. Well, that seems to be perfect and just what you asked for. So, how do you do this??? Well, that is the bad news. While we do have the exact functionality, we have not made it easy for you to get to. You can create an escalation and it can be disabled. NO problem there. Now, there is way using an API call to say to run ANY escalation (enabled or disabled) ONE TIME RIGHT NOW. So, this is good news. The bad news is that we have not exposed a way to call that API call from Dev Studio. This means you have to call it from an API program or use the driver sample program we ship to cause it to run. Using driver, you can create a small script that performs the login, runs the escalation, and terminates and pass the escalation name in as a parameter. Then, you could just run that script directly (or through workflow) to perform the operation. A good enhancement request is to have the ability to say to "run now" for an escalation exposed through dev studio. Other than this feature, you have to enable it so that it triggers and runs and then disable it so that it does not run again. There is no other way to manage this. Doug Mueller From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG<mailto:arslist@ARSLIST.ORG>] On Behalf Of Charlie Lotridge Sent: Thursday, May 01, 2014 10:18 AM To: arslist@ARSLIST.ORG<mailto:arslist@ARSLIST.ORG> Subject: Re: Self-Terminating/disabling Escalation ** Hi Sapna, The bad news is that there is no workflow action that will accomplish this for you. You could potentially try to use a SQL update (in a Direct SQL action) to directly update the Remedy data dictionary, which would look something like this: UPDATE escalation SET enable = 0 WHERE name = 'The Escalation Name' But I'd recommend against this for two reasons. First, any running AR servers would not notice the change until they reload their data dictionary caches. Second, doing this *might* cause the escalation to become invalid in that it would no longer match the checksum (in the safeGuard column of the escalation table). I haven't checked this and don't know offhand if the "enable" is part of that checksum. The only way I can think of would be to write a small API program that performs the action. This would immediately affect the AR server on which it's run, but it would not propagate to any other servers until they reload their caches (I don't know much about server groups...would other servers in the group notice such changes and automatically reload?). I hope this helps. -charlie On Wed, Apr 30, 2014 at 12:06 PM, Sapna Motwani mailto:sapana.motw...@gmail.com>> wrote: Hello Experts, Please suggest is it possible to define a self-terminating escalation. I need to run an escalation just once, and then it should disable itself. I want to know is it possible to define an escalation which triggers some workflow to mark the calling parent escalation as disable. Any help would be highly appreciated. Regards, Sapna ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org<http://www.arslist.org> "Where the Answers Are, and have been for 20 years" _ARSlist: "Where the Answers Are" and have been for 20 years_ _AR
Re: Self-Terminating/disabling Escalation
Doug, I hate to contradict you, but, if you right click on any escalation, the bottom option is 'Run Now'so, at least in the 8.1 version of the Dev Studio, there is a GUI option that enables this. On Thu, May 1, 2014 at 1:22 PM, Mueller, Doug wrote: > ** > > OK, good news and bad news…… > > > > The best way to do this is to create an escalation that is disabled. > Then, tell it to run one time. > > > > Well, that seems to be perfect and just what you asked for. So, how do > you do this??? > > > > Well, that is the bad news. While we do have the exact functionality, we > have not made it easy for you to > > get to. > > > > You can create an escalation and it can be disabled. NO problem there. > > > > Now, there is way using an API call to say to run ANY escalation (enabled > or disabled) ONE TIME RIGHT NOW. > > So, this is good news. > > > > The bad news is that we have not exposed a way to call that API call from > Dev Studio. This means you have > > to call it from an API program or use the driver sample program we ship to > cause it to run. > > > > Using driver, you can create a small script that performs the login, runs > the escalation, and terminates and pass > > the escalation name in as a parameter. Then, you could just run that > script directly (or through workflow) to > > perform the operation. A good enhancement request is to have the ability > to say to "run now" for an > > escalation exposed through dev studio. > > > > > > Other than this feature, you have to enable it so that it triggers and > runs and then disable it so that it does not > > run again. There is no other way to manage this. > > > > Doug Mueller > > > > *From:* Action Request System discussion list(ARSList) [mailto: > arslist@ARSLIST.ORG] *On Behalf Of *Charlie Lotridge > *Sent:* Thursday, May 01, 2014 10:18 AM > > *To:* arslist@ARSLIST.ORG > *Subject:* Re: Self-Terminating/disabling Escalation > > > > ** > > Hi Sapna, > > > > The bad news is that there is no workflow action that will accomplish this > for you. You could potentially try to use a SQL update (in a Direct SQL > action) to directly update the Remedy data dictionary, which would look > something like this: > > > > UPDATE escalation > > SET enable = 0 > > WHERE name = 'The Escalation Name' > > > > But I'd recommend against this for two reasons. First, any running AR > servers would not notice the change until they reload their data dictionary > caches. > > > > Second, doing this *might* cause the escalation to become invalid in that > it would no longer match the checksum (in the safeGuard column of the > escalation table). I haven't checked this and don't know offhand if the > "enable" is part of that checksum. > > > > The only way I can think of would be to write a small API program that > performs the action. This would immediately affect the AR server on which > it's run, but it would not propagate to any other servers until they reload > their caches (I don't know much about server groups...would other servers > in the group notice such changes and automatically reload?). > > > > I hope this helps. > > > > -charlie > > > > On Wed, Apr 30, 2014 at 12:06 PM, Sapna Motwani > wrote: > > Hello Experts, > > Please suggest is it possible to define a self-terminating escalation. I > need to run an escalation just once, and then it should disable itself. > I want to know is it possible to define an escalation which triggers some > workflow to mark the calling parent escalation as disable. > > Any help would be highly appreciated. > > Regards, > Sapna > > > ___ > UNSUBSCRIBE or access ARSlist Archives at www.arslist.org > "Where the Answers Are, and have been for 20 years" > > > > _ARSlist: "Where the Answers Are" and have been for 20 years_ > _ARSlist: "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"
Re: Self-Terminating/disabling Escalation
Hi Sapna, The bad news is that there is no workflow action that will accomplish this for you. You could potentially try to use a SQL update (in a Direct SQL action) to directly update the Remedy data dictionary, which would look something like this: UPDATE escalation SET enable = 0 WHERE name = 'The Escalation Name' But I'd recommend against this for two reasons. First, any running AR servers would not notice the change until they reload their data dictionary caches. Second, doing this *might* cause the escalation to become invalid in that it would no longer match the checksum (in the safeGuard column of the escalation table). I haven't checked this and don't know offhand if the "enable" is part of that checksum. The only way I can think of would be to write a small API program that performs the action. This would immediately affect the AR server on which it's run, but it would not propagate to any other servers until they reload their caches (I don't know much about server groups...would other servers in the group notice such changes and automatically reload?). I hope this helps. -charlie On Wed, Apr 30, 2014 at 12:06 PM, Sapna Motwani wrote: > Hello Experts, > > Please suggest is it possible to define a self-terminating escalation. I > need to run an escalation just once, and then it should disable itself. > I want to know is it possible to define an escalation which triggers some > workflow to mark the calling parent escalation as disable. > > Any help would be highly appreciated. > > Regards, > Sapna > > > ___ > 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"
Re: Self-Terminating/disabling Escalation
Doug, “ A good enhancement request is to have the ability to say to "run now" for an escalation exposed through dev studio.” This is already available…. In Dev Studio v8.1, why can’t one just right-click and say “Run Now”? We’ve used this during a migration for a one time update. [cid:image001.png@01CF6578.69A73380] Thank you, Michelle From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Mueller, Doug Sent: Thursday, May 01, 2014 2:22 PM To: arslist@ARSLIST.ORG Subject: Re: Self-Terminating/disabling Escalation ** OK, good news and bad news…… The best way to do this is to create an escalation that is disabled. Then, tell it to run one time. Well, that seems to be perfect and just what you asked for. So, how do you do this??? Well, that is the bad news. While we do have the exact functionality, we have not made it easy for you to get to. You can create an escalation and it can be disabled. NO problem there. Now, there is way using an API call to say to run ANY escalation (enabled or disabled) ONE TIME RIGHT NOW. So, this is good news. The bad news is that we have not exposed a way to call that API call from Dev Studio. This means you have to call it from an API program or use the driver sample program we ship to cause it to run. Using driver, you can create a small script that performs the login, runs the escalation, and terminates and pass the escalation name in as a parameter. Then, you could just run that script directly (or through workflow) to perform the operation. A good enhancement request is to have the ability to say to "run now" for an escalation exposed through dev studio. Other than this feature, you have to enable it so that it triggers and runs and then disable it so that it does not run again. There is no other way to manage this. Doug Mueller From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Charlie Lotridge Sent: Thursday, May 01, 2014 10:18 AM To: arslist@ARSLIST.ORG<mailto:arslist@ARSLIST.ORG> Subject: Re: Self-Terminating/disabling Escalation ** Hi Sapna, The bad news is that there is no workflow action that will accomplish this for you. You could potentially try to use a SQL update (in a Direct SQL action) to directly update the Remedy data dictionary, which would look something like this: UPDATE escalation SET enable = 0 WHERE name = 'The Escalation Name' But I'd recommend against this for two reasons. First, any running AR servers would not notice the change until they reload their data dictionary caches. Second, doing this *might* cause the escalation to become invalid in that it would no longer match the checksum (in the safeGuard column of the escalation table). I haven't checked this and don't know offhand if the "enable" is part of that checksum. The only way I can think of would be to write a small API program that performs the action. This would immediately affect the AR server on which it's run, but it would not propagate to any other servers until they reload their caches (I don't know much about server groups...would other servers in the group notice such changes and automatically reload?). I hope this helps. -charlie On Wed, Apr 30, 2014 at 12:06 PM, Sapna Motwani mailto:sapana.motw...@gmail.com>> wrote: Hello Experts, Please suggest is it possible to define a self-terminating escalation. I need to run an escalation just once, and then it should disable itself. I want to know is it possible to define an escalation which triggers some workflow to mark the calling parent escalation as disable. Any help would be highly appreciated. Regards, Sapna ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org<http://www.arslist.org> "Where the Answers Are, and have been for 20 years" _ARSlist: "Where the Answers Are" and have been for 20 years_ _ARSlist: "Where the Answers Are" and have been for 20 years_ -- This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.bankofamerica.com/emaildisclaimer. If you are not the intended recipient, please delete this message. ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
Re: Self-Terminating/disabling Escalation
We use a table/form (i.e. CMN:System Variables) that has one entry with multiple attributes, we have a large number of escalations doing many different things that look at the CMN:System Variables, and then runs appropriate actions on appropriate tables. Works slick! Doug From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Ben Cantatore Sent: Thursday, May 01, 2014 12:18 PM To: arslist@ARSLIST.ORG Subject: Re: Self-Terminating/disabling Escalation ** Sapna, Have a flag field as part of the escalation set the flag to true. Make the run if qualification for the escalation run on flag equal false. That should ensure it only runs once. Otherwise, I'd just create an escalation, run it and then remove it manually. [cid:image001.png@01CF654F.F2408490] Ben Cantatore Remedy Architect Bed Bath & Beyond 650 Liberty Avenue Union NJ 07083-8130 Office: (908) 613-5769 Cell: (914) 263-6802 [LinkedIn] From:Sapna Motwani mailto:sapana.motw...@gmail.com>> To:arslist@ARSLIST.ORG<mailto:arslist@ARSLIST.ORG>, Date:04/30/2014 11:58 PM Subject:Self-Terminating/disabling Escalation Sent by:"Action Request System discussion list(ARSList)" mailto:arslist@ARSLIST.ORG>> Hello Experts, Please suggest is it possible to define a self-terminating escalation. I need to run an escalation just once, and then it should disable itself. I want to know is it possible to define an escalation which triggers some workflow to mark the calling parent escalation as disable. Any help would be highly appreciated. Regards, Sapna ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years" "-- CONFIDENTIALITY NOTICE: This e-mail, and any attachments thereto, is intended only for use by the addressee(s) named herein and may contain confidential information. If you are not the intended recipient of this e-mail, you are hereby notified that any dissemination, distribution or copying of this e-mail, and any attachments thereto, is strictly prohibited. If you have received this e-mail in error, please permanently delete the original and any copy of any e-mail and any printout thereof. Thank you for your compliance." _ARSlist: "Where the Answers Are" and have been for 20 years_ This email is subject to certain disclaimers, which may be reviewed via the following link. http://compass-usa.com/Pages/Disclaimer.aspx. ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
Re: Self-Terminating/disabling Escalation
OK, good news and bad news…… The best way to do this is to create an escalation that is disabled. Then, tell it to run one time. Well, that seems to be perfect and just what you asked for. So, how do you do this??? Well, that is the bad news. While we do have the exact functionality, we have not made it easy for you to get to. You can create an escalation and it can be disabled. NO problem there. Now, there is way using an API call to say to run ANY escalation (enabled or disabled) ONE TIME RIGHT NOW. So, this is good news. The bad news is that we have not exposed a way to call that API call from Dev Studio. This means you have to call it from an API program or use the driver sample program we ship to cause it to run. Using driver, you can create a small script that performs the login, runs the escalation, and terminates and pass the escalation name in as a parameter. Then, you could just run that script directly (or through workflow) to perform the operation. A good enhancement request is to have the ability to say to "run now" for an escalation exposed through dev studio. Other than this feature, you have to enable it so that it triggers and runs and then disable it so that it does not run again. There is no other way to manage this. Doug Mueller From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Charlie Lotridge Sent: Thursday, May 01, 2014 10:18 AM To: arslist@ARSLIST.ORG Subject: Re: Self-Terminating/disabling Escalation ** Hi Sapna, The bad news is that there is no workflow action that will accomplish this for you. You could potentially try to use a SQL update (in a Direct SQL action) to directly update the Remedy data dictionary, which would look something like this: UPDATE escalation SET enable = 0 WHERE name = 'The Escalation Name' But I'd recommend against this for two reasons. First, any running AR servers would not notice the change until they reload their data dictionary caches. Second, doing this *might* cause the escalation to become invalid in that it would no longer match the checksum (in the safeGuard column of the escalation table). I haven't checked this and don't know offhand if the "enable" is part of that checksum. The only way I can think of would be to write a small API program that performs the action. This would immediately affect the AR server on which it's run, but it would not propagate to any other servers until they reload their caches (I don't know much about server groups...would other servers in the group notice such changes and automatically reload?). I hope this helps. -charlie On Wed, Apr 30, 2014 at 12:06 PM, Sapna Motwani mailto:sapana.motw...@gmail.com>> wrote: Hello Experts, Please suggest is it possible to define a self-terminating escalation. I need to run an escalation just once, and then it should disable itself. I want to know is it possible to define an escalation which triggers some workflow to mark the calling parent escalation as disable. Any help would be highly appreciated. Regards, Sapna ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org<http://www.arslist.org> "Where the Answers Are, and have been for 20 years" _ARSlist: "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"
Re: Self-Terminating/disabling Escalation
Sapna You can create a form with the workflow (filters) actions you want to accomplish on you primary form This form will act as you trigger Set you Escalation to run on this trigger form. The Escalation can have a Run If Qualification of something like 'Status' = "Active" Then have part of the escalation action change the 'Status' to "In-Active" The Escalation continues to run on its set interval but finds no entries to match its Qualification Alternatively, you can have a couple escalations to change the trigger entry Status (1 to Activate, 1 to Deactivate) This allows you to setup a window of time where the trigger can be active on a reoccurring basis. Gregory Givens CTR NPC Remedy Admin -Original Message- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Sapna Motwani Sent: Wednesday, April 30, 2014 2:06 PM To: arslist@ARSLIST.ORG Subject: Self-Terminating/disabling Escalation Hello Experts, Please suggest is it possible to define a self-terminating escalation. I need to run an escalation just once, and then it should disable itself. I want to know is it possible to define an escalation which triggers some workflow to mark the calling parent escalation as disable. Any help would be highly appreciated. Regards, Sapna ___ 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"
Re: EXTERNAL: Re: Self-Terminating/disabling Escalation
Or Set it up to run every 99 days like Rick said and add AND $DATE$ = "05/01/2014" to your run if. It will run immediately today and by tomorrow the DATE check will be false. Since it only gets run every 99 days there is little impact on the system except to check the escalation and verify that it's counter has not expired and when it does expire the run If is still false. But I would still go back in and clean it up manually. Either disabling it or deleting it. Thank you, --- John J. Reiser Remedy Developer/Administrator Senior Software Development Analyst Lockheed Martin - MS2 The star that burns twice as bright burns half as long. Pay close attention and be illuminated by its brilliance. - paraphrased by me -Original Message- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Rick Westbrock Sent: Thursday, May 01, 2014 11:13 AM To: arslist@ARSLIST.ORG Subject: EXTERNAL: Re: Self-Terminating/disabling Escalation I don't know of a way to do that. When I need to have an escalation run only once I will either set it for an interval of 99 days (if I want it to run immediately) or for a specific day of the month and time. In either case you must go back and disable the escalation but that will give you 99 days or one month respectively to do so before it fires again. -Rick ___ 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"
Re: Self-Terminating/disabling Escalation
I don't know of a way to do that. When I need to have an escalation run only once I will either set it for an interval of 99 days (if I want it to run immediately) or for a specific day of the month and time. In either case you must go back and disable the escalation but that will give you 99 days or one month respectively to do so before it fires again. -Rick ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
Re: Self-Terminating/disabling Escalation
Sapna, Have a flag field as part of the escalation set the flag to true. Make the run if qualification for the escalation run on flag equal false. That should ensure it only runs once. Otherwise, I'd just create an escalation, run it and then remove it manually. Ben Cantatore Remedy Architect Bed Bath & Beyond 650 Liberty Avenue Union NJ 07083-8130 Office: (908) 613-5769 Cell: (914) 263-6802 From: Sapna Motwani To: arslist@ARSLIST.ORG, Date: 04/30/2014 11:58 PM Subject:Self-Terminating/disabling Escalation Sent by:"Action Request System discussion list(ARSList)" Hello Experts, Please suggest is it possible to define a self-terminating escalation. I need to run an escalation just once, and then it should disable itself. I want to know is it possible to define an escalation which triggers some workflow to mark the calling parent escalation as disable. Any help would be highly appreciated. Regards, Sapna ___ 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"
Self-Terminating/disabling Escalation
Hello Experts, Please suggest is it possible to define a self-terminating escalation. I need to run an escalation just once, and then it should disable itself. I want to know is it possible to define an escalation which triggers some workflow to mark the calling parent escalation as disable. Any help would be highly appreciated. Regards, Sapna ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
Re: due to escalation some text lines adding in arerror log
Well...the main problem is that that Run-Process is a client side (Active Link) run process, and shouldn't be in a filter/escalationso wherever you happen to have it should be removed. On Wed, Feb 12, 2014 at 6:57 AM, Sandeep Pandey wrote: > ** > Dear Team, > > There is one escalation running on so and so time and having two actions > (set change flag and process) running perfectly. However I getting below > lines added in arerror log for each records escalation qualification is > passing. > > Sun Feb 09 01:25:01 2014 390603 : Failure while trying to run the > filter/escalation process (ARERR 24) > Sun Feb 09 01:25:01 2014 SET-CHANGE-FLAG 0 > > Could you please suggest what is the problem? > > Regards, > Sandy > _ARSlist: "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"
due to escalation some text lines adding in arerror log
Dear Team, There is one escalation running on so and so time and having two actions (set change flag and process) running perfectly. However I getting below lines added in arerror log for each records escalation qualification is passing. Sun Feb 09 01:25:01 2014 390603 : Failure while trying to run the filter/escalation process (ARERR 24) Sun Feb 09 01:25:01 2014 SET-CHANGE-FLAG 0 Could you please suggest what is the problem? Regards, Sandy ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
