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 31 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 hub into what any other system requires. It may have additional business logic such as filtering for specific data from the hub.

Adaptors perform data operations 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."

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





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.

Pause/Play

An adaptor's state can be set to Pause or Play, which is part of the PUT /zones/zone-uuid/adaptors/adaptor uuid endpoint. See Changing Adaptor States. An entire zone's adaptor set can be paused or played and there is a scheduler for doing so. 

  • No labels