Jarvis Pizzeria: Functional description of the payment process

Before we start preparing our pizza the order needs to be paid. With the implementation of the payment process we try to answer the following questions:

• How do the business rules work in PCS and how do they differ from their on-premises counterpart?
• What types of gateways do we have at our disposal?
• Do we have multi-instance subprocesses?
• How do we implement correlation?
• And more…

The business process that would fit most of our purposes would look something like the image below:

We start our process without a message, i.e. the payment process will be a reusable subprocess, according to the blog ‘Setting up the Jarvis 1.0 process’ where we explained the setup of our main process.

After the start we are going to determine which payment options would be at the customer’s disposal. Interesting to see is to what extent the web based version of the business rule implementation will be a copy of the business rules editor we have at our disposal in the on-premises versions of the BPM suite. Although that implementation is quite intuitive and straightforward, it definitely leaves room for improvements. Let’s find out!

The second activity will be a multi-instance subprocess where we will use the outcome of the business rules to start the available payment options. Although it is not clear from the picture, we are intending to implement the subprocess as a multi-instance parallel embedded subprocess (see the image below).

After starting the several payment options we have to wait for a callback of one of the payment options confirming the order has been paid. Obviously the event-based gateway is the component to use for listening to the several callbacks.

The observant reader might have noticed that using a parallel subprocess to make several service calls and subsequently use a single callback setup looks counter intuitive. We agree, but let's see what PCS is up to :).

There is also a timer connected to the gateway as we don’t want to wait forever for the customer to pay. After a timeout of the payment we notify the admin, here we want to try out the notification task mechanism of PCS, and end the process by throwing an error end event which will be caught by the main process as we have seen in the blog ‘Setting up the Jarvis 1.0 process’ .

After the gateway construction we will notify all the instances that we have started (a combination of creditcard, debit and deferred payment based on the outcome of the business rules) that the payment has happened in one of the available manners. These services have to listen to the event we throw and end themselves peacefully. This way we don’t end up with a bunch of orphan processes and we can experiment with the usage of correlations.