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

Back in 2008 we uploaded the first version of our FIX transport for Mule to the Mule Forge. The FIX (Financial Information eXchange) protocol, owned and maintained by FIX Protocol Ltd. (FPL) is widely used in the financial community to provide real-time electronic exchange of securities transactions.

This first release of our FIX transport was developed for Mule 2 and until recently was not compatible with Mule 3. We are now happy to announce that we’ve ported this transport over to Mule 3.x (tested with Mule 3.3.1 CE). The implementation of this transport is based on version 1.5.3 of QuickFix/J. QuickFix/J is a widely-used library that provides a means for developers to use the FIX protocol in their applications. The configuration file below is a simple use case that illustrates the FIX transport in action with Mule 3.

Below is a code snippet found in the Java component which is referenced in the XML configuration file:

The Executor component found in the server flow is responsible for validating trade requests and to provide reporting on these requests. The code below represents a method that the component uses to validate a single order and send back a report.

The configuration expects an HTTP request from an external party, say a partner or a client, which then creates a NewOrderSingle object in NewOrderComponent. After the Java component has created a NewOrderSingle object, the request is dispatched to a FIX outbound endpoint which is received by the FIX server (found in the server_flow). When the FIX server receives the client’s request, it validates the order and if it succeeds, it accepts the trade and sends back an ExecutionReport.

One should note that each FIX connector is coupled with a configuration file. Each of these files specify parameters that are required by both the server and the client to connect with eachother. Below are the configuration files for the client and the server respectively:

Client configuration file
[default]
ConnectionType=initiator
SenderCompID=CLIENT
TargetCompID=SERVER
SocketConnectHost=localhost
StartTime=00:00:00
EndTime=00:00:00
HeartBtInt=30
ReconnectInterval=5

[session]
BeginString=FIX.4.1
SocketConnectPort=9977

Server configuration file
[default]
ConnectionType=acceptor
StartTime=00:00:00
EndTime=00:00:00
HeartBtInt=30
ValidOrderTypes=1,2,F
SenderCompID=SERVER
TargetCompID=CLIENT
UseDataDictionary=Y
DefaultMarketPrice=12.30

[session]
BeginString=FIX.4.1
SocketAcceptPort=9977

FIX uses the initiator and acceptor pattern to execute trades. The initiator (client) is attempting to initiate a connection with another party, while the acceptor (server) is accepting connections from existing parties.

A configuration file should always specify the following:

  • ConnectionType – Specifies whether this specific connector runs as an acceptor or initiator
  • SenderCompID – The ID of the server that sends messages to other parties while listening for existing messages.
  • TargetCompID – The ID of the client that the server sends messages to.
  • BeginString – The FIX version number.
  • SocketAcceptPort – The port where the server should listen for messages.

A larger, more complete list of parameters accepted by FIX in config files can be found here.

For further information, follow the references below. These should give you a better understanding of how the FIX protocol works and what changes were made to enable the porting of the previous version of the FIX transport over to Mule 3.x.

To obtain access to our FIX transport for Mule 3 please contact us here:  info (at) ricston (dot) com and we’ll be happy to assist.