Skip to end of metadata
Go to start of metadata


The purpose of this page is to enable you to understand the process involved in managing persistence of Process Integration (PI) or Process Orchestration (PO) messages (we will just use the term PI from here on), the various Background Jobs that are involved, how different types of messages are persisted and the various parameters which impact on the removal of messages from the PI DB tables.


The persistence of messages in a PI system is a complex situation and requires inputs from all stakeholders involved. This can include, the PI Developer/functional teams, the Basis Admin team, Database Admins and very importantly, the Business stakeholders. How you manage the persistence will depend on several factors which are generally unique to your business organization. This requires careful planning which ideally is taken care of prior to the go-live of any system or any new additional interfaces. It is an important factor when sizing a PI system e.g. estimating the size and volume of PI messages as well as the number of versions of each message you plan to persist and the length of time you need to persist these for. 

Develop your strategy:

  • If you have requirements to configure additional persistence for PI messages e.g. using the Logging or Staging functionality, it is recommended to do this only for interfaces which have a specific business requirement
  • Do not configure Global Logging or Staging properties, which impact all interfaces, if there is no specific business requirement to do so
  • The following factors should be taken into account:
    • the specific interfaces which require additional persistence
    • the volume of messages to be processed by the interface
    • the estimated size of the messages
    • the number of versions of each message you will be persisting (depending on Logging or Staging configurations, multiple versions of each message can be persisted to the DB)
    • the length of time these need to be persisted for
    • whether you need to move the messages to an Archive store or whether the Delete Job is sufficient to meet your business requirements
    • if you do identify a need to move the messages to Archive, then identify which specific interfaces require this
    • generally, there is not a requirement to Archive every version, of every message of every interface so it is important, for overall system resource consumption, to minimize the amount of data which is sent to archive i.e. only archive the messages which have a specific business requirement to do so
    • note: if you are configuring a custom Archive Job, it is really important that you use the Rules option to specify messages from particular interfaces to send to the Archive. If you configure a custom Archive Job with no Rules, then every version, of every message of every interface is sent to the Archive store and the Delete Job

Understand the main PI related tables:

Read the below resources:

  1. SAP Blog Introduction of the tables that keep message related data in the database of PI/PO system

  2. SAP KBA 2592310 PO/AEX Messaging tables relevant for DB reorg jobs

Abnormal Growth in PI related DB tables: 

If you observe abnormal growth in PI related DB tables take the following actions:

  1. Verify if the Background Jobs are running as expected i.e. no errors are reported. Go to the NWA → Background Job Monitor
  2. Check if additional Global Logging and/or Staging parameters are configured - if so, revert to default (if possible).
  3. Check if Interface (ICO) level Logging/Staging parameters are configured.
  4. Check the number of entries in PI related DB tables

Parameter Glossary: 

XPI Service: XI Adapter 


SAP Note 1760915 FAQ: Staging and Logging in PI 7.3 and higher

SAP KBA 2442344 How to enable logging for synchronous messages

SAP Help Background Job Types
SAP Help Data Storage Security for the Advanced Adapter Engine

SAP Community:
Blog Message Staging and Logging Options in Advanced Adapter Engine of PI/PO 7.3x/7.4

  • No labels