First I want to thank all those who sent me their suggestions for a fix.
BMC did get back to me on 2/21 informing me the problem I'm having with ARServer is a "known bug" and it can be fixed with a hot patch 008. This amounts to installing a new arapprove.dll file. There's only one problem, I can't find this patch on the BMC web site; go figure. If you go to there ftp site the last patch you see is 007. I've sent BMC an update explaining I can't find this patch and I await their reply. Thanks again for the help, Larry B. -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of Mueller, Doug Sent: Monday, February 20, 2012 11:20 AM To: [email protected] Subject: Re: Approval Engine Issues Larry, You are right that the copying of this critical join form has copied information either in the change diary or in terms of the fields on the form to confuse the system and make it think that this new form is the key support form that the approval server uses rather than the original form which is really the key form. This is always something you have to take care with. If the form is a system form -- comes with AR System or is system generated or is a form that you generate but then configure into a subsystem (like this case where you probably created the original join but then ran apjoinfixup to complete the definition and reconfigure it for attachment to approvals) -- you SHOULD NOT clone the form. There are often either tags put into fields like the change diary or specific field combinations with reserved field IDs put onto the forms so that the system can find them regardless of any name change you have made to the form. When you copy the form, the system is confused as there are multiple forms that qualify. Depending on the subsystem, the system will either just error and complain that there is a conflict and not continue with that subsystem or will just pick one. This case seems to have just picked one but it unfortunately picked the wrong one. So, now, you are at the stage of wanting to remove this new form but keep any of the logic that is attached to it but attach it to the correct form. Is that correct? If so, the easiest way to do that is: 1) Find a list of all the workflow -- filters, active links, escalations -- that are attached to the form. 2) For each of these, open the definition and ADD the form you want to transfer the workflow to as an additional form on the "attached to forms list" 3) Delete the form you want to delete. This will remove it from the form list on all workflow but the workflow will have another form attached and so will not be deleted but will stay still attached to that other form. You have just completed the job of keeping the workflow with its attached form switched to another form. There should be no more than a handful of workflow items that need to be modified in step 2 so this should be a short process. I hope this helps, Doug Mueller -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of Larry Barnes Sent: Friday, February 17, 2012 7:56 AM To: [email protected] Subject: Re: Approval Engine Issues Thanks everyone for your quick response. I did turn the approval engine debug mode on and found some interesting entries. Turns out I copied an existing form, "SRM:RequestApDetail" and called it "lab:SRM:RequestApDetail". Apparently all the workflow now points to this new form. This form was going to be used for audit purposes. I'm trying to figure out now how to remove this form without breaking anything else. There's only 1 field in the new form and that's why the approval engine is not working; in my opinion. Is there a way to safely remove this form and get the workflow to point back to the original form? Larry B. -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of Kedar Joshi Sent: Thursday, February 16, 2012 9:20 PM To: [email protected] Subject: Re: Approval Engine Issues Hi, Can you enable approval debug logs and check if you are getting any error in the logs ? You can enable the logs by performing following steps: 1. Go to AP:Administration 2. Click on Server Settting 3. Click the checkbox for "Approval Debug Mode" 4. Click Save Once done, execute the use case and check the log file - arapprove.log in "db" folder of your AR install directory. Let me know if you find something from the logs. (Also keep an eye on arerror.log file) ________________________________________________________________________ _______ 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" _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are"
