Repository Framework Events 

Use

To enable applications to keep track of changes to resources, the repository framework supports events. The framework raises an event whenever a significant change to a resource takes place, for example, when a resource is renamed or moved. Interested applications can register to receive the events and, if required, respond with suitable processing steps.

The events that are predefined in the repository framework are not raised for all resources because they can be disabled in the configuration. Changes in backend systems that are not routed through the framework or are not reported by the repository also do not trigger events.

Features

Events are of different types. The type indicates the operation causing the event. The table below gives an overview of the most important event types.

Events are sent as pre-events before an operation starts and as post-events, after an operation has completed. If the operation fails, no post-event is sent. To identify events that belong together, for example, pairs of pre- and post-events, events can provide a correlation id.

An event that is sent defines the operation that caused the event and contains the resource for which the operation was executed. A client that uses the resource passed in the event must be aware that some operations invalidate the resource, for example, a delete operation destroys the resource. If a resource is invalid, only its RID can be retrieved.

Receiving Events

A client application that wants to receive events must register itself as an event receiver with the event broker of the responsible repository. During registration, the client can specify whether it wants to receive the event in synchronous or asynchronous mode.

Synchronous Events

In synchronous mode, the event receiver is called while the operation is being performed on the resource. The event indicating the operation is sent as a pre- and a post-event: The pre-event is sent before the operation begins and the post-event after the operation has been completed.
Clients that receive synchronous events must be aware of the impact on performance. The repository blocks all other operations on the resource, until the operation and the processing related to an event has been completed. The figure illustrates the sequence of calls that take place:

Asynchronous Events

In asynchronous mode, the event receiver is called from a separate thread that buffers events in an event queue. The event receiver can perform lengthy operations when receiving an event because the repository is able to finish processing the operation without waiting for the event receiver to return from the call.
A drawback is that the event receiver cannot rely on receiving pre-events on time. They might be received after the operation has been performed.

 

Event Types

The table shows event types that are implemented for resources in the repository framework.

 

Operation Category	Event	Operation
Retrieval	Get	Retrieval of  the content of a resource
	Get children	Retrieval of the list of children of a collection
Content and property operations	Set	Change to the content of a resource
	Property get	Retrieval of a resource property
	Property set	Creation or update of a resource property
	Property delete	Deletion of a resource property
Namespace operations	Create child	Creation of a new child resource within a collection (which is not a link or a collection).
	Create collection	Creation of a new sub collection inside a collection
	Create link	Creation of a new link inside a collection
	Copy	Copy operation
	Move	Move operation
	Rename	Rename operation
Locking Operations	Lock	Application of a lock
	Unlock	Removal of a lock
Version control Operations	Enable versioning	Activation of version control for a collection
	Checkout	Check-out of resource
	Undo checkout	Reverting the checkout of a resource