One of the problem with using the Request ID to change on a nightly basis, is that you have to cache the definitions on a nightly basis just after the Escalation to set the prefix is run. So basically this would lead to a slight nightly overhead everytime you cycle the definition cache by running a process arsignal -g <server name>. This may not be very healthy for your system.
Another drawback is when you are searching for ticket 123, you will get ticket 123 for every day, as the prefix is ignored when searches are performed on ID 1. And you cannot really alter this as search defined to field ID 1 are cannot really be user modified, where it ignores the prefix and searches for a match only in the non prefix part. This would be in your control on a custom field as this field would have the same search behavior as any other custom field. Another suggestion when creating the string YEAR($DATE$) + MONTH($DATE$) + DAY($DATE$). Do not do this in a single action. Or your results for 2007 + 09 + 18 will be 2038. It adds up as a single integer before converting it to a string while setting it to a string. Instead have 3 Set field actions. One for setting $CustomID$ to YEAR($DATE$), another for resetting it to $CustomID$ + MONTH($DATE$) and the third for resetting it to $CustomID$ + DAY($DATE$). This will append it as a string instead of a numerical addition. Cheers Joe D'Souza -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] Behalf Of Carey Matthew Black Sent: Wednesday, September 19, 2007 9:37 AM To: [email protected] Subject: Re: Custom Request ID/GUID Paul, Actually I think it can be done. ( I have seen it done.) HOWEVER, I would most strongly advise against this type of modification. What Joe suggested, using a non-core field, is a much better design IMO. The 'Request ID' field can have a "prefix" that is changed nightly with an escalation changing the value via direct SQL. If the prefix-of-the-day is set to YEAR($DATE$) + MONTH($DATE$) + DAY($DATE$) + "-" then I think the result would be values like this... 20070918-000123 I do think you would have to live with the zero padded "count-for-the-day" part. If you have a 15 character length for the Request ID field. If you have a 13 character length for the Request ID field then the values would be like this 20070918-0123, and you would be limited to only being able to support 10,000 tickets a day. (MAX) And very bad things would happen if you ever tried to submit that 10,001 ticket. Not to mention that searching for tickets other than "for today" only by the "count-for-the-day" part would not be a nice search. Not to mention that you would be "creating gaps" and limiting the total number of records that the ARS form could ever hold daily. So in case it is not obvious by now... use a field other than field 1 for this type of value. :) Let ARS be ARS, and leave the Field 1 without a prefix and a length of 15 and you will save yourself a lot of possible long term problems. -- Carey Matthew Black Remedy Skilled Professional (RSP) ARS = Action Request System(Remedy) Love, then teach Solution = People + Process + Tools Fast, Accurate, Cheap.... Pick two. On 9/18/07, Joe D'Souza <[EMAIL PROTECTED]> wrote: > ** > > Paul, > > What you are looking for cannot be done using any Out-Of-The-Box features of > Remedy. > > Having said that, it is however possible to implement what you want by > creating a custom field to store this ID that you wish to generate. The > easiest way to achieve this would be to create a counter form that would > keep the counter (in your example 123), that would reset to 0 at midnight > every night using an escalation. > > On creation of a ticket, you perform a push field action, preferably as the > last execution order of a filter which has a phase override, to this form > containing the counter, to set the counter to existing counter value + 1 and > retrieve this set value to your current transaction. Retrieve this value set > on that form, and set it to the current $YEAR$ + $MONTH$ + $DAY$ + $counter$ > on a character field that would be used as that custom ID. > > Do not forget to index this ID as I'm pretty sure you will be using it to > retrieve either through user searches on that table or perhaps through > workflow. > > Cheers > > Joe > > -----Original Message----- > From: Action Request System discussion list(ARSList) > [mailto:[EMAIL PROTECTED] Behalf Of Paul Blasquez > Sent: Tuesday, September 18, 2007 7:45 PM > To: [email protected] > Subject: Custom Request ID/GUID > > > Hello, > > Are any of you using the ticket identifier format of > <year><month><day>-<unique number>? For example, issue 123 for today would > be ticket number 20070918-123. I have been a user on a system that used > this format, and I appreciate its intuitiveness. > > What is required to implement this? Is there simply a format/pattern applied > to the request id field? Or is it a bit more involved? I can't seem to > find anything about it in the Basic/Advanced guides nor in the ARS archives. > > _______________________ > Paul Blasquez > Remedy Developer/Senior Network Engineer > Equinix, Inc. No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.487 / Virus Database: 269.13.22/1015 - Release Date: 9/18/2007 11:53 AM _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are"
