Distribution Modeling in Data Orchestration Engine: Dependency with Dependency Rule
This is in continuation of simple dependency explained in Distribution Modeling in Data Orchestration Engine: Dependency and Dependency with Static Filter.
To make it slightly easier the pure dependency based distribution relies on the relation among the data. And for a following data object’s record the preferences of receiver for any further record filtering is not considered.
So taking the ServiceOrder and Customer example of “Distribution Modeling in Data Orchestration Engine: Dependency and Dependency with Static Filter”, it will mean that receiver is getting ServiceOrder because of relation that ServiceOrder is having with the records of Customer. But because of some receiver property or preference, can the ServiceOrder records be distributed more efficiently? The dependency rule comes handy for such cases. The dependency rule follows the similar concept as that of normal distribution rule. The difference comes in the manner that it tries to further filter out the records that have been identified by the dependency on which the dependency rule is modeled.
The problem we solved in “Dependency and Static Filters” is to “distribute incomplete ServiceOrder to those receivers which also receive the corresponding Customer records in such a way that Customer’s location matches the receiver’s location”.
An example problem statement for dependency rules for above can be: “Distribute incomplete ServiceOrders based on servicecategory [say automobile, electrical etc] to those receivers having the required category skill based on the corresponding Customer records received by them in such a way that Customer’s location matches the receiver’s location”.
Distribution modeling for this problem statement will involve:
Modeling distribution rule on Customer such that receivers get the records based on location. This cause the Customer records to be distributed to receivers.
Modeling dependency with static filter between Customer and Service order. With Customer as the leading data object, this will cause all the corresponding ServiceOrders to be identified for the receiver which received respective Customer records.
Model dependency rule on the dependency created in step-b, such that ServiceOrder’s will be distributed to receivers where ServiceOrder’s category matches the receiver’s category. This will act on the ServiceOrder identified for step-b, and filter them further based on the dependency rule details.
Note: If all the dependency rules modeled on a dependency are in INACTIVE state, then no records from following data object will be identified for the receivers for the corresponding dependency.
The dependency rule can affect performance as it has to check extra conditions. In particular, the rule operators and the number of record in node used for rule modeling needs to be considered carefully.
With reuse of distribution rule concept on dependency, the DOE thus provides another powerful distribution capability.