cancel
Showing results for 
Search instead for 
Did you mean: 

How to change encoding in Multimapping to process special characters?

Former Member
0 Kudos

Dear All,

We are facing a problem in Processing special characters (western european .e.g. À, È, Ì, Ò, Ù). PFB the scenario details:

PI Version: 7.4 Single Stack, SP 09

Scenario: We are reading a fixed length file and by using Java Mapping we are inserting data in to 4 tables in target DB.

               SFTP(Fixed length file)--> Java Mapping (1:4 multimapping with 4 different interfaces and 1 single receiver)-->JDBC receiver

Issue Description: We are facing issue while processing special characters, as mentioned above. These special characters were getting distorted. As per our understanding, this problem is due to character encoding and can be broken into following parts:

1. Inbound Message via SFTP: This has been addressed by using MessageTransformationBean and setting Transform.ContentType parameter as shown below:

After above setting, the Inbound message to PI is coming properly without any distortion.

2. Java Mapping: In Java mapping we have set the encoding at two places:

    a) Encoding change for output stream

          out.getOutputPayload().getOutputStream().write(new String(OpString).getBytes("ISO-8859-1"));

    b) Encoding for XML Message Structure: By setting

        <?xml version="1.0" encoding="ISO-8859-1" ?>

After above changes the mapping is able to process special characters and mapping output structure is as follows:

<?xml version="1.0" encoding="ISO-8859-1" ?>

- <ns0:Messages xmlns:ns0="http://sap.com/xi/XI/SplitAndMerge">

<ns0:Message1>
     <ns1: MT_TargetMessageType1 xmlns:ns1="targetnamespace">....</ns1: MT_TargetMessageType1>
</ns0:Message1>

<ns0:Message2>

  <ns1: MT_TargetMessageType2 xmlns:ns1="targetnamespace">....</ns1: MT_TargetMessageType2>

</ns0:Message1>


<ns0:Message3>

     <ns1: MT_TargetMessageType3 xmlns:ns1="targetnamespace">....</ns1: MT_TargetMessageType3>

</ns0:Message3>


<ns0:Message4>

     <ns1: MT_TargetMessageType4 xmlns:ns1="targetnamespace">....</ns1: MT_TargetMessageType4>

</ns0:Message4>


</ns0:Messages>


3 Message Split: The above o/p from the Java Mapping is split up into 4 messages. E.g. Resultant structure is as:

<?xml version="1.0" encoding="UTF-8" ?>

<ns1:MT__TargetMessageType1 xmlns:ns1="TargetNamespace">
</ns1:MT_TargetMessageType1>


At this step we the output is distorted for special characters. E.g. À, È, Ì, Ò, Ù are appearing as?,?, ?, ?, ? A, E, ?, I, O, U
As per our understanding, this is due to, as we see above, the encoding is still UTF-8 after split up..


Please suggest how to handle this. Ultimate target is to be able to process these special characters..

Thanks,
Rahul

Accepted Solutions (1)

Accepted Solutions (1)

praveen_sutra
Active Contributor
0 Kudos

Hi Rahul,

Could you please try below link.

hope this  helps,

thanks and regards,

Praveen T

Former Member
0 Kudos

Hi Praveen,

Thanks for your response!

This has already been done as mentioned in Part 2 in Issue Description.

PI takes output of Java mapping (which is multi-mapping) and does the message split and after message split individual messages are having encoding UTF-8. Not sure how to change this encoding from UTF-8 to ISO-8859-1 after message split as this split happens at runtime after message mapping.

Is there a way to influence this behaviour without impacting any other interface?

Thanks,

Rahul

praveen_sutra
Active Contributor
0 Kudos

Hi Rahul,

Sorry i missed that part.

could you please refer below discussion.

not sure if it can help.

thanks and regards,

Praveen T

Answers (1)

Answers (1)

former_member186851
Active Contributor
0 Kudos

Hello Rahul,

In the Operation Mapping did you put this Java mapping before the Multimapping. I guess it should work. Since your passing the encoded input to multimapping.

Former Member
0 Kudos

Hello Raghuraman,

Thanks for your response!

This Java mapping is itself Multimapping. No separate mapping is used. Operation mapping has only this Java mapping.

Thanks,

Rahul