cancel
Showing results for 
Search instead for 
Did you mean: 

Extra Special Characters in File-IDOC to File Scenario in SAP PI

sri_reddy10
Explorer
0 Kudos

Hi All,

I have a IDOC to File Scenario in SAP PI.

Our sender is an SRM system and receiver is SFTP server.

The file received in SFTP folder has some extra special characters.

These extra special character is not displayed in payload of SXMB_MONI of PI.

When i tried to copy the payload of moni and tried processing through the Integration Engine,got the below Error.

I have checked the encoding in RFC connections as well as module parameters(we have used MTB) which is UTF-8.

Kindly help me on the above issue to removethe special character.

Regards,

Sri.

Accepted Solutions (0)

Answers (4)

Answers (4)

stefan_grube
Active Contributor
0 Kudos

These extra special character is not displayed in payload of SXMB_MONI of PI.

When i tried to copy the payload of moni and tried processing through the Integration Engine,...

Do not copy the payload from Monitor.

Your File is UTF-8, when you copy it, it becomes ANSI. PI will fail with codepage ANSI, it expects UTF-8.

Upload the file instad of copying it.

RaghuVamseedhar
Active Contributor
0 Kudos

Sri,

Please request SRM functional person to check with end user, who has entered this data in SAP SRM system. Check SAP SRM ABAP table. I guess it is a typo.

Is this issue occurring in other messages, other parts of same message?

FYI. Â and £ are on right hand little finger in European keyboard.

iaki_vila
Active Contributor
0 Kudos

Hi Sri Reddy,

The best way is to do the java mapping proposed by Praveen and to omit the special characters.

You have another alternatives, changing the charset like the java mapping in this link http://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/502991a2-45d9-2910-d99f-8aba5d79f...

Finally, you can try to skip the special character at IDOC adapter as well, like this note pointed out 1420744 - IDoc adapter: Rare special characters in IDoc XML

Hope this helps.

Regards.

sri_reddy10
Explorer
0 Kudos

Hi Inaki,

Thank you for your reply.

As mentioned in my reply to praveen,this specail character is not a ppart of IDoc data but is generated when the file is been generated at the target side.

I can use the Java mapping if the specail character could be predicted.

So,Could you please suggest any alternate way.


iaki_vila
Active Contributor
0 Kudos

Hi Reddy,

I haven't seen the necessity to predict the £ symbol. You can do your normal mapping and in the operation mapping set a before java mapping to replace this symbol (or to change to the charset ISO-8859-1 HTML ISO-8859-1 Reference). If the symbol is not in the payload the java mapping won't do anything, Please, correct me if my supposition is wrong.

Regards.

Ryan-Crosby
Active Contributor
0 Kudos

Hi Sri,

I don't think you have a problem with the payload but rather the designated encoding of the target file.  If you read a pound sign that is encoded in UTF-8 then it is a two byte sequence of 194, 163.  If you then read that file using a program that recognizes the file encoding as ISO-8859-1 instead of UTF-8 then you will see the two characters '£' instead of '£' because those are the corresponding two characters in ISO-8859-1 for that two byte sequence.

Try a simple experiment with Notepad++ for example: copy the two byte sequence above into a new file and it will display as the two bytes.  Then change the encoding to UTF-8 from the menu and you will get the one single byte to display.

Regards,

Ryan Crosby

praveen_sutra
Active Contributor
0 Kudos

Hi Sri,

You can use java mapping to change the encoding type and remove special character.

hope this helps.

thanks and regards,

Praveen T

sri_reddy10
Explorer
0 Kudos

Hi Praveen,

Thanks for the reply.

Coul you please suggest if there is any alternative way to solve this as the special character is auto generated during conversion at the receiver side(File).

So for any other combination ,we will not kinow what will be the special character that it will convert.