A data domain (domain) refers to a data model, such as student or course, and is defined by the parties responsible for data governance. The data domain defines the model schema and other attributes for that focus. Common examples of data domains are customers, students, employees, parts, and product orders.
...
Federated: Federated domains do not store their data in YOUnite but retrieve and update the data on the systems in which it resides. For example, MIS, ERP, or CRM systems. Federated domains require adaptors, metadata, and governance configurations and are covered in detail *TODO: TUTORIAL ON FEDERATED*
Domain Model Schemas
A domain Model Schema refers to the attributes (properties), format, and other metadata that defines how a specific domain should expect to store the data (either in the YOUnite Data Store or Federated), for the purposes of standardizing how data is exchanged between systems. The Data Governance Steward is responsible for configuring and maintaining domain model schemas. A domain model schema is a JSON object describing/defining the properties for the domain's schema. The root node of the model schema is the properties element. See Valid Property Names and Valid Types for ModelSchema Properties below.
...
property | required | valid values | description |
---|---|---|---|
name | yes | Must be between 2 to 128 characters long and must start with an alpha character. The | The domain name. Must be unique to the entire YOUnite deployment since domains are typically shared. |
description | no | 0 to 255 characters long. If longer it will be truncated. | A human readable description of the domain. |
zoneUuid | no | Owning zone's domain UUID | The zone that the domain, the domain's versions, and its data records will be tied to. If this is omitted the caller's current zone will be used. Note that the caller must have permissions to create a domain. |
domainType | no | MDM_DATA_STORE or FEDERATED | The domain type can be either: MDM_DATA_STORE, which is when the domain's data records are stored in YOUnite. This is used when the entire organization is comfortable or mandated to migrate a domain to a single store. MDM_DATA_STORE is optimal for reference data such as a list of states, countries, zip-codes, etc. FEDERATED domains do not store their data in YOUnite, but reference and update data on the systems in which it resides. Federated domains require adaptors, metadata, and governance configurations that are covered in detail. |
...
property | required | valid values | description |
---|---|---|---|
modelSchema | yes | See Model Schema Properties and Post a Domain below for details. | A JSON model describing the schema for the data domain; it defines the properties that make up the domains schema. The root node of the model schema is the properties element. |
description | no | 0 to 255 characters long. If longer it will be truncated. | A human readable description of the domain version. |
fastDuplicateDetectionProperties |
Once the domain/version has been created you can POST data records to, and retrieve data records from, the domain.
...
Code Block | ||
---|---|---|
| ||
{ "name": "states", "version": 1, "json": { "name" : "California", "abbreviation" : "CA" } } |
NoteNotes: In
- In a federated domain you will need to Map the data record.
- Inside the value portion of the
json
node, all of the double quotes must be escaped with a backslash (\). Newlines have been added above for readability but they should not be included in the request body. The request should look like this:
Code Block | ||
---|---|---|
| ||
{
"name": "states",
"version": 1,
"json": "{ \"name\": \"California\", \"abbreviation\" : \"CA\"}
} |
Retrieving Data Records from the Domain
Anchor | ||||
---|---|---|---|---|
|
...