Category Archives for "ImageSource"

Oracle IPM 10g and Imaging 11g Migration

One of the things we’ve done a lot of here at ImageSource are migrations. It’s definitely one our core competencies. For a little more information on our approach to migrations, you can review my earlier post here. Lately, migrations have been more focused because the majority of them involve moving content out of the Oracle IPM 10g or Oracle Imaging 11g products. Oracle IPM 10g has reached end-of-life, and Oracle Imaging 11g was the terminal release of the product, so essentially that product line is dead. The IPM 10g product was something we worked with for many years, so we have a wealth of knowledge on its “ins and outs.” IPM was a feature-rich, but older, product stack, and it was in need of a rewrite. However, when Oracle rewrote the product as Imaging 11g, there were a lot of key and important features that didn’t make the cut.

Because of everything I’ve mentioned, businesses running on these particular Oracle ECM platforms have had to make decisions for their long term ECM vision or roadmap. I have worked with a number of clients on technology evaluations and like to help determine their roadmap, but that’s a blog post for another time. One of the key pieces to any ECM roadmap for a company performing  these ECM solution changes is the migration of their content from the systems that they are replacing. Luckily we have ILINX Export and ILINX Import to make these migrations straightforward as possible.

There are a number of options with ILINX Export, but in short we use it to export all content and metadata out of a source system for migration into any destination system. By default, ILINX Export retrieves the content from the source system in exactly the same format it was in when it was added to the original system. By exporting the content out in its native format, a customer can keep a copy of the original data, and any data manipulation or file conversions can be done downstream. ILINX Export does have the ability to convert files to PDF, but we generally recommend image conversion when importing the content into the destination system. Utilizing our knowledge of Oracle ECM, there are plenty of options when extracting the content from these products. For example:

  • Only migrate certain applications.
  • Only migrate content created after, or before, a certain date.
  • Only migrate the content that falls within certain criteria: i.e., specific business unit, a set of document types, or virtually any criteria that can be identified with the content metadata.
  • Split the content up so content that meets certain criteria goes to one destination, and content meeting other criteria goes elsewhere.
  • Retain the IPM, or Imaging, annotations. These can be flattened into the documents, but I only recommended that in certain instances. If the client is migrating to ILINX Content Store, we can migrate the annotations as an overlay into the new ILINX system.
  • There are many options for formatting the data when it its exported from the source system. ILINX Export can output the metadata to text or XML files with complete control of the format, delimiter, field order, layout, and size of those files. That flexibility allows for the creation of input files in a format that can work for just about any destination system.
  • The metadata can also be written directly to SQL to support long term storage or manipulation if necessary.
  • Schedule the export to run during off-hours to keep the load off the servers while clients are using the old system.
  • Detailed auditing of the entire process to help with reporting, compliance and troubleshooting.
  • Many more.

Once you’ve defined all the rules surrounding the migration and started execution, the next step is importing that content and metadata to the destination ECM system. For that, we use our ILINX Import product which I’ll cover in a later post. If you have any questions about ILINX Export, reach out to us for a demo or discussion.

John Linehan
Sr. Systems Engineer
ImageSource, Inc.

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:ProgramDataImageSourceILINXReleaseSettingsJobs. 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] set SettingsXml = ‘COPY AND PASTE ALL TEXT FROM 5.4 OR PRIOR RELEASE JOB SETTINGS FILE HERE’
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.

Implementing SQL FILESTREAM Part II

Last month I wrote about enabling SQL FILESTREAM with ILINX Content Store. After discussing this with a few people, I think I should share some more information and reiterate a couple points.

For Existing Applications:
As I mentioned before, the decision to enable FILESTREAM should be done during the planning phase. If you perform this process on an application with a lot of content, it can be a very time costly endeavor with a big performance impact to the server. Also, after the move from BLOB to FILESTREAM, you could have a fragmented database. The BLOB to FILESTREAM process can definitely be done on an existing system, just be sure to plan accordingly and allow for sufficient time.

After step #10 of my previous blog post (all the data is copied and you have deleted the BLOB column), you will notice that the database file size hasn’t decreased. This is remedied easily enough be executing a DBCC CLEANTABLE command. The DBCC CLEANTABLE command will reclaim the space from the dropped variable length column. For example, if your database is named ILINX_CS and your application is named Sample Application, the query to do this is:

DBCC CLEANTABLE ('ILINX_CS','[dbo].[Sample Application]',10000)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

ILINX 6.X Database Lookup IXM

ILINX 6.X is an easy to configure and easy to use software package to scan, index, and provide workflow. The workflow steps are based on IXM (ILINX eXtension Modules) that are very similar to a programming language. There are several different types of IXM’s available out of the box. The following is a quick listing by name of the out of the box IXM’s:

5

By using the IXM’s, the designer of a workflow can have a batch move through single or multiple steps to perform any required task.

In addition to the IXM’s there can be actual code executed through a Client Side Extension or through a Server Side Extension. So there is little that cannot be accomplished using the ILINX Capture workflow IXM’s.

This week I would like to concentrate the discussion on a single IXM Database Lookup. The Database Lookup IXM is one of the most powerful when it comes to interacting with entities outside of ILINX. It not only allows ILINX to perform a database lookup and return column values to the Batch Profile or Document fields, but it also allows for the update of a database table’s columns.Continue reading