Content Motation
What is Content Motation?
Content Motation is the primary Motation object created and used. Every Motation will have a content Motation object. A content Motation then has dependencies that are other Motation objects which provide the definition, relationships, etc. which are synced prior to the content Motation being synced.
Thus every source connector will generate a content Motation and every destination connector will support a minimum content Motation. But not every source connector will generate the other Motation objects. Nor will every destination connector support the other Motation objects.
Motation Types
Every Motation will have a type. There are only two Motation types possible.
Content
The default Motation type. This is used for most data picked up from a repository. If a repository has additional types of data, they should be handled with repository specific attributes and listed as a supported repository.
File
A Motation file type requires a binary field. In addition each destination connector will be able to handle a file type differently than a content type. Otherwise, a Motation file type is not very different than a content type.
Each Motation type supports all Motation fields. However there may be additional restrictions for certain types (i.e., File type requires a binary field). In addition, a Motation type should be selected appropriately with correct intention for the data. This is because destination connectors are expected to be able to use the Motation type to handle specific types in the repository.
Motation Fields
Each Content Motation object has a field. These fields all have a type that matches the associated Definition Motation object's type. The Motation has the following field types.
Array
An array value. Values are not selectable.
Array
Big Integer
A big integer value.
BigInteger
Big String
A Big string value.
BigString
Binary
Binary
Boolean
A boolean value.
Boolean
Category
The IDs of the category objects.
Category
Checkbox
A checkbox value. Often an array of "tickable" values
Checkbox
Date
A date value.
Format of value is yyyy-MM-dd'T'.
"Zero" value is 0001-01-01
Date
Date-Time
A date and/or time value.
Format of value is yyyy-MM-dd'T'HH:mm:ss.SSS'Z'.
"Zero" value is 0001-01-01 00:00:00 +0000
Meaning, if using only date value, time value will be 00:00:00 +0000 . While if using only time value, date value will be 0001-01-0.
Datetime
Decimal
A decimal value.
Decimal
File
File
Float
A float value.
Float
Image
The ID of an image binary file.
Image
Integer
An integer value.
Integer
JSON
A JSON value. Requires JSON conformity.
JSON
Key Value
A key/value pair value.
KeyValue
Multi-select
A multi-select value. An array with multiple options selectable.
Multiselect
Radio
A radio value. An array with only one option selectable at a time.
Radio
Relationship
Relationship
Select
A select value. An array with only one option selectable at a time.
Select
String
A regular string value.
String
System
A "System" value. Paired with system/repository specific fields. Can be used with the system field type option in content Motation.
A destination connector should check the Motation's top level system attribute to determine if it was generated by a supported system.
System
Tag
The IDs of the tag objects.
Tag
Text Area
A text area value.
Textarea
Time
A time value. Format of value is HH:mm:ss.SSS'Z' . "Zero" value is 00:00:00 +0000
Time
WYSIWYG
A WYSIWYG value.
WYSIWYG
Field Mapping
Expanding on the Einstein-Rosen concept, the source connector will take the source repository's content and map the fields of the content to Motation's field types. Then when the destination connector reads the Motation, it knows how to handle each field type of Motation. The following diagram helps illustrate a simple example.
No System Fields Support
In this diagram We see the source repository has four field types. These field types are all mapped to a field type in Motation. We see that the source "Text" becomes a Motation "String" while "Integer" becomes "Integer." Notice that the source has the "Custom" field type which is stored in Motation as a "System" field type. When this Motation is handled by a destination connector the connector would need specific rules for parsing and handling the value(s). In this example, the destination is not the same system and does not have the rules to handle this "System" field.
However, the destination also has four fields. The destination connector handles Motation field type "String" as a "short text" and "Integer" as "integer." Notice how the "long text" field type is not generated from a Motation field type. The same is true of Column. In this case Motation is built from a repository that the destination repository does not handle the "System" field type from.
System Fields Support
Now, lets look at an example where the destination repository is the same as the source repository and thus handles all the system specific fields.
In this example, we can see that the destination connector makes use of Motation's "System" field type as well as other repository specific attributes in Motation to fully support the source repository's "Column" and "long text" fields.
So, Motation directly handles and maps the "short text" and "integer" field at both the source and destination. Motation then handles the "Column" field as a "System" type where the destination connector is able to read repository specific attributes to correctly handle the "Column" field in the destination.
Finally, you can see that "long text" on the source is mapped to Motation's "String". However the destination connector is able to sync the source "long text" as a destination "long text." This is due to Motation's "system" attributes. The source connector is able to add additional "system" specific attributes to Motation that the destination connector is able to parse and use. Like the "System" field type, these these system attributes should only be used when the Motation comes from a supported source repository.
Structure
Below is the structure of the content motation object and what each attribute is for. Every source connector must create a content Motation with the required fields. And every destination connector must support a content Motation with only the required fields.
systems (array | required) the system that the motation came from.
name (*string | required) *string value with the name of the system
date (*string | required) *string value with the date the Motation was built from the system
version (*string | optional) *string value with the version of the system
dependencies
definition (*string | optional) *string value with the ID of the definitions motation object
domain (*string | optional) *string value with the ID of the domains motation object
categories (*string | optional) *string value with the ID of the categories motation object
folders (*string | optional) *string value with the ID of the folders motation object
languages (*string | optional) *string value with the ID of the language motation object
relationships (*string | optional) *string value with the ID of the relationships motation object
tags (*string | optional) *string value with the ID of the tags motation object
contents (*object | required)
id (*object | required)
value (*string | required) Single ID of the content and it's versions. Always an Impulse ID.
label (*string | optional) Label of the ID.
properties (*object | required) The properties for the entire content.
type (enum | required) The type of content. Either "Content" or "File."
definitionId (*string | required) The ID of the associated definition.
name (*string | required) The name of the content.
status (enum | optional) The status of the content. "None", "Live", "Working", or "Deleted".
languageId (*string | optional) The ID of the associated language.
description (*string | optional) The description for the content.
path (*string | optional) The path the content lives at.
site (*string | optional) The site the content lives at.
system (*object | optional) Key/Value repository specific values.
creationDate (*string | optional) Creation date of the content.
modificationDate (*string | optional) Last modification date of the content.
versions (*array | required) An array of the multiple versions of the content.
id (*object | required) The id of the version.
value (*string | required) Single ID of the version for the content. Always an Impulse ID.
label (*string | optional) Label of the ID.
properties (*object | required) The properties for the specific version.
status (enum | optional) The status of the version. "None", "Live", "Working", or "Deleted".
name (*string | optional) The name of the version.
order (*int | optional) The order of the version respective to other versions.
creationDate (*string | optional) The creation date of the version.
modificationDate (*string | optional) The last modification date of the version.
modificationUser (*object | optional) The last modification user of the version.
value (*string | required) Single ID of the modification user for the version. Always an Impulse ID.
label (*string | optional) Label of the ID.
system (object | optional) Key/Value repository specific values.
fields (array | required) The list of fields for the version.
id (*object | required) The ID of the field.
value (*string | required) Single ID of the version for the content. Always an Impulse ID.
label (*string | optional) Label of the ID.
values (*array | optional) The list of values for the field.
value (*string | required) The value of the field as a string. May be nil when field type is "Binary" or "Relationship.
order (*int | optional) The order of all values when multiple values are present. Required when values array is greater than one.
binary (*object | optional) The attributes for binary object. Required when fieldType is "Binary."
bucket (*string | required) The bucket the binary data will be stored under. Often times defaulted to the endpoint ID.
md5 (*string | required) The md5 of the binary data.
filePath (*string | required) The file path the binary data lives at.
fileName (*string | required) The file name of the binary data.
relations (*object | optional) The attributes for a relationship field. Required when fieldType is "Relationship."
fieldId (*object | required) The ID of the field.
value (*string | required) Single ID of the version for the content. Always an Impulse ID.
label (*string | optional) Label of the ID.
parentIds (*object | required) The ID of the parent content.
value (*string | required) Single ID of the parent content. Always an Impulse ID.
label (*string | optional) Label of the ID.
childIds (*object | required) The ID of the child content.
value (*string | required) Single ID of the parent content. Always an Impulse ID.
label (*string | optional) Label of the ID.
order (*int | required) The order of the relationships with respect to other relationships.
system (object | optional) Key/Value repository specific values.
fieldType (enum | required) The field type of the field. Must match the field type in definition.
systemFieldTypeOption (*string | required) used by the system when fieldType is "System" and for testing.
endpointSpecificFieldType (*string | optional) used by the system for additional rules.
system (object | optional) Key/Value repository specific values.
audit (*array | required)
date (*string | required) Date the raw data was picked up.
user (*object | optional) User that picked up the content.
id (*object | required) ID of the user.
value (*string | required) Single ID value for the user. Always Impulse ID.
label (*string | optional) Label for the ID.
name (*string | optional) Name associated with the user.
email (*string | optional) Email associated with the user.
username (*string | optional) Username associated with the user.
Time Layout
Any date or time attribute in Motation structures or values adhere to the following Golang time layout.
Meaning, when writing a destination connector you can expect that any time field is in uses this layout.
Last updated
Was this helpful?
