Transport protocol for FIX

, ,
1

Imported from previous forum

2

Hi,
I am new to FIX. In the document transport mechanisms mentioned are web services HTTP, MQSeries, Multicast UDP.These transport protocols are used to connect between the FIX engine and trading platform.Is my understanding correct?
So If we have to go with web services HTTP, then can we use SOAP over HTTP protocol to connect to the engine.
Where will get the information on the technologies used in implementing/testing the FIX protocol.

Thanks,
Harish

3

When FIXProtocol was first introduced, TCP was the only Transport mechanism “between” FIX Engines, i.e SessionInitiator ↔ SessionAcceptor. With Transport Independence, any reliable transport can be used between FIX Engines.

FIX does not define the integration between FIX engine and Trading application, even before the Transport independence framework was introduced, transport mechanisms like web services HTTP, JMS / MQSeries, Multicast UDP, Tibco, Corba, JRMP, RMI etc were being used for communication between FIX engine and Trading application.

Hi, I am new to FIX. In the document transport mechanisms mentioned are
web services HTTP, MQSeries, Multicast UDP.These transport protocols are
used to connect between the FIX engine and trading platform.Is my
understanding correct? So If we have to go with web services HTTP, then
can we use SOAP over HTTP protocol to connect to the engine. Where will
get the information on the technologies used in implementing/testing the
FIX protocol.

Thanks, Harish

4

Hi Mahesh ,

Reference to below mail ,

We like to work on both sell side and buy side FIX Automated Certification Test Framework.

I am new to finiance domain .

We have couple of queries regarding Sell side and Buy side as listed below.

  1. who are all Sell side system with examples ? whether they have FIX Interface ?
  2. who are all Buy Side system with examples ? whether they have FIX interface ?

My Assumption to develop the Test Automation Framework,
It can be connected to either Sell side system or buy side system and to test the work flow and message validation is it correct ?

Please clarify

Thanks in advance.

Thanks & Regards,
Jagadeesan.M

From: Mahesh Kumaraguru [mailto:kay_mahesh@yahoo.com]
Sent: Thursday, May 20, 2010 9:22 PM
To: Harishbabu Nagaraj
Subject: FW: FIX queries

Hi Harish,

In the future I would recommend you to post your query to the FIXProtocol discussion forums at

http://fixprotocol.org/discuss/

because I check the FIX website multiple times a day (all my browsers have FIX website as home page), but I do not access emails so many times in a week and there are lot of spam / junk messages and digging thru them to find useful messages is a waste of time. Also there so many other users on the FIXProtocol.org website who could answer your question.

Take a look at the image below which shows one FIX connection

http://upload.wikimedia.org/wikipedia/en/e/ea/Fix.jpg

and explain what is running in machine A and machine B. Also remember that FIX engine would talk to a FIX engine and presently most FIX engines use TCP for FIX sessions. Are you creating a Sell side or Buy side test simulator / framework?

Regards,
K. Mahesh

— On Tue, 5/18/10, Harishbabu Nagaraj Harishbabu_Nagaraj@mindtree.com wrote:

From: Harishbabu Nagaraj Harishbabu_Nagaraj@mindtree.com
Subject: FW: FIX queries
To: “kay_mahesh@yahoo.com” kay_mahesh@yahoo.com
Date: Tuesday, May 18, 2010, 8:06 AM
Hi Mahesh,

We are planning to develop a conformance test framework to test FIX Protocol implementation. We have couple of queries regarding this
i.) Will the following setup be sufficient for this ?

  1. Desktop machine (A) running open source FIX engine (sample AUT)
  2. desktop machine (B) running our test framework
  3. A is connected back to back with B
  4. The test client we develop interacts with the FIX engine using SOAP over HTTP calls.

ii.) If we are able to validate all the xml interactions between the test client and FIX engine as per the FIX specifications, can we claim to have performed conformance testing for the FIX implementation ?

Thanks in Advance.

Thanks and Regards,
Harish

When FIXProtocol was first introduced, TCP was the only Transport
mechanism “between” FIX Engines, i.e SessionInitiator ↔
SessionAcceptor. With Transport Independence, any reliable transport can
be used between FIX Engines.

FIX does not define the integration between FIX engine and Trading
application, even before the Transport independence framework was
introduced, transport mechanisms like web services HTTP, JMS / MQSeries,
Multicast UDP, Tibco, Corba, JRMP, RMI etc were being used for
communication between FIX engine and Trading application.

