Gracefully Handle REST Server Error

Question

I have an application that generates a PDF on the fly (accessed via service/generatePdf).

It returns a HTTP response with content-type="application/pdf" and the outputStream set to the binary contents.

Per business specs, when the user clicks a button we need to open a new window/tab that displays that PDF.

Submitting the form below, that all works beautifully on the Happy Path, where the response is an actual PDF.

<form action="service/generatePdf" method="post" name="PdfForm" target="_blank">

However, what does not work so well is when the PDF can't be generated for whatever reason. For example, let's say that the HTTP response outputStream is empty.

What I want to be able to do is display a nice error message on the first page, and not open the new window/tab.

But there doesn't seem to be any way to do it. Your choices seem to be

• Return a valid PDF, or
• Live with how the browser's PDF plugin handles corrupt files

I've tried jQuery, Ajax, the jQuery Form Plugin , the jQuery Download plugin plugin, and nothing seems to work.

Answer 1

The server should indicate error or success through a HTTP status code (eg 200 = OK, 500 = error). This you can catch in your REST client, with JQuery

$.ajax({
    url: 'service/generatedPDF',
    error: function(jqXHR, textStatus, errorThrown) {
        ... // show error message
    },
).done(function(data) {
    // data contains the PDF
}

It would be better to just create the PDF on the server, put it in a temporary store and send the URL to this PDF in the response. Once the client downloads the file, or after a certain download, the PDF is removed from the store.

In that case you would just open a new window with the URL you received from the server.

If the server provides the PDF in the initial request, you can convert it to a Data URI and open that data URI in a new window.

Answer 2

This is a fairly common requirement. You need to make your REST app a little smarter. It needs to check the result of the LiveCycle PDF generation and, if it wasn't successful, return an HTML response (with a content-type of text/html).

The browser is fairly dumb. It examines the content-type of the incoming response and, based on the content-type, launches the plug-in. It's then up to the plug-in to process the response. The PDF plug-in is also not so bright, it assumes that the incoming data stream is a PDF and if it's empty, it produces an error.

The key here is to send down the right content-type (and content) to the browser, which means checking the PDF result and sending a more appropriate response if the PDF result is a failure.

We often see this in LiveCycle orchestrations too. The temptation is to generate the PDF into a com.adobe.idp.Document object and then return that object directly. This leads to similar problems that you describe. Instead, the better approach is to check the result of the PDF generation. If it is valid , then return that response. If the PDF generation failed, then construct an HTML response in a com.adobe.idp.Document object (with the appropriate text/html content-type) and then return that instead.