When processing events via an event processor or an OIEP, a change flag is displayed in XML output as Changed="true". A Change flag indicates the current truth, namely that data in the event being processed is different compared to the approved data currently in STEP.
Consider the transactions (Txn) shown in the table below, and the resulting output, to understand how change flags work. The data was generated using the following setup:
- The exported data is a single, internally maintained attribute (attrWarranty), that has a dimension dependency of Country, and is visible in both contexts being exported.
- The values are modified in two contexts: one that includes the Country dimension point = USA, and a second that includes the Country dimension point = Canada.
- The OIEP is configured for 'No event batching'. This means the OIEP will fully process a single event (run an export, create a file, and deliver the file) before processing the next event in the queue.
Note: In the table, the 'Event XML Processed' column output has been edited to show only the attribute values for product ID, object type (UserTypeID), parent ID, Name, and attrWarranty.
|
Txn |
Action |
Event XML Processed |
|---|---|---|
|
1 |
attrWarranty value originally set to Y in the USA and Canada dimension points is updated to N in both dimension points. While viewing both contexts using Context Mode in workbench, the object is approved for both contexts, two events are generated, and a revision is created. OIEP is invoked and processes Event 1 and Event 2. Export compares current attrWarranty approved values to those in the prior revision:
For Event 1, the value in the approved workspace for each context is different from the previous revision, so both dimension points are marked with Changed="true" in the XML. For Event 2, because two contexts were approved, a false positive flag is included as the second event, although the change had already been reported in the previous event. |
Event 1:
Event 2:
|
|
2 |
attrWarranty value is cleared in the USA and Canada dimension points. Object is NOT approved, NO revision is created. Since the object is not approved in either context, no event is generated.
|
|
|
3 |
attrWarranty value is set to Y for USA. Object is approved in the context with USA dimension only, an event is generated, and a revision is created. OIEP is invoked and processes Event 3.
The value for USA has been changed to Y and approved, so the change flag is true. The removal of the value for Canada has not yet been approved, so it continues to export as N. |
Event 3:
|
|
4 |
attrWarranty value is set to Y for Canada. Object is approved in the context with Canada dimension only, an event is generated, and a revision is created. OIEP is invoked and processes Event 4.
Compared to the previous revision, only the Canada value has changed, so the change flag is true. |
Event 4:
|
|
5 |
attrWarranty value is cleared from the USA and Canada dimension points. Object is approved in both contexts, two events are generated, and a revision is created. OIEP is invoked and processes Event 5 and Event 6.
The attrWarranty attribute is excluded from the XML output because neither of the contexts in the Approved workspace contains a value. |
Event 5:
Event 6:
|
Changing the OIEP to use batching would cause multiple events to be delivered in a single file. This would lessen the number of occurrences of a 'false positive' change flag, but would also require that the downstream system be able to process multiple objects per file. For more information, refer to the Event-Based OIEP Event Batching topic in the Data Exchange documentation here.