Axeda® ConnectedConfiguration

Notes: Axeda ConnectedConfiguration is a separately licensed feature. If the Axeda Platform is not licensed for ConnectedConfiguration, the ConnectedConfiguration functionality and associated tools and features will not be available in the Axeda Applications tabs. Contact Axeda Technical Support for more information. If your Platform is licensed for ConnectedConfiguration, you must have the appropriate privileges to view or use the ConnectedConfiguration tools.

If you had Axeda ConnectedConfiguration licensing in the past, and created packages and deployments with Defined Configuration dependencies and routing criteria, then those packages/deployments will continue to exist once licensing is removed. However, no asset will ever become eligible for the deployments, and no new deployments can be created for existing packages with Defined Configuration dependencies.

The Axeda Platform can read and store any type of information sent from an asset. Assets send this information, called Asset Configurations, to the Axeda Platform in the form of XML documents. An Asset Configuration is a tree of key/value pairs (Configuration Items) containing metadata about the specific asset. Some examples of asset metadata may include hardware or software make, model, version, position (for example, relative to other hardware), and so forth.

Axeda ConnectedConfiguration identifies the ability for the Axeda Platform to be used as the "system of record" for asset configuration information. Each time an asset's configuration changes, the new configuration can be sent to the Axeda Platform for validation, rule execution, and storage.

You can use asset configuration information to determine the current settings for an asset, including its hardware and software configuration, the make and model of its hardware, and more. Any configuration information for an asset can be captured in its asset configuration and stored to the Axeda Platform. Once there, this asset metadata can be used in Expression rules for validation purposes or to route packages using "Defined Configuration" rules. You can create validation rules to evaluate the current configuration and potentially modify it or perform any other expression rule action depending upon the results of that evaluation. The Platform can be configured to compare the uploaded asset configuration to the "Actual Configuration" of another asset. For example, a validation expression can be defined to verify that an asset is running version 1.5 of ACME software and, if it's not, then a notification action can be executed to notify a user of the mis-configuration. Furthermore, configurations of assets can be evaluated using DefinedConfiguration type rules, to see whether the asset possesses such a ‘DefinedConfiguration’. Packages can subsequently be deployed to assets that possesses such "Defined Configuration". In this example, the asset's Actual Configuration would be compared to a Defined Configuration in which the version requirement is set at 1.5.

XML-formatted for asset configuration

Asset configurations are either sent to the Platform by the agent directly, or they can be managed through the SDK/API (or UI available via the Asset Configuration SDK/API). Asset configurations sent by the agent require that the agent upload a single XML file with a Dependencies file hint. This XML file needs to contain all configuration data for that agent. (See the help for configuring file upload rules or for creating packages that upload files for more information about using the dependencies file hint.)

Note: The ConnectedConfiguration Path and XML are case-sensitive. Make sure you use the correct case when defining XML, Path, and expression rule configurations.

The following is an example Hardware configuration (XML) that may be defined as the actual configuration for an asset:

<Config>

<Hardware>

<MotherBoard position="top">

<Make>Asus</Make>

<Model>123</Model>

<Version>1.05</Version>

</MotherBoard>

<MotherBoard position="bottom">

<Make>Asus</Make>

<Model>123</Model>

<Version>1.05</Version>

</MotherBoard>

</Hardware>

</Config>

The asset can send this XML-formatted configuration to the Platform (as defined in the Agent project). The Platform resolves this configuration to Path expression format before storing it. The XML key corresponds to the Path expression which leads to the value. Each key is a node or attribute in the XML configuration.

Path expression for asset configuration

The following Path expressions will be stored as a result of this XML configuration:

Notes about parsing XML to create Path expressions:

o        Each of the Leafs identified during the Parsing phase (either attribute or node) will be stored as individual “Configuration Items” which can be independently referenced. For example, in the above Path expression, each Key (position, make, model, etc.) is a Configuration Item for that Path.

o        The distinction between nodes and attributes are preserved in the Path expression by the presence of the “@” prefix for Attributes

o        Arrays (that is, multiple occurrences of the same element) are supported using the [N] annotation, starting at [0]. Best practices is to not rely on these indices when referencing elements. Instead, if possible, use a differentiator in the actual path itself to this reduce potential issues when elements are re-ordered or items are deleted in which case the path indices are updated an any hard-coded references in Expression rule functions for instance, will no longer be accurate.

o        The source XML can be reconstructed after persistence

o        Empty Nodes, such as “<foo/>” will be persisted with empty String contactable values

The following portions of XML documents are not preserved during the parsing operation:

o        Namespace and type declarations (references to XSD defined types)

o        XML Processing Instructions

o        Comments

o        Whitespace in between Elements

When the newly-formatted configuration is exported (after the Platform removes the non-preserved portions), the Path configuration keys and values are re-assembled into XML for output. You notice that the new XML file has been formatted for printing and uses standard XML format conventions, including new lines for separating tags, tabs indenting children, and so forth. See an example of asserted XML versus exported XML.

Validating and saving the Configuration

When the Platform reads the XML-formatted configuration, it parses it to a flat list of paths in expression format and subsequently creates a ConfigurationEvent that contains the list of Path expressions as well as the actual XML string that is automatically injected in custom objects that can be executed using the ExecuteCustomObject action. The Platform will validate the configuration ONLY if it is set to validate.(By default, the Platform is set to save the configuration without validation.) After the configuration has been saved, any DefinedConfiguration type rules are evaluated to determine the ‘matched’ configurations for an asset.

Configuration events are evaluated asynchronously for Agent configuration uploads and synchronously for the SDK API/UI configuration definitions. The results of the evaluation - true or false - are returned through the SDK/API (or UI), but not for Agent configuration uploads. The outcome of the evaluation of all applicable evaluation rules determines whether the configuration updates are persisted when the Platform is configured to do so; when all rules evaluate to true then the changes are saved. The Platform may save agent uploaded configurations that fail validation evaluation by configuration rules. This is a Platform setting; contact your administrator if you have questions about this setting.

Note: The Platform will also create ConfigurationEvent messages when the Country or Language defined for a Location is changed OR when the location reported for an asset changes. The Axeda Platform will create a ConfigurationEvent for each asset associated with the changed location. If the location associated with a managing gateway is changed, the Axeda server creates a ConfigurationEvent message for the gateway and for all assets managed by that gateway.

Privileges control access

The ability to create, update, delete or otherwise manipulate or view configuration items and configuration types is controlled by user group privileges. If a user wants to create a new defined configuration, for example, that user needs to be defined in a user group with the ConnectedConfiguration - Create privilege. See a description of the ConnectedConfiguration privileges.