Service action Peculiarity
Has anyone come across a peculiarity with the filter Service action where-in what is mapped is not what is received on the other end? ARS7.6.4 sp2 The particulars... Filter Service Input Mapping: inChar000 (536870913) = $host$ //source field id (536870913) inChar001 (536870914) = "People" //source field id (hardcoded) inChar002 (536870915) = "Used by" //source field id (hardcoded) inChar003 (536870916) = $corpid$ //source field id (536870915) Source values at time of call say: inChar000 (536870913) = vm04 inChar001 (536870914) = People inChar002 (536870915) = Used by inChar003 (536870916) = 4712258 Receiving says (and passes wrong value - see inChar003)... --> service action input inChar000 (536870913) = vm04 inChar001 (536870914) = People inChar002 (536870915) = Used by inChar003 (536870916) = Used by Change Service Input mapping to use new field/id as: inChar000 (536870913) = $host$ //source field id (536870913) inChar001 (536870914) = "People" //source field id (hardcoded) inChar002 (536870915) = "Used by" //source field id (hardcoded) inChar003 (536870916) = $corpid1$ //source field id (536870929) => new field/id not in field id set on destination form Use same Source Values as previously noted. Receiving now says (and works properly)... --> service action input inChar000 (536870913) = vm04 inChar001 (536870914) = People inChar002 (536870915) = Used by inChar003 (536870916) = 4712258 Thoughts? Bug? Enhancement? As designed? Thanks, Eric Roys Seamless Technologies CONFIDENTIALITY NOTICE: This email communication is intended only for the personal and confidential use of the recipient(s) designated above and may contain information which is subject to Federal and/or State privacy laws. In the event that you are not the intended recipient or the agent of the intended recipient, you are hereby notified that any review, disclosure, or use of the information contained herein is strictly prohibited. Do not copy or use the information contained within this communication, or allow it to be read, copied or utilized in any manner by any other person(s). If you have received this communication in error, please notify the sender immediately, either by response e-mail or by phone, and permanently delete the original e-mail, any attachment(s), and copies. ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are"
Re: Service action Peculiarity
Hi, Its not a bug. We have seen a case where because of change in the input length of a field it was providing a wrong value. HTH -- Regards, Dhanshree Vyom Labs Pvt. Ltd. BSM Solutions & Services || ITIL Consulting & Training Email: i...@vyomlabs.com || Web Site: www.vyomlabs.com Follow Vyom Labs http://twitter.com/#!/vyomlabs || http://www.linkedin.com/company/vyom-labs -Original Message- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Eric Roys Sent: Friday, August 17, 2012 8:51 AM To: arslist@ARSLIST.ORG Subject: Service action Peculiarity Has anyone come across a peculiarity with the filter Service action where-in what is mapped is not what is received on the other end? ARS7.6.4 sp2 The particulars... Filter Service Input Mapping: inChar000 (536870913) = $host$ //source field id (536870913) inChar001 (536870914) = "People" //source field id (hardcoded) inChar002 (536870915) = "Used by" //source field id (hardcoded) inChar003 (536870916) = $corpid$ //source field id (536870915) Source values at time of call say: inChar000 (536870913) = vm04 inChar001 (536870914) = People inChar002 (536870915) = Used by inChar003 (536870916) = 4712258 Receiving says (and passes wrong value - see inChar003)... --> service action input inChar000 (536870913) = vm04 inChar001 (536870914) = People inChar002 (536870915) = Used by inChar003 (536870916) = Used by Change Service Input mapping to use new field/id as: inChar000 (536870913) = $host$ //source field id (536870913) inChar001 (536870914) = "People" //source field id (hardcoded) inChar002 (536870915) = "Used by" //source field id (hardcoded) inChar003 (536870916) = $corpid1$ //source field id (536870929) => new field/id not in field id set on destination form Use same Source Values as previously noted. Receiving now says (and works properly)... --> service action input inChar000 (536870913) = vm04 inChar001 (536870914) = People inChar002 (536870915) = Used by inChar003 (536870916) = 4712258 Thoughts? Bug? Enhancement? As designed? Thanks, Eric Roys Seamless Technologies CONFIDENTIALITY NOTICE: This email communication is intended only for the personal and confidential use of the recipient(s) designated above and may contain information which is subject to Federal and/or State privacy laws. In the event that you are not the intended recipient or the agent of the intended recipient, you are hereby notified that any review, disclosure, or use of the information contained herein is strictly prohibited. Do not copy or use the information contained within this communication, or allow it to be read, copied or utilized in any manner by any other person(s). If you have received this communication in error, please notify the sender immediately, either by response e-mail or by phone, and permanently delete the original e-mail, any attachment(s), and copies. ___ 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: Service action Peculiarity
Hi, It still seems a bug to me. If a field does not exist, or the user does not have permissions to it, the value should always be NULL. Best Regards - Misi, RRR AB, http://rrr.se > Hi, > > Its not a bug. We have seen a case where because of change in the input > length of a field it was providing a wrong value. > > HTH > -- > Regards, > Dhanshree > > Vyom Labs Pvt. Ltd. > BSM Solutions & Services || ITIL Consulting & Training > Email: i...@vyomlabs.com || Web Site: www.vyomlabs.com Follow Vyom Labs > http://twitter.com/#!/vyomlabs || > http://www.linkedin.com/company/vyom-labs > -Original Message- > From: Action Request System discussion list(ARSList) > [mailto:arslist@ARSLIST.ORG] On Behalf Of Eric Roys > Sent: Friday, August 17, 2012 8:51 AM > To: arslist@ARSLIST.ORG > Subject: Service action Peculiarity > > Has anyone come across a peculiarity with the filter Service action > where-in > what is mapped is not what is received on the other end? > ARS7.6.4 sp2 > > The particulars... > > Filter Service Input Mapping: > inChar000 (536870913) = $host$ //source field id (536870913) > inChar001 (536870914) = "People" //source field id (hardcoded) > inChar002 (536870915) = "Used by" //source field id (hardcoded) > inChar003 (536870916) = $corpid$ //source field id (536870915) > > Source values at time of call say: > inChar000 (536870913) = vm04 > inChar001 (536870914) = People > inChar002 (536870915) = Used by > inChar003 (536870916) = 4712258 > > Receiving says (and passes wrong value - see inChar003)... > > > --> service action input > > >inChar000 (536870913) = vm04 > > >inChar001 (536870914) = People > > >inChar002 (536870915) = Used >> by > > >inChar003 (536870916) = Used >> by > > Change Service Input mapping to use new field/id as: > inChar000 (536870913) = $host$ //source field id (536870913) > inChar001 (536870914) = "People" //source field id (hardcoded) > inChar002 (536870915) = "Used by" //source field id (hardcoded) > inChar003 (536870916) = $corpid1$ //source field id (536870929) => new > field/id not in field id set on destination form > > Use same Source Values as previously noted. > > Receiving now says (and works properly)... > > > --> service action input > > >inChar000 (536870913) = vm04 > > >inChar001 (536870914) = People > > >inChar002 (536870915) = Used >> by > > >inChar003 (536870916) = >> 4712258 > > > Thoughts? Bug? Enhancement? As designed? > > Thanks, > > Eric Roys > Seamless Technologies > > > CONFIDENTIALITY NOTICE: This email communication is intended only for the > personal and confidential use of the recipient(s) designated above and may > contain information which is subject to Federal and/or State privacy laws. > In the event that you are not the intended recipient or the agent of the > intended recipient, you are hereby notified that any review, disclosure, > or > use of the information contained herein is strictly prohibited. Do not > copy > or use the information contained within this communication, or allow it to > be read, copied or utilized in any manner by any other person(s). If you > have received this communication in error, please notify the sender > immediately, either by response e-mail or by phone, and permanently delete > the original e-mail, any attachment(s), and copies. > > > ___ > 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"
Re: Service action Peculiarity
Thanks, Misi and Dhanshree. Input length is not an issue as source/destination are same size. Swapping source field with another source field of same size would technically fail if it were an issue of input length, but does not. Whether the field exists or not is not an issue as I assure you it does exist and is being accessed via Admin account. What does appear to be at issue is confusion of the id/value pairing in whatever is transpiring in the black box of the service action. Normally I would not allow the system to default an id so normally this would not be an issue, it just so happens that this was a quick prototype and the additional scrutiny was not (until now) necessary. And what are the odds that even if one specified their own id that the source form and the service handler form would have the same ids? -Eric -Original Message- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Misi Mladoniczky Sent: Friday, August 17, 2012 3:47 AM To: arslist@ARSLIST.ORG Subject: Re: Service action Peculiarity Hi, It still seems a bug to me. If a field does not exist, or the user does not have permissions to it, the value should always be NULL. Best Regards - Misi, RRR AB, http://rrr.se > Hi, > > Its not a bug. We have seen a case where because of change in the > input length of a field it was providing a wrong value. > > HTH > -- > Regards, > Dhanshree > > Vyom Labs Pvt. Ltd. > BSM Solutions & Services || ITIL Consulting & Training > Email: i...@vyomlabs.com || Web Site: www.vyomlabs.com Follow Vyom > Labs http://twitter.com/#!/vyomlabs || > http://www.linkedin.com/company/vyom-labs > -Original Message- > From: Action Request System discussion list(ARSList) > [mailto:arslist@ARSLIST.ORG] On Behalf Of Eric Roys > Sent: Friday, August 17, 2012 8:51 AM > To: arslist@ARSLIST.ORG > Subject: Service action Peculiarity > > Has anyone come across a peculiarity with the filter Service action > where-in what is mapped is not what is received on the other end? > ARS7.6.4 sp2 > > The particulars... > > Filter Service Input Mapping: > inChar000 (536870913) = $host$ //source field id (536870913) > inChar001 (536870914) = "People" //source field id (hardcoded) > inChar002 (536870915) = "Used by" //source field id (hardcoded) > inChar003 (536870916) = $corpid$ //source field id (536870915) > > Source values at time of call say: > inChar000 (536870913) = vm04 > inChar001 (536870914) = People > inChar002 (536870915) = Used by > inChar003 (536870916) = 4712258 > > Receiving says (and passes wrong value - see inChar003)... > > > --> service action input > > >inChar000 (536870913) = vm04 > > >inChar001 (536870914) = People > > >inChar002 (536870915) = Used >> by > > >inChar003 (536870916) = Used >> by > > Change Service Input mapping to use new field/id as: > inChar000 (536870913) = $host$ //source field id (536870913) > inChar001 (536870914) = "People" //source field id (hardcoded) > inChar002 (536870915) = "Used by" //source field id (hardcoded) > inChar003 (536870916) = $corpid1$ //source field id (536870929) => > new field/id not in field id set on destination form > > Use same Source Values as previously noted. > > Receiving now says (and works properly)... > > > --> service action input > > >inChar000 (536870913) = vm04 > > >inChar001 (536870914) = People > > >inChar002 (536870915) = Used >> by > > >inChar003 (536870916) = >> 4712258 > > > Thoughts? Bug? Enhancement? As designed? > > Thanks, > > Eric Roys > Seamless Technologies > > > CONFIDENTIALITY NOTICE: This email communication is intended only for > the personal and confidential use of the recipient(s) designated above > and may contain information which is subject to Federal and/or State privacy > laws. > In the event that you are not the intended recipient or the agent of > the intended recipient, you are hereby notified that any review, > disclosure, or use of the information contained herein is strictly > prohibited. Do not copy or use the information contained within this > communication, or allow it to be read, copied or utilized in any > manner by any other person(s). If you have received this communication > in error, please notify the sender immediately, either by response > e-mail or by phone, and permanently delete the original e-mail, any > attachment(s), and copies.
