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