Generic Rest Service/Generic Routing using Oracle Service Bus (OSB) 12c

Below is the sample to demonstrate creating a micro service using Oracle SOA 12c which can dynamically call any Rest Service. Here I am using DVM configured method name (GET, PUT, POST), content-type, Accept, host, queryparams and headers.

Lets Start

Create a new Service Bus Project GenericRouting

Because we are creating a generic service which can be integrated with different systems, the request and response should accept any XML/JSON. SO, first we will create xml schema (xsd) to handle anyType request/response, name it as generic.xsd

Below are the generic request and response elements definition

The above xsd is generalized to handle any kind of request/response (Json/xml), systemid is the unique identifier used to get the hostname, request parameters from dvm

Let’s create a dvm to understand the attributes

The DVM has system ID, Method name, Host, params

Create a Generic Rest Service, here I am using traditional HTTP adapter instead of REST Adapter (It was not working)

Create the Pipleline pair

Now Add the Message Type as defined below

Wire them

Go into the Piplelinepair and u will see the Routing is automatically added

We have to construct the Request by using DVM, add a New PipelinepairNode. Below screenshot will explain the steps

I am constructing Request variable gathering all the parameters, considering the request payload.

Custom are the params which I am matching with names available in DVM and later I will assigned there values

Add Insert Activity to construct Query Parameters, methods, Body if it is POST

Below id the Response from the Rest

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.