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 36 Next »

Adaptor Intro: An introduction to YOUnite and Adaptors can be found on the Introduction to YOUnite page

Adaptor Configuration: How to configure and manage adaptors is covered on the Managing Adaptors page.

Adaptor Development: Developing adaptors can be found on the YOUnite Adaptor Guide for Java Developers page.

An adaptor is software that is located within a system that is participating in the sharing of data through the YOUnite Data Hub (via the Message Broker) and acts as the connection point between that system and Data Hub. It focuses on ETL (Extract, Transform, and Load) functions, ensuring the outbound data from that system meets the format requirements of the Data Hub and transforming the inbound data from the Data Hub into what any other system requires. An adaptor may have additional business logic such as filtering for specific data from the Data Hub.

Adaptors perform data operations (CRUD) on data records that conform to one or more data domains (for more information on data domains see the Data Domains page). The data operations an adaptor can perform are referred to as its "Capabilities" and are defined in an Adaptor Capabilities List.

The white ellipse in the diagram below represents a JSON data object being passed between the adaptors and the Data Hub. The data object could have originated in one of several ways. The most common are:

  • By an API POST /drs/assembler request made by an API consumer to the Data Hub
  • An adaptor detecting a change and sending it to the Data Hub
  • The Data Hub receiving a change from an adaptor and routing it out to other adaptors and API consumers that have subscribed to receive notifications for that specific change
  • The Data Hub requiring data from an adaptor





Adaptors and Federated MDRs

In order to provide data management, the YOUnite Data Hub needs to know where the data domain and property(ies) live. Federated Master Data Records (MDRs) are stored in the source system (federated domain) instead of centrally in the Data Hub. The Data Hub contains a reference to the federated domain so it can retrieve the data. In order for this to happen the federated domain elements must be mapped to the YOUnite Data Hub. This mapping can happen organically or by creating a master list of all source system entities that need to be mapped to YOUnite. 

The mapping process includes creating YOUnite data records for each domain entity using the POST /drs request. YOUnite will then contains the uniqueness rules but none of the data records are yet mapped to any of the adaptors' attached systems or services. The adaptor for the domain must be paused while you map the entities in the systems and services attached to the adaptors to the YOUnite data records, linking them together.

See Mapping for Federated Domains for details. 

Adaptors Can Be Either Uni-Directional or Bi-Directional

Uni-Directional - Inbound Only

Uni-Directional - Outbound Only

Bi-Directional

The Infinite Update Issues - the Importance of the equals() Method With Bi-Directional Adaptors

The infinite update problem can occur in the following scenarios:

  • An MDR property at an adaptor is updated by the adaptor and then the adaptor itself sees this as a change and pushes it back out again
  • an MDR property at an adaptor supports two different versions of the same domain and one version receives the update and the second version adaptor code detects the change and pushes it out; this isn't such a problem unless the first version detects it and pushed it back out again
  • an MDR property is changed with value X on one adaptor and some other data integration (DI) solution pushes the change out to another system that is attached to a YOUnite adaptor that detects the change; since the change pushed by the other DI system is identical to the MDR it should not get pushed out again.

This will require storing a hash of the last known value of an MDR or inspecting the last known update hash at the adaptor.

Adaptor Design Pitfalls to be Avoided

Having two uni-directional adaptors (one inbound only and the other outbound only) is to be avoided.

Selecting Enterprise Applications That Can Meet Your Organization's Governance Requirements

Developing adaptors can be the most difficult tasking the the MDM development and implementation phases. While it is unlikely an organization will swap out an existing enterprise applications to meet its governance needs (although, it may be required in some circumstances) an organization can require new applications and vendors can meet the requirements so that their solutions  can be made MDM/Governance aware at the appropriate granularity.

To meet the needs of MDM and governance, new applications and solutions must have robust APIs that allow:

  • Source entity updates that map to the organization's data domain definitions
  • Source entity CRUD operations:
    • Create
    • Update
    • Delete
    • Get
  • Eventing i.e. adaptors should not have to poll a service for changes but should be able to register for change notifications for entities that map to the organization's data definitions
  • Eventing and source entity CRUD operations should be at the data domain property level. This is a critical distinction because if the API only allows change detection at the source record level then governance can only be applied to the source entities in the system at the data record level. Ideally, an organization will want to detect changes and perform CRUD operations at the domain property level. This is the difference between allowing a customer record from being shared or restricted (record level) versus being able to restrict individual properties such as tax ID numbers, phone numbers, etc.
  • No labels