This article can be taken in continuation with the Distribution Modeling in Data Orchestration Engine - 1 series available sometimes back in the SDN. In this series the focus will be on the dependency modeling.
Dependency:
One option of identifying data for the receivers is through the distribution rules wherein DOE evaluates the content against the modeled rules. This makes the simple distribution paradigm of distribution based on rules. This approach is simple way for distributing those data which can be processed in isolation by the client application running on devices. However it rarely happens that all the enterprise data will qualify to be processed in isolation. For various reasons underlying data model is likely to have relations. There can be multiple DOE data objects are created out of such underlying enterprise data models. And it may be necessary by application to have all the related object records be available for processing. In such cases, modeling distribution rules may involve complications but their corresponding dependency model may appear to be intuitively simple. For eg if considered all the data objects in isolation, then for modeling rules developer need to ensure the common criteria details exist in all the data objects having the need to be processed together. This will then involve adding additional fields to data objects, and hence more handling in the BApiWrappers for those fields.
Instead for the same one can use dependency to distribute the related records from different data objects.
With dependency, developer needs to ensure that relation exists between the related data objects by modeling node associations among the related data objects. Once this node association is identified, the same details can be used to build the dependency model.
For example consider the service order scenario. For this, at minimal, typical data objects that can be thought about are ServiceOrder and Customer. And it is expected the service orders be given to recipients based on the Customer region.
We can expect the Customer details to have the respective location information giving the region details. To distribute the Customer record we can model a rule based on the region such that receivers will get those Customer details where the region of Customer matches with region served by recipient.
However if need to distribute the ServiceOrders, then options are
In this example, all the ServiceOrder corresponding to Customer received by a receiver will also be sent to the same receiver.
Static Filters on dependency:
The static filters are used to filter the records of following data object being distributed to receivers based on the respective dependency. The static filter is essentially a particular field modeled on the node defining the relation (and used in dependency) using which relevant following data object records are filtered. It is mandatory to specify the value of this field while modeling itself and hence the name Static Filter.
For example in the above scenario all the ServiceOrder [related to respective Customer] will be distributed to receiver irrespective of the order’s processing status. The orders that are served may not be distributed to and stored by the receiver. For this we can make use of ServiceOrder’s status field [assuming it is also in the same node as the one having Customer]. We can define Filter field as “Staus” with value “Incomplete”. With this additional filter modeling only those ServiceOrder which are having status as “Incomplete” will be distributed to receivers having the corresponding Customer records. The ServiceOrders that are in “complete” status will not get distributed. And the ServiceOrder records which were distributed to receiver when in “incomplete” status will be removed [by sending deletion] when their status changes to “complete”.
