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, 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.


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.

Join the Conversation

About the Author