Use Open Message Format with CONNECT data services

The Open Message Format (OMF) specification is generic in that it does not specify a particular back-end system. This topic is a companion to the OMF specification which describes how OMF is interpreted by CONNECT data services back-end system.

Headers

For a description of each of the headers, see OMF specification. Note that rather than using a producertoken, data collection calls to CONNECT data services require a bearer token to be attached in the header, as documented in the Quick Start: Sequential Data Store documentation. The bearer token is used to authenticate the sender and to authorize the sender for use with a particular tenant. The client ID associated with this token is used to route messages to a particular OMF connection that it is mapped to.

The omfversion header must match the version of the OMF spec used to construct the message. Versions 1.0 and 1.1 of the spec are currently supported.

Message types

OMF message types fall into three categories: type, container, and data, which are described below.

Type messages

A type message is interpreted by CONNECT data services as an SdsType in the Sequential Data Store. Because SdsTypes are immutable, update operations are not supported. The keywords in the Type definition are interpreted as follows:

• id: Corresponds to the SdsType Id field. It must conform to the rules defined for a typeId specified here: Types

  Note: For this field, both forward slashes (/) and back slashes (\) are supported. Forward slashes are automatically replaced with periods (.) when it receives a message.

• classification: Only the dynamic classification is currently supported.

• version: Versioning of SdsTypes is not supported.

• name: Corresponds to the SdsType Name field. This is the friendly name for the type.

• description: Corresponds to the SdsType Description field.

• tags: Currently unsupported.

• metadata: Currently unsupported.

The isindex keyword corresponds to the isKey attribute of an SdsTypeProperty. SdsTypes support clustered indexes which can be specified with multiple properties marked with the isindex keyword with a value of true. For compound indexes, the index property order within the message corresponds to the Order field of an SdsTypeProperty. The isname keyword is not supported.

Link type

Link types are not supported in Sequential Data Store and will be ignored.

Property types and formats

OMF supports setting the format keyword to specify how a particular JSON type should be interpreted. The following is a mapping for the Sequential Data Store supported types (see types):

Container messages

A container message is interpreted as an SdsStream in the Sequential Data Store. The keywords in the container definition are interpreted as follows:

• id: Corresponds to the SdsStream Id field. It must conform to the rules defined for an SdsStream Id specified here: Streams.
• typeid: Corresponds to the SdsStream TypeId field.
• typeversion: Versioning of SdsTypes is not supported.
• name: Corresponds to the SdsStream Name field. This is a friendly name for the stream.
• description: Corresponds to the SdsStream Description field.
• tags: Corresponds to the SdsStream Tag field.
• metadata: Corresponds to the SdsStream Metadata field.

Note: For the id and typeid fields, both forward slashes (/) and back slashes (\) are supported. Forward slashes are automatically replaced with periods (.) when it receives a message.

Data messages

A data message is mapped to generic Sds values in the Sequential Data Store. The keywords in the data definitions are interpreted as follows:

• typeid: Data that is not grouped by containerId is not supported.
• containerid: Stream Id for the associated Sds Stream.
• typeversion: Not supported.
• values: An array of the generic Sds values.

Note: For the typeid and containerid fields, both forward slashes (/) and back slashes (\) are supported. Forward slashes are automatically replaced with periods (.) when it receives a message.