Mail attachment generated in UDF in SAP PI 7.1 - Issue with line feed

[Former Member]

Hello,

Situation is:

Implemented a scenario in SAP PI 7.1 with a mail receiver following this thread:

/people/samuel.chandrasekaran2/blog/2008/10/06/xi-mail-adapter-dynamically-building-attachment-and-message-body-content-using-a-simple-udf

which is about moving message lines from sender into an attachment forn the receiver mail.

It is working great!

The receiver gets the mail including the attachment with all added lines.

But when opening this mail there is an issue depending on the program we are using to open the attachment

which is defined as txt file

- Using MS Editor 5.1 (Windows XP 2007, SP3) the Carriage returns and line feeds (added with

in the UDF) to separate the message lines are not recognized. In the Editor each

is shown as □ within the text. Word wrap (flag set in the editor) is different to the carriage return/line feeds set in the file.

- Using MS Notepad 5.1 (Windows XP 2007, SP3) situation is the same but

is NOT shown as □ , it simply seems to be unvisible. Word wrap (flag set in the editor) is different to the carriage return/line feeds set in the file.

- Using Word 2007 the carriage returns are recognized and used in a correct way to display the file content. But now mutated vowels (äüö) are not recognized. They are displayed as

So I followed this thread:

http://help.sap.com/saphelp_nw04/helpdata/en/96/f04142099eb76be10000000a155106/content.htm

Nice....

In the editors there is no change, but when opening the file in Word it asks now how to convert the file content

(proposing UTF-8) and Word recognizes mutual vowels.

But there seems to be a side effect....

Following the second link, PI recognizes an error.

This is the error message.

MP: exception caught with message Null as XI message received (PrincipalData in ModulData is null)

Adapter Framework caught exception: Null as XI message received (PrincipalData in ModulData is null)

Delivering the message to the application using connection Mail_http://sap.com/xi/XI/System failed, due to: com.sap.engine.interfaces.messaging.api.exception.MessagingException: java.lang.Exception: Null as XI message received (PrincipalData in ModulData is null).

But the message is sent to the mail recipient which could be ok if PI would not repeat the mail sending now for several times.

So we will receive not one but a number of mails.

So we removed the modul recommended in this help link from the channel.

Result: Behaviour in Word changed now to the described one. But the errors are no longer coming up in channel monitoring incl. message send repetition. So this is a first success. But the partner wants to process the files first with one of the named editors. So we are looking for another solution now to fix the last issue!

Your ideas are really welcome!

Best regards

Dirk

[RaghuVamseedhar · Accepted solution]

Hi Meinhard,

In the UDF instead of using u201C\r\nu201D, please try

1.	System. getProperty(u201Cline.separatoru201D) OR
2.	u201C\\r\\nu201D OR
3.	u201C\\\\r\\\\nu201D

FYI, In Window -- CRLF, in Unix -- LF, in Mac -- CR. Note, System.getProperty(u201Cline.separatoru201D) will give new line character of OS (on which PI is installed).

Regards,

Raghu_Vamsee

[Former Member · Accepted solution]

Hi Raghu_Vamsee

Thank you for your answer.

Unfortunately this is not working here for any of your points.

So there are no changes for 1. (only a "LF" per line shown in notepad+)

but \r\n is now added as text with points 2 and 3.

But I will keep this in mind for the next time!

Thank you!

Dirk

[former_member193466 · Accepted solution]

Hi Dirk,

So this got resolved? if so can you please let me know as I am also in the same situation of adding /r/n using UDF but only LF is coming.

Thanks

VR

[Former Member]

Hi,

as I found this in wikipedia:

Another common problem is the use of '\n' when communicating using an Internet protocol that mandates the use of ASCII CR+LF for ending lines. Writing '\n' to a text mode stream works correctly on Windows systems, but produces only LF on Unix, and something completely different on more exotic systems. Using "\r\n" in binary mode is slightly better, as it works on many ASCII-compatible systems, but still fails in the general case. One approach is to use binary mode and specify the numeric values of the control sequence directly, "\x0D\x0A".

Back to my issue:

In the UDF I am adding "\r\n" but only the "\n" seems to survive!

In Mapping test line feeds are available and the lines are shown as expected.

Using Notepad ++ to open the created txt file from the mail shows that LF is in the file at each end of line but CR is missing.

CR is only at the end of the last line in the file and is not from the UDF that creates the mail or the UDF that creates the attachment lines. Seems that this is added somewhere else behind the mapping.

This is what I found in galileo computing

(http://www.galileocomputing.de/glossar/gp/anzeige-11241/FirstLetter-Z, SORRY, only available in german language!):

In Parsing of XML-Documents the XML-Parser changes the end of line delimiter internally in general to a simple line feed (LF, #0A) as usual in UNIX. ..... In Windows this could result in problems with readability of source texts (e.g. in Notepad) which can be solved by choosing the right editor.

My target application is on Windows and not able to "choose" the right editor (PI system is on windoes OS too) !

But Im wondering where the CR at the end of the text comes from when all the \r\n will be replaced with \n as described.

Ideas are really welcome!

Best regards

Dirk

Edited by: Meinhard Dirk on May 31, 2011 2:45 PM