SOA 12c - Invoke REST Service

We discussed about REST services and also saw how to create REST services in SOA 12c in previous post. Click here to read that post, if you didn’t read that already. As we saw in that post, WADL file gets generated when we deploy REST service to server and we use that WADL file to test that REST service.

In this post, we will see how to invoke REST service from SOA composite in 12c. To invoke the REST service we use the WADL file of REST service. In earlier version of SOA we use HTTP bindings to invoke REST service but in this version we use REST bindings to invoke REST services. REST bindings also provide JSON support in this version.

We have created a sample composite and added a BPEL to it. We will add reference to the composite to invoke REST service. To add reference to composite file, drag REST bindings which you can find under component palette. REST binding was not part of SOA 11g, this is newly introduced in SOA 12c. Once you drag the REST binding to composite file, it opens another wizard where we fill required information to add REST service reference. 

Provide REST service reference name and make sure type is selected as Reference in drop down list. Now we will add required operation of REST service and we will use WADL file for that. To do that click on green plus button in Operation Bindings section and choose “Add operation based on WADL service”.

Once you click on above option, it opens another wizard window where we need to choose the REST service WADL file. Click on Application server and choose WADL file under SOA folder. We choose the integrated Weblogic server as we use this server, you can choose standalone server if you are using that server.

Once you choose the WADL file, you can see all the required information like resource path, operation, http verb gets filled automatically in create REST binding wizard. Click on ok, then it ask to maintain local copy of the files, check all checkboxes and click ok. This will add required REST service reference to your composite, now wire the REST reference to BPEL process, your final composite should look like below.

Now compile this service and deploy it to the server. Now we either test this service from HTTP analyzer or from EM console. To test it from HTTP analyzer, go to application server connection and choose Integrated Weblogic server connection, expand till SOA folder and go to above deployed service WSDL file , right click on that and test it. This opens HTTP analyzer window where we can provide required input and see the response.

To test it from EM console, go to EM console and in the left pane, open the above deployed composite and click on test. Fill request parameters and test the service. You can see success response in response tab. Open the instance and see the flow, in the flow you can that BPEL successfully invoked the REST service.

SOA12c - Create REST Services

REST stands for Representational State Transfer. Restful service is an alternative to SOAP web service. Restful application use HTTP to transfer the data. In previous version of SOA suite there were very limited support for REST, we use HTTP bindings in 11g to create restful service. Click here to see how to create Restful service is SOA 11g. In SOA 12c additional feature provided for REST, REST bindings introduced which helps to create REST enable service and reference components.

In 12c we can integrate external REST API’s and XML, JSON and URL-encoded GET/POST data support is provided. Web Application Description Language (WADL) support is also provided, WADL is similar to WSDL only difference is WADL file is used when we create or Invoke REST service and WSDL is used when we create or invoke SOAP service. OWSM (Oracle Web Service Manager) policy support is also provided for REST security.

In this post, we will see how to create REST service in SOA 12c. We will also see how to test this REST service from HTTP analyzer using WADL file.

How to create REST service

To create a REST service, drag REST binding from component palette to composite. This opens the Create REST binding wizard, name your service and choose service as type. You can also added required description for this service. Now add the resource path, to add that click on green plus sign link and provide the relative path.

Once you define the resource path, next step is to add operation binding. To add that go to operations bindings and click on green plus sign and choose “Add operation binding”. Once you click this, it opens another REST operation binding wizard, in that wizard provide operation name. Choose POST as HTTP verb and in request tab choose “XML” as we will receive the request in XML form. Browse the schema which we need to use for request message. Now go to response tab and repeat same steps as we did in request tab.

Now create a new BPEL, choose Define service later template. Then wire it to the above created REST service reference. Now add one receive activity inside the BPEL to receive the request, make sure you check the “Create Instance” check box in receive activity. Also add reply activity and link it to REST adapter. Add assign activity and add require logic. Once you are done with above steps, deploy your composite to SOA server. Now we will test this REST service using HTTP analyzer.

How to test REST service using HTTP analyzer

As mentioned before WADL file gets generated when we deploy REST enable service to server. We will use that WADL file only to test REST enable service from HTTP analyzer. To get the WSDL file URL, go to EM console and go to your composite. Click on link as shown in below diagram to see WADL file URL. Copy this URL, we will use this URL in next step.

