Configuration Deployment

Overview

Socotra Enterprise Core configurations are defined using files, mostly JSON, organized in a pre-defined folder structure. The application loads this folder structure to get settings and definitions for things like account and policy structure, data extensions, data table definitions, document declarations and other behaviors and structures that you define.

Notes

Configuration Structure

The basic structure of the configuration payload is a zip file with a top-level config.json file. Folders can be added that also contain a config.json file and the system will merge these files into a single logical json payload when representing the config datamodel. If creating a configuration zip file manually, users should ensure that the archive is made at the same level as top-level config.json file and any top-level folders. It is also permissible to create the zip at 1 level above this, but there may only be a single folder. Encountering multiple folders or other levels of depth will result in a failed deployment with a path validation error.

Configuration Validation

In order for a config to pass validation, it must meet the following criteria;

  • At least one Account definition must be included.

  • At least one Product definition must be included.

  • Have at least one Charge with type: premium.

  • The following referential integrity checks are also run;

    • If eligibleAccountTypes is specified in the defintion of a Product, each must be the name of an account definition.

    • Each Charge category must be a valid choice.

    • Each Contents value for a product or element must be a valid element name.

    • Each field type for accounts, products, and element extension data must be a valid pre-defined type or a type declared in dataTypes.

    • Each coverage term for a product or element must be one declared in coverageTerms.

    • Any product or element that uses extend must extend from a valid entity

      • e.g. Products may only be extended from other products, and elements may only be extended from non-products.

    • Quantifiers must be valid for the type (i.e. coverage terms may only have blank, ?, or !)

  • In a config, for deployment or re-deployment, at the top level or for any product, if defaultTermDuration is specified, then defaultDurationBasis must also be included.

  • The built-in validation will include both whether the element’s data is conformant with the definition in the config, but also that the JSON itself is conformant. So, if a field is specified as a string but the payload looks like { "name": 42 } then the element may be created and will save, but validation will fail.

Configuration Case Sensitivity

In configuration packages, the property names in JSON for all built-in property names (like startTime, removeCoverageTerms, etc) are case insensitive (i.e. case does not matter, so STARTTIME, REMOVECOVERAGETERMS, or even starttiME would be valid.)

See Also