3606052 - Unexpected Header Payload Format when Saving the Source Payload from CPI of Cloud for Customer Version 2 Iflow

You have observed an issue where the source payload is not being saved properly because of a misconfiguration in the Content Modifier. Specifically, the Data Type field has been set to "java.io.Reader", which appears to prevent the payload from being correctly stored and accessed.

Use Case example: 

The configuration for saving the source payload seems incorrect. In the content modifier, data Type is filled with "java.io.Reader", and it's not saving the payload properly.

The header payload will be saved as : java.io.StringReader@75efed9b

by removing the data type value, the source payload in the header is visible.

Symptom noticed:

Instead of displaying the actual payload content, the header shows an instance reference such as: java.io.StringReader@75efed9

Sales Cloud Version 2

Service Cloud Version 2

SAP Cloud Platform Integration (CPI)

• In CPI, enable the Trace log level to capture the Source Payload. 
• Evoke the message processing flow of the respective iflow by pushing a replication.
• e.g. 
  • Iflow: Replicate Equipment from SAP S4Hana
  • Content Modifier: Save Source Payload
  • Message Header: Create action

 This Data Type "java.io.Reader" is used to handle large payloads in HTTP headers efficiently. Since the payload can be huge, sending it as a string could exceed the maximum allowed length for an HTTP header. To avoid this, we are using Java's Reader class to process the payload more efficiently.

This is working as designed. Casting the data type is a better use of HTTP header. Since the source payload can be huge, sending it as a string can exceed the length of the maximum allowed HTTP header length.

SAP is using a Reader data type instead of a String one. Within the reasons below:

• Instead of handling the source payload as a direct string (which could be too large), the data is processed using the Reader class.
• The Reader class allows streaming access to the data, meaning it doesn’t require loading the full payload into memory at once.
• Avoiding String Length Limits: If the payload were handled as a string, there would be a risk of exceeding the maximum HTTP header length, causing errors.
• We are simply passing a reader object instead of a string, which reduces the number of characters and makes the message smaller.

By removing "java.io.Reader" from the Data Type field in the Content Modifier, the system will store the actual payload instead of a Reader reference. Once this change is applied, the source payload in the header should become visible as expected.

If you want a different behavior, the Workarounds are: 

1- either to remove the Data Type Value in the Content Modifier;

By removing "java.io.Reader" from the Data Type field in the Content Modifier, the system will store the actual payload instead of a Reader reference. Once this change is applied, the source payload in the header should become visible, as expected.

2 - Create a Custom Exit iflow to by pass the Reader Class;

In the Custom Exit, you can simply read the payload by passing the Reader class, which is more efficient.

Below is an example of reading the country from the source payload, which is a Reader object:

def xmlString = message.getHeader("sourcePayload",java.io.Reader)
  def xml = new XmlSlurper().parse(xmlString)
  
  def country = xml.EquipmentType.Country.text()

KBA , CEC-CRM-INT , Integration for SAP Sales/Service Cloud , How To