carriage return in file creation

I've been making files with processflow (pfi, ipa) for several years now.. up until now, I've been getting by using
for CRLN with no issues - either from vendors or internally. Now I have a file that needs a carriage return only
yet when I use it, no matter what, the flow seems to write CRLN or
. Why is it not just writing CR?

Thank you!

Chris

Find more posts tagged with

Process Automation (IPA) - General Discussions

Accepted answers

All comments

andy

How are you building the string? Is it in a Msg Builder, Assign Node, or explicitly in the the File Access node?

russel-cornelson

I am with Andy, this will depend how you are building the data, an potentially will depend on the Operating System landmark is running on.

Assign Node
var outputData = "Carriage Return Test
"

File Access to write file; with outputData variable as the contents will create:
Carriage Return Test CR

MessageBuilder uses the default for the operating system landmark is running on.

Windows:

Unix/Linux:

I am also not sure why a "carriage return" only would be required; I can see something running on Linux or unix requiring a
but I've never encountered a scenario where someone wants a "
only. If you have a use case can you expand on it? I am opening an enhancement request to allow the Message Builder line separator to be defined on the node ... and want to make sure we handle all scenarios that we need to cover.

chris-mccullough

Thanks guys!
I am using an older recommended style of file creation Russ suggested a couple years ago with the combo of assign node and file access...the count >= filewritecounter, loading a buffer and then writing the buffer out to a file.

In the start node I have a string variable called strRT = "
"
I grab some data using sql, then create a buffer in an assign node Javascript Type that looks like:

buffer = buffer + "somedata" + "|" + <!moredata> + | + "more data" + strRT

Once my counter is reached, the buffer gets appended to the file using file access node and we start over until all records written.

We are running landmark on Windows....and when the file comes out, the result is CRLF instead of the expected CR.

To your point Russ - this is the first time I have seen the need for just
too and I am actually doing something new. We're healthcare and this is an HL7 message going into EPIC. Basically loading employees from GHR into EPIC..so , its still an interface file but HL7 messages need their segments separated by
and then each message separated by
- or at least this is what I have been told.

russel-cornelson

Quick Notes
You should be able to imbed a
into the file; I did not try it with a variable but hard coding the"
into the javascript worked for me yesterday when I tried this. Are you using notepad++ to verify the character added?

Since we made this recommendation we've learned quite a bit about performance an IPA. What we have found is that this technique of periodically clearing out the file is not always needed.
variable = variable + data ...

Can generate alot of memory pressure even when we clear it out. My current/new recommendation is to use an array.
start node, create array variable called "outputData"

In the assign node in your loop
outputData.push("somedata" + "|" + <!moredata> + | + "more data" + strRT);

In an assign node outside loop before file access:
var outputDataString = outputData.join("");

Use outputDataString to write to file. For most situations this runs more efficiently by reducing the amount of work the JVM has to in garbage collection.

unknown

Hi - interestingly, we are also on windows so I tried to reproduce your issue, and I cannot! It is working as expected for me - when I open the output file in Textpad, I only see a carriage return at the end,. I haven't had luck uploading the flow here as any kind of file, but if you want to compare them to perhaps get some additional troubleshooting ideas, I'd be happy to email it to you.,

chris-mccullough

Thank you so much! What type of encoding are you using for the File Access? I am set to UTF-8... I would love to see your flow if you can email me? chrisprocessflow@yopmail.com

Thank you!

unknown

just sent it to you. I am using US-ascii. Let us know if you figure out what is going on!

0_day_wait_from_adjhd_rule.doc

chris-mccullough

Thank you everyone for your help. So, I feel kinda of ****. Having Patti's flow helped as I knew I had a working flow on my hands so I could use it as a base line. Long story short...when you look at the file that is created on the server (which in my case is all that matters) - the characters are correctly being written... even my flow was doing it, which I failed to look at because I had an email node sending me the file....which therein lies the issue. When you take the file attachment from (in my case Outlook) and save it to your pc, or open it directly from the email, windows/outlook is converting the CR to CRLF.... almost as if Outlook or Windows is performing an EOL conversion similar to the Notepad++ feature (EOL conversion).....
I've started researching a little to learn more and see if it's Outlook doing this, or possibly Landmark when it sends the email - one of them is trying to normalize the attachment to the operating system. I need to do some testing but the good news is that the raw file is correct and has been all along! It took Patti's flow to help me realize that it was the emailing part that was causing the issue. If someone wants to verify that they too see the change after the email is sent, that would let me know it's not something else:
https://superuser.com/questions/285735/mail-attachment-eol-end-of-line-problem

unknown

I just tried emailing the file to myself as the last step in my flow and got the same results as you, CRLF at the end of each line.

unknown

I wanted to mention also that we use microsoft ATP Safe Attachments here. If your shop uses it also, it could be that is what is converting the CR to CRLF - to somehow make it more efficient to scan the file...?? Just a guess.

chris-mccullough

Thanks for testing that. Interesting stuff we learn! Take take, be safe and thanks again for your help!

Copyright © 2025 Infor. All rights reserved.