Define Deletion Procedure for Persistence Layer
XML messages processed by the Integration Engine are saved in the multiple database tables when persisted.
XML messages are saved in a hierarchy. Each XML message has a master entry that contains the most important data, such as the message ID, QualityOfService or date of execution. This data is also used as search criteria in dynamic searches for XML messages. All additional table entries are attached to this master entry. For each message version, the header and body of the XML message and the message payload are saved in a separate table for each version, along with a version record.
The XML messages are not automatically deleted from the database tables. Deletion and archiving jobs have to be scheduled for this. The deletion and archiving jobs are scheduled in cycles using the administration interface.
Messages are deleted by default. If messages are to be archived, at least one interface must be defined as to be archived.
When archiving, all dependent table entries are archived in the first step. In the second step, you can delete all archived table entries.
If a message is to be deleted, a single step is used.
Below are two different procedures for deleting XML messages from the database tables:
- Simple Deletion Procedure
- For a simple deletion procedure, all XML messages are deleted from the database tables in records.
- This procedure is recommended when small volumes of XML messages are to be processed by the Integration Engine. However, large data volumes have an adverse effect on performance during the deletion process. For this reason, the switch procedure is recommended when processing large volumes of messages.
- Switch Procedure
- The switch procedure is based on the fact that an identical table copy exists for each persistence layer table. The copies are shipped by SAP.
- To begin with, the original tables are the active tables. All XML messages are saved in these tables.
- When the deletion job is started, the table entries are not physically deleted from the database tables as in the procedure above, instead the flag Deleted is set in the master entry. The monitors then no longer display this XML message.
- When a certain fill level is reached (standard 90%), the deletion job recognizes that a reorganization (or switch) is required. The table copies that were inactive before now become active tables. All new XML messages are written to the table copies. For all existing XML messages, the system checks whether the delete flag in the master entry is set or not. If it is not set, all corresponding table entries from the original tables are copied to the table copies. Once the all the table entries have been copied, the original tables in the database are deleted and then recreated again immediately.
- The fill level refers to the maximum possible number of entries in the table SXMSPMAST and can be defined using the configuration parameter DROP_MAX_TABLE_LOAD of category DELETION.
Choosing a Deletion Procedure
The simple deletion procedure is set as the default.
It is easy to activate the switch procedure. To do so, select the Switch Procedure Active checkbox. You can do this at any point. The deletion jobs react automatically.
You can only deactivate the switch procedure when the original tables are active and the counter for the number of deleted records in the original tables is at zero. If this is not the case at the time of configuration, this is noted by the system and the switch procedure is deactivated the next time that table entries are copied from the table copies to the original table.
Note
Deletion and archiving are client-dependent. Therefore, the archiving and deletion jobs must be scheduled in all necessary clients. The switch procedure is cross-client and must only be configured in one client.
