Troubleshooting Common Issues

Errors on the transport layer often result in messages not reaching the final destination or the middleware system because of network issues or network-related configuration errors. The root cause may originate from the sending system, the receiving system, or may even be located between them, caused by a network component such as firewalls, proxy servers, and others.

Error messages related to transport layer issues are usually only found in the sending system because the message couldn’t reach the receiving system.

The following list provides common examples of configuration items that lead to transport-layer errors when set up incorrectly.

• Hostnames: An incorrectly configured hostname on the sending system causes DNS (Domain Name System) resolution to fail. Without the hostname of the receiving system being resolved, the message will not leave the sending system. "Host not found" or "Hostname cannot be resolved" are common error messages.
• Ports: Ports can be misconfigured in the sending system, blocked by firewalls or other network components along the way to the receiving system, or the receiving system may be set up incorrectly so that data cannot be received on the designated port."Connection refused" or "Connection Timeout" are common error messages.
• HTTP(S) paths: In the source system, configured target paths must match the endpoints provided by the target system. If messages are sent to the wrong path, the receiving system might react very differently:
  • HTTP 404 (Not Found) indicates that a resource doesn’t exist, for instance, that an integration flow is not deployed, listens on another path, or the configured path in the source system has a typo.
  • HTTP 401 (Unauthorized) and HTTP 403 (Forbidden) indicates that the path might be valid, but the user doesn’t have access to it, the credentials are not valid, or the resource at this path doesn’t exist, and the system returns this error as a general response.
  • HTTP 400 (Bad Request) and HTTP 500 (Internal Server Error) indicate that there might be a resource at this path, such as a web service listening for inbound connections, but invoking the service didn’t succeed.
• TLS/SSL issues: Root causes often include trust relationship issues, including missing certificates or expired validity periods. This is indicated in some systems by the keyword ICM_HTTP_SSL_ERROR within the error description. The root cause of such an issue can be present in both the sending and receiving systems and is often related to missing or expired certificates in the trust chain.

If a message fails to reach the target system, an error message usually appears only in the source system log, because the communication attempt didn’t reach the target system.

Unlike connectivity issues, this kind of error typically indicates that messages reach the target system but can still not be delivered because of invalid credentials or insufficient access rights.

• Authentication Issues: Invalid credentials, such as an incorrect username, a typo in the password, or an invalid certificate, can cause authentication problems. This typically results in an HTTP 401 (Unauthorized) error returned to the source system. Some target systems log such errors by default or when specific trace modes are enabled. Invalid login attempts for an existing user can cause the account to be locked. Once a user account is locked, even subsequent login attempts with the correct password will result in errors.
• Authorization Issues: After successful authentication, the authenticated user may still have insufficient access rights for the resource. This typically results in an HTTP 403 (Forbidden) error returned to the source system and may also be logged in the target system.

  While a lack of permissions is a common cause, it can also result from using the wrong technical user for a specific scenario. For example, attempting to access the cloud CRM's inbound connector services with a user who only has access to the code list REST APIs. In the cloud CRM, permissions for technical users are automatically applied through communication configurations, but in SAP S/4HANA, you must manually manage the access rights of technical users.

Mixing up authentication and authorization, or the HTTP errors 401 Unauthorized and 403 Forbidden, is a common mistake. Therefore, we clarify them again:

1. HTTP 401 (Unauthorized) – Authentication fails – Wrong credentials
2. HTTP 403 (Forbidden) – Authorization fails – Lack of permissions

The listing also highlights the sequence. Authentication occurs first. Only for a successfully authenticated user can permissions be checked. As long as the user isn’t authenticated, the system doesn’t know who the caller is or what permissions should apply.

Let’s have a closer look at how issues with credentials are treated and displayed in each system.

The following screenshots display error messages across different systems after the usernames or passwords were intentionally changed to incorrect values.

1. SAP S/4HANA: Error details for an outbound message in the Web Service Message Monitor(transaction SRT_MONI)

   SRT: Wrong Content-Type and empty HTTP-Body received: ("HTTP Code 401: Unauthorized")

2. SAP Sales and Service Cloud Version 2: Error details for an outbound message in the Message Monitor.

   Error in target system for outbound asynchronous message. (code 401)

3. Cloud Integration to SAP S/4HANA: Error details in the Monitor Message Processing log.

   An internal server error occured: HTTP response 401: Unauthorized.

4. Cloud Integration to SAP Sales and Service Cloud Version 2: Error details in the Monitor Message Processing log.

   HTTP operation failed invoking {...} with statusCode: 401

