Runtime Model Configuration

Introduction

A new feature called runtime model configuration is added to Origam starting with the version 2021.2. This will let you set values of some model properties in a new config file so that they can be easily changed in different environments. An example of such a property is the TraceLevel. You probably want to have the trace on in test environment but not in production. Well may be you need to switch it on in production too for a brief moment and then switch it back off. All this can be done with the new RuntimeModelConfig.json file.

The File Format

The configuration file is just a json array of repeating objects shown below. Each configuration object has three mandatory fields: Id, PropertyName and PropertyValue. The Id is model id of the object to be modified. PropertyName is name of the property to be modified (more on that later) and the PropertyValue is string representation of the value to be set. The Description field is not mandatory and can be used for notes.

If the PropertyValue contains the properties default value, the configuration object can be omitted and the default value will be used. Note that this does mean the properties’ default value, not default value of the properties data type.

[
  {
    "Id": "d2cefee8-1617-4a63-a838-33e916c9ea78",
    "PropertyName": "trace",
    "PropertyValue": "Yes",
    "Description": "Test1"
  },
  {
     ...
]

The File Location

The file name and path can be set in OrigamSettings.config. Default path is RuntimeModelConfiguration.json (located at the Origam directory)

   <OrigamSettings>
      ...
      <PathToRuntimeModelConfig>C:\Projects\RuntimeModelConfiguration.json</PathToRuntimeModelConfig>
     ...
   </OrigamSettings>

What Exactly Can Be Modified With the Config File

There are two types of properties you can change in the configuration file.

Properties Persisted in the .origam Files

Properties in the .origam files can be sub divided into two types. Value properties, these set a value directly. And reference properties, these create a link pointing to some model element or a file.
You can only override the value properties in the configuration file. To do that first look into the .origam file where the object you’d like to override is persisted. An example of a value property is the transactionBehavior…

  <w:Workflow
    asi:abstract="false"
    x:id="d2cefee8-1617-4a63-a838-33e916c9ea78"
    asi:name="Test1"
    w:transactionBehavior="InheritExisting">
    ...

Note object’s Id and the PropertyName without the namespace. To learn about the allowed property values for the PropertyValue field open the model in Architect. Find the object you are interested in using the search function and look at the available property values there. The resulting configuration file object to override the property transactionBehavior could look like this:

  {
    "Id": "d2cefee8-1617-4a63-a838-33e916c9ea78",
    "PropertyName": "transactionBehavior",
    "PropertyValue": "Ignore",
    "Description": "Test value"
  }

Some examples of the properties you cannot override in the configuration file are:

     ...
     csi:widget="Root/Control/_Basic Controls/AsTextBox.origam#AsTextBox/7d1ec946-017e-4a00-9d92-d4d6b9fabffc">
     ...
     scusa:commandText="-***-ExternalFile:1.0.0.origam___commandText___850618e1-e31b-4667-842b-04183e440b78.txt"
    ...

Why Can’t I See Value From the Config File in Architect
Architect will not display the configuration values for properties that are persisted in the .origam files as it could create a confusion as to where did the particular values come from and where they should be saved.

Properties Persisted in the Configuration File Only

These properties are marked in the Origam source code to be saved in the config file. As of now there is no way to find out which ones are marked this way when inspecting the model in the Architect or the origam files. That is why the complete list of the configuration file only properties will be maintained here:

Property Name in Model Name in Config File Exists on Object Type
TraceLevel traceLevel Workflows, Workflow Steps, Rules

You can look for the allowed property values in the way described above because the fact that the properties are save in the configuration file and not in .origam files does not change how they behave in the Architect.
Note for Origam developers: The properties have to be marked with RuntimeConfigurable attribute

1 Like

I would find a use to override these specific properties as well. E.g. overriding an XSLT either by configuring a different file or by linking to an alternative XSLT transformation.

Is there some difficulty in implementing these?