Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 8 Next »

Outbound Scopes

Scopes are what provide visibility to master data between zones & adaptors.

Scopes are a key component of MDM and are part of what is often referred to as the router. Scopes can be thought of as permissions on out-bound data. Scopes are controlled at various levels:


Source of DataDestinationPriority
Zone[1]Zone[2]

1

Zone[1].Adaptor[x]Zone[2]2
Zone[1].MDR[i]Zone[2]3
Zone[1].MDR[i].MDRproperty[X]Zone[2]4
Zone[1].Adaptor[x].MDRproperty[X]Zone[2]5


* At the highest level a Zone[1] can shutoff all outbound master data changes to Zone[2] and at the lowest level, Zone[1] can shutoff sharing a single attribute on a single adaptor (that it owns) to Zone[2],

* Sharing precedence is based on the priority e.g. If Zone[1] has turned off access to Zone[2] (Priority 1), then all other sharing actions are null.

* Permissions for each element are based on REST operations GET, PATCH, POST and DELETE. An additional operation is added for PUSH  -- where a zone allows another to receive real-time changes however it may be determined that GET will scope will include PUSH.


Inbound Scopes

Background

Generally speaking, metadata is mostly to do (but not limited to) considerations regarding inbound data in a federated data domain.

Types of Metadata

Metadata includes settings for the following:

Incoming Filters

A zone or adaptor has the capability of filtering out changes it has scope to.

  • "forbid" zone - Don't GET or accept any updates from a zone
  • "forbid" adaptor - Don't GET or accept any updates from an adaptor

Classes

  • Adaptor classes: 1, 2, 3: Allow a zone or an adaptor in a zone to set a class level on adaptors that are sharing data with them. 1 is highest and 3 is lowest. For example, if a GET yields three adaptors with the same domain property, and one adaptor is a class 1 and the other are class 2, then the data from the class 1 adaptor is returned in the GET.

Timestamps

  • key/map of change timestamps and hashes
    • if a GET yields two adaptors with the same property and both are the same level, we can take the one with the latest timestamp.

Latency (post pilot)

  • If a GET request is issued with a reduced-latency parameter, the request will query only the adaptors that are in PLAY or PLAY_RO with the lowest latency times.




  • No labels