After a message is delivered to the target system, several technical issues can still prevent the message from being processed successfully. These errors can occur in any of the involved systems.

Typical root causes include the following:

• Parsing errors caused by invalid content: Imagine the sender system sends an XML message while the receiver system expects JSON.
• Malformed messages: For example, XML messages that violate the schema definition (XSD), such as a code that is sent as "01" when the target system expects only a single character or digit and disallows longer content.
• Inactive communication systems or communication configurations in SAP Sales and Service Cloud Version 2

SAP Sales and Service Cloud Version 2 often responds to technical issues with HTTP 400 (Bad Request), which is otherwise primarily used for application errors. Whether an entry appears in the Message Monitor or the error message is only returned to the caller depends on the specific issue.

Cloud Integration typically returns an HTTP 500 (Internal Server Error) when messages fail to process. In some cases, Cloud Integration, acting as middleware, informs the caller about errors in the target system.

The calling system then receives a SOAP fault message with the content "An internal error occurred. For details check MLP ID ...". However, the actual processing details can only be found inside Cloud Integration, as the screenshot series in the next section shows.

The following series of screenshots shows the monitoring tools for all systems following a message sent from SAP S/4HANA to the cloud CRM. The message couldn't be processed in the cloud CRM because the communication configuration was inactive at that time, which leads to an error message in Cloud Integration that is returned back to SAP S/4HANA.

1. SAP S/4HANA - Web Service Message Monitor:

   System Error with a message from Cloud Integration: An internal error occurred...

2. SAP S/4HANA - Message Details:

   Show the full message with a URL pointing to the message processing log in Cloud Integration.

3. Cloud Integration - Monitor Message Processing:

   Messages with the status Failed and Error Details, such as:

   HTTP operation failed invoking https://my...crm.cloud.sap/sap/c4c/api/v1/inbound-data-connector-service/... with statusCode: 400

   → Clear indicator that the error occurred in SAP Sales/Service Cloud Version 2.

4. Cloud Integration - Text View:

   Often quite lengthy, but contains further error details, usually at the very top or bottom, in this case:

   1. inbound-data-connector.100: Failed to create the inbound message.
   2. inbound-data-connector.125: Communication configuration for communication system T41CLNT400 does not support the message sap.crm.md...

The error message Communication configuration for communication system T41CLNT400 does not support the message sap.crm.md... indicates an issue with the communication configuration. A common cause might be a missing inbound service in the configuration. In this specific case, the root cause was that the entire communication configuration was not set to Active.

Although this error was visible in Cloud Integration and SAP S/4HANA, it didn’t create a message in the web service monitor in SAP Sales and Service Cloud Version 2.

Error messages, such as Role ... does not exist; code: sap.crm.common.commonMessage. ... CodeValueDoesNotExist, indicate a problem with code lists or possibly value mappings.

This can have the following root causes and solutions:

• A code value is missing in the cloud CRM and needs to be created in the cloud CRM’s settings.
• A code value, which was not intended for the cloud CRM, was transmitted. The value should be filtered out in future transmissions.
• A value mapping is required but doesn’t currently exist. It needs to be created.

The following screenshot shows a code list error caused by the unintended transmission of the business partner role code FLCU00, which does not exist in the cloud CRM.

When objects are missing or the corresponding External ID Mapping entry is absent, the cloud CRM will display the following error message or something similar: Mapping Error at ...: Key mapping not found for XXX, external key ...

Such errors are most likely to occur during initial load, when an object is replicated that references other objects (for example, a product that references sales organizations). If the referenced objects are missing or are not properly maintained in the target system, the replication message cannot be processed. Typical cases include:

• The referenced object does not yet exist in the cloud CRM. This could be because the referenced object is supposed to be replicated, but it hasn’t been received yet, or the corresponding message was received but encountered an error during processing. In such cases, it’s important to determine why the referenced objects are missing or whether the reference is unnecessary in the target system and should be omitted during replication.
• The referenced object exists in the cloud CRM, for example, because it was created manually. However, the External ID Mapping entry is missing. The reference to such objects typically relies on the external ID. As long as the external ID is not maintained, processing the message will not succeed. In this situation, the External ID Mapping can be maintained manually.

The following screenshot shows such an error message where a business partner was replicated with a sales employee in its partner functions, which does not exist in the cloud CRM. As a result, the error message states that it cannot find the key mapping, which is an internal term for External ID Mapping.