GetRealtimeOrder() on Playback

[webus]

Hi,

I'm using "IsUnmanaged = true" and change Limit order using 'ChangeOrder()' feature.

The example from the link below does not work in Playback - Historical connection. I still see the error "XXX has been disabled because it attempted to modify a historical order that has transitioned to a live order. Please see the help guide for more information on transitioning order references from historical to live."

The problem: OnOrderTrace() and OnOrderUpdate() are not triggered when the Strategy's state changes from State.Historical to State.Realtime. So, there is no sence in using OnOrderUpdate() for the order's transition.

https://ninjatrader.com/support/helpGuides/nt8/NT%20HelpGuide%20English.html?getrealtimeorder.htm

Please take a look at the video from my side. I've creataed a Strategy based on the example from the NT8 guide. Your can find it in the attachements. It does not work also:

[NinjaTrader_Jesse]

Hello webus,

Please try the sample from the following link. That is a managed approach strategy, please try that in the same use case first and check that it works as expected. If so you can convert this to unmanaged by setting the bool to true and then modifying the order submission methods to use SubmitOrderUnmanaged, the other order handling code should be able to remain the same to confirm if that also works in the same use case while using unmanaged.

https://ninjatrader.com/support/helpGuides/nt8/using_onorderupdate_and_onexec.htm

[webus]

Hi

Hello webus,

Please try the sample from the following link. That is a managed approach strategy, please try that in the same use case first and check that it works as expected. If so you can convert this to unmanaged by setting the bool to true and then modifying the order submission methods to use SubmitOrderUnmanaged, the other order handling code should be able to remain the same to confirm if that also works in the same use case while using unmanaged.

https://ninjatrader.com/support/helpGuides/nt8/using_onorderupdate_and_onexec.htm

But what is wrong in my example? Based on the guide - 'This method only needs to be called once per order object, and should be done in OnOrderUpdate to handle all scenarios.' In your example the 'GetRealtimeOrder()' is called in 'OnStateChange()'

[webus]

Hi NinjaTrader_Jesse,

Hello webus,

Please try the sample from the following link. That is a managed approach strategy, please try that in the same use case first and check that it works as expected. If so you can convert this to unmanaged by setting the bool to true and then modifying the order submission methods to use SubmitOrderUnmanaged, the other order handling code should be able to remain the same to confirm if that also works in the same use case while using unmanaged.

https://ninjatrader.com/support/helpGuides/nt8/using_onorderupdate_and_onexec.htm

Wow. I would say that this example is potentially dangerous. You are suggesting to transite virtual TakeProfit and StopLoss orders into REALTIME orders. What if the entry order is opened in Histrorical Filling process, and the current position is virtual? In this case there is no real position on the Account, but it will be two REAL pending orders. But they must be virtual orders, if the entry position is virtual.

I did not test the example, but as far as I see - I'm right.


p.s.:
the entry order in this example is a Market order. I will change it to a Limit and modify it on each new bar.

[NinjaTrader_Jesse]

Hello webus,

The targets in that sample are only submitted if the entry is filled which would mean that happened in either historical or realtime, if the entry was a type of order that could still be active during the transition it would have been transitioned.

Please try the sample before trying to visually debug the code, the reason I suggested that is because it is different from your sample. If you want you can modify the orders to match what you are trying to use but it would be suggested to just make sure that does not encounter the same problem to start.

[webus]

Hi NinjaTrader_Jesse,

Hello webus,

The targets in that sample are only submitted if the entry is filled which would mean that happened in either historical or realtime, if the entry was a type of order that could still be active during the transition it would have been transitioned.

Yes, but let's imagine that the entry si filled in historical. In this case, the targets are submitted in historical also. Let's assume that the targets are not triggered in histrorical and State.Realtime accurs. In this case, the Strategy will transite targets into realtime orders, is this correct? But the current position is virtual (opened in State.Histrorical).

Hello webus,

Please try the sample before trying to visually debug the code, the reason I suggested that is because it is different from your sample. If you want you can modify the orders to match what you are trying to use but it would be suggested to just make sure that does not encounter the same problem to start.

I've tried this example, but changed the Market order into Limit order. The problem with entry order is fixed. But targets get lost - after 'GetRealtimeOrder' they becomes 'null':