Now we will use HTTP analyzer to test the REST enable service, to open the analyzer go to Jdeveloper, go to Tools then click on HTTP Analyzer. This opens new window in below pane, click on folder (Open URL) button to specify WADL file URL.

Once you specify the WADL URL, this opens below screen, where you can see service details. You can see one Test button for POST method, click on that button to test this service. This take you to another screen where you can specify the request parameter, provide request parameters and click on send request. This invokes the service and provides the response, you can see the response in right window.

SOA 12c - Standalone Subprocesses

There are many features introduced in SOA 12c to increase developers productivity, one of the feature is sub process. We already discussed about what is sub process and types of sub process available in SOA 12c, click here to read the post if you missed to read earlier. We discussed in detail about Inline sub processes in previous post. Click here to read that post. That post explains how to create and use Inline sub processes. In this post we will discuss about standalone sub processes. We will see how to create standalone sub process and how to use existing standalone sub process inside composite.

Opposed to inline sub processes, standalone sub processes are not confined to parent BPEL process, we can use these standalone sub process across different BPEL process but we can use these processes inside one composite only. These sub process are used when we need to re-use the whole component multiple times in one composite. If we have logic which needs to implemented in one composite multiple places then we write that logic inside standalone sub process and call that sub process from BPEL process using call activity.

How to create Standalone Sub Process

We have created one sample SOA composite and added one synchronous BPEL process to it. Inside BPEL process we simply assign request message to output. Now we will create a standalone sub process in this composite.

To create a standalone sub process, right-click on the composite and click on Insert and choose “Subprocess” option. This opens another pop-up window where we can the process details. You can edit the details as per your environment, once done click on ok. This will add one standalone sub process to the composite file. Once you create the standalone sub process, you can see that sub process inside component palette. If you notice this sub process further categorized as standalone sub process.

How to make changes to Standalone Sub process

Once we are done with standalone sub process creation, next step is to edit the standalone sub process. To edit the standalone sub process, right click on the sub process and click on edit. This opens sub process flow and you can add required logic inside that.

How to use Standalone Sub Process

Once we add the required logic in the standalone sub process, next step is to use above created standalone sub process inside BPEL process. To call the standalone sub process from BPEL process, drag the above created sub process from component palate and drop it to BPEL process. You can rename the call activity as per your naming standards.

You can drag multiple sub processes in one BPEL process, you can also use this sub process in another BPEL which is there is same composite. Once you are done with above step, your BPEL process should look like below. You also see BPEL component get wired to standalone sub process through dotted wire.

Once we are done with above steps, deploy your composite to server. All the sub process automatically get deployed to server when we deploy composite as these sub process are part of composite only. Test the composite and you can see that standalone sub process get triggered.

SOA 12c - Inline Subprocesses

We discussed about sub processes in previous post, we also discussed about types of sub processes available in SOA 12c. In this post we discuss about Inline sub process, we will also see how to create the inline sub processes, how to make change to inline sub process and how to use these inline sub process inside BPEL process.

Inline sub processes are introduced to increase developer productivity and reduce code redundancy.  These inline sub processes are confined to parent BPEL process only, we can’t use these inline sub processes outside parent BPEL process. If we want to use sub process across different BPEL processes inside one composite then we need to go for standalone sub processes. These inline sub processes are used when we want to repeat same logic in one BPEL flow so instead of writing same activities again and again inside same BPEL, we add that activities to inline sub process and call that inline sub process wherever required inside that BPEL process using call activity. This means whenever any change comes in future then we need not to make any change in parent BPEL process, we only need to make that change in inline sub process and that change reflect at all the places wherever we call that inline sub process.

How to create Inline Sub Process

We have created one sample SOA composite and added one one-way BPEL process to it. Inside BPEL process we write customer information to local file. We have added assign and Invoke activity inside scope activity that writes the local file.

To create an inline sub process, right-click on the scope activity and click on “Convert to a Subprocess”. Fill the inline sub process label text and also provide comments. There is provision to use custom images for sub process so you can also provide your own image for this sub process.

Once it is created, you can see this inline sub process in component palette under Subprocesses section. You see that this sub process is categorized as Inline sub process. You also see that scope activity inside BPEL get replaced with Call activity.

How to make changes to Inline Sub process

