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.

Steps for a successful ECM migration using ILINX Export

As a Sr. Systems Engineer at ImageSource, I am currently engaged on a project where the customer had a need to migrate all content out of their Stellent IBPM 7.6.0.0 software platform. (This is the same product stack as Optika Acorde and Oracle IPM; the product has gone through a few name changes over the years with the different acquisitions.) In my experience, I have found there are several steps that need to be taken when considering migrating content from your current ECM repository.

The first steps in any migration are to analyze existing content and ensure that the majority has been discovered, identified and prioritized.

  1. Categorize content into categories (document types, applications, folders, etc.)
  2. Prioritize content based on:
    1. A business value rating to the content
    2. A difficulty level associated with the migration effort

Categorizing Content:
All discovered content should be cataloged by the indexes or field data that exists for it and the file formats used. All systems that may be migrated need to be investigated for existing export tools that can export data into various formats, such as CSV or directly to custom databases. If the system is lacking any direct export capability built into the product it is necessary to either develop a migration tool or purchase one. In my current project we are using a tool developed by ImageSource called ILINX Export. ILINX Export supports migrations out of Oracle IPM (along with Stellent IBPM and Optika Acorde), WebCenter Content 11g, EMC AppXtender, IBM FileNet P8, and IBM FileNet ImageServices. Continue reading

IBM FileNet P8 Links

Looking for some useful links to information in regards to the installation and configuration of IBM FileNet? We have been deploying successful IBM FileNet implementations and will be providing useful information, as well as, tips and tricks on this blog.

Continue reading

Kofax KTM is a Powerhouse Product

Kofax Transformation Module is one very powerful product once you learn some of its secrets.  In this installment I plan to show you two of KTM’s abilities to modify the out of the box functions, Validation Design and Scripting.

Screenshot

Screenshot

The scripting language and class object models of KTM allow you to modify how Extraction works and also how Validation works.  In the case of extraction, out of the box KTM does not recognize negative amounts as in the case of a Credit Memo.  In order to allow KTM to recognize negative amounts requires the use of a script function.  This script is listed in the HELP documentation and is simple to add.  It performs the original function of validating that what was extracted from the invoice is indeed an amount and it also validates the amount if the negative sign is present.  Another example is during extraction, an amount is not considered valid if it consists of just a decimal point followed by 2 digits, such as “.75”.  A lot of invoices are printed in just such a fashion if the amounts are only cents and no dollars are involved.  A script of only one or two lines of code is then used to force KTM to recognize the value by adding a zero in front of the decimal point to form the amount of “0.75”.  In this manner scripts can be used to add additional validation of the extracted values and to modify the extracted values if necessary.  This also applies to field values that are not extracted as we will see in the discussion of Validation. Continue reading

Integrating Legacy Systems with ECM

I’ve been working on a project that required scraping values from an IBM Terminal Emulator and using them for updating indexes in an Oracle IPM imaging repository and was lucky enough to have the ILINX AIK tool to work with in accomplishing this task.

The first challenge was in dealing with the values that we were gathering from the Terminal Emulator Screen.  The way that the data was served to the terminal emulator was not parsed into separate values.  The AIK allowed us, through VB Script, to parse the data into a form that we could use.  Once the data was massaged into a usable form, we used the values to update indexes in Oracle IBPM.  The ILINX AIK natively comes with connections to Oracle IPM for searching.  However, updating index values on documents that already exist in the system can be a challenge.

To overcome this obstacle we used the ILINX AIK to map the data into an executable.  This option was used for performing the Oracle IPM Index updates, and we were able to accomplish this by mapping the data to an executable with the mapped index values as arguments, and having the executable perform the index updates.
Continue reading