Building workflows by connecting the dots with Datalogics PDF Java Toolkit

Back in April of 2016 with version 6.1.1 of our PDF Java Toolkit, we released a new set of samples that was significantly trimmed down from what we had previously been shipping. There are a number of reasons why we did this – better organization, less duplication, demonstration of best practices instead of proof of a feature working (read about it in the blog post that announced this).  However,  the most important reason was that we wanted to provide samples that could be extended to produce longer workflows. We wanted our users to be able to reuse the samples to accomplish some of the common actions that are done with PDF (print, digitally sign, fill a form, or extract text) and at the same time, use the samples in conjunction with one another to meet real business needs. I was recently asked about how users of the samples can build longer workflows by connecting one sample to the next and we came up with two similar yet slightly different ways. While there is more work to do when embedding these in your final product, linking them together can be used as the proof source for insuring the capabilities of PDF Java Toolkit meet your needs.  Let’s take a look at how to accomplish more by working smarter and reusing what already exists.

Chaining samples together by calling their main methods

The simplest and most straight forward way to chain multiple samples together with our PDF Java Toolkit is to simply write a new sample and call the main methods of the samples you want to chain together with the appropriate arguments. Below is a short sample that chains together the MakeWhiteFangBook and TextExtract samples to create a PDF and then extract the text from it. This may seem like an odd combination, however, it is useful, for example, if you want to make sure that PDFs you are creating from a mass of text can have that same text extracted correctly. The code is really short to chain these two samples together, you just have to know what arguments to pass and then run the application. As you can see in the two samples chained together below you can make a larger new workflow while reusing the existing code that we provide as part of the product.

public class ChainSamplesTogether {

    public static final String WHITE_FANG_BOOK_PDF =
        "WhiteFangBook.pdf";
    public static final String WHITE_FANG_BOOK_TXT =
        "WhiteFangBook.txt";

    public static void main(final String[] args) throws Exception {
        MakeWhiteFangBook.main(WHITE_FANG_BOOK_PDF);
        TextExtract.main(WHITE_FANG_BOOK_PDF, WHITE_FANG_BOOK_TXT);
    }
}

For the complete sample, take a look at the code in my fork of our samples project on GitHub here. Let’s take a look at a longer more complicated workflow.

Chaining samples together by calling their public non main methods

Alright, the first sample was a little too simple, right? What if you wanted to import some FDF or XFDF data into a form, digitally sign the PDF, and then flatten the form? The code is still short and simple, this time around though we are going to use a few of the public methods that the samples expose instead of just calling their main methods.

public class ChainSamplesTogetherViaMethods {
    public static final String UNFILLED_PDF_FORM = "src/main/resources/com/datalogics/pdf/samples/forms/acroform_fdf.pdf";
    public static final String FILLED_PDF_FORM = "acroform_fdf_filled.pdf";
    public static final String SIGNED_AND_FILLED_PDF_FORM = "acroform_fdf_filled_signed.pdf";
    public static final String FLATTENED_SIGNED_AND_FILLED_PDF_FORM = "acroform_fdf_filled_signed_removed_interactivity.pdf";
    public static final String PDF_FORM_DATA = "src/main/resources/com/datalogics/pdf/samples/forms/acroform_fdf.fdf";

    public static void main(final String[] args) throws MalformedURLException, Exception {
        FillForm.fillPdfForm(IoUtils.createUrlFromPath(UNFILLED_PDF_FORM), IoUtils.createUrlFromPath(PDF_FORM_DATA),
                             FillForm.FDF_FORMAT, IoUtils.createUrlFromPath(FILLED_PDF_FORM));
        SignDocument.signExistingSignatureFields(IoUtils.createUrlFromPath(FILLED_PDF_FORM),
                                                 IoUtils.createUrlFromPath(SIGNED_AND_FILLED_PDF_FORM));
        RemoveInteractivity.removeInteractivity(IoUtils.createUrlFromPath(SIGNED_AND_FILLED_PDF_FORM),
                                                IoUtils.createUrlFromPath(FLATTENED_SIGNED_AND_FILLED_PDF_FORM));
    }
}

Here is a break down of the 3 (yes, 3 lines of code) that it takes to create this workflow :

• This line utilizes the FillForm sample to import FDF data into a PDF form. The arguments that we pass are the URL to the PDF that contains the form we would like to fill, the URL to the FDF data we want to use to fill the PDF form, the form data type, and the URL where the PDF with the filled in form should be written to

FillForm.fillPdfForm(IoUtils.createUrlFromPath(UNFILLED_PDF_FORM), IoUtils.createUrlFromPath(PDF_FORM_DATA), FillForm.FDF_FORMAT, IoUtils.createUrlFromPath(FILLED_PDF_FORM));

• The next line utilizes the SignDocument sample to digitally sign the PDF that we just filled in with our FDF data using our test certificate

SignDocument.signExistingSignatureFields(IoUtils.createUrlFromPath(FILLED_PDF_FORM), IoUtils.createUrlFromPath(SIGNED_AND_FILLED_PDF_FORM));

• Our last line uses the RemoveInteractivity sample to flatten the PDF so that the form is no longer interactive, when viewed in a PDF reading application, making it so no one can alter the data in the form

RemoveInteractivity.removeInteractivity(IoUtils.createUrlFromPath(SIGNED_AND_FILLED_PDF_FORM), IoUtils.createUrlFromPath(FLATTENED_SIGNED_AND_FILLED_PDF_FORM));

With those 3 lines in place, we have now built a more complex workflow by reusing the existing samples. This is a good way to quickly prove out workflows for PDFs using our PDF Java Toolkit, there is a catch though. (For the complete sample, take a look at the code in my fork of our samples project on GitHub here.)

The catch! There is always a catch

You may have noticed in the second example that the arguments being passed into each method call are URLs to the PDFs that we want to operate on and that there is a URL for the input PDF and a URL for the output PDF. The reason to chain samples together is to quickly build a prototype of a workflow, not to process PDFs as efficiently as possible. If you were building this into your product you would most certainly want to be more particular about how you connect the dots of the workflows so that you don’t spend resources on opening or saving the same PDF multiple times. For prototyping though, this is a relatively small price to pay for the ease of use and quickness of trying different combinations out.

Note: Our FillForm sample input file was slightly modified for this demonstration so that the input would have a signature field, the version we ship as part of Datalogics PDF Java Toolkit does not have a signature field. You can get a copy of my slightly modified input file from the branch in my fork of our samples on GitHub here : http://bit.ly/2g7nPXK