Once we create the inline sub process, we can see it inside component palette. There are chances that in future we may need to make some changes to this inline sub process. As already mentioned before, once we make changes to inline sub process that changes get reflected everywhere wherever we used this inline sub process. To make changes to inline sub process first we need to open this sub process, to open this sub process, choose this sub process from drop-down list and make required changes to it.

How to use inline Sub Process

To use the inline sub process, we simply need to drag the inline sub process from component palette to BPEL flow. Once we drag the sub process to BPEL flow, it adds one call activity to the BPEL flow which call that inline sub process. You can change the call activity name as per your naming standards.

Once we are done with above steps, deploy your composite to server. All the sub process automatically get deployed to server when we deploy composite as these sub process are part of composite only. Test the composite and you can see that inline sub process get triggered two times.

SOA 12c - Sub Process

In earlier post we discussed about templates which are introduced in SOA 12c as a new feature. There are mainly three types of templates which are introduced in 12c, we discussed about each template in details in previous post. If you missed to read that post, you can click here to read that. In 12c there is another feature introduced which is called sub process, we will discuss about sub processes in this post.

Sub Process act like a bundle which contain a piece of BPEL code which we can re-use inside same BPEL or different BPEL in same composite. Sub process contains fragment of BPEL code.  Benefit of sub process is that it increases developer productivity and chances of human error got reduced. Suppose we have a piece of code which we need to use at multiple places in one BPEL or in one composite so instead of writing same logic/code again and again in BPEL, we can create sub process of the logic/code and call it where ever required in that BPEL or in different BPEL but in same composite. So whenever we need to make any change into the logic/code we need not to do that change at all places, we just need to do that change in sub process and that change will reflect at all place wherever we call that sub process.

Below things we need to keep in mind when we use sub processes.

Sub processes are supported for only BPEL 2.0; it is not supported for 1.1 version. In the first release of 12c, we cannot use sub processes across multiple composites i.e. sub processes can be used inside same composite only.

There are mainly two types of sub process in 12c which are explained below.

Inline Sub-Process:  As name suggests this sub process is in line to parent BPEL process means this can’t be used outside parent BPEL process. Inline sub process contains group of activities which we can re-use within one BPEL process only. This sub process is not visible in composite view as this is part of parent BPEL.  This sub process is visible in palette under sub process. We need to use call activity to call this sub process inside BPEL process. Below is real time example which explains the use of inline sub processes.

E.g. suppose we receive the sales order from source system, once we receive the sales order, first we update the source system that we receive the sales order successfully, secondly after we receive the order, we do required validations and submit the order to target system, after we submit, we again send status back to source system that order is successfully submitted. In both the cases we update database flag in source system. Here we can use inline sub process, we can put activities which update the status in source database in one scope and create an inline sub process from it. Once we have inline sub process created, we can use call activity to call that sub process to update the receive status and submit status. So if in future there is any change in table structure or table columns then we need to make that change only in sub process and that will reflect at both the places.

Click here to see how to create and use inline subprocesses.

Standalone Sub-Process: As name suggests this sub process act as standalone inside one composite. Standalone sub process is similar to inline sub process, except we can use it outside of parent process. This sub process contains group of activities that can be re-used across other BPEL processes. Similar to inline sub process we use call activity to invoke standalone sub process. This sub process is also visible in palette under sub process. 

Click here to see how to create and use standalone subprocesses.

Reference: Oracle Fusion Middleware Guide 12c

SOA12c -Service Bus Resequencer

We often come under such situation when we receive message from source system which are not in proper sequence but target system need to receive that in proper sequence. To resolve this we need to re-sequence the messages and process them in proper sequence.   Re-sequencing is term used when we need to process incoming messages in sequence which are not coming in proper sequence. Design and developer need to think on this re-sequencing when they encounter such requirement as e described above. E.g. suppose we are receiving sales orders from source system, sales order contain one field with the name sales order number, suppose source system sends sales order in this sequence ( 1, 4,3,2,5,6,7 ) but target system need sales order in this sequence (1,2,3,4,5,6,7) , in this case we need to do re-sequencing of message.

In 11g version of Oracle SOA Suite, re-sequencing was there in Mediator component but this feature was not available for BPEL and Service Bus. In 12c release, this feature is provided for service bus. We can set this feature either at pipeline level or at operation level. In this post, we will discuss on that. We will only discuss about pipeline level re-sequencer.  

We have three types of re-sequencing in Service Bus.

