Hi. all. I'm using OWB 220.127.116.11 on Oracle 18.104.22.168.
I have a PL/SQL packaged procedure that creates the text for an email body. The procedure uses an OUT VARCHAR parameter that is bound to a process flow "string" variable, and the email activity in turn has it's message_body parameter bound to this same variable. We use this successfully in a number of process flows. In one of the cases, I'm seeing strange characters being inserted into the email body and don't know where they are coming from. It's always an exclamation point followed by a Windows-style line break (21 0D 0A). To help debug, at the end of my procedure, I wrote the out parameter to a file using UTL_FILE and do not see these characters present. So they must be coming from some process after the procedure ends. It's not always in the same location, but happens around the 2K point in the email body. The email bodies are generally 2K-4K characters of plain text long-- the code makes sure we don't exceed the 4000-character limit.
Has anyone else ever seen an issue like this? Since it's clearly occurring somewhere after or as my procedure passes the out parameter and the email begin generated, I'm at a loss in trying to debug this further.
I have eliminated everything except the assign and email activities. I created a new PF with a variable for the email body, an assign activity that populates that variable with a 3000-character string of repeating "1234567890" and an email activity. I sent the email to two different servers, and both arrived with the strange string, actually a "!" followed by a 0D 0A and then another line break a few characters later. I'm going to submit an SR.
I first encountered this a number of years ago generating html-formatted emails via plsql. The characters being inserted are due to line length limits in the SMTP standard and the server(s) transporting the message.
To be safe you need to either limit the line length to < 990 if the message may be transported qmail or sendmail standard ESMTP, and/or the message may need to be encoded (i.e. send the long-line message as a base64 attachment).
Many thanks, Richard. My <cr> string doubled-up to print blank lines was resulting in Outlook automatically removing them, so I altered it to something that solved that but apparently caused this side effect. I just tested CHR(9)||CHR(10) and this solved both issues.