Vikrant,
So, what we have here is an error condition and a question about error handling.
The error condition is a misformatted input -- extra semicolon separators.
The problem really is that there is no error handling for this condition. The
approval process is parsing the string, finds an empty definition, and just
converts the value it finds into an integer and continues. And, the integer
conversion logic converts anything non-numeric into a 0 (blank, letters,
whatever
is there if it is non-numeric).
OK, but then, the issue is that a value of 0 has a very special meaning of
Public
which is all users....
So, what is really needed here for this case -- or other cases of misformatting
like 3344;a;3433 which would produce the same problem as after processing that
would be 3344;0;3433 -- is better handling of the problem of a value of 0.
Realistically, you could argue that there is never a condition where sending a
notification to Public is a good idea. I agree with that position myself. Even
if there was some corner case where every single registered user of the product
somehow needed to be involved in an approval, I would argue that you should
have a
group that everyone is a member of and not use Public which is uncontrolled and
unconstrained.
For now, you can put in logic that checks for the condition you encountered and
eliminate double separators. A set fields using REPLACE('field', ";;", ";") and
assigned back to the field would do the trick.
I also suggest submitting a bug report (I am going to share the condition
internally as well, but bug reports from customers always carry more weight)
that
Public should simply not be allowed as a target for an approval and any attempt
to
specify Public as an approver should be ignored.
The approval server and processing is working correctly. The issue is that we
really should not allow Public to be an approval target at any time as it is not
deterministic and not a reliable or safe target.
Doug Mueller
-----Original Message-----
From: Action Request System discussion list(ARSList)
[mailto:[email protected]] On Behalf Of Vikrant
Sent: Tuesday, July 23, 2013 11:33 PM
To: [email protected]
Subject: Approval list parsing issue?
hi Everyone,
Yesterday we came across a strange issue with the SRM approval
processing. The case is such that we are creating approver list on the
SRM:Request form. From there we have written an approval rule which attaches
the approval process to the request and sends out approval requests to the
entire approver list on the SRM:Request form.
The string works about 99% of times(till yesterday evening 100%) but yesterday
evening we found out an issue with it. What happened is that due to data
inconsistency the approver list that got generated on the SRM:Request form was
like
Next Approvers (13005) = ;175540;;175540;;175540;;175540;;175540;;175540;
instead of Next Approvers (13005) = ;175540;175540;175540;175540;175540;175540;
Now this string was picked up by the approval process and somehow parsed into
the below string
Expanding roles for approver(s): 175540;0;75540
The 0 in the approver string set out an approval email to each and every
individual of the organization for approval (even the CEO :( scary....).
So my question stand likes this is or should approval server be smart enough to
parse the approves list with double ';' to one with single ';' or worst case
should leave it as it is and still be able to restrict approval to the members
in the approvers list.
Still confused about this as this is data issue due to which we get ";;" in the
approvers list. We have written special filters to handle this case but now its
about RCA and I am supposed to do this. A formal BMC ticket will be logged but
just want your opinion on this very special case.
Just in case you would like to see the log file, I have attached a segment of
the approval.log file which shows the parsing done by approval server along
with the post.
Thanks,
Vikrant
_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers
Are, and have been for 20 years"
_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
"Where the Answers Are, and have been for 20 years"
