Order.OrderId changes, but what about Execution.OrderId?

[Glefdar]

I was reading this thread: https://forum.ninjatrader.com/forum/...tay-persistent

The context of my question is that I am using an ATI workaround for getting a trackable order ID into my C# application by outputting the order ID from NT8 to CSV, and then reading the CSV file with my application. When I do this, I am using OnExecutionUpdate to grab "Execution.OrderId" and "Execution.ExecutionId".

They appear to be the same number but ExecutionId has a suffixed integer after an underscore (e.g. "123456_1") and I am assuming that if two execution events such as from partial fills were to occur, the suffixed integer would increment to _2, etc.

I can see that the OrderId generated in the ATI changes after execution to become the OrderId that shows in the Orders tab of Ninjatrader desktop, and the CSV output of Execution.OrderId matches what I see in the Orders tab of Ninjatrader desktop.

Although the documentation says OrderId can change / is not persistent, is that only talking about the change that it undergoes up until the execution? I.e., is it the case that Order.OrderId can change but Execution.OrderId (and Execution.ExecutionId) will not ever change for that order once the order has executed? I just need to confirm this point. It makes sense to me but it's already so insane that we aren't provided an easy way to track orders by ID that I don't want to take it for granted that Execution.OrderId won't change (in which case, if it won't change, that order identification string could be used with ATI functions such as Filled(), etc.).

I would be very grateful if anyone can clarify this point for me definitively.

[NinjaTrader_Jesse]

Hello Glefdar,

Because the broker supplies the order ID which may change that is not the suggested way to try and track orders when using the ATI. Your external application in that use case would need to generate unique order ids which it holds on to and supplies with the order command, that is the id it will use for tracking. You don't need to export data as a csv to track the orders, your application would generate any unique string and store that after submitting the order. That unique string is attached to the order so the ATI knows what order you are referring to when using that ID.

[Glefdar]

Hello Glefdar,

Because the broker supplies the order ID which may change that is not the suggested way to try and track orders when using the ATI. Your external application in that use case would need to generate unique order ids which it holds on to and supplies with the order command, that is the id it will use for tracking. You don't need to export data as a csv to track the orders, your application would generate any unique string and store that after submitting the order. That unique string is attached to the order so the ATI knows what order you are referring to when using that ID.

Jesse,

Thank you for replying. The issue that I am having is that if I submit the order via ATI with the temporary ID created by the NewOrder function, then the order ID changes after execution on NinjaTrader's side, so I have no way to actually manage that order in the ATI-connected application (such as checking fill status, or canceling the order), because I need the broker-generated order ID as the orderID parameter to use those ATI functions but the ATI functions for retrieving the orderID only give me the temporary ID! I understand that the OrderID changes (I see it change between submitting it from ATI and then the order being processed and executed on the broker's end) but the important point for my use case is whether it changes *after* execution. If it does not change after execution then that means Execution.OrderId is indeed going to be a stable or persistent value. I suppose that one simple way to track this is to export a CSV from the Orders tab of the Ninjatrader desktop app; then a day later, export the Order tab again and check if the order IDs are identical (I suspect that they will be).

Edit: I just realized that Execution.OrderId only generates when an order fills so it provides no way of tracking an unfilled order (duh) even if it is persistent. So I guess it's not a good workaround.

[NinjaTrader_Jesse]

Hello Glefdar,

You do still have a way to manage it, in your external application lets say you make an id called "ID01" and submit that with the PLACE command in the ATI. In your PLACE command string you supply ID01. Later when you need to know about that order you would use ID01 and ignore any of the other ID's in the platform.

PLACE COMMAND

PLACE;<ACCOUNT>;<INSTRUMENT>;<ACTION>;<QTY>;<ORDER TYPE>;[LIMIT PRICE];[STOP PRICE];<TIF>;[OCO ID];[ORDER ID];[STRATEGY];[STRATEGY ID]

The ATI is not designed to use the information that you see inside the platform, the ATI is just a simple service which allows something to submit orders and manage orders externally. This is also designed to be running all the time so you would need to keep both NinjaTrader and your application running for the lifetime of the orders to be able to track it. If possible I would suggest avoiding the ATI and to instead build your script in NinjaScript so you can make use of the platforms standard features and events.