Clovertech

base64 pdf decoding issues

› Clovertech Forums › Read Only Archives › Cloverleaf › Cloverleaf › base64 pdf decoding issues

  • Creator
    Topic
  • May 19, 2011 at 8:36 pm #52493
    Jim Lohe
    Participant

      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%âã

    • Creator
      Topic
    Viewing 4 reply threads
    • Author
      Replies
      • May 19, 2011 at 9:08 pm #74458
        James Cobane
        Participant

          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

        • May 20, 2011 at 5:55 pm #74459
          Jim Lohe
          Participant

            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

          • May 20, 2011 at 7:18 pm #74460
            Scott Folley
            Participant

              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?

            • May 23, 2011 at 4:27 pm #74461
              Jim Lohe
              Participant

                Scott Folley wrote:

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

              • May 23, 2011 at 9:12 pm #74462
                Scott Folley
                Participant

                  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
              Viewing 4 reply threads
              • The forum ‘Cloverleaf’ is closed to new topics and replies.