Part 5 of the blog series deals with the deletion of performance data that gets stored for the xml messages.
Performance data is persisted for both, synchronous and asynchronous messages in table SXMSPFRAWH and hence the performance headers for XI messages (SXMSPFRAWH table entries) must be reorganized. Perform the steps listed below in sequence.
1. Below steps must be carried out in the Integration Server client, which can be found in SE16 by looking at table SXMSCONFVL. In the field ‘VALUE’ enter ‘HUB’ and press F8 – the corresponding table entry lists the IS client beside parameter ENGINE_TYPE as shown.
2. Set the following XI parameters using transaction SXMB_ADM -> Integration Engine Configuration -> Category PERF.
3. Schedule an initial single run of the reorganization job at a time of low workload. This job may run for several hours as it removes all XI message performance headers up to the previous 15 days. Create the job in SM36 using the name SAP_XMB_PERF_REORG and including program step SXMS_PF_REORG.
4. When the initial reorganization job is finished schedule two periodic background jobs to aggregate and reorganize XI performance data. Use the following settings:
This job reads the persisted runtime data from the persistence layer and aggregates it on an hourly basis. You must schedule this job once for each system by calling transaction Define Job (SM36) and using the following values:
Job name: SAP_XMB_PERF_AGGREGATE,
Job class: C
Under Start condition ® Date/Time, Period: 1 hour
Choose Step -> ABAP Program and specify the following step:
Go to transaction SM37 and check the status of Job SAP_XMB_PERF_AGGREGATE
Job SAP_XMB_PERF_REORG :
This job deletes the runtime data once the time interval defined by the configuration parameter DAYS_TO_KEEP_DATA has been exceeded.
You must schedule this job once for each system by calling transaction Define Job (SM36) and using the following values:
Job name: SAP_XMB_PERF_REORG,
Job class: C
Choose Start condition ® Date/Time, Period: 1 hour
In Step -> ABAP Program, specify the following step:
Go to transaction SM37 and check the status of Job SAP_XMB_PERF_REORG
TIPS & TRICKS:
Below are few tips related to various reports that can be used in PI.
1. Table SXMSMSTAT displays different status of the messages.
2. Use report RSWF_XI_INSTANCES_DELETE to delete data records (which are flagged as erasable) from the ccBPM message persistence. The report deletes the data without any further confirmation or consultation if you execute it from the selection screen. If you want to examine the data before the report deletes it, you can call the report RSWF_XI_INSTANCES_SHOW, which you can use to display and examine the erasable messages.
3. Check if there are messages with a white flag in transaction SXMB_MONI or with message state: 01 – Scheduled. If this is the case, please use report RSXMB_CANCEL_NO_COMMIT_MSG.
4. Use report RSXMB_SHOW_STATUS to display the status of different messages in system.
5. Based on the results of report RSXMB_SHOW_STATUS check the number of messages with adapter status 001, 007 and 008. Should you find status 001 and 008, schedule following report to refresh status of messages SXMS_REFRESH_ADAPTER_STATUS.
6. You use report RSXMB_CANCEL_MESSAGES to cancel messages with status 014 and 017 from the system rather than manually cancelling them.
7. Use message monitoring in Runtime Workbench to check for messages having statuses other than successful (i.e. HOLDING, WAITING, DELIVERING, SYSTEM ERROR etc.)
9. You have executed the report RSXMB_SHOW_STATUS and you find many entries with status 14. In the XI monitor, you cannot find so many messages with errors. In the XI monitor (transaction SXI_MONITOR) you can always display the acknowledgements if you set the following selection parameters on the “Advanced Selection Criteria” tab page:
“Logical Pipeline ID” as “CENTRAL_BACK” and select the checkbox “With Acknowledgment Messages”
10. If you use the local Alert Framework to generate alerts e.g. by using Message based alerting you also have to consider deletion (archiving) of alerts in your XI system. Based on the number of alerts generated table SALRT can grow significantly otherwise. To delete alerts the execute report RSALERTPROC in SE38.
11. The application log is a tool to collect, save and display logs. Many different applications collect messages in the application log which contain information or messages for the end user. The application automatically log serves as a temporary storage for messages. The logs are written on the database but they are not automatically deleted. There is no general procedure for switching the application log on or off.
A log usually has an expiration date, which is set by the application that calls the ‘Application log’ tool. If the application log does not set an expiration date, the ‘Application log’ tool sets the expiration date as 12/31/2098 or 12/31/9999,depending on the release, which allows the logs to stay in the system for as long as possible. The end user cannot set the expiration date. The expiration date does not mean that logs which have reached that date will automatically be deleted. It is used to control the deletion of logs when you call the Deletion report.
The DEL_BEFORE flag in the BALHDR table determines whether or not the log can be deleted even before the expiration date is reached.
DEL_BEFORE= SPACE means that the log can be deleted before the expiration date is reached.
DEL_BEFORE=‘X’ means that the log can only be deleted after the expiration date.
For SAP Releases greater than 4.6A use Transaction SLG2 to delete these logs from system.
If you also want to delete logs which have not reached the expiration date you must set the option “Also logs which can be deleted before the expiration date”.
You can refer to other parts of this Blog series at following links: