We now add to our a model functionality for Repeating Groups which allow multiple copies of the same record of information to be passed in to the system. For example the Parties of FIX version 4.4 is defined as
The NoPartyIDs is an indicator of the number of copies of this group that exist. All repeating groups must have a field with type NumInGroup or type NoSides which is restricted to a maximum length of 2.
In this repeating group, the field PtysSubGrp}is also a repeating group, meaning there are multiple copies of this group within each member of the Parties repeating group.
Customising Repeating Groups
With repeating groups, as with non-repeating records and messages, it is possible to add custom fields. Also it is possible to override a defined optionality of an existing repeating group to ensure certain elements be present within each copy of the group.
Add custom fields
As shown in the section on custom fields and cases it is possible to add a custom field to a repeating group. We do so here, by adding a new field of type int called PartyIndex:
It is important to note that any modification to a repeating group is true for all instances of that repeating group within the model. This means any field which is of type Parties in the model will have the same internal fields and optionality.
Changing field optionality
It is possible to change the optionality of a field with a repeating group. For example we could impose a condition that the PartyID field be required in all copies of the Parties field of message NewOrderSingle. We do this in this model, as well as explicitly importing the fields we want to include in the repeating groups for this model as follows:
Incorporating Repeating Groups
In order to incorporate repeating groups we first add a field to the NewOrderSingle message as follows:
We can add a validation statement to this field - for example:
which ensures that the new field PartyIndex is within a certain range, and that the PartyID field is not the empty string.
We can also add the Parties field to ExecutionReport:
More complex validation statements
It is possible to write more complex validation statements about repeating group elements. For example we could write the following:
which states that for each copy of the repeating group Parties, the PartyID field should not be the same as any of the PartySubID fields of the contained sub-repeating group PtysSubGrp if they are present.
Modification of State
We can modify state and introduce repeating groups in the same as for any other field. For example by adding to the assignable section:
Now the Parties element of the state will be automatically assigned to from the incoming message, and can be assigned to the Parties field of the outgoing ExecutionReport of a receive or reject block.
Errors and Warnings
Tag consistency errors apply to the fields of repeating groups as they do for any other field. Further, it is only possible to assign entire repeating groups e.g.
It is not possible to assign to a particular field. Particular fields can only be referenced in boolean expressions such as
which implicitly checks that all PartyID fields are not equal to "acct".
If you try to write, for example
you will receive the error message
Repeating Group fields can only be referenced in a boolean expression.
Full Model – Imandra Analysis
Click on the image below for an interactive analysis of this model performed by imandra.
Full Model - IPL Code
Generated Documentation
Click here to view the generated documentation for this model.