Defining entities uniquely within the context of a message

It must be possible for every instance of an entity to be uniquely identified within an AFD message, structure or function. This can be done in two ways: with functional and/or technical identifiers. With functional identifiers, entities can be uniquely identified based on attributes that have value in the outside world. For example: the licensePlate of an object, or the contractNumber of a policy or mortgage. These types of identifiers are not explicitly designated as such in the model, but can of course be used as such in certain contexts.

In addition, it remains possible to use sequenceNumber (VOLGNUM in AFD 1.0), which in combination with entityType must always be unique. This unique combination forms a technical identifier of an entity within the message.

Defining entities uniquely outside the context of a message

It must also be possible for every instance of an entity to be uniquely identified outside an AFD message, structure of function: for example when data is stored in internal databases, and data from future AFD messages needs to be linked to stored information. Again, both functional and/or technical identifiers can be used. To ensure uniqueness over multiple messages, AFD 2.0 introduces the (optional) refKey attribute: a technical identifier which – when used – must be unique over multiple messages, and is mainly intended for the purpose of data storage.

Referrals

New in AFD 2.0 is the possibility to explicitly refer to another entity. For example, within a policy component, an explicit reference can be made to the corresponding package policy. In this way, the relationship no longer needs to be implicitly derived from the hierarchy. New attributes for these references are included in the data catalog. For example, within a policy component, the explicit reference to the relevant package can be established using the packageRef attribute.

Example

The example below shows multiple coverage and objects. The same message would become unclear with hierarchies: both motorVehicle objects must refer to the same coverage entity. In AFD 2.0 this is solved by referring explicitly in the relevant coverage entity to the refKey of the relevant object entities, via the objectRef array.

{
	"policy": [ {
		"entityType": "policyDetails",
		"refKey": "P20190101010",
		"porCompany": "M088",
		"contractNumber": "P20190101-010",
		"party": [ {
			"entityType": "policyHolder",
			"refKey": "9082315781",
			"firstName": "Maria",
			"surname": "de Jong"
		} ],
		"object": [ {
			"entityType": "motorVehicle",
			"refKey": "SIVI20",
			"licensePlate": "SIVI20",
			"carManufacturer": "Fiat",
			"type": "Panda"
		},
		{
			"entityType": "motorVehicle",
			"refKey": "VISI40",
			"licensePlate": "VISI40",
			"carManufacturer": "Citroen",
			"type": "DS"
		},
		{
			"entityType": "building",
			"refKey": "building1208935",
			"buildingType": "00001",
			"constructionYear": "1954",
			"diy": false
		} ],
		"coverage": [ {
			"entityType": "hullVehicle",
			"refKey": "78927127",
			"coverageCode": "2002",
			"deductibleAmount": "799.85",
			"objectRef": ["SIVI20", "VISI40"]
		},
		{
			"entityType": "building",
			"refKey": "089251376",
			"coverageCode": "5001",
			"deductibleAmount": "15990",
			"objectRef": ["building1208935"]
		} ]
	} ]
}

Feedback

Thanks for your feedback.

Post your comment on this topic.

Post Comment