Pls find the general guidelines on P360 usage of DQ rules
DQ is most useful, if the resulting DQ status of an item is used:
- for (manual) cleansing of data, for example in context of a workflow task that contains all items with a failed DQ status
- in context of an automatic process like merge or import (items with a failed DQ status won't be merged)
DQ is not recommended (and the proposal would be a customization):
- in general, if the DQ status is not used for follow up processes as described above
- calls to Product360 via Rest calls in a Java Transformation that are not performant and/or complex e.g.
- usage of many input ports to gather several data. This may slow down the execution time since these fields result in a too big sql statement to be performant (3900 characters in resulting sql statement part is the limit). An example is the concatenation of dozens of text attributes.
- solving duplication detection problems. An example would be involving item id duplication checks on products of an item which are retrieved via rest calls.
- in general rebuilding a large portion of the hierarchical and referential Product360 data model inside a DQ rule mapplet instead of simply using only the input data from the input ports of a rule mapplet.
In these cases one could think about avoiding usage of DQ checks and instead finding another way to reach the business goal - like a customization with extension points.
Never do this
- Never create, delete or modify objects in the context of the DQ execution itself.
A good example would be to define a workflow instead, execute DQ inside the workflow and after the execution create a workflow task containing failed items.
- Never use database connection access to our databases in DQ rules, neither for reading nor for writing. It is not supported by Product 360. If read access is needed, please use the Rest Service API (again, only read access in that case).
- Never change our OOB rule packages like 'Informatica_PIM_Content.xml' and do not re-export OOB rules from IDQ Developer. Otherwise we can not guarantee that they still work.
Thank you for your response however the whole point of creating standardizing rules is to output the result. I do not believe there is a way around this. The standardizing rule was not a modified version of the OOB rule rather a new rule. The issue is not the rule itself. It is the fact that multiple execuion of the workflow is being triggered base on the Entity Changed setup. In this case, we have no way around executing the workflow base on attribute changes but it is the source of the issue.
Also, this issue is not generating an error nor do we have DQ failures but we do see the impact because of the execution of multiple workflow.
Thank you Sathiesh for this.
What is trigger Grouper? I have never heard of it. Can you provide an example that might help me understand it.