The importance of data as an integral building block is often lost when planning large-scale CCM migrations. Many companies focus, organize and budget using form counts and complexities as a benchmark, but often fail to consider the real implications that data has on overall project costs and timelines. Oracle Documaker and Quadient Inspire access, organize and manage data very differently, so it is critical that you establish a strategy for moving a Documaker XDD to a Quadient Inspire Data Master and automate as much as possible (more on that below).
Managing Data in Documaker
Oracle Documaker’s approach to data comes with certain limitations, and companies usually resort to custom scripting to gain access to input variables that drive form triggering and batching of output. Some key points include:
- Uses an XDD to map variables from a single input file (no support for multiple inputs).
- Can accommodate XML or flat-file extract (fixed-length) input types.
- Scripting or job configuration (AFGJOB) to directly access input data via GVM’s (global variables).
- Organization of data not tremendously important as ad-hoc access to input data during assembly easily available via script.
Managing Data in Quadient
In contrast, Quadient Inspire’s workflow-based approach can accommodate multiple data inputs within a single WFD dedicated to managing data, which can be inherited by any downstream workflow. Some key points include:
- Uses workflows (WFD) to map variables to one or more inputs via pre-defined modules.
- Can accommodate a wide variety of input types including XML, flat-file extract, CSV, ODBC, line-data and others.
- Includes over 30 data-processing modules that facilitate organization and refactoring of data.
- Structuring and contextual arrangement of data very important for downstream workflows, templates and blocks (no ad-hoc access to input data beyond input modules).
Understanding the differences and why it’s important
When planning and budgeting a move from Documaker to Quadient, you really need to undertake a thorough review of the Documaker implementation to understand how data is organized, maintained, and accessed. Is the implementation XML or flat-file based? If XML, is there an XSD? How much data is mapped via the XDD vs AFGJOB? How extensive are custom GVM’s used in DALScript? How is the data formatted for placement on the forms and where is it done? What about repeating data for tables and sub-forms? How extensive is input data used for batching logic and how much DALScript is involved? The answers to these questions and others can have a significant impact on migration cost and timeline.
Moving the XDD to Quadient
As Documaker only supports two types of input files, data migration effectively follows one of the following techniques:
- XML — since XML is self-describing and often associated with a schema, this is pretty easy. Use an XML Data Input module in Inspire Designer and import an XSD or sample XML file to generate the data layout. Continue to build out the Data Master workflow and add other modules as necessary to fulfill all data requirements needed for downstream document assembly.
- Flat-File — working with fixed-length extract files is much more tricky, as variable data is mapped to fixed positions and offsets within specific records in the extract (some of which may be repeated). A large XDD might contain a couple thousand variable definitions, so you can imagine what sort of effort might be involved to redo an entire flat-file data definition in Inspire Designer.
Recognizing the significant impact that flat-file XDD conversion has on a migration project, we’ve built an automation utility to streamline the process. Our utility can read a Documaker XDD and generate an Inspire Fixed Length Settings (FLS) definition that can be used within a Data Input module to map every variable from the extract into a Quadient workflow. Using this automation, we can effectively map thousands of variables within a matter of minutes.
Once the Data Input module is finalized with the mapped variables, it becomes a standard exercise in Quadient to utilize additional modules to organize and format the data for downstream forms and document assembly needs (see our Cascading Data Master post for more details). You will need to work with the Data Structure tab of the Data Input module to organize the mapped variables for important things such as:
- ExtractKeyField/SearchMask from Documaker will determine transaction boundaries. Be sure to accommodate this structure in your Data Master.
- Arrange all records in a hierarchy as they are used for document assembly (accounting for overflow and such).
- Review AFGJOB and any DALScript for GVM’s that were NOT mapped via the XDD and be sure to account for these in your design.
Bottom-line, don’t underestimate the impact that data organization and management can have on a Documaker-to-Quadient migration project. Moving Documaker data to Quadient can be tricky and complex, depending upon the nature and design of the legacy implementation.