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.

Transferring ILINX Release Configurations When Upgrading

Starting with ILINX Capture v6, the Release configurations are stored within the ILINX database. In ILINX Capture v5x, the ILINX Release configurations were stored in XML files on a disk. ILINX Capture called ILINX Release using a SendAndReceivedReply IXM. The change to store the settings within the ILINX database is very useful for a number of reasons: Release settings are part of the batch profile allowing for simpler migrations between environments, Release is much easier to configure, all configurations are in the database, etc. However, this change can create some extra work when upgrading from ILINX Capture 5x to ILINX Capture 6x. Because of the different architecture, ILINX Release needs to be completely reconfigured for the existing batch profiles. In addition, the Release XML doesn’t change, but there is a shortcut that can be taken. After you have upgraded ILINX Capture to v6, you’ll notice a new IXM in the palette: ILINX_Release_IXM_Icon

The existing ILINX workflow will likely have a SendAndReceiveReply IXM on the map that the 5x version of ILINX Capture used to call ILINX Release. Most likely, it would look like this:
SendAndReceiveReply_IXMTo configure ILINX Release for ILINX Capture 6x, the SendAndReceiveReply IXM will need to be removed from the map and a Release IXM must be dragged onto the workflow map in its place. Once the new Release IXM is on the map, it will need to be configured. This is where the shortcut can be taken. Instead of having to manually enter in the correct URLs, map the metadata values, and configure any other settings, do this:
Configure and save Release with some place holder settings: I normally leave the settings at default and enter in the bare minimum:

  • Job Name
  • User Name
  • Password
  • Batch Profile
  • Release Directory

Once ILINX Release configuration is saved and the workflow map is published, there will be a new entry in the ILINX Capture database Capture WorkflowAppSettings table. The CaptureWorkflowAppSettings.SettingsXML column is where the Release configuration is stored. Now it’s time to update the SettingsXML column with the XML from the ILINX Release 5x job settings file. The Release job should be on the ILINX Release 5.x server at c:\ProgramData\ImageSource\ILINX\Release\Settings\Jobs. The only caveat here is to be sure to place single quotes around the XML content. Here is what the SQL update statement would look like:

update [ILINX CAPTURE DATABASE].[dbo]. [CaptureWorkflowAppSettings]
where settingsID = ‘APPROIATE ID HERE’

Following this procedure can save some time if upgrading an ILINX Capture 5x system that has a lot of batch profiles. A lot of the time spent on the upgrade could be in the ILINX Release configuration. If I was upgrading a system with only a few batch profiles, I would probably just reconfigure them. If I was upgrading a system with a lot of batch profiles, I would go through the above steps to save some time.

John Linehan
Sr. Systems Engineer
ImageSource, Inc.

One Way ILINX® Manages Compound Documents

As part of the ECM industry, it is important to understand what compound documents are and how they affect you.  Compound documents have been an issue in ECM software from the beginning of time. According to wiseGEEK, Compound documents are document files that contain several different types of data as well as text. A compound document may include graphics, spreadsheets, images, or any other non-text data. The additional data may be embedded into the document or be linked data that is resident within the application. You may be asking what that means for you? We all know that basic ECM is scan/store/retrieve, but what happens when you add electronic documents in PDF or MS Word?

Continue reading

Installation Hand Off to the Client

As an integrator there are many things we can do as far as making the install a success, but only a very limited amount we can do to guarantee its continuing success. One of the most often seen issues is the handoff of an installation to the client, in particular the maintenance of the database.

Continue reading

Slowing Down?

For those of you with Enterprise Content Management systems, you know that a lot (if not all) of your data is stored in a database.  A lot of times, performance issues are not a result of your Content Management system itself, rather your database is not tuned properly.

Continue reading

Bits and Bytes – Backups!

Today’s topic is short and sweet – Backups!  Backups are worth their weight in gold to an administrator. Even though backups have never been put on a scale, we know they weigh a lot! In the world of Enterprise Content Management, backups have to be attacked from many different angles usually.  System registry, databases, filesystems and more have to be backed up and then integrated back together on a restore, which can be complicated to say the least.

But there is one ECM system that does not require complicated backup strategies: ILINX Content Store!  That’s right – all you do is configure database backups.  No registries—file system is completely optional and in the event of a recovery, a fast reinstall of the server software and a database reattach is all that is required.  Conveniently all the settings, data, and preferences are saved in the database.   Compare that backup strategy to other industry-leading ECM systems and you will see how simple it is.

Mike Peterson
Support Engineer
ImageSource, Inc.

College Transcript Processing

College Transcript Processing refers to converting a paper based transcript into an electronic transcript via software that OCR’s the scanned paper version, locates specific data within the transcript and saves that data for later use.  The reason for processing a transcript via software is to improve the rate of data transfer to another system for storage and retrieval versus manual data entry by a data entry specialist.  This is a somewhat difficult task due to the following reasons:

  1. Each and every College presents similar data in a very different format.
  2. Almost all colleges attempt to prevent the copying of the paper transcript through various copy protection methods.  Most of these methods render the data on the transcript almost un-readable.

The data that is similar on a transcript falls into several main areas:

  1.  College Identifying Information
  2. Student Identifying Information
  3. Session/Course Information
  4. Previous Colleges Attended Information
  5. Degrees Awarded Information

The data is similar but not the same on each college transcript.  In addition, the layout of a transcript varies greatly between the various colleges.  Session/Course data could take up the entire width of the paper for one college, but be formatted as multiple columns of data for another college.  There are many, many variations that need to be taken into consideration when attempting to OCR to find and extract the data.

So far the Abbyy FlexiCapture 9.x software has been able to handle most of these issues out of the box.  One of its most powerful features I am finding out is the scripting language to write rule, custom scripts and export scripts that can correct OCR issues and assist the Verification Operator improving efficiency and throughput.

The scripts for rules, custom scripts or export can be written in VBasic or Jscript.  There is some documentation on the Abbyy classes and objects, but not a whole lot.  Most of what I have done has been through trial and error or in specific cases from examples provided by Tech Support.  However, what scripts that have been developed work well for correcting OCR issues and providing automated checks of extracted field data.  Through Custom scripts there is even the option to use a Database lookup on extracted data and return other fields from the database to assist in providing a complete set of validated information.

This has been a learning experience but it is proving to be well worth the effort in getting the data off the paper and into the system used to evaluate a student for enrollment by cutting down on the man hours required under the old manual data entry.