Jarvis Pizzeria: Using a DM in PCS (how to manage versions …)

In this blog we show two different ways to embed a Decision in PCS. This with special attention to version control.

In PCS (OIC component) it is possible to use a Decision Model Activity directly from a process. See the image below.

This process uses a Decision to calculate how much time it takes to deliver an order. To not make this all too complex, the Decision takes into account a limited number of factors, namely distance and means of transport.

In Version 1.0 – DeliveryTime-s1 we have implemented the following decision table in the Decision.

However, it now appears that we regularly receive orders that must be delivered to locations up to 20 Km. We want to deliver these orders by car. The Decision must also be adjusted for this. A number of lines must be added. What this table will look like then probably speaks for itself. We will not go into this further, as it is not relevant to the use case.

However, what is relevant is that this new Decision must be used in the existing process. We have a number of options for this.

If we look at the Decision in the process, we see that it is linked to Version 1.0.

And when we click on the Decision, we see that it is linked to DeliveryTime-s1 (the first snapshot).

Option 1: Active the Decision as Version 1.0 – DeliveryTime-s2

After modifying the Decision we can for example, activate the Decision as Version 1.0 – DeliveryTime-s2.

This is by far the simplest approach. Because the process is linked to Version 1.0, nothing needs to happen there. If we now click through from the decision, we see that it is linked to DeliveryTime-s2.

The question is whether this is desirable?

That will depend on the situation. In our scenario, this probable works fine if we just want to expand the table with extra lines for the car. But what if the algorithm should take into account more variables. For example, the number of pizzas ordered. A large order can be better delivered by car than with 2 or 3 scooters. In that case we want to use a new version of the Decision.

Option 2: Active the Decision as Version 2.0 – DeliveryTime-s3

After modifying the Decision we can also activate the Decision as Version 2.0 – DeliveryTime-s3. However, the process is linked to Version 1.0 and will not use the new 2.0 version. This is easily repaired through the “Update definition” of the Decision.

After clicking “Update definition” the following popup appears

Select the 2.0 version and then click update.

However, we have now made an adjustment to the process application. In this case it must therefore be reactivated (possibly as a new version). In this scenario, this seems like a logical step. The input of the Decision has been expanded with the number of pizza. The process must provide this. So the adjustment is too responsible.

But what if the interface of the Decision does not change, and we still want to change to a different version. E.g. if we want the version number to be increased if the car is added as a means of transport. Then an “update of the definition” is the only thing that needs to be done in the process, but this does result in reactivating the application.

So a “hard-coded” link has actually emerged between the process and the Decision version.

Question: can this “hard-coded” relationship be somehow circumvented?

Note: we do not consider the question whether this is desirable in a production environment. There are various reasons for doing this or not. But we want to keep that discussion out of the blog. In the blog we look at the technical possibilities.

The short answer is “Yes”, …

But unfortunately not in the way you might expect.

A Decision activity is always linked to a specific version of the Decision. There is no possibility of choosing “latest” which would very easily solve the problem.

In the picture above there are 3 decisions. Version 1.0 – Snapshot 1 has become unreachable for the process. The others can all be “hard-coded” linked to a process.

However, if we take a closer look at the decision, we can see that all snapshot versions are still available and that one of them can also be reached via ‘latest’.

Open the Decision and then select Snapshots at the top right to manage them. Then select ‘view’ from a specific snapshot via the hamburger menu.

After the snapshot has been opened, the corresponding url can be found via the Payload.

The most interesting url is the url of the current source (not of a snapshot). This contains the reference to ‘latest’.

But if these are not available in PCS, what should we do? ICS offers a solution here. In ICS it is very easy to call, besides the versions also, the snapshots including the latest snapshot. So by placing an integration between the decision and the process, we have the option to avoid the “hard-coded” relationship between the two.

The picture below shows this in the process.

This brings me to the end of this post. However, the story is not over yet. In a follow-up post I will describe this ICS integration step by step.