Hi all, I just wanted to let you know that I found out why this was happening, but I am still not sure exactly what caused it behind the scenes. Just in case anyone else has the same or similar workflow, and has the same problem with jumping incident #s
Just an FYI, the jumps in my incident #'s were in a vast range. Sometimes jumps of 2, 5, then 27, 40, back to 2, then 10, then 5, 27, etc, and every so often it would jump over 100 numbers within a 3 minute range. So what was causing it, or at least having a direct effect. I have built workflow to process incoming emails into 7.6 Incident Management. It is the typical: 1. Copy incoming messages to a processing form. 2. have the workflow check for possible spam/to address/etc 3. push it to a new ticket 4. or update an existing one if there is a ticket# in the subject line. It was working fine for approximately 7-8 days after our go-live, and then something in it seemed to cause the ticket# jumps. The reason I am 99% sure it was this, is because while troubleshooting different possibilites one at a a time, I ended up disabling all email processing workflow, and within minutes the Incident#s were back to normal increments(only jumping 1, 2 or 3 numbers which is normal based on amount of people we have working tickets). So I enabled all workflow again, and the increments are still normal. So at this time, even though the email workflow is enabled, my incident #s are normal. I am still monitoring every day to make sure nothing starts jumping again. I do not know yet what caused this, but am still investigating and researching to see what I can come up with. thanks for all your ideas and help, Michael On Tue, Jul 26, 2011 at 8:35 AM, Alejandro Canon <aca...@extensionsa.com> wrote: > That´s right. > When you are creating an incident record through HPD:IncidentInterface_Create > form, two processes will be triggered: > - (1) One process for creating a record in HPD_IncidentInterface_Create form > where all data entered is validated (i.e Operational and Product Catalogs, > Summary does not exceed 100 characters, Client and Contact are valid records > against People form, and so on). When that process becomes to finish it will > be reserved an Incident Number in HPD_IncidentInterface_Create form and one > record in that form will be created. > - (2) Once Incident record is generated in HPD_IncidentInterface_Create form > there's a second process who will create a record in HPD:HelpDesk form using > data stored in HPD_IncidentInterface_Create (1). One of first routins > triggered because of this process is reserving an Incident Number ID using > HPD:CFG Ticket Num Generator form. Then all standard routines (Filters - > CREATE event) for creating records in HPD:HelpDesk will be triggered. > If Incident record in HPD:HelpDesk is created successfully, then the record > in HPD:IncidentInterface_Create will be deleted. > As result of executing these processes you will see just one record in > HPD:Help Desk form. > > The big issue with these process is related with process (1) executed > successfully but process (2) failed because of some error. In that case you > will see one record in Interface form but no record in Help Desk form. In > many cases Help Desk create process may fail after reserving Incident Number > through HPD:CFG: Ticket Num Generator. That´s the reason I was asking Michael > about external interfaces for creating incidents. > > > HTH, > > Alejandro > > -----Mensaje original----- > De: Action Request System discussion list(ARSList) > [mailto:arslist@ARSLIST.ORG] En nombre de uday kiran > Enviado el: Martes, 26 de Julio de 2011 4:27 > Para: arslist@ARSLIST.ORG > Asunto: Re: Jumps in Incident ID numbers > > Yes that is correct when we dont call the webservice it will not > reserver a number > > thanks > uday > > On Fri, Jul 22, 2011 at 9:47 PM, Michael <mhi...@email.arizona.edu> wrote: >> Hi Alejandro, >> >> Yes we do use the HPD:IncidentInterface_Create WebService for a few >> web forms used through a PHP class we designed. Though I have not >> heard of any failures on the web form submissions, and our users are >> usually quite vocal when something does not work. >> >> Question.... I know when the web service is being consumed it will >> reserve a number, but it won't reserve a number if the web service is >> not called, is that correct? >> >> Michael >> >> On Thu, Jul 21, 2011 at 1:58 PM, Alejandro Canon <aca...@extensionsa.com> >> wrote: >>> Michael: >>> >>> Do you have published HPD:IncidentInterface_Create WebService or some >>> external creation of incidents through HPD:IncidentInterface_Create form? >>> Because of that interface form it will trigger Incident ID Reservation in >>> HPD:Help Desk form. Even if Incident ticket is not created due to some >>> error, Incident ID is reserved and NextID will be incremented according >>> what Christopher said. >>> >>> Regards, >>> >>> Alejandro >>> -----Mensaje original----- >>> De: Action Request System discussion list(ARSList) >>> [mailto:arslist@ARSLIST.ORG] En nombre de Michael >>> Enviado el: Jueves, 21 de Julio de 2011 16:05 >>> Para: arslist@ARSLIST.ORG >>> Asunto: Re: Jumps in Incident ID numbers >>> >>> Nice idea! >>> >>> I love 'what if', I always learn so much in trying. >>> >>> I will play with that and see if I can get anything from it. >>> >>> thanks, >>> Michael >>> >>> On Thu, Jul 21, 2011 at 12:53 PM, Martinez, Marcelo A >>> <marc...@cpchem.com> wrote: >>>> Just an idea here.. What IF... >>>> >>>> You create a custom form with some fields you'd like to capture. Then >>>> create workflow to fire when [TR.IncidentID*+ =! $NULL$ ] and have it >>>> populate those fields on your custom form. You could capture user / >>>> timestamp / etc fields.. >>>> >>>> I have not tried this - don't know if it would work >>>> >>>> >>>> -----Original Message----- >>>> From: Action Request System discussion list(ARSList) >>>> [mailto:arslist@ARSLIST.ORG] On Behalf Of Michael >>>> Sent: Thursday, July 21, 2011 2:44 PM >>>> To: arslist@ARSLIST.ORG >>>> Subject: Re: Jumps in Incident ID numbers >>>> >>>> Thanks, I will look into that. >>>> >>>> Not sure if they(management) want to make that customization, but it >>>> never hurts to explore all options. >>>> >>>> thanks again, >>>> Michael >>>> >>>> On Thu, Jul 21, 2011 at 12:34 PM, pritch <pri...@ptd.net> wrote: >>>>> There's a couple active links you can disable that should stop that (I >>>>> had a similar issue with change). They have the active links duplicated >>>>> as filters on submit so it generates it there. I did have to put in a >>>>> warning message to give the user their ticket number. >>>>> >>>>> ----- Original Message ----- >>>>> From: "strauss" <stra...@unt.edu> >>>>> To: arslist@ARSLIST.ORG >>>>> Sent: Thursday, July 21, 2011 3:26:09 PM >>>>> Subject: Re: Jumps in Incident ID numbers >>>>> >>>>> Anything that tries to open a new ticket generates a new Incident ID, >>>>> then if the transaction is abandoned that ID is considered "consumed" and >>>>> the Next ID is incremented. On ITSM 7.0 this occurred if you selected >>>>> the Customer in the ticketing form; in 7.6.04 it occurs when you open a >>>>> new Incident (or other) form, so the skipping of numbers will just get >>>>> "worse" from here on out. >>>>> >>>>> Christopher Strauss, Ph.D. >>>>> Call Tracking Administration Manager >>>>> University of North Texas Computing & IT Center >>>>> http://itsm.unt.edu/ >>>>> >>>>> -----Original Message----- >>>>> From: Action Request System discussion list(ARSList) >>>>> [mailto:arslist@ARSLIST.ORG] On Behalf Of Michael >>>>> Sent: Thursday, July 21, 2011 2:22 PM >>>>> To: arslist@ARSLIST.ORG >>>>> Subject: Jumps in Incident ID numbers >>>>> >>>>> Hi all, >>>>> >>>>> ITSM & server 7.6.03 >>>>> Linux 2.6.18-238.9.1.el5 >>>>> Oracle 11g >>>>> >>>>> I am opening a ticket with Remedy support on this, but was wondering >>>>> if anyone had seen this before. We are getting constant jumps in >>>>> Incident ID numbers. For example: >>>>> >>>>> (Last 3 tickets created less than 5 minutes apart) >>>>> >>>>> INC000000029396 >>>>> INC000000029399 >>>>> INC000000029401 >>>>> >>>>> This is constant, and sometimes the jumps between numbers is random, >>>>> sometimes its 1, then 3, then 2, then 10, then 27, it bounces all over >>>>> the place. >>>>> >>>>> Next Request ID Block size is set to 1 on the Configuration tab of the >>>>> "Server Information" form. >>>>> >>>>> There is no Next Request ID Block size on: >>>>> >>>>> HPD:Help Desk >>>>> HPD:CFG Ticket Num Generator >>>>> >>>>> Also, except for very minor customizations like a field name, or >>>>> adding a field to the IM console, this is OOTB. >>>>> >>>>> Anyone seen this, or have any ideas? >>>>> >>>>> thanks! >>>>> -- >>>>> Michael Hirst >>>>> University of Arizona, >>>>> UITS >>>>> 520-621-0867 >>>>> >>>>> _______________________________________________________________________________ >>>>> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org >>>>> attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are" >>>>> >>>>> _______________________________________________________________________________ >>>>> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org >>>>> attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are" >>>>> >>>>> _______________________________________________________________________________ >>>>> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org >>>>> attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are" >>>>> >>>>> >>>> >>>> >>>> >>>> -- >>>> Michael Hirst >>>> University of Arizona, >>>> UITS >>>> 520-621-0867 >>>> >>>> _______________________________________________________________________________ >>>> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org >>>> attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are" >>>> >>>> _______________________________________________________________________________ >>>> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org >>>> attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are" >>>> >>>> >>> >>> >>> >>> -- >>> Michael Hirst >>> University of Arizona, >>> UITS >>> 520-621-0867 >>> >>> _______________________________________________________________________________ >>> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org >>> attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are" >>> >>> _______________________________________________________________________________ >>> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org >>> attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are" >>> >>> >> >> >> >> -- >> Michael Hirst >> University of Arizona, >> UITS >> 520-621-0867 >> >> _______________________________________________________________________________ >> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org >> attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are" >> > > _______________________________________________________________________________ > UNSUBSCRIBE or access ARSlist Archives at www.arslist.org > attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are" > > _______________________________________________________________________________ > UNSUBSCRIBE or access ARSlist Archives at www.arslist.org > attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are" > > -- Michael Hirst University of Arizona, UITS 520-621-0867 _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"
