Master Data Package Reference#
This page provides a technical reference for the Master Data Package generated by the UNS Export Integration business scenario. Understanding this structure enables administrators to inspect, modify, and extend the integration beyond the defaults provided by Cortex.
Package Overview#
The Master Data Package contains three object types that together define the complete UNS Export Integration pipeline:
Master Data Package
├── AutomationController — Controller entity with scope and task packages
├── AutomationControllerWorkflow — Setup workflow with event processing logic
└── AutomationControllerIoTEventDef — Bindings to Light CDM event definitions
AutomationController#
The AutomationController object defines the controller entity that manages the UNS Export Integration workflow.
| Property | Description | Example Value |
|---|---|---|
| Name | Descriptive name for the controller. Assigned during Cortex setup. | Test-01 Controller |
| Description | Auto-generated description. | Created by UNS Export Integration automation business scenario. |
| Type | Controller type. | General |
| Scope | Determines the operational scope. Must be DataPlatform for UNS integration. | DataPlatform |
| ControllerPackageVersion | Version of the controller engine package. | 11.3.0-dev |
| TasksPackages | Array of task package names required by the workflow. | See table below. |
| TasksLibraryPackages | Versioned task library packages. | See table below. |
| DefaultWorkflowType | Workflow execution model. | ControlFlow |
Required Task Packages#
The automation controller requires three task packages to function:
| Package | Purpose |
|---|---|
@criticalmanufacturing/connect-iot-controller-engine-core-tasks | Core workflow engine tasks, including code execution. |
@criticalmanufacturing/connect-iot-controller-engine-dataplatform-tasks | Data Platform-specific tasks for CDM event processing. |
@criticalmanufacturing/connect-iot-controller-engine-factoryautomation-tasks | Factory automation tasks, including job triggers and distributed message sending. |
Table: UNS Export Integration Task Packages
AutomationControllerWorkflow#
The Setup workflow defines the event processing pipeline. It is a ControlFlow workflow containing a single job trigger with a handler branch that executes two sequential tasks.
Workflow Structure#
jobStart (Trigger)
└── handler (Branch)
├── codeExecution (Transform CDM event → MQTT topic)
└── distributedMessageSend (Publish to MQTT broker)
Task: jobStart#
The jobStart task triggers the workflow when a CDM event matching one of the subscribed IoT event definitions is generated.
| Output | Data Type | Description |
|---|---|---|
raw | Any | The complete raw CDM event payload. |
iotEvent | Any | IoT event metadata, including application properties such as the event definition name. |
jobId | String | Unique identifier for this job execution. |
Task: codeExecution#
The codeExecution task transforms the raw CDM event into an MQTT-compatible message with a constructed topic.
Inputs:
| Input | Source | Description |
|---|---|---|
raw | {{ $jobStart.__raw }} | The raw CDM event payload from the trigger. |
iotEvent | {{ $jobStart.__iotEvent }} | The IoT event metadata. |
Output:
| Output | Data Type | Description |
|---|---|---|
dataOut | Object | Contains topic (the constructed MQTT topic string) and raw (the original CDM event payload). |
Code Logic:
The TypeScript code performs the following operations:
- Extracts
Enterprise,Site,Area, andResourcenames from the raw CDM event. - Applies defaults (
DefaultEnterprise,DefaultSite,DefaultArea,DefaultResource) for missing values. - Constructs the hierarchical topic string using
/as separator. - Conditionally includes the
Resourcelevel only if present in the event. - Extracts the event definition name from the IoT event metadata.
- Appends the event name as the last topic level.
- Replaces spaces with hyphens for MQTT compatibility.
For the full code listing and customization options, see UNS Topic Mapping and Customization.
Task: distributedMessageSend#
The distributedMessageSend task publishes the transformed event to the MQTT broker through the UNS Connector service.
| Setting | Value | Description |
|---|---|---|
| serviceName | UnsExportIntegration.SendToMqtt | Identifies the distributed messaging service that routes messages to the MQTT broker through the UNS Connector. |
| requestTimeout | 60 seconds | Maximum time to wait for the send operation to complete. |
| requestAttempts | 10 | Number of retry attempts if the initial send fails. |
| requestSleepBetweenAttempts | 1000 ms | Delay between retry attempts. |
| confirmationTimeout | 30 seconds | Timeout for delivery confirmation from the broker. |
Table: distributedMessageSend Task Settings
Inputs:
| Input | Source | Description |
|---|---|---|
serviceName | Static | UnsExportIntegration.SendToMqtt |
dataIn | {{ $codeExecution.dataOut }} | The topic and payload object from the code execution task. |
requestTimeout | Static | 60 |
Outputs:
| Output | Data Type | Description |
|---|---|---|
id | String | Message identifier returned by the distributed messaging system. |
data | Object | Response data from the MQTT send operation. |
AutomationControllerIoTEventDef#
This object binds the automation controller to specific CDM event definitions. Each entry subscribes the controller to one event type.
| Property | Description |
|---|---|
| AutomationController | The name of the parent automation controller. |
| IoTEventDefinition | The CDM event definition name to subscribe to. |
| SupportedEventVariant | Must be Light — only light variants are supported for UNS export. |
| Order | Execution order for multiple event subscriptions. |
Example Configuration#
The following example subscribes the controller to two light CDM events:
| # | IoT Event Definition | Variant | Order |
|---|---|---|---|
| 1 | ResourceStateChange | Light | 1 |
| 2 | MaterialOperations | Light | 2 |
Table: Example IoT Event Definition Bindings
Available Light CDM Events#
To add subscriptions for additional event types, either:
- Use Cortex to create a new automation controller with the desired events, or
- Manually add
AutomationControllerIoTEventDefentries to the Master Data Package JSON and reload it.
Warning
Only events with the Has Light Variant property enabled can be used with the UNS Export Integration. Subscribing to full CDM events is not supported in this business scenario.
Loading and Reloading the Package#
Initial Load#
- Open the Master Data Package generated by Cortex.
- Select Run > Load on the top ribbon.
- Select the
AutomationControllerobject and confirm.
Reloading After Modifications#
If you modify the Master Data Package JSON (for example, adding event subscriptions or changing workflow code):
- Navigate to the Master Data Package.
- Select Run > Load.
- Select all modified objects.
- Confirm the reload. Existing objects are updated in place.
Note
Reloading a Master Data Package updates the objects defined within it. Running automation controllers will pick up the new configuration after the next event trigger cycle.
Package JSON Structure#
The complete Master Data Package JSON follows this structure:
{
"<DM>AutomationController": {
"1": { /* Controller definition */ }
},
"AutomationControllerWorkflow": {
"1": { /* Setup workflow with tasks */ }
},
"AutomationControllerIoTEventDef": {
"1": { /* First event subscription */ },
"2": { /* Second event subscription */ }
}
}
Tip
The <DM> prefix in <DM>AutomationController indicates that this is a Data Model-aware entity. This prefix is required for the Master Data Package loader to correctly identify the entity type.
Related Topics#
- [Tutorial: Customizing UNS Hierarchyand Payloads]] — developer guide for customizing topics and payloads
- Configuring UNS Export Integration — end-to-end setup guide
- UNS Topic Mapping and Customization — topic structure and customization
- Master Data Packages — general Master Data Package information