the code:

            else if (State == State.Realtime)
            {
                // one time only, as we transition from historical
                // convert any old historical order object references
                // to the new live order submitted to the real-time account
                
                Print(
                        "OnStateChange:1:"+
                        (stopOrder == null ? " null order " : stopOrder.ToString())
                        );
                
                if (entryOrder != null)
                    entryOrder = GetRealtimeOrder(entryOrder);
                if (stopOrder != null)
                    stopOrder = GetRealtimeOrder(stopOrder);
                if (targetOrder != null)
                    targetOrder = GetRealtimeOrder(targetOrder);
                
                Print(
                        "OnStateChange:2:"+
                        (stopOrder == null ? " null order " : stopOrder.ToString())
                        );
            }
​

the log:

OnStateChange:1:orderId='NT-00001-1582' account='Playback101' name='MyStop' orderState=Working instrument='NQ MAR24' orderAction=Sell orderType='Stop Market' limitPrice=0 stopPrice=17999.5 quantity=1 tif=Gtc oco='' filled=0 averageFillPrice=0 onBehalfOf='' id=-1 time='2024-02-12 01:22:00' gtd='2099-12-01' statementDate='2024-06-19'
OnStateChange:2: null order  ​ 

[NinjaTrader_Jesse]

Hello webus,

While I won't be able to go through hypothetical situations with you we can work on your original question. Do you see the same problem when using GetRealtimeOrder in the way the sample uses it or is the error message not happening?

In what you provided you don't have the print inside the if statement where GetRealtimeOrder is called, the order could have just been null before that point, that print does not help to see that the transition actually happened. To see the transition happen you would have to add a body to that if statement and add a print inside the if body before GetRealtimeOrder to confirm a valid order was seen before being transitioned and then also after that method to print out if the order variable is now null if that is what you think is happening.

[webus]

Hello webus,

In what you provided you don't have the print inside the if statement where GetRealtimeOrder is called, the order could have just been null before that point, that print does not help to see that the transition actually happened. To see the transition happen you would have to add a body to that if statement and add a print inside the if body before GetRealtimeOrder to confirm a valid order was seen before being transitioned and then also after that method to print out if the order variable is now null if that is what you think is happening.

I believe I did the same, you can see 'OnStateChange:1:' before 'GetRealtimeOrder()' and 'OnStateChange:2:' after. But ok, please take a look at the new code and result:

the code:

            else if (State == State.Realtime)
            {
                // one time only, as we transition from historical
                // convert any old historical order object references
                // to the new live order submitted to the real-time account
                
                if (entryOrder != null)
                    entryOrder = GetRealtimeOrder(entryOrder);
                if (stopOrder != null){
                    
                    //the log before
                    Print(
                            "OnStateChange:1:"+
                            (stopOrder == null ? " null order " : stopOrder.ToString())
                            );
                    
                    stopOrder = GetRealtimeOrder(stopOrder);
                    
                    //the log after
                    Print(
                            "OnStateChange:2:"+
                            (stopOrder == null ? " null order " : stopOrder.ToString())
                            );
                    
                }
                if (targetOrder != null)
                    targetOrder = GetRealtimeOrder(targetOrder);
            }
​

the log:

OnStateChange:1:orderId='NT-00001-779' account='Playback101' name='MyStop' orderState=Working instrument='NQ MAR24' orderAction=Sell orderType='Stop Market' limitPrice=0 stopPrice=17999.5 quantity=1 tif=Gtc oco='' filled=0 averageFillPrice=0 onBehalfOf='' id=-1 time='2024-02-12 01:22:00' gtd='2099-12-01' statementDate='2024-06-19'
OnStateChange:2: null order  ​ 

[NinjaTrader_Jesse]

Hello webus,

That likely is related to the start behavior set which is wait until flat. The targets are transitioned into null orders in that case because the strategy is waiting until flat to become active in realtime. If you were to use ImmediatelySubmitSyncronizeAccount you should see that the order is transitioned into a realtime order.

[webus]

Hello webus,

That likely is related to the start behavior set which is wait until flat. The targets are transitioned into null orders in that case because the strategy is waiting until flat to become active in realtime. If you were to use ImmediatelySubmitSyncronizeAccount you should see that the order is transitioned into a realtime order.

It seems that when I specify 'StartBehavior = StartBehavior.ImmediatelySubmitSynchronizeAccount; ' - the issue is fixed. I will test it more. Is this a 100% solution?


As a new example, my entry order was lost in the same way (the 'StartBehavior = StartBehavior.WaitUntilFlat', it seems that 'ImmediatelySubmitSynchronizeAccount' solve the problem):

