th2 is an Open Source
Next-generation Test Automation Framework
for Financial Markets.
It is designed to enable automation
in functional and non-functional testing
for complex distributed
transaction processing systems.
The key features of th2 are:
A high level of customisation
for Financial Systems.
It has a library of existing
built-in test components
that supports multiple protocols
such as FIX
and its dialects, Native, SoupBinTcp,
etc.
And it allows you
to create custom components
to support the logic
that is specific to your Financial System
th2 аllows you to develop your test
components using mainstream
programming languages
such as Java/Kotlin, Python and C++
th2 uses unified data storage
that enables you
to bring AI/ML into testing
It also provides you
with various options for testing,
such as real-time-based automation,
model-based testing,
load generation and more.
Today, we'll tell you about th2
and its integration with FIX Orchestra.
FIX Orchestra aims
to provide a standard for machine
readable rules of engagement
between counterparties.
Its goal is to reduce the time it takes
to get counterparties trading
and improve the accuracy of implementations.
It contains
additional information
that is not provided in
the commonly used libraries
for implementing communication
using FIX protocol, such as QuickFIXJ.
You can specify
conditionally required fields
for messages,
different sets of tags
in messages for different scenarios
of message use
and many other rules and validations.
Today we will see how this allows you
to perform additional validation
during functional testing.
In the demo example, we'll execute
the following scenarios:
Sending a valid Limit order,
Sending a valid Stop order
and receiving an invalid ExecutionReport,
And sending an invalid StopLimit order.
We will emulate system behavior
using the th2-sim component.
It allows you to define the rules
that will generate a response
for certain requests.
Let’s take a look at the rule definition.
We can see that the rule
takes a set of fields
from the original message,
adds some additional fields to the response
and sends it back.
Note that the StopPx field is not copied
from the original message.
Let’s run our scenarios
using the base fix codec
that does not know anything
about FIX Orchestra.
As we can see, everything is green
after the execution,
and no errors were generated by the codec.
Let's take a close look at the generated events.
We can see in the second scenario
that the Execution Report
does not have a StopPx field,
but it was still accepted by our script.
In the third case,
we can see that we were allowed
to send a message without the required tag,
and we have received a BusinessMessageReject message.
For that run,
we were using the codec
that uses the QuickFIXJ library
for decoding and encoding messages.
Now let’s switch to the FIX Orchestra codec.
It can work in two modes:
The first mode is the Error mode
in this mode,
the codec reports an error
and does not allow the message to go further.
The second mode is the Warning mode
in this mode,
the codec reports a warning,
but the message still goes further in the chain of components.
Let’s start with the error mode.
Let's run the script again.
We can see that the output is different now.
Let’s go to the report.
We can see that the report
now contains failed events in our scenarios,
and the codec root event
also contains events with errors.
Let’s take a closer look at the second scenario.
Now we see that the invalid response
was not received by our script.
The codec contains an event
about the error that occurred during message decoding.
We can see that
the required tag 99 is missing.
Also, in act events, we can see the list of messages
that were processed by act
while it was trying to find a response.
Our execution report
with the error reason is one of them.
In the third scenario,
we see that the message was not sent at all.
The codec has blocked it
from going further.
It can be used to stop testers
from sending messages
that do not correspond to the specification
in positive scenarios.
Now let’s switch to the warning mode
and rerun our script.
At this time, all the events are green
and our scenarios are passed.
But let’s check the codec events.
We can now see warnings among those events.
They say that something has happened
during the codec's work.
Here, we can see two warnings:
one for the invalid ExecutionReport response
and one for the invalid NewOrderSingle request.
Also, we can see a reference
in the codec in our third case,
where we had sent an invalid request.
Because th2 uses a unified storage
for all test data,
we can also analyze the results
after the fact using th2 data services.
It is a Python library
that allows you to request data from that storage
and perform different operations on it.
You can aggregate data, collect links
between messages and events
related to those messages,
as well as build charts and tables based on that data.
For the purposes of the demo,
we will extract all the errors
produced by the FIX orchestra codec
and see which messages it affects
and what kinds of errors we get when running our scripts.
This brings us to the end of our demo
of th2 and its integration with FIX Orchestra.
Thank you for watching.