QuickFIX/J User Manual

Installation and Building the Code.

Runtime Dependencies

Java Virtual Machine:

JVM compatible with JRE Java 1.8.x or higher.

Required run-time libraries:

QuickFIX/J has "base" and "core" libraries for the FIX "Engine" and one or more Message libraries are required at runtime.

The required Message libraries depend on the FIX Protocol Version. A QuickFIX/J process can support more than one FIX Protocol version at runtime, using different Session configurations.

Please note that customised versions of the FIX message artefacts can be built to meet specific Rules of Engagement. Please refer to the QuickFIX/J github repository for details.

(Note: The actual JAR files have semantic version numbers in the name. For example : quickfixj-messages-fixlatest-3.0.0.jar)

Optional run-time libraries:

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 pre-built 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.5.0 or newer). Building from source requires Java 8 or later.

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 mvnw 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

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

Find further details in the project readme

IDE support:

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. If the IDE reports some errors after the compilation with mvnw package, try to use mvnw install .

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.

You need only include message libraries for the FIX protocol version that you require.

Note : the quickfixj-messages-fixt11 jar is required for FIX versions 5.0 and later.

The following example shows maven dependencies, any SLF4J compatible logging implementation can be used:

<!-- QuickFIX/J dependencies -->
<dependency>
    <groupId>org.quickfixj</groupId>
    <artifactId>quickfixj-core</artifactId>
    <version>3.0.0</version>
</dependency>
<dependency>
    <groupId>org.quickfixj</groupId>
    <artifactId>quickfixj-base</artifactId>
    <version>3.0.0</version>
</dependency>
<dependency>
    <groupId>org.quickfixj</groupId>
    <artifactId>quickfixj-messages-fix40</artifactId>
    <version>3.0.0</version>
</dependency>
<dependency>
    <groupId>org.quickfixj</groupId>
    <artifactId>quickfixj-messages-fix41</artifactId>
    <version>3.0.0</version>
</dependency>
<dependency>
    <groupId>org.quickfixj</groupId>
    <artifactId>quickfixj-messages-fix42</artifactId>
    <version>3.0.0</version>
</dependency>
<dependency>
    <groupId>org.quickfixj</groupId>
    <artifactId>quickfixj-messages-fix43</artifactId>
    <version>3.0.0</version>
</dependency>
<dependency>
    <groupId>org.quickfixj</groupId>
    <artifactId>quickfixj-messages-fix44</artifactId>
    <version>3.0.0</version>
</dependency>
<dependency>
    <groupId>org.slf4j</groupId>
    <artifactId>slf4j-api</artifactId>
    <version>2.0.6</version>
</dependency>
<dependency>
    <groupId>org.slf4j</groupId>
    <artifactId>slf4j-log4j12</artifactId>
    <version>2.0.6/version>
</dependency>

Please refer to the QuickFIX/J github repository for more details about working with QuickFIX/J.

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:

• beginstring
• sendercompid
• targetcompid
• session_qualifier
• msgseqnum

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.

  iCONNECT
  I8=FIX.4.2␁35=A␁34=1␁49=TW␁52=<time>␁56=ISLD␁98=0␁108=30␁
  E8=FIX.4.2␁9=57␁35=A␁34=1␁49=ISLD␁52=00000000-00:00:00␁56=TW␁98=0␁108=30␁10=0␁

  # sequence reset without gap fill flag (default to N)
  I8=FIX.4.2␁35=4␁34=0␁49=TW␁52=<time>␁56=ISLD␁36=1␁
  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␁

  I8=FIX.4.2␁35=1␁34=2␁49=TW␁52=<time>␁56=ISLD␁112=HELLO␁
  E8=FIX.4.2␁9=55␁35=0␁34=3␁49=ISLD␁52=00000000-00:00:00␁56=TW␁112=HELLO␁10=0␁

  # sequence reset without gap fill flag (default to N)
  I8=FIX.4.2␁35=4␁34=0␁49=TW␁52=<time>␁56=ISLD␁36=1␁123=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␁

  I8=FIX.4.2␁35=1␁34=3␁49=TW␁52=<time>␁56=ISLD␁112=HELLO␁
  E8=FIX.4.2␁9=55␁35=0␁34=5␁49=ISLD␁52=00000000-00:00:00␁56=TW␁112=HELLO␁10=0␁
  iDISCONNECT
  

Action Commands

Message Commands

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.