Difference between revisions of "Intrinsic Component Configuration"

From OPC Labs Knowledge Base
Jump to navigation Jump to search
Line 1: Line 1:
[[Category:Configuration]] [[Category:High-Level Configuration]]
+
[[Category:Configuration]] [[Category:High-Level Configuration]] [[Category:OpcCmd Utility]]
 
= Introduction =
 
= Introduction =
 
The parameters of main QuickOPC components can be configured externally, without you having to write a specific code for it. The external configuration can be provided by multiple means, e.g. settings file (such as ''appsettings.json''), environment variables, or Azure App configuration, and the functionality for it is already built-in to the components. This feature belongs to [[:Category:High-Level Configuration|High-Level Configuration]], and allows tweaking of component parameters for experiments, testing, and in production. Its main benefit is that the component parameters can be changed without somebody having to implement the code for it first, and/or without having to change and rebuild the application (which may come really handy if rebuilding the application is not an option for you, e.g. in many restricted production environments).
 
The parameters of main QuickOPC components can be configured externally, without you having to write a specific code for it. The external configuration can be provided by multiple means, e.g. settings file (such as ''appsettings.json''), environment variables, or Azure App configuration, and the functionality for it is already built-in to the components. This feature belongs to [[:Category:High-Level Configuration|High-Level Configuration]], and allows tweaking of component parameters for experiments, testing, and in production. Its main benefit is that the component parameters can be changed without somebody having to implement the code for it first, and/or without having to change and rebuild the application (which may come really handy if rebuilding the application is not an option for you, e.g. in many restricted production environments).

Revision as of 18:50, 18 January 2021

Introduction

The parameters of main QuickOPC components can be configured externally, without you having to write a specific code for it. The external configuration can be provided by multiple means, e.g. settings file (such as appsettings.json), environment variables, or Azure App configuration, and the functionality for it is already built-in to the components. This feature belongs to High-Level Configuration, and allows tweaking of component parameters for experiments, testing, and in production. Its main benefit is that the component parameters can be changed without somebody having to implement the code for it first, and/or without having to change and rebuild the application (which may come really handy if rebuilding the application is not an option for you, e.g. in many restricted production environments).

Where the configuration is read from (the "configuration providers") is determined by the default settings for your application host. For the usual hosts, these defaults are described here:

Since this is a standard mechanism used by software libraries and applications, you will be able to place the configuration settings for QuickOPC component alongside with configuration settings for other parts of the software.

By far, the most commonly used configuration provider will probably the JSON configuration provider, and you will place your configuration data into the appsettings.json or appsettings.Environment.json file (e.g. appsettings.Production.json).

Naming Conventions

The key (name) of the configuration section is the full (namespace-qualified) name of the component being configured. For example, parameters for the EasyUAClient component are under the OpcLabs.EasyOpc.UA.EasyUAClient configuration section.

The component parameter name is then the key (name) of the sub-section. For example, the InstanceParameters can be configured under the InstanceParameters sub-section. If the parameter is not an atomic value, but rather a structured object, deeper sub-sections are used as necessary, recursively.

Examples

The JSON and the environment variable configuration providers are available by default on most hosts (including ASP.NET, and .NET console apps), and you can therefore reliably use configurations similar to the examples below "out of the box" with any QuickOPC-based software.

Example: Using the JSON configuration provider

In order to set the default URL of the OPC UA Global Discovery Server (GDS) used by QuickOPC global discovery operations, you can use the following appsettings.json file:

{
  "OpcLabs.EasyOpc.UA.EasyUAClient": {
    "InstanceParameters": {
      "GdsEndpointDescriptor": {
        "UrlString": "opc.tcp://opcua.demo-this.com:58810/GlobalDiscoveryServer"
      }
    }
  } 
}

Example: Using the environment variable configuration provider

In order to achieve the same configuration effect as with the JSON example above, you can set the environment variable as follows (the syntax is for Windows, but the provider is available on other systems as well):

