QuickFIX/J User Manual

Installation and Building the Code.

Runtime Dependencies

Java Virtual Machine:

JVM compatible with Oracle JRE Java 1.7.x or higher.

Required run-time libraries:

(Note: The actual JAR files may have version numbers in them.)

Library Description
The QFJ core JAR and message JARs.
  • quickfixj-core.jar
  • quickfixj-msg-fix40.jar
  • quickfixj-msg-fix41.jar
  • quickfixj-msg-fix42.jar
  • quickfixj-msg-fix43.jar
  • quickfixj-msg-fix44.jar
  • quickfixj-msg-fix50.jar
  • quickfixj-msg-fix50sp1.jar
  • quickfixj-msg-fix50sp2.jar
  • quickfixj-all.jar (includes core and message JARs)
QFJ runtime libraries

Library Description
mina-core-2.0.16.jar Socket handling (Java NIO)
slf4j-api.jar SLF4J library for JDK logging.

Optional run-time libraries:

Library Description
log4j.jar If Log4J logging is desired. The JDK logging is the default.
slf4j-log4j12.jar Use this JAR file instead of slf4j-jdk14-*.jar if you want to use Log4J logging.
proxool.jar This JAR provided database connection pooling capabilities. It is required if you are using the JDBC store or log.
jcl104-over-slf4j.jar Adapts Jakarta Commons Logging to SLF4J. Required if you are using an optional library that depends on Jakarta Commons Logging. Currently, this includes Proxool (needed by JDBC store and log for connection pooling).
sleepycat-je.jar Needed if the SleepyCat JE message store is used.

By default, the XML processing in QuickFIX/J uses the XML parser included with the JDK. In general other parsers can be used but it's possible you will have problems. We've had users report that Xerces 2.6 does not work, but that version 2.8 does. If you try other parsers, please let us know if it works or not.

Building QuickFIX/J

These instructions are for developers who don't want to use the prebuilt binaries or are intending to modify and rebuild the QuickFIX/J code. If you are building the code from the command line you'll need to download and install Maven (version 3.2.5 or newer). If you are building from an IDE, Maven is usually included. Building from source requires Java 7+.

  1. Check out the code from GitHub. See the instructions at GitHub for more details on cloning the repository.
  2. Change directory to the top-level directory of the checked out code. You should see a pom.xml file.
  3. Run mvn package to build the QuickFIX/J and examples jar files. This will also generate all the FIX message-related code for the various FIX versions.
  4. There is an option for the code generator to use BigDecimal instead of double for fields like price and quantity. To enable this feature pass a -Dgenerator.decimal option on the command line when running the generate.code target.

Command-line Switches

There are various command-line switches you can pass to ant to modify the produced behavior:
Switch Description Default
-Dgenerator.decimal Generate BigDecimal vs doubles fields false
-DskipAT=true Skip running of acceptance test suite. false

For example, in order to generate fields with BigDecimals and skip acceptance tests:
mvn test -Dgenerator.decimal=true -DskipAT=true

IDE support:

There are Eclipse and Netbeans project definition files in the top-level directory of the checked out directory. When the project is first created, it will not have the generated message classes and compile errors will occur! Best is to compile once on the command line before importing the project into the IDE.

Maven Integration:

If you are using the Maven build system, you can reference the pre-built QuickFIX/J libraries hosted at the Central Repository repository.

Add the following to your dependencies section, with appropriate modifications based on the logging subsystem you choose:

<!-- QuickFIX/J dependencies -->

Generating the database for JDBC based store and log

Everything needed to generate your database is in the src/main/resources/config/sql subdirectories. For MySQL, there are the script and batch files create_mysql.sh and create_mysql.bat. These scripts will work on a newly installed mysql database with default permisions. The scripts will try to generate the database using the root MySQL account with no password. If you need to use a different account or need a password, you will have to edit the script. To select a different user, simply change 'root' to another user. To add a password, use pass the -p option after the username. Similar scripts are provided for MSSQL, PostgreSQL and Oracle.

Special notes for Oracle

Oracle treats empty strings as null values. Null values are not allowed for primary key fields. The fields used in the primary keys are:

