November 11 2017

Back in mid-2014, Oracle was releasing Oracle BPM 11g Bundle Patch 3 and with it, the first version of its BPM REST APIs. That first cut was a good starting point, but it just offered a limited amount of functionality (find my previous post here). In this post, we’ll take a look at the BPM REST APIs version 12.2.1.2, released in August 2016, and see how they evolved after 2 years. 

The list of available services can be obtained by accessing to http://yourserver:port/bpm/services/rest/application.wadl.

BPM REST APIs WADL

The picture above shows all the REST services included in this new version; highlighted in yellow are the new services introduced since the first version of the REST APIs. There’s one curious thing, the two processes services (1.0/processes and /processes). Like in the very first version of processes service, if you execute getProcess operation, the response is just “Processes.”. Likewise with runtime service, if you execute getRuntime operation, the response is an empty string.

Let’s now focus on one of the most important things we would like to do with these REST APIs: get and update the task payload. This can be achieved using tasks service and we need to know the task number of the task we want to work with. The task number is no other thing than an integer number that identifies the task, but internally the BPM APIs don’t use it, they use the task id instead, which is a string (GUID). So, the first thing the REST operation will do is, to call a service to get the task id for the given task number.

The following picture shows the response of getTask operation.

getTask outcome

In this version, the URL of the operation to get the task payload is tasks/:taskNumber/summaryFields but in the very first version, it was tasks/:taskNumber/payload.

Below, there is the response of the call to getSummaryFields operation.

getSummaryFields outcome

I’ve tried several times this operation with different tasks numbers and the response was always the same. In a further analysis I found out that internally, the getSummaryFields REST operation is calling the Human Workflow Web Service operation getSummaryFieldsInfoForTask.

getSummaryFieldsInfoForTask outcome

It seems this web service is the culprit of the “Task payload not found” message returned by getSummaryFields operation.

In brief, no major changes have been done in the BPM REST APIs. There are some new services but is still not possible to get and update the task payload.

About the Author

Sebastian Marucci profile picture

Sebastian is a passionate software engineer. He has been working in BPM projects for the last 9 years mostly focused on user interface development and user experience enhancement. He participated in projects in several countries around America, such as Argentina, Brasil, Chile, Bolivia, Uruguay, Panama and USA.

Sebastian loves playing tennis and soccer. He is a big Boca Juniors fan and never misses a game at 'La Bombonera'.

Join the Conversation

Enter your first name. It will only be used to display with your comment.
Enter your email. This will be used to validate you as a real user but will NOT be displayed with the comment.
By submitting this form, you accept the Mollom privacy policy.