Jarvis Pizzeria: How to manage Masterdata of a DM (part 1)

This blog is a follow up of Using a DM in ICS, but can also be read as a separate item.

We have implemented the decision table below in a Decision Model (see Using a DM in PCS) and we have made the Decision Model accessible through an integration (see Using a DM in ICS). But now let’s look at the data in this table.

Suppose that it turns out that deliveries by scooter at distances above 5 Km turn out to be faster than expected (because this is usually outside built-up areas, where there is less traffic).

For this we have to adjust the CalculateDeliveryTime in line 6 of the table from 20 to e.g. 18. Once this is done we must activate a new snapshot. Because the integration of the previous blog refers to the LATEST snaphot version, no further adjustments are needed. The Decision integration can be used unchanged.

Changing the CalculateDeliveryTime, but also the Distance range are data where we can imagine that they will change regularly. The question is whether we want to reactivate the Decision for each adjustment?

If the answer to this question is “No”, we must see if this can be done differently. Is there an alternative? “Yes” there is. We will explain that further in the remainder of this blog.

The first thing we do is take a closer look at the decision table.

We can break this down by means of transport. We have 3 rules for each means of transport. If we then also replace the values ​​in these lines with variables, we get the following:

• note 1: <var1> is the means of transport
• note 2: in the first line the format is converted from <1 to [0 .. 1).

Now let’s implement this setup in the Decision. This can be done as follows:

• note 3: deliveryTimeConfig.deliveryTime4 is the default value (return value when the distance is not in a standard range). In the remainder of this post I will ignore this.
• note 4: means of transport is no longer needed in the decision table. The value of the other variables that comes in as input varies per means of transport.

We must then expand the decision service input with values ​​for these variables.

For completeness also the definition of the defined type:

Next, we have to adjust the integration so that the payload of the Decision call is expanded with values ​​for the variables. For this we have to update step 2 and 3 in the following picture.

In step 3 we have to adjust the request payload. Previous payload:

{ "Distance" : 2, "Transport" : "bike" }

New payload (json example):

{
"Distance" : 2,
"deliveryTimeConfig" : {
"distanceFrom1" : 0,
"distanceTo1" : 1,
"deliveryTime1" : 6,
"distanceFrom2" : 1,
"distanceTo2" : 3,
"deliveryTime2" : 12,
"distanceFrom3" : 3,
"distanceTo3" : 6,
"deliveryTime3" : 20
}
}


And in relation with this change, the mapping of step 2 must also be adjusted.

 

• note 5: the means of transport is still needed in the payload of the integration but not in the call to the Decision.

In this mapping, the variables are filled with a constant that depends on the means of transport. As an example. If the transport has the value ‘bike’, the distanceTo1 variable is filled with the value ‘1’. If this is not the case, the variable is filled with the value ‘2’. See screenshots below.

Is it really that simple to use variables?

Unfortunately there is still a snag. Oracle currently does not yet support variables on the input side of the decision table. This means that a decision table cannot be used in this way.

But luckily it is possible to implement the decision table with a number of if-then-else constructions as shown below.

On the outside the Decision service has not changed by these if-then-else constructions. The Decision service interface can remain unchanged. Internally, the structure of the decision functionality has changed slightly. So there is no immediate need for input variables support in a decision table. But because many users are used to an excel like interface, I hope that support for input variable will be added in the future.

Finalizing

Now we have moved the constants from the Decision to the Integration. In the next blog we go one step further and we will retrieve the constantes from a VBCS Business Object.