1,126
edits
Difference between revisions of "Migrating From Filenet to Content Manager OnDemand"
Jump to navigation
Jump to search
Migrating From Filenet to Content Manager OnDemand (view source)
Revision as of 07:21, 11 February 2017
, 07:21, 11 February 2017A variety of small changes, addition of the paragraph about data validation.
m (Updated CMOD to IBM CMOD.) |
(A variety of small changes, addition of the paragraph about data validation.) |
||
| Line 45: | Line 45: | ||
OnDemand doesn't like to have indexes defined in the Application Group without a corresponding value appearing in the reports it processes -- it also wastes space inside the database. It seems common in the Filenet world to assign a report to a Document Class that has indexes configured that simply don't exist anywhere in the report. Yes, you can assign default values to the empty fields to get ACIF to stop complaining, but if you want to do this right, you'll want to look into your index usage. Not just which fields you're populating most often, but also which fields your end users are searching on. Eliminating unused fields from Application Group definitions will streamline indexing, reduce storage costs, and reduce complaints from end users at the end of the day. | OnDemand doesn't like to have indexes defined in the Application Group without a corresponding value appearing in the reports it processes -- it also wastes space inside the database. It seems common in the Filenet world to assign a report to a Document Class that has indexes configured that simply don't exist anywhere in the report. Yes, you can assign default values to the empty fields to get ACIF to stop complaining, but if you want to do this right, you'll want to look into your index usage. Not just which fields you're populating most often, but also which fields your end users are searching on. Eliminating unused fields from Application Group definitions will streamline indexing, reduce storage costs, and reduce complaints from end users at the end of the day. | ||
=== Perform quality checks on existing metadata === | |||
Over the years, and substantial amount of junk can accumulate inside database tables. Bad data that passes a very rudimentary check at the time it was loaded starts accumulating in databases, and is often discovered during the migration process. A common example is a bad date value -- someone meant to type in a date for 2013, but entered 2031 instead, or there's a mix-up between the month and day fields. (February 12th as 02/12 vs. December 2nd as 12/02). There needs to be an additional 'sanity check' on data before performing the migration, to identify and correct these issues before importing them into the new IBM CMOD server. | |||
=== Check for field re-use === | === Check for field re-use === | ||
| Line 52: | Line 56: | ||
=== Transfer in Original Formats === | === Transfer in Original Formats === | ||
For some Filenet installations, upstream servers (or intermediate file transfer systems) convert report data (from EBCDIC to ASCII) and change the formatting of the report. Content Manager OnDemand doesn't need any data transformation, and can ingest EBCDIC reports (of fixed record length, stream, or variable record lengths) directly and without conversion. Some conversion tools (I'm looking at you, MQ Series File Transfer Edition) can be configured to change the report so drastically, that CMOD can't properly index it. | For some Filenet installations, upstream servers (or intermediate file transfer systems) convert report data (from EBCDIC to ASCII) and change the formatting of the report. IBM Content Manager OnDemand doesn't need any data transformation, and can ingest EBCDIC reports (of fixed record length, stream, or variable record lengths) directly and without conversion. Some conversion tools (I'm looking at you, MQ Series File Transfer Edition) can be configured to change the report so drastically, that IBM CMOD can't properly index it. | ||
Wherever possible, remove any data conversion and deliver report data to OnDemand in its original format. | Wherever possible, remove any data conversion and deliver report data to OnDemand in its original format. | ||
| Line 68: | Line 72: | ||
=== Annotations === | === Annotations === | ||
If you're using in Filenet, you'll need to extract them, and integrate them into CMOD. Annotations can be added to individual documents in OnDemand at load time, through the Generic Index files. | If you're using in Filenet, you'll need to extract them, and integrate them into IBM CMOD. Annotations can be added to individual documents in OnDemand at load time, through the Generic Index files. | ||
=== Reconciliation === | === Reconciliation === | ||
In order to reconcile the documents after the migration is complete, you'll want to have a unique identifier for each document that needs to be moved out of FileNet and into CMOD. Thankfully, FileNet provides a unique 'Document Indentifier' or "DocID" -- which can be loaded into CMOD by adding a corresponding field in the Application Group definition. The DocID field doesn't need to be added to | In order to reconcile the documents after the migration is complete, you'll want to have a unique identifier for each document that needs to be moved out of FileNet and into CMOD. Thankfully, FileNet provides a unique 'Document Indentifier' or "DocID" -- which can be loaded into IBM CMOD by adding a corresponding field in the Application Group definition. The DocID field doesn't need to be added to OnDemand folders, so it can remain invisible to end users, or exposed to a different folder to be used with existing tools that use them. | ||
=== Don't create unnecessary directories === | === Don't create unnecessary directories === | ||