From message types to structures
Within AFD 1.0 the structure of a message was based on the type of message. For example, the contract message (contractbericht) or loss message (schadebericht). Within such messages, it was recorded which entities and attributes were mandatory or optional, and how they related to each other (see the image below for an excerpt).
Within AFD 1.0 you could, for example, submit an application for insurance or a loan with the contract message. Within SIVI AFS you do this by means of a policyStructure or loanStructure. SIVI AFS has the following AFD structures, with the corresponding message type in AFD 1.0 in brackets:
- policyStructure (contractbericht)
- loanStructure (contractbericht, under construction)
- pensionStructure (contractbericht, under construction)
- masterAgreementStructure (pakketbericht)
- groupStructure (groepbericht)
- claimStructure (schadebericht)
- orderStructure (new)
- partyStructure (relatiebericht)
- objectStructure (new)
- message (new)
- container (new)
- afsTableStructure (new)
- afsStructure (new)
Bridge between data catalog and API-framework functions
In SIVI AFS, the use of AFD structures occupies a prominent place. In thinking about API architectures, the starting point is that functions are defined on the basis of the specific data set to which the function applies. The AFD structures form the basis for data exchange: not only as a structure for the messages, but also for the in- and output of API functions within the API-framework. For these functions, the payload (both input and result message) must comply with one of the AFD structures. For example, the
submitPolicy function must always provide the result message in the
A structure is designed for a specific high level business domain and comprises all entities which are relevant for that domain, without any restriction on the usage of specific entities or attributes. This means that a structure constitutes a subset of the full AFD catalog, which is dedicated to one specific high level domain like for instance policy, claim or party. Structures are the vessels for transporting and recording data with regard to business processes, and allow a maximum of flexibility with respect to available entities and attributes.
A structure does not have any proprietary attributes, it only serves to define a set of entities and their respective relationship(s). (Some structures are allowed to contain a
refKey attribute to make it easy to refer to the top level of the structure, i.e. within a container or message structure.) A structure usually contains either a
commonTechnical entity, and may contain both. A structure may also contain a
document entity that can be used to transmit or store files in any format, pdf, word, excel, image files etc.
When used in messages, top-level structures are not defined within JSON. Structures that are nested under a different structure or entity are explicitly defined. See, for example, masterAgreementStructure, where the top instance of
masterAgreementStructure remains implicit in the message, but underlying instances of
policyStructure are explicitly defined. Note: in XML, structures and entities at the highest level always have an explicit instance.