hi Doug, Yes I agree with you about the incorrect syntax or the miss formatted input to the approval process. We have set in the check that you have suggested to replace ";;" with ";" in the approver list just some time back.
But on further analysis of our issue we found out few more things and one more such case. We found out that the approval notification was not sent to everyone in the org (about 100K people) but was sent to about 82K of them the reason or at least the possible reason I found was that all the 82K people had '0' in there login ID. Does it have any significance? still to find out... Second thing was that we got one more such case today late in the evening where the approver list passed on the SRM:Request form was Next Approvers (13005) =;175558;;175558;;175558;;175558;;175558;;175558; which was parsed by the approval server into Expanding roles for approver(s): 175558;8;75558 Looking at this the theory of replacing '0' for ";;" in the code does not fit right as I had initially thought about. May be some issue with the parsing logic. We have raised a BMC ticket as well for this let's see if we can get something out of it. Again the approval process is working fine seems like something to do with parsing. Also apologies to mention late about the environment details ARS 7.6.04 ITSM 7.6.04 SRM 7.6.04 SQL 2008 Remote Database and everything is SP4 on windows. Thanks, Vikrant -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of Mueller, Doug Sent: Wednesday, July 24, 2013 10:17 PM To: [email protected] Subject: Re: Approval list parsing issue? 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" _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
