CPI - white space in XML element removed by message mapping

[MaAll]

Hi CPI experts,

I have a simple message mapping in CPI which maps from a source XML to a target XML. There is a requirement in the target system that any element not present in the XML is created and must contain a space character.

To do this in CPI I created a simple mapping from the source element to the target element, with a mapWithDefault containing a space.

The issue is that when the target element is created it will not contain the space, it instead will pass an empty element when it is output back to the body of the iflow.

Example of the expected target:

<field1>aaa</field1>

<field2> </field2>

<field3>ccc</field3>

However what the message mapping actually produces is an empty element:

<field1>aaa</field1>

<field2/>

<field3>ccc</field3>

I could not find this behaviour documented. Is this expected behaviour?

The same empty element output can also be seen when using the simulate test in the message mapping. However using the Display Queue in testing will show the space still present in the element <field2> </field2>.

I have also tried with passing a constant of space too - same issue.

I have also tried using a simple groovy function in the mapping to pass a space or a horizontal-tab. Again, both whitespace characters are removed when the Target XML is output to the body after the mapping.

It appears that it is not possible to pass whitespace only in a message mapping. White space is only maintained as expected if it is present with other text in the element.

Please let me know if you have seen this behaviour before or if you can replicate the same behaviour in your CPI mappings?

Thanks,

Matt

[Sriprasadsbhat · Accepted solution]

Hello Matthew,

I have tried your scenario unfortunately its not working.Appreciate if you could raise a ticket to LOD-HCI-PI-ET-MAP so that somebody from development team can look into it.Also I have observed if you are passing space in constant also being truncated in output.So finally I left with custom function which worked.As an alternative you can use below function which works for sure .

Once you follow above it gives window to write script and copy below and then map it .

import com.sap.it.api.mapping.*;

def String customFunc(String arg1){
	if(arg1.equals(""))
	return "\u00A0" 
}

Regards,

Sriprasad Shivaram Bhat

[MaAll · Accepted solution]

Hi Sriprasad,

Many thanks for your quick response. Your suggestion has worked.

I will raise this with SAP against ticket to LOD-HCI-PI-ET-MAP as a bug as you suggest.

I had already tried some similar groovy code in a function, but I was trying with the "SPACE" hex code \u0020. This gets removed by CPI, leaving an empty element.

However your suggestion to use \u00A0 - "NO-BREAK SPACE" works within CPI and it is not removed.

Hopefully this workaround will also be acceptable in the target system - still to be tested.

Thanks,

Matt.

[matthiasbraeuer · Accepted solution]

Hi Matthew:

Did you end up raising a ticket about this issue? We are facing the same problem in a message mapping. Formatting strings with whitespaces via, e.g., `padLeft` or `sprintf` in a mapping script results in the whitespace being removed in the final message. Padding a string with other characters (incl. non-breaking spaces) works but the receiver system (ECC) does not accept those and therefore requires enhancements to the IDoc processing.

I wasn't able to find a note or KBA on this immediately.

Thanks and best regards
Matt

[MaAll · Accepted solution]

Hi Matthias,

I did raise it, but it was part of a wider and more complex ticket. In the end, this specific space issue was not resolved in that ticket.

It should really be be 1 issue = 1 ticket with SAP. However I've not had time to specifically raise it in LOD-HCI-PI-ET-MAP. It was not a high priority for me since I have a workaround using NO-BREAK SPACE instead of SPACE.

I'm sure the community would appreciate it if you were able to raise a ticket with SAP to get this fixed. This same issue has occurred multiple times on this forum.

Thanks,

Matthew