Jarvis Pizzeria: Creating a Custom Tasklist

So within Process Cloud Service (PCS) we have already shown the tasklist a couple of times. This is the default tasklist that comes with the product. You can use the left hand side filters and handle the actions in the tasks within the task screens.

However, as with all of the ‘one-size-fits-all’ solutions, the tasklist might not be exactly what you need for your organisation or use-case. In this case it is good to know, that you can create your own custom tasklist.

This compares to what we see at customers using BPM Suite on premises. We use a lot of features from BPM, but usually not the Worklist/Workspace that comes out of the box with BPM. Since there is an SOAP API to call your tasks, it is quite easy to talk to this API and create your custom tasklist in the on-premises world.

For PCS, we do not have SOAP APIs, but we do have REST APIs, if there is any need to create a custom tasklist, you can use these APIs to; Start an application, query for tasks, query for task details, handle the payload or outcome and much more.

To find the APIs, all you need to do is add ‘/bpm/components’ at the end of your baseurl. This brings up the PCS ‘Embeddable Process UI Components’ page. On the first page, you can enter your credentials and it will help you get the authentication token for the service url. After that, you can use the cookbook to start working with the components.

For those who are familiar with Oracle JET, this works exactly the same as the Oracle JET Cookbook.

Once in the Cookbook tab, you can select the component on the left hand side. In the above screenshot, this is the task list component. You can open the demo code to see the JavaScript, HTML or CSS snippets. This makes it easy to help you get your custom application up and running. You can even change the look and feel by using the ‘Component Setup’ and edit the properties of the component you see and get the demo code for it.

Some of the APIs, like the demo page for the task details, actually need you to provide some of the component setup before they work. Here you will need to enter a task number to make the demo component work. Below the component is shown which task numbers are available. For the demo purpose I have also switched on the hide Attachment, Comments, History & Conversation toggle. If we press apply we will see the result of the Task Detail in the ‘Embeddable Process UI Components’ page.

Now that you know where to find the APIs and how to use them, you can pick any framework or technology you prefer and create your own tasklist. From an Oracle perspective, the best choice for this task is Oracle JET. However, if you have experience Angular developers within your organisation, you can decide to build it in Angular just as easy (or React, or Vue, etc.).

Although, now that you are using PCS as your choice of Cloud Tools, there is another good option within the Oracle Low Code Cloud Platforms. As part of the Oracle Integration Cloud you also have access to the Visual Builder Cloud Service (VBCS). This is a Low Code Cloud tool for rapid UI development.

VBCS works with JET under the hood and has an OOTB integration with PCS. You create a task screen or tasklist in a drag & drop style.

Jarvis Pizzeria: Second step in Implementing the Order Processing, Multi Instance Subprocess

In our previous blog we introduced the Pizza Order process. In this blog we will implement the next part of the Order Preparation process. We will add the call out to the Pizza Preparation process from the multi instance subprocess.

The first thing we need to do is feed every instance of the subprocess with the details of one pizza. For the outcome of the subprocesses we also need a storage location.

As a recap, an order consists of customer details and a list of pizzas to be made:
The order outcome is a list of status outcomes for each pizza.
We had already defined the data objects (DO’s) for these BO’s. Now we are going to associate them with the subprocess. For this we open the properties of the subprocess. Associated the DO’s to the consume and result of the subprocess (as shown on the right side of the image below). Now also make sure that the subprocess instantiates sequentially.

Next step is calling the Pizza Preparation process. Set the process call in the properties of the send activity.
Do the same for the receive activity.
Now we can feed the called subprocess with data. Go to the Data Association of the send activity. In here select the details of a specific pizza (by using the loopCounter over the list of pizzas) and associate it to the payloadIn of the Pizza Preparation process.
Next we do something similar for the receive activity.
And that was it again, how easy can it be? So let's deploy and see if everything works properly. But unfortunately the result of the test run surprised us. The first instance of the subprocess became suspended at the final step.