Hi, I am new to FIX. In the document transport mechanisms mentioned
are web services HTTP, MQSeries, Multicast UDP.These transport
protocols are used to connect between the FIX engine and trading
platform.Is my understanding correct? So If we have to go with web
services HTTP, then can we use SOAP over HTTP protocol to connect to
the engine. Where will get the information on the technologies used in
implementing/testing the FIX protocol.

Thanks, Harish

5

Hi Jagadeesan,

The Buy Side consists of institutional investors, money managers, pension funds, mutual funds etc. who buy services from broker dealers. The sell side consists of broker dealers who sell their services to the Buy Side.

Take a look at the picture below to get an end to end Flow between BuySide <-> SellSide <-> StockExchange

but keep in mind that there would be many different brokerage firms between the Institutional investors and Liquidation sources and each of the institutional investors could be connected to multiple brokers and each broker could be connected to multiple sources of liquidity.

In FIX terms, you should see the sides as Session Initiator versus Session Acceptor since FIX is a Session based client server protocol. Session Acceptor will open a TCP socket and wait for inbound socket connections, Session Initator has to make a socket connection to the machine:port on which the acceptor is listening.

Both sides can send all types of Session / Administrative messages, but Business / Application messages have certain FIX workflows, refer Specs at http://fixprotocol.org/specifications/. You should consider this when designing your test framework.

Regards,
K. Mahesh

6

Hi ,

Thanks a lot Mahesh,

  1. Initially TCP was the only communication mode which provided for FIX Engine . Now FIX Engine become Transport independent . Is it in my Test framework I have to support all the transport mechanism which is listed in suggestion (HTTP, JMS / MQSeries, Multicast UDP, Tibco,Corba, JRMP, RMI etc). When and where these transport mechanism will be used in FIX Architecture ?

  2. If you can suggest me what transport mechanism , I can support in my FIX Automation framework , it will be very helpful to base line my Framework design

  3. There is any document which tells about how to test the buy side system ?

Thanks in advance.

Thanks & Regards,
Jagadeesan.M

Hi Jagadeesan,

The Buy Side consists of institutional investors, money managers, pension funds, mutual funds etc. who buy services from broker dealers. The sell side consists of broker dealers who sell their services to the Buy Side.

Take a look at the picture below to get an end to end Flow between BuySide ↔ SellSide ↔ StockExchange

http://www.ksvali.com/wp-content/uploads/2009/09/fix_players_1.gif

but keep in mind that there would be many different brokerage firms between the Institutional investors and Liquidation sources and each of the institutional investors could be connected to multiple brokers and each broker could be connected to multiple sources of liquidity.

In FIX terms, you should see the sides as Session Initiator versus Session Acceptor since FIX is a Session based client server protocol. Session Acceptor will open a TCP socket and wait for inbound socket connections, Session Initator has to make a socket connection to the machine:port on which the acceptor is listening.

Both sides can send all types of Session / Administrative messages, but Business / Application messages have certain FIX workflows, refer Specs at http://fixprotocol.org/specifications/. You should consider this when designing your test framework.

Regards,
K. Mahesh

7

Hi ,

To test the Session initiator ( Buy side ) whether i need to work on Session acceptor simulator or any other method to test and certify the Buy side system .

please clarify .

Thanks in advance.

Warm Regards,
Jagadeesan.M

Hi Mahesh ,

Reference to below mail ,

We like to work on both sell side and buy side FIX Automated Certification Test Framework.

I am new to finiance domain .

We have couple of queries regarding Sell side and Buy side as listed below.

  1. who are all Sell side system with examples ? whether they have FIX Interface ?
  2. who are all Buy Side system with examples ? whether they have FIX interface ?

My Assumption to develop the Test Automation Framework,
It can be connected to either Sell side system or buy side system and to test the work flow and message validation is it correct ?

Please clarify

Thanks in advance.

Thanks & Regards,
Jagadeesan.M

From: Mahesh Kumaraguru [mailto:kay_mahesh@yahoo.com]
Sent: Thursday, May 20, 2010 9:22 PM
To: Harishbabu Nagaraj
Subject: FW: FIX queries

Hi Harish,

In the future I would recommend you to post your query to the FIXProtocol discussion forums at

http://fixprotocol.org/discuss/

because I check the FIX website multiple times a day (all my browsers have FIX website as home page), but I do not access emails so many times in a week and there are lot of spam / junk messages and digging thru them to find useful messages is a waste of time. Also there so many other users on the FIXProtocol.org website who could answer your question.

Take a look at the image below which shows one FIX connection

http://upload.wikimedia.org/wikipedia/en/e/ea/Fix.jpg

and explain what is running in machine A and machine B. Also remember that FIX engine would talk to a FIX engine and presently most FIX engines use TCP for FIX sessions. Are you creating a Sell side or Buy side test simulator / framework?

