Migrating from Stellent UCM & IBPM – A little foresight can alleviate a lot of trouble

Migrations from systems like IBPM to ILINX can be fraught with issues that can bite the unwary in very bad places. However, if you are aware of such problems, you can plan ways to mitigate them and have a successful migration in the end.

One issue we run into is documents that have a page or two with corrupt images. Perhaps when the page was first contributed to IBPM, a system or other type of issue caused the image to be corrupt or cease to exist. Either physical hardware or a software bug can be the culprit. The product we use for migration, ILINX Export, will flag this document as an error, skip it and move on to the next document in RECID order. Once the export is completed, these flagged documents have to be re-visited. Once a determination is made that an image is indeed corrupt, and the chance to recover it from backups is extremely remote, the document can be deleted or manually exported from IBPM without the corrupt image.

Another matter we’ve dealt with is related to non-tiff images. This category is “universal” type images, and includes PDF, DOC, XLS, MSG and a host of other file types that IBPM supports. There are options within the ILINX Export tool that will allow the export of these files types in their native format through the IBPM SDK. Or the export can be done through database manipulation that can directly access the image file and then “unzip” the universal file into its native format.

The issue that can be encountered here is twofold, and manifests itself when migrating to another repository. One, IBPM stores the native file zipped up with another file that contains metadata and has no file extension. When the document is unzipped there are two files, one with a valid file type and one without. Typically, backend repositories require file extensions, which are useful for performance, like displaying file type icon on the user interface, and a variety of other reasons. During the migration, importing to the backend may be impeded due to a lack of extensions on the metadata files. Secondly, if the extension of the universal file has been altered or damaged in storage, the file type may not be a standard that the new repository will accept. In any case, having your migration come to a screeching halt is something to avoid.

Awareness is the key. By proactively incorporating a response into your migration plan, you can eliminate much heartburn and anxiety. That is where the expertise and knowledge of a seasoned Optika / Stellent / Oracle integrator, like ImageSource, comes into play. We have helped many customers build migration plans that take these and other items into account, so the migrations are as smooth and worry-free as possible.

Indexing Tables in Kofax-Based Environments

We recently had a customer who needed to migrate off of an aging and highly customized Capture/indexing/workflow one-off solution. At the center of many of their form types in this system was a repeatable field collection object that functioned much like how you would expect a .NET DataTable control to function – values could be added horizontally to the current “row”, and at the end of it you could hit enter and a new “row” would be added. As you moved through, you also had the ability to validate the line item as a whole. In other words, nothing too out-of-the-ordinary.

Unfortunately, this stood out as a red flag for both myself and my coworker when we first saw it, since we were migrating the client to Kofax Capture. There’s nothing inherently wrong with Kofax’s flagship product, in fact it is an excellent tool for getting content where it needs to be, often in record time. One thing it doesn’t do well out-of-the-box, however, is table fields. Defining one looks normal enough, but when you actually get the chance to index them, each column ends up being a standard index field. Needless to say, turning the table 90 degrees counter-clockwise and forcing keyers to manually delimit values is not an ideal experience, especially when 99% of your form is tables that need to be indexed. Continue reading

Registering DLLs in COM with WiX for creating an MSI installation package for a Kofax Custom Panel

I was working on a project recently for a customer that was upgrading their Kofax versions and making some enhancements to a custom Kofax panel that we had written for them some time ago. Like any good developer, I migrated the code for the custom panel to the latest version of Visual Studio I had, (in this case, Visual Studio 2012). I had finished development and was discussing installation when the customer requested an MSI package to install the custom panel. Unbeknownst to me, Visual Studio 2012 had dropped their support for the easy, drag and drop, built in set up and deployment project to create MSI’s.

