Kofax Capture – Customisation beyond standard features

Kofax Capture in a nutshell
With Kofax Capture you are able to process all kinds of business-related documents and to collect metadata for these documents before releasing them to a backend system. Kofax Capture is a comprehensive platform for input management. It delivers originally functions for barcode recognition, OCR or ICR, creating pdf files for digital preservation, collecting and validating the documents’ metadata and at least for content delivery in backend systems of well-known manufacturers (Microsoft SharePoint, IBM Content Manager) by way of so called export connectors.
The work is done step by step by so called queues in a predefined sequence. Hereby everything follows the IPO principle. The sequence always starts with the scan module and ends with the export of the collected data (metadata and image files).

But not all possible modules make sense for a single use case. If the customer doesn’t want to archive pdf files, the module for pdf creation will not be considered.

Not every feature is out of the box
That is why we always are confronted with use cases that can be solved out of the box but also with complex use cases that can’t be solved out of the box.

What can you do if the standard features are not sufficient for the use case? What can you do if the export has to release metadata in a proprietary format? How can you realise an own queue fitting your needs e.g. the creation of electronic signatures? How can you realise cross field validation, something that is difficult with the standard validation module? What can you do if the customer wants to make an OCR in the scan module directly after scanning the documents and make a validation of the recognised values also in the scan module?

All these questions arose and could be solved satisfactorily for the customer, as Kofax Capture provides several API libraries and customisations.

A summary of customisations

Kofax Capture provides several kinds of customisation whereupon only the most common are listed:

• Creating scripts for recognition and validation (SBL or VB.NET)
• Creating own OCX panels for the modules administration, scan, quality control, validation and verification
• Creating an own queue, a so called custom module
• Creating a workflow agent, which can change the predefined sequence of queues programmatically
• Creating an own export connector

Therefore Kofax as manufacturer provides several API libraries:

Creating validation scripts (SBL or VB.NET)
In a document class of a batch class you define the metadata of your documents. Each index field is represented by a form type or data type in Kofax Capture e.g. an insurance policy number which is numeric and has a length of eight digits. In the validation module the input of data for this field would be checked by Kofax Capture out of the box only by means of the defined form type. But of course that is insufficient.
That is why you can create validation scripts with your own validation rules. Primarily you had to use SBL (Softbridge Basic language) a kind of Visual Basic 6 but since Kofax Capture 8 you are free to use VB.NET as well if an appropriate application development is installed.

SBL is very old and you can see that in the editor, which often has problems with the clipboard. You can do quite a lot with SBL and you can also call .NET Assemblies (late binding) by using COM technology but you will seek some functions in vain e.g. the replace function.
VB.NET scripts are more comfortable to develop because you use the IDE of Visual Studio which you maybe know from your daily work and because of .NET you can draw on plentiful resources in the .NET libraries. And it is very comfortable to debug code of a .NET script.

Creating an OCX panel
On the technical view an OCX panel is an OLE custom control that is embedded during runtime in the modules administration, scan, quality control, validation or verification. To realise complex functional dependencies between several fields you should design a panel for validation that is responsible for the correct collection and validation of the metadata.

For many customers we have developed a panel for the scan module that is called batch generator. Currently in input management systems with many clients or special requirements concerning the naming of a batch it is possible to wrap these technical demands in a batch generator. The scan operator creates the batches over a simplified GUI.

The above mentioned feature for an OCR after scanning and the need for indexing the recognised metadata in the scan module was realised with a batch generator, too. As we could not use the Kofax OCR engine we had to program against a third party library.

Creating a custom module
A custom module represents the extension with the farthest freedom of design in the Kofax Capture system. Hence you have to take care of everything like opening or closing a batch, navigating through the documents, displaying of image files in an own viewer component or just the logging of information. Therefore a custom module is recognised as the supreme discipline. A custom module for validating documents is an interesting option for the customer concerning the licences in Kofax Capture because there are no licenses needed for a custom module compared to validation scripts in SBL or VB.NET.

GUI of a custom module
In this case we realised the existence of a logical level that combines more documents. The metadata of the higher logical level is inherited to all lower documents in that level.
An error is only notified by error providers and not by showing a message box so that the flow of work is not intercepted. The error provider shows only an exclamation mark on a red background beside the control containing an error.

GUI of the viewer component
The viewer offers functions like thumbnail viewing, adjusting the size of the displayed image, a magnifier feature, OCR and sending the recognised value to the custom module and a print function. All these features were customised for the customers’ special requirements.

Creating a workflow agent
A workflow agent is an assembly that is called by the Kofax Capture System after a queue ends and before the next queue is called. Within this unit the workflow agent has access to the batch, its documents and metadata. Moreover you now where in the Kofax Capture workflow you reside because you know the name of the queue you come from and the next queue that will be called after. Even if a workflow agent is not very common there are use cases for it.

Black box processing
Let’s assume that you are scanning documents of the same printed form and you want to make an OCR in an area to read an insurance policy number. After the batch has been processed by the recognition server (module for the OCR in Kofax Capture) only the not validated documents must be shown for validation. But if all insurance policy numbers were recognised correctly and the recognised values could be validated, the batch goes directly to the export module and leapfrogs the validation module. The workflow agent starts its work after the queue recognition server. It starts to validate the recognised value for each document against a database or web service. If the value is correct the document is indicated as indexed. If all documents in the batch are validated and indicated as indexed, the batch can be queued directly to the export module.

Changing of user profiles
If you use Kofax Capture profiles for assigning batches to several user groups (VIP documents) then the workflow agent can be used to change the user profile if a special constellation in the metadata appears. In that case the batch can only be accessed by users that belong to that group.

Creating an export connector
There are, as mentioned above, several connectors you can use out of the box. But if you need to create an xml file with a special content then you can program an export connector on your own.
The connector is an assembly with two entry points for setup via the administration module and for releasing the documents and its metadata during export.
In the setup you define e.g. at design time for your batch class at least the name of the xml file and the destination where it has to be stored during export.