The EXECUTION_LOGGING shows the following message

And in more detail:
<auditQueryPayload auditId="1725" ciKey="366" xmlns="">
<dataObject name="InstanceCount" isBusinessIndicator="false">
<dataObject name="LoopCount" isBusinessIndicator="false">
<dataObject name="FaultMessage" isBusinessIndicator="false">
<![CDATA[oracle.bpm.bpmn.engine.model.runtime.microinstructions.TrappableException: faultName: {{}selectionFailure} messageType: {{}RuntimeFaultMessage} cause: {faultName: {{}selectionFailure} messageType: {{}RuntimeFaultMessage}
parts: {{
summary=<summary>XPath query string returns multiple nodes.
The assign activity part and query bpmn:getActivityInstanceAttribute('ACT8ab29e4034addb8071bc8eb9960d7ffc', 'loopDataOutput')[1] are returning multiple nodes.
The assign activity part and query named in the error message returned multiple nodes. It should return single node.
According to BPEL4WS specification 1.1 section 14.3, the assign activity part and query named in the error message should not return multiple nodes. Verify the part and xpath query named in the error message at line number -1 in the BPEL source.
We used the ‘loopCounter’ and the details in the subprocess proves that it works fine for the input (loopDataInput[loopCounter]’) so how could it be possible that we selected multiple nodes on the output (loopDataOutput[loopCounter]) side? Why is this?

If we take a closer look to the data available in the subprocess then we see that it is not necessary to access the data via an index in the array, but that a separate variable has become available. it therefore seems that we are not approaching the data in the right way.
After changing both the send and receive activities to the InputDataItem and OutputDataItem, we rerun the test. Now we get the expected outcome. Three times ‘Preparation Finished’ as we ordered three pizzas.
Does the ordering process now work as desired? No, not yet. It is not the case that someone on his own is baking pizzas somewhere. We are a growing company with ambitions where we want to prepare several pizzas simultaneously. So far, however, the pizzas are prepared one by one (sequential). Let's run the preparation in parallel.

Would changing to parallel processing be enough to arrange this? Let’s try and see what is happening.
Go to the properties of the subprocess and switch to ‘In Parallel’. Redeploy again and perform a new test.
As we can see, three subprocess threads are started and the order process becomes faulted. Why is the order process faulted? Opening the fault gives the explanation
We have got a conflicting receive. All subprocess instances are waiting for a response of the called ‘Pizza Preparation Process’. But which call is correlated to which response? To use the subprocesses in parallel we need custom correlation. That is the subject of one of our coming blogs.

Jarvis Pizzeria: Send Task vs Throw Message Event

Now that many of you are acquainted implementing BPM(N) processes, one should have noticed that there are multiple roads leading to the same goal while implementing a business process. One example is the invocation of an asynchronous service. This can either be done with a Send Task or a Message Throw Event. This blog tells about the difference between those two activities within PCS and when you should pick one over the other.
Let’s discuss the Send Task first. The Send Task lets you: instantiate a process, trigger a Receive Task in the middle of a process, or trigger a Message Catch event. Furthermore, the Send Task allows to attach boundary events to it. In other words, you can either attach an error boundary event to a Send Task as well as a Timer Catch Event. The former implies that the process that is invoked by the Send Task propagates its faults to the calling process.

How about the Message Throw Event? Well, it is nearly the same as the Send Task except that one is not able to attach boundary events to it and the calling process won’t be notified upon failures in the called process.

To show an example of the above we implemented two processes. The main process is shown below:

And the process that is called from the main process is implemented in the following way:
While implementing the main process, we ran into the following findings:
  1. The Throw Intermediate Event is able to invoke the Start, the Catch and the Receive in the calling process.                                

  2. The Throw Intermediate Event does - indeed- not allow us to attach boundary events.

  3. The Send Task allows us to invoke the Start, the Catch and the Receive task.

4) The Send Task allows us - indeed - to attach boundary events to it:

Where the upper boundary allows you to catch system faults and/or (a specific) business fault(s).

So where does that leave us? When to pick which activity? In the left corner of the boxing ring we have the Send Task and in the right corner we have the Throw Message Event. Use the Send Task when:

You want to keep track of time passing by. A possible use case can be that you start a process that facilitates a customer to pay. When no payment transaction occurs within 30 minutes, the timer expires and the main process can cancel the order.

You want to be sure that the invoked process is invoked (and executed) correctly. In case of any malfunctioning the main process will be notified. But only use the Send Task to either invoke a Start event or a Receive task. Don’t intertwine Send Tasks and Message Catch Events.

Use the Throw Message Event:

When you are implementing a Fire and Forget message exchange pattern. You don’t want to start a process with the Throw Message, but you want to notify running processes.

In combination with the Catch Message Event.

For those of us that are used to working with BPM suite, there aren’t many differences. However, there is unfortunately no opportunity to use the Throw Message Event to trigger an Event Subprocess, as the Event Subprocess is not part of the PCS implementation. Furthermore, BPM Suite supports the usage of so called Signals to communicate in a 1-n manner with other processes. In PCS there is no such thing as signals.

Jarvis Pizzeria: First step in Implementing the Order Processing, Interface Definition

In a previous blog post we gave a functional description of the pizza preparation process. For this we used the image below. Till now we only have implemented the bottom part ‘the preparation of a single pizza’.
In this post we will do the next step. The preparation of a complete order, containing potentially multiple pizzas. We will do this in a separate process. So let's start by creating a new process in the preparation application. We gave it the self explaining name OrderPreparationProcess.
Next we created the process flow. We used the baby-step approach to implement to flow, for this reason we start with all components in draft mode.
Make sure to define the subprocess as Multi instance. For now is does not matter yet if it’s sequential or parallel.

First thing to do is feed the flow with some data. We know the data format for a single pizza. An order consist of one or multiple pizzas, so we need a list for that. Besides that we need information about the customer, like name and address. For demo purposes we have limited the amount of data, but in a real life scenario, more data is needed. But we assume you get the point. So let's go.
Start with creating a new Business Object for an order. We called it OrderPreparationBO
Click next to get to the attributes page.
Then, click the Plus sign to add an attribute
After giving a name, select ‘Change Type’ to specify a list of PizzaPreparationsBO’s.
After clicking OK, the attribute is defined as shown below
Click add, to add it to the new Business Object.

We also added the general customer data attributes as shown here.
Now we have defined the input payload format of an order. Next we need to define the output format of the order. Because we don’t want to make it to complicated we have used a String simple type for that, which means that no Business Object is needed.

Now that we have defined the input and output format we can start using them in the process. First we will do the input. Open the properties of Start Order and click the pencil next to Define Interface.

Add the payloadIn argument with type OrderPreparationBO.

That’s all, the input payload is specified.
Do the same for the output.
Now we have defined both the input and output, but of course the data also needs to flow through the process. First lets create a Data Object for that. After selecting the Start Order Message Event open the Data Associations via the button in the top right corner.
In here we see on the left side our order Payload. On the right side we see the Data Objects. In there, add a new Data Object to store the order.
After creating the Data Object, the order can be associated.
Do something similar for the output. We just return the constant value ‘Done’.
Perhaps it is somewhat boring or disappointing but let see the result so far to go. Deploy the application and create some instances with for example SoapUI.
After submitting a soap call with an order containing three pizza the process has the following flow.
And in Tree view mode, we do see that three subprocesses have been executed. So we are on the right track.
What’s next?

In coming posts we will continue to complete the picture. Next part will be the call out to the pizza preparation process from the multi instance subprocess. After that we will extend it with a Decision Model and custom Correlation. And of course besides these topics we will also continue to blog about other PCS features.