Friday Sep 11, 2015

What can a Workflow Administrator do?


Workflow Administrator is a user who can take various administrative actions on a Workflow Process. In addition to that a Workflow Administrator can view the progress of a work item in a workflow process by connecting to the Workflow Monitor using a standard Web browser that supports Java. The Workflow Monitor displays an annotated view of the process diagram for a particular instance of a workflow process, so that users can get a graphical depiction of their work item status.

Setting up a Workflow Administrator

To setup a user as a Workflow Administrator, you can navigate to Workflow Administrator Web Applications > Administrator Workflow > Administration > Workflow Configuration. Here, there is a field called “Workflow System Administrator” to which a user can be assigned.

WARNING: If the value of this field is set as ‘*’, then every user on that E-Business Suite instance is considered as a Workflow Administrator. Hence, it is advisable not to set the value as ‘*’.

The following section presents us with different areas of Workflow and the actions a Workflow Administrator can perform in those areas:

Notification System

A Workflow Administrator can

  • Search and view any notification in the E-Business Suite application using Notification Search function.
  • Take any action on a Notification such as Respond, More Information Request, Reassign etc. An exception to this is Notifications requiring Digital Signatures (notifications requiring Password Based and Certificate Based Signature) where even a Workflow Administrator cannot respond to as it requires Digital Signatures of the recipient.
  • Respond to a notification that is sent by him/her.
  • Reassign even notifications restricted for reassign action (through #HIDE_REASSIGN attribute).
  • Restrict the list of users to whom a user can reassign a notification or request more information from (using #WF_REASSIGN_LOV).
  • Define vacation rules for any user and can update them appropriately.
  • Add list of item types that can be used in providing Worklist Access to or defining Vacation Rules for those item types
  • Reassign a notification that is not responded to and the workflow process waiting on that.

Business Event System

A Workflow Administrator can

  • Create, modify or test business events
  • Create or modify subscriptions, agents and systems

Workflow Mailer

A Workflow Administrator can
  • Setup Workflow Mailer to
    • Determine which response method should be used for a notification response to Email Notifications (Ex: template response or direct response)
    • Determine how frequently summary notifications are sent

 Status Monitor

A Workflow Administrator can

  • Perform administrative operations on a Workflow Process from Status Monitor screen. An admin can Cancel, Suspend, Retry, Skip a workflow process.
  • Set the display size of Status diagram that shows the current state of a Workflow in a diagrammatic representation.
  • Set default user preference values globally using workflow Configuration page.

More information can be obtained from the following documents:

Wednesday Jun 24, 2015

Make your workflows context dependent the right way


Oracle Workflow is context-agnostic. Oracle Workflow does not guarantee a specific application context to be available during the execution of a workflow process.

A workflow process may need certain application context to be initialized in order for a process activity to execute successfully. For example, if an activity submits a concurrent program request, it needs certain application context to be initialized.

Oracle Workflow provides ability for application code to manage application context for their workflow processes. Before executing a workflow process, it first allows to test the context. If the test determines that a specific application context should be initialized, it then allows to set the required context before continuing to execute the workflow process.

In order to manage application context from within a workflow process, Oracle Workflow supports the notion of Callback Function (popularly known as Selector Function). Hence, for a given item type a single function operates as both selector and a callback function.

  • Selector - Selects the appropriate process name to execute when the item type is initiated without specifying the process name.
  • Callback - To test and set application context required for the workflow process to execute.

Callback Function 

In this blog post we will only discuss the function modes for the Callback feature. A function mode is the condition under which the callback function implementation should do a certain processing.

  • TEST_CTX - Before executing a workflow process activity, determine if the current application context is correct for the given item type. In a typical case, the application context is evaluated by checking the values of but not limited to FND_GLOBAL.USER_ID, FND_GLOBAL.RESP_ID, FND_GLOBAL.RESP_APPL_ID and so on. These are Application Object Library (FND) global variables that determine if an appropriate application context is initialized or not.
    • NOTSET - Context has not been initialized. For example, if FND_GLOBAL.USER_ID is -1 it indicates an application context was not initialized.
    • FALSE - A context is already initialized but it is not correct for the given workflow item type. Workflow engine should switch context is allowed.
    • TRUE - A context is already initialized and it is valid for the given workflow item type.
    • Null - The item type does not depend on any context.
  • SET_CTX - Establish required application context for the item type.

Refer to Oracle Workflow Developer's Guide for Standard API for an Item Type Selector or Callback Function 

In a given session, Oracle Workflow executes the callback function each time it encounters a new item type and item key combination. For example, when a workflow process (identified by a given item type and item key) is initiated, the workflow engine executes the callback function only once before first activity. For the rest of the activities in the process, the selector function is not executed in that session. Now, in the same session if a new workflow process (identified by the same item type but a different item key) is initiated, the callback function is executed again.

Preserve Context

While it is extremely beneficial to allow application code to manage required application context during execution of a workflow process, it is also important to determine when the application context can be switched and when it cannot be. Oracle Workflow internally maintains a flag WF_ENGINE.PRESERVED_CONTEXT that determines whether context switching is allowed or not.

WARNING: This flag is INTERNAL ONLY and cannot be manipulated by the application code

Oracle Workflow initializes this flag with either TRUE or FALSE based on whether it is required to preserve the current application context or not.

  • TRUE - This value indicates that the workflow engine is required to preserve current context. This is typically when workflow engine executes in the foreground.
    • For example, if an approver signed into Worklist and approved a notification, the workflow engine executes in the foreground. Since it is required to preserve the current approver's context, workflow engine cannot switch to a different application context.
    • If the callback function returns FALSE in TEST_CTX mode, the workflow engine since it is required to preserve existing application context, it will not execute the callback function in SET_CTX mode. Instead, it will defer the workflow process to background engine that will then invoke the callback function in TEST_CTX and SET_CTX modes. 
  • FALSE - This value indicates that the workflow engine is not required to preserve current context. This is typically when the workflow engine executes in the background, such as initiated by Workflow Mailer or Workflow Background Engine concurrent request.

Following table summarizes how Oracle Workflow treats results of TEST_CTX mode in a given preserve context situation.

 TRUE  Set Context  Defer to Background Engine  No Change  No Change
 FALSE  Set Context  Set Context   No Change  No Change


It is very important to understand the nuances of context management within workflow process with regards to

  • What result to send back to workflow engine in TEST_CTX mode?
    • Clearly understand the difference between NOTSET and FALSE. They have completely different meanings and impact to workflow execution.
  • How workflow engine treats different TEST_CTX results in the context of preserve context flag?
    • Your workflow process may be deferred to workflow background engine and executed later on. If the background engine is not running, your workflow will not be executed.


Friday May 29, 2015

Increase throughput of your Workflow Mailers

The Workflow Notification Mailer is a component running on the Workflow Mailer GSM Service (also known as container). This service can host multiple instances of the Workflow Notification Mailer so that the load of sending and receiving e-mails can be shared, improving the overall performance. This is specially true as more and more applications moved from PLSQL-based notifications, that pretty much only required access to the database, to HTML/Framework-based notifications that also require access to the application server to retrieve the content of these good-looking notifications. 

Note: to learn more about Generic Service Management click here.

Creating a new component for the mailer allows the following:

  • Increase the number of processes for inbound and outbound processors - although this can also achieved simply by increasing the number of processors in the existing Notification Mailer 
  • Use a different SMTP account to process outbound messages and/or a different IMAP account for inbound processing
  • Specify a different correlation ID to dedicate message processing to a specific item type
  • Specify a user, responsibility and application different from the default one (SYSADMIN). This is typically done when specific profile values need to be applied for the applications user that the mailer will use to retrieve its content.

Creating another Notification Mailer component

 By creating a new Container a whole new set of components will be added to exclusively manage the components (mailers) and this way provide more scalability. The diagram below depicts what a Component Container is composed by.


 To create a new component follow this simple steps:

  • Connect to Oracle Apps with the responsibility Workflow Administrator Web Applications
  • Navigate to Oracle Applications Manager -> Workflow Manager
  • Click on Notification Mailer. Then click on the Create button on the top right part of the page
  • Select the Workflow Mailer service and hit Continue
  • Key in the corresponding parameter values for this new Notification Mailer.
  • Use the Advanced option to specify the Correlation Id and other parameters. The Inbound Agent is always WF_NOTIFICATION_IN while the Outbound Agent is WF_NOTIFICATION_OUT.

Creating a new Workflow Mailer service

A new Workflow Mailer component still has a limitation: the connection to retrieve HTML/Framework content is synchronized and this means that only one Java thread can retrieve the content at a time. Of course, this retrieval happens very fast, but still there is the chance of a bottle neck when the number of this kind of notifications is very high. 

To increase the performance in this scenario a new Workflow Mailer service is the solution, and it can be done as follows:

  • Connect to Oracle Apps with the responsibility Workflow Administrator Web Applications
  • Navigate to Oracle Applications Manager -> Workflow Manager
  • Under column Container, click on Workflow Mailer Service and hit the Create New button
  • Enter the names desired for the new service. The image below provides an example
  • Use the button Add from Available Shits to indicate the availability of this new service. Use the one called Active 24 hours every day.

  • Save the changes

Now new Workflow Notification component can be created with the steps given earlier, but instead of using service Workflow Mailer, use New Workflow Mailer with the desired parameter values.

Thursday Dec 11, 2014

e-Signing a Workflow Notification fails on Internet Explorer on Windows 7

With the launch of Windows 7 Operating system, Microsoft has ceased to support CAPICOM DLL. CAPICOM is an ActiveX control used to digitally sign data, display certificates from browser and to encrypt and decrypt data. In Oracle Workflow Notification System, CAPICOM has been used to digitally sign Notification data in Workflow Notifications. This is only used when signing a workflow notification from Internet Explorer. Now that this DLL is not included in Windows 7 and further versions of Windows OS, the signing process of a Workflow Notification, requiring certificate based signature, errors out with the following message:

"Verification of signature has failed"

Oracle Workflow provides a solution to this issue. The patch numbers for obtaining this solution on the following code-lines are as follows:

  • Release - 18921580
  • Release 12.1.3 - 18921687:R12.OWF.B
  • Release 12.2.3 - 19410235:R12.OWF.C

Due to the removal of dependency on an ActiveX control, there are certain subliminal changes in the user interface for signing a workflow notification. The following are two changes:

1. Change in the look of Certificate Selection window. The list of certificates to be selected are now loaded in an Applet. This is as shown below:

2. A small time lag after clicking on Sign button. A informative message conveying the same is displayed. The screenshot of the same is as shown below.Please wait for the applet to be loaded after clicking on "Sign". There would be an applet loaded as shown in earlier image a user can select certificate for signing the notification data.

Apart from these negligible changes, the whole signing experience is in parity with that which existed before Windows 7 plus Internet Explorer as browser.

Tuesday Nov 11, 2014

Scheduling Workflow Mailer Stop and Start events as good practice

The Workflow Notification Mailer runs on the generic service called Workflow Mailer Service, which in turn uses the Standard workshift, active 24 hours every day. This means the notification mailer runs non-stop.

 Not allowing the mailer to restart periodically may present some issues:

  • The corresponding log file corresponding to the Workflow Mailer Service will grow several gigabytes large and eventually the OS will error due to I/O file handling.
  • Some SMTP servers and IMAP servers used for outbound and inbound processing respectively, have time limits to the sessions connected to them. If the mailer reaches those time limits it will encounter a connection error and will be abnormally brought down.
  • Similarly the same might happen to the session the mailer establishes to retrieve HTML and framework content from the application server. This is less likely though but it has been seen.
  • The size of the INBOX folder in the IMAP server won't get expunged as long as the mailer does not refreshes the session. For a purged INBOX folder it takes the mailer to restart - and for parameter Expunge Inbox on Close to be set to Yes.

In order for the issues above to be minimized, a good practice is to schedule the Mailer to automatically go down and start up periodically, daily preferably. This can be done by using the event schedule feature provided in the Workflow Mailer configuration. This can be done as follows:

First, connect to EBS using the responsibility Workflow Administrator Web Applications and go to Workflow Manager

Then edit the Notification Mailer configuration. Continue going through the train stages until you reach the Schedule Events stage:

Use the corresponding link/button to create two events, one for stopping the mailer and one for starting it up:

In the screen shot above the stopping event is set to happen at 11:50 PM and the starting event at 11:55 PM, and these are set to repeat every using 1440 minutes as the interval. If no interval value is specified the stop/start events are raised just once.

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. 



Wednesday Aug 06, 2014

Now Available: Oracle Mobile Approvals for iOS - Version 1.0.0


Oracle Mobile Approvals for Oracle E-Business Suite lets you respond on-the-go to your pending approval requests. From your phone, anywhere and anytime, take quick action on approval requests for expenses, requisitions, purchase orders, recruitment vacancies and offers, and more.

- Quickly filter approval requests by sender or subject
- Review at a glance header and line item details, action history, and comments
- Approve or reject with or without comments, or request more information

Oracle Mobile Approvals for Oracle E-Business Suite is compatible with Oracle E-Business Suite 12.1.3 and 12.2.3 and above. To use this app, you must be a user of Oracle E-Business Suite, with mobile services configured on the server side by your administrator.



Oracle Mobile Approvals for Oracle E-Business Suite 1.0.0 is available on Apple's iTunes Store  for download.

This app works against Oracle E-Business Suite Release 12.1.3 and above and 12.2.3 and above.


Oracle Mobile Approvals requires set up on Oracle E-Business Suite instance to support connections from the mobile app. Following patches are required to be applied.


Additional Resources


New versions of the smartphone app Approvals for EBS has been released. Refer to following posts.

Please go to the blog post for latest version of Approvals app and post your comments.

Friday Aug 16, 2013

Understanding Workflow Errors - Part 2

This post is a follow up to Understanding Workflow Errors - Part 1 that deals with some of the most common errors raised when some of the Workflow Engine APIs are used. 

The way to trap and continue processing upon finding these errors is the same: evaluate the content of global variable WF_CORE.error_name.

Error message: 3103 Attribute 'ATTRIBUTE' does not exist for item 'TYPE/KEY'


The most likely reason for this to happen is a change in the Workflow definition. For instance, an attribute is added to the definition while there are open workflows  not having it. Then you attempt to set a value for it and notice new processes have no issues but the ones created before the change will fail.

Whenever possible these regressions should be foreseen and addressed in the design of the Workflow definition. A possible workaround is to add the supporting plsql code to check for the exception:

    if WF_CORE.error_name='WFENG_ITEM_ATTR' then
    end if;

Error message: 3120 Activity 'TYPE/ACTID' has no performer


All performers of notification activities are taken from view WF_ROLES. The most typical reason for this error is the originally assigned user/role has been expired. While the correct fix is to unexpire the performer and let the workflow complete, there are two possible ways to go around:

1. Change the value to the attribute holding the name of the performer. For instance, if there is an item attribute RECIPIENT pointing to expired user JSMITH then change it to an active user/role, say JHOPKINS. You will need to call this from a SQL*Plus session:

   WF_ENGINE.SetItemAttrText(<type>, <key>, 'RECIPIENT', 'JHOPKINS');

2. The other alternative is to change all references in ALL the workflow runtime tables to change anything related to JSMITH and change it to the taking over user JHOPKINS:

  l_attributes wf_parameter_list_t;
  WF_EVENT.AddParameterToList('OLD_USER_NAME', 'JSMITH', l_attributes);
  WF_EVENT.AddParameterToList('USER_NAME', 'JHOPKINS', l_attributes);
  WF_LOCAL_SYNCH.Propagate_Role(p_orig_system    => <orig system>, --for instance, 'FND_USR' or 'PER'
                                p_orig_system_id => l_orig_system_id, --for instance, 29984
                                p_attributes     => l_attributes);

As always, use care and try these APIs on a test environment before using them in production

Error message: 3133 Activity instance 'NAME' is not a notified activity for item 'TYPE/KEY'.


When it is needed that the processing of a workflow stops to wait for something to happen a BLOCK function can be used. When the block function runs the activity goes into NOTIFIED status. Then, to resume the processing, an explicit call to WF_ENGINE.CompleteActivity must be made. But if the activity is not in notified status then the API will raise WFENG_NOT_NOTIFIED.

There is no straightforward action to deal with this error. Rather, troubleshooting must be made to see why the activity did not go into NOTIFIED status. Sometimes the reason is that the workflow process continued to the next activity, leaving it complete or did not even reach it. A good way to understand what the workflow process has done is to run the seeded script wfstat.sql. Check the output and follow the execution path.

Friday Apr 12, 2013

Understanding Workflow Errors - Part 1

Workflow Engine and other public APIs throw a variety of user-defined exceptions to indicate specific Engine conditions. It is important that Workflow Developers and Administrators understand the meaning of these errors and know how to deal with them. In this post, we will cover some of the important Workflow Engine related errors and understand how to deal with them.

Engine Errors

3122: Duplicate item 'ITEM_TYPE/ITEM_KEY' could not be created


Cause: This error may be thrown from WF_ENGINE.CreateProcess when you attempt to create a new instance of a workflow item. This error indicates that the Item Type and Item Key combination you have used to launch a new workflow instance already exists.

Fix: Use an unique item key for that item type

3136: Item 'ITEM_TYPE/ITEM_KEY' cannot be accessed while synchronous process in progress.


Cause: This error may be thrown from WF_ENGINE.CreateProcess when attempt to create a new synchronous workflow instance while another synchronous workflow  instance is already running in the same session. All synchronous workflow instances are created with item key #SYNCH to make sure the workflow instances starts and completes in the same session.

Fix: Wait till the existing synchronous workflow instance completes before creating another one.

3146: Commit happened in activity/function 'ACTIVITY/FUNCTION'


Cause: While a workflow instance was executing, a commit was issued inside a PLSQL procedure associated to a workflow function activity before or after an error occurred in that PLSQL procedure. The Workflow Engine traps errors produced by function activities by setting a savepoint before each function activity. If an activity produces an unhandled exception, the engine performs a rollback to the savepoint, and sets the activity to the ERROR status. 

Fix: You should never commit within the PL/SQL procedure of a function activity. The Workflow Engine never issues a commit as it is the responsibility of the calling application to commit.

How to Catch these Errors?

Each error above is associated to an Error Code. Within your PLSQL code, you should following method to capture the specific error based on the error code to act on it.

   Wf_Engine.CreateProcess('ITEM_TYPE', 'ITEM_KEY', 'PROCESS_NAME');
    when others then
if (wf_core.error_name = 'WFENG_ITEM_UNIQUE') then
        -- Item already exists, use a unique item key
        Wf_Engine.CreateProcess('ITEM_TYPE', 'ITEM_KEY', 'PROCESS_NAME');
      end if;

Friday Nov 16, 2012

New Worklist features on 12.1.3

Following new Worklist features are available on E-Business Suite 12.1.3 via Patch 13646173.

Ability to view comments on top of a notification

If an action is performed on a notification such as Reassign, Request for Information or Provide Information, the recipient of the notification will see who performed the last action and the associated comment on top of the notification.

Reassigning a request for information notification

If an approver requests more information on a notification from it's submitter, the submitter now has two options

  1. Answer Request for More Information
  2. Transfer Request for More Information

If the submitter thinks the requested information can be provided by another user, he/she can transfer the request to the other user. Please note that only Transfer is supported for Request for More Information. Once transferred, the submitter cannot access the notification and provide the requested information.

Use actual sent date when reassigning a notification

The Sent field in notification header always showed the date on which the notification was first created. If the notification was later reassigned, the Sent date was not updated to show the last action date. This caused problems in following scenario

  1. Approval notification was sent to JACK on 01-JAN-2012
  2. JACK waited for 10 days before reassigning to JILL on 10-JAN-2012
  3. JILL does not see the notification as sent on 10-JAN-2012, instead sees it as sent on 01-JAN-2012
  4. Although the notification was originally created on 01-JAN-2012, it was sent to JILL only on 10-JAN-2012

The enhancement now shows the correct sent date in Worklist and Notification Details page.

Figure 1 - Depicts all the above 3 features

Related Action History for response required notification

So far it was possible to embed Action History of an response-required notification into another FYI notification using #RELATED_HISTORY attribute (Please refer to Workflow Developer Guide for details about this attribute). The enhancement now enables developers to embed Action History of one response-required notification into another response-required notification.

To embed Action History of one response-required notification into another, create message attribute #RELATED_HISTORY. To this attribute set a value during run-time in the following format.


The TITLE, ITEM_TYPE and ITEM_KEY are optional values.

  1. TITLE is used as Related Action History header title. If TITLE is not present, then a default title "Related Action History" is shown.
  2. If ITEM_TYPE is present and ITEM_KEY is not, For Example: {TITLE}[ITEM_TYPE]PROCESS_NAME:ACTIVITY_LABEL_NAME , the Related Action History is populated from parent item type of the current item.
  3. If both ITEM_TYPE and ITEM_KEY is present, For Example: {TITLE}[ITEM_TYPE:ITEM_KEY]PROCESS_NAME:ACTIVITY_LABEL_NAME , the Related Action History is populated from that specific instance activity.

Figure 2 - Depicts Related Action History feature

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. 

Tuesday Jun 19, 2012

E-Business Suite Proactive Support - Workflow Analyzer


The Workflow Analyzer is a standalone, easy to run tool created to read, validate and troubleshoot Workflow components configuration as well as runtime. It identifies areas where potential problems may arise and based on set of best practices suggests the Workflow System Administrator what to do when such potential problems are found. This tool represents a proactive way to verify Workflow configuration and runtime data to prevent issues ahead of time before they may become of more considerable impact on a production environment.


Since it is standalone there are no pre-requisites and runs on Oracle E-Business applications from 11.5.10 onwards. It is installed in the back-end server and can be run directly from SQL*Plus.

The output of this tool is written in a HTML file friendly formatted containing the following on both workflow Components configuration and Workflow Runtime data:
  • Workflow-related database initialization parameters
  • Relevant Oracle E-Business profile option values
  • Workflow-owned concurrent programs schedule and Workflow components status
  • Workflow notification mailer configuration and throughput via related queues and table
  • Workflow-relevant recommended and critical one-off patches as well as current code level
  • Workflow database footprint by reading Workflow run-time tables to identify aged processes not being purged. It also checks for large open and closed processes or unhealthy looping conditions in a workflow process, among other checks.

See a sample of Workflow Analyzer's output here

Besides performing the validations listed above, the Workflow Analyzer provides clarification on the issues it finds and refers the reader to specific Oracle MOS documents to address the findings or explains the condition for the reader to take proper action.

How to get it?

The Workflow Analyzer can be obtained from Oracle MOS Workflow Analyzer script for E-Business Suite Workflow Monitoring and Maintenance (Doc ID 1369938.1) and the supplemental note How to run EBS Workflow Analyzer Tool as a Concurrent Request (Doc ID 1425053.1) explains how to register and run this tool as a concurrent program. This way the report from the Workflow Analyzer can be submitted from the Application and its output can be seen from the application as well.

Tuesday Aug 03, 2010

SSL in Oracle Workflow


This topic is created to give better understanding of how Oracle Workflow uses SSL in different modules and if in case of an issue how to troubleshoot it.

Secure Sockets Layer (SSL)

SSL is a technology that defines the essential functions of mutual authentication, data encryption, and data integrity for secure transactions. Exchange of data between the client and server in such secure transactions is said to use the Secure Sockets Layer (SSL). SSL uses 2 types of Certificates:

  • User certificates - These are Certificates issued to servers or users to prove their identity in a public key/private key exchange.
  • Trusted certificates - These are Certificates representing entities whom you trust - such as certificate authorities who sign the user certificates they issue.

Read more information in MOS Doc Enabling SSL in Oracle Applications Release 12.

Oracle Workflow as SSL Client

Oracle Workflow modules act as a HTTP/SSL client in different scenarios connecting to the EBS or non-EBS SSL servers. For SSL/TLS connection, the Workflow's client process should have access to the following.

  • Necessary SSL libraries (mostly available)
  • Trusted certificates (ca.crt) used to validate if the server certificate is valid.
  • Client certificates (if client authentication required).

The Key/Trust Store accessible to the Workflow process should have the correct certificates for the client code to participate in SSL handshake with the server. In summary, the SSL client should be able to validate the SSL server certificate's authenticity using it's root certificate and exchange cipher suites with the server.

Workflow as SSL Client

When troubleshooting SSL issues with Workflow, it is important to understand in detail as to where exactly each Workflow's HTTP client process executes so the necessary setup can be verified.

Workflow Manager UI

Workflow Notification Mailer is configured from Oracle Applications Manager >> Workflow Manager screens. When configuring IMAP and SMTP servers with SSL Enabled option checked, the Workflow Manager code attempts to connect to the IMAP and SMTP servers over SSL to validate connectivity before saving the configuration parameters. Since the OAM UI executes within OACORE OC4J container, it would use $OA_JRE_TOP/bin/java. The root certificate in the JRE's store should correspond to the Server Certificates on IMAP and SMTP servers in order for the connection to succeed.

Workflow Notification Mailer

Mailer executes within the Concurrent Manager process in the CM tier. The Java run-time used to run Mailer Service is configured as $AF_JRE_TOP/bin/java. If SSL is enabled, Mailer initiates SSL connection for following three reasons.

  • SMTP server - Establish SMTP connection to send e-mails.
  • IMAP server - Establish IMAP connection to receive e-mails.
  • EBS or non-EBS web server -Establish HTTP connection to a Web server to fetch OAF content or if images are to be embedded, connect to a content server.

Workflow Status Monitor

When Status Monitor page is loaded, there are two separate actions.

  • Loading of the OAF page first
  • Then loading of the Monitor Applet within that above OAF page that shows the diagram

Status Monitor makes HTTP requests during both actions above.

  • OAF controller - When status monitor diagram page is loaded, this OAF controller code runs within OC4J? and it acts as HTTP client making a loop back request to Web server to fetch tags to embed the Status Monitor applet. If any exception occurs while loading the status monitor diagram page, it will result in OAF page error. OC4J runs using JRE at $OA_JRE_TOP/bin/java.
  • Monitor Applet - The monitor applet code running in Web Browser JVM (JInitiator or Sun JRE plugin) makes HTTP requests to fetch data to display diagram on the applet. The applet loads only after the status monitor page loads successfully above in (a). Any exceptions within the applet can only be tracked through Java console output on the browser.

Workflow Business Event System

From R12.1, Business Event System supports invoking web services. This includes following steps.

  • Consuming the WSDL - WSDL is consumed in a OAF page to create web service meta-data. The controller makes HTTP(S) request to the WSDL URL. In order for the OAF page to successfully connect to a HTTPS WSDL URL, the OC4J JVM should have access required SSL libraries and root certificate installed.
  • Invoking the web service - Invocation of the earlier consumed web service may occur in one of the following two processes.
    • OC4J - If the web service is invoked from a OAF page using synchronous subscription, then the OC4J process acts as SSL client. Like any OAF page, the process runs using $OA_JRE_TOP/bin/java
    • Concurrent Manager - If the web service is invoked using a asynchronous subscription, it is executed by Java Deferred Agent Listener in Agent Listener Service process. Like Workflow Mailer Service, this runs using $AF_JRE_TOP/bin/java

When there are issues...

In summary, Workflow's SSL client code executes in following run-time environments

  • $OA_JRE_TOP/jre/bin/java (Web Tier)
  • $AF_JRE_TOP/jre/bin/java (Concurrent Tier)
  • JInitiator
  • Sun JRE

For any SSL handshake errors involving Workflow code as client,

  1. Always verify that the JVM from which Workflow code initiates a SSL connection has the required root certificate installed
  2. If the server presents a certificate chain to validate, then the complete chain is installed on the client side.
  3. Most importantly, as part of SSL enablement of EBS, is the trusted certificate/certificate chain installed into internal EBS JVMs that could potentially act as SSL client to our own EBS servers.

How to check SSL connectivity?

SSL connectivity can be verified from the run-time environment where Workflow acts as client to a SSL server to confirm if the setup is correct. This helps troubleshoot general SSL setup without involving Workflow code.

For example, for Status Monitor SSL issues,

  1. - Check connectivity from $OA_JRE_TOP/bin/java by using this JRE's trust-store to the web-server.
  2. Status Monitor Applet - Check connectivity from client machine based on appropriate run-time such as Sun JRE or JInitiator. For JInitiator, the certificates are stored under <JInitiator Home>\lib\security\certdb.txt. Java run-time is accessible using <JInitiator Home>\bin\java.exe

For connectivity testing following can help.

  1. openssl utility available in Unix based platforms
  2. This sample
    class can be used to test a handshaking from the Java run-time
    1. Download the Java class source code in a directory. There is no package name for this Java class.
    2. Compile as
      javac -classpath $CLASSPATH
    3. Run it as below from required Java run-time
      java -classpath . -Dport=443 -Dtruststore=<jre/lib/security /cacerts> SSLSocketClientTest

How to update the JDK Cacerts File?

These steps are mentioned as part of EBS SSL setup MOS Doc Enabling SSL in Oracle Applications Release 12.

  1. Navigate to the $OA_JRE_TOP/lib/security directory
  2. Backup the existing cacerts file.
  3. Copy your ca.crt and server.crt files to this directory. Issue the following command to insure that cacerts has write permissions. 
  4.    chmod u+w cacerts
  5. Add your Apache ca.crt and server.crt to cacerts
  6. keytool -import -alias ApacheRootCA -file ca.crt -trustcacerts -v -keystore cacerts
    keytool -import -alias ApacheServer -file server.crt -trustcacerts -v -keystore cacerts
  7. When prompted enter the keystore password (default password is changeit).

Certificate Chains

A certificate chain establishes as chain of trust. The certificate issued by a CA is not signed by their own root certificate but is signed by another CA's root certificate. For example, VeriSign is the most common CA whose user certificates that all the web browsers trust. This is because, the web browsers are pre-installed with VeriSign's root certificate. If another CA XyZ issues a certificate signed using VeriSign's root certificate, then the browser can trust the certificate from XyZ simply because the root certificate is issued by CA.

The chain of trust is

VeriSign's Root CA Certificate >> XyZ's Intermediate CA Certificate >> Server Certificate

There must be a chain of trust from the server certificate up through intermediate authorities up to one of the trusted Root Certificate in order for the server to be trusted. If the client is unable to build the chain of trust starting from the server certificate up to a trusted Root Certificate, then the SSL handshake fails with X509CertChainIncompleteErr.

How to rectify this?

Concatenate all the certificates in the chain into one single file as per the order in which they appear in the chain. Server Certificate should be the first one in the chain and followed by the intermediate certificates and finally the root certificate. You can verify this order and download the certificates using a Web browser. Import the concatenated certificate into the JDK from which the Workflow's code acts SSL client.


It is just a matter of establishing trust between the client and the server. Does the client have access to the certificates to trust the server?

Leveraging Oracle Workflow for Declarative PageFlow

This blog post contributed by Dilbagh Singh.

Oracle Workflow can be leveraged in Oracle Applications Framework for designing declarative Page Flow, which is used to handle conditional navigation rules.This is a better way to handle page navigations if you would want to avoid static, complex logic in the page controllers to handle different navigation scenarios. This requires a user to create a Pageflow workflow definition which is associated with the OA Framework based pages. Then there are certain APIs which are used in transition flow of the workflow. I would like to focus on creating a Workflow Definition for the page flow and how to interact with it as the transaction proceeds.

1. Create the OA Framework pages
Create the OA Framework pages you would want the page flow to consist of.

2. Design the Workflow Definition for the Page Flow
Define the Workflow in the workflow builder following the below mentioned guidelines:

  • Add a function activity for each page in the transaction. For each activity, decide whether to:

    • Associate the result with this activity (for conditional navigation) OR

    • Explicitly mark the activity as blocked by associating a Blocking Function (wf_standard.block), a PLSQL function with it

      • When the Workflow Engine encounters a blocking activity it stops and waits for some sub-process or external entity to provide the information it needs to proceed. So, with the mapping between transaction pages and the blocking activities in the Workflow, you can query the activity data to find out what page ought to be rendered.

  • Add a FORM attribute to each page-related blocking activity. The FORM attribute would have a value which specifies the next page to be traversed.

3. Start the Page Flow

  • You can start the page flow from a OAF page directly or upon triggered by some event or can start it from a static page by using the API OANavigation which provides createProcess() and startProcess()

  • You can then transition through the workflow by using getNextPage() from OANavigation API. There are different overloaded getNextPage APIs for transitioning through workflow, transitioning to next page, resuming a saved transaction etc. You can get the code snippets in the OAF Dev guide.

4. Clear the Workflow Context
  • Since the Workflow transaction holds an independent local JDBC connection, you must override the OADBTransaction.beforePoolCheckin() method in your root UI application module and call getDBTransaction.clearWorkflowInfo() to release the connection.

Some More features:

  1. Workflow-based page flows automatically support browser Back button navigation at the Workflow technology layer. Whenever user moves between the pages using browser Back button and resubmits, the workflow rewinds itself to the appropriate blocking activity so it stays in synch with the user's current navigation position.

  2. Workflow Page Flow can be used with Train and Navigator bar in a page, which the traditional 'Destination Function' based approach does not support.

  3. For the most part, you handle application errors in your Workflow-based page flows the same way that you do in any other context. That said, however, you need to consider the possibility that the user might fix mistakes and resubmit the form whenever you introduce workflow code.

Monday Aug 02, 2010

Workflow Engine vs Business Event System

Oracle Workflow has two major execution engines.

    • Workflow Engine
    • Workflow Business Event System

Here is a simple comparison of what they process and their associated background components.

Workflow Engine Workflow Business Event System
Executes workflow processes created using Windows based Workflow Builder client Executes subscriptions to business events registered using Event Manager in Workflow Administrator Web Applications Responsibility
Entry point foreground APIs are WF_ENGINE.CreateProcess and WF_ENGINE.StartProcess Entry point foreground API is WF_EVENT.Raise
Execution deferred to background by enqueuing message to AQ WF_DEFERRED_QUEUE_M Execution deferred to background by enqueuing message to AQ WF_DEFERRED
Entry point background API is WF_ENGINE.Background Entry point background API is WF_EVENT.Listen
Background processing is done by Concurrent Program - FNDWFBG (Workflow Background Engine) Background processing is done by GSC Component - Workflow Deferred Agent Listener
Background Engine is submitted as recurring concurrent request from SRS form or Workflow Manager in OAM Agent Listener is a service component managed through Workflow Manager in OAM

This blog post is as a result of confusion about what AQ and corresponding background process comes into picture when troubleshooting a given problem. For example,

  • When troubleshooting issues with Business Event System, users verify that the Workflow Background Engine is running.
  • When troubleshooting deferred workflow processes, users verify that the Workflow Deferred Agent Listener is running.

It is important to understand the two processing engines in Oracle Workflow, the supporting background components and how these two engines integrate with each other.



« June 2016