Bulk responding to notifications

A question that comes up regularly is what’s the best way to respond / close / abort notifications in bulk.  I’ve recently been writing a pretty horrendous workflow for a government organization, and when I was developing the code, needless to say there were a few errors that came out.

The workflow that errored raised the standard error handling workflow, so I ended up with somewhere in the region of 2000 notifications being sent to SYSADMIN.  Once the code was fixed, I just wanted a quick way to respond to all of them.  Depending on the patch level of the environment, Oracle have introduced a way of bulk responding to notifications via the worklist – however, having to click through the 2000 notifications to select each one is a pretty tedious task 🙂

The WF_NOTIFICATION package contains everything that you need to do to respond to notifications programatically – I’ve used it a lot when responding from Portal and from forms as well.  There are two different approaches, depending on whether the notification requires a response or not.

FYI notifications are the easiest – all you need to do is call WF_NOTIFICATION.Close, passing in the notification ID.  Since it’s that easy, I’ll credit you with the ability to be able to write your own code to do it!

Notifications which require a response are slightly harder – you need to set the response in the notification, and then tell the engine that the notification has been responded it.  Firstly, call WF_NOTIFICATION.SetAttrText to set an attribute called "RESULT" to the value that you are sending back.  This needs to be the internal name of the lookup code that you are using.  Once you’ve done that, you just need to call WF_NOTIFICATION.Respond to close the notification.

A code sample to retry all open notifications sent from the standard error workflow to the SYSADMIN user is:
BEGIN
  FOR i IN ( SELECT notification_id
             FROM wf_notifications
             WHERE recipient_role = 'SYSADMIN'
             AND status = 'OPEN'
             AND message_type = 'WFERROR'
             AND message_name = 'RESET_ERROR_MESSAGE' ) LOOP
    wf_notification.setattrtext ( nid => i.notification_id
                                , aname => 'RESULT'
                                , avalue => 'RETRY' );
    wf_notification.respond ( nid => i.notification_id );
    COMMIT;
  END LOOP;
END;
/

4 thoughts on “Bulk responding to notifications

  1. I used a similar construction to Respond to Open notifications within a loop.
    Additionally I added a reponder to the wf_notification.respond call like this
    wf_notification.respond( nid => r_fiatteer_log.notification_id
    , respond_comment => NULL
    , responder => r_fiatteer_log.USER_NAME);

    The first responder is correctly stored, but for the second respond in the loop the user_name of the user who initially started the workflow is used in stead of the approver.

    Do you have any idea what goes wrong?

    Regards

    Rinus Jansen
    Qualogy Applications

  2. Hi,

    You’d need to write a cursor to identify the item type and item key of the processes that you want to abort, and for each one of those call WF_ENGINE.AbortProcess. There is no standard API to bulk abort Workflow processes.

    Matt

Comments are closed.

By continuing to use the site, you agree to the use of cookies. more information

In common with almost all professionally run websites, this website logs the IP address of each visitor in order to keep it running reliably. This is also essential for protecting the website and its visitors from malicious attacks, including infection with malware.

This website provides information as a service to visitors such as yourself, and to do this reliably and efficiently, it sometimes places small amounts of information on your computer or device (e.g. mobile phone). This includes small files known as cookies. The cookies stored by this website cannot be used to identify you personally.

We use cookies to understand what pages and information visitors find useful, and to detect problems such as broken links, or pages which are taking a long time to load.

We sometimes use cookies to remember a choice you make on one page, when you have moved to another page if that information can be used to make the website work better. For example:
- avoiding the need to ask for the same information several times during a session (e.g. when filling in forms), or
- remembering that you have logged in, so that you don’t have to re-enter your username and password on every page.

You can prevent the setting of cookies by adjusting the settings on your browser (see your browser Help for how to do this). Be aware that disabling cookies will affect the functionality of this and many other websites that you visit.

Close