Thursday Feb 19, 2015

Different ways of sending workflow notifications


There are various ways of sending workflow notifications using Workflow Activities like Notification Activity with 'Expand Roles' flag checked, Notification Activity without 'Expand Roles' flag checked, APIs like WF_NOTIFICATION.Send, WF_NOTIFICATION.SendGroup, and using Business Event System Subscription Action Type 'Send Notification'.

Using Workflow Activities

A notification can be sent by running a workflow process having the notification activity. The recipient of the notification can be set by using the Performer attribute in the notification activity, and the message template can be set using the Message attribute. If the performer value is a role, then the 'Expand Roles' flag will be used to decide whether to send the same copy to all the users of the role or a different copy.

Notification Activity without "Expand Roles"

 The 'Expand Roles' flag will be unchecked by default, sends the same copy of notification to all its users and that notification is visible in the notification queue of all the users in that role. If one user in that role responds to or closes that notification, the notification is removed from the notification queue of all other users in that role.

Notification Activity with "Expand Roles"

The 'Expand Roles' flag when checked, sends a different copy of the notification to all its users. The notification remains in a user's notification queue until the user responds to or closes the notification. By both checking Expand Roles and specifying a post-notification function, you can create a voting activity. A voting activity is a notification activity that first sends a notification message to a group of users in a role and then executes a PL/SQL post-notification function to tally the users' responses and determines the transition to the next activity.

Refer to WF dev guide for more details about voting activity.

Using APIs

A notification with the specified message can be sent to the role by calling the WF_NOTIFICATION.send() and WF_NOTIFICATION.sendGroup() APIs without actually launching the workflow process. The message template that needs to be sent has to be defined within a workflow item type .


This function sends the specified message to a user/role and returns a notification ID if successful. The specification of the function is shown below.

function SEND
 (role in varchar2, 
  msg_type in varchar2, 
  msg_name in varchar2,
  due_date in date default null,
  callback in varchar2 default null,
  context in varchar2 default null,
  send_comment in varchar2 default null
  priority in number default null)
 return number;


  nid number;
  msg_type varchar2(100) := 'WFTESTS';
  msg_name varchar2(100) := 'PLSQL_MSG';
  role varchar2(320) := 'TESTUSER';
   nid := wf_notification.send(role, msg_type, msg_name);  


This function sends a separate copy of notification to all the users assigned to the specified role and returns the notification group ID if successful. All the notifications have the same group id, which is the first notification id sent.

function SendGroup
  (role in varchar2,
   msg_type in varchar2,
   msg_name in varchar2,
   due_date in date default null,
   callback in varchar2 default null,
   context in varchar2 default null,
   send_comment in varchar2 default null
   priority in number default null)
  return number;
  nid number;
  msg_type varchar2(100) := 'WFTESTS';
  msg_name varchar2(100) := 'PLSQL_MSG';
  role varchar2(320) := 'TESTUSER';
   nid := wf_notification.SendGroup(role, msg_type, msg_name);  

Using Business Event System Subscription Action Type

The notification can also be sent by raising the business event for which the subscription action type is specified as 'Send Notification - Send a notification using a standard or custom message template'. As part of the subscription definition, the workflow item type and message name for the message you want to send and role that should receive the notification must be specified. In this approach, you do not need to define or run a workflow process to send a notification from a subscription. However, you do need to define the message you want to send within a workflow item type. The list of values for the Message Name field includes only the messages within the item type you specify.

Following are the subscription mandatory parameters

  • Message Type - An item type that contains the message definition
  • Message Name- An message template for the notification you want to send
  • Recipient  - A role that should receive the notification
  • Priority - Normal, High, or Low as the priority for the message.

Following are the subscription optional parameters

  • Callback - Custom callback function you want the Notification System to use for communication of SEND and RESPOND source message attributes.
  • Context - The context information for a workflow process instance that needs to passed to the callback function. The context information consists of the item type, item key, and activity ID in the following format:
  • Comment - A comment to send with the message

Thursday Oct 09, 2014

'The signing operation has failed' - common error with Password Based Signatures in Workflow Notifications


Oracle Workflow Notifications can be digitally signed in two ways.

  1. Password Based Signature
  2. X.509 Certificate Based Signature.

Following are the authentication mechanisms categorized based on whether or not a user subscribes to Single Sign-On (SSO).


  1. Pure E-Business Suite User (Otherwise called FND User)
  2. Pure SSO user
  3. Hybrid Mechanism (Both E-Business Suite and SSO)

Issues and Reasons

Time and again we have encountered a problem with Password Based signatures failing with the error: 'The signing operation has failed'. This happens when the notification is signed using SSO credentials i.e., the logged in user is an SSO user. The profile option APPS_SSO_LOCAL_LOGIN, controls the type of authentication mechanism to be used for a user at the time of user-creation. More information about SSO can be found here

