Re: Complimentary Webinar: Maximise Availability of your Business Applications and Databases
PedantryMode Complimentary? What you mean that you browse to the webinar and get a message saying Wow! You're looking good today! What a great browser. You're smooth... Or do you mean complementary? I.e. It's free. /PedantryMode ;-) Gavin Coleman Senior Analyst/Programmer Computacenter (UK) Ltd Services Solutions Hatfield Avenue Hatfield, Hertfordshire, AL10 9TW, United Kingdom T: +44 (0) 1707 631662 E: gavin.cole...@computacenter.commailto:gavin.cole...@computacenter.com W: www.computacenter.comhttp://www.computacenter.com From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of shomit.di...@vyomlabs.com Sent: 08 December 2011 06:53 To: arslist@ARSLIST.ORG Subject: Re: Complimentary Webinar: Maximise Availability of your Business Applications and Databases ** Dear ARSListers, We at Vyom Labs have scheduled a free webinar on Maximise Availability of your Business Applications and Databases. Topic: Maximise Availability of your Business Applications and Databases Day / Date: Wednesday ,14th Dec, 2011 Time: 7:00 pm - 8:00 pm IST [Check Local Timehttp://www.worldtimeserver.com/convert_time_in_IN.aspx?y=2011mo=12d=14h=19mn=0] Register Here: https://www1.gotomeeting.com/register/542506584 CIOs and IT Managers of Small and Medium size enterprises are constantly under pressure for doing more with less. They need to work towards meeting expectations of business from IT while constantly keeping the budget of IT low. ITIL good practices and Remote Infrastructure Management services can be handy for the small and medium enterprises. This webinar goes into explaining how ITIL can be used in SME setup, how automation and engagement model with service providers will help. AGENDA * ITIL for SMBs * 4Ps - People, Process, Product and Partner * How to minimize cost and increase availability of IT? * Case Study: Increased Availability of databases and business applications in medium size enterprise Feel free to share this webinar details with your Followers / Group Members / Friends Colleagues. -- Warm Regards, Shomit Mitra Vyom Labs Pvt. Ltd. IT Infrastructure Management | Solutions Services Email: i...@vyomlabs.commailto:i...@vyomlabs.com Web Site: www.vyomlabs.comhttp://www.vyomlabs.com/ _attend WWRUG12 www.wwrug.com ARSlist: Where the Answers Are_ ** COMPUTACENTER PLC is registered in England and Wales with the registered number 03110569. Its registered office is at Hatfield Business Park, Hatfield Avenue, Hatfield, Hertfordshire AL10 9TW COMPUTACENTER (UK) Limited is registered in England and Wales with the registered number 01584718. Its registered office is at Hatfield Business Park, Hatfield Avenue, Hatfield, Hertfordshire AL10 9TW COMPUTACENTER (Mid-Market) Limited is registered in England and Wales with the registered number 3434654. Its registered office is at Hatfield Business Park, Hatfield Avenue, Hatfield, Hertfordshire AL10 9TW COMPUTACENTER (FMS) Limited is registered in England and Wales with the registered number 3798091. Its registered office is at Hatfield Business Park, Hatfield Avenue, Hatfield, Hertfordshire AL10 9TW The contents of this email are intended for the named addressee only. It contains information which may be confidential and which may also be privileged. Unless you are the named addressee (or authorised to receive mail for the addressee) you may not copy or use it, or disclose it to anyone else. If you receive it in error please notify us immediately and then destroy it. Computacenter information is available from: http://www.computacenter.com ** ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: Where the Answers Are
Re: Midtier Internal Error
Fred, I think you are onto something. For some reason the Advanced Search bar did not come over when I moved my form over to ARS 7.6.04 SP2. AND the search checkbox is no longer checked. We are a custom shop, so I'm working in Base Mode and this is a custom form. I always make it a point (whether it's a new form or workflow, or already existing forms and workflow) to select Replace Objects on the Destination Server and then I check Delete Excess Fields and Delete Excess Views. I wonder if that had something to do with it. I'm going to test it out You are the best! I'm going to add these items and see if it works, but I bet it does Thanks! Lisa From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Grooms, Frederick W Sent: Wednesday, December 07, 2011 3:03 PM To: arslist@ARSLIST.ORG Subject: Re: Midtier Internal Error ** I hate to ask this, but is the Search bar a field on your form (under Form - Add Action Fields)? Fred From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Kemes, Lisa Sent: Wednesday, December 07, 2011 10:25 AM To: arslist@ARSLIST.ORG Subject: Re: Midtier Internal Error ** Just one more piece of info, this error does not pop up at all on the User Client (no matter what ARS)... Thanks! Lisa From: Kemes, Lisa Sent: Wednesday, December 07, 2011 11:24 AM To: 'arslist@ARSLIST.ORG' Subject: Midtier Internal Error Testing out my new ARS server (7.6.04 sp2) and Mid Tier (7.6.04) and a particular Active Link action is giving me an Internal Error All the active link is doing is executing on a Search and setting the advanced Search Bar field to a value. This works with ARS 7.1 p7 with Midteir 7.6.04, but NOT with ARS 7.1 p7 with Midtier 7.6.04 P1. (also does not work with ARS 7.6.04 sp2 and Midtier 7.6.04 as I said in the beginning). I get the Internal Error 9215. They list what the error means (which is an All Purpose error) and I THINK it's might be because of Failure to set a field in the Set Field workflow action at runtime possibly. This is where the error pops up anyway (right after the Active Link is started, but the Advanced Search Bar field never gets set). Should I upgrade to Midtier 7.6.04 p2 with my ARS 7.6.04 p2 before I create a ticket with BMC? Lisa Kemes AR System Developer TEIS - USA +1 717 810 2408 tel +1 717 602 9460 mobile lisa.ke...@te.commailto:lisa.ke...@te.com 100 Amp Drive Harrisburg, PA 17112 [http://www.te.com/images/socialmedia/smallTElogo.gif]http://www.te.com/ www.te.comhttp://www.te.com/ [http://www.te.com/images/socialmedia/twitter.png]http://twitter.com/teconnectivity[http://www.te.com/images/socialmedia/facebook.png]http://www.facebook.com/teconnectivity[http://www.te.com/images/socialmedia/flickr.png]http://www.flickr.com/photos/teconnectivity/[http://www.te.com/images/socialmedia/linkedin.png]http://www.linkedin.com/groups?gid=1591657[http://www.te.com/images/socialmedia/youtube.png]http://www.youtube.com/teconnectivity _attend WWRUG12 www.wwrug.com ARSlist: Where the Answers Are_ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: Where the Answers Are
Re: Search Work Info on a change
Have the User open a CRQ (must have a record selected, not just a blank Search) and then under the Advanced section of the NavBar Select Advanced Search. You will be prompted for Search by Work Information and Search by Relationships. From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Peters, Ron Sent: Wednesday, December 07, 2011 3:00 PM To: arslist@ARSLIST.ORG Subject: Search Work Info on a change ** I have a user who needs to search for a term in change work info entries across a group of changes. I didn't see anything in the stock interface but in the thick client I found a join form called Search Work Info CHG:Chg Search-Worklog. It seems to be what I'm looking for but the user doesn't see it when looking for the form in their thick client. I figured this is some sort of permission issue - duh. I looked at the form in the developer tool and the only permission on the form was Public read-only. So it's obvious that I don't fully grok the permissions. What is the proper process to allow the user to see/use this form? Should I do something to the form? Or user roles/permissions? Or ??? Thanks again. _attend WWRUG12 www.wwrug.comhttp://www.wwrug.com ARSlist: Where the Answers Are_ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: Where the Answers Are
need Blade Logic Training in the Chicago area
Well, we've had our second blade logic class cancelled in the Chicago area in the last 30 days. Dev Tech is looking to find a BL instructor in the greater chicago area to train one of our individuals.We will pay up to what we had planned to pay for the BMC training. 19-22 dec works best. mike ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: Where the Answers Are
Application-Query-Delete-Entry
Hello Listers,
I'm trying to learn how to delete records that are past and the End Date
is more than 6 months prior to todays date. I built the escalation and
when I run it nothing happens. Can someone point in the right
directions with the Run Process syntax.
I'm using SQL 2008 and Windows 2008. ITSM is 7.5
The form I'm deleting from is: AP:Alternate
Run IF Qualification is:'Status' = Past (also tried without
setting a Run If Qualification)
Run Process is:Application-Query-Delete-Entry AP:Alternate
('Status' = Past) and ($End Date$ ($TIMESTAMP$ - (86400 * 180)))
I have also tried:Application-Query-Delete-Entry AP:Alternate
('Status' = Past) and ($End Date$ ($DATE$ - (86400 * 180)))
Thanks in advance for your time,
Larry B
___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
attend wwrug12 www.wwrug12.com ARSList: Where the Answers Are
Re: Application-Query-Delete-Entry
Try
Run Process is:Application-Query-Delete-Entry AP:Alternate ('Status' =
Past) and ('End Date' ($TIMESTAMP$ - (86400 * 180)))
'End Date' is the field on the form like 'Status'.
___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
attend wwrug12 www.wwrug12.com ARSList: Where the Answers Are
Re: Unable to open a form in modify mode when a form is maximized
Alright, I managed a fix to my issue. Since the form wouldn't open in a modify window (it does open in a new window) I tried opening in a search window. This works. I open the windows with the values I want to search on plus a flag that the active link uses in the Run If so that the action won't happen on every instance the window is loaded, First action is to null that field so it won't be included in the search, then a Commit Change action to do the search. Voila! I have my open tickets! ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: Where the Answers Are
Re: Midtier Internal Error
This did not work. Advanced Search is on my form now on 7.6.04 p2 and I'm still getting Internal Error. Not to mention (I forgot) that I'm also getting this on my old dev server 7.1 p7 as well. 7.6.04 p2 is pointing to 7.6.04 midtier and 7.1 p7 is pointing to 7.6.04 p1 server. (getting internal error) 7.1 p7 pointing to 7.6.04 midtier seems to be working. Still researching. Thanks! Lisa From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Kemes, Lisa Sent: Thursday, December 08, 2011 8:58 AM To: arslist@ARSLIST.ORG Subject: Re: Midtier Internal Error ** Fred, I think you are onto something. For some reason the Advanced Search bar did not come over when I moved my form over to ARS 7.6.04 SP2. AND the search checkbox is no longer checked. We are a custom shop, so I'm working in Base Mode and this is a custom form. I always make it a point (whether it's a new form or workflow, or already existing forms and workflow) to select Replace Objects on the Destination Server and then I check Delete Excess Fields and Delete Excess Views. I wonder if that had something to do with it. I'm going to test it out You are the best! I'm going to add these items and see if it works, but I bet it does Thanks! Lisa From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Grooms, Frederick W Sent: Wednesday, December 07, 2011 3:03 PM To: arslist@ARSLIST.ORG Subject: Re: Midtier Internal Error ** I hate to ask this, but is the Search bar a field on your form (under Form - Add Action Fields)? Fred From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Kemes, Lisa Sent: Wednesday, December 07, 2011 10:25 AM To: arslist@ARSLIST.ORG Subject: Re: Midtier Internal Error ** Just one more piece of info, this error does not pop up at all on the User Client (no matter what ARS)... Thanks! Lisa From: Kemes, Lisa Sent: Wednesday, December 07, 2011 11:24 AM To: 'arslist@ARSLIST.ORG' Subject: Midtier Internal Error Testing out my new ARS server (7.6.04 sp2) and Mid Tier (7.6.04) and a particular Active Link action is giving me an Internal Error All the active link is doing is executing on a Search and setting the advanced Search Bar field to a value. This works with ARS 7.1 p7 with Midteir 7.6.04, but NOT with ARS 7.1 p7 with Midtier 7.6.04 P1. (also does not work with ARS 7.6.04 sp2 and Midtier 7.6.04 as I said in the beginning). I get the Internal Error 9215. They list what the error means (which is an All Purpose error) and I THINK it's might be because of Failure to set a field in the Set Field workflow action at runtime possibly. This is where the error pops up anyway (right after the Active Link is started, but the Advanced Search Bar field never gets set). Should I upgrade to Midtier 7.6.04 p2 with my ARS 7.6.04 p2 before I create a ticket with BMC? Lisa Kemes AR System Developer TEIS - USA +1 717 810 2408 tel +1 717 602 9460 mobile lisa.ke...@te.commailto:lisa.ke...@te.com 100 Amp Drive Harrisburg, PA 17112 [http://www.te.com/images/socialmedia/smallTElogo.gif]http://www.te.com/ www.te.comhttp://www.te.com/ [http://www.te.com/images/socialmedia/twitter.png]http://twitter.com/teconnectivity[http://www.te.com/images/socialmedia/facebook.png]http://www.facebook.com/teconnectivity[http://www.te.com/images/socialmedia/flickr.png]http://www.flickr.com/photos/teconnectivity/[http://www.te.com/images/socialmedia/linkedin.png]http://www.linkedin.com/groups?gid=1591657[http://www.te.com/images/socialmedia/youtube.png]http://www.youtube.com/teconnectivity _attend WWRUG12 www.wwrug.com ARSlist: Where the Answers Are_ _attend WWRUG12 www.wwrug.com ARSlist: Where the Answers Are_ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: Where the Answers Are
Re: Application-Query-Delete-Entry
End Date as Linda pointed out should be a field on that form you are
searching for, represented by 'End Date' in the qualification and not $End
Date$..
That being said, LJ's suggestion is right..
The qualification should be in the Run If of the Escalation and the run
process should be
Application-Delete-Entry $SCHEMA$ $Request ID$
Having an Escalation with no Run If instructs it to be run over the entire
data table. You do not want to do that in case you have like a million or
more records in it.. It may probably hang the escalation thread waiting for
it to complete..
Also a faster way to do it would be to 'mark that entry for deletion' using
a tag on a field created for that. This would mean that the Escalation would
do a single update to that table which is a faster operation that multiple
deletes and be done with it.. Create a filter that runs if the $USER$ is
AR_ESCALATOR and the flag for delete is set, to delete that entry. So on a
fairly large set of data, although the deletes are still potentially
happening triggered by that filter, the escalation thread has already
finished processing the escalation and is ready to take on a new job..
Joe
-Original Message-
From: LJ LongWing
Sent: Thursday, December 08, 2011 12:54 PM Newsgroups:
public.remedy.arsystem.general
To: arslist@ARSLIST.ORG
Subject: Re: Application-Query-Delete-Entry
Larry,
Your approach is a bit ‘off’. An escalation performs a search that matches
your qualification, and then performs your action on ALL records that match
that qualification. So in this case, I would expect your run-if
qualification to be
('Status' = Past) and ($End Date$ ($TIMESTAMP$ - (86400 * 180)))
Or, whatever qual you want to identify your specific records,
Then, from there, you will be modifying ‘that’ record…so you wouldn’t want
to then perform an Application-Query-Delete-Entry, you could simply perform
an
Application-Delete-Entry $SCHEMA$ $Request ID$
From: Action Request System discussion list(ARSList)
[mailto:arslist@ARSLIST.ORG] On Behalf Of Larry Barnes
Sent: Thursday, December 08, 2011 10:23 AM
To: arslist@ARSLIST.ORG
Subject: Application-Query-Delete-Entry
**
Hello Listers,
I'm trying to learn how to delete records that are past and the End Date is
more than 6 months prior to todays date. I built the escalation and when I
run it nothing happens. Can someone point in the right directions with the
Run Process syntax.
I'm using SQL 2008 and Windows 2008. ITSM is 7.5
The form I'm deleting from is: AP:Alternate
Run IF Qualification is:'Status' = Past (also tried without setting
a Run If Qualification)
Run Process is:Application-Query-Delete-Entry AP:Alternate ('Status' =
Past) and ($End Date$ ($TIMESTAMP$ - (86400 * 180)))
I have also tried:Application-Query-Delete-Entry AP:Alternate
('Status' = Past) and ($End Date$ ($DATE$ - (86400 * 180)))
Thanks in advance for your time,
Larry B
_attend WWRUG12 www.wwrug.com ARSlist: Where the Answers Are_
___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
attend wwrug12 www.wwrug12.com ARSList: Where the Answers Are
___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
attend wwrug12 www.wwrug12.com ARSList: Where the Answers Are
Re: Application-Query-Delete-Entry
Joe,
I know this discussion comes up every once in awhilebut you and I seem to
differ in our opinions of how it works.
So...based on your statement below, having the escalation set a field, and
having a filter fire on that field being set, then performing the delete will
be 'faster' because of a 'fire and forget' type of mechanism?
I would argue that an action of delete within the escalation, and a setfield
causing a filter to fire that causes the delete are 'the same', in that the
escalation thread does not 'go onto the next record' till after the filters on
the current record are done...so, in essence, the performance of either action
would be the same and the escalation thread would still be tied up for exactly
the same amount of time regardless
At least, that's my understanding :)
-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:arslist@ARSLIST.ORG] On Behalf Of Joe Martin D'Souza
Sent: Thursday, December 08, 2011 11:33 AM
To: arslist@ARSLIST.ORG
Subject: Re: Application-Query-Delete-Entry
End Date as Linda pointed out should be a field on that form you are
searching for, represented by 'End Date' in the qualification and not $End
Date$..
That being said, LJ's suggestion is right..
The qualification should be in the Run If of the Escalation and the run
process should be
Application-Delete-Entry $SCHEMA$ $Request ID$
Having an Escalation with no Run If instructs it to be run over the entire
data table. You do not want to do that in case you have like a million or
more records in it.. It may probably hang the escalation thread waiting for
it to complete..
Also a faster way to do it would be to 'mark that entry for deletion' using
a tag on a field created for that. This would mean that the Escalation would
do a single update to that table which is a faster operation that multiple
deletes and be done with it.. Create a filter that runs if the $USER$ is
AR_ESCALATOR and the flag for delete is set, to delete that entry. So on a
fairly large set of data, although the deletes are still potentially
happening triggered by that filter, the escalation thread has already
finished processing the escalation and is ready to take on a new job..
Joe
-Original Message-
From: LJ LongWing
Sent: Thursday, December 08, 2011 12:54 PM Newsgroups:
public.remedy.arsystem.general
To: arslist@ARSLIST.ORG
Subject: Re: Application-Query-Delete-Entry
Larry,
Your approach is a bit ‘off’. An escalation performs a search that matches
your qualification, and then performs your action on ALL records that match
that qualification. So in this case, I would expect your run-if
qualification to be
('Status' = Past) and ($End Date$ ($TIMESTAMP$ - (86400 * 180)))
Or, whatever qual you want to identify your specific records,
Then, from there, you will be modifying ‘that’ record…so you wouldn’t want
to then perform an Application-Query-Delete-Entry, you could simply perform
an
Application-Delete-Entry $SCHEMA$ $Request ID$
From: Action Request System discussion list(ARSList)
[mailto:arslist@ARSLIST.ORG] On Behalf Of Larry Barnes
Sent: Thursday, December 08, 2011 10:23 AM
To: arslist@ARSLIST.ORG
Subject: Application-Query-Delete-Entry
**
Hello Listers,
I'm trying to learn how to delete records that are past and the End Date is
more than 6 months prior to todays date. I built the escalation and when I
run it nothing happens. Can someone point in the right directions with the
Run Process syntax.
I'm using SQL 2008 and Windows 2008. ITSM is 7.5
The form I'm deleting from is: AP:Alternate
Run IF Qualification is:'Status' = Past (also tried without setting
a Run If Qualification)
Run Process is:Application-Query-Delete-Entry AP:Alternate ('Status' =
Past) and ($End Date$ ($TIMESTAMP$ - (86400 * 180)))
I have also tried:Application-Query-Delete-Entry AP:Alternate
('Status' = Past) and ($End Date$ ($DATE$ - (86400 * 180)))
Thanks in advance for your time,
Larry B
_attend WWRUG12 www.wwrug.com ARSlist: Where the Answers Are_
___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
attend wwrug12 www.wwrug12.com ARSList: Where the Answers Are
___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
attend wwrug12 www.wwrug12.com ARSList: Where the Answers Are
___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
attend wwrug12 www.wwrug12.com ARSList: Where the Answers Are
Re: Application-Query-Delete-Entry
I was thinking the same thing.
On Thu, Dec 8, 2011 at 11:18 AM, LJ LongWing lj.longw...@gmail.com wrote:
Joe,
I know this discussion comes up every once in awhilebut you and I seem
to differ in our opinions of how it works.
So...based on your statement below, having the escalation set a field, and
having a filter fire on that field being set, then performing the delete
will be 'faster' because of a 'fire and forget' type of mechanism?
I would argue that an action of delete within the escalation, and a
setfield causing a filter to fire that causes the delete are 'the same', in
that the escalation thread does not 'go onto the next record' till after
the filters on the current record are done...so, in essence, the
performance of either action would be the same and the escalation thread
would still be tied up for exactly the same amount of time regardless
At least, that's my understanding :)
-Original Message-
From: Action Request System discussion list(ARSList) [mailto:
arslist@ARSLIST.ORG] On Behalf Of Joe Martin D'Souza
Sent: Thursday, December 08, 2011 11:33 AM
To: arslist@ARSLIST.ORG
Subject: Re: Application-Query-Delete-Entry
End Date as Linda pointed out should be a field on that form you are
searching for, represented by 'End Date' in the qualification and not $End
Date$..
That being said, LJ's suggestion is right..
The qualification should be in the Run If of the Escalation and the run
process should be
Application-Delete-Entry $SCHEMA$ $Request ID$
Having an Escalation with no Run If instructs it to be run over the entire
data table. You do not want to do that in case you have like a million or
more records in it.. It may probably hang the escalation thread waiting for
it to complete..
Also a faster way to do it would be to 'mark that entry for deletion' using
a tag on a field created for that. This would mean that the Escalation
would
do a single update to that table which is a faster operation that multiple
deletes and be done with it.. Create a filter that runs if the $USER$ is
AR_ESCALATOR and the flag for delete is set, to delete that entry. So on a
fairly large set of data, although the deletes are still potentially
happening triggered by that filter, the escalation thread has already
finished processing the escalation and is ready to take on a new job..
Joe
-Original Message-
From: LJ LongWing
Sent: Thursday, December 08, 2011 12:54 PM Newsgroups:
public.remedy.arsystem.general
To: arslist@ARSLIST.ORG
Subject: Re: Application-Query-Delete-Entry
Larry,
Your approach is a bit ‘off’. An escalation performs a search that matches
your qualification, and then performs your action on ALL records that match
that qualification. So in this case, I would expect your run-if
qualification to be
('Status' = Past) and ($End Date$ ($TIMESTAMP$ - (86400 * 180)))
Or, whatever qual you want to identify your specific records,
Then, from there, you will be modifying ‘that’ record…so you wouldn’t want
to then perform an Application-Query-Delete-Entry, you could simply perform
an
Application-Delete-Entry $SCHEMA$ $Request ID$
From: Action Request System discussion list(ARSList)
[mailto:arslist@ARSLIST.ORG] On Behalf Of Larry Barnes
Sent: Thursday, December 08, 2011 10:23 AM
To: arslist@ARSLIST.ORG
Subject: Application-Query-Delete-Entry
**
Hello Listers,
I'm trying to learn how to delete records that are past and the End Date is
more than 6 months prior to todays date. I built the escalation and when I
run it nothing happens. Can someone point in the right directions with the
Run Process syntax.
I'm using SQL 2008 and Windows 2008. ITSM is 7.5
The form I'm deleting from is: AP:Alternate
Run IF Qualification is:'Status' = Past (also tried without setting
a Run If Qualification)
Run Process is:Application-Query-Delete-Entry AP:Alternate ('Status'
=
Past) and ($End Date$ ($TIMESTAMP$ - (86400 * 180)))
I have also tried:Application-Query-Delete-Entry AP:Alternate
('Status' = Past) and ($End Date$ ($DATE$ - (86400 * 180)))
Thanks in advance for your time,
Larry B
_attend WWRUG12 www.wwrug.com ARSlist: Where the Answers Are_
___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
attend wwrug12 www.wwrug12.com ARSList: Where the Answers Are
___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
attend wwrug12 www.wwrug12.com ARSList: Where the Answers Are
___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
attend wwrug12 www.wwrug12.com ARSList: Where the Answers Are
___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Re: Application-Query-Delete-Entry
First, let me thank you for all the input.
I struggled with the Application-Delete-Entry $SCHEMA$ $Request ID$,
because the AP:Alternate form doesn't have a field called Request
ID. Upon further digging, from the clues you gave, I used the
following to get the results I was looking for.
Run If Qualification: ('Status' Current) AND ('End Date' ($DATE$
- (86400 * 180)))
Run Process:Application-Delete-Entry $SCHEMA$ $1$
I had to put the $SCHEMA$ inside of quotes and the $1$ field represents
the Alternate ID field in the form; found this hiding on the second tab.
Thanks again,
Larry B.
From: Action Request System discussion list(ARSList)
[mailto:arslist@ARSLIST.ORG] On Behalf Of Jason Miller
Sent: Thursday, December 08, 2011 11:33 AM
To: arslist@ARSLIST.ORG
Subject: Re: Application-Query-Delete-Entry
** I was thinking the same thing.
On Thu, Dec 8, 2011 at 11:18 AM, LJ LongWing lj.longw...@gmail.com
wrote:
Joe,
I know this discussion comes up every once in awhilebut you
and I seem to differ in our opinions of how it works.
So...based on your statement below, having the escalation set a
field, and having a filter fire on that field being set, then performing
the delete will be 'faster' because of a 'fire and forget' type of
mechanism?
I would argue that an action of delete within the escalation,
and a setfield causing a filter to fire that causes the delete are 'the
same', in that the escalation thread does not 'go onto the next record'
till after the filters on the current record are done...so, in essence,
the performance of either action would be the same and the escalation
thread would still be tied up for exactly the same amount of time
regardless
At least, that's my understanding :)
-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:arslist@ARSLIST.ORG] On Behalf Of Joe Martin D'Souza
Sent: Thursday, December 08, 2011 11:33 AM
To: arslist@ARSLIST.ORG
Subject: Re: Application-Query-Delete-Entry
End Date as Linda pointed out should be a field on that form you
are
searching for, represented by 'End Date' in the qualification
and not $End
Date$..
That being said, LJ's suggestion is right..
The qualification should be in the Run If of the Escalation and
the run
process should be
Application-Delete-Entry $SCHEMA$ $Request ID$
Having an Escalation with no Run If instructs it to be run over
the entire
data table. You do not want to do that in case you have like a
million or
more records in it.. It may probably hang the escalation thread
waiting for
it to complete..
Also a faster way to do it would be to 'mark that entry for
deletion' using
a tag on a field created for that. This would mean that the
Escalation would
do a single update to that table which is a faster operation
that multiple
deletes and be done with it.. Create a filter that runs if the
$USER$ is
AR_ESCALATOR and the flag for delete is set, to delete that
entry. So on a
fairly large set of data, although the deletes are still
potentially
happening triggered by that filter, the escalation thread has
already
finished processing the escalation and is ready to take on a new
job..
Joe
-Original Message-
From: LJ LongWing
Sent: Thursday, December 08, 2011 12:54 PM Newsgroups:
public.remedy.arsystem.general
To: arslist@ARSLIST.ORG
Subject: Re: Application-Query-Delete-Entry
Larry,
Your approach is a bit 'off'. An escalation performs a search
that matches
your qualification, and then performs your action on ALL records
that match
that qualification. So in this case, I would expect your run-if
qualification to be
('Status' = Past) and ($End Date$ ($TIMESTAMP$ - (86400 *
180)))
Or, whatever qual you want to identify your specific records,
Then, from there, you will be modifying 'that' record...so you
wouldn't want
to then perform an Application-Query-Delete-Entry, you could
simply perform
an
Application-Delete-Entry $SCHEMA$ $Request ID$
From: Action Request System discussion list(ARSList)
[mailto:arslist@ARSLIST.ORG] On Behalf Of Larry Barnes
Sent: Thursday, December 08, 2011 10:23 AM
To: arslist@ARSLIST.ORG
Subject: Application-Query-Delete-Entry
**
Hello Listers,
I'm trying to learn how to delete records that are past and the
End Date is
more than 6 months prior to todays date. I built the escalation
Commit Changes vs PERFORM ACTION APPLY
HI All, Commit Changes vs. PERFORM ACTION APPLY. Is one better to use than the other on ARS 6.3? I have one active link that populates data from a SQL query and a second active link to commit the changes. These were probably created under ARS 3 or 4. The Commit Changes does the job but always looking to smart way to do things. Thanks Mark Mark Brittain Remedy Developer NaviSite - A Time Warner Cable Company mbritt...@navisite.com Office: 315-453-2912 x5335 Mobile: 315-317-2897 This e-mail is the property of NaviSite, Inc. It is intended only for the person or entity to which it is addressed and may contain information that is privileged, confidential, or otherwise protected from disclosure. Distribution or copying of this e-mail, or the information contained herein, to anyone other than the intended recipient is prohibited. ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: Where the Answers Are
Re: Application-Query-Delete-Entry
$1$ is the same as $Request ID$ if a form when created, has not have had the
database name altered. In case of AP:Alternate, I think this has been altered
to Entry ID.. Check the database name..
That being said, its safer to use $1$ in your workflow as irrespective to
whatever changes are made to the database name of that field, it will always
work..
Joe
From: Larry Barnes
Sent: Thursday, December 08, 2011 3:10 PM
Newsgroups: public.remedy.arsystem.general
To: arslist@ARSLIST.ORG
Subject: Re: Application-Query-Delete-Entry
**
First, let me thank you for all the input.
I struggled with the Application-Delete-Entry $SCHEMA$ $Request ID$, because
the AP:Alternate form doesn't have a field called Request ID. Upon further
digging, from the clues you gave, I used the following to get the results I was
looking for.
Run If Qualification: ('Status' Current) AND ('End Date' ($DATE$ -
(86400 * 180)))
Run Process:Application-Delete-Entry $SCHEMA$ $1$
I had to put the $SCHEMA$ inside of quotes and the $1$ field represents the
Alternate ID field in the form; found this hiding on the second tab.
Thanks again,
Larry B.
From: Action Request System discussion list(ARSList)
[mailto:arslist@ARSLIST.ORG] On Behalf Of Jason Miller
Sent: Thursday, December 08, 2011 11:33 AM
To: arslist@ARSLIST.ORG
Subject: Re: Application-Query-Delete-Entry
** I was thinking the same thing.
On Thu, Dec 8, 2011 at 11:18 AM, LJ LongWing lj.longw...@gmail.com wrote:
Joe,
I know this discussion comes up every once in awhilebut you and I seem to
differ in our opinions of how it works.
So...based on your statement below, having the escalation set a field, and
having a filter fire on that field being set, then performing the delete will
be 'faster' because of a 'fire and forget' type of mechanism?
I would argue that an action of delete within the escalation, and a setfield
causing a filter to fire that causes the delete are 'the same', in that the
escalation thread does not 'go onto the next record' till after the filters on
the current record are done...so, in essence, the performance of either action
would be the same and the escalation thread would still be tied up for exactly
the same amount of time regardless
At least, that's my understanding :)
-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:arslist@ARSLIST.ORG] On Behalf Of Joe Martin D'Souza
Sent: Thursday, December 08, 2011 11:33 AM
To: arslist@ARSLIST.ORG
Subject: Re: Application-Query-Delete-Entry
End Date as Linda pointed out should be a field on that form you are
searching for, represented by 'End Date' in the qualification and not $End
Date$..
That being said, LJ's suggestion is right..
The qualification should be in the Run If of the Escalation and the run
process should be
Application-Delete-Entry $SCHEMA$ $Request ID$
Having an Escalation with no Run If instructs it to be run over the entire
data table. You do not want to do that in case you have like a million or
more records in it.. It may probably hang the escalation thread waiting for
it to complete..
Also a faster way to do it would be to 'mark that entry for deletion' using
a tag on a field created for that. This would mean that the Escalation would
do a single update to that table which is a faster operation that multiple
deletes and be done with it.. Create a filter that runs if the $USER$ is
AR_ESCALATOR and the flag for delete is set, to delete that entry. So on a
fairly large set of data, although the deletes are still potentially
happening triggered by that filter, the escalation thread has already
finished processing the escalation and is ready to take on a new job..
Joe
-Original Message-
From: LJ LongWing
Sent: Thursday, December 08, 2011 12:54 PM Newsgroups:
public.remedy.arsystem.general
To: arslist@ARSLIST.ORG
Subject: Re: Application-Query-Delete-Entry
Larry,
Your approach is a bit ‘off’. An escalation performs a search that matches
your qualification, and then performs your action on ALL records that match
that qualification. So in this case, I would expect your run-if
qualification to be
('Status' = Past) and ($End Date$ ($TIMESTAMP$ - (86400 * 180)))
Or, whatever qual you want to identify your specific records,
Then, from there, you will be modifying ‘that’ record…so you wouldn’t want
to then perform an Application-Query-Delete-Entry, you could simply perform
an
Application-Delete-Entry $SCHEMA$ $Request ID$
From: Action Request System discussion list(ARSList)
[mailto:arslist@ARSLIST.ORG] On Behalf Of Larry Barnes
Sent: Thursday, December 08, 2011 10:23 AM
To: arslist@ARSLIST.ORG
Subject: Application-Query-Delete-Entry
**
Hello Listers,
I'm trying to learn how to delete records that are past
Re: Application-Query-Delete-Entry
Now that you remind me, I actually remember discussing this once with you..
I'll really need to log the workflow to see what thread processes the filter
workflow when filters are executed triggered by the AR_ESCALATOR user.
I was told this in a performance tuning class years ago (version 4.0 - 4.5
days so probably 11 or 12 years ago) that you let escalations perform first
stage actions, and leave any 2nd and 3rd stage actions (deletes, push
fields, notifications) to be performed by filters that are run using the
admin thread. Maybe the design was different back then? So this is obsolete
now?
I wish I had a server to verify this :-)
Joe
-Original Message-
From: LJ LongWing
Sent: Thursday, December 08, 2011 2:18 PM Newsgroups:
public.remedy.arsystem.general
To: arslist@ARSLIST.ORG
Subject: Re: Application-Query-Delete-Entry
Joe,
I know this discussion comes up every once in awhilebut you and I seem
to differ in our opinions of how it works.
So...based on your statement below, having the escalation set a field, and
having a filter fire on that field being set, then performing the delete
will be 'faster' because of a 'fire and forget' type of mechanism?
I would argue that an action of delete within the escalation, and a setfield
causing a filter to fire that causes the delete are 'the same', in that the
escalation thread does not 'go onto the next record' till after the filters
on the current record are done...so, in essence, the performance of either
action would be the same and the escalation thread would still be tied up
for exactly the same amount of time regardless
At least, that's my understanding :)
-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:arslist@ARSLIST.ORG] On Behalf Of Joe Martin D'Souza
Sent: Thursday, December 08, 2011 11:33 AM
To: arslist@ARSLIST.ORG
Subject: Re: Application-Query-Delete-Entry
End Date as Linda pointed out should be a field on that form you are
searching for, represented by 'End Date' in the qualification and not $End
Date$..
That being said, LJ's suggestion is right..
The qualification should be in the Run If of the Escalation and the run
process should be
Application-Delete-Entry $SCHEMA$ $Request ID$
Having an Escalation with no Run If instructs it to be run over the entire
data table. You do not want to do that in case you have like a million or
more records in it.. It may probably hang the escalation thread waiting for
it to complete..
Also a faster way to do it would be to 'mark that entry for deletion' using
a tag on a field created for that. This would mean that the Escalation would
do a single update to that table which is a faster operation that multiple
deletes and be done with it.. Create a filter that runs if the $USER$ is
AR_ESCALATOR and the flag for delete is set, to delete that entry. So on a
fairly large set of data, although the deletes are still potentially
happening triggered by that filter, the escalation thread has already
finished processing the escalation and is ready to take on a new job..
Joe
-Original Message-
From: LJ LongWing
Sent: Thursday, December 08, 2011 12:54 PM Newsgroups:
public.remedy.arsystem.general
To: arslist@ARSLIST.ORG
Subject: Re: Application-Query-Delete-Entry
Larry,
Your approach is a bit ‘off’. An escalation performs a search that matches
your qualification, and then performs your action on ALL records that match
that qualification. So in this case, I would expect your run-if
qualification to be
('Status' = Past) and ($End Date$ ($TIMESTAMP$ - (86400 * 180)))
Or, whatever qual you want to identify your specific records,
Then, from there, you will be modifying ‘that’ record…so you wouldn’t want
to then perform an Application-Query-Delete-Entry, you could simply perform
an
Application-Delete-Entry $SCHEMA$ $Request ID$
From: Action Request System discussion list(ARSList)
[mailto:arslist@ARSLIST.ORG] On Behalf Of Larry Barnes
Sent: Thursday, December 08, 2011 10:23 AM
To: arslist@ARSLIST.ORG
Subject: Application-Query-Delete-Entry
**
Hello Listers,
I'm trying to learn how to delete records that are past and the End Date is
more than 6 months prior to todays date. I built the escalation and when I
run it nothing happens. Can someone point in the right directions with the
Run Process syntax.
I'm using SQL 2008 and Windows 2008. ITSM is 7.5
The form I'm deleting from is: AP:Alternate
Run IF Qualification is:'Status' = Past (also tried without setting
a Run If Qualification)
Run Process is:Application-Query-Delete-Entry AP:Alternate ('Status' =
Past) and ($End Date$ ($TIMESTAMP$ - (86400 * 180)))
I have also tried:Application-Query-Delete-Entry AP:Alternate
('Status' = Past) and ($End Date$ ($DATE$ - (86400 * 180)))
Thanks in advance for your time,
Larry B
_attend WWRUG12 www.wwrug.com ARSlist: Where the Answers Are_
Re: Commit Changes vs PERFORM ACTION APPLY
Joe….that is ‘one’ of the things the Commit Changes does….when you are NOT in a dialog window, for example in a search window, the commit changes action performs the search, if in a submit window, it creates the record…if in a modify window it saves changes…so I think they ‘kinda do the same thing’ From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Joe Martin D'Souza Sent: Thursday, December 08, 2011 2:55 PM To: arslist@ARSLIST.ORG Subject: Re: Commit Changes vs PERFORM ACTION APPLY ** If you have a direct SQL query in your workflow, you do not need to use either of these after the Query. The AR Server performs the commit after the successful execution of that query wherever a commit is required (in case of insert, update or delete). Perform-Action-Apply is used for submitting in a submit or modify window and search in a search window while commit changes is used to push the values from a child window in a dialog box operation to the parent window after the child is closed, on fields where there was a mapping on window close between the parent and child window.. Joe From: Brittain, Mark mailto:mbritt...@navisite.com Sent: Thursday, December 08, 2011 3:51 PM Newsgroups: public.remedy.arsystem.general To: arslist@ARSLIST.ORG Subject: Commit Changes vs PERFORM ACTION APPLY ** HI All, Commit Changes vs. PERFORM ACTION APPLY. Is one better to use than the other on ARS 6.3? I have one active link that populates data from a SQL query and a second active link to commit the changes. These were probably created under ARS 3 or 4. The Commit Changes does the job but always looking to smart way to do things. Thanks Mark Mark Brittain Remedy Developer NaviSite – A Time Warner Cable Company mbritt...@navisite.com Office: 315-453-2912 x5335 Mobile: 315-317-2897 _ This e-mail is the property of NaviSite, Inc. It is intended only for the person or entity to which it is addressed and may contain information that is privileged, confidential, or otherwise protected from disclosure. Distribution or copying of this e-mail, or the information contained herein, to anyone other than the intended recipient is prohibited. _attend WWRUG12 www.wwrug.com ARSlist: Where the Answers Are_ _attend WWRUG12 www.wwrug.com ARSlist: Where the Answers Are_ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: Where the Answers Are
Re: Application-Query-Delete-Entry
One of us should set this up and test it :)if either of us had that sort of
spare time :D
-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:arslist@ARSLIST.ORG] On Behalf Of Joe Martin D'Souza
Sent: Thursday, December 08, 2011 3:06 PM
To: arslist@ARSLIST.ORG
Subject: Re: Application-Query-Delete-Entry
Now that you remind me, I actually remember discussing this once with you..
I'll really need to log the workflow to see what thread processes the filter
workflow when filters are executed triggered by the AR_ESCALATOR user.
I was told this in a performance tuning class years ago (version 4.0 - 4.5
days so probably 11 or 12 years ago) that you let escalations perform first
stage actions, and leave any 2nd and 3rd stage actions (deletes, push
fields, notifications) to be performed by filters that are run using the
admin thread. Maybe the design was different back then? So this is obsolete
now?
I wish I had a server to verify this :-)
Joe
-Original Message-
From: LJ LongWing
Sent: Thursday, December 08, 2011 2:18 PM Newsgroups:
public.remedy.arsystem.general
To: arslist@ARSLIST.ORG
Subject: Re: Application-Query-Delete-Entry
Joe,
I know this discussion comes up every once in awhilebut you and I seem
to differ in our opinions of how it works.
So...based on your statement below, having the escalation set a field, and
having a filter fire on that field being set, then performing the delete
will be 'faster' because of a 'fire and forget' type of mechanism?
I would argue that an action of delete within the escalation, and a setfield
causing a filter to fire that causes the delete are 'the same', in that the
escalation thread does not 'go onto the next record' till after the filters
on the current record are done...so, in essence, the performance of either
action would be the same and the escalation thread would still be tied up
for exactly the same amount of time regardless
At least, that's my understanding :)
-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:arslist@ARSLIST.ORG] On Behalf Of Joe Martin D'Souza
Sent: Thursday, December 08, 2011 11:33 AM
To: arslist@ARSLIST.ORG
Subject: Re: Application-Query-Delete-Entry
End Date as Linda pointed out should be a field on that form you are
searching for, represented by 'End Date' in the qualification and not $End
Date$..
That being said, LJ's suggestion is right..
The qualification should be in the Run If of the Escalation and the run
process should be
Application-Delete-Entry $SCHEMA$ $Request ID$
Having an Escalation with no Run If instructs it to be run over the entire
data table. You do not want to do that in case you have like a million or
more records in it.. It may probably hang the escalation thread waiting for
it to complete..
Also a faster way to do it would be to 'mark that entry for deletion' using
a tag on a field created for that. This would mean that the Escalation would
do a single update to that table which is a faster operation that multiple
deletes and be done with it.. Create a filter that runs if the $USER$ is
AR_ESCALATOR and the flag for delete is set, to delete that entry. So on a
fairly large set of data, although the deletes are still potentially
happening triggered by that filter, the escalation thread has already
finished processing the escalation and is ready to take on a new job..
Joe
-Original Message-
From: LJ LongWing
Sent: Thursday, December 08, 2011 12:54 PM Newsgroups:
public.remedy.arsystem.general
To: arslist@ARSLIST.ORG
Subject: Re: Application-Query-Delete-Entry
Larry,
Your approach is a bit ‘off’. An escalation performs a search that matches
your qualification, and then performs your action on ALL records that match
that qualification. So in this case, I would expect your run-if
qualification to be
('Status' = Past) and ($End Date$ ($TIMESTAMP$ - (86400 * 180)))
Or, whatever qual you want to identify your specific records,
Then, from there, you will be modifying ‘that’ record…so you wouldn’t want
to then perform an Application-Query-Delete-Entry, you could simply perform
an
Application-Delete-Entry $SCHEMA$ $Request ID$
From: Action Request System discussion list(ARSList)
[mailto:arslist@ARSLIST.ORG] On Behalf Of Larry Barnes
Sent: Thursday, December 08, 2011 10:23 AM
To: arslist@ARSLIST.ORG
Subject: Application-Query-Delete-Entry
**
Hello Listers,
I'm trying to learn how to delete records that are past and the End Date is
more than 6 months prior to todays date. I built the escalation and when I
run it nothing happens. Can someone point in the right directions with the
Run Process syntax.
I'm using SQL 2008 and Windows 2008. ITSM is 7.5
The form I'm deleting from is: AP:Alternate
Run IF Qualification is:'Status' = Past (also tried without setting
a Run If Qualification)
Run Process is:Application-Query-Delete-Entry AP:Alternate ('Status' =
Past) and ($End
SRM AIF
Does Advanced Interface Form (AIF) support conditions and questions in SRM 7.6.2? I have worked a lot with AIF, but never used any sort of conditions or questions. It's been primarily for workflow. Moe. ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: Where the Answers Are
Re: Application-Query-Delete-Entry
Going out on a limb here, since this is all new to me. It appears to me
that both methods are needed depending on the form you are working with.
The CAI:EventParmsInterface from has a field called Deleted which when
set to True will trigger workflow to delete the entry.
The AP:Alternate form doesn't appear to have a field to set that would
trigger backend workflow to delete these records thus the need for the
Run Process command line : Application-Delete-Entry SCHEMA$ $1$
The $1$ is the Alternate ID field in this form
Larry B
-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:arslist@ARSLIST.ORG] On Behalf Of Joe Martin D'Souza
Sent: Thursday, December 08, 2011 2:06 PM
To: arslist@ARSLIST.ORG
Subject: Re: Application-Query-Delete-Entry
Now that you remind me, I actually remember discussing this once with
you..
I'll really need to log the workflow to see what thread processes the
filter workflow when filters are executed triggered by the AR_ESCALATOR
user.
I was told this in a performance tuning class years ago (version 4.0 -
4.5 days so probably 11 or 12 years ago) that you let escalations
perform first stage actions, and leave any 2nd and 3rd stage actions
(deletes, push fields, notifications) to be performed by filters that
are run using the admin thread. Maybe the design was different back
then? So this is obsolete now?
I wish I had a server to verify this :-)
Joe
-Original Message-
From: LJ LongWing
Sent: Thursday, December 08, 2011 2:18 PM Newsgroups:
public.remedy.arsystem.general
To: arslist@ARSLIST.ORG
Subject: Re: Application-Query-Delete-Entry
Joe,
I know this discussion comes up every once in awhilebut you and I
seem to differ in our opinions of how it works.
So...based on your statement below, having the escalation set a field,
and having a filter fire on that field being set, then performing the
delete will be 'faster' because of a 'fire and forget' type of
mechanism?
I would argue that an action of delete within the escalation, and a
setfield causing a filter to fire that causes the delete are 'the same',
in that the escalation thread does not 'go onto the next record' till
after the filters on the current record are done...so, in essence, the
performance of either action would be the same and the escalation thread
would still be tied up for exactly the same amount of time regardless
At least, that's my understanding :)
-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:arslist@ARSLIST.ORG] On Behalf Of Joe Martin D'Souza
Sent: Thursday, December 08, 2011 11:33 AM
To: arslist@ARSLIST.ORG
Subject: Re: Application-Query-Delete-Entry
End Date as Linda pointed out should be a field on that form you are
searching for, represented by 'End Date' in the qualification and not
$End Date$..
That being said, LJ's suggestion is right..
The qualification should be in the Run If of the Escalation and the run
process should be
Application-Delete-Entry $SCHEMA$ $Request ID$
Having an Escalation with no Run If instructs it to be run over the
entire data table. You do not want to do that in case you have like a
million or more records in it.. It may probably hang the escalation
thread waiting for it to complete..
Also a faster way to do it would be to 'mark that entry for deletion'
using a tag on a field created for that. This would mean that the
Escalation would do a single update to that table which is a faster
operation that multiple deletes and be done with it.. Create a filter
that runs if the $USER$ is AR_ESCALATOR and the flag for delete is set,
to delete that entry. So on a fairly large set of data, although the
deletes are still potentially happening triggered by that filter, the
escalation thread has already finished processing the escalation and is
ready to take on a new job..
Joe
-Original Message-
From: LJ LongWing
Sent: Thursday, December 08, 2011 12:54 PM Newsgroups:
public.remedy.arsystem.general
To: arslist@ARSLIST.ORG
Subject: Re: Application-Query-Delete-Entry
Larry,
Your approach is a bit 'off'. An escalation performs a search that
matches your qualification, and then performs your action on ALL records
that match that qualification. So in this case, I would expect your
run-if qualification to be
('Status' = Past) and ($End Date$ ($TIMESTAMP$ - (86400 * 180)))
Or, whatever qual you want to identify your specific records,
Then, from there, you will be modifying 'that' record...so you wouldn't
want to then perform an Application-Query-Delete-Entry, you could simply
perform an
Application-Delete-Entry $SCHEMA$ $Request ID$
From: Action Request System discussion list(ARSList)
[mailto:arslist@ARSLIST.ORG] On Behalf Of Larry Barnes
Sent: Thursday, December 08, 2011 10:23 AM
To: arslist@ARSLIST.ORG
Subject: Application-Query-Delete-Entry
**
Hello Listers,
I'm trying to learn how to delete records that are past and the End Date
is more than 6 months prior to
Re: SRM AIF
SRM Advanced Interface Form is a normal Remedy Regular form and you can design/ develop as per your requirements. Thanks Mahesh On Thu, Dec 8, 2011 at 5:11 PM, Gmail moe.abdela...@gmail.com wrote: ** Does Advanced Interface Form (AIF) support conditions and questions in SRM 7.6.2? I have worked a lot with AIF, but never used any sort of conditions or questions. It’s been primarily for workflow. ** ** Moe. ** ** _attend WWRUG12 www.wwrug.com ARSlist: Where the Answers Are_ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: Where the Answers Are
Re: SRM AIF
Hi Moe, Currently the question and answer functionality in SRM is implemented by a visualisation plugin using a set of Remedy forms for configuration and data storage. It is possible to reverse engineer the question/answer functionality in an AIF using standard Remedy workflow. I have done this and I will say that it is easier in ARS 7.6.4 than 7.6.3 though I wouldn't say it is simple in either. Mahesh is right an AIF can do anything a normal Remedy form can do. The sample AIFs do give you a lot of workflow to share or copy that provides a lot of the standard SRM functionality though. Rod Harris On 9 December 2011 07:11, Gmail moe.abdela...@gmail.com wrote: ** Does Advanced Interface Form (AIF) support conditions and questions in SRM 7.6.2? I have worked a lot with AIF, but never used any sort of conditions or questions. It’s been primarily for workflow. ** ** Moe. ** ** _attend WWRUG12 www.wwrug.com ARSlist: Where the Answers Are_ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: Where the Answers Are
Re: Commit Changes vs PERFORM ACTION APPLY
That's a good question Mark. I'm not aware of any differences that would make one more efficient than the other. Personally I prefer to use the Commit Changes as it seems cleaner to use this rather than one of many run process commands. Rod Harris On 9 December 2011 04:51, Brittain, Mark mbritt...@navisite.com wrote: ** HI All, ** ** Commit Changes vs. PERFORM ACTION APPLY. Is one better to use than the other on ARS 6.3? ** ** I have one active link that populates data from a SQL query and a second active link to commit the changes. These were probably created under ARS 3 or 4. The Commit Changes does the job but always looking to smart way to do things. ** ** Thanks Mark ** ** *Mark Brittain* Remedy Developer *NaviSite – **A Time Warner Cable Company* mbritt...@navisite.com Office: 315-453-2912 x5335 Mobile: 315-317-2897 ** ** -- This e-mail is the property of NaviSite, Inc. It is intended only for the person or entity to which it is addressed and may contain information that is privileged, confidential, or otherwise protected from disclosure. Distribution or copying of this e-mail, or the information contained herein, to anyone other than the intended recipient is prohibited. _attend WWRUG12 www.wwrug.com ARSlist: Where the Answers Are_ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: Where the Answers Are
Re: Commit Changes vs PERFORM ACTION APPLY
True Commit Changes does that too, though personally I have started to use the Perform-Action-Apply for creating workflow for submits and searches as soon as it got available in version 6.3 I think.. Commit Changes should not however be confused with the ‘commit transaction’ in T-SQL or a ‘commit’ in Oracle as was by Mark following his SQL – at least that was my understanding of what he was attempting to do A Direct SQL once run from the Direct SQL action, is automatically followed by a commit when necessary. Joe From: LJ LongWing Sent: Thursday, December 08, 2011 5:32 PM Newsgroups: public.remedy.arsystem.general To: arslist@ARSLIST.ORG Subject: Re: Commit Changes vs PERFORM ACTION APPLY ** Joe….that is ‘one’ of the things the Commit Changes does….when you are NOT in a dialog window, for example in a search window, the commit changes action performs the search, if in a submit window, it creates the record…if in a modify window it saves changes…so I think they ‘kinda do the same thing’ From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Joe Martin D'Souza Sent: Thursday, December 08, 2011 2:55 PM To: arslist@ARSLIST.ORG Subject: Re: Commit Changes vs PERFORM ACTION APPLY ** If you have a direct SQL query in your workflow, you do not need to use either of these after the Query. The AR Server performs the commit after the successful execution of that query wherever a commit is required (in case of insert, update or delete). Perform-Action-Apply is used for submitting in a submit or modify window and search in a search window while commit changes is used to push the values from a child window in a dialog box operation to the parent window after the child is closed, on fields where there was a mapping on window close between the parent and child window.. Joe From: Brittain, Mark Sent: Thursday, December 08, 2011 3:51 PM Newsgroups: public.remedy.arsystem.general To: arslist@ARSLIST.ORG Subject: Commit Changes vs PERFORM ACTION APPLY ** HI All, Commit Changes vs. PERFORM ACTION APPLY. Is one better to use than the other on ARS 6.3? I have one active link that populates data from a SQL query and a second active link to commit the changes. These were probably created under ARS 3 or 4. The Commit Changes does the job but always looking to smart way to do things. Thanks Mark Mark Brittain Remedy Developer NaviSite – A Time Warner Cable Company mbritt...@navisite.com Office: 315-453-2912 x5335 Mobile: 315-317-2897 This e-mail is the property of NaviSite, Inc. It is intended only for the person or entity to which it is addressed and may contain information that is privileged, confidential, or otherwise protected from disclosure. Distribution or copying of this e-mail, or the information contained herein, to anyone other than the intended recipient is prohibited. _attend WWRUG12 www.wwrug.com ARSlist: Where the Answers Are_ _attend WWRUG12 www.wwrug.com ARSlist: Where the Answers Are_ _attend WWRUG12 www.wwrug.com ARSlist: Where the Answers Are_ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: Where the Answers Are
caught exception :Unable to get value of the property 'mObj'
Hi , I am keep on getting this error message whenever I tried to access the remedy using IE . Please find the attached screenshot for your reference. Now this message is keep on appearing when I am trying to create a new incident also . Please any work around for this error. Thanks and Regards RAVI CHANDRA R | Sr.BMC Remedy Administrator DLF - SEZ, Block 5, 4th Floor, Manapakkam,Chennai - 600 089 | INDIA ravi.chandra.ramag...@logica.com | www.logica.com http://www.logica.com/ Logica Pvt Ltd, registered in India (registered number U30007KA1998PTC023830) Registered Office: 124-125, Divyasree Technopolis, Off Airport Road, Bangalore - 560 037 http://www.logica.com/ Think green - keep it on the screen. This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you. ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: Where the Answers Are image001.pngimage002.gif
