Data Aging for IDocs

The data aging object BC_IDOC supports data aging (see also Data Aging).

Use

IDocs are stored on the database in the tables EDIDC (control records), EDID4 (data records), and EDIDS (status records). To relieve the working memory, IDocs can be moved from the HOT area to the COLD area depending on their status and time. This procedure is called Data Aging for IDocs. The moved IDocs are still visible in the system, they can be deleted or archived but can no longer be changed or processed. The aging object BC_IDOC contains the tables EDID4 (data records) and EDIDS (status records).

Prerequisites

Your database must support data aging. Note the following in particular:

Activities

  1. Determining the Status

    IDocs that are in a currently archivable status can be moved to the COLD area. You should check your IDocs for this (Displaying or Changing the Archivable Status). IDocs that can still be processed are excluded from data aging. This affects the following IDoc status values:
    • 64 IDoc is ready to be transferred to the application
    • 66 IDoc waiting for predecessor IDoc (serialization)
    • 51 Application documentation not posted
    • 75 IDoc is in the inbound queue
    • 69 IDoc was edited
  2. Maintaining the Residence Times

    Only IDocs that were not changed or edited in the last 14 days are taken into consideration for data aging when using standard settings. If, however, you want to use longer or shorter times, for example, for specific message types or partners, use transaction Residence Times for Message Types or Partners (WEIDOCDAAG).

    You can store different times for the following key fields:

    • Message type
    • IDoc type
    • Enhancement
    • Sender or receiver report
    • Partner type
    • Partner number
    • Direction (inbound or outbound)
A more specific entry overwrites a less specific entry.

Example

Table Field Example 1 Example 2
Message type ORDERS ORDERS
IDoc type ORDERS04
Enhancement
Partner port MYREMOTE
Partner type
Partner number
Direction
Residence time 3 12
The example above shows the following case:

IDocs with the message type ORDERS should be taken into consideration for a data aging run after just 3 days (Example 1). In contrast to this rule, IDocs of partner port MYREMOTE (sent as ORDERS04) are left in the HOT area for 12 days (Example 2).