The user wants to get information regarding the meaning of the individual statuses of XML messages:
- Has the message a final status or can it be restarted?
- What does the status refer to, which actions can the user take?
- What is the English-German translation?
- What changes have been implemented among the different Support Package levels?
- Which statuses permit me to either delete or archive messages?
- In the ABAP monitoring, what are the equivalent statuses?
The user can use SAP XI 3.0 and he also uses the message display tool (MDT) for monitoring his XML messages. With PCK (Partner Connectivity Kit) installations, the user can reach the tool with "PCK homepage -> Message monitor". If the user works with an XI Integration Server, he can reach the MDT with "Runtime Workbench (RWB) -> Message monitoring".
The "Statuses" dropdown list comprises of the different selection options. He should be able to differentiate whether he monitor XML messages of the Integration Engine (ABAP) or a central/decentralized adapter engine (Java). When he monitors the adapter engine messages, not all statuses available return results as these only exist in ABAP. They are the following statuses: "Branched", "Application error, "Changed manually", "Repeat attempt" and "Unknown". On the other hand, the "Delivering" and "Holding" statuses only exist in the adapter engine however not in the Integration Engine (ABAP).
The statuses which exist in the ABAP monitor for processed XML messages (transaction SXMB_MONI) are grouped partially together in the MDT. For instance, the statuses for a manual and automatic retry are put together and combined in a " Repeat attempt" status. This means that the statuses showcased in the MDT are a subset of the statuses displayed in the ABAP monitor. More details have been listed in the following description of the individual statuses of the Integration Engine.
The statuses have been listed as follows:
I) Monitoring Adapter Engine.
II) Monitoring Integration Engine
III) Other Statuses
Deletion of messages of the adapter engine
Up to XI 3.0, Support Package 10, can can delete all messages – irrespective of their status - from the database post the retention time has expired. As of Support Package 11, the user can only delete messages with a final status ('successful' or 'canceled with errors').
Archiving messages of the adapter engine
The deletion rules for messages are also applicable to the archiving of messages.
Solution
I) Monitoring Adapter Engine
Successful (German: "erfolgreich", internal: DELIVERED, DLVD)
The message has been delivered successfully to the relevant recipient. The status is final. Messages with this status can either be deleted or archived.
To Be Delivered (German: "zu senden", internal: TO_BE_DELIVERED, TBDL)
The message was transferred to the messaging system and was then placed in the queue for the messages which to be sent or received. The status is temporary and cannot be manually altered. Generally, this is not important, as the message has been derived from the queue by a worker thread. For a large queue, the user can initiate such a message manually for raising its priority.
Delivering (German: "wird gesendet", internal: DELIVERING, DLNG)
The message was retrieved from the queue of messages to be sent or received and is currently being transferred to its final destination. The status is temporary and cannot be modified manually. Incase the message cannot be delivered successfully, the message status changes to "Waiting" incase retries have been configured. If retries have not been configured or the maximum number of retries has been achieved then the message status changes to "System error".
Waiting (German: "wartet", internal: WAITING, WAIT)
The message delivery has failed at least once and the message is in retry mode. The user can manually restart the message. If the delivery fails post the maximum number of retries has been reached, the message status then changes to "System error".
System error (German: "Systemfehler", Internal: NON_DELIVERED, NDLV)
The message could not be delivered in any of the delivery attempts. The reason for the problem is logged in the audit log of the message. The user can access the audit log with the 'Details' pushbutton. A message with this status can be restarted which means that he can resend it after he has corrected the problem (for example, a network problem, incorrect configuration, inactive adapters, and so on).
If he cannot rectify the problem (for example, an incorrect configuration), he can change the message status to "Canceled with errors". For doing this, select the message and choose the "Cancel" push button.
Note: The user can use the "Multiple selection on" push button for switching to a mode which permits him to choose multiple messages at the same time.
Canceled with errors (German: "fehlerhaft beendet", internal: FAILED, FAIL)
The message was canceled and cannot be restarted. As of Support Package 11 for the adapter framework and Support Package 10 of the adapter framework core patch 02, user can only manually set this status. Messages with this status can be either deleted or archived.
Note: Due to a translation error, the status was termed as "completed" (German: "beendet") up to Support Package 09.
Holding (German: "angehalten", internal: HOLDING, HOLD)
This is an EOIO message whose predecessor was not processed successfully yet. The status is retained until all predecessors have been delivered successfully. If a predecessor has the "System error" status and is restarted, all successors are also restarted provided that the delivery of the predecessor is successful.
If a predecessor has the "canceled with errors" status, then further processing is impossible in systems before Support Package 11 for the adapter framework and Support Package 10 for the adapter framework core patch 02. In higher version systems, the status of predecessors can only be set to "canceled with errors" manually. Successors that have the "Holding" status which can be restarted after user has set the "canceled with errors" status (see related note 811864).
All containing errors (German: "alle fehlerhaften", internal:)
Combines all messages with a certain error status. For the adapter engine, these are the "System error" and "Canceled with errors" statuses. All (German:
'Alle', Internal:)
Syndicates all the messages with all statuses.
To summarize: There are 7 various message statuses in the Adapter Engine, of which 3 cannot be manually started. (FAIL, DNLG, DLVD).
II) Monitoring Integration Engine
Successful (German: "erfolgreich", internal: SUCCESS)
From the point of view of the current system, the message has been sent successfully to the relevant recipient or already exists. With asynchronous processings, The status is final.
ABAP monitoring: "Message processed", "Message already processed", "Message transferred to process engine", "Acknowledgment message stopped". Exception: The status ""Message transferred to Process Engine" is not final, but is updated by the BPE.
To Be Delivered (German: "zu senden", internal: TO_BE_DELIVERED)
The message is scheduled as well as released for processing. Additionally, ABAP monitoring differentiates whether the database Commit has already been issued or not. Depending on this, the status is temporary or final.
ABAP monitoring: "Message scheduled (commit follows)", "Message scheduled (commit missing)".
Note: The English translation is not correct, it should be read as "Message scheduled (commit executed)".
Waiting (German: "wartet", internal: WAITING)
The recipient was determined successfully and the message was scheduled for further processing. The status is temporary.
ABAP monitoring: "Scheduled for outbound processing".
System error (German: "Systemfehler", Internal: SYSTEM_ERROR)
The recipient cannot be determined or an error happened during the further processing. With synchronous processings, an error is returned to the sending system. The message can be restarted.
ABAP monitoring: "System error (restart possible)", "No receiver found".
Canceled with errors (German: "fehlerhaft beendet", internal:
CANCELED) The message has errors and was manually canceled. This is the final status. The message can be deleted.
ABAP monitoring: "Message with errors canceled".
Branched (German: "verzweigt", internal: BRANCHED)
A message split was made in the Integration Engine since various recipients were determined. The original message has been divided into at least two new ones. The status is final.
ABAP monitoring: "Branching: Multiple receivers found".
Application error ("Anwendungsfehler" internal: APPLICATION_ERROR)
The message was sent to an application (ABAP proxy) in which an error occurred. With asynchronous processings, the error only takes place in the receiving system, with synchronous processing, it takes place in all systems involved. The message can be restarted.
ABAP monitoring: "Application error (restart possible)".
Changed Manually (German: "manuell modifiziert", internal: MODIFIED)
The message was edited manually as well as stored. This action is possible only if the message previously had an error status ("Application error" or "System error"). The message can be restarted.
ABAP monitoring: "Message changed manually".
Repeat Attempt (German: "erneuter Versuch", internal: RETRY)
The message is in a retry mode of the Integration Engine. This status can only be set manually or automatically. The status is temporary.
ABAP monitoring: "Manual Restart for version", "Message is in automatic retry mode".
All containing errors (German: "alle fehlerhaften", internal:)
Syndicates all messages with a some error status. For the Integration Engine, these are the "System error", "Canceled with errors" and "Application error" statuses.
ABAP monitoring: No equivalence.
'Alle', internal:)
Amalgamates all the messages with all statuses.
ABAP monitoring: No equivalence.
III) Other Statuses
Unknown (German: "unbekannt", internal: UNDEFINED)
The message has an unknown status. This situation should never take place and indicated a deadly error. The status is final.