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.

Passing custom values to Captiva Completion Module in 7.5

I recently was wrestling with migrating a 6.5 Captiva InputAccel process into 7.5 environment and had to figure out how I could manipulate custom values and pre-fill them for Index operators using Completion modules. Assuming the reader has the basic development knowledge with the new Captiva version (using UIM data etc), here’s a break down so we don’t have to re-invent the wheel. I hope it goes without saying that, at this point in time, the EMC documentation is still in its infancy.

First thing first. Before you attempt to assign a value to the document type that’s associated to a process, set the UimDataImportMode

RIP Documentum!

Too hasty you say? But seriously though, what are the real alternatives?

First a disclosure. I’ve been away from blogging for few years to pursue another passion of mine which effectively consumed every waking moment outside my work. I enrolled in film school and here’s the trailer of my film for the curious minds.

FAST is fast gone

I was at the EMC world today and it was quite productive. I noticed Pie covered the keynote session well but couldn’t make it for Victor’s session. I tried myself to get to Victor’s session as soon as I could (ran into a buddy of mine on the way and lost some precious time) but was able to listen to the session standing. Here’re some notes:

Sharepoint/Documentum: Today and tomorrow…

Its always interesting when a company as big as Microsoft makes it way into a new niche and the leader in that domain accommodates to co-exist. Make no mistake, its a strategic move from both sides but the challenge is to help our customers strategize ECM solutions keeping long-term in mind. This is my $0.02 to understand where we are heading and how to plan for it.

EMC Documentum Support

I had experienced various interesting encounters with EMC support, but lately, I feel like they are just getting arrogant… I guess it comes with the size (Documentum to EMC) and its layers. Here are some to ponder…

BOF 1.0 and BOF 2.0

BOF is critical in getting business logic and processes implemented accurately *enterprise* wide. And its capabilities play significant role with development, deployments and migrations. First of all, I have to be honest and say how much I adore the BO framework in Documentum. When the first version came out, I loved it and loved the control it offered. And soon realized how the BO functionality wasn’t being invoked on machines where BO registration wasn’t done. And it was taken care of in 2.0, but it was not recommended to use dbor.prop although it was backward compatible. This intangible setup on a machine (using 2.0), leaves you hanging when things do not work. And the fact that individual interfaces/implementations for each business object need to be deployed OR define the same jar over and over for each business object if you decide to club all together – not perfect yet…

BPM

Documentum’s BPM is one of those technologies which business can’t wait to implement. The evolution from the Workflow Manager to this is quite remarkable. And, in all fairness, I should also say that its gotten quite temperamental over time, rightly so, at the rate at which the features are being added in.

Setting up an unsupported active-directory

I was recently asked by a technologist on how to go about adding a new active directory sync which is not supported by Documentum. As I was thinking through it, I remembered that James McGovern had posed this question in the past – Why does Documentum need its own user store when it can use other systems which are developed solely for this purpose?

Supporting Workflows

The success of a production deployment can be analyzed with the amount of support which goes into maintaining and/or trouble-shooting the application. One of the challenges in a production release tends to do with the workflows. Several times in the past, I had to run variety of queries to identify various combination of results relating to workflows. In the process I developed this cheat sheet for myself which gives a quick overview of the workflows and what you have to query for.