4.) As a rule only those messages get archived, for which persist until date is expired. Persist until date gets calculated by the current send/receive time of a message, plus the configurable “persist duration” value. For the central and decentral Adapter Engine(s) “persist duration” value can be configured as two properties of the J2EE Service
1.”SAP XI Adapter: XI” (value is in milliseconds): “xiadapter.outbound.persistDuration.default”
5.) Keep in mind that the default persist time for messages in the Adapter Framework is 30 days. This means that messages will be kept in the database for 30 days until the deletion job removes them. Changing the retention period in the AFW will only affect new messages that get processed by the adapter engine.
6.) As of XI 3.0, SP11, a user interface is available that allows you to manually set the retention time for messages to expired so that you can remove these messages from the database immediately or archive them before deleting them.
For this purpose, call the following URL in a browser
* * Enter a number of days. For the messages that were sent or received earlier than the number of days you have specified, the retention time is reset so that you can delete them immediately from the database. Bear in mind that you can only delete or archive messages whose retention time has expired and at the same time, that have, a final status (successful or failed). In addition, only messages without any configured archiving rules can be removed manually from the database. If an archiving rule exists for a message to be deleted, it is deleted automatically after the scheduled (or manually started) archiving job was completed. 7.) You can check the successful execution of the deletion and archiving jobs via the background processing monitor in the RWB. Enter the RWB, navigate to “Component Monitoring” and click “Display”. Choose the Adapter Engine of your Integration Server host and hit the button *”Background Processing” * *BPE Runtime – Deleting work items: * 1. When you execute receive steps, send steps, transformation steps, receiver determinations and blocks, work items are generated in integration processes in each case. The system may contain a very large number of work items as a result. The table *SWWWIHEAD* has a large number of entries in your system. 2. Messages that are processed by integration processes in work items can have synchronous and also asynchronous origins. Asynchronous messages are already persisted in the integration server and can also be archived from there. Synchronous messages are not persisted. 3. The question therefore arises as to whether you can delete the work items or whether you must also archive them. In most cases, it should suffice to archive the incoming message and the outgoing message for asynchronous messages, or to archive the outgoing message for synchronous messages in the sending system. If this is insufficient due to legal regulations, the generated work items can also be archived or deleted during message processing. 4. You can use the report *RSWWWIDE* or Transaction *SWWL* to delete all work items, including all of the attachments and dependent work items. Since the report RSWWWIDE can also delete work items that are not in a final status, it is recommended to make the selection according to the “*COMPLETED*” work item status, the creation date and work item type “*F*”. 5. If a large number of work items must be deleted, you may have to restrict the selection criteria by specifying smaller date ranges. Note that if you use the report incorrectly, at worst, all of the work items in the system are deleted. Always run the report in test mode first by not selecting the *”Delete immediately”* checkbox. Once you press F8, all work items having status as ‘COMPLETED’ will be deleted.