Registry APIs now support asynchronous processing with status indicators and global task IDs for workflows.

Breaking Changes

New status for registry operations

The behaviour of the Registry APIs has changed to support asynchronous processes. The response payload for all POST, PUT and DELETE endpoints will now include a status property.

{
   status: 'ACCEPTED' | 'PERSISTED'
   ...aditional metadata
}

• ACCEPTED indicates that the request was captured and an asynchronous workflow has started.
• PERSISTED indicates that the request is completed and the data has been persisted.

The bulk, bundle and purge endpoints will now return a taskId property in addition to their workflow IDs. This means that bulkId and purgeId will live side-by-side with a global taskId for the time being.

Eventually, these legacy IDs will be deprecated and only the global taskId will be supported.

New payload for single registry operations

When creating or upserting a single resource or relationship, the record data is now nested within a resource object in the response payload instead of being at the root-level.

// Previous response payload
{
  "data": {},
  "id": "abc",
  "meta": {}
}

// Current response payload
{
  "resource": {
    "data": {},
    "id": "abc",
    "meta": {}
  },
  "status": "PERSISTED"
}

Updated format for partition record/relationship source identifiers

A partition record/relationship often contains source identifiers in the meta.identifier section, pointing back to the source records/relationships that make it up. The previous convention for those identifiers was the following:

{
  "identifier": [
    {
      "system": "{sourceKey}",
      "value": "{sourceId}",
      "use": "source"
    }
  ]
}

// Example 
{
  "identifier": [
    {
      "system": "source-a",
      "value": "1234567890",
      "use": "source"
    }
  ]
}

The source identifier convention has been updated to provide more information about the source record or relationship. The new expected format is:

{
  "identifier": [
    {
      "system": "source",
      "value": "{sourceId}",
      "use": "{sourceKey}.{sourceRecordType}"
    }
  ]
}

// Example
{
  "identifier": [
    {
      "system": "source",
      "value": "1234567890",
      "use": "source-a.organization"
    }
  ]
}

Features

• Adds option to use clinia models in the ingestion pipeline for chunking and embedding data

Improvements

• Improvements in propagation performance of relationships from source to MDM to partitions.
• Improved search performance for data partitions with better indexing
• Clearer error messages for purge operations
• Improve the consistency of relationship identifiers in GET endpoints and query filters