Transactional Event Publishing

Publishing from the LN application is transactional. This means the publishing is done within a database transaction. The actual publishing is postponed until the end of the transaction. If the transaction is committed, the publishing is done. If the transaction is aborted, the publishing is not done.

When PublishEvent or ShowAndPublish(Standard)Event is invoked from the application, first the subscription is checked. If a subscription exists for the specified business object and

eventAction, then the request is stored in a queue. The enqueuing will only be effective if the transaction is committed by the application. In case of an abort, nothing will be published.

A publisher process is not only running in case of a SubscribeEvent on standard event actions, but for all event actions (also when the standard publishing process is suppressed in an on execute hook for SubscribeEvent). The publisher does not only check for standard events as logged in the audit trail, but also for application events from the queue. The events from both sources are sequenced correctly. Technically, the audit trail facility is reused for the application events, so the time each application event gets a commit time and a transaction ID.

This approach has a number of advantages:

  1. When publishing inside a transaction, the event will not be published if the application’s database transaction is aborted.
  2. All events (from PublishEvent, from ShowAndPublish(Standard)Events and from the standard audit trail entries) are sequenced correctly.
  3. The performance impact for the application is limited, because the aggregation and publishing of events is done ‘offline’.
Note: This means that PublishEvent PublishEvent, ShowAndPublishEvent and ShowAndPublishStandardEvent must always be invoked from the application inside a database transaction. So a retry point must be set before publishing and a commit or abort must be done afterwards. This must be the same application transaction that actually initiates the event. For example, if an Order row is changed and an event is published because of that, these must be in the same transaction scope. This way, an event is only published if the corresponding database change succeeds.