Regards,
K. Mahesh

— On Tue, 5/18/10, Harishbabu Nagaraj Harishbabu_Nagaraj@mindtree.com wrote:

From: Harishbabu Nagaraj Harishbabu_Nagaraj@mindtree.com
Subject: FW: FIX queries
To: “kay_mahesh@yahoo.com” kay_mahesh@yahoo.com
Date: Tuesday, May 18, 2010, 8:06 AM
Hi Mahesh,

We are planning to develop a conformance test framework to test FIX Protocol implementation. We have couple of queries regarding this
i.) Will the following setup be sufficient for this ?

  1. Desktop machine (A) running open source FIX engine (sample AUT)
  2. desktop machine (B) running our test framework
  3. A is connected back to back with B
  4. The test client we develop interacts with the FIX engine using SOAP over HTTP calls.

ii.) If we are able to validate all the xml interactions between the test client and FIX engine as per the FIX specifications, can we claim to have performed conformance testing for the FIX implementation ?

Thanks in Advance.

Thanks and Regards,
Harish

http://www.mindtree.com/email/disclaimer.html

When FIXProtocol was first introduced, TCP was the only Transport
mechanism “between” FIX Engines, i.e SessionInitiator ↔
SessionAcceptor. With Transport Independence, any reliable transport can
be used between FIX Engines.

FIX does not define the integration between FIX engine and Trading
application, even before the Transport independence framework was
introduced, transport mechanisms like web services HTTP, JMS / MQSeries,
Multicast UDP, Tibco, Corba, JRMP, RMI etc were being used for
communication between FIX engine and Trading application.

Hi, I am new to FIX. In the document transport mechanisms mentioned
are web services HTTP, MQSeries, Multicast UDP.These transport
protocols are used to connect between the FIX engine and trading
platform.Is my understanding correct? So If we have to go with web
services HTTP, then can we use SOAP over HTTP protocol to connect to
the engine. Where will get the information on the technologies used in
implementing/testing the FIX protocol.

Thanks, Harish

8

To test a Session initiator / Buy side you would need to build a Session Acceptor / Sell side simulator.

Take a look at the architecture shown in a diagram uploaded at

http://www.4shared.com/photo/Bi5ADekd/Test_Framework_for_End_to_End_.html

There are 5 parts in the diagram

  1. Your Test frame work
  2. Your Test framework’s Session Acceptor
  3. Buy side FIXEngine
  4. Buy side Trading application
  5. Buy side database

Just for the sake of this discussion, lets say there is a table in the Buy Side database called ExecReports which has the following columns

ExecID
BrokerCompID
ExecTransType
ExecType
LastQty
LastPx

Unique key of this database table is ExecID+BrokerCompID

Also I assume that there is a manual tester on the Trading application. Your test framework is running as Automated functional tester

Now lets look at a test sequence

  1. Bring up your test framework & test framework’s Session acceptor
  2. Session Acceptor starts listening on machine:port
  3. Bring up Buy side DB, Buy Side Trading application & Buy side FIX engine.
  4. Session initiator initiates session to machine:port and Session is successfully established
  5. Buy side tester sends a New Order single with 55=MAX
  6. Order reaches Test Framework. Test framework matches this order with full fill test case using
    If(TickerSymbol==“IBM”)
    {
    sendFullFill(nos);
    }
  7. Testframe work send the execution report thru its FIX engine to the buy side FIX engine.
  8. The Order is shown as filled in Trading application and the manual tester on the buy side trading application marks the test as passed in his test report.
  9. The execution details are inserted into the ExecReports table of Buy side database
  10. Test framework keeps polling the database until it finds the execution it sent in step 7 using ExecID+BrokerCompID. It verifies that values in DB match values sent in step 7.
  11. Full Fill test is marked as pass in your test framework’stest report.

This is a simple example. You could add verification point at Buy side FIX engine log, Buy side trading application log, automate Buy side trading application’s GUI testing using QTP etc.

9

Hi Mahesh,

really this info help me to go ahead.

it is possible for u to share sell side as well.

Thanks in advance

Warm Regards,
Jagadeesan.M

To test a Session initiator / Buy side you would need to build a Session Acceptor / Sell side simulator.

Take a look at the architecture shown in a diagram uploaded at

http://www.4shared.com/photo/Bi5ADekd/Test_Framework_for_End_to_End_.html

There are 5 parts in the diagram

  1. Your Test frame work
  2. Your Test framework’s Session Acceptor
  3. Buy side FIXEngine
  4. Buy side Trading application
  5. Buy side database

