Professional Documents
Culture Documents
RN 144
RN 144
1 Symptom
The database of your PI or connected Proxy system is growing and you would like to
know how to remove messages from the database. You have scheduled the required
deletion and archiving jobs, but some or all messages are neither deleted nor archived
and the corresponding database tables increase.
1.1.3 Solution
Introduction:
Per default only asynchronous messages (EO and EOIO) will be persisted on the ABAP
and Java side. Synchronous messages (Best Effort) will only be persisted if an error
occurs during processing or if the parameter LOGGING_SYNC (ABAP only) is set.
Setting LOGGING_SYNC is not recommended to reduce processing overhead. Note:
Also on applications systems connected to PI via ABAP proxies the messages will get
persisted and archiving/deletion has to be configured. Performance data on the other
hand are persisted for both, synchronous and asynchronous, messages
(tables SXMSPFRAWH and SXMSPFRAWD).
In general, there are for all data types in PI two ways to remove the relevant objects from
the database - Deletion or Archiving. The exceptions are history entries and
performance data which can only be deleted. Also synchronous PI messages can only
be deleted and not archived.
Per default no deletion & archiving is carried out in the Integration Engine and BPE.
Therefore manual interaction is necessary by the administrator of the PI system to setup
a suitable deletion/archiving strategy. On the AFW messages will per default be deleted
after a default time of 1 day (for 7.0x and lower the default is 30 days). Reorganization of
PI internal processing data is vital for the performance of an PI system. Since many of
the relevant flags are persisted on database during the processing time of a message
and can not be changed easily afterwards Archiving and Deletion has to be configured
prior to processing messages for the relevant interface. If you want to change the
archiving of interfaces after the message processing please consult Note 789352.
In general only messages with a final status can be deleted. Asynchronous messages in
error cannot be deleted and have to be cancelled first. While in the Integration Engine
(ABAP) asynchronous messages that were manually cancelled or changed have to be
archived they will be per default be deleted directly in the Adapter Framework.
For the archiving, different actions need to be taken, depending on the type of object you
would like to archive: