# Configuration Deployment



Overview [#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](/configuration/data-extensions/overview), [data table definitions](/configuration/resources/data-tables), [document declarations](/configuration/resources/documents) and other behaviors and structures that you define.

Configuration Structure [#configuration-structure]

The basic structure of the configuration payload is a zip archive with a top-level `config.json` file that contains the desired <ApiLink name="ConfigurationRef" /> entities.
Users can also choose to structure the config with directories named for the various entities and their instances, each containing their own `config.json`.

For example, the following two config structures are equivalent:

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

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

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

```text
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 retrieved from the <ApiLink name="fetchConfigDefinition">datamodel API</ApiLink>.
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 <ApiLink name="ConfigurationRef">Configuration reference here</ApiLink>

Configuration Validation [#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 definition of a *Product*, each must be the name of an account definition.

  * If `eligibleTransactionTypes` is specified in the definition of a *Product*, each must be the name of a transaction 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 <ApiLink name="CoverageTermRef">coverageTerms</ApiLink>.

  * 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.

<span id="configuration_element_name_length_limits" />

Configuration Element Name Length Limits [#configuration-element-name-length-limits]

Names for the following configuration elements are limited to 65 characters:

* Accounts
* Products
* Payments
* Disbursements
* Tables
* Constraint Tables
* Range Tables
* Secrets
* Custom Events
* Contacts
* FNOLs
* Schedules

Names for all other configuration elements with `data` extensions are limited to 67 characters, and those without `data` extensions are limited to 120 characters.

<span id="configuration-case-sensitivity" />

Configuration Case Sensitivity [#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 custom data types, elements and coverage terms must be declared in the same casing as the original definition.
4. References between other entities are case sensitive: For example, while an <ApiLink name="AutoRenewalPlanRef">Auto-Renewal Plan</ApiLink> name may be defined in either `PascalCase` or `camelCase`, when that plan name is referenced as a Product's `defaultAutoRenewalPlan`, casing should be consistent.
5. The *level* an entity resides within the config hierarchy has no bearing on its casing requirements.

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

* <ApiLink name="AccountRef">
    Accounts
  </ApiLink>
* <ApiLink name="ProductRef">
    Products
  </ApiLink>
* <ApiLink name="ElementRef">
    PolicyLines
  </ApiLink>
* <ApiLink name="ElementRef">
    ExposureGroups
  </ApiLink>
* <ApiLink name="ElementRef">
    Exposures
  </ApiLink>
* <ApiLink name="ElementRef">
    Coverages
  </ApiLink>
* <ApiLink name="CoverageTermRef">
    CoverageTerms
  </ApiLink>
* <ApiLink name="DataTypeRef">
    Custom DataTypes
  </ApiLink>
* <ApiLink name="TableRef">
    Tables
  </ApiLink>
* <ApiLink name="ConstraintTableRef">
    ConstraintTables
  </ApiLink>
* <ApiLink name="SecretRef">
    Secrets
  </ApiLink>
* <ApiLink name="PaymentRef">
    Payments
  </ApiLink>
* <ApiLink name="DisbursementRef">
    Disbursements
  </ApiLink>

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

* <ApiLink name="CoverageTermOptionRef">
    CoverageTerm Options
  </ApiLink>
* <ApiLink name="ColumnRef">
    Table Columns
  </ApiLink>
* <ApiLink name="ColumnRef">
    ConstraintTables Columns
  </ApiLink>
* <ApiLink name="SecretRef">
    Secrets attributes
  </ApiLink>
* <ApiLink name="WorkManagementRef">
    Work Management Task categories and types
  </ApiLink>
* <ApiLink name="WorkManagementRef">
    Work Management Qualification categories
  </ApiLink>
* <ApiLink name="WorkManagementRef">
    Work Management User Association Roles
  </ApiLink>
* <ApiLink name="PropertyRef">
    All extension data properties (data field names for any entity)
  </ApiLink>

Inheritance Case Sensitivity [#inheritance-case-sensitivity]

Entities that are eligible for inheritance (such as <ApiLink name="ProductRef">Products</ApiLink>, <ApiLink name="ElementRef">Elements</ApiLink>, and <ApiLink name="PaymentRef">Payments</ApiLink> 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.

<Callout>
  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.)
</Callout>

See Also [#see-also]

* [Redeployment](/configuration/general-topics/redeployment)