Quite recently we had a customer come to us with a question regarding the Execution events received on the API. The question was: "How do a I recognise the last execution event for a given order event?" This is a little bit tricky in the Java API as it does not behaviour exactly the same way that FIX does. E.g. If an individual order with a quantity of 30 aggressively matches multiple price points (quantity of 10 at each) on the exchange, a fix user would expect would expect:
MsgType(35)=8, ExecType(150)=New(0), CumQty(14)=0 MsgType(35)=8, ExecType(150)=Trade(F), CumQty(14)=10 MsgType(35)=8, ExecType(150)=Trade(F), CumQty(14)=20 MsgType(35)=8, ExecType(150)=Trade(F), CumQty(14)=30
As our API is based upon our XML protocol the information that we can return on the API is restricted to what we receive in those events. For a similar scenario over our XML protocol only emits a single order event at the end of the matching cycle, therefore the data output would be:
So the Java API does not have the information about the individual filled quantities as a result of each execution only the final state of the order. This can make it a little tricky to find which execution event represents the end of the matching cycle. The information seen by a user of the Java API for the same scenario would be:
getQuantity() = 10, getOrder.getFilledQuantity() = 30 getQuantity() = 10, getOrder.getFilledQuantity() = 30 getQuantity() = 10, getOrder.getFilledQuantity() = 30
However, it is possible to use some of the additional events that are available on the Java API to derive the same behaviour. By listening to both Execution and Order events we can track the cumulative quantities as we go. It does require a little bit more state management by the client, but the logic is fairly straight forward.
