Oracle SOA Suite 12c: Retrieve data from JSON Using JavaScript Expressions in Service Bus 12C (OSB)

Service Bus provides a JavaScript action, which is used in pipelines The JavaScript action allows you to include snippets of JavaScript code to be executed during pipeline processing.

The most common case for using JavaScript is when dealing with JSON objects in REST services. Rather than converting the payload to XML and using XQuery or XSLT for manipulation, using JavaScript allows you to manipulate the JSON object directly. The JavaScript engine used in Service Bus also allows you to easily reference XML elements, making it easier to handle both JSON and XML-style payloads in JavaScript.

Useful Expressions

Service Bus binds a globally-scoped object called process

To access a $body variable in the Service Bus message context, use an expression like the following:

process.body

To create a variable in the Service Bus message context, use an expression like the following:

process.newVar = …;

To delete a variable, use the JavaScript delete operator:

delete process.var;

To access a variable, use below JavaScript:

process.firstName = process.body.employees.firstName;

The following expression returns the value of the inbound HTTP Content-Type header:

process.inbound.ctx::transport.ctx::request.tp::headers.http::[“Content-Type”].text()

For this example, we get JSON as Request, the requirement is to get firstName and LastName from the JSON payload using JavaScript Expression

Below is my JSON Request Payload

{

"employees": {

"firstName": "John",

"lastName": "Doe"

}

}

For Retrieving firstName and lastName from JSON Request, below is my Java Script Expressions in the Request Stage

In the Response Stage, I just added a replace action to sending an XML Response

Testing

Request

Response

Checking the Request/Response Pipeline

Conclusion

The end-to-end JSON and JavaScript support are both powerful additions to Oracle SOA Suite 12c and using Javascript expression we can manipulate data without any overhead of XML Conversion. 

Please comment / leave a message with your inputs.

Transaction boundaries in Oracle SOA

The article is an effort to demonstrate transaction boundaries in Oracle SOA, I will try to demonstrate with BPEL first, later we will see in OSB.  

Implementing the process in BPEL

In BPEL, the activities that defines transaction boundaries are Receive, Pick, invoke, wait and checkpoint. So let us demonstrate each of them by some examples.

Usecase 1 (Building the process without defining transaction boundaries)

For the first use case, we have create a simple BPEL process, performs an Insert operation into two tables (Department and Employee), and both have Master- Detail relationship with department Id as a foreign key.

All resources are XA-enabled and the process forms a global transaction

Below is the process flow

                        

Because we don’t have transaction boundaries, the above process automatically make the entire process run in a single XA transaction. If there is a problem with any of the data sources (for example, if a database is down or database constrain), and no exception handler has been defined, the whole transaction will roll back.

I have tested the above process by making job_id null for the Employee table.

                   

The process failed with an error and rollback whole transaction as expected

Usecase 2 (Checkpoint activity)

For this use case, we have extended the above process by adding a checkpoint activity in between Department and Employee invoke process. So as per the definition, the process should commit all the transaction which are prior to checkpoint activity.

Tested the use case by making job_id null for the Employee table.

The process failed with same error and because we have a checkpoint activity in between Department and Employee detail, it has done commit transaction for Department.

Usecase 3 (wait activity)

For this use case, we have replaced checkpoint activity with wait activity in between Department and Employee invoke process. So ideally, it should also have 2 transactions

Here I have added wait for 1 minute (As per the oracle documentation, the transaction will not commit for short waits)

Below diagram shows the implementation steps

Let’s Test the flow

As expected, the process has done a commit for the transaction prior to wait.

Usecase 4 (Invoke activity)

By default, invoke activity will participate in transaction. In order to make Invoke to commit the transaction, we have to set the idempotent property on the target partner link to false. If idempotent is set to false, the invoke activity is dehydrated immediately after execution and recorded in the dehydration store. This will end the initial transaction and start a new transaction. The diagram below shows how this can be implemented

Deploy and test the service with the same payload

The service failed in the Employee detail invoke as expected. But Surprise, it has rollback the entire transaction including Department table transaction.

I have revalidated the idempotent property in the composite, it is set to false as shown below.

Ideally the process should commit the Department transaction (I am using Oracle SOA Suite 12.2.1 for the demo, it seems to have bug for this version because the previous version 12.1.3 worked for this usecase.)

Usecase 5 (Receive activity)

For this usecase, I have create a new Asynchronous process (AsyncHelloWorld) and added an invoke in between Department and Employee detail, below is the process implementation and transaction diagram

This time the process committed department table transaction as expected.

Conclusion

Other than Idempotent usecase, Oracle BPEL Process Manager uses XA transactions to manage that state, and allows XA transactions to extend beyond the boundaries of the active BPEL process.

Oracle SOA 12C (12.2.1) : Creating a Restful service with JSON Response using Service Bus 12c (OSB)

There are some changes made in Rest Adapter from previous Oracle SOA 12.1.3 version, in the new Oracle SOA version 12.2.1 they have removed a predefined request/response schema definition in WADL that we use while configuring rest adapter.

For Building a Rest GET Operation, there are two important ways.

Create params using Templates

We can get them from Inbound → user-metadata

Create params using QueryParameters

We can get them from inbound → query-parameters

Below is the Step By Step process for building a GET Operation for getting a JSON Response using Templates

Create a new Project

Name as “RestProject”

Now we will start creating a Rest Adapter

Name as “sayHello”

Adding a New “Resource path” as /{name}

Creating a New Method

Method: sayHello

Resource:/{name}

HTTP: GET

Now Create a New pipeline

Name as “HelloWorldPipeline”

Map them

DoubleClick on HelloWorldPipeline

Create a pipelinepairNode

Create a new Assign Activity and add below concat operation

---------------------------------------------------------------------------------------

concat('Hello ',$inbound/ctx:transport/ctx:request/tp:user-metadata/@value)

or

If you have more than one template use below xpath

concat('Hello ',$inbound/ctx:transport/ctx:request/tp:user-metadata[@name=’name’]/@value)

---------------------------------------------------------------------------------------

Now, for our scenario we need to send a JSON Response, so we need to create a NXSD to transform XML to JSON.

Create a new NXSD Schema

Add sample response { "Response":"Hello"}

Now In the response stage, insert nXSD Translate activity

In the input of nXSD, past below xml

--------------------------------------------------------------------

<Root-Element xmlns="http://TargetNamespace.com/ServiceName">

<Response>{$AssignRequest}</Response>

</Root-Element>

--------------------------------------------------------------------

Translate: XML to Native

nXSD Schema: xsd location

Output: Content of $body

Testing