A while back, I was asked for advice on finding the result of a notification within the process:
Can you please help me, how to capture the result of notification approval? My notification has result type approval.
My first response was to question why the client needed to know the result within the process. Merely by having a result for the notification, the knowledge is automatically communicated back to the process, which can then have conditional branching based on the response provided. If the result is needed further down the line as an attribute, then a standard ASSIGN activity could be used to store the result in an attribute.
The problem with this approach is that if the process models multiple results on the same transition branch (i.e. by using a <Default> or <Any> transition), then there is no easy way to determine which of the multiple responses was actually provided. For example, imagine that the notification has a lookup type as a response which has lookup codes defined which mean “Approved”, “Finally Approved”, “Rejected” and “Resubmit”. In the process flow, the notification has a transition defined for “Rejected”, one for “Resubmit” and a “default” transition which manages the two approval routes. If the business requirement is that the only thing that we need to capture is the “type” of response (i.e. approval or rejection) then we can still take the same approach. If, however, the business requirement is that the exact response is required rather than the type of response, then the response needs to be captured in a different method.
There are two approaches that can be adopted to find the exact response to the notification, both requiring custom PL/SQL. Firstly, you can define an activity in the process which accesses the Workflow tables directly to find the previous notification and then find the response to the notification. In this case, you will need to hard-code in the PL/SQL the type of message that you are looking for, and if there is any change to the Workflow process at a later stage, the PL/SQL will need to be modified to handle the change of notification type.
The second approach, which is the one that I would recommend is to write a custom post-notification function (PNF). Within the PNF, you can find the details of the response directly, and perform your processing logic. Additionally, because the code can be written in a generic manner, the PNF can be re-used for any number of scenarios where the result is required.
The developer for the client followed this advice, but still had problems trying to find the result:
I attached the function to the notification. in the function I’m trying to capture the result using getItemattrtextlc_result := wf_engine.getitemattrtext( itemtype => itemtype, itemkey => itemkey, aname => 'RESULT' );
I always get null
The problem here, which is an easy fix is that he was using the wrong API to fetch the result. When the notification is being responded to, the result won’t be stored in item attributes. That would only happen once the processing of the post notification function is complete. The way to find the result is to firstly find the notification ID using WF_ENGINE.context_nid.
Once you know the notification ID, call WF_NOTIFICATION.getAttrText to find the attribute from the notification. You’ll need to do that for the RESULT attribute and any other attributes on the notification that the business requires.
Why would you need the result?
After some discussion, we finally got to the business requirements, which then meant that we could design an effective solution – one of my bugbears about providing support and advice is that I would much prefer for someone to ask “what is the best way to solve the problem?” rather than “how do I do XYZ?” which means that some times you go off down the wrong path (see this post featuring a video by Tom Kyte on the same issue!).
The business requirements were that the notification has a “comments” field, which if the notification is being rejected must be completed to conform to the business processing requirements. Therefore, the check needs to be that when the notification is responded to, and it is being rejected, and the comments field has not been completed, then an error should be raised. This can only be done effectively using a post notification function – if I had known the business requirements from the start, then I would not have suggested by first approach.
Anyway, that’s how to find the response in different ways – depending on the business requirements, either one may be the right approach to adopt.