LiveCycle, as an piece of Enterprise software, tends to assume that you may want to keep a quantity of data around for posterity. Long-lived processes can cause a lot of disk space bloat, and whilst this is fine for those who wish to archive lots, this may not be ideal when running a lower-spec server.
In this article, I will point out the main areas where data and disk space use can happen, and how to clean up.
1) About Short-Lived and Long-Lived processes
Processes (also known as “workflows”, or “orchestrations”) are created in LiveCycle Workbench. This tool that allows you to create workflows, or processes, organized into Applications; and each process can be either long-lived (“asynchronous”) or short-lived (“synchronous”).
When a short-lived process is invoked, the response is only returned once the whole process has run. For this reason, no short-lived process can have a step which requires human interactions – namely, a Workspace task.
When a long-lived process is invoked, the request returns immediately. The process will run, but you will need to get the result through a different request or action. Long-lived processes do not need to have a human-centric activity in them: you could use a long-lived process to send a document to the server for procesing, without needing to know what status it ended up in.
Note that for any process that stalls, the documents associated will also be kept, ready for recuperation, analysis and debugging.
2) About the Global Document Store
The Global Document Store, also known as “the GDS” is a space on the hard drive or in the database (depending on your configuration in the Core System Configuration) where LiveCycle stores documents during the running of processes, and once long-lived processes are complete.
Note that whilst the GDS stores the files themselves, the references to them that processes need are stored in the database. For this reason, the GDS and the database must NEVER be out of sync. Should that happen, any processes that are running would fail, making data recuperation difficult or even insurmountable.
In short-lived processes, when documents are larger than a certain size, they will be written to the GDS instead of being held in memory. This size is set in the Admin UI as the Document Max Inline Size. When a result document is produced, no mater what its size, it will be written to the GDS. Short lived processes can return the document itself, or a URL to the document. Accessing this URL will cause LiveCycle to lookup the document in the GDS to write it back to the client.
Documents from short-lived processes are removed after their time is passed. The Sweep setting (set in the Admin UI in the Core System Configuration) determines how frequently the GDS is scanned for documents to delete, and its associated Document Disposal Timeout determines how long the document should be kept for. If during a sweep of the GDS any new document is found from a short-lived process, it is marked for expiry by placing a similarly named document in the GDS, with a timestamp indicating the clock time after which the document should be deleted – this clock time is determined by the disposal timeout. Every sweep checks the timestamp, and if the clock time is after the one specified in the timeout, it will be deleted. The URL returned from short-lived processes need these documents for an amount of time, between the time the URL is returned to the user, and the time the user clicks the URL. It is good to set the Document Disposal Timeout to a value between 30s to 120s, depending on the load expected on the server.
Long-lived processes will write required documents to the GDS before assigning them to a human-centric task so that they can be obtained later when the user actually logs on to process them. At the end of the process, the final collaterals are kept in the GDS for posterity and later review if required.
Thus, for long-lived processes, the files are never disposed of. The default behaviour for the GDS then is to constantly grow, if long-lived processes are used. If you do not want this to happen, you must perform regular purges.
3) Purging Jobs
In LiveCycle ES, a command-line purge tool is provided to purge jobs that either completed or were terminated. This exists still in ES2, should you ever need it.
In LiveCycle ES2, the Health Monitor was introduced to offer a graphical UI for performing purges.
In ES2 SP2, a purge scheduler was introduced to automate, at intervals, the purge of jobs.
a) If you are on ES2 SP2
Connect to Admin UI and go to Health Monitor > Job Purge Scheduler
Schedule a One Time Purge for records older than 1 day
b) If you are using ES2 pre-SP2
Connect to Admin UI and go to Health Monitor > Work Manager. Search with the following criteria:
-Category = Job Manager
-Status = Terminated
-Create Time 2 Weeks
-(iterate over time periods)
Delete any terminated processes that are found.
c) If you are on LiveCycle ES
The purge tool requires some knowledge of the contents of the LiveCycle database; for this reason I will not cover this in this article.
You can find most of the required information in the link below, however you would be best advised to operate under the guidance of the Enterprise Support service, if you can.
4) A note on process recordings
I would like to add a special note here concerning process recordings. These can be activated via Workbench by right-clicking on a process or on a process canvas, and selecting Process Recordings > Start Recording
This will record the activity of every time the process is launched, including the contents of LiveCycle variables, branches followed, etc, at EVERY step of the process, for later review in Workbench.
Even processes not started in Workbench will be recorded.
For this reason, process recordings must be activated ONLY for debugging purposes.
Process recordings are heavy, and are not suitable for a production server, both in terms of performance and space used. They can easily be deleted via Workbench through the playback dialog.