base64 pdf decoding issues

[Jim Lohe]

Hello

I am trying to figure out why, when we decode a pdf sent embedded into HL7 OBX segments, about 2 percent of the time we end up with blank pages in the pdf.     The mysterious thing is that when the same message is replayed, the PDF gets built perfectly.      The only wildcard in the process (that I can see) is the base64 decoding.      If it were a message based problem, it would seem like it should be consistent every time the message is played through.    

Key logic from tclproc:

# encodedData is the encoded pdf stitched together from multiple OBX’s

set base64DecodeFile [::base64::decode $encodedData]  

set pdfFileHandle [open $pdfFilePath w]      

puts $pdfFileHandle $base64DecodeFile

close $pdfFileHandle

The pdf file created is not EMPTY – it’s there – it just opens up as a PDF with several blank pages.      Ex:

%PDF-1.6^M%âã

Topic

[James Cobane]

Jim,

One thing that you may want to do is ensure that you are handling the output file as ‘binary’ with fconfigure:

  set pdfFileHandle [open $pdfFilePath w]

  fconfigure $pdfFileHandle

[Jim Lohe]

Jim

Thanks for the input.   It sounds like that certainly can’t hurt.    The hard part is that I can’t make it happen in test or production, so it will be hard to know if anything fixes it.   It just happens randomly on it’s own.    

I will update test and see how it goes.    Thanks again.

Jim

[Scott Folley]

Are you using ACK/NAK processing on the receiving thread?  Do you have SMAT turned on?  If the answer to those two questions are yes AND you can resend it from SMAT successfully after it has already errored then that is a real stumper.

James’ suggestion sounds good in theory but it does not make much sense that it is only happening sometimes if the file configuration were wrong.  I think that it would be a good idea to use “puts -nonewline” when you are writing out the file but that doesn’t sound like it will solve your problem either because it sounds “environmental”.  Maybe a variable that is not being cleared out.

Where in the process are you performing the decode?

[Jim Lohe]

Scott Folley wrote:

Are you using ACK/NAK processing on the receiving thread?

[Scott Folley]

I would encourage you to check any instances where you are using an lappend in your procs or in your translate because it sounds like you are getting bad data left in a variable that is causing the message to not be decoded properly.  This is especially true if you are seeing that it always works on the test system because, presumably, you do not have nearly the same opportunity in the test system for a scope conflict on those variables.  I know that we have had instances where variables in the translate that have not been initialized get data from other translates because the translate thread is shared.

[Author]

Replies