Standard:  This sequencer is used when incoming message contain numeric identifier.  This numeric identifier is termed as Sequence Id. We may specify message Group also, that means incoming order can be Sales Order or purchase order, in this case we will have separate group for both Sales Order and purchase order. When source system send out of order messages then it store out-of-order message until complete order is received this is based on sequence Id.

FIFO: This sequencer works based on message arrival time. Whichever message received first, will be processed first. Here you need to specify only Group. So all the messages which are there in one group processed based on message receive time.

Best Effort: It is used when we receive large number of messages in a short period of time and cannot provide information to the re-sequencer about the identifier to use for sequencing. Typically, the identifier used for sequencing in such scenarios is of a dateTime type or numeric type.

To configure re-sequencer in service bus, double click on the pipeline and choose configuration tab. Click on resequencer, to enable the resequencer check the “Enable Resequencer” checkbox. Once you enable the resequencer, you need to choose the resequencer level. Resequencer level can be set either pipeline or operation. Also choose the type of resequencer which you need to use.

If you choose to use standard resequencer then you need to provide values for sequence id and group. Only sequence id is mandatory for you can skip group for this sequencer, empty group value means all the incoming messages will be in one group only.  Sequence id is of numeric type. You can also set resequencer start counter and increment counter. We can also specify message expiry time by setting Timeout value. When we set Timeout as 0, that means messages will never expire.

For FIFO, we need to set only Group and that is also option. So when we choose FIFO resequencer, all the messages are processed based on their arrival time.

SOA 12c - Translate Activity

In Oracle SOA Suite we deal with XML request and response messages. There are cases when we receive XML message and that xml message contains delimited or fixed length string. In 11g version we didn’t have any activity which converts delimited or fixed length string to XML format so we need to go for alternative solutions. However we have native format builder wizard in file/ftp adapter from where we can generate the required schema from flat file and use that schema to convert XML to Native format and vice versa.

In Oracle SOA 12c, new activity is introduced which solves our problem, with the help of this activity, we can convert Native to XML format and vice versa. All the steps remain same as we follow while we use native format builder in file/ftp adapter.

In this post, we will discuss about that activity and see how to convert from Native to XML format and vice versa using translate activity.You can find this activity under Oracle Extensions. So to add this activity, drag it to required BPEL and start configuring it.

Double click on this activity and go to translation tab. You can see two options there “Native to XML” and “XML to Native”.  In Native to XML, we convert delimited string to XML format and in XML to Native; we convert XML to native format. Let’s first see how “Native to XML” works.We need to choose the input variable from where we get the delimited string, for this post we choose input variable as we pass delimited string in that variable.

Now we need to specify the schema which convert Native (delimited string) to XML format, if you already have that schema then simply browse the schema and choose the required element from that schema but if you don’t have then we need to create it using native format builder wizard. Click on second button which is there for NSXD schema and open the native format builder wizard. Specify the schema name and schema directory, also choose the type of Native format, here we choose delimited as we get the data in delimited format.

Now we need to specify the file which contain sample native format i.e. sample file which contain at-least one sample delimited record. If you don’t have that file, create it first and add one sample row in that. There are different options available; you can choose that as per your requirement. We also need to specify the types of record present in the file, in our case we can have multiple records in one file which are of same type so we choose that option, once done click on next. Now we need to specify schema root element and other element name, you can also edit the schema namespace.

Specify al required delimiters; we need to specify record delimiter and field delimiter. We use Complex lookAhead Record processing when we deal with COBOL file so we need not to set this fields for now. Once done, click on next, now we need to specify the field properties, these properties are nothing but schema elements name, by default this wizard shows C1, C2, etc names for fields but we can change it as per our requirement. For our use case we changed it to meaningful names.

Once you are done with above steps, your Translate activity should look like below. You can see schema already generated for you and that schema has all required elements. In the translate activity, you can see we need to specify output variable also. If you already have output variable which is based on above generated then you can use that otherwise you need to create a new output variable.

Now let’s test it, before we test it deploy it to the server, open the em console, go to the composite and click on test. This should open the request message window; provide delimited string which we need to convert to XML. As you can see in below screen shot, delimited string got converted to XML.

If we need to convert XML to Native format then we needs to provide the input variable from where we receive XML input which gets converted to native format. Choose schema if you already have or follow above steps to generate schema using native format builder. In this case output will be string so create output variable as string type. Once complete, your activity should look like below. Now deploy your composite and test it. In the output you see response in native format.