Structures: general rules
The general rule for structures is that structures should not be nested under other structures: for example, if you want to include claim data under a ticketStructure, you include a claim entity (and not a claimStructure) under the ticket entity of the ticketStructure.
In addition, an important starting point for AFD structures is, that only one core entity occurs at the highest level: for example, the party entity in the partyStructure. At the top level of the structure, next to this core entity, only the technical entities (commonFunctional, commonTechnical, error), the process entity and the document entity may occur.
Need for more top-level entities
Still, with specific messages you may want to include multiple entities, while nesting is not an option. Consider, for example, data about customers in a mortgage application. You can register a couple applying for a mortgage as two parties in a partyStructure. But if their address details match (as they usually will), you don’t want to nest an identical address entity under both party entities twice. A top-level address entity, with references from the relevant party entities, is then desirable.
That is why SIVI offers – in specific cases – the possibility to deviate from the general rules regarding structures. This is possible for certain instances of certain structures. We call such structures superStructures, and they do not get the name of the main entity (as there can be several main entities) but of the application/domain. A superStructure uses entities from other structures, but doesn’t have entities by itself.
personalDataStore
The personalDataStore is an example of a superStructure. Several parties struggled with the registration of customer data. In order to develop a 360° customer perspective, advisors have an increasing interest in aggregating and collecting customer data from as many angles and perspectives as possible. And even. if the customer gives permission, share these data with other parties in (for example) the mortgage application process.
Several types of data are needed in the example of a couple applying for a mortgage. Some data are specific for each party, e.g. name, date of birth, income and health data. Other data apply to the couple, like address, joint loans and mortgages. Hence you want to record more than just the party from the standard version of the partyStructure at the highest level.
Explicit references in SIVI AFS ensure that it is clear which address belongs to which customer. The couple applying for a mortgage consists of two instances of the party entity, both with entityType customer. Add the attribute objectRef to both party entities, each objectRef referring to the object entity of that party. If both parties live at the same addres (as described in the JSON example below), both party entities refer to the same object entity. In this case it is sufficient to add the object entity itself only once.
JSON example
Below is an example of a personalDataStore, with both party (two customers) entities and an object (building) entity at the highest level. Note that at the top level within JSON, the personalDataStore entity is not explicitly mentioned. In XML, the structure is always explicitly defined (as personalDataStore) at the highest level.
{
"commonFunctional": [ {
"entityType": "default",
"dataCatalogVersion": "34C",
"afdDefinitionName": "our custom Personal Data Store",
"afdDefinitionVersion": "001.00",
} ],
"party": [ {
"entityType": "customer",
"objectRef": ["currentHomeAddress"],
"surname": "Janssen",
"firstName": "Marieke"
},
{
"entityType": "customer",
"objectRef": ["currentHomeAddress"],
"surname": "Janssen",
"firstName": "Frans"
}],
"object": [ {
"entityType": "building",
"refKey": "currentHomeAddress",
"address": [ {
"entityType": "default",
"street": "Van Broekhuizenstraat",
"houseNumber": 20,
"city": "Almere"
}]
}]
}AOS
The personalDataStore can be found and used within SIVI AFS Online Samenstellen (AOS) at the SIVI website.
Feedback
Powered by
Post your comment on this topic.