Saturday, November 17, 2012

Manual/Automatic(NENU) Roll back to reset batches left in running or aborted status

Certain errors can prevent a task from completing successfully. The batch or batches affected may be left in running or aborted status. By design such batches require intervention before they can advance in the workflow. A privileged operator can manually reset them, or NENU can be configured to automatically reset them on a schedule.
This document explains general roll back scenarios and procedures but it is not a substitute for procedures and instructions which


In the course of processing a batch of documents, Taskmaster may encounter internal or external errors. If the software is unable to continue, or fails to update the batch status in the Engine database for any reason, the affected batch will remain in running status. If the error is not recoverable or if data integrity could be compromised by continued operation, the batch will be set to aborted status. In either case, the batch will not advance until a human operator or an automated process resets or "rolls back" the batch.

Basic manual roll back procedure

The simplest way to roll back a batch is to set its status to Pending. An operator holding Job Monitor and Status change/rollback privileges can perform this in the Job Monitor. In Taskmaster Web click on the Batch ID (in the Batch column). In the resulting dialog, change the Status to pending. In most cases this is sufficient and the batch will be picked up and processed by the task that previously failed. If the error condition has been resolved the batch will advance in the workflow, if not it may be left running or aborted again.

How to tell if a batch in running status is taking a long time, or is actually stuck

Before resetting a batch from running to pending status, check that the batch is actually stuck as opposed to simply taking a long time to complete the task. The simplest way to approach this is to estimate the longest time any batch takes to complete this task (you can factor in the size of the batch), and add 50%. If the task is taking longer than that it is probably stuck. To increase your confidence you could 1) check system logs, 2) for an interactive task you could check the operator or workstation for recent activity, or 3) for a background process you could check logs and system activity on the workstation that was last processing the batch.

Advanced roll back scenarios and procedures

If the task which failed cannot be safely run twice in a row, some additional steps are required.

Before rolling back batches in a production environment you should confirm that the task involved is safe for rollback, and/or follow roll back instructions for your specific application.

For example if a batch creation task (Vscan, email input, fax input, etc.) fails after some images have already been ingested, a person or a process must ensure that those images are not lost. It may be necessary to re-insert those images into the input stream before rolling the batch back.

Tasks that perform file format conversion, image processing, or other one-way operations can typically be rolled back, but in some cases the Page file must be reset to its previous value. If image processing includes operations such as erosion, dilation, or unconditional rotation, the original image files must be restored.

Export tasks or tasks that modify external data are only safe for rollback if they explicitly keep track of each external transaction, and prevent re-execution of those transactions when the task runs more than once on the same batch. All of the IBM repository connectors include this feature and thus are safe for rollback.

In some cases it may not be safe or practical to roll a batch back in the current task, but it is safe to roll it back to its initial state after batch creation, or to some intermediate state. In this situation, the files in the batch should be restored to the desired state, the Task ID reset to the desired task for processing, and the Status set to Pending.

Automated roll back with NENU

In any of the above scenarios, the roll back procedures that can be performed manually can also be automated. The NENU utility and the is designed for this purpose. NENU can be configured to run on a schedule, or NENU rules can be run continuously via a NENU task configured in Rulerunner Server. NENU actions suitable for roll back rulesets include QuerySetStatus, QuerySetTaskID, QuerySetAge, ProcessChangeBatchStatus and ProcessRunQuery, For advanced roll back scenarios, FileIO actions may also be useful. Documentation for NENU can be found in the Taskmaster InfoCenter. NENU actions are documented in Datacap Studio action help.

No comments:

Post a Comment