Esta página no está disponible actualmente en Español. Si lo necesita, póngase en contacto con el servicio de asistencia de Icon (correo electrónico)

Configurations

Below are some key configurations used on the dynamic config adapter.

Configuration Purpose

dynamic-config-types

Defines the dynamic configurations types that should be sourced by the dynamic config adapter. Currently only supports "customProcessingSettings".

value-refresh-period

Defines how frequently the dynamic config adapter should refresh all the dynamic expression registry entries.

setting-categories

1) Setting categories is a way for client implementations to group related dynamic configurations on custom processing settings.

2) Client implementations can specify a list of setting categories that the instance of dynamic config adapter should source.

3) Dynamic config adapter will retrieve and refresh only those dynamic configurations that belong to the specified setting categories.

correlation-entries

1) The correlation entries provide a way of mapping a dynamic variable name on the custom processing settings to one or more dynamic variables on the rules designer.

2) One custom processing setting can correlate to multiple dynamic variables. However, one dynamic variable can only be sourced from a single custom processing setting.

  1. The attribute variable-value-type defines the data type of the destination dynamic variable. Client implementations must ensure correct values are assigned to variable-value-type attributes on the correlation entries.

    • Currently supported types: string, stringArray, number, numberArray, boolean

    • The dynamic variable value will not be updated by the adapter, if retrieved value from custom processing setting has a different type than what is registered on variable-value-type of the corresponding correlation entry.

  2. destination-variable-key is a unique key that identifies the variables on the model. An IPF service can hold multiple git models under rules designer and each of them can have variables declared as dynamic. The variable keys are made of the model name on the service followed by the variable name, separated by "-".

  3. Client implementations should assign a low value to value-refresh-period so the refresh all processing is done as frequently as possible and the risk of a notification being missed is mitigated. The default (and recommended value is 1 minute)

Examples

Examples of the configuration values on the dynamic config adapter.

ipf.dynamic-config-adapter {
  # Dynamic Configuration Types supported by the dynamic config adapter
  dynamic-config-types: ["customProcessingSettings"]

  # the period at which the values are refreshed automatically
  value-refresh-period: 1m

  # list of setting categories to be retrieved upon refresh
  setting-categories: ["InitiationSettings", "FXSettings"]

  # Correlation Entries map dynamic configuration values to the variables used by external systems
  correlation-entries: [
    {
      # variable key
      # For IPF studio, variable keys are made of the model name and variable name
      destination-variable-key: "test-model1.fxAllowed"
      # the type of the variable used on the registry; Currently supported types:
      # string
      # stringArray
      # number
      # numberArray
      # boolean
      variable-value-type: boolean
      # dynamic configs to be used to source values to be refreshed into the dynamic variables
      source-dynamic-config: {
        # the type of dynamic configuration
        config-type: "customProcessingSettings"
        # the name of dynamic configuration
        config-name: "fxEnabled"
      }
    }
  ]
}

Above configuration means that the instance of the dynamic configuration will:

  1. Source the dynamic configuration values from custom processing settings, to provide the values into dynamic expression registry.

  2. Source all active dynamic configurations with setting category of "InitiationSettings" or "FXSettings".

  3. Refresh all the entries on the dynamic expression registry, every 1 minute.

  4. Use value of the custom processing setting "fxEnabled" to update the dynamic expression registry entry for the variable "fxAllowed" on the model "test-model1".

  5. The variable "fxAllowed" on the model "test-model1" is of type boolean so only boolean values can be provided to it.

Static Configuration Validation on Startup

To ensure correct and safe mapping of the dynamic expression registry values, the dynamic config adapter performs below validations on the configurations:

Configurations Validation Failure Behavior

correlation-entries.variable-value-type

Validate that only supported data type values are registered on the variable-value-types.

The service restart will fail and the reason will be logged.

dynamic-config-types

dynamic-config-types should not be empty.

1) The failure of this check does not stop the service from starting up. A warning will be logged.

2) An empty dynamic-config-types means dynamic variables on the rules designer cannot be refreshed using dynamic config adapter source.

3) It is still possible for dynamic variables to be refreshed from Hocon provider.

correlation-entries

correlation-entries should not be empty

1) The failure of this check does not stop the service from starting up. A warning will be logged.

2) Empty correlation-entries means dynamic variables on the rules designer cannot be refreshed using dynamic config adapter source, as dynamic config adapter is not aware of which dynamic variables are to be refreshed with values from custom processing settings.

3) It is still possible for dynamic variables to be refreshed from Hocon provider.

destination-variable-key

1) Each destination-variable-key must be unique. One destination variable key should not be correlated from more than one custom processing setting.

2) Mapping one dynamic variable from multiple custom processing settings can cause conflicts. This is not allowed.

The service restart will fail and the reason will be logged.