Defining Interfaces for Archiving
You use this function to define which interfaces should be archived.
You differentiate between sending (outbound) and receiving (inbound) interfaces. Enter an interface in the relevant field. With the function Provide Interface for Archiving, the selectable interface is included in the list. Mark line and select Delete Interface from List to remove the relevant interface from the list.
The decision as to which interfaces you want to archive depends on the respective application, and is usually very customer-specific. For this reason, SAP does not provide any default values.
Select the interfaces you wish to archive either by using the input help and copying them into the list, or by entering the interfaces manually. Only interfaces that are known to your Integration Directory are offered in the F4 help of the central Integration Server. The interfaces offered in the F4 help in the sending or receiving application systems are known to the proxy framework of each system.
If you enter the interfaces manually, you can specify them generically (using *) and still be able to select interfaces from the input help.
It is also possible to copy generic entries such as FLIGHT* to the list. You must enter the namespace in this case. The interface name is only determined for this variant when the interfaces you want to archive have been determined at runtime.
To optimize system performance at runtime, it is recommended that you use generic entries instead of copying interfaces using input help, since this restricts the size of list. Only specify fully qualified interfaces if there are multiple interfaces with the same prefix, and you only want to archive one of them.
To select multiple interfaces simultaneously, choose Multiple Selection. The system displays a list in the form of a table with all interfaces known by your Integration Directory.
Defining Retention Periods
You can also specify the retention period for asynchronous XML messages before they are deleted or archived.
Synchronous XML messages are subject to different demands to synchronous messages, because the sender of a synchronous XML message receives an answer directly.
You can specify how long synchronous XML messages with and without errors are to be retained in the database. You can also specify (by entering 0 days) whether XML messages are deleted as soon as they have been processed successfully.
History entries can be deleted 7 days after the reorganization (deletion or archiving and deletion) of the relevant XML messages at the earliest.
The IDX5 references (connections from IDoc to XML messages) can be deleted with a delay (see Parameter RELATED_OBJECTS with subparameter IDX5_DELAYED). If the delayed deletion is activated you can specify how long the IDX5 references are to be saved. Deleting an IDX5 reference takes place as soon as when the related message is deleted. In this way the reference is kept in the database as long as the hold time of the message. If the delayed deletion is deactivated then the specified retention period for IDX5 references is not evaluated at runtime.
Comments
You should keep retention periods down to a minimum in most cases.
If in doubt, archive XML messages so that they can then be deleted from the database.
Lean database tables guarantee better system performance when processing XML messages in the Integration Engine.
Note also that the decision on which messages are able to be archived must be made before the processing of the first message since every processed message contains the to be archived or to be deleted flag.
Example
The retention period for XML messages to be deleted is three days. The retention period for XML messages to be archived was set at two days.
The sender interface FlightBooking.Create is the only interface entered in the list.
All XML messages that have the interface FlightBooking.Create as sender are written to the archive and deleted from the database two days after they have been processed successfully.
All other XML messages are deleted from the database three days after they have been successfully processed.
XML messages not in status processed successfully remain in the database.
Archiving jobs can be scheduled periodically using transaction SXMB_ADMIN (Administration -> Scheduling Archiving Jobs).
All changes made are automatically entered in a customizing request. The system displays a corresponding dialog box, in which you must specify a request to transport the changes.
The interface type (I or O) is not included in the customizing request. In other words, all selected interfaces are transported independently of the interface type.
In addition to this you can transport the current contents using the Transporting Entries function irrespective of any changes that have been made.
