FIX Made Easy With BIG-IPs FIX Profile

The world is largely run on the web, these days. And by “web” I mean “somehow transported over a TCP/IP or UDP based connection”. While much of this is handled with boiler plate or slightly coerced HTTP as the transport protocol, meaning things sit inside HTTP payloads and are handled by web servers, there are a fair number of other heavily used and rapidly growing protocols. This rings true in nearly every vertical, and finance is no different. In the financial arena, especially when dealing with trade information on either the buy side (institutions) or sell side (brokers & dealers), it is common to see the FIX (Financial Information eXchange) protocol crop up repeatedly.

The FIX protocol is comprised of a number of fields, each of which is a tag & value pair, separated by a common SOH (Start of Header) delimiter. The tag, which is effectively the name in a name:value pairing in more traditional programming terms, is an integer. This number is what describes the meaning of that field. For instance field 49 is the SenderCompID field, which will be more relevant later. Associated with this tag’s integer is a value which is represented as either a plain text, encoded or binary array of bytes.

As you can see there is plenty at work in the FIX world. While we have been able to handle FIX inspection, routing and manipulation for years, it required iRule intervention. As the usage of those iRules continued to increase, and new demands surrounding FIX were being laid on our users consistently, we decided to do something to help out. To do so, we’ve put together a FIX Profile that makes keying off of this data for flow routing or substitution painless and efficient.

The FIX Profile that’s now built into BIG-IP LTM allows you to use FIX protocol messages for routing, load balancing, persisting, logging and more. The FIX profile will now do all of the hard work of examining and parsing the header, body and footer of any inbound FIX messages. This is what was previously done in an iRule, which is functional, but certainly more work for the user. This is all now automated with the in-line profile. Once the profile parses the FIX data it will then make any decisions or take any actions necessary based on the requirements of your configuration.

The existence of the profile at all will make life infinitely easier for those that need to parse FIX data to route or persist. Steering, that is, the act of select pool members based on the data contained in the FIX traffic being parsed by the FIX profile, allows for general persistence and routing. The profile, however, goes above and beyond such basic functionality. A couple exciting features that are included with the FIX profile, above and beyond “This is so much easier now!” are Quick Parsing Validation, and Tag Substitution.

Quick Parsing Validation

As we covered earlier, the FIX protocol is made up of a series of tag -> value pairs of fields. These fields are used for a myriad of different things, but there are common fields that get used more often than others. If what you’re looking for is pretty basic FIX validation, meaning you want to identify that the inbound message is indeed a valid FIX message, but you’re not looking to dig into every single field, then this option is the answer you’re seeking. Quick Parsing Validation allows you to validate only a subset of potential fields, namely these (from askf5):

· The first three fields: 8 (BeginString), 9 (BodyLength), and 35 (MsgType).

· The last field.

· Field 49 (SenderCompID).

· Fields requested by an iRule tag query command.

· Fields in the message that precede the fields requested by an iRule tag query command.

This allows the BIG-IP to more rapidly and efficiently processes the FIX data to validate traffic, as it is only concerned with a small subset of fields that it can comfortably rely on to ensure the data is in fact FIX formatted. If you’re looking for details on exactly what it does to validate those fields or more information about how this works, refer to the askf5 link above.

 

Tag Substitution

Tag Substitution is a feature that is now available in the FIX Profile to allow for further customization of your FIX traffic and business logic. With Tag Substitution you are able to create a list of mappings per “Mapping List Sender”, which is effectively the SenderCompID within the FIX body. This feature allows you to define logic such as “If the SenderCompID is x, modify tag n to be y”. That is, you can define tag based substitutions for a given Mapping List Sender (SenderCompID). This is a powerful yet easy to use and manage way of transforming FIX data in flight, without having to write a single line of code.

As you can see the FIX Profile takes what was once possible and makes it not only easy and efficient, but also much improved. Both of these features represent highly desired use cases from multiple users. The Tag Substitution alone will take the place of rather complex iRules for any users looking to do per SenderCompID tag modifications, which is a growing list. It has never been easier to inspect, route, validate and transform FIX data on a BIG-IP. And now all of that can be done with minimal if any coding, thanks to this new, powerful profile. For more info on how to get your own FIX profile set up and running, check out askf5 for detailed instructions.