RESTful API access via Business Processes

This is something I wrote for fun :). These samples demonstrate on how to invoke REST API methods like GET and POST from a BPEL process running on WSO2 BPS.
Here I used a RESTful API which is enabled by GoodReads, a social networking site for book readers.
You need to attain your own API key to access GoodReads REST API. So make sure to read the README.txt which explains on how to get your own API key.
I’m working on BPEL samples which use PUT and DELETE methods and will update the post once they are done.

Related Posts

• Manipulating HTTP headers via Unified-Endpoints
• Unified endpoints for BPEL Processes

Manipulating HTTP headers via Unified-Endpoints

WSO2 Carbon platform supports unified-endpoints(UEPs) to configure partner endpoints which are used in the BPEL processes. In more general terms, UEPs facilitate for a generalized way of configuring endpoints taking quality of service into the picture.
The following sample provides a guide on how to manipulate HTTP headers for an request message of the given endpoint.


Related Posts

• Unified endpoints for BPEL Processes
• How to invoke a secured web-service through BPEL

BPEL activity failure and recovery

In Business/Scientific work-flows, activities like invoking a partner service end-point could failed due to several reasons like network inconsistencies(non-deterministic), erroneous configurations(deterministic) etc. So the work-flow administrator should be able to retry and cancel those activities.
The administrator can retry activity any number of times, so the business logic related to the particular activity gets repeated until the particular process instance leads to “completed” or “fault” state.
Or the administrator can cancel the failed activity, so the particular process instance leads directly to “fault” state.

BPEL activity recovery is an in-build feature comes with WSO2 BPS and at the moment the implementation supports for failed <invoke/> activities. So a process administrator can monitor activity states via the BPEL visualization and retry or cancel them based on their preference.

An screenshot of a failed <invoke/> activity named “InvokeCreditRating” and its recovery options...

BPEL Deployment Descriptor Editor

In previous releases, a BPEL Deployment Descriptor Editor was available only for BPEL developers via BPEL editor of WSO2 Carbon Studio. So BPEL process administrators had to change the deployment descriptor configuration file (deploy.xml) by hand and re-deploy back to the system.

The next major release of WSO2 BPS will be out with BPEL Deployment Descriptor Editor Support via WSO2 BPS administration console. So BPEL process administrators can configure process/instance/scope event generation, instance cleanup etc. at run-time. Also it represents the other configuration details like MEX interceptors, process properties, provided services, partner service etc. which make the BPEL process administrator’s life much easier.

BPEL deployment descriptor editor for WSO2 BPS administration console is a contribution from Ishara Premadasa from University of Moratuwa.

A screen shot of the BPEL Deployment Descriptor Editor.

BPEL visualization - WSO2 BPS

Initial version of BPEL visualization feature was added to WSO2 BPS as a result of my first internship project at WSO2. It had some functional requirements like,

1. BPEL process instance details visualization
2. BPEL process visualization with different abstractions etc.
3. BPEL activity filtering

With the next release of WSO2 BPS, its new BPEL visualization feature is going to be a completely new design to meet the requirements as mentioned above. This work was a result of research related to Process views carried out by Dr. David Schumm and his research group from University of Stuttgart.
The presentation on this work by Dr. David Schumm at WSO2Con-2011 can be found from here.

Some of the screen shots of the unfinished work...

Process Management View

Instance Management View

Process Management View for a Complex Workflow

Instance Management View for a Complex Workflow

How install the BPEL features via Feature Manager

This blog post explains how to install BPEL specific features to WSO2 ESB.

Tested Environment

• WSO2 ESB 4.0.2 (Based on WSO2 Carbon 3.2.2 release)

Introduction

If you consider WSO2 products like WSO2 BPS, WSO2 ESB, WSO2 AS etc. all those products can be considered as a collection of solution specific features included on top of WSO2 Carbon platform. As an example, WSO2 BPS is a collection of features which facilitate BPEL process/instance management, BPEL process runtime management etc. included on top of some other features provided by WSO2 Carbon platform. So theoretically you can convert a WSO2 Carbon distribution to WSO2 BPS by including those BPEL specific features.

