When the order comes in, payment needs to be made first before we start preparing the pizza. Our order payment process supports three possible payment options:
- Creditcard: obviously a commonly accepted payment option
- Cash: although we are a very tech-savvy company we would also like our old-fashioned customers to be able to pay the pizza with cash money
- Deferred payment: our most trusted customers can pay their order in a deferred way. Deferred payment means the customer receives an invoice per email and is asked to pay the order within two weeks.
The payment process is depicted below. The first activity in the process is concerned with determining which payment options are available. What component can we use to insert some facts, start reasoning about those facts and give us an answer based on those facts? Of course...Oracle’s own business rules!
In the picture below the business rules component is magnified. As shown in the picture, we attached a boundary event to the business rules activity. The reason is that in case the business rules fail - for whatever reason - the payment process is cancelled instantly and a business fault is thrown to the parent process.
Let’s take a look into the business rules component itself. Interesting to see is what the implementation screens look like and how they differ from the JDeveloper environment we are all familiar with.
When opening the “Rule”-properties and adding a new Business Rule we get the following popup:
We name our business rule “PaymentRules” and give as input parameters the order amount and the customer Id. We expect our business rules to output the allowed payment options in a string separated format.
As eager developers we want to open our business rules editor immediately, hence we leave the checkbox checked.
When the editor opens we start by creating a decision table.
As “Decision Table 1” is not a very convenient name, we first rename the decision table to “PaymentOptions” and leave all the other fields unchanged.
Because it doesn’t make sense to reason about non-feasible facts, we can add a kind of precondition.
Now we can start adding conditions:
All orders up to and including EUR 10 can be paid both with cash and via creditcard and are - in case we have a trusted customer - applicable to deferred payment. We add the value “10” to the list of values:
Note the checkbox which indicates if the value 10 itself would also be included in the range.
Having added the “10” value, we can now select our range from the dropdown menu:
Note that the condition we actually want - orderAmount <= 10 - cannot be chosen from the dropdown menu. So obviously the “Include Endpoint” checkbox was not the option we needed. Adding the value 10 again but without the “Include Endpoint” option, we get the following dropdown list:
And that’s exactly what we want!
Now we can add another rule for all the order amounts that are greater than EUR 10. We don’t want our pizzeria to store large amounts of cash money for security reasons, hence orders that exceed the EUR 10 amount must be paid with creditcard, or, in case the customer is allowed to, paid in a deferred way.
Having defined the ranges of the order amounts, we can now add a condition that checks the id of the customer.
But before we add a condition, it might be convenient to create a list of values first on which we can base our condition. To do that, we click the following icon in the uppermost toolbar.
This brings us to the following screen.
Here we can add our customers.
Now we can go back to the rules and add a condition.
We select our customerId from the list.
But before clicking “Done” we are going to associate a ValueSet to this condition by pressing the pencil at the bottom of the popup.
We select the “CustomerAliases” set.
Using the “Split table” function in the utilities dropdown, the rules editor will generate a table for us with all the possibilities
Note: we are aware that this is far from an ideal way of setting up your business rule. “For the sake of science” justifies a lot :)
Cool, now it’s time to add the actions.
We choose the “Add action - modify” as we want to modify our output parameter.
We select the PaymentRule.out value and check the “With parameters” checkbox.
This results in the following overview:
The v-signs indicate that the specific rule is active.
Now we can start filling in the possible options.
Conclusion
Although this blog just shows a peek of all the possibilities PCS’ business rules has to offer, the goal of this blog was to wander around, get acquainted with the look and feel and see to what extent the PCS business rules deviate from the on-premises implementation we are all so familiar with. The answer can be short and concise: one who is familiar with implementing business rules in JDeveloper is not going to have any difficulties implementing the same rules in PCS. Maybe the closest thing you can compare the editor with is the rules editor of the SOA composer.
Are there things missing? Well, actually, there is one item that lacks in PCS compared to the on-premises business rules: the option to test your business rules design time. Although we’ve never been happy with the setup of the design time test functionality within JDeveloper (creating design-time tests for business rules is a tedious task and gets JDeveloper to run into a frozen screen every now and then), at least it gave us the option to test before we would deploy the whole application. Does PCS offer us any other possibilities to evaluate facts and make decisions? Let’s find out in our next blog!
No comments:
Post a Comment