Just for the sake of this discussion, lets say there is a table in the Buy Side database called ExecReports which has the following columns

ExecID
BrokerCompID
ExecTransType
ExecType
LastQty
LastPx

Unique key of this database table is ExecID+BrokerCompID

Also I assume that there is a manual tester on the Trading application. Your test framework is running as Automated functional tester

Now lets look at a test sequence

  1. Bring up your test framework & test framework’s Session acceptor
  2. Session Acceptor starts listening on machine:port
  3. Bring up Buy side DB, Buy Side Trading application & Buy side FIX engine.
  4. Session initiator initiates session to machine:port and Session is successfully established
  5. Buy side tester sends a New Order single with 55=MAX
  6. Order reaches Test Framework. Test framework matches this order with full fill test case using
    If(TickerSymbol==“IBM”)
    {
    sendFullFill(nos);
    }
  7. Testframe work send the execution report thru its FIX engine to the buy side FIX engine.
  8. The Order is shown as filled in Trading application and the manual tester on the buy side trading application marks the test as passed in his test report.
  9. The execution details are inserted into the ExecReports table of Buy side database
  10. Test framework keeps polling the database until it finds the execution it sent in step 7 using ExecID+BrokerCompID. It verifies that values in DB match values sent in step 7.
  11. Full Fill test is marked as pass in your test framework’stest report.

This is a simple example. You could add verification point at Buy side FIX engine log, Buy side trading application log, automate Buy side trading application’s GUI testing using QTP etc.

10

Refer diagram at

http://www.4shared.com/photo/waj16rFA/Test_Framework_for_End_to_End_.html

Parts are :-

  1. Your Test frame work
  2. Your Test framework’s Session Initiator
  3. Sell side FIXEngine
  4. Sell side Trading application
  5. Sell side database

Just for the sake of this discussion, lets say there is a table in the Sell Side database called NewOrders which has the following columns

OrderID
ClOrdID
ClientCompID
OrderType
OrderTIF
OrderQty
LimitPx
StopPx

Unique Primary key of this database table is OrderID.

Unique key is ClOrdID + ClientCompID

Also I assume that there is a manual tester on the sell side Trading application. Your test framework is running as Automated functional tester

Now lets look at a test sequence

  1. Bring up Sell side DB, Sell Side Trading application & Sell side FIX engine.
  2. Sell side FIX Engine starts listening on machine:port
  3. Bring up your test framework & test framework’s Session intiator
  4. Session initiator initiates session to machine:port and Session is successfully established
  5. Test framework sends a New Order single with 55=RMD
  6. Order reaches Sell side Trading application.
  7. The Order is displayed in Trading application and the manual tester on the sell side trading application checks the values in Sell side trading application matches values of order from step 5 and marks the test as passed in his test report.
  8. The order details are inserted into the NewOrders table of Sell side database.
  9. Test framework keeps polling the database until it finds the order it sent in step 5 using ClOrdID+ClientCompID. It verifies that values in DB match values sent in step 5.
  10. Send New Order test is marked as pass in your test framework’stest report.

Hi Mahesh,

really this info help me to go ahead.

it is possible for u to share sell side as well.

Thanks in advance

Warm Regards,
Jagadeesan.M

11

Corrected diagram is located at

http://www.4shared.com/photo/FM8aCoYI/Test_Framework_for_End_to_End_.html

Refer diagram at

http://www.4shared.com/photo/waj16rFA/Test_Framework_for_End_to_End_.html

Parts are :-

  1. Your Test frame work
  2. Your Test framework’s Session Initiator
  3. Sell side FIXEngine
  4. Sell side Trading application
  5. Sell side database

Just for the sake of this discussion, lets say there is a table in the Sell Side database called NewOrders which has the following columns

OrderID
ClOrdID
ClientCompID
OrderType
OrderTIF
OrderQty
LimitPx
StopPx

Unique Primary key of this database table is OrderID.

Unique key is ClOrdID + ClientCompID

Also I assume that there is a manual tester on the sell side Trading application. Your test framework is running as Automated functional tester

Now lets look at a test sequence

  1. Bring up Sell side DB, Sell Side Trading application & Sell side FIX engine.
  2. Sell side FIX Engine starts listening on machine:port
  3. Bring up your test framework & test framework’s Session intiator
  4. Session initiator initiates session to machine:port and Session is successfully established
  5. Test framework sends a New Order single with 55=RMD
  6. Order reaches Sell side Trading application.
  7. The Order is displayed in Trading application and the manual tester on the sell side trading application checks the values in Sell side trading application matches values of order from step 5 and marks the test as passed in his test report.
  8. The order details are inserted into the NewOrders table of Sell side database.
  9. Test framework keeps polling the database until it finds the order it sent in step 5 using ClOrdID+ClientCompID. It verifies that values in DB match values sent in step 5.
  10. Send New Order test is marked as pass in your test framework’stest report.

