Problem: For outbound integrations where not only the leaf level is published, sometimes data from children is used on parents, for instance, via calculated attributes. When the children change, the parents are not automatically republished.
For comparison, downward inheritance is typically handled by publishing all object descendants.
Solution:
In an event-based OIEP:
- If children get exported along with the parent, whenever an event is generated for a child with appropriate parent, catch it, discard it, and generate a derived event for the parent instead.
- If children are not published with parents, do not discard the children events.
Important: The following scripts are only an example and should not be used as-is without thorough testing.
The first option is described below, using the following object types:
Use the following triggering object types setup:
No Filter or Generator is used for the Sales Item Family Object Type as all Events should pass for this type.
Use the following logic for the Sales Items:
Event Filter - If Sales Items can be children of both Sales Item Family and other types, a filter that checks the parent object type is required. The Script below discards events for Sales Items that are children of Sales Item Family objects:
If Sales Items can only exist below Sales Item Family objects, instead an 'Always False' condition like the one used in OIEP Example Publishing of Leaf Products with Inherited Data (here) can be used instead.
Event Generator - This business action script is also fairly straight forward, notice that it is assumed that a 'Derived Event' with ID 'salesItemFamilyRepublish' has already been defined in STEP.
If Sales Items can only exist below Sales Item Family objects, the 'if' statement can be left out.
Output Template - Using the configuration described above, you will need one or more output templates that cover both Sales item and Sales Item Family, and the different types of possible events must be defined. Below, a single output template is used.