12.02.2024 6:59:52 (GetRealtimeOrder_CTrade:2242) (GetRealtimeOrder_CTradeHandler:1637),  | e1: orderId='NT-00016-1223' account='Playback101' name='Long#3#3' orderState=Working instrument='NQ MAR24' orderAction=Buy orderType='Limit' limitPrice=18012.9714744291 stopPrice=0 quantity=1 tif=Gtc oco='' filled=0 averageFillPrice=0 onBehalfOf='' id=-1 time='2024-02-12 06:56:46' gtd='2099-12-01' statementDate='2024-06-19'
12.02.2024 6:59:52 (GetRealtimeOrder_CTrade:2252) (GetRealtimeOrder_CTradeHandler:1637),  | e1:  | null |
​ 

As you can see - the order is 'null' after GetReatimeOrder(). However, I see it in the list, but I cannot manage it after the order is lost in the code:

[webus]

It seems that when I specify 'StartBehavior = StartBehavior.ImmediatelySubmitSynchronizeAccount; ' - the issue is fixed. I will test it more. Is this a 100% solution?


As a new example, my entry order was lost in the same way (the 'StartBehavior = StartBehavior.WaitUntilFlat', it seems that 'ImmediatelySubmitSynchronizeAccount' solve the problem):

12.02.2024 6:59:52 (GetRealtimeOrder_CTrade:2242) (GetRealtimeOrder_CTradeHandler:1637), | e1: orderId='NT-00016-1223' account='Playback101' name='Long#3#3' orderState=Working instrument='NQ MAR24' orderAction=Buy orderType='Limit' limitPrice=18012.9714744291 stopPrice=0 quantity=1 tif=Gtc oco='' filled=0 averageFillPrice=0 onBehalfOf='' id=-1 time='2024-02-12 06:56:46' gtd='2099-12-01' statementDate='2024-06-19'
12.02.2024 6:59:52 (GetRealtimeOrder_CTrade:2252) (GetRealtimeOrder_CTradeHandler:1637), | e1: | null |
​ 

As you can see - the order is 'null' after GetReatimeOrder(). However, I see it in the list, but I cannot manage it after the order is lost in the code:

No, it does not work for me. In this case I see this error when I tried to cancel HISTORICAL TakeProfit level. Again, I do not need to transite the historical TakeProfit level if the position is virtual. I did not apply GetRealtimeOrder() for the TakeProfit order (because I do not need a real take profit order, if my current position is virtual):

(OnOrderTrace:544) State:Realtime, timestamp: 12.02.2024 8:07:20, Cancelled custom managed order: orderId='NT-00017-1241' account='Playback101' name='Long#3#2#TakeProfit' orderState=Working instrument='NQ MAR24' orderAction=Sell orderType='Limit' limitPrice=18023 stopPrice=0 quantity=1 tif=Gtc oco='052ae8e2ce7a42d6a48536403801c55e' filled=0 averageFillPrice=0 onBehalfOf='' id=-1 time='2024-02-12 06:56:46' gtd='2099-12-01' statementDate='2024-06-19'
Strategy 'XXX/329729121' has been disabled because it attempted to modify a historical order that has transitioned to a live order. Please see the help guide for more information on transitioning order references from historical to live.
Disabling NinjaScript strategy​ XXX 

[NinjaTrader_Jesse]

Hello webus,

If a strategy is waiting until flat it is in an in-between state between historical and realtime waiting for the historical position to be closed, no orders would be transitioned into realtime orders in that use case because they fill have to fill virtually before the strategy gets into realtime. GetRealtimeOrder is only used for historical order variables that will also be a realtime order, the only situations where that would happen would be when using a start behavior that allows for orders to be resumed into existing realtime orders or when using a start behavior that submits the order as a live order.

When using wait until flat you shouldn't need to use GetRealtimeOrder at all because you shouldn't have a situation where a position is open for an order to target. If you are submitting entries that do not fill you should likely be using a different start behavior so the order can be transitioned to a realtime order and also submitted to the account as a live order.

I would suggest reading the description of each of the start behaviors to make sure that matches your trading goal, I only suggested ImmediatelySubmitSynchronizeAccount beecause that submits the order as a live order on the account for the purpose of demonstrating the transition.

https://ninjatrader.com/support/help..._positions.htm

[NinjaTrader_Jesse]

Hello webus,

I am not able to see that problem with the sample that I linked, changing the start behavior so orders can be live in realtime and when a target remains active during the transition it gets transitioned to realtime and the strategy stays enabled. If you made any changes to the script that may be the reason you are seeing an error.