Documentation for a newer release is available. View Latest

Step 10 - Add a Subflow

Introduction to Step 10

In this step you will introduce a subflow. Using a subflow is a way of logically grouping together a set of events and states (in this case sanctions). Subflows can be reused within the same flow and in different flows in the same model.

If you are familiar with use case modelling, a subflow is exactly the same as a use case that is INCLUDED in another.

For this use case, you will be calling the sanctions subflow once you have completed the debtor account validation and the validation has passed.

You will introduce the following sanctions flow:

  • A request is sent to a new sanctions external domain

  • If the response is 'no hit' continue processing the payment

  • If the response is 'hit' a second response will be expected that will be either 'pass', 'fail' or 'block'

  • If the response is fail then the transaction is rejected

  • If the response is block then the transaction will be dealt with manually and the payment is terminated

Creating a new Subflow

You can create a new subflow by right-clicking on your model from the left hand panel and selecting New>v2Fo>SubFlow.

Give the subflow a name, and you have created an initial subflow which should look like something like this:

step 10 1

Filling in the subflow

You will see that a subflow is set out exactly the same way as a flow, where you define your states and events and add them to your initiation, input and event behaviours.

Now that you have been creating and updating flows for a while have a go yourself at building a valid sanctions flow. You will need to:

  • Create an external domain to represent the sanctions system

  • Create a single sanctions request with multiple responses for a 'Hit',' 'No Hit' and the 'Final Response'

  • Create a new response code library for the possible 'Final Response' codes from sanctions ('Pass', 'Fail' or 'Block')

  • Define your states and events in the subflow

  • Create an initiation behaviour in the subflow

  • Build those responses into input behaviour in the subflow

  • Complete the subflow by creating event behaviour

External Domain

Once you have finished, your new external domain should look like this:

step 10 2

Response Code Library

Your updated response code library should look like this:

step 10 3

subflow

And your subflow should look like this:

step 10 4
The global state for everything in the subflow is 'PENDING' because we want all the substates to be viewable in the IPF Dashboard under that global state. You could create a new library of global states just for the sanctions subflow and use those instead if you wished.
step 10 5
step 10 6
step 10 7
step 10 8

subflow Graph

If you look at the graph for your subflow, you will see it looks something like this:

step 10 9

Add the subflow to Event Behaviour

Now you have created a reusable sanctions subflow, you can plug it into your flow.

Add a subflow Sub State

First of all you have to put it in the right place - once the account validation is passed you will be checking sanctions prior to deciding whether it’s an 'On Us Payment' or 'Scheme Payment'.

So in the first event behaviour, delete the decision from the 'Move to State' and press Ctrl+Space. You will have the option to create a subflow state, so pick that option and your event behaviour should look like this:

step 10 10

Name the subflow

Like decisions, which you used in a previous step, subflows can be used multiple times so you need a unique name each time a subflow is called.

In your use case you are going to call the sanctions subflow once before being sent to clearing so let us call the substate 'Sanctions'.

step 10 11

Add Call subflow Action

Once you have moved the payment to the subflow substate, you also have to instruct the flow to actually send the payment to the subflow.

Replace the 'Perform Action' (which is currently the decision) with a call to a subflow by deleting the current entry and pressing Ctrl+Space and then selecting the subflow you have just created.

If you had created multiple subflows, all of those subflows would be available to select.

step 10 12

Finish off Event Behaviour

Now you have created a new 'Sanctions' substate, you can now specify what should happen when the payment is in that state.

For subflows, a terminal state is the equivalent of an event (i.e. a terminal event in a subflow is used to move the payment from one state to another in the calling flow).

If you remember you created three terminal states in the subflow: 'Sanctions Passed', 'Sanctions Blocked' and 'Sanctions Failed' - you need to add these into the event behaviour of the calling flow.

Add two new event behaviours as shown below.

You have to build the decision that you removed from event behaviour 1 into the new event behaviour (in this case 11).
step 10 13

Check the Flow Graph

You can now see that the called subflow shows in the flow viewer as a green box. The events that exit the subflow, are the terminal states that you defined within the subflow.

You can also expand the subflow within the same graph if you wish.

step 10 14