Managing Environment-Specific Configuration

In my last post, I discussed ways to programmatically modify Rule Applications in code to handle different configurations and data requirements in different environments. While that method is certainly useful, it takes significantly more effort than is necessary to fit the needs of the vast majority of InRule customers.

Today, we’re going to look at three simple ways to alter your execution configuration between different environments.

Each of these methods can configure overrides for the same set of items, any number of which you may have in your Rule Application. Some examples of items in your Rule Application that can be overridden using any of these methods include:

• REST Service Root URL and Authentication information
• Webservice URL and Configuration
• Database Connection String and SQL Query
• Inline Value List and Table data

To demonstrate each method of specifying execution settings, I’ll provide an override for two everyday items from the above list: a REST Service root URL, and a database connection string.

Option 1: OOTB Rule Execution Service (RES) Overrides

This functionality has been around for quite a while, and using it is incredibly straightforward. When placing an execution request to the RES, simply add to your body some additional information about what you’d like to modify within the Rule Application.

This sample request has the override specifications listed on lines 10-21:

{
    "RuleApp":{
        "RepositoryRuleAppRevisionSpec":{
            "RuleApplicationName":"MortgageCalculator",
            "Label": "LIVE"
        }
    },
    "EntityName":"Mortgage",
    "EntityState":"{'LoanInfo': { 'Principal' : 400000, 'APR' : 3.1, 'TermInYears' : 30 }}",
    "RuleEngineServiceOptions":{
        "Overrides":[{
            "OverrideType": "RestServiceRootUrl",
            "Name": "ExchangeRateService",
            "RestServiceRootUrl":"https://api.exchangeratesapi.io"
        },
        {
            "OverrideType": "DatabaseConnection",
            "Name": "SupplimentalDataStore",
            "ConnectionString":"Data Source=localhost;Initial Catalog=Dev;Integrated Security=SSPI"
        }]
    }
}

Pros

• It’s simple to use different values for different requests
• There is no additional server-side work needed

Cons

• It requires the executor to know what the correct values should be in the environment – this may include credential information

Option 2: RES Configuration Overrides

This functionality was added in InRule v5.6, and is a streamlined solution to overriding settings. By taking advantage of Application Configuration files as well as Microsoft ConfigurationBuilders, you’re able to provide Overrides in a variety of locations, and they’ll be used for any executions flowing through that execution service. While by default the web.config is only set up for AppSettings-based and Environment Variable-based overrides, you’re also able to update the configuration to include overrides brought in by ConfigBuilders from JSON configuration files, files on the filesystem (KeyPerFile), and UserSecrets.

Regardless of where the configuration settings are stored, the keys will always follow the same structure:

Inrule:runtime:overrides:{objectname}:{overridetype}:{settingname}

That key structure can be used to specify an override in the RES web.config file:

<appSettings>
  <add key="inrule:runtime:overrides:ExchangeRateService:RestService:RestServiceRootUrl" value="https://api.exchangeratesapi.io" />
  <add key="inrule:runtime:overrides:SupplimentalDataStore:DatabaseConnection:ConnectionString" value="Data Source=localhost;Initial Catalog=Dev;Integrated Security=SSPI" />
</appSettings>

In Environment variables:

Or in any of the other locations mentioned previously.

Pros

• It’s simple to configure for an environment
• There are flexible options for how the setting gets stored
• Override values are stored on the Execution Service host, so do not need to be known by executors
• Only one setting is needed to override all Rule Apps running through that Execution Service containing an item with the same name

Cons

• It requires a server-side configuration
• The setting will impact items with the same name within all Rule Apps running through the execution service (this was listed as both a pro and a con – depending on your environment, this could be either desirable or a drawback)

Option 3: irSDK Custom Execution Service Overrides

Finally, this option has also been around for a long time, and it offers the largest amount of flexibility. That flexibility, however, comes at the cost of operating within the context of a custom execution service.

In your irSDK code that executes Rules, you’ll simply need to specify the overrides on the RuleSession prior to executing rules; the pertinent code is on lines 3 and 4 below:

using (var session = new RuleSession(new FileSystemRuleApplicationReference(ruleAppPath)))
{
    session.Overrides.OverrideRestServiceRootUrl("ExchangeRateService", "https://api.exchangeratesapi.io");
    session.Overrides.OverrideDatabaseConnection("SupplimentalDataStore", "Data Source=localhost;Initial Catalog=Dev;Integrated Security=SSPI");
    var entity = session.CreateEntity(entityName, initialState);
    session.ApplyRules();
    return entity.GetXml();
}

Pros

• This operation is extremely flexible, allowing you to pull setting values and override information from anywhere within your architecture

Cons

• It requires your developers to write and maintain a custom execution API/Service using irSDK that implements the appropriate behaviors

It’s that easy!

There you have it – three different ways to assign overrides to your rule execution requests! Depending on your needs, this should open up some avenues to simplify your multi-environmental woes and give you a clear path to configuration nirvana.