Oracle Service Bus 12c provide the feature to handle JSON messages inside pipeline, although this feature was not there in first version of 12c but later version provides full JSON support. In this post, I will show how to handle JSON message inside pipeline. JavaScript is new action introduced inside message flow that help us to read/write and manipulate JSON messages.
Let’s start with this sample. I will show how to read below JSON message inside pipeline using JavaScript action and how to generate below JSON response using JavaScript action.
Request JSON
{ “inputVal” : “world” }
Response JSON
{ “result”:  “Hello world” }

First of all, create new OSB project under OSB application. Now create Rest proxy service that accept JSON message and send JSON as response, to do that right click and choose “REST” option and provide proxy name. In next screen you need to provide resource path for this rest proxy.

Now click on “Add a new Rest Method” option. Provide method name in next screen and choose “POST: method. Also choose “JSON” option for both request and response as we are dealing with JSON message here.

 Add Pipeline where service type is REST and choose the proxy WADL file for the same. Ensure that expose as proxy option is unchecked.

Link pipeline with proxy service. Inside pipeline, add pipeline node and first in request pipeline add one JavaScript action. Open the JavaScript action and click on Value expression.

In Expression, add below text.

var $request = process.body
process.response= “Hello ” + $request.inputVal

Here $request is variable and process.body contains the request JSON data so I assign request JSON to request variable.

imputVal is the element name that we receive in request so to access that I used $request.inputVal expression and “Hello ” is appended to that and assigned to process.response.

Now add another JavaScript action in response pipeline to create response JSON, click on Value expression and add below text.
process.body={“result” : process.response};

Test the flow by using the request JSON and you see the response JSON as shown below.

we discovered a version mismatch issue in which two SOAP services on different versions (Service-A on SOAP 1.2 and Service-B on SOAP 1.1) were failing to communicate with each other. Here, we explain how to resolve this issue.

Difference between SOAP 1.1 and SOAP 1.2

Before diving into the solution, let’s look at the improvements SOAP Version 1.2 provides over SOAP 1.1.

1. Offers a clear processing model;
2. Provides improved interoperability with testing and implementation requirements;
3. Based on XML Information Set (i.e. It is specified as an Infoset, which is carried from one SOAP node to another, whereas SOAP 1.1 was based on XML 1.0 serialization.);
4. Offers protocol independence for developers by providing a binding framework;
5. Includes HTTP binding for improved integration to the World Wide Web;
6. Delivers a well-defined extensibility model; and
7. Provides improved support for Web standards.

WSDL changes observed in SOAP 1.2

1. Namespace Changes: SOAP 1.2 supports the following namespace definition:

2.  SOAP 1.2 uses “application/soap+xml” as the Content Type, whereas SOAP 1.1 uses “text/xml”.

3.  SOAP:Operation and SOAP Binding must be specified in SOAP 1.2 WSDL.

Solution

Now, to overcome the versioning mismatch issue mentioned above, we must follow these steps:

1. Generate the OSB Proxy as a Message Based Proxy service. This will be based on the XSD with only the “body” part with required parameters to call Service-A (SOAP 1.2) and Service-B (SOAP 1.1).
2. Create a Pipeline Service based on the same methodology explained in number 1, above.
3. In the Pipeline Service, navigate to Message Flow and add a Pipeline Pair – rename it per the process standards.
4. In the Request Pipeline node, add a Stage and rename it per process standards.
5. Inside the Stage, add a Service Callout, then browse for the Proxy Service for the wrapper of Service-A or the business service of Service-A. The Service Callout configuration is shown below with the required message to Service-A parameters assigned. 
6. After the above Pipeline Pair is complete, add a Route Node.
7. Inside the Route Node, add a Routing Operation and configure the same for the Business Service of Service-B.
8. Inside the Request Actions, assign or replace the Body and Header to make a successful call for Business Service. The following snapshot illustrates this.