In one of my precious articles I explained how to use our FIX connector to set up some inbound and outbound FIX connectivity. In this post I delve a little deeper into the actual FIX protocol traffic (whilst omitting some of the detail to keep things simple.)
For this scenario we will use the Mule connector in an counterparty role, more particularly it will represent a receiving bank (sell side) to which a trade could be ordered. As a reminder we will be using this flow:
In this case we will only be looking at the FIX traffic used to establish connection and send an order to Mule, which would then be processed by your custom fix logic.
The simplified traffic log looks like this:
There are several classes involved here, the FixConnectorInjectionAdapter, SenderFixEngine (in practice the buy side client) and the FixEngine (internal to the mule connector).
The first two lines were logged by the FixConnectorInjectionAdapter and are to wire up FIX with the Mule flow.
Note: internally to the connector the @Connect method in Devkit is used to start up the FIX connector engine. @Source is called once per inbound FIX session and allows Mule to capture FIX messages to be passed to the next message processor. Please see Mulesofts guide for Devkit for more details.
What follows in the next 5 lines is the FIX login handshake between the SenderFixEngine and the FixEngine in the FIX Mule connector. If you check out FIXimate you will see that the message type (tag nuber 35) field has a value of A (logon). Here is a short list of useful message types that appear in many FIX communication sessions:
The –FROM ADMIN– and –TO ADMIN– are just there to show where the information is being processed.
Note: internally to the Mule FIX engine we handle incoming admin messages in the fromAdmin() callback and then when sending admin messages to another FIX server we can have custom logic in the toAdmin() callback. Our connector should be able to handle common admin functionality out of the box but we are keen to extend as needs arise in real world scenarios.
Following on from the admin message there is the flow of FIX traffic to send a trade and receive it. The message in this case is of type D, new order single, which is then passed on to the logger as can be seen in the Fix Inbound xml gist. We then just log the raw FIX message (in the real world you would process the FIX message further with your custom logic.) The raw FIX message looks like this:
Breaking this down into a human readable format:
Essentially this is just a request to buy 100 EUR by the buy side client (STANDALONE_INITIATOR) from the sell side counterparty (MULE_FIX_INBOUND). Feel free to discover more about the message types from FIXimate.
Thanks for reading and feel free to comment. We hope to have more improvements as we gain more feedback from industry.