Launched using the Cúram batch launcher, the main features of this tool are as follows:
- The tool extracts Dynamic Evidence configuration information and stores it in standard Cúram development artefacts (e.g. DMX, CTX, XML blob/clob and section configuration files). This is done so that that these artefacts can be automatically recreated as part of a database rebuild using the existing Cúram data manager.
- The tool writes its output to a single directory and it expects this to be a standard Cúram component directory (e.g. 'custom'). For example, within this directory it creates subdirectories such as 'codetable', 'data', and 'tab'.
- Extracting database records with their generated primary keys poses a potential risk for key clashes when the records are uploaded. The reason for this is that when the database is rebuilt, the key generation mechanism is reset and it is very likely to produce the same keys as those in the extracted Dynamic Evidence Types. To avoid this, the extractor replaces generated database primary keys with new keys from a pre-defined key range. The key range is applied to each extracted table individually rather than being shared across all tables (this way keys are used more efficiently). Only two tables: CreoleRuleset and CreoleRulesetEditAction share the same key range, because both tables are referenced from the same field in CreoleRulesetCategoryLink table.
- Tab configuration files (for generated Evidence tabs) are extracted as blobs, as part of extracting the AppResource entity. Section configuration files, however, cannot be extracted as individual blobs. They are extracted as contribution section files (and placed in the 'tab' folder), so they can be merged with other component-specific section files on a database build.
- The tool optionally extracts Dynamic Evidence links to Products and Integrated Cases, configurable via the extractor's input parameters. Note that the extractor does not extract Product or Integrated Case configuration information, only the links to them.
- The extractor implements three extraction strategies (the one to be used is determined by the input parameters):
- Extract all Dynamic Evidence Types: All active Dynamic Evidence Types on the system are extracted.
- Extract a list of Dynamic Evidence Types: This strategy allows users to specify a list of Dynamic Evidence Types to extract (using a list of Evidence Type logical names).
- Extract a set of Dynamic Evidence Types identified by Evidence Type code prefix: Dynamic Evidence Type codes are generated using a customizable three character prefix e.g. 'DET'. This extraction strategy allows users to only extract Dynamic Evidence Types that use a specific code prefix.
- Dynamic Evidence Types have localizable descriptions. Prior to Cúram V6.0 SP2 the descriptions for all Dynamic Evidence Types on the system were stored in a single properties file (DynEvd_EvidenceTypeDescriptions.properties) in the AppResource entity. In Cúram V6.0 SP2 this mechanism was changed to store Dynamic Evidence Type descriptions in individual properties resources, one per Evidence Type. If the extractor finds the old evidence descriptions properties file, it will split it into individual Evidence Type specific properties files.
- The extractor extracts the key set (DYNEVDCODE) used to generate Dynamic Evidence Type codes (preserving the Next Unique Block ID for this key set). Dynamic Evidence uses the Cúram key server ability to generate human readable keys. This is used to generate Dynamic Evidence Type codetable codes. When the database is reset, the key generation mechanism is also reset and there is a likelihood of producing keys that clash with previously generated ones. This is best avoided by preserving the state of the Dynamic Evidence key set used to generate Evidence Type codetable codes.
- The extractor extracts both Active and In Edit Evidence Type versions.
- A number of rulesets related to Evidence Type Versions are extracted: generated data and processing rulesets, and custom (calculated attributes, validations, summary information) rulesets. Custom rulesets can be edited by customers. Newly created custom rulesets are extracted by the tool (together with In Edit Evidence Type Versions). However, any changes made to published custom rulesets will not be picked up by the extractor until the changes are published.
- The extractor does not extract localizable resource bundles referenced from rulesets. Rulesets can include localizable resource messages which are stored in resource bundles in the AppResource entity. If users choose to use such messages in customized rulesets they have to handle the extraction of containing resource bundles manually.
- The extractor can either be run from the command line or the Eclipse development environment.
- Before uploading extracted artefacts back to the database, codetables have to be re-generated (via the ctgen target or server build) to include the extracted Dynamic Evidence Type codetable codes.