External Value Type Support

CDP node values are stored by default in the CDP configuration storage (i.e., in XML files). In some cases, it is useful to store the values in some other storage. For these purposes, CDP provides an external value type support. This support enables seamless integration with databases, files, and other external data sources while maintaining the familiar CDP node value interface.

Overview

External value type support provides a way to:

• Store property values in external files (e.g. SQLite database)
• Ensure values persist independently of application XML configuration and its deployment
• Store sensitive data in secure databases rather than in plain in configuration XML files.
• Enable advanced data management scenarios, like multiple applications or nodes to access and modify shared data sources.
• Link properties to external files for binary or large text content

The feature consists of:

• External Type Provider - The main component that manages external type handlers and stores their global configuration.
• External Type Handlers - pluggable implementations for different external types (data sources)
• Core CDP integration for seamless node value behavior and metadata exposure

Currently available external type handlers:

• EncryptedXMLConf Handler - Handler for storing values in CDP XML configuration in encrypted form
• SQLiteValue Handler - Handler for storing values seamlessly in SQLite databases
• File Handler - Handler for linking to external files

There are two types of external type handlers possible:

• Value Handlers - Handlers that seamlessly replace the node value with a value from an external source (like SQLiteValue Handler)
• Binary Large Object (BLOB) Handlers - Handlers that manage large binary or text content linked to the node value (like File Handler)

External Type Provider

The External Type Provider is a built-in CDP internal component located at CDP.ExternalTypesProvider that manages all external type handlers and coordinates external data operations. It provides:

• Asynchronous request processing with configurable worker threads
• Request aggregation and optimization for performance
• Error handling and retry mechanisms
• Cross-thread communication for safe data access

External Type Handlers

External type handlers are pluggable adapters that implement specific logic for interacting with external data sources. Handlers have to be added and configured according to the need under the ExternalType Provider configuration (under node CDP.ExternalTypesProvider) first. Some handlers, like SQLiteValue Handler, are added by default in any new application.

Currently available handlers include:

• EncryptedXMLConf Handler - Stores property values in encrypted form in CDP XML configuration (available by default)
• SQLiteValue Handler - Stores property values in SQLite databases (available by default)
• File Handler - Links properties to external files

Handlers are attached to nodes by their configured names in the External Type Provider configuration, e.g. "SQLiteValue" or "File". There can also be multiple instances of the same handler type with different configurations, under different names like "SQLiteValue", "SQLiteValueWithChangeCount", etc.

CDP Property Integration

External type can be attached via the handler configured name to any CDP property through the ExternalType model attribute in the property model definition, like this:

<Attribute Name="PropertyName" Type="{any CDP value type}"
 ...
 ExternalType="{external type handler name}{;optional semicolon-separated list of key=value configuration parameters}"
 ...
/>

The ExternalType attribute can also be hooked in C++, at configuration time, using:

node->SetExternalType("{external type handler name}{;optional semicolon-separated list of key=value configuration parameters}");

When a property has some external type value handler assigned, it exhibits the following behaviors:

• The property value is loaded (asynchornously) using the external type value handler, not directly from XML
• Value changes are also written (asynchornously) to the storage via the external type value handler, so they are not written to XML
• Node XML value is still loaded and available as a "InternalValue" metadata entry, and it can also used as the key value to the actual value in the external storage.

For BLOB handlers, the property behaves as follows:

• The property value contains the path to the external file managed by the BLOB handler
• The BLOB handler manages reading and writing the actual file content (via special BLOB value API or via CDP Studio BLOB handling delegate, like TypeHint="File" delegate)

For both value and BLOB handlers, in addition to property value, metadata (e.g. information about database location, schema, etc.) about the external source becomes available via CDP Node metadata API (also can be inspected in CDP Studio while looking at the value tooltip).

External Type Provider Configuration

Configuration Properties of External Type Provider:

Error Handling

The external types system provides comprehensive error handling:

• Individual node errors are reported through their metadata
• Errors trigger also HandlerError alarm in External Type Provider
• Cumulative error tracking via External Type Provider NodesInError property
• Automatic retry mechanisms for transient failures
• Errors will be logged into CDP application window

Handler Request Processing

External type operations are processed asynchronously to avoid blocking the main application:

• Requests are queued and processed by worker threads
• When handler is configured to allow aggregation (like SQLiteValue Handler) then multiple requests for the same node are automatically aggregated, i.e., when many value changes happen quickly and are in the write queue, then only the latest value change will be posted to the external source
• Retry mechanisms handle temporary failures
• Cross-thread communication ensures thread safety

External type handler implementations focus only on the specifics of their data source, while the provider manages threading and request coordination, so that:

• All blocking external operations happen in worker threads
• Node value updates are marshalled back to the main thread
• Thread-safe request queuing prevents data races