Performance-Critical Processes

Example: Processing sales data using POS interface - inbound

When processing sales data using POS interface – inbound (Point of Sale) you may need to include IDoc processing for store goods receipts and store physical inventory.

An enterprise with 1000 stores uses the POS interface to send inventory data for approximately 5 000 – 10 000 articles in IDocs from ten stores on approximately 100 days per year. Each IDoc can contain a maximum of 1000 items.

Deletion of object links (tables IDOCREL and SRRELROLES):

The deletion report RSRLDREL performs many cross-checks to avoid the deletion of link data that still may be required. The runtime of this report will increase with increasing size of tables SRRELROLES and

IDOCREL. For this reason it is vital to schedule this report right from go-live of a system on a regular basis to avoid running into runtime problems.

4.1.12.2 Avoidance

Cannot be used.

4.1.12.3 Summarization

Cannot be used.

4.1.12.4 Deletion

You can only delete IDocs in the IDoc interface in an emergency and after close consultation with SAP. The data is therefore not archived. You must therefore run archiving for IDocs on a regular basis.

If you want to delete obsolete IDocs from the database, you can temporarily set the archiving indicator (transaction WE47) for specific IDocs status. The temporary setting can then be removed again at a later date. For more information, see SAP Note 40088 (SAP R/3 Release 3.0A-4.6C).

4.1.12.5 Archiving

You can restrict the growth of IDoc tables by ensuring the archivability of the IDoc status using transaction WE47. (See also SAP Note 179046 release-independent). IDoc data is archived using archiving object IDOC.

Note: As an approximate guide for archiving, IDocs can be archived one week after processing has been

completed (for example, if they have the status “53” meaning “Application document posted” at POS interface - inbound). Follow-on documents are then created and the IDoc is no longer required. Entries that still have to be processed, such as IDocs that contain errors, can only be archived if they have been corrected.

Alternatively, you can check if the IDoc is still required, and then delete it. It is also possible to archive IDocs separately according to message type. However, this type of differentiation is generally not necessary. You can accelerate the archiving process for IDocs by deactivating logging using program RSEXARCA (intermediate status “38” or “73”, meaning “IDoc archived” is not used) - for more information, see SAP Note 133014 (SAP R/3 Release 4.0A - 4.6C). This can be used, for example, if you want to archive a large number or IDocs. A status update is generated for every IDoc that is archived, which could lower system

performance.

Recommendation:

Archive completed IDocs, such as outgoing IDocs with status 12 (“Dispatch OK”) or incoming IDocs with status 53 (“Application document posted”), after a relatively short residence time.

Also check whether there are still old IDocs (older than 6 months) with a status that keeps them from being archived. In order for you to be able to archive these IDocs, you must release them for archiving. You can do this in transaction WE47 in the detail view for an IDoc (radio button “Poss.”).

You can check the status of existing IDocs in the head table EDIDC. To analyze the IDocs, use transaction BALE.

For the processing of outgoing IDocs, you can determine whether the receiving system sends a status message or not, when it receives the IDoc. An outgoing IDoc has the status 03 (“Data passed to port OK”). As soon as the receiving system sends a status message, the status of the IDoc changes. If the IDoc has been processed successfully, this status is 12. If the receiving system does not send a status message, the IDoc continues to have status 03. Remember to also archive these IDocs.

Recommendation: Archiving should be run in parallel as often as possible. The deletion

procedure must be included if you want to generate separate jobs for archiving and deleting the archived IDocs.

Archiving and deleting application object links:

Links still exist between application objects and IDocs (or between the application log and the IDoc) after the IDocs have been archived. These links must be deleted from the system. A distinction is made between:

Type C work items

These work items are normally archived after the IDoc itself is archived (for more information, see SWW_CONTOB).

When the IDocs are archived, the status of the relevant type C work items is set to READY or COMPLETED. You may experience poor system performance if you try to process an extremely high number of IDocs at the same time. To avoid poor performance, you can delete the type C work items that have READY status by running report RSWWCIDE. By deleting these work items, you can greatly improve the performance of the IDoc archiving session. For performance reasons, the status update can, if required, be suppressed – this enables the IDoc to be archived considerably faster – see also SAP Note 215982 (SAP_APPL 40B – 45B, SAP_BASIS 46B – 731).

Application links stored in table IDOCREL.

Report RSRLDREL is used to delete these links and also partly deletes the IDOCREL related records from table SRRELROLES. (e.g. records of role type: OUTIDOC, INIDOC, OUTBELEG, …) This report is available as of SAP R/3 Release 4.6B. For more information, see SAP Note 149367 (release-

independent). If report RSRLDREL is scheduled too late, i.e. on already very big IDOCREL and SRRELROLES tables the performance may no longer be sufficient. For this reason another report RSRLDREL2 (see SAP Note 853035 SAP_BASIS 46C – 700) is available to perform a first clean-up of those tables.

Starting release SAP R/3 Enterprise the IDOC archiving object will archive the application links, i.e. write the information of tables IDOCREL and SRRELROLES into the archive file, but will not delete the corresponding records from the DB. So still report RSRLDREL is required and should be scheduled AFTER the IDOC archiving so that the data is still available on the DB so that the IDOC archive job can still access them.