The incoming IDOCs are created when the objects are to be created/updated at SAP side (triggered by the Cloud). Once the incoming IDOC has been successfully processed, it should have the Status 5153:
...
The following Statuses are set during the lifetime of the IDOC:
Status | Description |
60 | IDOC has been created (normally this status is set for a very short time, very soon the next status should be set) |
64 | IDOC ready to be transferred to the application (normally this status is set for a very short time, very soon the next status should be set) |
62 | IDOC passed to the application (normally this status is set for a very short time, very soon the next status should be set) |
53 | The IDOC has been properly processed. To see more details, you should double click at the status 53:
The log is presented: 
|
51 | The IDOC has not been properly processed. To see more details, you should double click the status 51: 
|
...
The logs of the application can be viewed with the following call of SLG1 transaction:
...
Besides message monitoring in SAP as described in Data Extractor paragraph above, it is also possible to track the communication on the Message Broker level. Message Broker produces log files that contain runtime information related to the message processing. The messages are generated with the following log levels:
DEBUG – the most verbose level, containing detailed information of message processing, including content and metadata of XML messages being sent between SAP and Cloud
INFO – contains entries for messages transferred, so that it is possible to track message exchange, but no detailed information (i.e. no message content)
WARN – entries generated for non-critical problems
ERROR – entries generated for problems that prevent message exchange (problem to connect to SAP or Cloud, application misconfiguration, etc.)
...
User administration
...
56 and 68 | If the FSM Cloud Connector transporter does not receive confirmation for a message after a certain amount of time (around 15 minutes), the transporter resends the same message. Such timeout should not happen if connection and traffic is well optimized. Duplicated messages will be identified and receive status 56. Since
|
| Anchor | ||||
|---|---|---|---|---|
|