View Source

To fully leverage the YOUnite ecosystem, organizations need to fully understand the following areas of integration:

Operational: Managing zones, users, groups, roles, and permissions using the YOUnite API. The YOUnite UI is an example of an application that consumes the YOUnite API and makes operational and Data Governance requests on behalf of the logged-in user. This functionality can also be built into the organization's own applications.
Data Stewardship and Governance: Creating data domains and managing scope (ACLs) using the YOUnite API.
Creating and mapping source entities to YOUnite data records. This can be done with the YOUnite API. Adaptors also perform creating and mapping tasks over the YOUnite message bus.
Integrating data and keeping source entities in sync. This is managed by adaptors connected to the YOUnite message bus.
Receiving notifications of data record changes so that applications can initiate their own work flows.
Retrieving Data Records: The YOUnite API has an endpoint for retrieving data records (both federated data records and those stored in YOUnite). This endpoint is generally used by applications that don't have access to a source system that is connected to YOUnite through an adaptor or when the adaptor doesn't support a data domain required by the application.

Once the operational and data governance resources are created and source records are mapped to YOUnite data records (items 1 through 3 above), a functioning YOUnite MDM ecosystem performs three primary tasks using both the YOUnite message bus and API interfaces:

Primary Task	Description	Interfaces Used
Data Integration	Generally business logic in adaptors is kept to a minimum. The sole purpose of adaptors is to both detect changes in source entities and publish them to YOUnite and to subscribe to changes published by other adaptors and process them by updating entities in the source system attached to the adaptor.	Adaptors connected to both source systems and the YOUnite message bus.
Governance	Scopes can be managed manually by the Data Governance Steward (DGS) and the Zone Data Stewards (ZDSs) or they can be managed programmatically by applications when well-defined events occur. For example, if a customer signs up for a new service, scope can be set so that data in a source system that already contains the customer's data is granted to a system that holds customer records for the new service.	YOUnite API
Notifications	Changes in data can trigger events in applications and services. YOUnite allows applications and services to register for events so that they can be notified when changes occur allowing the services and applications to start their own workflows.	YOUnite API
Operational Data Store	This is generally used for systems that are not connected to YOUnite through an adaptor or when the adaptor doesn't support a data domain required by the service.	YOUnite API

CCC Master Data Management > Developing YOUnite MDM Aware Applications and Services > wiki-layer3.png (YOUnite as an Operational data store and event/change notification system)

YOUnite acts as an operational data store and can deliver event & change notifications

To develop adaptors see the YOUnite Adaptor Guide for Java Developers. To use the YOUnite API see the YOUnite API.

1. Operational

zones

permissions

access tokens

UI and seeing effective permissions

2. Data Stewardship and Governance

See Domain Related Permissions & Inbound/Outbound Scopes for overview of scopes.

Inbound

Setting

Outbound

Setting

3. Creating and Mapping Source Entities to YOUnite Data Records

Entities in source systems need to be mapped to YOUnite data records that are part of YOUnite data domain.

See Linking YOUnite Data Records to Entities at the Source Systems.

4. Integrating Data and Keeping Source Entities in Sync

Adaptors is a key step in creating a YOUnite MDM ecosystem.

See YOUnite Adaptor Guide for Java Developers.

5. Receiving Data Record Changes (Data Notifications)

TODO: Move the detailed description of this to another page

Event Notifications & Webooks

Webhooks allow applications to setup integrations that subscribe to certain YOUnite events. An API consumer integrates a webhook by following these steps:

Create a URL endpoint where YOUnite notifications can be delivered.
1. When an event occurs, a notification is triggered and an HTTP POST payload is sent to this URL endpoint.
Register the URL endpoint with YOUnite and configure which events the consumer wants to subscribe to.

When a YOUnite subscribed event occurs, the consumer will receive an HTTP POST request and payload to the registered URL endpoint.

6. Receiving Metadata Changes (Metadata Notifications)

YOUnite Events (TODO Anuj needs to help Mark update this)

When registering a webhook, the consumer chooses which events they want to subscribe to. The list of subscribed events can be changed at anytime. The following is list of event types that a subscriber can be notified of on a per-zone basis:

Event	Event Type
A zone is created	zone_post
A zone is updated (including moved)	zone_update
A zone is deleted	zone_delete
A data domain is created or a new version of the data domain has been created	domain_post
A data domain has been updated	domain_update
A data domain has been deleted	domain_delete
A data record has been created for a given data domain (TBD)	dr_post
A data record has been updated in a given data domain (TBD)	dr_put
A data record has been deleted in a give data domain (TBD)	dr_delete

Notification Event Response Body

The notification's response body includes the following:

key	value
description	A full description of the event - i.e. a full concatenation of the information described below for easy displaying.
changeVersion	The resources change version.
createdDate	The date the resource was created.
Name	The resource name.
message-id	The JMS message ID.
dateCreated	Unix timestamp of when the event notification was sent.
uuid	Zone UUID of target resource.
eventType	One of the above described "Notification Event Types."
originatorName	The name of the zone that generated the event.
originatorUuid	The UUID of the zone that generated the event.
timestamp	The time the notification was created.
actions	Some PUT & PATCH commands provide multiple actions and this list contains a description of what actions were performed.
optional	Other key/values that are appropriate for the notification type.

6. Getting Data Records

Applications can use YOUnite as an operational data store. TODO ... point of view golden/silver request options.

See the /drs endpoint in the YOUnite API.

TODO examples