Configuration Deployment

Overview

Socotra Insurance Suite 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.

Configuration Structure

The basic structure of the configuration payload is a zip archive with a top-level config.json file that contains the desired ConfigurationRef entities. Users can also choose to structure the config with directories named for the various entities and their instances, each containining their own config.json.

For example, the following two config structures are equivalent:

Single top-level ``config.json``:

{
    "accounts": {
        "ConsumerAccount": {...},
        "CommercialAccount": {...}
    },
    "products": {
        "PersonalAuto": {...},
        "HO3": {...}
    },
    "defaultCurrency": "USD"
}

Structure with directories named for the various entities and their instances:

config
└── config.json //contains some global defaults e.g. defaultCurrency
└── Accounts
│   └── ConsumerAccount
│   │   └── config.json
│   └── CommercialAccount
│       └── config.json
└── Products
    └── PersonalAuto
    │   └── config.json
    └── HO3
        └── config.json

The system will merge these files into a single logical datamodel which can be retrived from the datamodel API. 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 another level above this, but there may only be a single folder path - encountering multiple folders or other levels of depth will result in a failed deployment with a path validation error.

See the complete Configuration reference here

Configuration Validation

In order for a configuration deployment 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.

• It must 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, element or other config entity that uses extend to inherit, must do so from a valid, like-typed entity

    • e.g. Products may only be extended from other products, exposure elements may only be extended from other exposure elements etc.

  • 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

Upon deployment, Socotra converts many of the elements in the configuration package to a Java data model that is used throughout the system to govern the structure of data and enforce strict typing. As a result, there are implications for the casing of configuration entities which are enforced through validation prior to deployment.

In short, the following convention applies:

1. The name of any configuration entities that will be rendered to a Java Class, must be declared in PascalCase.

2. Any enum or attribute of Class entities, must be declared in camelCase.

3. References between entities are case sensitive: For example, while an Auto-Renewal Plan name may be defined in either PascalCase or camelCase, when that plan name is referenced as a Product’s defaultAutoRenewalPlan, casing should be consistent.

4. The level an entity resides within the config hierarchary has no bearing on its casing requirements.

The following configuration class entities are rendered as Java Classes and so must be declared in PascalCase:

• Accounts

• Products

• PolicyLines

• ExposureGroups

• Exposures

• Coverages

• CoverageTerms

• Custom DataTypes

• Tables

• ConstraintTables

• Secrets

• Payments

• Disbursements

The following properties of configuration class entities must be declared in camelCase:

• CoverageTerm Options

• Table Columns

• ConstraintTables Columns

• Secrets attributes

• Work Management Activity categories and types

• Work Management Qualification names

• Work Management AssignmentRoles

• All extension data properties (data field names for any entity)

Inheritence Case Sensitivity

Entities that are eligible for inheritence (such as Products, Elements, and Payments etc) may be designated as being abstract, meaning they can only be inherited and never instantiated themselves. While it is best practice to consistently apply casing styles, abstract entities are not strictly subject to the same PascalCase validations as concrete versions of the same class entity. When actually inherited however, the camelCase validations still applies to the class entities properties.

Note

Built-in property names leveraged when exercising the API (like startTime or autoRenewalPlanName for quote requests) are case insensitive (i.e. case does not matter, so STARTTIME, AUTORENEWALPLANNAME, or even starttiME would be valid.)

See Also

• Configuration Redeployment