Open topic with navigation

Core Events

Within STEP, an event indicates data has been changed. An event triggered automatically is known as a 'core event'. Core events are always tied to an object in STEP, meaning an event can include data about its creation time, the object for which the event was generated, and the event type. Except for the Republish event, core events are all generated automatically by STEP when the actions defined below are performed.

This topic addresses:

• Core Events and Event Types
• Core Event Generation
• Using Core Events
• Change Flags for Events

Prerequisites

It may be helpful to review the Workspaces (here) and Managing Revisions in STEP (here) sections of the System Setup / Super User Guide documentation prior to this topic.

For more information on revisability of entities, see the Revisability on Entity Object Type section of the System Setup / Super User Guide documentation here.

Core Events and Event Types

The table below lists core events, the associated event type, and the action performed to generate the core event.

Important: The timing or action performed to generate a core event is especially important when dealing with an OIEP or Event Processor, because it impacts when an OIEP or an Event Processor is triggered. For more information related to OIEPs see the OIEP - Event-Based - Event Triggering Definitions Tab section of the Outbound Integration Endpoints documentation here. For more information related to Event Processors, see the Event Triggering Definitions Tab section of the Event Processors documentation here.

Core Event Generation

Core events are automatically generated based on both the database transaction method and the revisability used. Details for each are below.

Database Transaction Methods

Each time an update is made in STEP, a transaction is used to write the changed data to the STEP database. The method used to make the change is a factor in determining if each transaction generates its own event, or if multiple transactions are collected to create a single event.

Available database transaction methods:

• STEP Workbench
• Generates a transaction each time a field is changed.
• Does not provide a Save button.
• Web UI
• Generates a transaction when the Save button is clicked.
• May include several changes in a single transaction.
• Import
• Generates a transaction on the success of the import.
• May include several changes in a single transaction.

Revisability

Revisability determines when it is possible to include different values per workspace. Revisability can be either global or workspace dependent. Below are details of how revisability works with each of the database transaction methods to affect the generation of events.

• Global Revisable Objects
• Do not require approval (values are the same for all workspaces), thus an event is generated when the database transaction is written.
• Are system setup objects (workflows, business rules, integration endpoints, event processors, and all publication structures), externally maintained attributes, and entities with the revisability parameter set as global revisable.
• Create a transaction and event based on the change method, as follows:

For example, assuming an event-based OIEP is set up to listen for appropriate events on the applicable object types, changing data in Web UI on a similar entity object that is global revisable would trigger the OIEP as soon as the change was saved. Whereas on Workbench, if a value of an externally maintained attribute is changed, the value gets reflected automatically in all the workspaces.

• Workspace Revisable Objects
• Do require approval (values can differ per workspace), thus an event is generated when the object is approved.
• Are products, classifications, assets, and entities set as workspace revisable.
• Create a transaction and event based on the change method, as follows:

For example, assuming an event-based OIEP is set up to listen for appropriate events on the applicable object types, changing data in Web UI or Workbench on an entity object that is workspace revisable would not trigger an OIEP export until that object is approved.

Using Core Events

Core events can be monitored and used to kick-off additional processing (e.g., a derived event, business rules, event processors, a post-processor on an OIEP, and some event handlers can cause events to be generated). Additionally, events can be manually generated based on some system action or setup.

To learn more about:

• Derived events, see the Derived Events documentation here.
• Business rules, see the Business Rules documentation here.
• Event processors, see the Event Processors documentation here.
• How core events can be used to control the output and format of an OIEP (Outbound Integration Endpoint), see the OIEP - Event-Based - Output Templates Flipper topic in the Outbound Integration Endpoints section of the Data Exchange documentation here.
• Manually generating events on demand, see the Generating Match Codes and Running a Matching Algorithm section of the Matching, Linking, and Merging documentation here.

Change Flags for Events

Although actions can trigger events as they occur, a record of the individual actions taken are not stored in the database—only the end result. This means that it is not possible to review a list of actions that comprised an event, and also that STEP does not track the series of individual actions taken by an event, outside of any revision created. For information on revisions, see Managing Revisions in STEP here.

When exporting event data, to determine if a change has happened, STEP compares the current values with the values in the revision prior to the event (based on the timestamp). The XML output then reports the current truth along with a 'change flag' or 'changed marker, which is output as Changed="true".

For externally maintained data, since revisions are not created, a change to one externally maintained object results in change flags being included on all externally maintained objects, also referred to as a 'false positive'. This is because STEP cannot determine exactly which externally maintained data on the object has changed. False positives are likely, especially when a large number of externally maintained attributes or references exist on an object. However, you can be certain that when a change flag is present, data has changed. In the event that an externally maintained value of an attribute or reference is deleted, no change flag is output. For more information on externally maintained data, see the 'Important considerations for revisions' heading within the Managing Revisions in STEP here.

Limitations and Exceptions

In addition to the caveats on externally maintained data mentioned above, the following limitations exist for change flags:

• No change flags are produced when republishing events. For more information, see Event-Based OIEP Forward, Rewind, Purge, and Republish here.
• No change flags are produced when using the context splitter post processor on a OIEP Output Template. For more information, see OIEP - Event-Based - Output Templates Flipper here.
• No change flags are produced for hierarchy inherited values. Change flags are only applied on the node that 'owns' the data. For more information, see Inherited Attributes here.
• If there are multiple edits on an attribute within a scheduled Event publish time, it is not possible to record all the edits and publish the events at a scheduled time as STEP gives the latest change available during the publish of the event.
• No change flags are produced for deleted values.
• Use caution when relying on change flags in combination with dimension inheritance or suppression of references. The complexity of change flags is much greater in these scenarios.
• Derived events are always compared between the first approval of a node and the last approval of the node. This results in an excessive number of change flags.
• When using the Expand LOV Value Changes event processor, if change flags are used in the format for the endpoint receiving the event, the relevant objects will have change flags on all attributes set to true (instead of only the changed attribute), because the endpoint interprets the event generated by the processor as a change to the object rather than to the individual attribute value. For more information, see Expand LOV Value Changes Processing Plugin Parameters and Triggers here.
• Data Container tags are marked Changed=true on the data container object itself, and not on that of the individual attribute value tags inside the data container.

Note: To eliminate any concern about when change flags are included (or are not included), you should consider each export as a full replacement.

For an example of a number of transactions and how they are represented by the change flag, see the Change Flag Example documentation here.

2018, Stibo Systems