Preventing circular dependency references in a hierarchical tree
|Description||Performing validation to optimize hierarchical tree set up|
|Version as of||8.5|
Validation has to be performed to avoid a direct or indirect circular dependency reference scenario while manually setting up a tree hierarchy.
Consider a hierarchical structure.
For Example, Order Fulfilment where we have the root node as 'Product' with 'Service' and 'Resource' as child nodes.
The products can have services and resources as child nodes and services can have resources as child nodes. Order Fulfillment processing requires dependencies defined between the siblings to ensure the fulfillment process is completed appropriately. A user can create new specifications (Product, services or resources), edit and also define dependencies. While creating the top-level specification, they can add child nodes to any level of depth.
Use case examples
Consider an example where Product A, Product B and Product C are siblings.
Possible circular dependency reference scenarios in this configuration could be listed as below:
1. Product A is dependent on Product B
Product B is dependent on Product C
Product C shouldn’t be dependent on Product A at any level of the product hierarchy.
2. Product A Shouldn’t be dependent on itself
3. Product A is dependent on Product B
Product B shouldn’t be dependent on Product A
Process/Steps to achieve objective
- A Page list can be created which contains details about the list of child specifications for a Product along with the dependencies between them.
- Once all the dependencies are added manually by the user, in the postprocessing of the flow action, a data transform can be called.
- In the data transform, loop over the current page list which holds the child specification details, set the current specification to a parameter (example “Top”) and its dependency to another parameter (example “Dependency to look for”)
- Call another Data transform where the actual circular dependency check happens for each of the specification.
- Loop over the dependency list of the current specification
- Now set the index of the dependency in the page list using the function IndexInPageList and check if the dependency of that specification is equal to the parameter named Top.
- If yes, configure the error message and exit the data transform.
- Else set the parameter "Dependency to look for" to the dependency present in the current specification (dependency of the result which comes after executing IndexInPageList function) and call the Circular Dependency check Data transform until all the dependencies of the specification mentioned in the Top parameter are completed.
Note: To prevent the user from selecting the same specification as its dependency (eg: Product A having Product A as its dependency), we can configure a step in the data transform while populating the autocomplete to eliminate the specification from the list by adding a when condition.
Example scenario and pseudo code to validate it
Product A is dependent on Product B
Product B is dependent on Product C
Product C is dependent on Product A
Product D is dependent on Product E
Product E has no dependency
Now we have a pagelist which contains all the products A, B, C, D, E.
Param.Top = Product A
Param.Dependency to look for = Product B
Index of dependency = 2
Product C == Product A (False)
Param.Dependency to look for = Product C
Index of dependency = 1
Product A == Product A (True)
Set message and exit DT.
Detailed description of the above use case:
Product A→loops over dependencies of Product A
Sets the index of product B (which is 2)
Checks if Product B’s dependency is Product A→No
Now sets the Dependency to look for parameter to Product C which is the dependency of Product B
Loops over the dependency of Product C
Check if dependency of Product C is equal to Product A (True)
Set message, exit activity
Note: Similar logic can be applied for the child case dependencies as well. The above example is for the dependencies between siblings.