When using ccBPM (cross-component Business Process Management) in SAP Exchange Infrastructure or SAP Process Integration problems might occur with archiving of ccBPM messages or deletion of ccBPM message persistency. Typically these problems show only after a while when database tables grow and slow down the system. This article gives a short overview about ccBPM message deletion and describes some situations which can lead to problems with ccBPM message deletion or archiving.
2 Overview ccBPM Message Reorganization
During execution of a ccBPM scenario there are three different types of ccBPM runtime data or messages produced that need to be reorganized:
1.Â Â Â Â Â PI Messages (including ccBPM copies in pipeline PE_ADAPTER)
2.Â Â Â Â Â Process Instances (Work Items)
3.Â Â Â Â Â ccBPM message proxies or ccBPM message persistency in Tables SWFRXI*
The following sections describe how to reorganize the relevant data.
2.1 Archiving or Deleting the PI Messages
Sometimes problems occur with PI Messages that cannot be deleted or archived because of their message and adapter status. To analyse this situation a special report RSXMB_SHOW_STATUS was provided with SAP Note 944727 – Status overview of XI messages. It checks the PI messages in the system regarding their message status and adapter status. As a result it gives an overview about how many messages can be archived or not and shows the number of messages per status. Â
The report might have a long runtime, so please make sure that SAP Note 1236724 – XI3.0/7.0x/7.1x: Termination of report RSXMB_SHOW_STATUSÂ is implemented on your system and execute the report as a batch job.
The report shows the number of messages in different message statuses:
For messages in message status 003 (successful) it also includes the adapter status:
From ccBPM point of view messages with message status 029 or message status 003 combined with adapter status different from 000 or 006 typically cannot be reorganized and have to be analyzed in detail.
Usually the procedure described in SAP Note 1042379 – BPE-HT: Deleting messages that are no longer used helps in these cases. The note does not have to be implemented, it just describes the procedure to delete old messages and clean up the system from failed process instances. It is important that each step is executed one after another. When there are many â€˜oldâ€™ process instances in status â€˜STARTEDâ€™ or â€˜ERRORâ€™ in the system that shall not be restarted, maybe it is not applicable to logically delete the messages manually as described under section 1c) of the note. Then the mass cancellation feature in transaction SWIA introduced with SAP Note 1286336 – SWIA: New “Logically Delete” function for mass processing might be used.
2.2 Archiving or Deleting the Process Instances (Workflows)
It is important not to forget to archive or delete the process instances that are created when using ccBPM. If workitem archiving or deletion is not done regularly this leads to an increasing table size of SWWWIHEAD and other workflow tables like SWWCNTP0, SWPCMPCONT or SWWLOGHIST.
The procedure to archive or delete the workitems is described in SAP Note 836092 – Archiving/deleting work items in the XI .
2.3 Deleting ccBPM Message Persistence Data
During execution of a ccBPM scenario there is also additional data created for the ccBPM message persistence or also called ccBPM message proxies. These message proxies have to be deleted regularly. These message proxies and related process-specific data are stored in tables SWFRXICNT, SWFRXIHDR and SWFRXIPRC.
The two reports used for displaying respectively deleting entries from these tables are RSWF_XI_INSTANCES_SHOW and RSWF_XI_INSTANCES_DELETE, which are described in SAP Help Page “Deleting Process Data No Longer Required”. RSWF_XI_INSTANCES_SHOW can be used to display and check the relevant data first. Here it is important to use also the deletion timestamp as selection criteria. Otherwise there are also messages shown for which the deletion timestamp is not set. Such messages showÂ no value in the second column from the right. Message proxies with no deletion timestamp set cannot be deleted.Â In this case also the procedure of SAP Note 1042379 – BPE-HT: Deleting messages that are no longer used should be applied.
There are a few additional SAP Notes available for the report RSWF_XI_INSTANCES_DELETE, which correct program errors in this area. Please check if the following SAP Notes are already implemented on your system:
There are also two SAP Notes that improve the performance of report RSWF_XI_INSTANCES_DELETE:
3 Analyzing Problematic Messages in Detail
When there are many problematic XML Messages in the system, it is useful to search for the reason why they cannot be reorganized. Either the situation is caused by some programming errors, which are already corrected with the SAP Notes mentioned earlier in the blog or it can be also caused by process design errors.
This section shows some examples why the XML Messages stay in a not reorganizable status, the most common cases are these two:
- Messages with message status 003 â€“ successful and outbound status 001 â€“ Scheduled for Outbound Processing, shown with a green flag in column â€˜Outbound Statusâ€™ in monitoring transaction SXI_MONITOR
- Messages with message status 029 â€“ Transfer to Process EngineÂ
3.1 Messages in Status ‘Scheduled for Outbound Processing’ in SXI_MONITOR
There are messages with a green flag (â€˜Scheduled for outbound processingâ€™) in column â€˜Outbound Statusâ€™ in monitoring transaction SXI_MONITOR. These messages are in pipeline â€˜CENTRALâ€™.
Report RSXMB_SHOW_STATUS shows messages with message status 003 and adapter status 001.
In SXI_MONITOR for such a message clicking on the PE or SA_COMM hotspot in column â€˜Outboundâ€™ leads to:
an empty qRFC monitor for Outbound Queues:Â
– Â Then it could be the case that the entry in the outbound queue was deleted manually.
– Â Or the message was buffered (parked) at a process instance that is now already finished. In SXI_MONITOR you sometimes see the message â€˜Message 0123456789ABCDEF was parked at process 012345678901, but not yet processedâ€™. Usage of global correlations in combination with delivery mode â€˜Buffering possibleâ€™ can be the reason for it. In standard view of transaction SXI_MONITOR check the column â€˜Queue IDâ€™ for the queue name that contains the task name (â€˜WS<xxxxxxxx>â€™, xxxxxxxx being an 8-digit number). This task name stands for the process definition that the message was or should be delivered to. For a solution and details on buffered messages see recommendations beneath under â€˜Messages were buffered at a Process Instanceâ€™.Â
-Â Â Possibly the message could not be delivered to a process instance because of a missing correlation and the system was configured to ignore this error (configuration parameter ERROR_ON_NO_CRL_FOUND = 0). SAP Note 1094028 – BPE RUN: Queue is stopped if no correlation exists describes how to find these undelivered messages in CCMS Monitoring.Â
a qRFC monitor with a queue in status â€˜SYSFAILâ€™, then see SDN blog How to Analyze Stopped Queues in ccBPM about queues in this status and how to resolve it
a workflow log of a process instance in status â€˜STARTEDâ€™. Then you also see that the message was buffered at the process instance (in SXI_MONITOR you get the message and as entry in the Tab â€˜Step Historyâ€™ of the technical workflow log). Check whether the process instance will reach a receive step that will process the message or why it is still in status started. If the message shall not be delivered to this process instance, then also global correlations in combination with Delivery Mode â€˜Buffering Possibleâ€™ can be the reason for the problem. See recommendations beneath under section â€˜Messages were buffered at a Process Instanceâ€™
3.1.1 Messages were buffered at a Process Instance
You can identify this problem also in CCMS Monitoring in transaction RZ20. Choose â€˜CCMS Monitor Templatesâ€™ ->â€™Exchange Infrastructureâ€™ or â€˜Process Integrationâ€™-> â€™<System>_xxx_Business Process Engineâ€™ -> â€˜Process Dataâ€™ -> â€˜XML Messagesâ€™ -> â€˜Unprocessed Messagesâ€™. You can find entries like the following:
Due to an open correlation the message was delivered to a process instance, but the process instance had no active receive step at this time that could receive the message. Nevertheless the Delivery Mode â€˜Buffering Possibleâ€™ was defined for this process using transaction SWF_INB_CONF or by default. If the process instance, that the message was delivered to and buffered at, never reaches a matching receive step the message remains unprocessed.
Often using a global correlation can be the reason for the problem. Then the solution is to change the process definition in the Integration Repository so that the process is divided into a message reception part and a transformation/send part. Then the correlation can be defined local at a block that contains only the receive phase of the process. In that case the correlation is only valid during message reception. Time consuming transformation and send steps are executed outside the block when the correlation is not valid anymore.
SAP Note 1040354 – BPE-TS: Unprocessed Messages helps in these cases.
You can find these unprocessed messages via report RSWF_XI_UNPROCESSED_MSGS. This report is also available via a CCMS Monitor Template, see also SAP Note 1040354 above for details. The note includes also a reference to SAP Note 894906 – BPE-RUN: Finding unprocessed messages, which describes the features of report RSWF_XI_UNPROCESSED_MSGS. It is possible to resend the affected messages with the report.
If the messages shall not be reprocessed, it is possible to finalize these messages without processing them by using report RSWF_XI_UNUSED_MSGS. Please see SAP Note 894193 – BPE-RUN: find messages that are no longer used and delete for documentation of the report.
You can also change the Delivery Mode using transaction SWF_INB_CONF to â€˜Without Bufferingâ€™ for the affected process. Then in case a message cannot be received directly by a process instance, the queue is set to status â€˜SYSFAILâ€™ and all following messages for this process are waiting in the queue until the error is resolved and the queue is restarted afterwards.
3.2 Messages with Message Status ‘029 – Transfer to Process Engine’ in Pipeline ‘PE_ADAPTER’
Transaction SXI_MONITOR shows messages with message status 029 (Transfer to Process Engine, symbol is a grey arrow).
When executing the report RSXMB_SHOW_STATUS it shows messages with message status 029 in the system. These can be messages from process instances which did not end correctly, the process instances are in status â€˜ERRORâ€™ or â€˜STARTEDâ€™. These process instances can be found using transaction SXMB_MONI_BPE and the different transactions available there (e.g. Process Selection).
If there are many more messages with status 029 in the system than processes that are not finished, then there could be a problem with the message status change when finishing a process. Check if every SAP Note mentioned in this blog is implemented in your system, especially the ones mentioned in section â€˜Deleting ccBPM Message Persistence Dataâ€™ and in SAP Note 1042379.
Also these messagesÂ occur combined with the messages in section 3.1, so avoiding the problems that lead to messages in status â€˜Scheduled for Outbound Processingâ€™ reduces these messages for the future as well.