Captiva Scripting: what-is and where-to-use

I’ve seen/heard developers talk about Captiva Scripting in confusing ways and given that we have new ways of scripting, I figured it wouldn’t be a bad idea to take a moment to discucss the break down on a  high-level, to help ease the discussion on this subject.

Captiva scripting is essentially used to customize two different behaviors of a process flow:

1) Process Behavior: In customizing the behavior of a process, you have two choices:

Capture Flow Scripting:
This is the traditional scripting that should be familiar to all Captiva developers, where one would be able to customize the standard process flow routines (prepare, finish, error). It is to be kept in mind that these routines are expected to be simple functions, primarily used for exchanging IA values between capture flow steps. As you’d imagine, this type of scripting applies to all batches which are created from the relevant process; however it’s to be kept in mind that it’s triggered on the IA Server. Any changes made to this script would obviously require the process to be recompiled & redeployed for the changes to take effect.

.NET Code Module (if one could call that scripting):
This is a standalone module that could be incorporated as a step into any process. This is by far the most powerful scripting feature available and is typically used to manage critical business logic. This could also be treated as a reusable cookie-cutter library that could be applied to processes across the Organization (you could also build a custom setup-form to pass design time parameters to this library). It’s ability to be a executed independently as its own step in the process, allows it to easily access & integrate into other legacy systems in the Organization. Additionally, you could use it to manipulate the batch tree in this step. Last but not the least, please be sure to keep your eye on the DLL file size… because the IA server, which downloads the assemblies & any associated files during run-time to the machine where dotNET code module is running, has a file size limitation of 2MB.

2) Module Behavior:

This type of scripting is primarily used for mid-task data manipulation, with the ability to be used by any number of processes without any dependency on the process binary. With that said, this needs to be kept concise so it could perform quickly & efficiently. In customizing the behavior of a module, you also have two choices:

Client Side scripting (CSS):
This helps modify module behaviors, specifically Scan Plus, Nuance OCR, Documentum Export & Web Services. There are two main events that you’d deal with in this type of scripting — one is TASK, which applies to specific batches; and the other is MODULE, which applies to all processes which uses this module. As you could guess, these events would be fired where the cleint module is running (not necessarily on IA server). Please note that any process which directly uses this module doesn’t require to be recompiled to pick up these changes — meaning, any CSS changes would immediately impact all the current batches on the system. Lastly, moving processes or batches from one server to another doesn’t bring all the related CSS dependencies with it and would have to be performed manually (in other words, copy the DLL to the binnt folder on the workstation where it’s expected to execute and register).

Profile Scripting
This is a new & powerful concept to customize document type & image processor profiles. For those who are new to this, a good example to understand a document type scripting is to imagine configuring a pick list table for the Index users in a non-standard query format. In other words, if your enterprise architecture prevents you to submit a standard query to a database and could only query via proprietary API’s and such, profile scripting for the document type is where you are heading to. Alternatively, if you need to manage which filters or annotations should be applied to the input image based on image color, tones etc., profile scripting for image processors is where your answer lies. The independence of the module scripting from the Capture Flow process gives the ability to effectively reuse across multiples processes. Please note that all the related assemblies created as part of the scripting is managed in IA Database.