Hi Mahesh,

really this info help me to go ahead.

it is possible for u to share sell side as well.

Thanks in advance

Warm Regards,
Jagadeesan.M

12

Step 6 (Match rule) should be

If(TickerSymbol=="MAX")
{
     sendFullFill(nos);
}

To test a Session initiator / Buy side you would need to build a Session Acceptor / Sell side simulator.

Take a look at the architecture shown in a diagram uploaded at

http://www.4shared.com/photo/Bi5ADekd/Test_Framework_for_End_to_End_.html

There are 5 parts in the diagram

  1. Your Test frame work
  2. Your Test framework’s Session Acceptor
  3. Buy side FIXEngine
  4. Buy side Trading application
  5. Buy side database

Just for the sake of this discussion, lets say there is a table in the Buy Side database called ExecReports which has the following columns

ExecID
BrokerCompID
ExecTransType
ExecType
LastQty
LastPx

Unique key of this database table is ExecID+BrokerCompID

Also I assume that there is a manual tester on the Trading application. Your test framework is running as Automated functional tester

Now lets look at a test sequence

  1. Bring up your test framework & test framework’s Session acceptor
  2. Session Acceptor starts listening on machine:port
  3. Bring up Buy side DB, Buy Side Trading application & Buy side FIX engine.
  4. Session initiator initiates session to machine:port and Session is successfully established
  5. Buy side tester sends a New Order single with 55=MAX
  6. Order reaches Test Framework. Test framework matches this order with full fill test case using
    If(TickerSymbol==“IBM”)
    {
    sendFullFill(nos);
    }
  7. Testframe work send the execution report thru its FIX engine to the buy side FIX engine.
  8. The Order is shown as filled in Trading application and the manual tester on the buy side trading application marks the test as passed in his test report.
  9. The execution details are inserted into the ExecReports table of Buy side database
  10. Test framework keeps polling the database until it finds the execution it sent in step 7 using ExecID+BrokerCompID. It verifies that values in DB match values sent in step 7.
  11. Full Fill test is marked as pass in your test framework’stest report.

This is a simple example. You could add verification point at Buy side FIX engine log, Buy side trading application log, automate Buy side trading application’s GUI testing using QTP etc.

13

Thanks a lot mahesh.

Step 6 (Match rule) should be

If(TickerSymbol=="MAX")
{
     sendFullFill(nos);
}

To test a Session initiator / Buy side you would need to build a Session Acceptor / Sell side simulator.

Take a look at the architecture shown in a diagram uploaded at

http://www.4shared.com/photo/Bi5ADekd/Test_Framework_for_End_to_End_.html

There are 5 parts in the diagram

  1. Your Test frame work
  2. Your Test framework’s Session Acceptor
  3. Buy side FIXEngine
  4. Buy side Trading application
  5. Buy side database

Just for the sake of this discussion, lets say there is a table in the Buy Side database called ExecReports which has the following columns

ExecID
BrokerCompID
ExecTransType
ExecType
LastQty
LastPx

Unique key of this database table is ExecID+BrokerCompID

Also I assume that there is a manual tester on the Trading application. Your test framework is running as Automated functional tester

Now lets look at a test sequence

  1. Bring up your test framework & test framework’s Session acceptor
  2. Session Acceptor starts listening on machine:port
  3. Bring up Buy side DB, Buy Side Trading application & Buy side FIX engine.
  4. Session initiator initiates session to machine:port and Session is successfully established
  5. Buy side tester sends a New Order single with 55=MAX
  6. Order reaches Test Framework. Test framework matches this order with full fill test case using
    If(TickerSymbol==“IBM”)
    {
    sendFullFill(nos);
    }
  7. Testframe work send the execution report thru its FIX engine to the buy side FIX engine.
  8. The Order is shown as filled in Trading application and the manual tester on the buy side trading application marks the test as passed in his test report.
  9. The execution details are inserted into the ExecReports table of Buy side database
  10. Test framework keeps polling the database until it finds the execution it sent in step 7 using ExecID+BrokerCompID. It verifies that values in DB match values sent in step 7.
  11. Full Fill test is marked as pass in your test framework’stest report.

This is a simple example. You could add verification point at Buy side FIX engine log, Buy side trading application log, automate Buy side trading application’s GUI testing using QTP etc.

14

Thank for the information .its very helpful for me dapfor.com