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: [email protected]
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 <[email protected]> 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: [email protected]
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"
