Device Orchestration Service Overview
A-Stack Device Orchestration Service (DOS) is a component that allows device data from a number of device providers to bridge into the device models. As part of bridging multiple devices, data streams are created leveraging stream processing engines with the ability to process the raw device data into the selected device processors functions. Device Orchestration Service can be thought of three major components -
Smart Bridge Framework (SBF) - A subcomponent of Device Orchestration Service responsible for ingesting data from a number of configured Device Providers. Device Providers can either push the data to the transport enabled by Smart Bridge Service or Smart Bridge Service can pull the data a scheduled interval from the Device Provider.
Stream Processing Engine (SPE) - A subcomponent of Device Orchestration Service responsible for converting the Device Provider data bridged via Smart Bridge Service into a stream. Stream Processing Engine maintains the device data in memory with periodic disk writes in case of overflow. Interaction between Smart Bridge Service (SBF) and Stram Processing Engine (SPE) is either local (colocated) or remote mode (via HTTP interface)
Device Processor Framework (DPF) - A subcomponent of Device Orchestration Service responsible for processing the device data and store into Device models.
Requirements for DOS
The latest version of A-Stack TQLStudio
Connections to HTTP, WS, AMQP, MQTT, Perif, and OPC protocol handlers are supported out of the box.
Getting Started with DOS
This tutorial provides a hands-on introduction to Atomiton DOS. You create a DOS configuration to move data between a provider data source and your models.
Tasks:
Pre-requisites
Step 1: Create a new TQLStudio Project
Step 2: Prepare DOS Configuration files
Step 3: Map data fields
Step 4: Add filters, custom handlers (if any)
Step 5: Review and Create DOS Configuration
Step 6: Activate and Listen to Data
Step 1: Create a new TQLStudio Project
Step 2: Prepare DOS Configuration files
Step 3: Map data fields
Step 4: Add filters, custom handlers (if any)
Step 5: Review and Create DOS Configuration
Step 6: Activate and Listen to Data
DOS Supported Handlers and Functions
Message Handlers
Filter Functions
Description of DOS Configuration Parameters
Parameter Name | Description |
|---|---|
Service | An overall container of ServiceInstance |
ServiceName | Unique name of the ServiceInstance |
ServiceDescription | Description of ServiceInstance |
Tags | Choose key-value pairs to tag your ServiceInstance. Use tags to organize, track, or control access for this ServiceInstance. For example, a tag can include CustomerName and license agreement |
DataEncrpytion | Encryption ensures that your data and your sensitive information are not accessible by any user or application without a valid key. Encrypting data in transit and data at rest is vital for regulatory compliance. Service always encrypts your data and sensitive information during transit and at rest. You can either choose a customer master key (CMK) managed by Atomtion (default) or bring your own key to encrypt your data and sensitive information. |
ServiceTrigger | A trigger causes ServiceInstance to run. You can choose from one of three triggers types: Run on-schedule. Use when you want the ServiceInstance to run automatically at a scheduled frequency. Event-driven. Use when you want the ServiceInstance to run when an external event happens (As described by the Provider) Run on-demand. Use when you want to run the ServiceInstance |
SBFOptions | An overall container to hold SBF Options |
ProviderInfo | An overall container to hold Provider Information |
ProviderName | Name of the Provider |
ProviderDescription | A detailed description of the provider |
ProviderInteractionName | Provider interaction name. Combination of ProviderName and ProviderInteractionName must be unique |
Interaction | An overall container to hold the provider interaction |
CustomInteractionAction | Users can specify their own actions than can handle the complete provider interaction. This is useful when there are multiple steps involved in an interaction. |
InteractionType | Interaction can be a “READ” or “WRITE” type. Read is for reading from the provider and write is to write back to the provider. |
Protocol | An overall container to hold the provider protocol communication information |
ProtocolHandlerName | Protocol Handler name - must be one of the A-Stack provided protocol handler name (HttpServerExtensionArgs) or short prefix like - HTTP or OPCUA, etc. |
ClientServer | The interaction can be Client i.e. ServiceInstance initiates a connection at specific trigger interval OR Server i.e. provider pushes data to ServiceInstance |
ConnectionInfo | An overall container to hold protocol connection information. It includes hostname, port, URI constructed via an array of name-value pairs, Request Message Value to be sent as a payload. Header parameters, Protocol Method (GET/PUT/POST..) |
MessageProcessingHandler | An overall container to hold information on how to handle and process the message received from the provider using a given interaction. |
MessageProcessingHandlerAction | Action name that can handle the message. Values can be |
MapFields | An overall container to hold source to the destination field mapping. From the Studio one can Upload a .csv file with mapped fields - Use a comma-separated values (CSV) file to specify the field mappings. Each line in the CSV file contains the source field name, followed by a comma, followed by the destination field name. |
Field | An overall container to hold a single field mapping information |
SourceFieldName | Source filed name from the response of a provider interaction |
DestinationFieldName | Destination field name pointing to the user Thing Model attribute |
Formula | This step is optional. To add a formula that concatenates fields, select two fields from Mapped fields, and then provide a custom formula to chose one of the standard formulas provided. Example: Concatenation. |
DataModificationAction | This step is optional. Some of the data modifications are truncate a string value. Users can specify custom action to handle data modification. |
Validation | Overall container to hold singe data validation. This can be used to discriminate if the same value is sent by the provider. |
ValidationCondition | For Validations, add validations to check whether a field has bad data. For each field, choose the condition that indicates bad data. Service provided conditions are:
Users can provide their validation own condition. |
ValidationAction | What action ServiceInstance should take when a field in a record is bad. Users can provide their own validation action |
Service End-2-End Runtime Flow
Runtime Flow
Service Monitoring and Metering
ServiceRunHistory
Column | Description |
|---|---|
ServiceName | ServiceInstance Name whose history is being maintained. |
DataCreated | Data time when ServiceInstance was created |
Status | The Status column tells you if the ServiceInstance is active, in the draft, or has been suspended. ServiceInstances triggered on a schedule that has been created but not yet activated are in “draft” mode. You can suspend ServiceInstances that is triggered on a schedule or by an external event. Suspended ServiceInstances can be resumed by calling StartListen action again |
RunStatus | Run Status column shows the status of the last ServiceInstance run indicating if it was a success or if there were errors. |
LastRunDate | Date time when ServiceInstance last run |