Fix message manipulation

I have had a chance to work on some projects which involved minor modifications to fix messages on a repetative basis. Since this project was in C++ i wrote an initial header file to get the required result. later on out of curiosity i ported the same methods to java and bingo i have methods to work both in C++ and Java. The discussion which proceeds is related to methods and their usage and source code for the same.

Need:
The work involved parsing of FixSession.log files and making some generic changes to it (like replacing all client names and codes with cypher text or changing stock codes to dummp code and so on). This was done to take care of compliance and regulatory requirements. So, i worte two methods :
String getValueForTag(String fixMsg,String tag)
String replaceTagValue(String fixMsg, String tag, String replace)

Why all string manipulation? the reason was i was reading a file containing these messages and so string was the most logical choice.. only later did i realise that this is what makes the task easier when working with realtime systems. Time for some code now.... (pasting images as formatting gets lost on blogger mail me for full source code)

replaceTagValue[java]


replaceTagValue[C++]


getValueForTag[java]


getValueForTag [C++]


After you are done with FixMessage manipulation you need to recalculate the checksum value and the body length value before u send out this message on the network. (why is this done? well these checks are useful in determining if the message recieved is complete in all respects and if not a resend can be requested. This is vital in case of applications working in unreliable network connectivity) And to do this you can use the following methods:

For CheckSum Calculation C++ (Tag 10)



Java:


For BodyLength calculation (tag 9) C++:


Java:

Introduction to FIX messages

FIX (Financial Information exchange) is a protocol which allows user/traders/financial systems to automate the order management……. Enough !!! lets stop this technical blabbering and get something concrete and easy to digest on this plate. Its basically a set of rules just like formula one.

Is It a Data Representation Format?
Protocol is just a heavy name for rules, rules which we all love to hate which ironically make them indispensable. Before I start with any of this crap, let’s set up some sample data, using which we will try to understand why we need these rules in the first place. Consider an order with very small number of attributes. (The types which we love to create while creating sample orders)

Order Type: single order
Stock Code: 7200.T
Quantity: 10000
Price: 4.21

Whatever I have typed above can also be a way to represent an order, which can be easily interpreted by the human beings. But from an application perspective I can also represent the same data something like this:

As you would have guessed it by now this is an xml representation of the same data. The nice thing about xml is that its universally understood. So, in case you want to send out data from one application to another, one of the most popular ways of doing it is to send out an xml representation. But in spite of its many advantages, xml has some disadvantages. There is no standard on what tags can be used as anyone can use his/her own custom tags. Also xml data is difficult to parse when the hierarchy is very deep and adds additional overheads for applications which are meant to be hugely scalable.

Just for the sake of completeness I have showed below another form of data representation called JSON which is common in AJAX based web applications.

Bottom-line being that you can use any format for data representation, provided the “rules of the engagement are correctly specified” or in heavy words the “protocol is put in place”.

Another popular format is the tag/value representation, which is depicted something like this

10=A;11=7200.T;12=10000;13=4.21;

Where, 10 is Order Type
11 is stock code
12 is quantity
13 is price

This format has advantages, its crisp and the data is represented in just one line. There is no restriction on the number of attributes. And its simple “tag=value” separated by delimiters which you can select your own favourite. Personally I would prefer this nice isn’t it !!! But again there is no standard, no rules !!! I can define my own set of tags and make my own API.
So, all different organisations will have their own propriety tagging conventions (which is actually true in case of the client i work for) This is suitable for internal workings of one single organisation but obviously has loopholes when considering the scenarios when systems across organisations need to interact with one another.

Keeping all these considerations in mind people in the financial domain thought and agreed to another kind of data representation (which is basically the tag/value way of representation). This has its advantages. If you create an application which supports FIX protocol you can make your application “pluggable” to other third party systems/applications whether they are upstream or downstream.
In comes FIX to solve the problem. Let us have a look at the fix representation of the data we have been talking all this while.



If you look up the fix specification (http://fixprotocol.org/) following tags are of special importance and they form part of all the fix messages. They are:
8: This is the BeginString tag which identifies the beginning of new message and the protocol version. This is always the first tag in any fix message.
9: This is the BodyLength tag which contains the message length of the fix message. This is always the second tag of any fix message.
10: This is the CheckSum tag, which contains the basic checksum value of the entire message. This always forms the last tag of the FIX message and signifies the end of message.
The delimiter is the char 001 as per ASCII character set.

So, to conclude this section, we can safely say that FIX is just another format used to represent data, specific to financial sector.

*** We will be discussing these tags in more detail in later parts. Whenever in doubt which tag means what you can refer to the following online Fix dictionary: http://www.b2bits.com/fixopaedia/fixdic42/index.html

That’s enough for introduction !!!
So to conclude this section let me quote the official definition of FIX which says “The Financial Information Exchange protocol (FIX) is an open specification intended to streamline electronic communications in the financial securities industry. FIX supports multiple formats and types of communications between financial entities including email, texting, trade allocation, order submissions, order changes, execution reporting and advertisements.”

I hope the definition makes more sense now !!!