Jarvis Pizzeria: Setting up the Jarvis 1.0 process

For the Jarvis pizzeria process we have distinguished three phases: payment, preparation and delivery. Hence, the main process is comprised of those three phases. Setting up the main process enables us to work together, because each one of us can implement a separate phase, without running into merge conflicts or whatsoever.

For creating a new process, click the plus icon in the application home screen.

Note that we can check the “Document Only” box, which will start our process in draft mode, i.e. disabling the implementation of activities. As pioneers we like to live on the edge as we let the “Document Only” checkbox unchecked and start right away with the implementation.

On the right hand side of this popup, PCS allows us to choose from certain start patterns. As we would like to use SoapUI later on to start our process with a payload, we choose to start our Jarvis process with a message.

For the implementation of the three phases we tried to mix up the different options of calling a process. Looking at the picture below, the first step in our process is concerned with payment. Obviously, we don’t want to hand out our precious hand crafted pizzas for free.

The payment process is implemented as a Call activity which calls a reusable process “PaymentProcess”, which can be selected by opening the properties of the Call activity. This will open the properties screen below the process where we can configure the Implementation of the Call activity.

The preparation process is an asynchronous process, so we use the send and receive tasks for starting the process and receiving its callback.

This implementation is also known as a Process-as-a-Service call which comes with the drawback of marshalling and unmarshalling the payload. We are not totally sure what the impact will be in a PCS environment, but we suggest to take it into consideration before using it as the default pattern in your application.

Last but not least, the delivery process is implemented with both a message throw event and a message catch event.

Although the Send-Receive activities and the Throw-Catch activities might look the same, there are some subtle differences. The most important thing to consider is that the Send and Receive activities support attaching boundary events to themselves, whereas the Throw and Catch events do not. This implies that within the process we can catch an error on the invocation of a process and act upon it, whereas an error while invoking a process through a throw event would disappear somewhere in the abyss.

When implementing the main process we must admit that we were happily surprised by the fact that PCS neatly aligns the activities in order to make it look like a decent and readable BPM process!

Now that we have composed the main process we are ready to implement all the stages and start baking some pizzas!