Documentation for a newer release is available. View Latest

Dynamic Processing Settings (DPS)

Dynamic Processing Settings is design pattern can be implemented within an IPF Service as a library that facilitates the CRUD operation on the underlying MongoDB collections called the Dynamic Config Settings.

dynamic processing settings overview.drawio

The diagram above depicts the functional positioning of the Dynamic Processing Settings in the overall context of the IPF implementation. It must be possible that the same Dynamic Processing Settings can be used in multiple process flows and the business functions invoked from these process flows that can be deployed in different processing services (e.g Working Days Service). Dynamic Processing Settings must include APIs through which the concerning data can be registered, maintained and managed via the IPF GUI and data import applications, as well as (GUI) applications outside IPF.

There are several methods in which Dynamic Processing Settings can be applied in process flows and the business functions called from these process flows.

  1. A process flow retrieves via an API call the relevant Dynamic Processing Settings data and maps this data to a PDS so that the processing settings data can be used in subsequent parts (steps) of the process flow. This makes it possible to create generic process flows that are (re)used across multiple processing entities, but use processing entity specific processing settings to differentiate in the way payments/transactions for the concerning processing entity are processed (such as in conditions that define whether a certain process step need to be carried out or not).

  2. A process flow calls a business function that makes use of the relevant Dynamic Processing Settings data that is needed to execute its task (business logic) and return the result back to the process flow. It is part of the technical design of each business function (and possibly even as part of an implementation design) to determine whether it is included in the deployment of the processing service from which it is called or it is deployed in a separate deployment outside the processing services from which it is called.

It is recommended that every service implementations guidelines are followed on whether Dynamic Processing Settings can be used directly within the flows or other APIs provided by the service are used to interact with Dynamic configurations (e.g. Domain APIs provided by CSM Reachability Service)

It is also determined during the technical design whether the relevant Dynamic Processing Settings data are retrieved by a processing service when it is needed or is being cached into the processing service to meet specific non-functional requirements like performance and latency.

IPF Dynamic Configuration and the underlying Dynamic Processing Setting are vital within the IPF Solutions to facilitate the smooth processing of the payment.

Dynamic Processing Setting is an IPF framework for dynamically updateable configuration that is used during processing of a payment/transaction so that the update is applied instantly or scheduled to be applied later, but overall doesn’t require an application restart to take effect.

For a setting to be implemented as DPS it must make sense from a payment/transaction flow perspective. This means we should only define settings as Dynamic Processing Settings if they are meaningful to be used within a processing flow e.g. currency or limit settings for a CSM agent or selected CSM agent for a given payment parameters etc.

In order to update a dynamic setting, an approval process may be required, based on a "requires approval" flag. This gives higher flexibility on updating a setting, as not all updates may require approval.

Dynamic processing settings (DPS) is a model that provides an extensible and customisable approach for defining a catalogue of settings for different data types, alongside a pre-defined, but equally extensible, approval process.

The current use of DPS is not as a standalone application. It’s used as a pattern to facilitate the re-usability of the dynamic settings implementations. It’s an embeddable model that can be used to provide dynamic updates of data types with a pre-defined approval process for various different domains.

Some examples of the applications that are using DPS are

  1. CSM Reachability Service

    1. Agent Settings, Agent Settlement Settings, CSM Participants, Processing Entity and so on are a few examples of data that has been implemented as DPS. This means CSM reachability application contains DPS implementation in addition to the core reachability and additional functions.

  2. Working Days Service

    1. Calendar data is another example of DPS. Calendar data types are defined as settings catalogue and DPS is embedded within the working day service application as a supporting feature.

  3. Payment Status Notification

    1. Application responsible for consuming domain events and based on a filter and notification configuration, it produces payment status notification in pain002 json format into a Kafka topic. Internally it also uses DPS, for the filter and notification configuration. The usage is pluggable, instead you can also use a hocon config instead of a Dynamic Setting Configuration.

DPS is part of the SDK core. It’s implemented as a framework and reusable libraries so that IPF SDK clients can also create client specific implementations that uses DPS and as a result benefit from dynamically updatable data with an approval process, without having to rewrite the whole process.

DPS is made of many components such as

  1. Settings Catalogue - Specific settings which have been defined to be managed by the Dynamic Processing Settings framework. Contains supporting infrastructure such as read side models and settings definitions.

  2. Settings Domain - Contains generic setting domain and model objects e.g. CreateSetting, UpdateSetting, Setting.

  3. Settings Workflow - Contains the MPS generated artefacts to support lifecycle management via Event Sourced Behaviours.

  4. Settings Management API - Contains the API framework which is used to manage the settings (CRUD API).

Business Functions

A business function is a specialized type of function that is designed to assist with one or more IPF processing flows. It does this by providing data lookup or data processing services that are idempotent, meaning they are independent and can be consumed repeatedly without changing the outcome. For a function to be called a business function in IPF terms, it must make sense to call from a processing flow. This means not every API operation IPF exposes is a business function. For instance connector API operations are not considered business functions.