I thought the Next-ID-Commit setting only made the retrieving of the ID from the arschema table an independent transaction so if there is an error it does not try to roll back. It does not alter the fact that the Request ID is not available in the set fields actions of Phase 1 filters. In 7.6.04 it does not really do anything as it has been superseded by the Next-ID-Block-Size value. The server may grab it at the start of the submit cycle, but that is probably just so the programmers didn't have to alter the code between a submit and a modify with a bunch of If statements.
Fred -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Misi Mladoniczky Sent: Monday, April 23, 2012 3:54 PM To: arslist@ARSLIST.ORG Subject: Re: Save the Request-ID to a field on Submit Hi, No, it is not available. But if you look at the SQL logs, it is retrieved and committed before the filters start running. This option is available before 7.6.04, but it is not the default behavior in earlier versions. Best Regards - Misi, RRR AB, http://www.rrr.se (ARSList MVP 2011) Products from RRR Scandinavia (Best R.O.I. Award at WWRUG10/11): * RRR|License - Not enough Remedy licenses? Save money by optimizing. * RRR|Log - Performance issues or elusive bugs? Analyze your Remedy logs. Find these products, and many free tools and utilities, at http://rrr.se. > Haven't had the chance to play around with 7.6.04 too much as yet. So > haven't seen the impact of that default.. > > If it is already committed, how come its not available? Or is it > available. > I might have missed something you said in your previous posts.. > > Joe > > -----Original Message----- > From: Misi Mladoniczky > Sent: Monday, April 23, 2012 5:33 AM Newsgroups: > public.remedy.arsystem.general > To: arslist@ARSLIST.ORG > Subject: Re: Save the Request-ID to a field on Submit > > Hi Joe, > > No, it does NOT wait for the commit any longer. At least not if you use > the Default-settings in 7.6.04. > > The Unique-Index-error is fine to me. It means that the AR Developer did > something wrong. > > Again, all your next arguments is voided by the fact that the default > setting is now Next-ID-Commit:T, which means that the Next-ID is commited > BEFORE the filters start running. > > Best Regards - Misi, RRR AB, http://rrr.se > >> I think the reasoning behind keeping the nextid until after the request >> is >> submitted is that the application waits for an actual commit before >> assuming >> the nextID it has queried for as there is a less than a possible chance >> that >> two or more users may attempt to submit a new request at the same micro >> second thus attempting to use the same request ID. >> >> I'm guessing there must be some sort of a mechanism in place to prevent >> that >> so that users do not get the ugly violation of unique index error. >> >> This is just a guess though.. May not be the real reason.. >> >> In order to have a run process to get the nextID would mean that they >> would >> need to commit the request you are currently working on before you have >> even >> created it, so a sort of a create on window open. Whether or not that is >> a >> good idea, is probably debatable. Irresponsible use of a system by >> indiscriminately opening new windows, may result in loss of chunks of >> Request ID's - just like it is now with the Incident ID's - at least in >> this >> case the Request ID's stay pretty much sequential until a server restart >> where an unused block of request ID's is reset. >> >> Loosing Request ID's is often not a very pretty sight when reporting, as >> its >> harder to determine if the Request ID was deliberately deleted by some >> user >> having a greater access to the system. You may not be able to audit that >> even with a delete trigger on the database, as the application would >> actually need to delete the new entry created if the user does not save. >> >> In my opinion, a better - possibly cleaner way to fetch a Request ID on >> create is to device a new channel or method to allow the developer to >> access >> it both from an active link (which is possible with an After Submit) as >> well >> as a filter. Some sort of an after submit or after modify action on a >> filter. >> >> Obviously this operation event may have not been replicated with filters >> as >> there must be some challenges towards making that happen.. >> >> Joe >> >> -----Original Message----- >> From: Misi Mladoniczky >> Sent: Sunday, April 22, 2012 7:40 AM Newsgroups: >> public.remedy.arsystem.general >> To: arslist@ARSLIST.ORG >> Subject: Re: Save the Request-ID to a field on Submit >> >> Hi, >> >> Using arschema.nextId is not a good idea, as nowadays the default >> behavior >> in 7.6.04 is to commit that value in chunks of 100, and pick from the >> memory-based list within the AR Server process. >> >> In the old days, when the request id was increased in steps of 1 without >> any >> gaps, this would have worked. >> >> I have NO IDEA why BMC does not give us the request id in phase 1 in >> 7.6.04, >> at least if Next-ID-Commit:T is set in the ar.cfg (which is also the >> default >> value of 7.6.04). >> >> They could even give us a $PROCESS$ @@:GetNextID call that would reserve >> and >> set the Request ID on the client side. It makes no sense barring us from >> setting the Request ID in New-Mode using ACTL:s any longer. >> >> Best Regards - Misi, RRR AB, http://www.rrr.se (ARSList MVP >> 2011) >> >> Products from RRR Scandinavia (Best R.O.I. Award at WWRUG10/11): >> * RRR|License - Not enough Remedy licenses? Save money by optimizing. >> * RRR|Log - Performance issues or elusive bugs? Analyze your Remedy >> logs. >> Find these products, and many free tools and utilities, at >> http://rrr.se. >> >>> Tried that Joe, but it's not working. And BTW, when you build a filter >>> that fires on submit and you push the newly created Request-ID into >>> another form, then the $LASTID$ does containt the request-id. I think >>> the only not-too-tricky option I have is to query the ARSystem >>> Metadata: arschema form for next_id... >>> >>> On Apr 20, 4:17 pm, Joe Martin D'Souza <jdso...@shyle.net> wrote: >>>> $LASTID$ would not necessarily hold the current Request ID that is >>>> generated. It holds the ID of a request that was last queried for. So >>>> if >>>> you >>>> have workflow that did something like that, it may not necessarily be >>>> the ID >>>> of your current request that was just created. >>>> >>>> Use a filter to set the Request ID to that temp field, but bypass >>>> filter >>>> phasing, and name that filter to end with `!. For eg. >>>> HPD:SetRequestID`! >>>> >>>> That should get your current Request ID on that temp field.. >>>> >>>> Joe >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> -----Original Message----- >>>> From: Mark Milke >>>> Sent: Friday, April 20, 2012 5:47 AM Newsgroups: >>>> >>>> public.remedy.arsystem.general >>>> To: arsl...@arslist.org >>>> Subject: Save the Request-ID to a field on Submit >>>> >>>> Hello Listers, >>>> >>>> someone is creating a ticket in my form. On submit I'd like to copy >>>> the >>>> Request-ID into a field to in order to be able format it for another >>>> purpose, but it's not working. >>>> >>>> I've tried Set Fields: zzTmp_Request-ID = $Request-ID$ and >>>> zzTmp_Request-ID >>>> = $LASTID$. >>>> >>>> Any ideas how I can achieve this without into the same form on submit >>>> or >>>> overwritting the filter phases of the filter creating the ticket? >>>> >>>> Thanks >>>> Mark > > _______________________________________________________________________________ > 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"
