User Tools
Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
en:adminmanual:businessmappings:decisiontable [2020/08/17 00:33] joebordes [Full Map Structure] |
en:adminmanual:businessmappings:decisiontable [2020/08/20 21:06] (current) joebordes [Default Value] |
||
|---|---|---|---|
| Line 330: | Line 330: | ||
| the possibilities that the implementor has are very big. | the possibilities that the implementor has are very big. | ||
| + | |||
| + | ===== IGNORE Reserved Word ===== | ||
| Finally, comment on a very important option where you can set the value of any variable in the context to **%%__IGNORE__%%** to have that variable eliminated from the decision. This permits us to create complex rules with many variables where we search on only a few of them at a time. | Finally, comment on a very important option where you can set the value of any variable in the context to **%%__IGNORE__%%** to have that variable eliminated from the decision. This permits us to create complex rules with many variables where we search on only a few of them at a time. | ||
| + | We can also use this special reserved word in the rules table itself to create rules which cover many cases. For example, we could have a table of rules like this: | ||
| + | |||
| + | ^input1^input2^output^ | ||
| + | |e1|c1|r1| | ||
| + | |%%__IGNORE__%%|c2|r2| | ||
| + | |e3|c3|r3| | ||
| + | |||
| + | |||
| + | With these rules in place, any decision that has input2==c2 will pass no matter what value is passed in as input1. Note that this can easily cause that more than one rule to pass. If we add a rule to the table above, like this: | ||
| + | |||
| + | ^input1^input2^output^ | ||
| + | |e1|c1|r1| | ||
| + | |%%__IGNORE__%%|c2|r2| | ||
| + | |e2|c2|r2b| | ||
| + | |e3|c3|r3| | ||
| + | |||
| + | and we pass in the values | ||
| + | |||
| + | - input1=e2 | ||
| + | - input2=c2 | ||
| + | |||
| + | **both r2 and r2b will pass** and be returned, so if we have a hit policy of Unique it will fail and if we have a hit policy of First then the sequence is of utmost importance to get the correct result. | ||
| + | |||
| + | ===== Default Value ===== | ||
| - | ==== Preprocess Directive ==== | + | Using the %%__IGNORE__%% reserved word we can implement a default value for our rules. If we define a rule where all the input values are set to %%__IGNORE__%%, this rule will pass for all input values. If we set the hit policy of the decision map to First and order the rules in a way that the all %%__IGNORE__%% rule is always the last to be evaluated we accomplish a decision table where any combination of input values that is not explicitly defined will return the values in the all %%__IGNORE__%% rule instead of %%__DoesNotPass__%% |
| + | ===== Preprocess Directive ===== | ||
| Following the new enhancements, we don't have to valorize context variables on the Decision Table map using the Execute Expression Workflow before evaluating the Decision table map. The map will be evaluated on the context of the values that are present on the screen. | Following the new enhancements, we don't have to valorize context variables on the Decision Table map using the Execute Expression Workflow before evaluating the Decision table map. The map will be evaluated on the context of the values that are present on the screen. | ||
| Line 363: | Line 390: | ||
| <condition> | <condition> | ||
| <input>guestcount</input> <!-- context variable name --> | <input>guestcount</input> <!-- context variable name --> | ||
| - | <preprocess>if season == 'Spring' then '*' else guestcount end</preprocess> <!-- if present sends the expression to the workflow expression system--> | + | <preprocess>if '$[season]' == 'Spring' then '*' else '$[guestcount]' end</preprocess> <!-- if present sends the expression to the workflow expression system--> |
| <operation>e</operation> <!-- QueryGenerator operators --> | <operation>e</operation> <!-- QueryGenerator operators --> | ||
| <field>guestcount</field> <!-- fieldname of module --> | <field>guestcount</field> <!-- fieldname of module --> | ||
