1,126
edits
Difference between revisions of "Migrating From Filenet to Content Manager OnDemand"
Jump to navigation
Jump to search
m
Migrating From Filenet to Content Manager OnDemand (view source)
Revision as of 11:48, 3 November 2015
, 11:48, 3 November 2015Added info on field-re-use.
m (Added the warning.) |
m (Added info on field-re-use.) |
||
| Line 40: | Line 40: | ||
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. | ||
=== Check for field re-use === | |||
As is human nature, some shortcuts may have been taken in the distant past that are now your problem to resolve. One common annoyance is the 're-use' of a particular field for a new data type. The time saved in putting a value in a pre-existing field with an unrelated name is likely to be a recurring theme. For American companies, using Social Security Numbers ("SSNs") for customers or employee records used to be common. With the advent of large-scale identity fraud, companies ripped out SSNs from databases, and replaced them with different numbering systems. In order to save time and money, many companies simply re-used their old "Social" field with new "Employee" numbers, often causing chaos when new systems try and do any validation. Also, watch out for real metadata squeezed into generic fields, like 'Description' or 'Comment' or 'Notes'. You'll have to determine what exactly that data is, and where it truly belongs in order to complete the migration successfully. | |||
=== Transfer in Original Formats === | === Transfer in Original Formats === | ||