SOA Suite PS5 Email (UMS) Adapter

With the release of Soa Suite Patch Set 5 we can now try out the new UMS Email adapter. The UMS adapter allows you to listen for new mail or send a mail from a service component. Combined with BPEL it’s now relative easy to process email bodies or attachments.  To read more and test it yourself check my blogpost on Amis Technology.

Publish EDN JMS events from ADF BC

With ADF BC ( Business Components ) you can fire Event Delivery Network CRUD events from ADF BC entities which can be captured and handled by the Oracle SOA Suite. In this blogpost we will use the JMS implementation of EDN plus WebLogic Store and Forward for the reliable delivery to the SOA Suite server ( this way we can bounce SOA without effecting the Web Applications ).

To make this possible on a different ADF WebLogic server then the SOA Suite Server, we need to do the following steps.

First we need to add a WebLogic shared Library.  Copy the oracle.soa.fabric_11.1.1 and oracle.soa.workflow_11.1.1 folders from the SOA Suite Oracle Home (  Oracle_SOA1\soa\modules ) to your own WebLogic Middleware home. Put those two folders on the same level directory level.

Then we can add these jars to our own WebLogic Server. Go to deployments and add the following jar  oracle.soa.workflow_11.1.1\oracle.soa.workflow.wc.jar ( this contains a manifest which loads the other jars ). Target this shared library to the right WebLogic servers.

We need to add this shared library reference to the weblogic-application.xml deployment descriptor of the ADF Web application. This is the only place where it works ( WEB-INF/lib does not work )

Now we can create an EDN definition and add a publication to an ADF BC entity. Go the Business Events part of your entity editor.

We need to decide if we want to use EDN-AQ or EDN-JMS. The AQ implementation is the default EDN implementation but this requires some datasources to the soa-infra database. This can be Ok in a small server network but I don't want this dependency to this SOA Suite Server in my WebLogic Server. 

So I will go for the JMS implementation and create the required Queue and Connection Factories on my own WebLogic Server ( you can also do this with JMS Foreign Server ). 

Then those JMS message are stored locally and we will use WebLogic Store and Forward for the reliable delivery to the SOA Suite server. This way we can bounce the SOA Suite server without effecting our Web Applications.

For the EDN-AQ implementation read this blogpost. 

To enable the EDN-JMS implementation you need to do the following steps which are described in this blogpost. 

We need to create the following JMS artefacts.

Create a JMS Server with a file or jdbc persistence.

Create a JMS Modules with a sub-deployment targeted to this JMS server.

Create a JMS Connection Factory called EDNConnectionFactory with JNDI name jms/fabric/EDNConnectionFactory, disable XA and targeted this to your WebLogic server.

Create a JMS Connection Factory called xaEDNConnectionFactory with JNDI name jms/fabric/xaEDNConnectionFactory, enable XA and targeted this to your WebLogic server.

Create a Queue called EDNQueue with JNDI name jms/fabric/EDNQueue and use the subdeployment so its targeted to the JMS server.

When we start our ADF Web application and change some data, we can take a look at the Queue. Here we will see the EDN events.

Last step is to setup Store and Forward. For this we can follow this Middleware Magic blogpost. 

See this blogpost how to fire EDN events  from Java and OSB instead of ADF BC. 

cheers

Retrieve or set a HTTP header from Oracle BPEL

With Oracle SOA Suite 11g patch 12928372  you can finally retrieve or set a HTTP header from BPEL. This patch comes with Patch Set 5 ( 11.1.1.6 )  and this patch can also be applied on PS3 ( 11.1.1.4 ), please download it from http://support.oracle.com

I made a simple test case with soapUI which adds an username and a message as HTTP header to the  service invocation.  In a second testcase I will mock this service in soapUI and BPEL will invoke this service and set an extra HTTP header property.

First step is to add a property to the binding.ws element of the service in the composite.xml. Add a property with name oracle.webservices.http.headers and as value the HTTP headers you want to use in BPEL
<property name="oracle.webservices.http.headers">username,message</property>

Next step is to define some BPEL variables for those HTTP Headers

In the receive activity of the BPEL process we can use fromProperty to copy the HTTP header property value to the BPEL variable. 

Do this in the BPEL source mode. 

Now you can use these variables in BPEL, I will use these vars in the return message.

Let's invoke the service from soapUI, we need to set the HTTP header properties with their values.

When we want to invoke a reference service and we also want to set some HTTP header properties.

We need also need to set the http.headers property on the binding.ws element on the reference in the composite.xml

<property name="oracle.webservices.http.headers">username,message,message2</property>

On the invoke of the reference service we need to use the toProperty and set the BPEL vars to these HTTP header properties.

When we test it again in soapUI we can see the invoke request of the soapUI mockservice, this contains the HTTP headers which we set in the BPEL process.