ADR: Additional attributes in Storage record create and update notification events
Additional attributes in Storage record create and update notification events
Context & Scope
Information received from notification service on record create/update after recent ADR has:
3 fields like below in case of record create event
{
"id":"slb:Wellbore:id1",
"kind":"slb:wks:master-data--Wellbore:1.0.0",
"op":"create"
}
and 4 fields like below in case of record update event:
{
"id":"slb:Wellbore:id1",
"kind":"slb:wks:master-data--Wellbore:1.0.0",
"op":"update",
"previousVersionsKind": "slb:wks:master-data--Wellbore:1.0.0"
}
However, storage service when creating or updating the records has more information than this and publishing it can be useful for applications who are consumers of these notification events.
For example, specific blocks from a record like ACLs, legal tags and record tags can only be updated using storage service's PATCH API and in such cases record version is not changed. This information is known to storage service when processing the PATCH request and; if
published; can be used by consumer applications to decide whether to process the record or not. However these details are not published in the current notification events.
Tradeoff Analysis
Consumer applications can keep more information about the previously processed records, their ids, versions etc. and decide whether to process the record received in new event or not, but it will require a lot of book-keeping from the consumers side and instead the originator of the event i.e. storage service can provide this information.
Consumer applications can read the latest version of the record and compare it with previously processed records and decide whether to process the record received in new event or not, but it will require reading every record from the event which will increase load on storage service. Instead if the storage service can provide this information as a part of record change events, a lot of processing at consumers side can be saved.
Decision
We can enhance current behavior of storage service and provide more information in the record change event. Downstream services must be updated to consume the updated events structure. Currently the record changed event is structured as below
{
"id":"slb:Wellbore:id1",
"kind":"slb:wks:master-data--Wellbore:1.0.0",
"op":"create"
}
or
{
"id":"slb:Wellbore:id1",
"kind":"slb:wks:master-data--Wellbore:1.0.0",
"op":"update",
"previousVersionsKind": "slb:wks:master-data--Wellbore:1.0.0"
}
We would like to publish below additional information when the record is created i.e. when op is create
.
New attribute version
: to show the current/latest version of the record.
create
event with new attribute
{ "id":"slb:Wellbore:id1", "kind":"slb:wks:master-data--Wellbore:1.0.0", "op":"create", "version":1637131609117665 }
We would like to publish below additional information when the record is updated i.e. when op is update
.
- New attribute
version
: to show the current/latest version of the record. - New attribute
previousVersion
: to show the previous version of the record. - New attribute
modifiedRecordBlocks
: to show the updated record blocks like data, recordTags, legalTags, ACLs, kind
update
event with new attributes in case of no version change
{ "id":"slb:Wellbore:id1", "kind":"slb:wks:master-data--Wellbore:1.0.0", "op":"update", "version":1637131609117665, "previousVersion":1637131609117665, "modifiedRecordBlocks":"recordTags, legalTags", "previousVersionsKind": "slb:wks:master-data--Wellbore:1.0.0" }
update
event with new attributes in case of version change
{ "id":"slb:Wellbore:id1", "kind":"slb:wks:master-data--Wellbore:1.0.0", "op":"update", "version":9117665163713160, "previousVersion":1637131609117665, "modifiedRecordBlocks":"data", "previousVersionsKind": "slb:wks:master-data--Wellbore:1.0.0" }
Consequences
- Record change event needs to send new attributes suggested above in case of create and update events.
- Register service and accompanying documentation needs to update the example record changed event information to reflect the new attributes in list topics API.
- Consumer applications need to react to the updated event information from OSDU notification service.