Calling a HTTPs POST REST url web service which is SSL Certificate Secured Oracle Service Bus OSB

In one of my projects, I had a requirement to call a web service which was a REST service and I had to POST XML content to the web service. The web service URL demanded to query parameters though and the service only wanted a XML to be POSTed.
The service was Certificate SSL secured with HTTPs basic authentication.

So here are the steps which I did using Oracle Service Bus.

Firstly, I went to the UNIX box the ran the below command to load the certificate from the web service.
I used the openssl utility to load the certificate. Other option is any browser to do the same. The certificates nature vary from being a chain of certificates being CA signed or a single self- signed certificate. In my case it turned out to be a single self signed certificate.
Here is the command -

openssl s_client -connect host:port | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' > /..../somename.cert

Once the certificate was loaded. I had to loaded it up into the keystore of weblogic. To load it, I used the keytool utility.

Loading into the Java Keystore -

keytool -import -trustcacerts -keystore /appl/oracle/dev/fmw/11g/java/jrockit-jdk1.6.0_81/jre/lib/security/cacerts -noprompt -alias somealias -file somename.cert



Loading into the Default weblogic demoTrust keystore. Note, for production, it can be the Custom Trust store.

keytool -import -trustcacerts -keystore /appl/oracle/dev/fmw/11g/product/wlserver_10.3/server/lib/DemoTrust.jks -noprompt -alias somealias -file somename.cert

and the work for the certificate part was done.

Now, since the service was HTTPs basic authentication secured too, so an OSB Service Account was used to provide a static username and password and associate it with the Business Service.

After create the Business Service, I had too only put the XML content in the Request panel and the work was done.

Importance of Synchronous BPEL composite using File Adapter

By default, the JDeveloper wizard generates asynchronous WSDLs when you use technology adapters. Typically, a user follows these steps when creating an adapter scenario in 11g:
1) Create a SOA Application with either "Composite with BPEL" or an "Empty Composite". Furthermore, if  the user chooses "Empty Composite", then he or she is required to drop the "BPEL Process" from the "Service Components" pane onto the SOA Composite Editor. Either way, the user comes to the screen below where he/she fills in the process details. Please note that the user is required to choose "Define Service Later" as the template.

2) Creates the inbound service and outbound references and wires them with the BPEL component:
 
  3) And, finally creates the BPEL process with the initiating activity to retrieve the payload and an activity to write the payload.

This is how most BPEL processes that use Adapters are modeled. And, if we scrutinize the generated WSDL, we can clearly see that the generated WSDL is one way and that makes the BPEL process asynchronous (see below)


In other words, the inbound FileAdapter would poll for files in the directory and for every file that it finds there, it would translate the content into XML and publish to BPEL. But, since the BPEL process is asynchronous, the adapter would return immediately after the publish and perform the required post processing e.g. deletion/archival and so on.  The disadvantage with such asynchronous BPEL processes is that it becomes difficult to throttle the inbound adapter. In otherwords, the inbound adapter would keep sending messages to BPEL without waiting for the downstream business processes to complete. This might lead to several issues including higher memory usage, CPU usage and so on.
In order to alleviate these problems, we will manually tweak the WSDL and BPEL artifacts into synchronous processes. Once we have synchronous BPEL processes, the inbound adapter would automatically throttle itself since the adapter would be forced to wait for the downstream process to complete with a before processing the next file or message and so on.
Please see the tweaked WSDL below and please note that we have converted the one-way to a two-way WSDL and thereby making the WSDL synchronous:

Add a activity to the inbound adapter partnerlink at the end of your BPEL process e.g.

Finally, your process will look like this:

You are done.

Please remember that such an excercise is NOT required for Mediator since the Mediator routing rules are sequential by default. In other words, the Mediator uses the caller thread (inbound file adapter thread) for processing the routing rules. This is the case even if the WSDL for mediator is one-way.