Unmanaged: what is the real order of these methods ?

[pstrusi]

Hi,

In order to optmize speed and reliability and avoid code issues, I need to confirm that following below is the real consequitive way when order state changes:

OnOrderUpdate ---> OnExecution -----> OnPositionUpdate ?

My objective is pretty simple: detecting when an order state changes in the fastest and reliable way possible. For that I must code in a synchronous-events logic way and that's the reason that I need where to look first.

Reading NT7 guide I left a little confused, cause it seems there're some contradictory conclusions. Let's see:

In the IOrder section:

• CRITICAL: If you want to drive your strategy logic based on order fills you must use OnExecution() instead of OnOrderUpdate(). OnExecution() is always triggered after OnOrderUpdate(). There is internal strategy logic that is triggered after OnOrderUpdate() is called but before OnExecution() that can adversely affect your strategy if you are relying on tracking fills within OnOrderUpdate().

but later it states:

If you are relying on the OnOrderUpdate() method to trigger actions such as the submission of a stop loss order when your entry order is filled ALWAYS reference the properties on the IOrder object passed into the OnOrderUpdate() method.

then for more confusion, in the section OnExecution you find this very same statement:

If you are relying on the OnExecution() method to trigger actions such as the submission of a stop loss order when your entry order is filled ALWAYS reference the properties on the IOrder object property attached to the IExecution object passed into the OnExecution() method. So, which is it for real the more reliable ?

Another point, In the example given in the guide, we have:

As an example, the NinjaTrader core may have received "Working" and then "PartFilled" order state change events back from the broker API on thread "B" and at some point in time (milliseconds later) the NinjaTrader core will take these events and trigger the OnOrderUpdate() method in the strategy on thread "A". Thus, when the strategy receives the first "Working" state for an order, the IOrder object passed in will reflect the "Working" state although the actual order is really in a state of "Part Filled" which is truly reflected in the original IOrder object returned in any of the order methods such as EnterLong(). Of course, the OnOrderUpdate() method will subsequently receive the event for "PartFilled" state.

In that example, is it not the OnOrderUpdate ALWAYS the first method to detect the new order state ?

So, which way is more reliable, checking first always in OnExecution() or OrderUpdate() method ?

I understand the asynchronous way of IB-API and I agree that there's a queue of state changes that need to be processed by NT into those methods, until all of them are not processed, it's impossible to know what is the "real latest Order State"; however I'd like to know which method will ALWAYS AND FIRST detect the latest genuine state ?

Looking forward to clear these doubts, Thanks a lot in advance

[NinjaTrader_JessicaP]

Hello pstrusi, and thank you for your question.

The short answer to your question is that you can reasonably expect these three methods to be called in the order you specified, that is,

OnOrderUpdate -> OnExecution(Update) -> OnPositionUpdate

This is because

• OnOrderUpdate details the entire conversation between the trade desk and NinjaTrader, which includes several actions before an order executes
• Executions are required to change strategy positions.

OnExecution(Update) is the most reliable place to check whether an order is filled or not, because OnOrderUpdate tracks the entire conversation with the trade desk, while OnExecution(Update) is only called once your trade order has successfully executed and the conversation between Ninja and the trade desk is completely over.

The second and third quotes you provided are unrelated to this. Instead this is letting you know to keep a local reference to your order, and to ensure the reference passed in to execution.Order is the same as the reference your strategy keeps. There are code examples in the help guide that detail how this is done. Reliability in this context has less to do with the conversation between Ninja and the trade desk, as was the case with the first quote you provided, and more to do with tracking your internal logic, to ensure (for instance) a stop loss order is not treated like an entry order.

The fourth quote you provided details a situation where both the factors I mentioned - the conversation with the trade desk, and your local code logic, creating situations that must be handled carefully - come into play. A conversation with the trade desk in which the trade desk decides to break your order into multiple partially filled orders increases the complexity of the situation your code is responding to in both ways. If you are checking for fills during OnExecution(Update) and are comparing execution.Order against known order references, however, this will ensure your code behaves properly in this instance.

Please let us know if there are any other ways we can help.