DSL 1 - Introducing Icon’s DSL

We start by considering data. Data is what drives processing and decision making throughout IPF.

The first concept we consider therefore is the "Business Data Element". It has four properties:

Any MPS project can have as many different business data elements as you need. These elements are defined within a "Business Data Library" which is simply a collection of related business data and as many different business data libraries can be defined as needed.

Within the lifetime of a payment each business data element is unique and it can be updated as required.

The processing of a payment is performed by a "Flow". A flow represents a single business process from end to end and is designed to specify the lifetime of a single payment. A single flow might have many paths through it, each representing a different way of processing an individual payment based on the data provided for that flow. A flow contains a number of things:

A definition of each of these aspects are discussed in the following sections.

First we consider the "Global State Set". The global state set is a set of states that represent the overall state of a payment. It is particularly used where a payment may span multiple flows (for example if the payment processing is split into "initiation" and "execution" parts) but can also apply an overall grouping type state to the individual flow parts to simplify the apparent state transitions from a payment level. Each flow level state can be mapped to a global state such that multiple flow level states can all be considered to leave the payment in the same overall global state.

The next concept to consider within our flow is a "State". This is very simply a resting point on the flow that the payment can pass through in it’s journey, so for example we may have a very simple flow that goes from "State A" to "State B".

A state itself has a number of properties:

Each flow can contain many different states.

When a flow moves from one state to another, this is known as a "State Transition". Within IPF, for a state transition to occur then the system needs to receive an "Event" on the processing journey of the payment. In this case, it is actually a specific type of event known as a "Domain Event". A domain event is a persisted factual occurrence - the arrival of an event means that something explicit has occurred which may cause some form of change to the processing of our payment.

An event has a number of properties:

When an event is formed, then the system will check it’s own behaviour to determine what actions should be performed. Whilst this behaviour is explored later in this document, it is worth noting here that there are three occasions when an event can cause a change to the processing, these are known as the "Event Criteria" conditions and are defined as:

After an event is processed, the application can then perform one or more activities to determine what happens next on a payment. So for example on receipt of "Event A" we may wish to do some validation and call some other application to ask it to validate our data.

To support this post-event processing, the most important concept is the "External Domain". This represents some business domain - not our current flow’s - that we need to interact with.

For example, let’s assume that we need to talk to a sanctions system during part of the flow. To support this, we would model that sanctions system as an external domain.

Each external domain consists of the three types of interaction we can make with it:

It’s possible that we don’t want to have to call an external domain in order to continue processing our flow. This might happen because either we know what to do next or we can calculate what to do next. For this there are two other concepts that we need to consider:

In this case, one option is to use the "Domain Function" capability that the flow itself offers. It works in a very similar way to a request / response pair in an external domain call except that in the case of a domain function the IPF application itself is a domain so the actual call stays internal (consider for example creating an external domain that represents our current flow - this would work the same way as a domain function but would be a mis-representation of the actual control logic). So when we call a domain function, we will expect to get a response and then that response will be transformed into an event which can then cause onward processing.

Like a request, the domain function has a number of properties:

The second option is an "Additional Event"- these can also be used to move the flow on.

When an additional event is raised, the system will process it as though it has been received into the application via an instruction or response.

Let’s add these to our diagram:

What however if we want to perform some logic conditionally. So for example, we may only want to run a fraud check if the value of the payment is over £50. In this case we can use a "Decision".

A decision allows us to perform some logic and then take different processing routes subsequently based on the outcome of that decision. A decision has a number of properties:

The decisions themselves are stored within a "Decision Library". The libraries are flow-independent and as such the same decision can be used in multiple flows.

We can use a decision in two places:

Lets add these to our diagram:

Another useful utility to consider is the "Aggregate Function". An aggregate function is a piece of logic that can be executed upon receipt of an event to perform some kind of logic upon the data received. This data is considered "in flight" and thus is not persisted by the application.

So a good example of this is say a counter that tracks the number of times something has occurred during a flow - each time the function is called we may update that counter. The outcome of the aggregate function then becomes available down the flow.

Another good use case may to perform a data mapping exercise to transform the data into something that can be used downstream.

Let’s add the aggregate function to our diagram:

The next concepts to consider are both types of grouping. In order to separate the logic we need to define when processing an input to the system (from a response or instruction) and generating the event to the logic required when processing the actual behaviour of the system based off that event we have two grouping concepts:

The next thing to consider is reusable segments of flow.

For example, consider a sanctions check that may be required to be called from various different places within the flow. We could specify each section of the flow separately and write out the logic each time but ideally we would like to be able to simply reuse common logic each time. This is where the "Subflow" concept is introduced.

A subflow is a reusable flow component. It is essentially the same as a flow in that it has states, input behaviours and event behaviours. However, a subflow has no life of it’s own and is only used as a mechanism of reuse and therefore MUST be contained within an outer flow. When calling a subflow it is very similar in behaviour to receiving an event:

The key thing to understand here that is instead of moving to a state and then calling an action like the normal processing above, here we move to a pseudo-state that acts as an entry point into the subflow. "Control" of the flow is then handed over into the subflow, at this point it will process through the input and event behaviours until it reaches a terminal state in the subflow. When it reaches a terminal state, control will be passed back to the calling flow with a result of the name of the terminal state. This can then be used for onward processing.

Note that in order to achieve reuse of the subflow in multiple places, then when a subflow is placed within a main flow it’s state’s will be displayed as "<subflowid> <subflow state name>" where <subflowid> is the psuedo-state name of the calling flow and <subflow state name> is the name of the state within the subflow.

Finally, it’s also possible to directly call one flow from another. In this case control is handed over to the secondary flow and we wait for a result execution back. The child flow can report that it has reached any state back to the parent flow. Most commonly, this will be when a terminal state is reached and the child flow has finished processing, but it also allows for feedback from the child flow for intermediary states before it finishes. This provides an opportunity to pass control back and forth between the child and parent as required.