cancel
Showing results for 
Search instead for 
Did you mean: 

Field Containg embedded line breaks

Former Member
0 Kudos

Hi Experts,

I am doing FCC in sender File adapter. My field separator is "I" and Record separator is "\n".

In my .txt input file, one of field contains embedded line breaks and Adapter is taking that break as end of that record.

Without changing the file format & without using custom adapter module, how this problem can be resolved?

Thanks

Accepted Solutions (1)

Accepted Solutions (1)

Former Member
0 Kudos

Hi,

in "endSeparator" do not use '\n', but it's hexadecimal value '0x0A' (including simple quote).

If that does not works try with '0x0D''0x0A'. eventually try with 'nl'.

by this way the '\n' of end of line should be interpreted as a end of line (of course), and your '\n' in the field should be interpreted a string character. should be...

CR (0x0D) = CarriageReturn

LF (0x0A) = LineFeed

if previous solution does works, try with options "enclosureSign".

[http://help.sap.com/saphelp_nwpi711/helpdata/en/44/6713ec3f914ddee10000000a1553f7/content.htm]

mickael

Former Member
0 Kudos

Hello,

I tried with '0x0A' as endseparator. But In my .txt input file, one of field contains embedded line breaks (CR LF) so adapter is taking that break (LF) as end of that record omitting the remaing fields of that record. And eventually creating wrong xml.

Former Member
0 Kudos

My input file example

Record 1: ABC|DEFG| 123

Record2: XYZ|vbtttii|45666

Record3: vfg|ABFV

BYUHJ|79999

Record4: ADX|Sassa|45871

Former Member
0 Kudos

Hi Arimdam,

Which is strange, it is to have CRLF at the middle of line. I beleived the \n could be interpreted as a string charachter and not like the '\n' of end of line...

so when you open your file with Notepad++ (for instance) and use button "P : show all characters", do you see string character '\n' or a CRLF ? coz if it's a CRLF, according to me it's perhaps an issue from your source application which created this file. exm: myblabla...\n my next blabla CRLF

regards.

Mickael

Former Member
0 Kudos

Hi Mickael,

Indeed we have CRLF at the middle of line, I checked in notepad++.

Source application is not generating wrong file. Actually in the file, there is a field called Description, it is populated by end user in Source system. When End user is using Enter button while populating the description, one CRLF is embedded in the Description field. So, when PI is converting the file to XML taking that CRLF as end of one record and omitting the other fields on that record.

Is there any other solution to solve the issue?

Thanks,

Arindam

anupam_ghosh2
Active Contributor
0 Kudos

Hi Arindam,

could you please kindly provide the following information

1. sample source file you are receiving, along with field names. You have provided one sample in earlier post.

But it contains the word "record1","record2" etc. Are those words really part of file or you have added to explain the problem.

2. XML structure you want after FCC.

3. Version of PI you are working.

Java mapping can solve this problem easily without need of FCC. Thus after mapping you can get the proper XML as required.

Email me the source sample, and target XML if possible.

Regards

Anupam

Former Member
0 Kudos

hi Arindam,

I beleived you had a \n (string) in middle of line, but with a CRLF in the middle of line... Heu... no, I don't know how we can manage that (and enclosureSign will not work). And I think is impossible.

For me, you have a misbehaviour in your source system, because in a field (description), they do not put a field value but in fact a table (several lines of this description). So for me, that's a conceptual error in their side !

My suggest is:

1. To modify the source program of your partner application, in order to change the CRLF used in this description by a specific NewLineSeparator like #@#. by this way, they produce a long description view in a field:

exm: description = myblablaOf1stLine#@#my2ndLine#@#my3rdLine, for the 3 lines of description:

myblablaOf1stLine

my2ndLine

my3rdLine

2. in PI adapter, this NewLineSeparator like #@# will be interpreted as all other characters... so no issue.

3. in ECC, you will used this NewLineSeparator like #@#, to recreate the differents lines of this description, in SAP description.

Or you do this split in your PI mapping if your ECC target is an idoc with long description (so several "line" segments).

Regards.

Mickael

stefan_grube
Active Contributor
0 Kudos

> When End user is using Enter button while populating the description, one CRLF is embedded in the Description field. So, when PI is converting the file to XML taking that CRLF as end of one record and omitting the other fields on that record.

This is a bug and has to be fixed at sender application.

It does not make any sense at all to have a line break within a line.

A line break is a line break.

Former Member
0 Kudos

Hi Mickael/Stefan,

Thanks for your input. We are going to write one script to remove the CRLF from a middle of Record, before it enters in PI.

Regards,

Arindam

Answers (1)

Answers (1)

Former Member
0 Kudos

Try to use XSLT mapping to remove the special characters.

Former Member
0 Kudos

Hello Sekhar,

We need to solve the issue before mapping starts. I sthere any way to solve the problem in FCC?

Thanks,

Arindam

Former Member
0 Kudos

If you use the XSLT mapping , the special characters will be removed before your mapping starts. the XSLT mapping should be called in the operation mapping before message mapping starts.

Former Member
0 Kudos

Anyway I have to use FCC in sender commchanel first..And it will create wrong xml structure, assuming "\n" in text as endseparator.

So, after XSLT mapping will not help. Is anyway we can resolve the issue in adapter?