Store reference to Order (in Unmanaged mode)

[misova]

I found change in behavior, between NT7 and NT8. It is all in Unmanaged mode.

• In new NT8, when firing order, using SubmitOrderUnmanaged(...),
• then this method first invokes 3-4 times Strategy#OnOrderUpdate(...) method, before returning.
• In old NT7, submitting unmanaged order first returned, and after that, invoked OnOrderUpdate(...) method multiple times.

What is the problem:
I need to store the reference to Order first (before processing it), to be able to properly process it later and execute custom trading logic.

But I found, I cannot do this = I cannot store the reference to Order first (before this Order is processed), because SubmitOrderUnmanaged(...) does not return the Order immediately. It first calls Strategy#OnOrderUpdate(...) method multiple times and then (after some processing) returns the Order finally. So the Order is already processed multiple times, before I can store it. And this is the core of the problem.
(I get this is order of method invocations, when debugging historical backtest in VS)

I would expect, that SubmitOrderUnmanaged(...) should return the Order immediately (so I can store the reference to the Order, before its state changes) and the callbacks Strategy#OnOrderUpdate(...) should be invoked after returning the reference to Order.

Now, it is not clear, how I can store the reference (and custom contextual data about the order), before the processing of the order = before invocations of the Strategy#OnOrderUpdate(...) method.

I found in the docs, that it is good to store the reference in the OnOrderUpdate().
But this method is shared for all orders. I can't catch the order in this method, because I have lost the context, where I submitted the Order.

Example:
I can submit 2 orders: Each one will sell 1 contract at the same price. Plan is, that each contract will be managed differently from trader's point of view. (let's say, 1st contract is planned to be managed aggressively, 2nd conservatively).

So I need to store the reference for each one of these orders, to distinguish them and then handle them differently.

In point, when I am submitting each one of these 2 orders, I know which Order is which, so I can store the reference correctly into my variables.
But when you say to me: Wait until OnOrderUpdate(...) method is invoked to store your reference to your Order, then it is too late, because in this OnOrderUpdate(..) method all the context I need to distinguish between the orders is lost.

So how it is supposed to work please?
How can I store my orders into my variables first - before they are processed in OnOrderUpdate(..) method?

[misova]

Maybe I found answer for my own question. If it is correct, just confirm please, this is the right solution.

• It is true, that before SubmitOrderUnmanaged() returns the Order object, multiple invocations of OnOrderUpdate() can happen (usually for all states until OrderState.Submitted)
• This means, we can not obtain reference to Order before it is processed.
• What we can do to mark Order for special handling later is to set special signalName to the Order, and then use attribute Order#Name for distinguishing between various Orders

But I stil do not get the motivation, why you made it to work this way? Why you cannot return Order reference immediately and after that invoke all relevant OnOrderUpdate(..) callbacks on this Order? Why to mix creation of Order reference with also processing of this reference?

Could you explain please, why the concept of Order creation and next procesing are not decomposed, but merged together. Separating them would enable easy storing of Order references, before processing of the Order itself. It would make coding less complex and easier...

[misova]

After a lot of debugging, I maybe found an answer, why you made a decision to not return Order reference immediately, but call OnOrderUpdate(..) multiple times before returning...

One reason is correct handling of cancellation (or changing order):

If you would not do it, then after cancellation of Working order, it would be in invalid state (it would still have Accepted / Working state), until the OnOrderUpdate(..) would be invoked.
It is important to change state of the order to CancelPending / CancelSubmitted immediately after cancellation, to mark that order, like is is already in process of cancelation, to prevent multiple following cancellations from other places of the strategy.

If order-state would not be updated immediately after cancellation, then multiple cancellations could happen, because custom strategy could check the current order-state - and if it would be still in obsolete Accepted / Working state immediately after cancellation, then it would be completely valid to cancel it again from custom strategy point of view. Simple logic would tell: if order declares it is Accepted/Working, then it can be cancelled...
And this problem is solved by immediate updating order-state (by multiple invocations of OnOrderUpdate()), before order cancellation returns.

Completely the same principle is valid not only for cancellation of the order,
but also change of the order, to prevent multiple changes.
--

But anyway, this handling is ok for correct processing of order changes / cancellations in custom strategies, I don't see, that this handling is needed for submitting NEW orders.

Why could you not return new submitted order immediately in Initialized state, and then
later invoke all OnOrderUpdate(..) callbacks like TriggerPending / Rejected, , Submitted, Accepted, Working ?

This would make things more simple, because order-creation would not be mixed with immediate processing of the order itself, before we can store the reference to it.

For us developers, it is really important to be able to easily store the reference to new submitted Order before ANY processing of this order. If we have stored order-reference, this allows us to handle and distinguish this order in all callbacks easily by reference = without need to use Order#Name for distinguishing order, before reference is returned.

Using this Order#Name for distinguishing new order before it is returned makes coding more complex. We have to first recognize the order by Order#Name (until reference is returned) and then later, when it is returned, we recognize the order by reference.
This makes coding more complex, but this complexity is useless. I don't see any added value.

Immediate returning of NEW submitted orders would removed all this useless complexity. Think about it please.

[NinjaTrader_PatrickH]

Hello misova,

Thank you for your patience.

Form the Help Guide at the following link: http://ninjatrader.com/support/helpG...rderupdate.htm

OnOrderUpdate() will run inside of order methods such as EnterLong() or SubmitOrderUnmanaged(), therefore attempting to assign an order object outside of OnOrderUpdate() may not return as soon as expected. If your strategy is dependent on tracking the order object from the very first update, you should try to match your order objects by the order.Name (signal name) from during the OnOrderUpdate() as the order is first updated.

So if we want to assign the order object we need to do so inside of OnOrderUpdate(). If you are not doing this already and are expecting to have the order object update immediately after submitting EnterLong (for example) then it will not update in such a manner.

The change is that you now have access to the direct order object and when it is updated. NinjaTrader internal Order objects have been exposed to the NinjaScript methods and events giving direct access to order related information. So you would need to ensure to assign the order object (Order) in OnOrderUpdate() as it would not exist immediately in OnBarUpdate() after calling your desired order entry method.

In NinjaTrader 7 we had access to IOrder objects, which were really a container holding the hypothetical information of the order until it was updated in OnOrderUpdate(). In NinjaTrader 8 this was removed to allow more accurate information on the order objects.