set OpcLabs.EasyOpc.UA.EasyUAClient:InstanceParameters:GdsEndpointDescriptor:UrlString="opc.tcp://opcua.demo-this.com:58810/GlobalDiscoveryServer"

On platforms where the : separator does not work (e.g. Bash), use __ (double underscore) instead.

Note on Programmatic Component Configuration

The sequence of high-level component configuration evaluation is as follows:

  1. The values are set to their (constant, documented) defaults (both static and instance members).
  2. Built-in configuration, if present, is applied (this can involve multiple configuration providers in specific sequence). This affects both the static and instance members of the component.
  3. If the component supports programmatic component configuration, and the code that creates the component specifies a configuration interface, using a constructor designed for IoC (Inversion of Control), the configuration given by the specified interface is applied (this, again, can involve multiple configuration providers in specific sequence). Only instance members of the component can be configured in this way.

If the programmatic component configuration is used, the initial values (of instance members) that the component will end up using may be different from what you specify using the built-in component configuration feature.

Changing the Configuration Providers

If your application requires a set of configuration providers different from the default, you can configure them differently through IHostBuilder interface by accessing the result value of StaticHost.GetHostBuilder().

Of course, changing the configuration providers *does* require a code change; the configuration providers cannot be changed externally on an application that is already built.

Some applications built with QuickOPC already add configuration providers over those that are available by default. For example, the OpcCmd Utility adds the INI and XML configuration providers, and you can therefore use configuration files like these in the examples below with the OpcCmd utility.

Example: Adding and using the INI configuration provider

For example, to support a possibility to configure component parameters by key pairs from INI files, reference the Microsoft.Extensions.Configurations.Ini NuGet package, and add the following code at the beginning of your program:

StaticHost.GetHostBuilder().ConfigureAppConfiguration((hostingContext, config) =>
{
    IHostEnvironment hostEnvironment = hostingContext.HostingEnvironment;
    config
        .AddIniFile("appsettings.ini", optional: true, reloadOnChange: false)
        .AddIniFile($"appsettings.{hostEnvironment.EnvironmentName}.ini",
            optional: true, reloadOnChange: false);
});

The contents of the INI file which corresponds to the JSON example given earlier is as follows:

[OpcLabs.EasyOpc.UA.EasyUAClient:InstanceParameters:GdsEndpointDescriptor]
UrlString="opc.tcp://opcua.demo-this.com:58810/GlobalDiscoveryServer"

Example: Adding and using the XML configuration provider

For example, to support a possibility to configure component parameters by elements read from XML files, reference the Microsoft.Extensions.Configurations.Xml NuGet package, and add the following code at the beginning of your program:

StaticHost.GetHostBuilder().ConfigureAppConfiguration((hostingContext, config) =>
{
    IHostEnvironment hostEnvironment = hostingContext.HostingEnvironment;
    config
        .AddXmlFile("appsettings.xml", optional: true, reloadOnChange: false)
        .AddXmlFile($"appsettings.{hostEnvironment.EnvironmentName}.xml",
            optional: true, reloadOnChange: false);
});

The contents of the XML file which corresponds to the JSON example given earlier is as follows:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <OpcLabs.EasyOpc.UA.EasyUAClient>
    <InstanceParameters>
      <GdsEndpointDescriptor>
        <UrlString>opc.tcp://opcua.demo-this.com:58810/GlobalDiscoveryServer</UrlString>
      </GdsEndpointDescriptor>
    </InstanceParameters>
  </OpcLabs.EasyOpc.UA.EasyUAClient>
</configuration>

Component Support

The built-in component configuration feature is supported by following components, and for the data members listed:

EasyAEClient
AdaptableParameters, SharedParameters, InstanceParameters, IsolatedParameters.
EasyDAClient
AdaptableParameters, SharedParameters, InstanceParameters, IsolatedParameters.
EasyUAClient
AdaptableParameters, SharedParameters, InstanceParameters, IsolatedParameters.
EasyUASubscriber
AdaptableParameters, SharedParameters, InstanceParameters, IsolatedParameters.