Re: Save the Request-ID to a field on Submit
Ni, The Next-ID-Commit is not superseded, it still works. If it is set to true (default in 7.6.04) it will update NextID and commit it at the beginning of the API call, before the filters are run. If Next-ID-Block-Size is set, Next-ID-Commit:T does not really matter, does it, so in that sense it is superseded. But if Next-ID-Block-Size is set to 1 (not the default in 7.6.04), the Next-ID-Commit setting is honored. 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. > 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 >
Re: Save the Request-ID to a field on Submit
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: Sund
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$ @@
Re: Save the Request-ID to a field on Submit
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 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..
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 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 th
Re: Save the Request-ID to a field on Submit
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 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"
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 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 atwww.arslist.org >> attend wwrug12www.wwrug12.comARSList: "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"
Re: Save the Request-ID to a field on Submit
Mark, If some external system is creating a ticket on your ITSM form, you can trigger your workflows using the Request ID second time onwards. Ex : First : The external System creates a Record in the form. >> Record is submitted and Request ID gets generated. Second : The external System updates the above record (updates some field say Status) >> you can run your workflow based upon the status Change as you will have the Request ID at this point of time. Regards, Rajesh On Fri, Apr 20, 2012 at 3:17 PM, Mark Milke wrote: > 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"
Re: Save the Request-ID to a field on Submit
The Request ID is not available until Phase 2 in the filters. A usual method is to do a push back to the form in an AfterSubmit Active Link action or in a Submit Filter (Push to the same form where Push-If is '1' = $1$) to get the ID into another field. Fred -Original Message- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Mark Milke Sent: Friday, April 20, 2012 11:01 AM To: arslist@ARSLIST.ORG Subject: Re: Save the Request-ID to a field on Submit 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 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"
Re: Save the Request-ID to a field on Submit
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 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 atwww.arslist.org > attend wwrug12www.wwrug12.comARSList: "Where the Answers Are" ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are"
Re: Save the Request-ID to a field on Submit
$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: arslist@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"
Re: Save the Request-ID to a field on Submit
Are you using ITSM? If so, the Request Id (field 1) is not the "Incident Number". If it's your own form, or you really want field 1, you can only copy it after it has a value - which means after submit. So, you will have to set it after the create succeeds which means there must be a time separation between the submit and any workflow to set your field. That can be done in many ways.Here are a few options: Easiest option is this: add a 179 field (or equivalent) Add a filter to set 179 before submission Do a push to a new form such as "gots to do work in my ticket form" setting the 179 reference field (not 179) Set up an escalation on the second form that issues an update to it (Status != done or any extant records) 1) do a get fields to get the '1' from the ticket form 2) set the formatted value 3) do a push fields back to the ticket form using the 179 to select it 4) delete the record or set the status = done Make sure there's an index on 179 of the ticket (or equivalent) and (if you decide to use a status) on the status in the second form. This means that tickets can be in a state where the newly formatted field is not ready (until the escalation is run). The escalation will run once for each ticket so could be set to run each minute. It will not add too much to the server load. In this case the "error" time could be from 0secs to 60secs Other options include a Run Process (you'd have to write the process, but a simple batch file or shell script should suffice) which will have '1' available as it's fired after the submit (not a set fields run process). A further option is a process (windows? Unix) where the run process simply echos '1' to a file in a dir and a batch process wakes each second looking for such files, processes them (ie updates that field) and then deletes the file (in a loop). If the sleep is 1 s the amount of time the ticket could be missing the info is from 0 to 1 sec. Of course, with any process options you have to update an ARS record. You could use Perl, Java, other things, or do the whole thing with Meta-Update :) It is not safe to check the next available id from arschema because of threading and newer algorithms in the use of such. Cheers Ben Chernys Senior Software Architect Canada / Deutschland Mobile: +49 171 380 2329 GMT + 1 + [ DST ] Email: Ben.Chernys_AT_softwaretoolhouse.com Web: www.softwaretoolhouse.com Check out Software Tool House's free Diary Editor and out Freebies Section for an ITSM 7.6.04 Forms and Fields spreadsheet. Meta-Update, our premium ARS Data tool, lets you automate your imports, migrations, in no time at all, without programming, without staging forms, without merge workflow. http://www.softwaretoolhouse.com/ -Original Message- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Mark Milke Sent: April-20-12 11:48 To: arslist@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"
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"
