Archiving and Deletion of IDocs

(Intermediate Document)

Part-1 :Archiving Object- IDOC

Archiving data from intermediate documents (Idoc)

Intermediate Documents Archiving

Archiving Object IDOC

Intermediate documents (IDOC) can be archived depending upon the status.

In transaction WE47 , the status values are defined that are required by an IDOC (received or sent) so that it can be
considered for archiving.

Archived IDOCs can be reloaded .into the database (though the general recommendation from SAP to not to reload
any archived data).

As of Basis Release 620, object links are always archived but are not deleted with the corresponding idoc which
means that we need to use repot RSRLDREL to delete the object linkages.

It is generally recommended / sufficient to archive IDOC data by selecting the creation date, current status, and/or
logical message (message types).

There are no direct residence time that can be set for an IDOC. However, we can use the start date and end date in
selection criteria as an indirect residence time for the archive runs.

In order to view the archived IDOC specific data, either transaction WE10 or report RSEXARCR can be used.

Archiving Object Dependencies

The Archiving Object does not have any direct dependencies to other archiving objects.

There is also not a reference check done to application documents generated from IDOCS.

However, indirect dependencies exist to the deletion reports for ALE change pointers (tables BDCP and BDCPS) and
object linkages(Tables IDOCREL and SRRELROLES). ALE Change pointers(Report-RBDCPCLR) and object linkages
(Report-RSRLDREL) must be deleted after the IDOCs are archived.

In releases earlier than Basis Release 620,object linkages are not archived. Object linkages can be deleted (ReportRSRLDREL) if either the IDoc or the application document is archived.

In Basis Release 620 ,object linkages can be archived but not deleted with IDocs. The Report RSRLDREL is required to
delete the object linkages.

For releases later than 620,the object linkages are always archived but not deleted with the corresponding IDocs.

The IDocs can be archived depending on the customized status in WE47 transaction . The status of an IDoc can be
analyzed with table STACUST for field ARCHFL.

Check Archiving Object Dependencies Network Graphic

Check Archiving Object Dependencies- IDOC

When an archiving object is displayed as below without

any other archiving objects it means from a technical
no dependencies on any other
archiving object

perspective there are

Perform Customizing

Customizing options are accessible via transaction SARA

Before any archiving can be performed, certain customizing must be performed. The Customizing Settings are
accessible via transaction SARA.

Cross-archiving object Customizing Technical settings

Archiving object-specific Customizing Technical settings

Basis Customizing Cross-Client File Names/Paths

Application-specific Customizing Transaction OMEY:

There is no Application-specific Customizing available for IDOC Archiving Object .However an indirect
residence
time is available by restricting the date/time in the selection variant(creation date/change of
last date).

Perform Archiving object-specific Customizing Technical settings

Archiving object-specific Customizing Technical settings

Check Customizing Settings Transaction SARA

Data Content Analysis for Outbound IDocs

There are few parameters we can perform the analysis:

Year: The annual distribution in the EDIDC table for the outbound IDocs (EDICDC-DIRECT=1) is measured.
Status: The number of entries per status are calculated in table EDIDC.The majority of IDocs are in archivable status.
Message type:
The number of entries is calculated for each message type in table EDIDC.(top 30 message types that are used in the
system are considered)
The number of entries is calculated for top five message types for inbound IDocs by status and annual distribution
(only the message types with highest number of entries).

Outbound IDocs

Obsolete IDocs can be removed from the database if we select the archiving indicator temporarily for a particular
status (transaction WE47),restrict the date selection for the Idoc ,archive it and remove the archiving indicator again
after archiving.
In case of outbound IDocs, the Idoc processing can be defined in two ways:
1. The receiver system sends a status message for the Idoc
2. The receiver system does not send a status message for the Idoc
In both the cases the Idoc passes through status 03.
If the receiver system sends a message the Idoc ends in a different status (status 12 if it was processed
successfully).In this case the Idoc should only be archived with status 12.Such IDocs are recommended to be
archived by message type.
If the receiver system does not send a message back , the Idoc remains in status 03 permanently and these IDocs also
have to be archived.
The report RBDMOIND sets the IDocs with current status 03(Passed to port OK) to status 12(Dispatch OK) if no
entry can be found for these IDocs in the queue of transactional remote function call . This function is available for
IDocs sent using a TRFC port or an R/2 port.

Data Content Analysis for Inbound IDocs

There are few parameters we can perform the analysis:

