Restructure batches

Batch restructuring enables changes to be applied to the batch structure via script using the methods and functions of the Batch object. It is allowed in Batch_Open, Batch_Close events and additionally if folders are enabled in the RootFolder_DoFoldering event.

Important Batch restructuring scripts that physically change a document are not supported for PDF documents. This means that you cannot delete or move pages, split a PDF, or merge two PDF documents using scripting. If a script attempts to physically change a PDF document, a runtime exception is thrown explaining that batch restructuring is not supported for that document. The batch is then sent to Kofax Capture Quality Control for further processing.

Though rotating a page is also considered as a batch restructuring script this can be applied for a PDF document. In general, the result of the rotation of a PDF page is never stored on disk due to the fact that a PDF document is read-only. Instead, the result is stored within the XDocument.

Applying these methods causes a script error when executing them in other events (for example, during document processing). The batch events are implemented in the project script and can be tested during design time using the Test Runtime Script Events window. The RootFolder_DoFoldering is placed in the root folder script and can be tested by calling Perform Auto-Foldering from the Test Documents pane.

During batch restructuring events it is best practice to not use any page CSS XValues as the corresponding page index for the page CSS cannot be synchronized while the event is processing. If needed, you can store this information separately so that you can to ensure that the value is correct.

Batch restructuring has impacts on the states of the involved objects. Initially, all these operations switch the state of the involved objects to invalid. For example, using the Batch.DeleteDocument method makes the root XFolder invalid. This can be ignored if the batch is no more showing up in any module. By default, the validation of all changed objects is executed again to care for the consistency of the states. If these are expensive operations and if they are not needed this can be suppressed by setting the property Project.ValidateAfterBatchRestructuring to FALSE before leaving the chosen event in that batch restructuring methods are applied.

Important When using Thin Client Validation, the best practice is to set the Project.ValidateAfterBatchRestructuring property to TRUE.

If batch restructuring is applied in the Batch_Open event of server processing the defined validation rules are applied by the following processing anyway, so in this case it makes sense to avoid the validation. If it is applied at the end of server processing the validation has to be re-executed again to prepare the batch correctly for following validation steps. The same is true if batch restructuring is applied in one of the following Server workflow steps.

Important If applying batch restructuring at a later point than server processing you have to care for not doing operations that lead to object states that are not valid for the current workflow step.

In any case, you have to be aware that when applying batch restructuring in the user interactive modules the opening or the closing of a batch may be slowed down.

Note Applying the restructuring functionality does not fire the events related to the similar actions of batch editing.