SOA Suite 12.2.1: A first look at end-to-end JSON support in SOA Composites

SOA Suite 12.2.1 introduces end-to-end JSON support in composites, support for JavaScript in BPEL and a JavaScript embedding activity. The REST-binding (which can be used by Service Bus, BPEL, BPM) can receive and send untyped JSON without the need to translate it to XML. In BPEL, JavaScript can be used as expression language in various activities and there is a JavaScript embedding activity available.

In this article I'll show some examples on what you can do with this end-to-end JSON support and give some examples on how to use JavaScript in your BPEL process.

About the implementation

Oracle has used the Mozilla Rhino JavaScript engine which is embedded in Java SE 6 and 7. WebLogic Server 12.2.1 and thus also SOA Suite 12.2.1, runs on Java SE 8 (Java EE 7). Java SE 8 has a new JavaScript engine Nashorn embedded (see here). A possible reason of Oracle for choosing Rhino could be that Nashorn is not thread safe. See here. You can imagine you need thread safety in an environment like SOA Suite.

SOAIncomingRequests_maxThreads is a property indicating the number of threads available to incoming requests. It is by default set to the same value as the connection pool size of the SOADataSource. This might not be enough for REST/JSON services. You can find this setting by going to the MBean browser, Configuration MBeans, com.bea, SelfTuning, (domain), MaxThreadsConstraint.

Use untyped JSON

You can use untyped JSON in various BPEL activities such as assign and assert activities. Since the JSON is untyped, you can assign values to elements which do not exist yet and they will be created; there is no message definition. Payload validation will cause a NullPointerException.

In order to achieve an end-to-end JSON BPEL process, you first create a REST Binding and indicate you do not want to invoke components based on a WSDL interface.

Next, configure the binding and indicate the request and response will be JSON.

Create a new BPEL process based on this REST binding.

Now the BPEL process will use end-to-end JSON. It is useful to set the default expression language to JSON instead of XPATH since you will be working with JSON. Right-click your process, edit and set the expression language to Javascript. In the below screenshot, you can also set the query language to JavaScript.

You can create an assign activity which assigns a JavaScript expression to the result variable. In this case the 'resultfield' object is created in the resulting JSON.

As usual, you can test the service in the EM Fusion Middleware Control.

Use JavaScript

You can use JavaScript inline (JavaScript embedding activity) or import a JavaScript file which is present in the project. Currently putting JavaScript files in the MDS is not yet supported.

Importing a JavaScript file from within BPEL can look like:
<bpelx:js include="jslib/main.js"/>

The JavaScript embedding object is of the type org.mozilla.javascript and has various properties. You can determine properties of an object by looping them:

for (property in this)
{ audit.log("output: ", property);
}

Some examples of how you can use these properties can be found here.

• xpath can be used to execute XPath expressions. For example: xpath.ora.getECID()
• console and audit can be used for for logging to console or audit log. For example: audit.log("Hello audit log") 
• process allows you to access process variables such as input and output. For example: process.outputVar.result = new Object();
• bpel can help you with expressions in activities. For example: bpel.until(process.counter > 3)

If I assign a value to a variable from within the JavaScript embedding activity, that value is available inside the BPEL process:

In an assign activity I can then use myvar to use the string.

Finally

The end-to-end JSON and JavaScript support are both powerful additions to Oracle SOA Suite. It has the potential (I have not measured this yet) of providing a significant performance gain when using BPEL to orchestrate JSON/REST services since translation to XML can be avoided. When you enable end-to-end JSON support in your BPEL process, it still remains possible to call SOAP services and use the adapters thus mixing REST/JSON and SOAP/XML in the same process becomes relatively easy.

I have yet to research the possibilities of using already publicly available JavaScript libraries inside BPEL processes. Most libraries are front-end based, but I can imagine there are JavaScript libraries available which provide new functionality to JavaScript running inside the JVM, which can then be used in BPEL. Also I have not yet studied limitations of using JavaScript from the JVM as compared to from a browser. Running from the JVM, JavaScript allows easy integration with Java, which might also be interesting to look at; can we use JavaScript to more easily interact with SOA Suite API's?

This new feature of using JavaScript with BPEL also of course requires some standards. I can imagine it is useful to put most JavaScript functionality in a library and include that instead of having difficult to maintain JavaScript embedding activities. You can then also use for example TypeScript to allow easy editing / syntax checking of the JavaScript library.