Thursday Dec 03, 2015

Support of multiple e-mail addresses for a single user or role

In Oracle EBS 12.0 and 12.1 the Workflow notification system was not enabled to send e-mail notifications to users or roles who happened to have multiple e-mail addresses associated to them. For instance, if user JDOE had two e-mail addresses ( and only one of them could be associated to the user for the Workflow notification mailer to send any e-mail notifications.

This limitation has been lifted in EBS 12.2.5 and now both users and roles can define multiple e-mail addresses as needed. This means that still a notification is intended for one recipient but the same notification will be sent to all associated e-mail addresses.

Note: The limit size of the table column holding the list of e-mail addresses is 320 so bear this limitation in mind. This should not be an issue as it is not common to see a single user with as many e-mail addresses so as to pass this limit. Consider the use of a role and multiple users associated to that role if this limit is still an issue.

Defining multiple e-mail addresses for a user or role

  • If the target role is an FND user then this setting takes place in the corresponding user definition form:

  • If the target is an ad-hoc role or ad-hoc user the assignment takes place when the user or role is being created. For instance:
     WF_DIRECTORY.CreateAdHocUser(name => 'ADHOC-USER',
                                  display_name => 'ADHOC-USER',
                                  notification_preference => 'MAILHTML',
                                  email_address => ',',
                                  expiration_date => SYSDATE+1);
  • If the user or role is created from code, the setting will look like:
       l_params wf_parameter_list_t;
       WF_EVENT.AddParameterToList('USER_NAME', 'JDOE', l_params);
       WF_EVENT.AddParameterToList('MAIL', ',', l_params);
       WF_LOCAL_SYNCH.propagate_user(p_orig_system => 'FND_USR',
                                     p_orig_system_id => 123435,
                                     p_attributes => l_params);

Notification action history

When the Notification Mailer receives the e-mail response the from e-mail address is compared against the list of addresses corresponding to the target of the notification recipient. If there is a match the responder is set to the value of the recipient. If no matches are found then one of two actions will happen:

  • If the Notification Mailer Parameter Allow Forwarded Response is set to Yes the responder of the notification is set to the value of the from e-mail address, or
  • If not, such e-mail response is treated as an unsolicited e-mail: the notification is not processed and a message is sent to the sender indicating so.

What happens with invalid addresses? 

In the event that a user or role was created using invalid e-mail addresses - subsequently causing the SMTP server to fail to deliver e-mail to them - the following takes place: 

  • If the notification is successfully delivered to at least one e-mail address mail status of the notification is set to SENT and the invalid addresses are added to the in-memory list of invalid addresses so that they are not attempted further on.
  • If all of them are invalid the notification mail status is set to FAILED and the user/role notification preference is set to DISABLED

In both cases a notification is sent to the user SYSADMIN indicating that a user/role contains invalid addresses and require fix.

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:

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

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.

Wednesday Oct 15, 2014

Improving worklist notification response performance by deferring the processing


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 '' 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$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'.


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

Tuesday Nov 13, 2012

Using GMail's SMTP and IMAP servers in Notification Mailer


GMail offers free, reliable, popular SMTP and IMAP services, because of which many people are interested to use it. GMail can be used when there are no in-house SMTP/IMAP servers for testing or debugging purposes. This blog explains how to install GMail SSL certificate in Concurrent Tier, testing the connection using a standalone program, running Mailer diagnostics and configuring GMail IMAP and SMTP servers for Workflow Notification Mailer Inbound and Outbound connections.

GMail servers configuration

SMTP server

Host Name
SSL Port  465
TLS/SSL required  Yes
User Name  Your full email address (including or
Password  Your gmail password

 IMAP server

 Host Name
 SSL Port
TLS/SSL Required
 User Name
 Your full email address (including or
 Password Your gmail password

GMail SSL Certificate Installation

The following is the procedure to install the GMail SSL certificate

  • Copy the below GMail SSL certificate in to a file eg: gmail.cer


  • Install the SSL certificate into the default JRE location or any other location using below command
  • Installing into a dfeault JRE location in EBS instance
        # keytool -import -trustcacerts -keystore $AF_JRE_TOP/lib/security/cacerts  -storepass changeit -alias gmail-lnx_chainnedcert -file gmail.cer
  • Install into a custom location

        # keytool -import -trustcacerts -keystore <customLocation>  -storepass changeit -alias gmail-lnx_chainnedcert -file gmail.cer
       <customLocation> -- directory in instance where the certificate need to be installed

  • After running the above command you can see the following response

        Trust this certificate? [no]:  yes
        Certificate was added to keystore

Running Mailer Command Line Diagnostics

  • Run Mailer command line diagnostics from conccurrent tier where Mailer is running, to check the IMAP connection using the below command

$AFJVAPRG -classpath $AF_CLASSPATH -Dprotocol=imap -Ddbcfile=$FND_SECURE/$TWO_TASK.dbc -Dport=993 -Dssl=Y -Dtruststore=$AF_JRE_TOP/lib/security/cacerts -Daccount=<gmail username> -Dpassword=<password> -Dconnect_timeout=120 -Ddebug=Y -Dlogfile=GmailImapTest.log -DdebugMailSession=Y

  • Run Mailer command line diagnostics from concurrent tier where Mailer is running, to check the SMTP connection using the below command 

 $AFJVAPRG -classpath $AF_CLASSPATH -Dprotocol=smtp -Ddbcfile=$FND_SECURE/$TWO_TASK.dbc -Dport=465 -Dssl=Y -Dtruststore=$AF_JRE_TOP/lib/security/cacerts -Daccount=<gmail username> -Dpassword=<password> -Dconnect_timeout=120 -Ddebug=Y -Dlogfile=GmailSmtpTest.log -DdebugMailSession=Y

Standalone program to verify the IMAP connection

Run the below standalone program from the concurrent tier node where Mailer is running to verify the connection with GMail IMAP server. It connects to the GMail IMAP server with the given GMail user name and password and lists all the folders that exist in that account. If the GMail IMAP server is not working for the  Mailer check whether the PROCESSED and DISCARD folders exist for the GMail account, if not create manually by logging into GMail account.

Sample program to test GMail IMAP connection

 The standalone program can be run as below

 $java GmailIMAPTest GMailUsername GMailUserPassword           

Standalone program to verify the SMTP connection

Run the below standalone program from the concurrent tier node where Mailer is running to verify the connection with GMail SMTP server. It connects to the GMail SMTP server by authenticating with the given user name and password  and sends a test email message to the give recipient user email address.

Sample program to test GMail SMTP connection

The standalone program can be run as below

 $java GmailSMTPTest GMailUsername GMailPassword recipientEmailAddress   


  • As is an external domain, the Mailer concurrent tier should allow the connection with GMail server
  • Please keep in mind when using it for corporate facilities, that the e-mail data would be stored outside the corporate network

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?


« July 2016