Show TOC

Process documentationArchiving Sequence Event Handler and Event Message Locate this document in the navigation structure

 

This process represents an archiving sequence. You can use this process to keep event message data for as long as possible in SAP Event Management.

You begin the archiving process by archiving the event handlers. In preprocessing, the system marks all inactive event handlers with a positive residence time check as archived. This means that logically these event handlers are archived. Thereafter, the system writes all marked event handlers into the archive. In a second step you archive the corresponding event messages. The system archives all event messages that have a positive residence time check and that are linked only to already archived event handlers.

Caution Caution

A long residence time for event handler and event message objects in application tables results in a higher requirement for database volume.

End of the caution.

Prerequisites

For more information, see Data Archiving for High Data Volumes.

Process

  1. You deactivate an event handler in one of the following ways:

    • Using a rule activity and a rule condition

      If no incoming event message fulfills the rule condition, SAP Event Management does not deactivate the related event handlers and they remain in the system indefinitely.

    • Scheduling the report /SAPTRX/ARCHIVE_EH_DEACTIVATE

      To avoid data overflow, you can use this report to deactivate event handlers manually.

  2. You set up the preprocessing, write, and delete program for archiving event handlers in the initial screen of the Archive Administration (transaction SARA).

    1. The preprocessing program for the event handler archiving object (SAPTRX_EH) checks for inactive event handlers with a positive residence time check. The program marks these event handlers as archived. You can no longer change existing data. For example, you cannot update application object data or process a related event message. This status ensures there is no data inconsistency between archived data and application data.

      Logically the event handler has been archived, but technically it resides in application tables.

    2. The write program for the event handler archiving object selects all logically archived event handlers and writes them into the archive.

    3. The delete program for the event handler archiving object deletes the archived event handlers from the application tables. It builds up the archive index table according to the archive information structures maintained for the archiving object.

  3. You set up the write and delete program for archiving event messages in the initial screen of the Archive Administration (transaction SARA).

    1. The write program for the event message archiving object (SAPTRX_EVM) checks if the residence time for the event message archiving object is positive. If it is positive and the event message is linked only to already archived event handlers, the write program writes all event messages into the archive. Event messages, which are linked to event handlers that have not yet been archived are not written into the archive and reside in application tables.

    2. The delete program for the event message archiving object deletes the archived event messages from the application tables and builds up the archive index table according to the archive information structures maintained for the archiving object.

Note Note

You can still process event messages that are related to an inactive event handler (see Overview of Possible Statuses of an Event Handler).

End of the note.

Result

The system has archived all event handlers that are set to inactive and have a positive residence time check. The system also has archived all event messages that have a positive residence time check and that are linked only to event handlers already archived.