On a related note to this post, I have several step and path app package criteria working as expected. What I am struggling with is the 'definition criteria' for which i would expect a False return code to disable WF for the transaction assuming criteria is met. Now according to PBooks the definition criteria is 'used to determine which Definition ID is to be used to process the Approval'

So I am looking at either pointing to a definition that has no WF OR adding the criteria to every step...

Jim - Following up on my own comment - Ii was able to continue researching and found oracle support ticket Is it Possible to Setup Approval Workflow to Work With Multiple Approval Definition IDs? [ID 1134294.1].

Essentially this boils down to the fact that you can have multiple definitions configured for each approval process - the logical path being active status, default definition and effective date. If you return a False code in the default it will continue to cycle through the the active definitions.

Thanks for letting me bounce the idea off of you, hopefully another reader finds this thread useful!

A "Well" developed work flow will allow definition criteria to select the right definition. I have, however, seen work flows that hard code the definition ID. Obviously, in that case, it won't cycle through the list of definitions. And, like you said, it iterates over the collection of definitions until it finds one that returns true.It is my experience that if none return true, it will fall silently... basically the case where there is no work flow.

Jim -My current expectation is that returning False in from the approval definition criteria would bypass approval for the transaction as you stated. But this is not the case for me - a false return code continues to process the default definition...unless another definition is configured. Currently i have configured another definition that will always self-approve (or i can setup the second definition to bogus criteria) but it seems odd to have to configure this separately. Once i can come up for air, i will trace to find out why. Thanks again. Chris

I have a question related to AWE notifications for a specific event. Here is what I am encountering:

For the "Final Approval" event, I have configured three separate notifications to be generated -- all with the Participant = User List (different User Lists for each).

However, I have noticed that only the FIRST of the three notifications is being generated upon Final Approval. Is this an issue with how the AWE notifications execute or is there something that can be done within configuration to ensure delivery of all notifications?

@MattY, just to make sure I understand correctly... In the Transaction Configuration, do you have multiple rows with the same Event: "On Final Approval"? I can't say that I've tried that. I haven't looked into the code to see why it is behaving the way you described either. Perhaps there is an SQLExec in there to find rows by type rather than a loop? That would certainly behave the way you are describing. It would be nice if what you describe were supported. Perhaps an alternate method would be to create a query, app class, or SQL user list that combined all of three into a single user list? I'm sure you could make that work with an app class user list.

Has anyone had success creating custom AWE Line Level Approval? I’m having trouble trying to get the OnLineApprove method to fire. I have header level working so I decided to dig deeper. I added the keys to the Xref table, Updated the Registry, Configured the Events, added the method to my event handler, and created a new Process Definition using line level (very simple “Always True”). I have seen OnProcessLaunch fire so my routing has begun. But when my approver hits the Approve button, it saves and nothing happens to the approval. Tracing it show that the method does not fire. How does the system know to fire the line level method vs the header level method? Any ideas are appreciated.

@Kunal, a very good question. I do not know the answer off the top of my head. What I can't remember is the contents of the constructor &REC parameter and the check &bindRec parameter. You should print out the names of those records (log file or something). If the &bindRec has all of the header values, etc, then you could get a reference to the ApprovalManager which has an AppInst, stage and txn.

@Satish, short answer to both questions is "yes." You do this through one of the two records passed into the constructor or the check method. Unfortunately, I like I told @Kunal, I can't remember what those record variables contain. I wish I had documented that piece. I recommend printing the record names. From there, you can determine the SQL needed to investigate the transaction records or xref values.

Hi Jim, I used the code from your book 'webservice enabling approvals' to update the approval status using sync service. When there are multiple approval steps (this is Requisition process), only first step gets approved whereas the subsequent steps are updated to skipped and the Requisition status is updated to approved. When approved from the online page, it is routed to the next step/ approver just fine. Any pointers for me on what to look for?

Hi Jim,I am doing header level approval too. But when there are multiple approval steps, first step is approved and the second one's status turns to skipped.Whereas if I approve from the online page, it gets routed to second step just fine. I am not understanding what am I doing differently when I call doapprove?

Hi Jim, I have a small problem with my AWE. I have two steps in my awe. When user creates a request the AWE got triggered to the Step1 userlist and the Monitor Showed clearly Step1: Pending and Step2:Not routed.

Then I went and logged in as the Step1 user and approved. But this time it dint trigger the Worklist to the second step userlist.

The thread status for this transaction is still in P Pending. The stepstatus for the first step is in Pending and for the second step it is N Notrouted.

But Now a new problem has arised. When i try to access the link for the second level approver , nothing is happening the page is staying as it is. No action is happening, its not taking me to the approval page.

Buit for the first level approval this worklist link worked and took me to the Appr component.

Can you please help me where I should debug. Or am I missing something.

I have followed exact same steps for AWE as you suggested in Book. But i am stuck in error "Class extends another, but has no constructor." I am posting same code here:import PTAF_CORE:DEFN:UserListBase;

Is this a 9.1 or later application? If so, try using the EOAW classes instead of PTAF classes. PTAF were only in 9.0 applications. Oracle renamed the AWE classes in 9.1 to EOAW. Likewise, change all of your other configurations, etc, to use the EOAW versions (including tables).

That is correct. There is no EOAW in Campus 9.0. I do not have experience with AWE in Campus 9.0. I have heard of customers using it in 9.0 Campus. You might try posting your question on the PeopleSoft OTN General discussion forum. Be sure to note your app and tools release when you post your question.

The views expressed on this blog are my own and do not necessarily reflect the views of Oracle, my employer. Likewise, the views and opinions expressed by visitors to this blog are theirs and do not necessarily reflect my opinions or the opinions of Oracle.

Please be advised: this site contains code snippets and examples that may require modifications to delivered PeopleSoft objects. Before modifying delivered code, make sure your development team approves of your modification. Likewise, ensure that you have properly documented your modification according to your organization's best practices. You and your organization will be responsible for maintaining your modifications through patches and upgrades.

The author provides development tips and modification ideas for informational purposes only. Tips and techniques presented on this site should be considered proof of concepts only. Neither the author or his employer assume any liability for problems resulting from the implementation of these ideas.