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.
Infinite Update
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.