SOA Suite 11g (TP4) – Create Mediator based SCA Composite Application from XSD – write to output file using File Adapter

 

A quick overview of you can create an SCA Composite Application that publishes a WebService interface, accepts SOAP Messages and write their contents to a file, appending a new record to the current contents. In the center of the composite sits a Mediator. Its interface is based on a WSDL that is created directly from an XSD document that describes the XML messages that have to be processed. The Mediator is then exposed as Service through a simple drag & drop operation. An outgoing file adapter service is created that writes its input in a comma separated record format to an existing file. Finally with another drag and drop, the Meditor is wired to this File Adapter Service and – with more dragging & dropping – the mapping between the incoming XML message and the outgoing CSV record is created.

This is all done using Oracle 11g SOA Suite, Technology Preview 4.

The set up for this example is JDeveloper 11g TP4 with the SOA option enabled. I have created a new Application and a SOA project with Mediator Component, for which the interface is to be created later.

Our first step is the creation of the XSD. In this case we are creating a Service for Dentist Appointments – yes, they will do SOA to. (I am working on this as a case for the Oracle Press book Oracle 11g SOA Handbook, to be published later this year). In the XSD we see the information required to (semi)automatically schedule a dentist’s appointment, based on a referral by a general practitioner.

Next I go and edit the Mediator component. I click on the plus icon after the WSDL URL prompt. I then click on the little icon (cog) that indicates Generate WSDL from XSDL. I then click on the Explore Schemas icon and finally I select the AppointmentServiceProcessRequest element in the XSD document DentistAppointmentRequest.xsd.

This element describes the request message for this service. I do not define a reply (synchronous) or callback (asynchronous) message type, effectively creating this service as a one-way service that only accepts a request and does not reply anything back to the invoker.

I specify the Operation Name – handleDentistAppointmentRequest – and the Port Type Name. These too will be in the WSDL file.

 

When I click the OK button, a Routing Rule is automatically created. It has an input,  but no target service at this point. The messages that are received are going now

We can simply drag the diamond shape on the left hand side of the Mediator component and drop it in the Exposed Services lane. At that moment, a Service element is created in the SCA composite.xml file – indicating an externally exposed service , implemented by the Mediator.

Next is the creation of an outbound file adapter service that will write the transformed contents of the request message to a big file – appending new messages as they arrive.

It is important to specify a Logical Directory name, to be able to specify the real physical directory during deployment so without changing the source the application can be deployed in various environments. Note the checkbox Append to Existing File that is marked in order to have messages appended to an existing file.

Next I wire the Mediator and this new File Adapter Service together – another drag and drop operation.

Underneath this wire is the more detailed mapping from the message received by the Mediator to the format expected by the File Adapter Service.

Before deployment, we have to set the physical reference to the Logical Directory Name, in the composite.xml file:

Then deploy the composite application:

In the SOA Console we can see the new Service and Test it as well:

It takes some filling in of the properties for the request message:

but the result really makes it worth the effort:

 

Well, the real result is in the file that contains the collected request records of course: