Nium completes acquisition of Ixaris

6th April 2021

Flexible configuration with context properties

Dimensions and Context Property Module
Andrew Calafato

Andrew Calafato

Technology Director

As part of our Payments IQ series, Ixaris’ Technology Director Andrew Calafato delves into detail about our system configuration to explain how our Dimensions and Context Property Modules provide a flexible way to configure application or business properties.

System configuration can be stored in many ways and formats, including files (config files or ini files), repositories, configuration servers and databases. This article will explore business configuration stored in an operational database as part of an application.

At Ixaris, we have devised an interesting generic framework to handle such configurations, which we call context properties. A property value can be defined on some context, which comprises a list of dimensions.

For example, let’s imagine we need a configurable customer support email to be displayed in our web app:

  • depending on the account country,
  • and if need be, depending on the customer’s account type (Business / Consumer)
  • and even possibly for a specific account
  • or a system-wide default

Let us say we also need to have a configurable title displayed in the web app in front of the email link. So, we end up with the following context (list of dimensions), defined with some example configured values:

The module is split in two: the context management module and context property values module. (As we discuss later, the context management can be applied to a variety of other modules, and not just context properties.)

The dimensions module

In general, this dimensions module can store a list of dimension values’ in a table, which relates to a particular property. Each dimension value can be stored in 3 fields in a table:

  • An integer value
  • A float value
  • A string value.

Context property values are stored in a similar way. In the same example above, we can configure the system to store the two-part value as a pipe-delimited string (<Title>|<Email>). This is merely the way values are stored in the database.

The star (*) dimension entries are not stored in the database, and match any dimension queried.

A hash of the context is generated and used for sorting dimension entries like this:

  • Starting for the first defined dimension, which has the highest priority when searching, if the configured dimension value is more specific, the entry with the more specific value is returned first.
  • If the values match, the subsequent dimension is checked.
  • The FOR_EACH is a special dimension value used in modules such as context counters, which keeps a sum & count depending on a context. It will result in a CounterValue for each different value of the dimension, e.g. a separate counter specific for each account ID.
  • So in general, priority-wise, {specific value} > FOR_EACH > * .

The dimensions module offers 3 queries, or matching patterns, for a context:

  • Containing: This will match any defined configurations that are equal to or MORE specific than your query.
  • Matching: This will match any defined configurations that are equal to or LESS specific than your query.
  • Best match: This will return the highest priority entry from the matching pattern. This is the main query used when selecting a property.

Using the above example, if we query country = US, the three queries will result in these property values:

  • Containing will return entries 3 and 4
  • Matching will return entries 1,3,4 and 5 (all except the UK entry)

Typically, best match is used with a full context, so these entries are returned for different context:

Note how the last example matches the third and the fifth entry. This disambiguation of multiple matches is solved by the prioritisation of the dimensions, with the first dimension having the highest priority. We can achieve this effect using the context hash described earlier. So, the context for a property should be defined with the most ‘important’ dimensions first.

Usages of dimensions module

The context property value is one of the modules using the dimensions management module. If, in the example above, we wanted to extend the requirement to have a number of support email entries, we can use the context property set module. This is similar to context value, but each value can be a set of values, like in the below example:

Other uses of context functionality include the limits module, where each value is constant or percentage or rate — and optionally, for different currencies, and applied to particular date ranges.

We also have a context counter module, in which, for different dimensions, we keep a sum and count of a particular event. This is used to avoid executing complex queries every time we need to count/sum something, (for example, a limit check).


The dimensions and context property modules provide a flexible way to configure application or business properties. At the software development stage, a property can be easily defined to have a context (list of dimensions) and a simple or complex value structure. At runtime, generic system-wide values can be configured with an empty context, that is, having a * value in all dimensions. Different values can be configured with an even more specific context (for example, for all accounts in a particular country). Then, they can be ‘overridden’ for a particular type of account in a specific country or even a particular account ID.

Copy link to clipboard