How to determine the correct BPEL version compliant with the target server

We can do this easily via the feature manager provided by WSO2 Carbon platform. Here, the tricky part is user have to specify the correct version of BPEL feature to be installed on target server. This is solely depend on the version of the WSO2 Carbon platform in which the target server was released. Let me elaborate this with an example. eg - To install BPEL features to WSO2 ESB 4.0.2, first find the related WSO2 Carbon platform version. This can be determined by the version of $ESB-HOME/repository/components/plugins/org.wso2.carbon.core-x.x.x.jar. So if WSO2 ESB 4.0.2 is the target server, then the version of org.wso2.carbon.core jar would be 3.2.2. So the relevant BPEL feature version is 3.2.2.

Step by step guide to install a feature via feature manager

Once we figure out the right BPEL feature version we can add it via the Feature Manager. Please refer the following documentation on how to install a feature via feature manager. Once all the BPEL 3.2.2 features are installed in WSO2 ESB 4.0.2 and once the server restarted, there’ll be a separate menu item is appeared for BPEL features as follows.

How to invoke a secured webservice through BPEL

Engaging Quality of Service(QoS) for a partner web service endpoint in WSO2 BPS is facilitated by Unified Endpoint(UEP) feature. Not only QoS, but also, protocol specific properties like setting “ReplyTo” header for the outgoing message can be configured via UEPs. To get some more idea on UEPs please refer this post.

This post describes how to invoke a secured web service through a BPEL process using an UEP.

Tested Environment

• WSO2 BPS 2.1.2 (based on WSO2 Carbon 3.2.0) release and WSO2 BPS release based on WSO2 Carbon 4.0.0

A sample of referring the security policy in the Unified-Endpoints can be found via this Unified Endpoint  in this sample BPEL Loan Process. 

This policy can be maintained outside from the BPEL artifact as well.

eg - Referring to a policy maintained in the file system - Use the absolute path for the policy in UEP.

eg - Referring to a policy maintained in the configuration registry - Use the registry specific path for the policy in Unified Endpoint.


Maintaining an policy outside from the BPEL artifact becomes very useful when governing policies which are used by multiple BPEL processes in multiple WSO2 BPS instances.

Unified endpoints for BPEL Processes

WSO2 Carbon platform supports unified-endpoints(UEPs) to configure partner endpoints which are used in the BPEL processes. In more general terms, UEPs facilitate for a generalized way of configuring endpoints taking quality of service in to the picture. So a particular UEP configuration can be used across the carbon platform to configure security in a partner endpoint in BPEL process and to configure WS-Addressing in a WSO2 ESB endpoint.

This post provides a guide on how to properly configure a partner endpoint in a BPEL process.
Tested Environment :

• WSO2 Carbon 4.0.0 based releases 

Please take a look at Async-Server sample which is a sample BPEL process which uses an UEP to configure the target endpoint of a partner service.


If you are interested in other supported constructs by UEPs, please refer this xml schema which provides the current supported functionality like setting “ReplyTo” header.

So where is this UEP configuration actually engaged to a partner endpoint?. This is configured at the deploy.xml which declares the particular partner service as follows. Please refer the same sample mentioned above.


If you look at the mentioned sample above, UEP configuration is located inside with the BPEL artifact.
But on the other hand, an UEP can be maintained outside from the BPEL artifact. So it can be located in the file system or registry. Maintaining an UEP outside from the BPEL artifact becomes very useful when governing endpoints which are used by multiple BPEL processes in multiple WSO2 BPS instances.

eg - If the UEP to be maintained in the file sytem - Use the absolute path for the UEP in deploy.xml


eg - If the UEP to be maintained in the registry - Use the registry specific path for the UEP in deploy.xml


Please refer this UEP on configuring security for a partner service via a UEP. More information on this can be found from this post as well.