Quickfix version adapter

1

Hi,

We have an Initiator (Party A) that would like to send messages (New orders, cancellations, etc) to an Exchange/Acceptor (Party B). Likewise, the Exchange will send back responses in the form of Execution Reports, etc.

Party A only supports FIX42 and is unwilling to change, and Party B only supports FIX50SP2 and is unwilling to make changes to their system to accept FIX42. We’ve verified that minor modifications can be made to the messages in both directions to make the two compatible, so we are going to build an adapter in the middle to add compatibility.

We are considering the following options for our “adapter”:

(A) Act like a “Man in the Middle” stateless proxy: Intercept FIX42 messages off a tcp socket (probably using MINA), convert and modify some fields to be a FIX50SP2 message, then and forward to the tcp socket of the Exchange. The same on the way back. This solution lets us avoid managing any FIX application state. How easy/difficult would this be? Can you foresee any issues doing this? Or do you know any existing software the does this already?

(B) Create a more stateful adapter with 2 QuickFix instances. Create an Acceptor where PartyA using FIX42 connects, and create an Initiator to connect to the FIX50SP2 Exchange. The Acceptor will pass messages to a converter who will map from FIX42 to FIX50SP2, and then send to the Exchange, and the same for messages going the other way. Can you see any issues in using this approach?

© Use anything else you may know of, like a proxy, adapter or something to convert messages back and forth as explained before.

Any help or ideas will be much appreciated.

Thanks

2

Hi
I can not Compiler the Project , The Compiler don’t know what it Initiator , I have some error in Parser ,The Project it’s not ready to Run.
Thanks
Dimitry

3

Does Party A support repeating groups in FIX 4.2? Does Party B use repeating groups in FIX 5.0 SP2?

Even if the answer to both questions is “no” then I do not think you can get away with “minor” modifications long term. Repeating groups can be a stumbling block for adapters and the exchange may use them in the future. There are other pitfalls, e.g. if Party B optimizes the workflows by reducing message verbosity (see https://www.fixtrading.org/packages/ep188/). You would then not have a 1:1 mapping on the message level.

I would strongly advise against option A, i.e. to attempt a stateless adapter on a technical level (TCP socket). “Man in the Middle” also has a negative connotation :wink: . The mapping between versions of the FIX application layer is rather a business level mapping. You will have a hard time emulating a FIX 4.2 or FIX 5.0 SP2 engine to each of the sides respectively. Party A apparently has no business case to move to FIX Latest and thereby obtain access to the services offered by the exchange. I doubt it will be any cheaper to build option B with a second FIX engine connecting to the exchange and a bridge to the existing FIX 4.2 engine. Latency must also be a non-issue for Party A to see value in option B.

On the other hand, you could probably make a commercial product out of such a bridge :slight_smile: !

4

Thanks for your response Hanno. It’s been really useful.

Regards,
Ed

1 Like