Warning: A non-numeric value encountered in /home/ricston2/public_html/blogarchive/wp-content/themes/Divi/functions.php on line 5766

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:

 

Untitled drawing(2)

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:

A= Logon
0= Heartbeat
3=reject
4= SequenceReset
5= Logout
8=ExecutionReport
D=NewOrderSingle

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:

8=FIX.4.29=14235=D34=249=STANDALONE_INITIATOR52=20131126-12:01:21.17456=MULE_FIX_INBOUND11=121=138=10040=C54=155=EUR/USD60=20131126-12:01:21.11310=243
F

Breaking this down into a human readable format:

8=FIX.4.2 BeginString FIX.4.2
9=142 BodyLength 142
35=D MsgType D
34=2 MsgSeqNum 2
49=STANDALONE_INITIATOR SenderCompID STANDALONE_INITIATOR
52=20131126-12:01:21.174 SendingTime 20131126-12:01:21.174
56=MULE_FIX_INBOUND TargetCompID MULE_FIX_INBOUND
11=1 ClOrdID 1
21=1 HandlInst AUTOMATED_EXECUTION_ORDER_PRIVATE_NO_BROKER_INTERVENTION
38=100 OrderQty 100
40=C OrdType FOREX_MARKET
54=1 Side BUY
55=EUR/USD Symbol EUR/USD
60=20131126-12:01:21.113 TransactTime 20131126-12:01:21.113
10=243 CheckSum 243
F F

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.