Open topic with navigation

Events

Within STEP, an event indicates that data has been changed. Events can be monitored and used to kick-off additional processing via a business rule or an event processor, or to generate an export via an OIEP. Events are generated based on two factors: database transactions and revisability.

Database Transactions

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. The available methods for changing STEP data are:

• STEP Workbench generates a transaction each time a field is changed, since no Save button is available or required.
• Web UI generates a transaction when the Save button is clicked, meaning several changes may be included in a single transaction.
• Import generates a transaction on the success of the import, and may include several changes in a single transaction.

Revisability

Revisability determines when it is possible to include different values per workspace and affects the generation of events as follows:

• Global revisable objects do not require approval (values are the same for all workspaces) and an event is generated when the database transaction is written. Workflows, business rules, integration endpoints, event processors, and all publication structures are always globally revised. Entities can be set to be globally revisable.
• Workspace revisable objects do require approval (values can differ per workspace) and an event is generated when the object is approved. Products, classifications, and assets are always workspace revised. Entities can be set to be workspace revisable.

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

Note: It is important to note that the event system cannot be used as a transactional request / response integration with other applications. Events are not reflected by transaction in the exported data (which would, in many cases, cause an overflow of data). For more information, see Change Flags for Events below.

Generating Events

For many system actions an event is automatically generated based on the method used to change STEP data and the Revisability parameter on the object type. This information impacts when an OIEP or an Event Processor is triggered, and the rules are outlined below.

For a global revisable object, the transaction and event are created, based on the change method, as follows:

For a workspace revisable object, the transaction and event are created, based on the change method, as follows:

Considering the event generation rules, for example, changing data in Web UI on an entity object that is workspace revisable would not trigger an OIEP export until that object is approved. However, 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. Note that both scenarios assume that an event-based OIEP exists that is set up listen for appropriate events on the applicable object types. For more information, see the Core Events section here.

Additionally, events can be generated in a manual way based on some system action or setup. For example, business rules, a post-processor on an OIEP, a derived event, and some event handlers can cause events to be generated. For more information, see the Derived Events section here.

For an example of manually generating events on demand, see the Generating Match Codes and Running a Matching Algorithm section of the Matching and Linking documentation here.

2017, Stibo Systems