How Microsoft ClickOnce Platform Benefits ECM Deployments for Capture, Document Management & eForms

ClickOnce is a deployment technology that enables you to create self-updating Windows-based applications that can be installed and run with minimal user interaction. ClickOnce deployment provides 3 major benefits for any .NET application:

  • Updates are provided automatically, downloading only those parts of the application that have changed.
  • Each application is self-contained and cannot interfere with other applications.
  • Deployment enables non-administrative users to install, granting only those security permissions necessary for the application.

As manufacturers of an ECM platform built on the .NET Framework, we are able to take advantage of ClickOnce to provide simple deployment of the complex and powerful applications we create. Personally, I’ve found that ClickOnce strikes an excellent balance between the two things most often encountered in enterprise environments: requirements for rich client applications that can be frequently and rapidly updated, and the simple access and deployment thin client web applications are known for.

When software needs to be deployed to many users across an entire enterprise organization, like is often the case with our content management product, ILINX Content Store, ClickOnce successfully gets the software where it needs to be, when it needs to be there. This also holds true for our capture and workflow product, ILINX Capture, which requires complex interaction with both other software suites and several classes of image capture hardware.

But what if your platform has limitations that prevents you from taking this route, forcing you to package the software into a .MSI file instead? This is adequate for some situations, but quickly becomes a pain to deploy proportional to the number of machines it needs to be installed on.

Facing this challenge with our electronic forms product, ILINX eForms, we have found a workaround that allows us to avoid the headache of one-at-a-time deployment .MSI files create. In short, the same API used to build the standard ILINX eForms client is available for use in building custom .NET applications, which allows you the freedom and flexibility to integrate ILINX eForms into your own .NET software. When combining this benefit with even basic ClickOnce configuration, you end up with a strong, rich-client application that can be seamlessly deployed and updated across your organization as needed in a matter of seconds.

But what about building out the custom app itself? The highlights of that process will be covered in a future entry, but if you’re ready to go right now, just open up the Help file in your copy of the ILINX eForms Designer and take a look at the Standalone Application contents section for some guidelines to help get you started.

Jesse Kinney
Solutions Developer
ImageSource, Inc.

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.

Oracle IPM 10g and Imaging 11g Migration: Part 2

A couple weeks ago I wrote a post about ECM migrations, with a focus specifically on moving content from Oracle IPM/Imaging to other destination systems—projects we’ve been performing a lot of lately. Our tools of choice for migrations are ILINX Export and ILINX Import, but if the destination ECM system isn’t supported by ILINX Import, there are other options. Almost every ECM system has mechanisms to do bulk or mass imports. ILINX Export provides many options to format the data so sometimes it is a matter of configuring the output to be in a format supported by the third party import application. Other times, utilizing these third party import applications may require a little development. Regardless of what’s necessary, we’ve never run into a destination system that we couldn’t work with.

There are multiple reasons we split the migration operations into two parts—export and import—flexibility being the biggest one. There are a lot more options when splitting the migration into two separate operations. Since we don’t modify the data on export from the source system, a snapshot can be taken for long term archival. Then on import, or pre-import, we can massage the data, perform file conversions, or augment the data by pulling additional data from an external source. Even though we split the migration up into two operations, they can be run in tandem so there is little effect on the overall duration of the migration.

One of the biggest concerns surrounding these migrations is the amount of time it will take. Performing tests in the actual environment is required because of how many variables go into the throughput of a migration. If the migration is estimated to take too long after initial testing, there are options to address that scenario, including:

  • Create a migration environment with instances of the source ECM system software on newer, more powerful servers, and restore the production data to these new servers in order to execute the migration from there. This has the additional benefit of removing any potential performance impact to the legacy production system for the duration of the migration.
  • Spin up additional instances of ILINX Export and/or ILNX Import to increase throughput. There will be a point when additional instances of the export or import process will not increase throughput—generally when a bottleneck restricts the maximum throughput that the source or destination system can achieve.

Recently, I had a customer that had set a hard go-live date that was just 60 days after project initiation for their new system. We had no problem meeting this requirement from a technology deployment standpoint, but our migration testing indicated that we wouldn’t be able to move all of their 25+ million documents in that time frame. In order to make the new system go-live date, we migrated the three previous years’ content first, then resumed with the older, remaining content. Since the vast majority of content to be retrieved would be from the previous year, the fact that the migration wasn’t 100% complete at go-live was a non-issue. This is an approach we’ve followed numerous times.

Once a migration is in full swing, auditing can be the most time consuming part of the process. ILINX Export and ILINX Import have very complete auditing capabilities, so while the migration is occurring, issues are immediately identified and can be addressed. We generally audit a couple different ways to confirm success. If only using ILINX Export, what is exported can be compared with what is in the source system to ensure all content was pulled out. When performing a complete migration, what is imported into the destination system is compared with the source system. Any migration can only be considered a success when it is proven that all the content was migrated, which is why we practice multi-step auditing during the migration.

By following our standard methodology for migrations and utilizing the technology we’ve developed over the years, we consistently perform reliably successful migrations. To read more about migrations, review my previous blog posts Oracle IPM 10g and Imaging 11g Migration and Steps for a successful ECM migration using ILINX Export.

If you have any questions about my blogs, or would like to discuss the possibilities for migration within your organization, please reach out to me or your contact at ImageSource to start the conversation.

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:\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]
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.

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

How ILINX Capture changed my document conversion workflow

I have been doing document conversion for roughly 15 years and there are numerous applications you can choose from that are a complete waste of time. I have unfortunately had the opportunity to work with some very cumbersome and complicated applications over the years. One of the applications we were using had modules you would have to open separately for every step in the conversion process. After scanning you would have to open the import module then you would have to open another module for document classification then another module for indexing then another module for Quality Control and another module for releasing the final product. I was introduced to a new application called ILINX Capture that changed my entire workflow. I fell in love with it. Now, I no longer have to open a bunch of separate modules to complete the conversion process. The conversion process takes place all in the same window document classification, QC, indexing, etc. ILINX Capture is so easy to use and a complete time saver. I recommend checking it out if you find yourself wasting time going through unnecessary steps when capturing and indexing your content.

Ryan Ivie
Conversion Services Manager
ImageSource, Inc.

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