In doing some research, I found many developers had migrated to using the open source WiX product to create MSI packages, (http://wix.codeplex.com/). One can download WiX and integrate it directly into Visual Studio. Everything was fairly straight forward on following their tutorials except for one snag: in order to get the custom Kofax panel to install correctly, I had to register the custom DLLs as COM Components, not in the GAC. After a lot of head scratching, I finally figured out that I could use Heat (one of the WiX tools) to create a registry file of the DLLs to include in my WiX set up project. You can find out more about Heat here: http://wixtoolset.org/documentation/manual/v3/overview/heat.html. After the file was generated I was able to take the output of the Heat generated file and include it in my WiX install project to register the necessary DLLs. To do this, I followed these steps: Continue reading

How to troubleshoot SQL error [3566] & open applications in Kofax 10

I recently worked with a customer who was receiving the error below on a Client/Server installation with a standalone SQL instance (not built-in):

[3566] KdoLib: Network I/O error: A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections. (Provider: SQL Network Interfaces, error: 26 – Error Locating Server/Instance Specified) (-1)

After performing a clean install of Kofax 10 on a new workstation, they were unable to open Batch Manager, Administration, etc. The process could be seen in Task Manager, but the window would not open, and after about 20 minutes would show the error above.

To resolve this we first tested the connection to the SQL server using a .udl file. This can be done by creating a blank text file, then renaming the extension to .udl.

Open this new Data Link and fill in the fields for your SQL server and test the connection. If you do not get a success, verify that your server name, login, firewall, etc. are configured properly to access the server. Continue reading

Exporting Records Using KTM Medical Claims Add-on & Kofax Export Connector

Kofax provides an add-on pack for their Transformation Modules product to handle CMS-1500 (formerly HCFA) and CMS-1450 (alternatively, UB-04) medical claims forms called the KTM Medical Claims Add-on package. Related to this package is the Kofax Export Connector for Medical Claims. This Export Connector allows for the data captured off of said forms to be formatted in the HIPAA-compliant EDI/ASC X12 837 formats (to be exact, 837 Professional for the CMS1500 and 837 Institutional for the UB04).

Continue reading

KTM TDS Model Building

Are you tired of separator sheets?  Tired of wasted paper and countless hours of flipping through pages and inserting a barcode sheet at the start of a new document just to take it out after the batch is scanned or leave it in the batch and have more paper to store?  Why not have the computer do the work for you?  That’s the idea behind the Project Planner module in KTM.  There is a standard separation functionality built into KTM that works very well on structured and semi-structured documents but when you have more complex separation rules the Project Planner component of KTM is what you need.

Continue reading

Kofax KTM Dictionary Gotcha on Dates

In KTM there is a nifty feature to search the entire document for a date field. It will recognize all dates existing on the form and with some other snazzy logic you can find the date you are looking for. If it is nearby the word “recieved”, then you probably have a recieve date. Easy, right?

Okay, sometimes dates get a little more tricky. “3/17/2011“, “3-17-20011” and “MAR 17, 2001” are all valid date strings. Any of those formats could be found on your document. In KTM there is a nifty feature to search for the string “MAR” and replace it with a “3” when searching for dates. You use it in your locator’s regular expression. You can setup your own dictionary of months to look for “March” or “Mar” (or “Marzo” if you need internationalization).

Here’s the gotcha. I recently found text in an OCR’d document like this: “19 NOV2008“. It’s a bit of an odd string. The OCR engine didn’t think there was enough space between the “NOV” and the “2008” to put an actual space character in the ORC’d text. So, I can read it, but KTM can’t. The nifty feature to search for the string “NOV” fails because it is only looking at whole words, those with whitespace on either side. Unfortunately, there is no option in the KTM dictionary setup to change this.

Here’s the fix. Modify the default KTM regular expression from this:

[0-3]?\d§English_Months_Abr§([12]\d{3}|\d{2})

to this:

[0-3]?\d\s*(jan|feb|mar|apr|may|jun|jul|aug|sep|oct|nov|dec)\s*[0-3]?\d

You can now make the space character optional in your regular expression search. You are no longer using the month dictionary, but that’s okay. This logic is only to locate a date, not translate it from a string to a date when found.

Problem solved.