Improving worklist notification response performance by deferring the processing

Overview

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>;
  

Handling Errors

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‘.

Retry

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.

Resolved

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