Robustness of Implementation

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

Robustness of Implementation

mambadas
Hi,

I am newbie learning FIX and developing the FIX application for the first time...

I am trying to integrate order management system using SQL with C++ based quick fix. My Orders are generated/populated into SQL server data base on timely fashion and now
I am trying to figure out the better ways to update populated orders in database once they are STAGED  properly. I am implementing logic this way ....

Once a new Order is populated to database then Send the Msg Type = "D".

In the Ack back from broker in Execution Report, if OrdStatus is '0' then set an update of order status in database based on ClOrdID.
In the Ack back from broker in Execution Report, if OrdStatus is '1' then capture the partial fills to database.
In the Ack back from broker in Execution Report, if OrdStatus is '2' then Order is filled completely send the Allocation Recaps to broker via Msg Type '8'.
In the Ack back from broker in Execution Report, if OrdStatus is 'Rejected' then Order is pushed to Rejected Table in database.
In the Ack back from broker in Execution Report, if OrdStatus is 'Cancel/Replace' then Order is pushed to Cancel/ Replace table in database.

All these Ack's are captured in onMessage(Execution Report, session) event function.

In case of, possDup issue I am not resending the order to the broker, by sending DoNotSend() in the toApp().

Since I am sending only Msg Type "D" to STAGE Order and Msg Type "8" to send the trade recap allocation back to broker after complete execution of an Order. We may cancel or replace the STAGED order on discretionary basis by a Trader (NOT by sending the FIX Message). So I am listening for Acks from broker in Execution Reports based on OrdStatus rather than using "onMessage(const FIX42::OrderCancelReject&, const FIX::SessionID& ) {}" function.

My question is, Is my system robust enough ? Am I approaching the right direction of capturing all the events like fills, cancel/replace/ reject via Execution Reports just based on OrdStatus ? Is it good way to capture events via Acks in Execution Reports or Do I need to use onMessage() for both cancel replace and reject even though I am not sending any message via FIX for order cancel/replace.
 
Any suggestion or information on implementation is highly appreciated.

Thanks,
mambadas.