If any of these keys contains an empty string, null constraint violations will occur. Therefore, the session_qualifier has been set to a non-empty string for Oracle.

Please also not, that for string fields always the VARCHAR2 data type should be used. If CHAR fields are used, they always have to be spaced-padded to the full length.

Testing QuickFIX/J

The development of QuickFIX has been driven by a suite of functional acceptance tests and unit tests. We have been working incrementally, functional test by functional test, writing the unit tests before the code. If these tests pass, we're reasonably confident that the engine works as intended.

The developer unit tests are written as JUnit tests and test the code directly. The functional acceptance tests are scripted FIX messages that are pumped into a running FIX server. Most of these tests are based off of the FIX Session-level Test Cases and Expected Behaviors document.

The unit tests can be run by running the test target in the pom.xml file. If you are using Eclipse, you can right-click on the quickfix package in the test subdirectory and select the "Run as... -> JUnit Test" option. This should locate all the unit tests in the package hierarchy and run them in the integrated JUnit test runner.

Acceptance Tests

QuickFIX/J also has a scriptable test runner that comes with a series of automated acceptance test. The basic tests that come with QuickFIX are based off of the FIX Session-level Test Cases and Expected Behaviors document produced by the FIX protocol organization. These tests verify that QuickFIX adheres to the FIX specifications. The automated nature of these tests guarantees that future releases of QuickFIX will not break any current functionality.

Perhaps even more importantly is how these test are used to drive the development of QuickFIX. Before a line of code is written in support of a protocol feature, one of these tests is written. This test first approach sets up a goal for developers who will have objective verification that they correctly implemented the standard.

To run the acceptance tests: If you are using Eclipse, right-click on the quickfix.test.acceptance.AcceptanceTestSuite class and select the "Run as... -> JUnit Test" option. This will start an acceptance test program with an embedded QuickFIX/J server, load the AT definition files and convert them to JUnit tests, and run those tests in the embedded JUnit test view.

Writing your own Acceptance Test Scripts

Below is an example of a test script that tests the engines behavior when it receives a NewSeqNo value that is less than the expected MsgSeqNum.


  # sequence reset without gap fill flag (default to N)
  E8=FIX.4.2␁9=112␁35=3␁34=2␁49=ISLD␁52=00000000-00:00:00␁56=TW␁45=0␁58=Value is incorrect (out of range) for this tag␁372=4␁373=5␁10=0␁


  # sequence reset without gap fill flag (default to N)
  E8=FIX.4.2␁9=112␁35=3␁34=4␁49=ISLD␁52=00000000-00:00:00␁56=TW␁45=0␁58=Value is incorrect (out of range) for this tag␁372=4␁373=5␁10=0␁

In these script there are two types of commands, action commands and messages commands. Action commands begin with lowercase letters while message command begin with uppercase letters.

Action Commands

i<ACTION> - initiates an action
e<ACTION> - expect (wait for) an action

Supported actions are:

iCONNECT - initiate connection to a FIX acceptor
eCONNECT - expect a connection from a FIX initiator
iDISCONNECT - initiate a disconnect
eDISCONNECT - expect a disconnect

Message Commands

I<MESSAGE> - initiate (send) a message
E<MESSAGE> - expect (wait for) a message

When using the I command, you do not need to add the Length(9) or the CheckSum(10) fields, they will be added for you with the correct values in the appropriate locations. The only time you would add these fields is if you intentionally wish to make them incorrect.

The I command also provides a TIME macros for fields. By setting a field equal to <TIME>, the current system time will be placed in the field. (i.e. 52=<time>). You can also use offsets such as 52=<TIME-120> or 52=<TIME+15> in order to set the time plus or minus some seconds from the current time.

The E command verifies that you have received the correct message. This command will compare the values of each field to make sure they are correct. Some fields cannot be verified deterministically before run-time such as the SendingTime and CheckSum fields. These fields can be added to the fields.fmt file where a regular expression can be defined to at least verify the field is in the correct format. For example:

10=\d{3}, checksum must be exactly three digits
52=\d{8}-\d{2}:\d{2}:\d{2}, sending time must be in the form of DDDDDDDD-DD:DD:DD where D is a digit.