I wanted to share an approach I have been using to simplify the creation of complex rules.Users new to SAP information Steward typically are quick to grasp the creation of simple rules, however when it comes to creating complex rules and using the Advanced Editor a number ‘non coding’ users are often overwhelmed and daunted by the prospect of creating a rule like the one below:
So how can we create complex rules but avoid this complex scripting syntax (if/then/else/begin/end/return etc……) ?
Creating Information Steward Views is a valid strategy to address the complexity, though we should avoid thinking that we need to create a view to support every complex rule, as this leads to increased maintenance, less transparency and a potential IT dependency. Information Steward Views will definitely form part of a rules strategy, but shouldn’t necessarily be first port of call. Pre-processing data outside of Information Steward using tools such as SAP Data Services should be preferably avoided as this, means that the definition of the rule and the maintenance is spread across two separate tools.
Many of the complex rules can be created in advanced rule editor, we just need a simpler approach to avoid all the complex coding constructs.
A Simplified Approach – Re-think as a decision table
Let me illustrate this approach with a worked example.
1) Identify columns to evaluate and valid value combinations
2) Add the columns as parameters in the rule. The next step is to go into the advanced editor. I typically create a simple rule first and then select the advanced editor, this has the advantage the that Begin Return and End block are entered for you. You then replace the simple rule condition with the multiple conditions, one for each valid combination row where the columns conditions are separated by AND’s and the Rows separated with an OR. There is no need to worry about if/ then/else blocks, and the rule is simple to read!
3) Identify potential filters to improve performance and add these as a simple OR condition – no need for Begin/Returns/End’s in filters
4) Save the rule and create a test set of data based on the condition table and validate the expected results. The creation of a test data set is good practice, but is often skipped as it is seen as ‘just an extra step’. I would also strongly encourage the testing of the rule independently first before binding to the source data and executing. Too often a user will complain that the rule isn’t working when running the rule against their data. They then frantically start to modify the rule, where in reality the rule was correct, it was just that the results were not what they expected. It could also be the rule is correct but the binding was incorrect. Testing the rule independently will avoid this confusion.
An additional benefit of creating the test data set is that an approver can run this test before releasing a rule.
5) Finally Bind the rule to the columns in the table / view and calculate score.
And that’s It!!
After creating a few rules using this approach, even non-coders can quickly define complex rules.
This ‘Decision table’ approach can also be applied to more complex rules such as in the table below :
To reference another field in another table the ‘Exist’ and ‘lookup’ wizards can be used to create these functions. It should also be noted that it is possible to use these functions in the filter condition thereby restricting the data to process based on a reference to another table/column. So as you can see this approach can be used to model very complex multi-source conditions.
It’s fair to say that this ‘Decision table’ approach alone won’t allow you to solve every complex rule and Information Steward views will certainly be used as well. You may need to adopt an alternative strategy if dealing with extremely high data volumes and you need to tune for performance.However, what this approach does do is open up the ability to create complex rules to a much wider user base and make rule maintenance simpler.
Give it a go….