on 12-02-2011 5:16 AM
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
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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
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
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
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
> 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.
Try to use XSLT mapping to remove the special characters.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
88 | |
23 | |
11 | |
9 | |
8 | |
5 | |
5 | |
5 | |
5 | |
4 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.