By Saroja Kandepuneni-Oracle on Oct 15, 2014
When the user responds to a notification from self-service worklist, the control will be returned back to the responder only after processing the subsequent function activities and other synchronous activities until the next blocking activity. If there is any costly activity defined after the notification activity user can experience performance problems. There is a feature available from E-Business Suite Release 12.2 onwards to defer the response processing to a later time and the control will be returned back immediately so that the response time will be faster.
When a notification is responded in a deferred mode, a message with event name 'oracle.apps.wf.notification.wl.response.message' and other required properties will be enqueued in to WF_NOTIFICATION_IN queue for later processing, and the notification will be closed immediately. The 'Workflow Inbound Notification Agent Listener' dequeues the message from WF_NOTIFICATION_IN queue and executes its subscription to complete the notification activity and the subsequent activities.
Notification Response mode
The Workflow Administrator actually determines the response processing mode for their application whether to process all the workflows synchronously or to defer all the workflows or only some specific workflow types. There is a section available in the Workflow Administration page to select the required processing mode.
There are 3 options available
- NONE - None of the workflows response processing will be deferred. This is the default behavior.
- ALL - All the workflows will be deferred for processing
- SPECIFIC - Only the specified workflows will be deferred. There are buttons available to Add or Delete or Search for the required item types
Tracing the responded notification
The responded notification processing can be traced in the below sequence.
- Check the STATUS column in WF_NOTIFICATIONS table The notification status will be changed to CLOSED once the control returns back to the worklist and a message will be enqueued to WF_NOTIFICATION_IN queue with READY state
select notification_id, status from wf_notifications where notification_id = <nid>;
- Check the message state in WF_NOTIFICATION_IN queue The 'Workflow Inbound Notification Agent Listener' component processes the messages in WF_NOTIFICATION_IN queue and the message state will be changed to PROCESSED select win.user_data.GET_STRING_PROPERTY('NOTIFICATION_ID') NID, msg_state, enq_time, deq_time from applsys.aq$wf_notification_in win where win.user_data.GET_STRING_PROPERTY('NOTIFICATION_ID') = <nid>;
- Check the notification activity status in WF_ITEM_ACTIVITY_STATUSES table The notification activity status will be COMPLETE once the message is processed by the 'Workflow Inbound Notification Agent Listener' component SELECT notification_id, activity_status FROM wf_item_activity_statuses where notification_id = <nid>;
When there is any error occurs during the deferred response processing, WFERROR/NTF_DEFER_RESP_PROCESS_ERROR workflow process will be launched and an error notification will be sent to the Workflow Administrator role. The ERROR notification contains the information about the Errored notification details, Error message and Error stack.
The Error notification contains two response attributes 'Retry' and 'Resolved'.
When the problem that is causing the error is fixed and no longer exists, submit the 'Retry' response so that the actual notification will be enqueued to WF_NOTIFICATION_IN queue and will be processed again.
When the problem that is causing the error is resolved now and the notification is COMPLETE, then submit the 'Resolved' response so that the error notification will also be closed.
IMPORTANT NOTE: The 'Workflow Inbound Notification Agent Listener' component should be up and running for the above feature to work