I am using the FF Schema and convertToString service to generate the EDI STs. Some of the segments are getting generated with unnecessary field delimiters. I am not sure if it is a bug as this behaviour occurs for only some segements.
For eg “}” is the segment delimiter and “~” is the field delimiter and the output of the convertToString service is as follows :
In the above REF segment, ‘~’ delimiter is coming at the end though the field REF03 and REF04 are optional and I dont have it in my EDI record that gets passed to ‘convertToString’ service. Any idea why the output gets generated with two “~” at the end. Is it a bug ?
I guess the REF03 is getting a null map value that might be the reason its putting the (~~)shown in your REF segment at the end,So,Pls check the 816 Values in the pipeline before you are mapping to convertToString service.
I did check the REF03 and REF04 fields. Both of them are null and they dont even exist within the EDI Idata record. btw, they are optional and hence should not try to generate field delimiters if they dont exist in the EDI Idata record. So, I dont know what causes them to create these delimiters.
I think this is the new behaviour in 6.0.1 In 4.6 the extra Element delimiters were not present but I notice them in 6.0.1 they are now present. If I remember correctly EDI Translators do the same thing so I do not expect any problems with it.
yes,according to v4.6 its not happening(no extra delimiters) and works fine…regarding in 6.01 i am not sure…since we are in the design phase for implementing in that…but good to know this nature before…
I’m facing a problem regarding this issue … I’m defining no segment-delimiters … neither in the template nor as parameter to convertToString, but even this way, the output string includes a LF character in the end of the line.
Does anyone knows what causes this behavior?
I’m using IS 4.6 …
This is curious … If I open the result string in notepad, it shows a character represented by a square, but if I open it in wordpad I see a new line for each segment … windows’ stuff!
Unfortunately, the app that will read the flat file, thinks (or don’t think :^) … ) like notepad and waits for a cr/lf in the end of the line.
Back to the odd question, why wM puts a LF if I’m not defining any segment delimiter in any place?
character represented by a square indicates spaces in the file (in notepad).You can check this Hexa values from ultra-edit tool.
LF problem-i guess your template might be creating that new line and LF delimiters,Can you pls check the flatfile you are using…since convertToString default delimiters uses differently.
The character you see represented by the square is the newline (LF) character and not a space. Depending on the what you are using to view the file you will see a newline or the viewers representation of the newline character. Ultra-EDit, Textpad will get you the proper viewing where as Notepad will not.
in 4.6 wm will always end every record (segment delimiter) with a hex 10 newline character. There is no way around it. Even if you leave it out of the template or place another value in there it will always be hex 10.
In other words all records will be separated by a LF.
If wm exists on one platform (say UNIX) and you app on another (say WIN) and you’re FTPing the files back and forth add the ASCII command to the FTP script to get rid of LF translation problem. UNIX expects a hex 10/15 (CR/LF) where as Windows expects a hex 10 (LF) (or the otherway around) The ASCII command in the FTP script translates between them.
Hope I haven’t gone off on the wrong tangent.
Regarding 4.6 always placing a 0x0a at the end of every segment, that’s not the behavior I’ve seen. We’ve been able to use any segment delimiter we want and have not experienced “forced” LF delimiters. The default segment delimiter is LF. I’ve never successfully used delimiters specified in a template (only used custom templates a couple of times) so don’t know if there might be a bug or if it just doesn’t use delimiters from a template properly when creating output. Maybe delims in a template are for reading use only?
Passing delimiters to convertToString and to the EDI enveloping services has always done the right thing for the EDI projects I’ve worked on. I did a flat-file project to generate a flat-file but didn’t need to use a template–the EDI module can create a flat-file without a template in some cases. In this case, the delimiters were passed to convertToString and they were placed properly in the file.
UNIX normally uses 0x0a (LF) for EOL
Windows normally uses 0x0d 0x0a (CR/LF) for EOL
Mac normally uses 0x0d (CR) for EOL
As Chris points out, if files are FTP’d around and you want to keep CRs and LFs untouched, you’ll want to use binary mode.
Notepad (pre-XP) only understands CR/LF EOL. Stand-alone CR or LF appear as non-printable chars (usually an empty white box) as do other control characters. Wordpad understands multiple types of EOL markers, as does the aforementioned TextPad.
We just ran into nasty UltraEdit behavior–it massages end-of-line (EOL) markers to normalize to CR/LF pair. So a single CR or LF is changed to CR/LF. LF/CR is changed to CR/LF. CR/CR/LF is changed to CR/LF. Has anyone else seen this UltraEdit behavior? Is there a way to turn it off?
In UltraEdit, I try to always remember to use the menu FILE_CONVERSIONS DOS to UNIX or UNIX to DOS to handle the conversions. Since I work mostly on Windows to UNIX, it removes the ^M from the end of each line.
Rob, yes my comments are directed toward the templates and not convertToString
In using the templates for flat files in 4.6 the docs specifying 10 (hex) as the segment delimiter. No matter what value you place there it will always be the hex 10. This drove me crazy last year and tech support confirmed it.
The behaviour is different if specifying the delimiters in convertToString where you can specify alternate delimiters.
Thanks for the useful tips … Since I need to deliver this doc to another server I’ll try to use the FTP (ASCII mode) to solve that issue … I hope it works!
I think I learned quite a bit about the various forms of the end of line characters in different systems. Thanks for all the info.
Coming to the original post of mine, it looks like 6.0.1 is having a bug and generating these extra delimiters when I call convertToString as people using 4.6 dont experience this behaviour. Again, I think these delimiters should not impact when run through various EDI translators.
Hi I am using WM 4.6 with the EDI adapter package. When I use the convertToString service for some reason a ‘:’ is being placed within the data string. I am not using a template, instead I am providing a namespace record of my structure alonq with the segment (~) and field (*) delimiters. I guess I am doing something wrong but I am not sure what. My record is defined like the x124010 997 (ISA,GS,ST,AK1,AK2,AK5,AK9,SE,GE,IEA) with the AK2 and AK5 segments as record lists.
Any help will be greatly appreciated.
Thanks
That looks like the default subfield delimiter. Just checking to see if you defined any subfield delimiter in the service convertToString. If u can post the generated EDI data, we may be able to help you identify the problem.