James is right. I looked into this as well since yesterday and determined that there is currently no FilterBatchList and I have not come up with a way to address your use case. Also, it seems you're not the first to ask about this, so I think we need to consider addressing this use case for Desktop. It seems part of the reason for not providing scripted filtering of tasks was to prevent customers from getting into a state where batches with work cannot be processed because (for whatever reason) they are always filtered out of the list.
Can you confirm, in IndexPlus you were triggering at the Batch level? Do you have a use case where Desktop needs to trigger below Batch level but at the same time you need to implement a non overlapping verification step? Also, I assume you wouldn't have a problem with configuring a "mutually exclusive" routing pattern in Desktop vs a script like you did in IndexPlus.
Figured it might be good to post a few best practices this week as well - hope this helps someone out there in their day to day endeavors!
Part of the Captiva 7.x experience is figuring out how the new modules work and how to try and avoid errors. This is something that I can personally say we spend countless hours with and I want to discuss one error in particular that we may not necessarily help you to avoid it altogether but will help you tackle it quickly when you encounter it. This is something that we discovered the hard way, with trial and error of course.
In Captiva 7.x we have a new module called Extraction that replaces the Dispatcher Recognition module. Extraction relies highly on the quality of the image it is performing OCR on. Essentially what this means is that it is very sensitive to the types of images that it can process. If an image has incorrect DPI or incorrect compression type it will throw an error in Extraction and cause the batch to enter an error state. The reason for the error is because the PixTools tool that is used for image manipulation in Extraction is unable to read the input image. The error will read something along the lines of: “Error while loading image” or “PixTools error”. Here is a screenshot of that.
Whenever you get an error like the one above in Extraction is most likely the image. To troubleshoot it there are a few steps you can take to pinpoint the problem. First off make sure that the input image for extraction is valid. Here is a screenshot of an invalid input image in Extraction:
When the input image is not valid then you need to figure out where in the workflow the image was manipulated. It could be that the image was manipulated and never updated or saved incorrectly.
Best practice/tip to avoid errors like this
When our team would get errors like the one above they started to think: How can we avoid this? How can we make sure that the image is always the correct format when it gets to extraction? That is when they came up with a best practice that we use in our projects to try and minimize this error. The best practice is to add an Image Converter step at the beginning of the workflow after all our images have entered the workflow. This Image Converter step has only one job, to convert all the images in the batch to the necessary format. I won’t specify what that format is because it can differ.
Some of you may want 200DPI images while some may want 300DPI images. It really does not matter what the format is because Image Converter can convert to your specific scenario.
For example say my project expects 300DPI images with a compression type of CCIT4. Then all images will be converted to that format in Image Converter. This way, when it gets to extraction it is the correct format and we avoid having our batch being set to an error state. Here is a screenshot of that:
The data entry form is divided into groups; each table is in its own group. The first field in the first group will be the one that has focus. Based on that, the initial focus can be on the table, but only if the table is the first group (at the top of the form). However, the scripting APIs let you find any field—table or otherwise—and set focus to it.
Are there any future plans or methods for Dispatcher 7 to OCR tables from at least 2 tables on a form image? We've discussed a workaround is to make a copy of a classified image page node (Template1) and set the copy to a different template (Template1a) and OCR the 2nd table, then load the tables on one multipage Doc Type form in Captiva Desktop. Has anyone ever tried this?
I apologize for late answer.
Yes in IndexPlus I was triggering at Batch level. It was good-enough for me (otherwise I would need "FilterTaskList"which was never available ).
Is it possible to log this feature request officially to Captiva product management?
Without nonoverlapping verification, it is almost impossile for me to justify expenses of upgrade to "new and shiny" Captiva 7 modules to my customers. In adition, customers are stuck to Dispatcher Validation module which is inferior to competitive products (primarily Kofax and Datacap) and customers are aware of that.
Yes, I've already been discussing with Engineering. I will log this as an enhancement for Desktop and let you know about progress or if I have any additional questions.
We had tested the work around you mentioned in the initial release version of Captiva 7 (before 7.1 was released) and we were actually able to make it work, however, we felt it was not an efficient solution and was complicated so we remained focused on finding another solution.
Good news came quickly in that with Captiva 7.1, you can now define multiple tables using Captiva Designer and assign recognition zones to those multiple tables in a Captiva Extraction Project for a single image/template. This was an issue with the previous version of Captiva 7 but it has been fixed in the latest Captiva 7.1 release. You are now able to use multiple tables to extract data from a single image without needing any sort of workaround.
This Ask the Expert event has now ended. Thanks to our expert and those who participated in the discussion!
Just so you know, next week we're having the folowing ATE event:
Please, join us or let your peers know about it.
Would the following be an acceptable solution?