Skip to Content
Author's profile photo Kranti Khilari

Distribution Modeling in Data Orchestration Engine – 6 (Node Level Filter Rules)

This is a continuation in series started by fellow members of SCN with “Distribution Modeling in Data Orchestration Engine”.  Following are the links to the blogs written around this topic previously:

Distribution Modeling in Data Orchestration Engine – 1, Distribution Modeling in Data Orchestration Engine – 2, Distribution Modeling in Data Orchestration Engine – 3, Distribution Modeling in Data Orchestration Engine – 4, Distribution Modeling in Data Orchestration Engine – 5 

 

In this blog we will understand the concept of Node Level Filter Rules and in which scenarios would this concept be most applicable with respect to defining the distribution of business data to the end users.

 

Let us understand – What are Node Level Filter Rules and how are they different from Normal Distribution Rules?

In case of Normal Distribution Rules – bulk rules or rules defined based on criteria fields, the rule evaluation is done to identify all the instances of the Data Object that satisfy the criteria and send the “whole” instance to the subscribed devices.  By “whole” I mean that all the data across all the nodes of the Data Object instance are sent.

However, there could be scenarios where the end-user of the device is really interested in receiving only some part of the data to work upon in his day-to-day work and hence it is not necessary to clog his/her device with too much information which will not be used. 

For example: a service technician is responsible for handling service orders from the “South Region” and among these orders he is responsible only for Item type “Washing Machine” of Make “Whirlpool”.  In such scenarios where you wish to further filter the data to be sent to the device users, Node Level Filter Rules can be used.

 

Node Level Filter Rules provide a mechanism by which the data to be sent to the subscribed devices can be filtered at the node level of a Data Object. 

 

Let’s take an example of Order Data Object with following hierarchy:

Order_Header: Order Code, Customer Code, Customer Name, Region

            |

            |___ Order_Items: Order Code, Item Code, ItemType_Make

 

Also, lets take some example data:

Order_Header

Order Code

Customer Code

Customer Name

Region

Ord001

Cust001

ABC

SOUTH

Ord002

Cust002

XYZ

NORTH

Ord003

Cust003

PQR

SOUTH

 

Order_Items

Order Code

Item Code

Item Name

ItemType_Make

Ord001

Item001

Television

TV_Sony

Ord001

Item002

Music System

MS_Kenwood

Ord002

Item002

Music System

MS_Sony

Ord002

Item003

Washing Machine

WM_Whirlpool

Ord003

Item003

Washing Machine

WM_Whirlpool

Ord003

Item001

Television

TV_Samsung

 

Now, let’s have following service technicians (devices) with device attributes:

Tech1:

Region = North; Expertise = TV_Sony, MS_Sony

 

Tech2:

Region = South; Expertise = WM_IFB, WM_Whirlpool

 

Our requirement is:

  • Tech1 only gets orders from North Region for Sony Televisions and Music Systems.
  • Tech2 gets orders from South Region for Whirlpool and IFB Washing machines

 

If we model a Distribution Rule with following criteria:

Order_Header.Region = Mobile.Region

Order_Items.ItemType_Make = Mobile.Expertise

 

With the above data:

  • Tech1 will get all records of Ord002, that is, order for Sony Television as well as Whirlpool Washing Machine (Tech1 is not an expert in Washing Machine repairs)
  • Tech2 will get all records of Ord003, that is, order for Whirlpool Washing Machine as well as Samsung Television (Tech2 is not an expert in Television repairs)

So, both the technicians are getting “non-relevant” information which they do not require.

 

Following is the solution to deal with the above situation:

Have a Distribution Rule that filters Orders based on Region, that is;

Order_Header.Region= Mobile.Region

Additionally, have a Node Level Filter Rule created at the Order_Items level with criteria: Order_Items.ItemType_Make = Mobile.Expertise

First, the Distribution Rule will filter the Order Headers based on Region for the subscribed technicians (devices) and then for these Order Headers, the Node Level Filter Rule will further filter the Order Items based on the expertise of the technicians.

image

 

To create a NLF Rule on a Data Object:

  • Double-click the Distribution Model (DM) created on that Data Object.
  • Select the tab “Used Data Objects”. This will display all the Data Objects participating in the selected DM, which means if any Dependencies were created in the DM, the list will also display the following Data Objects.
  • Select a Data Object and click on the “Add Node Level Filter Rule” button in the toolbar
  • This leads to the usual Rule creation wizard for defining the criteria for the Rule. The only difference is that it is possible to define the criteria with fields of only one node of a Data Object for one NLF Rule.

image

 

Now, also let’s see the runtime behavior when we have one Distribution Rule (Normal Rule) and one Node Level Filter Rule (NLF Rule) as described in the Order example above with their Active / Inactive states in the Distribution Rule Administration:

 

Normal Rule

NLF Rule

Output

Inactive

Inactive

No Order Data will be sent to any technician

Active

Inactive

Order_Header Data will be sent to the Technicians based on the Region but none of the Order_Items will be sent

Active

Active

Order_Header Data will be sent based on the Region and Order_Items will be further filtered based on the Expertise

Inactive

Active

No Order Data will be sent to any technician

 

To summarize:

A Node Level Filter Rule cannot evaluate data distribution on its own.  It filters the data at the node level only of those Data Object instances that have been identified through Normal Distribution Rule evaluation. 

If an NLF Rule criterion on a particular node of a Data Object is not satisfied at runtime, then all the data corresponding to that node and its subsequent child nodes will not be sent to the subscribed devices. 

Also, if there is a dependency defined with another data object as following object such that the dependency link is from the same node where NLF rule is defined, then the corresponding dependant data will also be sent only if the NLF rule criteria at the leading object are satisfied.

Assigned Tags

      Be the first to leave a comment
      You must be Logged on to comment or reply to a post.