ADR: Replay API

Two New API in Storage service as part of Replay flow will be introduce in the storage service.

  • [] Proposed
  • Trialing
  • Under review
  • Approved
  • Retired

Context & Scope

This ADR is centered around the design of the new replay API within OSDU's storage service which is introduced as the part of the Replay ADR. The purpose of this Replay API is to publish messages that indicate changes to records, which are subsequently received and processed by consumers. It's important to note that the handling of these messages follows an idempotent process.

Terminology

Name Explanation
Record The record is stored in OSDU Data Platform in two parts, i.e., document database, which contains basic data (id, kind, legal information, and access permissions), and file storage in a Java Script Object Notation (JSON) format, which contains other relevant information of the record. We are interested in the document database part.

Tradeoff Analysis

The new APIs does not represent a breaking change of any other API, and consequently neither for the consuming applications. Only concerned-consuming applications would benefit from this new feature, while it remains entirely transparent for others.

Additional Requirement

The newly introduced APIs must facilitate Collaboration workflows through the utilization of the x-collaboration header. Additionally, the replay mechanism should ensure the accurate publication of collaboration context information in the corresponding event.

Decision

The proposal is to provide POST and GET Replay API -

The new APIs does not represent a breaking change of any other API, and consequently neither for the consuming applications. Only concerned-consuming applications would benefit from this new feature, while it remains entirely transparent for others.

API fields Explanation
kind It specifies to what Kind the schema belongs to. [optional]
repalyId It represents status id. [required]
operation Define the replay operation to be carried out. [required]
filter Define based on which field the record is selected. [optional]
Allowed roles for API access : users.datalake.ops
Method API Endpoint Design
POST v1/replay Request Example -

1. Description - This API request will reindex all the storage records.

This phase we will pass empty body for reindexall

{

}

In next phase -

operationrepaly

2. Description - This API request will reindex the specific kinds of storage records in this operationName is optional by default, it will reindex specific kinds with filter field. Currently we will replay for single kind only so the array of kind will be restricted to size one.

operationrepaly

Response example – responsepostreplay

GET replay/status/{id}

Request:

1. Response Replay in Progress:

a) Scenario - In Replay All

replaystatusAllKind
b) Scenario - In Replay single kind

replaystatusforsinglekind

2. Response Replay in Failed:

a) Scenario - In Replay All

replayFailedForAllKind
b) Scenario - In Replay single kind

replayfailedforsinglekind


API spec swagger yaml -ReplayAPISpecs.yaml
Edited by Akshat Joshi