Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

DR metadata is information about the adaptor and zone for the DR, and any changes that have occurred to the DR.Below content taken from: YOUMDM-527Metadata, in MDM, is generally related (but not limited) to notifications about inbound data in a federated data domain and relates to adaptors and Master Data Records (MDRs).

Note: These notifications are different from the notification messages that are sent between adaptors through the message bus to keep them in sync. 

The YOUnite notification service and related resources notify interested parties about events in the MDM system. For example, if an API client is registered for notifications on student record, when a student record is updated the API client is sent a notification message that informs them of the updated record.

For example a client interested in receiving metadata (e.g. zones, domains) notifications would POST a registration request to:

  api//notifications/registration/metadata 

with request body:

{
"callbackUrl":"http://localhost:8399/domainAndZone",
"metadataActions": [
{"entityType": "Domain",
"actions":["POST", "DELETE", "PUT"]},
{"entityType": "Zone",
"actions":["POST", "PUT"]}
],
"filter": ""
}


As YOUnite Data Hub events occur, notification messages are produced and sent to zone users (consumers). The consumer specifies a callback URL (WebHook) that the YOUnite Data Hub uses to POST notification messages to.

There are two types of notification messages:

  1. Metadata notifications: to notify the consumer of changes in metadata, for example Zone, Domain.
  2. Data Record (DR) notifications: to notify the consumer of changes in DRs, for example, as a DR is created or updated.

In addition to specifying interest in specific metadata and data notifications, registering a notification includes:

  • A callback URL
  • An optional notification token (NTOKEN). All notifications will include this token in the NTOKEN header so the callback can verify the notification origin.

Note that the consumer in case of callback delivery:

  • Is acting as a server and is expected to embed/implement a web server
  • Handles POST requests at the location specified by the callback URL
  • Can inspect the notification token in the NTOKEN header
  • Receives a YOUniteNotification object in the request body
  • Should return a 2xx HTTP response

...



"forbid" adaptorDon't GET or accept any updates from an adaptor
"forbid" zoneDon't GET or accept any updates from a zone

Classes

...

a zone

...

From YOUMDM-485: Router 0.4 - MDR- GET .pdf

Given an MDR uuid:

  • Show all adaptors tied to an MDR
    • include zone and adaptor scopes
    • Display each adaptor's state
    • Show Adaptor's CLASS
    • Show ACLs
  • Show ACLs

Show the probable adaptor that will provide the source of truth for each property in an MDR

From YOUMDM-487:

Adaptor Metadata

Allow the consumer to set an adaptor's CLASS to either 1, 2 or 3.

These settings are made between adaptors of the same and different zones.

This setting is made in both directions:

Adaptor X may set AdaptorY to level2
but
ADAPTORY may set AdaptorX to level1

From YOUMDM-488:

The sub-task describes the needs of an DR metadata object see Image Removed YOUMDM-540 OPEN andImage Removed YOUMDM-539 CLOSED . Other aspects to will be needed (see Image Removed YOUMDM-209 OPEN ) but this will be an ever evolving object or set of objects.

Update RAML documentation as needed.

YOUMDM-539:

When assembling an MDR consider the metadata:

  • FORBID
  • CLASS
  • TIMESTAMP (in the MDR)

Adaptor Metadata

Allow the consumer to set an adaptor's CLASS to either 1, 2 or 3.

These settings are made between adaptors of the same and different zones.

This setting is made in both directions:

Adaptor X may set AdaptorY to level2
but
ADAPTORY may set AdaptorX to level1

=====

2/9/18 Diana: The content below is in-progress as I assemble content from disparate sources to try and weave into something coherent.

Below content taken from: https://younite.atlassian.net/wiki/spaces/PDOCS/pages/38502414/Notification+Service

Note: the returned object can be an assembler URL or the assembler object itself. See notes above and in JIRAs.

Metadata, in MDM, is generally related (but not limited) to notifications about inbound data in a federated data domain and relates to adaptors and Master Data Records (MDRs). (DAB: or zones and domains?)

Note: These notifications are different from the notification messages that are sent between adaptors through the message bus to keep them in sync. These notifications are xx (DAB: fill in the xx...)

The YOUnite notification service and related resources notify interested parties about events in the MDM system. For example, if an API client is registered for notifications on student record, when a student record is updated the API client is sent a notification message that informs them of the updated record.

For example a client interested in receiving metadata (e.g. zones, domains) notifications would POST a registration request to  api//notifications/registration/metadata with request body

...




...