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 https://s0.wp.com/wp-content/mu-plugins/wpcom-smileys/twemoji/2/72x72/1f..." alt="