Adobe have two products for dealing with PDF files:
- Adobe Acrobat – mainly for creating new PDF files, in many different ways.
- Adobe Reader – mainly for reading existing PDF files. Can also be used to fill in forms. Reader is free.
There are some additional limitations in Reader. In particular, when you fill in a form, there are several things that you can ONLY do if the form is opened in Acrobat, and will not work in Reader. These include:
- Saving a copy of the form with the form data embedded in it. (This is considered to be creating a “new” form, which can only be done in Acrobat.)
- Submitting the form as PDF. (Again, this is considered to be creating a new PDF.) Submitting as XML is always possible in both Reader and Acrobat.
- Digitally signing the form. (Again, this is considered to be creating a new version of the form.)
- Adding comments or annotations. (Ditto.)
- Invoking web services directly from the form.
So what do you do if you’ve created a PDF Form, and you want to publish it on your web site, and want your users to be able to do any of the above?
Enter Reader Extensions! Tadaaah!
Reader Extensions allows you to apply a special “tag” to a PDF document. When that document is opened in Reader, all the features listed above will miraculously be available (just for that one document).
There are two ways to apply Reader Extensions to your document:
- Purchase a Reader Extensions certificate for your document from Adobe (<plug>through one of Adobe’s authorized partners, such as Avoka </plug>) You will need to install Adobe LiveCycle on one of your servers to actually apply the certificate to your document – but once the certificate has been applied, you don’t need to use the server any more. (Although you do get LiveCycle Foundation with Reader Extensions – so you have a server with a whole lot of really useful features.)
- Use the limited-use, cut-down version of Reader Extensions available in Acrobat. This only enables a subset of the capabilites above, and is limited to a maximum of 500 recipients. In Acrobat, use Forms/Distribute Form…
For more information about Reader Extensions, see:
If you’re interesting in more information, or purchasing Reader Extensions, please email sales-at-avoka.com
When you put a Submit button on a form, you can select either XML or PDF format (as well as some others that we’ll ignore for now.)
- XML format contains only the data from your form, in XML format.
- PDF format contains a copy of the form being filled in, as a PDF file.
Submitting as XML always works. However, submitting as PDF may or may not work. Here’s what happens:
- If you open the form in Acrobat, it will submit correctly as PDF.
- If you open the form in Reader, it will silently fail when you try to submit. (There will be no warning or error messages – it just doesn’t appear to work. This will not impress your customers 🙂 )
The reason for this is that only Acrobat can create a “new” PDF file; Reader is only for reading existing files. Since you’ve typed new information into the fields on your form, submitting as PDF would effectively create a “new” PDF file and is not allowed in Reader.
You have a number of options for resolving this problem:
- Ensure that everyone filling the form has Acrobat rather than Reader. (Difficult to do if this is a public form.)
- Buy an Adobe product called LiveCycle Reader Extensions for your form – this will allow you to “extend” the capabilities of Reader to allow it to send the completed form as PDF.
- If there are fewer than 500 recipients of your form, there is a limited version of Reader Extensions built into Acrobat. You simply need to convert the form after saving it. Open it in Acrobat, use Forms/Distribute… and select Save for later.
- Change from PDF submission to XML. You will either need to:
- Teach the recipient of the XML how to import the XML data back into a blank copy of the form. Open the original blank form in Acrobat, select Forms/Manage Form Data…/Import Data…
- Use Adobe LiveCycle on the server (LiveCycle Forms or LiveCycle Output is the product you’ll need) to merge the XML data back into the original blank PDF template.
For more details on Reader Extensions, check this out:
“What is Reader Extensions?”
If you’d like any further information about Reader Extensions or anything else in this blog post, please contact info-at-avoka.com
LiveCycle Process Management has a number of built-in facilities for managing reminders, escalations, and deadlines for User Tasks. But sometimes the built-in features may be a little limited.
For example, you may want one of the following features:
- In the first reminder, send it directly to the assigned user. But for the second reminder, cc that user’s manager. For the third reminder, send it to the user, their manager, and the CEO.
- Have different text in the first, second and third reminder emails, with each email getting increasingly abusive.
- Send the first reminder after 5 days, the second reminder after 2 days, the third reminder after 1 day, and subsequent reminders every 10 minutes after that.
- You may need to check the status of an external system or database prior to deadlining or escalating the task. For example, the project relating to the task may have been cancelled by the customer, and the task is no longer relevant – in this case, we’d like to simply terminate the entire process.
These type of escalations cannot be accommodated by the built-in features, and require some sneaky techniques.
Calling a Sub-process to Handle Custom Task Escalation
One of the possible ways to solve the above scenario is to call a sub-process to handle the task after the task assignment. We need to actually kick off the sub-process before we actually allocate the task, because once we hit the User step, the process won’t continue till after the step has been completed.
The idea is:
- call a sub-process before just before the user step asynchronously (in other words, without waiting for it to complete)
- pass the parent process id to the sub-process (so that the sub-process can reference the parent process’s tasks)
- the first step of the sub-process set to wait for a minute or two, to ensure that the parent process has time to allocate the task to the user.
- the sub-process will then have sufficient information to look-up for the active task that would have been assigned
With the task information, the sub-process can be configured according to your business needs to do custom task reminder notifications, escalations, deadlines, and can even terminate the parent process if necessary.
This provides an extremely simple way of achieving almost unlimited functionality in the way that reminders, escalations and deadlines are handled. It also allows you to handle escalations for multiple User steps in a single place – changing the sub-process will change the way it’s handled for all User steps.
This approach involves some of the custom components Avoka has developed to perform those task operations outside of the User step.
Please refer to the link below for the full article of this approach to the described scenario, containing the example process and sample LCA file for download: