Posted on

Handle JSON message in pipeline using javascript in OSB12c

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.

OSB 12c JavaScript Action Create Proxy
OSB 12c JavaScript Action Proxy Resource Path

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.

OSB 12c JavaScript Action Proxy add rest method
OSB 12c JavaScript Action Proxy Request and Response

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

OSB 12c JavaScript Action PipeLine

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.

OSB 12c JavaScript Action
OSB12c JavaScript Action Expression

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};

OSB 12c JavaScript Action Response

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

OSB12c JavaScript Action Testing
Posted on

SOAP Version Mismatch Issue Using OSB 12c

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:
1 xmlns:soap12=<strong>“http://www.w3.org/2003/05/soap-envelope”</strong>

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.  
Posted on

Accessing global custom attributes in WebCenter Portal 12c

Global Attributes can be declared to share variables and information between all the Portals.

Out of the box, one of the attributes is the wcSessionTimeoutPeriod responsible for the session timeout. My friend Daniel already blogged about
accessing this on his blog entry.http://blog.vassit.co.uk/knowledge/access-global-custom-attributes

Way of accessing in EL is still working as following

HOW CAN BE ACCESSED USING EL EXPRESSIONS?

#{WCAppContext.application.applicationConfig.customAttributes[‘wcSessionTimeoutPeriod’]}

If you want to use Java API, one way to use

ADFUtils.evaluateEL("#{WCAppContext.application.applicationConfig.customAttributes['wcSessionTimeoutPeriod']}")

But if you are concern about performance, it’s not best practices to use evaluate EL in the java class. It is better to use OOTB API to access this. in 12c you can use following way

WCApplicationContext wcAppCtx = WCApplicationContext.getCurrentInstance();
WCApplication wcApp = wcAppCtx.getApplication();
WebCenterType wcMeta = wcApp.getApplicationConfig();
CustomAttributes customAttr = wcMeta.getCustomAttributes();
...

This will work in 12c.

Happy learning