The possible values of this profile option are:

  • LOCAL - Login is only allowed via Oracle E-Business Suite local login.
  • SSO - Login is only allowed through Single Sign-On. The password is set to ‘EXTERNAL’ after a single sign-on account and an application account are linked.
  • BOTH - Login can be through both Single Sign-On and Oracle E-Business Suite. (Please note this is only a separate authentication mechanism but not a different class of users created for it)

Now based on the type of login/authentication mechanism, the signing differs.


  • For a FND User, the validation utility validates the credentials by fetching password from FND_USER table from ENCRYPTED_USER_PASSWORD column.
  • For a pure SSO user, the ENCRYPTED_USER_PASSWORD column is set to 'EXTERNAL' in FND_USER table and the Validation utility fetches the password from OID to validate it.
  • For a user using both types of authentication mechanisms, the Validation utility validates it as it does in the case of a FND User i.e., comparing the ENCRYPTED_USER_PASSWORD from FND_USER table. This implies that when the user uses authentication mechanism for both FND User and SSO user then the password for FND User is used for validation.

Also, it is to be noted that the password for SSO user is case sensitive and the password for FND user depends upon a profile option SIGNON_PASSWORD_CASE. In short:


  • An SSO user password is case-sensitive.
  • An FND User password is by default case insensitive. It depends upon the value of profile option 'SIGNON_PASSWORD_CASE' to have it case sensitive or case insensitive.
  • For a user which uses both authentication mechanisms, the password for FND user is used for signing. It would be good if these passwords are maintained in sync.
Hence, when one encounters the error mentioned here, the starting point to investigate is to see what type of user it is. Mostly it would be user using authentication mechanism for both FND User and SSO User. In that case the FND User password should be used and not the SSO password. Also the case of the password should be heeded to as that can well be the cause of the issue. 



Thursday Aug 30, 2012

Implementing a post-notification function to perform custom validation


Oracle Workflow Notification System can be extended to perform extra validation or processing via PLSQL procedures when the notification is being responded to. These PLSQL procedures are called post-notification functions since they are executed after a notification action such as Approve, Reject, Reassign or Request Information is performed. The standard signature for the post-notification function is

    procedure <procedure_name> (itemtype  in varchar2,
                                itemkey   in varchar2,
                                actid     in varchar2,
                                funcmode  in varchar2,
                                resultout in out nocopy varchar2);


The post-notification function provides the parameter 'funcmode' which will have the following values:

  • 'RESPOND', 'VALIDATE, and 'RUN' for a notification is responded to (Approve, Reject, etc)
  • 'FORWARD' for a notification being forwarded to another user
  • 'TRANSFER' for a notification being transferred to another user
  • 'QUESTION' for a request of more information from one user to another
  • 'QUESTION' for a response to a request of more information
  • 'TIMEOUT' for a timed-out notification
  • 'CANCEL' when the notification is being re-executed in a loop.

Context Variables

Oracle Workflow provides different context information that corresponds to the current notification being acted upon to the post-notification function.

WF_ENGINE.context_nid - The notification ID 

WF_ENGINE.context_new_role - The new role to which the action on the notification is directed

WF_ENGINE.context_user_comment - Comments appended to the notification 

 WF_ENGINE.context_user - The user who is responsible for taking the action that updated the notification's state

WF_ENGINE.context_recipient_role - The role currently designated as the recipient of the notification. This value may be the same as the value of WF_ENGINE.context_user variable, or it may be a group role of which the context user is a member.

WF_ENGINE.context_original_recipient - The role that has ownership of and responsibility for the notification. This value may differ from the value of the WF_ENGINE.context_recipient_role variable if the notification has previously been reassigned. 


Let us assume there is an EBS transaction that can only be approved by a certain people thus any attempt to transfer or delegate such notification should be allowed only to users SPIERSON or CBAKER. The way to implement this functionality would be as follows:

  • Edit the corresponding workflow definition in Workflow Builder and open the notification.
  • In the Function Name enter the name of the procedure where the custom code is handled, for instance, TEST_PACKAGE.Post_Notification
  • In PLSQL create the corresponding package TEST_PACKAGE with a procedure named Post_Notification, as follows:

    procedure Post_Notification (itemtype  in varchar2,
                                 itemkey   in varchar2,
                                 actid     in varchar2,
                                 funcmode  in varchar2,
                                 resultout in out nocopy varchar2) is
      l_count number;
      if funcmode in ('TRANSFER','FORWARD') then
        select count(1) into l_count
        from WF_ROLES
        where WF_ENGINE.context_new_role in ('SPIERSON','CBAKER');
              --and/or any other conditions
        if l_count<1 then
          WF_CORE.TOKEN('ROLE', WF_ENGINE.context_new_role);
        end if;
      end if;
    end Post_Notification;
  • Launch the workflow process with the changed notification and attempt to reassign or transfer it. When trying to reassign the notification to user CBROWN the screen would like like below:

Notification transfer error

Check the Workflow API Reference Guide, section Post-Notification Functions, to see all the standard, seeded WF_ENGINE variables available for extending notifications processing. 


This blog is dedicated to bring latest information on Oracle Workflow new features, best practices, troubleshooting techniques and important fixes directly from it's Development Team.


« October 2015