Year: The annual distribution in the EDIDC table for the inbound IDocs (EDICDC-DIRECT=2) is measured.
Status: The number of entries per status are calculated in table EDIDC.The majority of IDocs are in status 53 which is
an archivable status.
Message type:
The number of entries is calculated for each message type in table EDIDC.(top 30 message types that are used in the
system are considered)
The number of entries is calculated for top five message types for inbound IDocs by status and annual distribution
(only the message types with highest number of entries).
IDocs with an error status can only be archived when they have been migrated to an archive status(post processing) or
managed as obsolete IDocs.
Obsolete IDocs can be removed from the database if we select the archiving indicator temporarily for a particular status
(transaction WE47),restrict the date selection for the Idoc ,archive it and remove the archiving indicator again after
archiving.

Evaluation of all IDOCs

All the IDocs with the archivable status could be archived after 90 days.
For IDocs in error status we would recommend Sysco to review the set up for these and review the error correction
strategy. There should be no IDoc in error status older than 12 months.
Analysis shows that IDocs with an archivable status that are older than September should be archived i.e. 53%
(2025332/3822898).
SAP best practices recommend that we archive Intermediate documents after 3 months since they probably no longer
need to be accessed frequently after this time period.
If all the intermediate documents that can be archived are archived after a residence time of 90 days ,this would
lead to savings of 53% in this table or 8.33 GB .

Part-2:Transaction CodeWE11

Delete IDocs through WE11 transaction code (Report RSETESTD )

Deletion of records from tables

Condition: TEST RUN should not be activated and the records are deleted irrespective of any checkbox
activation.

Deletes the control records from table EDIDC based on the document number.

Atfirstwe trytodeletedata records fromtable EDID4 (IDoc Data Records from 4.0 onwards).
Ifthere are no records present in EDID4table, thendeletefromEDID2 table (IDoc Data Record from 3.0C onwards)
andtable EDIDD_OLD (IDoc Data Record).

Deletes the status records from table EDIDS table (Status Record (IDoc)) based on the document number.

If the records from all the tables are not deleted it gives message that EDI: Not all table entries of IDoc Number
could be deleted.

It deletes the entries which is relevant to relation.

Checkbox: GP_INTRF: Delete Interface Data

1. If the checkbox is activated:

Getsalltaskentriesfromtables TEDE2 (EDI process types (inbound)), TEDE5 (EDI Process codes for error
handling),andTEDE6 (IDOC process codes for inbound statuses)forlater processing.

Preparesalistwithallobjecttypesoccurringinthetasks in GT_OBJECT_TYPE.

2. If the checkbox is activated:

Searches for any related workflow work items. For each entry of Internal table GT_OBJECT_TYPE.

Gets the records into GT_WORKITEM based on the Object type and Object Key.

Deletes the work items if any exist if the TEST RUN is not activated.

Check box: GP_TRFC: Delete tRFC Entries

If the checkbox is activated:

If the direction of the idoc is OUTBOUND, fetch all data from EDIDS table (Status Record (IDoc)) based on the
conditions as below:

The IDOC number present in GD_EDIDC entries.

The STATUS of the IDOC is 03( data passed to port)

If the TRANSACTIONID (tid) is not blank and the TESTRUN is not activated,

Deletes tRFC Entries from Log File by calling standard report rsarfcdl by passing EDIDS TID (Transaction ID).It
deletes entries from tables such as arfcsdata, arfcsstate, arfcrstate.

If the TRANSACTIONID (tid) is blank,

For each record of GT_RELATION where Object Type (objtype_b) = 'TRANSID', Role in Which the Object Occurs
(roletype_b) = 'OUTTID',

if Test run is not activated then it deletes tRFC Entries from Log File by calling standard report rsarfcdl by passing
GD_RELATION OBJKEY_B (Object key).It deletes entries from tables such as arfcsdata, arfcsstate, arfcrstate.

Check box: GP_LOGDL: Delete Application Log Logs

If the checkbox is activated and not TEST RUN:

The matching entries are deleted from tables EDIQI (IDoc Inbound Queue Table) and EDIQO (IDoc: Outbound Queue
for qRFC) based on the IDOC number present in R_DOCNUM.
In addition to this we can analyze in detail as per below:

Fetch all the IDOC statuses into GT_IDOC_STATUS based on the IDOC number (GD_EDIDC-DOCNUM).

For each record of Internal table (GT_IDOC_STATUS) where Application Log is not blank, it moves the application
logs into another internal table GT_BAL_LOGN and append the IDOC numbers into table R_DOCNUM.

If the TEST RUN is not activated, deletes the entries from tables EDIQI (IDoc Inbound Queue Table) and EDIQO (IDoc:
Outbound Queue for qRFC) based on the IDOC number present in R_DOCNUM.