7.2. JSON Examples

An AFD-definition can be composed for different purposes: service, data storage, batch and reference. This paragraph shows some examples of the output of generic AFD-definitions in case of a service (including a validation rule), data storage, batch and reference.

Output of an AFD-definition as a JSON Schema in case of a service

In the AOS tool, organizations have the capability to create their own AFD-definitions tailored for their products, web services, functions and related components. For AFD 2.0, the tool generates an AFD-definition represented as a JSON Schema, This JSON Schema serves as a foundation for validating AFD messages and serves as a blueprint for configuring interfaces, APIs, and other tooling. For a description of services, see manual SIVI All Finance Standard.[link].

Below is an example of such an AFD-definition (click on the image to open), illustrating a newContractRequest function utilizing the policyStructure baseline. From this example, one can infer the following:

• The entities commonFunctional, commonTechnical and policy are mandatory at the top level of the message.
• Each of these entities must occur exactly once (as specified by minContains = 1 and maxContains = 1).
• The entityType attribute is compulsory under each entity (a non-configurable aspect across all AFD-definitions in AOS).
• The party entity with entityType intermediary and policyHolder are both mandatory.
• The party entity with entityType regularDriver is optional, but if used, the birthDate and refType attributes become required.
• The object entity with entityType motorVehicle is required and contains a mandatory attribute fuel which references a predefined codelist (ADNBRS). Only a subset of code values from this codelist is selected for this particular AFD-definition.

Validation rule in JMESPath

The example below shows a complete validation rule in JMESPath (click on the image to open). The rule consists of a commonFunctional section and an actual validation rule. The validation rule specifies that in the case of an coverage entity with entityType thirdPartyLiability an object entity with entityType motorVehicle should be present. An explanation of validation rules is available in 3.4 Validation rules in JMESPath.

Output of an AFD-definition as a JSON Schema in case of registration for data storage

Registration of data involves the storage of data with a certain purpose, for example, the registration of a car policy (click on the image below to open the example). In addition to vehicle data, you also see a set of insurance data. An AFD-structure is the starting point for data storage. A message for registration does not contain any entities or attributes, related to the execution of transactions.

The attribute ‘statusType’ is typically used for storage. It indicates the status of the data stored: for example 1 (ongoing), 3 (canceled) or 39 (future policy). This entity statusType should usually be included within the entity policy, entityType ‘policyDetails’. In case of an advanced registration this attribute can also be included in all entities where a status code is important.

Other elements used in case of data storage are the attributes changedBy and creationDateTime (both under the entity commonTechnical). The attribute changedBy identifies the name of the person that made the last change to the AFD-definition.

Output of an AFD-definition as a JSON Schema in case of a batch

A batch message allows users to send a group of messages simultaneously: in one batch. The example AFD-definition below contains one masterAgreement entity and one policy entity at the highest level (click on the image to open), but more are allowed. It is also allowed to have more than one commonFunctional in a batch message. The commonFunctionalRef attribute is used to refer from other entities to a specific commonFunctional entity.

Output of an AFD-definition as a JSON Schema in case of reference

References of data involve the storage of data with a certain purpose, for example to indicate which data elements should be displayed on a screen in a specific situation.
In the example below, it involves the reference to a car policy. In addition to vehicle data, you also see a set of insurance data (click on the image to open). An AFD-structure is the starting point for references. The example shows a policyStructure. A message for references does not contain any entities or attributes, related to the execution of transactions.