To make the delivery of the pizzas to our customer, we need to decide how to deliver the pizzas. In our process we’ve already got the order data, so we know what the order is and where it needs to be delivered, but what is the best way to deliver the pizzas?
We will create a decision model in PCS to help us with this decision. In the delivery process we will call the decision model like a service and use the answer to make the correct decision.
The input for the decision model will be the amount of pizzas and the distance to the customer. Based on these data we will decide to either use a bike, moped or car to do the delivery. A very common decision to make in the Netherlands, since we love our bikes and often deliver pizzas by bike rather than by car.
We start with going to the PCS home. All the way out of the jarvis application and on this home menu we click the create button. Here we see that besides new applications, we can also create a new decision model. This means the decision is not coupled directly to the application with our processes, but it is a stand alone decision model.
When creating the decision model a name, description and workspace is entered after which we can open the model.
The Decision Model uses DMN, Decision Model and Notation. For those using Business Rules on-prem, this is very familiar to Business Rules, but slightly different. Oracle advises that if you can use DMN instead of Oracle Business Rules, you should!
DMN is a standard published by the Object Management Group (OMG). It is a standard approach for describing and modeling repeatable decisions within organizations to ensure that decision models are interchangeable across organizations.
There is also an option to use FEEL, Friendly Enough Expression Language. We will explore this option and how to use this in a separate blog. For now we will create a decision table to make the decision for us.
After creating the model, there is a 5 step guideline how to build it. First we need to add the decision, after which we define the input. Based on the input we can start modelling the decision, this is the step where we model the logic, the heart of our decision model.
Before deploying, running and using our decision model, we can test it internally in the tester. After we are satisfied with the results, we can create a service to invoke the decision model.
We start with creating the decision, by clicking the add icon.
In the creation of the decision we will give it a name, description and some general information. On the right we choose Decision Table.
After the creation of the decision, we see a couple of options to use within the decision.
In this case we want to use the Decision Table.
On the top right hand side of the table, there are options to add columns and rows:
However, we start with describing the output to the DeliveryMethod. When clicking on the yellow bar, we get a popup to configure this. We choose a List of Text values, and add the values Bike, Moped & Car.
This results in the following header of the yellow DeliveryMethod column:
After the output, it is time to configure the input. This happens with the help of the input data on the right hand side. When you click the grey arrow in the black bar, the input section will open.
In here we can add the input data, or even special definitions for the input of our decision. In this case, we just need two numbers as input, the distance to the customer and the amount of pizzas within the order.
So we only need the top section of the input data and use the add icon to start adding the input arguments and use the predefined number type for them.
Clicking the add icon will result in a fold out to the left and we can enter the name as well as the Data Type.
The result will be two number typed input arguments within the input data section.
Now that both the input and the output data are in place, it is time to start working on the logic within the decision table. First we add an extra column using the buttons on the top right. After that we use the first column for the amountOfPizzas variable and the second column for the DistanceToCustomer variable.
Now that the columns are all set up, we can start adding rows in the decision table. The table constantly evaluates the expressions & conditions, which can be helpful as well as annoying when working on the logic.
When you think you are done with the logic, make sure all the warnings are gone, especially the gap analysis can be quite helpful within the decision table.
The assumption we use for creating the logic in the decision model is that both the bike and the moped can carry orders up to 5 pizzas. It is just better to do the nearby deliveries on bike and the ones further away on the moped. If the order gets too big, or too far away, we need to use the car!
This results in the following, valid decision table:
Now that we have the logic of our decision table in place and all validations are passed, it is time to test the logic within our model. We can do this by clicking on the play button in the top right corner.
Clicking the play button will launch the tester of the Decision Model. We can enter input data manually, click on the ‘Start Test’ button and the result will be displayed.
For example, we have entered an amount of 4 pizzas and a distance of 1.
This will result in the output ‘bike’.
To use the DeliveryMethod within our process we need to create a service out of it so we can call it as a stand alone service. Expand the Services bar on the left hand side.
In here we click the ‘add’ icon to create a new Service.
As name we enter ‘getDeliveryMethod’.
This generates the following layout in which we need to define the input & output for the service.
We can Drag & Drop the input data from the input section on the right hand side into the input data section of the service. As output, we need to Drag & Drop the DeliveryMethod in the Decision section to the Output Decisions. The result will look like the picture below.
Now we need to deploy this. For this we click the blue ‘Deploy’ button on the top right.
After the Decision Model is successfully deployed, we can start using it from within our process. In the Delivery Process we select the predefined Decision Model.
Pressing the ‘add’ icon on the right of the Decision Model will bring up a popup to select the DM.
Since we’ve only got one DM yet, it is very easy to find and select. We name it the ‘DeliveryDM’. Since this only has one service, the just created ‘getDeliveryMethod’, this is automatically selected.
Now that we have our DM in place, we need to open the Data Associations. In here we need to map the correct data from the payload as input to the DM as well as the output to Data Objects within the process.
After this, the Decision Model is integrated within the Delivery Process and the output can be used in the gateway to decide how to do the delivery of the pizzas to the customer.
Conclusion
In our previous blog we saw how decisions can be implemented with rules. This feels a lot like the on-premises rules we know from Oracle Business Rules. However, now that we also explored the new Decision Model within PCS, it might be worth to shortly compare the two.
We favor the new Decision Model, because this is a stand-alone component, it feels like a microservice that can be developed, test and deployed as a separate component with its own lifecycle.
The Decision Model applies the standard DMN notation from the Object Management Group and it feels like a newly designed and ‘build from the ground’-feature as where the Business Rules feel more as the on-premises implementation that has been shipped with PCS as well.
This, together with the recommendation of Oracle to use DMN if possible, we feel that we could explicitly express to favor the Decision Model over the rules implementation.
No comments:
Post a Comment