5 Replies Latest reply on Sep 27, 2019 7:47 PM by Mr Peabody-Oracle

    Documaker's Processing of Attachments


      The application and set up we use to communicate with Documaker allows for attachments to be added to Documaker developed templates.  Over the last few months we have been diving into our not-so-good processing times and found an interesting piece of information, many of us at my company did not know.  It appears that Documaker is processing the attachments by splitting them up into multiple image files based on number of pages (ex. if an attachment with 30 pages were attached it would create 30 image files) before adding them into the final PDF with the requested template and shipping it back to WIP Edit.  Does any one know if this is the only way Documaker processes attachments, or if there is another, more efficient way for Documaker to process attachments?


      Thank you

        • 1. Re: Documaker's Processing of Attachments
          Mr Peabody-Oracle

          The answer to you question is Yes, this is the way that "attachments" work in Documaker. The handling of TIF, PDF, and Doc (Word documents) is essentially the same - each page is rendered a separate bitmap page in the document. If you look through the forum threads searching for "addmultipage", you would probably find several discussions.

          • 2. Re: Documaker's Processing of Attachments
            Julie Printz

            In our process we have PDFs stored off on a network drive to be attached to Documaker letters at a later time. When these folders get quite full Documaker has a harder time performing the addmultipage bitmap function because it is breaking up the PDF, adding the individual bitmaps back to the already full folder for a short duration and then deleting those bitmaps. In fact, when we've had problems composing a document with these PDFs we sometimes notice that there are some bitmaps left lying around in the folder. We've learned that we need to be disciplined about running regular cleanout processes and that aids in processing time and processing success.

            • 3. Re: Documaker's Processing of Attachments
              Mr Peabody-Oracle

              Perhaps I misunderstood your question. You are saying that you think Documaker physically splits the PDF up first as temporary physical files before inserting them? That is not my understanding. Now, I know there are two different mechanisms that might be used for converting the PDFs. Perhaps only one of them does what you are suggesting. This might be a question to send through actual Support.

              • 4. Re: Documaker's Processing of Attachments

                Our setup is similar to Julie's and I can confirm that it behaves the same.  If the pdf is named BLAH.PDF Documaker will create BLAH-1.jpg, BLAH-2.jpg, BLAH-3.jpg etc, one for each page.  Then it'll consume them and delete the jpgs, adding the attachment to the WIP record.  When the file is sent to Documaker via a network location, as a PropFile_URL, it'll do this conversion in the same network folder.  If we send the file as bytes on the EWPS call itself, as a PropFile_ATTACH, it'll do this in the docserv folder.


                If the transaction errors for some reason while unpacking or consuming the jpgs they will be orphaned in the folder.


                Julie: for the PDFs we do the cleanup in code.  The file is deleted after the attach API call comes back successful.  That option might not work with your application, but for us the only pdfs left in the folder are the ones orphaned by errored transactions so it doesn't fill up very quickly.

                • 5. Re: Documaker's Processing of Attachments
                  Mr Peabody-Oracle

                  Interesting. I did not know that. As I mentioned, there are two methods supported for importing PDFs, so perhaps the other does not do that. On the other hand, the reason there are two methods is because some find one provides a better result than the other. So if you were to switch, there's no guarantee that you would approve of the other. I guess it comes down to evaluation.