You can reduce the complexity and testing of large Ruleflows by breaking a Ruleflow into smaller Ruleflows, and then constructing the larger Ruleflow from them. The resulting modularity simplifies unit testing and collaboration.
Consider the following Ruleflow from the Life Insurance sample project:
The Ruleflow editor shows the iSample_policy_pricing.erf canvas with seven Rulesheets in sequence. The first three apply the risk assessment rules and the other four Rulesheets are in a Subflow to generate a policy based on that assessment. (The Subflow has no processing impact.)
To use this sample to demonstrate Ruleflow within a Ruleflow, perform the following steps:
1. In the Life Insurance project in Project Explorer, right-click on iSample_policy_pricing.erf, and then choose Copy.
2. Right-click on that file again, and then choose Paste. Name the file iSample_AssessRisk.erf.
3. Again, right-click on that file, and then choose Paste. Name the file iSample_GeneratePolicy.erf.
4. Open iSample_AssessRisk.erf, click on the Subflow, press Delete, and then save the file.
5. Open iSample_GeneratePolicy.erf, select the three Rulesheets above the Subflow, press Delete, and then save the file.
The original Ruleflow has now been cleaved into two separate Ruleflows as shown:
iSample_AssessRisk
iSample_GeneratePolicy
6. In the project, create a new Ruleflow named iSample_policy_pricing_Ruleflows.erf.
7. Drag iSample_AssessRisk.erf onto the canvas, and then drag iSample_GeneratePolicy.erf to its right.
8. Add a Connection from iSample_AssessRisk.erf to iSample_GeneratePolicy.erf, as shown:
9. Save all the Ruleflow files.
Note: The original files are referenced and you are allowed to browse to choose a different Ruleflow that uses the same Vocabulary. You can change the name of the Ruleflow in this context so that it provides meaning, and you can add comments. None of these actions change the Ruleflow properties of the original Ruleflow.
You can now test the result. Because we only added Ruleflows and changed none of the original project files, you can run Ruletest in the project, alternating the test subject from iSample_policy_pricing.erf to iSample_policy_pricing_Ruleflows.erf to see that they both produce the same expected output.
Once you have these two Ruleflows, you can update and test each independently, and -- as long as you ensure that the Vocabulary stays consistent -- separate teams can collaborate on developing risk rules and policy rules. That makes it easy to reuse either of these Ruleflows. For example, if risk assessment applies to all markets but policy pricing varies, you can create a new Ruleflow that brings in the same AssessRisk module to provide the data to process against a modified policy pricing Ruleflow for another market, as illustrated:
Ruleflow Activity
A Ruleflow file's Properties can provide settings for versioning and effective date stamping of the Decision Service that will be created. (See the topic Ruleflow versioning and effective dating for details.) However, when a Ruleflow is added to another Ruleflow's canvas, it ignores its Ruleflow Properties and takes on Ruleflow Activity Properties that are local to its role as a component of another Ruleflow, as illustrated:
The parent Ruleflow provides its own settings for versioning and effective date stamping of the Decision Service that will be created, as illustrated:
Note: Deploying Ruleflows within a Ruleflow - When this Ruleflow is deployed, the generated Decision Service will include the content of both Ruleflows. However, when either of the included Ruleflows changes, Ruleflows that include one of them are not automatically updated -- each must be redeployed to include the changes.
