Archiving Issues

[Former Member]

I have archiving running smoothly on my XML messages through SARA, but for some reason the DESADV IDOCS are never archived/deleted.Any thoughts on this one?

[Former Member]

Issue is resolved. Thanks for the assistance.

[Former Member]

Hi David,

First thing is that you need to define retention for the interfaces whose message you want to archive. First you need to check whether any message are in 'to be archived' state or not through 'reorganisation report' . Go to se38 and run the report

RSXMB_SHOW_REORG_STATUS. Only if message are in ' to be flagged for archivig; will the message be archived otherwise not.

Second thing to consider is that only message which has come into XI Server for defining the retension, will be archived. Old message will not be. To archive old message you need to run a SAP standard report . SXMB_SET_ITFACTION_TO_ARCH .

===========================

Problem Description:

Old XI message cannot be archived if we have not set them for archiving before the first message was processed in integration engine. When XI messages are processed successfully in integration engine, they are flagged with status DEL (to be deleted). It means that these messages can be deleted from XI persistence layer but they cannot be archived. If we run report RSXMB_SHOW_REORG_STATUS, these messages will come under ‘Delete’ section not in ‘Archiving’. So ideally to do the archiving of XI messages, we should select the corresponding interface and set retention periods before processing any message from those interfaces.

Solution Approach:

To resolve above problem, SAP has provided a standard ABAP report ,namely, SXMB_SET_ITFACTION_TO_ARCH.This report changes the flag for delete or archive decision making at already processed message from DEL(deletion) to ARCH(archive).

Selection criteria are only the execution time and date of the message. There is a 'start date' input field and an 'end date' input field on the initial screen of the program. To assure that all messages within the given time period will be changed, don't change the 'start date' field at a repeated run after an abortion. If the Program aborts while processing, it stores the date and time of the last changed message to assure continuous following processing. This date and time appears in the 'start date' input field at the next program run. If running the program in a batch-job, create a new variant after abortion of the batch-job to get the 'start date' field automatic filled. To limit the amount of messages being changed in one run, we can give an end date. There is also a 'block size' input field with default value 1000. This means that the program commits every 1000 messages changed, so in the case of abortion there is no need to process all messages again. We can change the default value if needed (e.g. set it lower if the update repeatedly dumps or set it higher to achieve better performance).

=========================================

check out reorganisation report

Ranjeet Singh.

[Former Member]

Hey,

When you are configuring the archiving, you can select specific message interfaces,

(in transaction sxmb_adm).

You might just need to add those message interface to the configuration.

In addition, be aware that the archiving program, never archives messages with errors.