OrderId Unreliable / needs real dev fixes for it / whinging re Ninjascript issues

[firefoxforum12]

Docs state this about OrderID:



So basically when an order gets fired on broker this ID is probably going to change, allowing the Ninjascript developer no way to find that order again without annoying trickery?

Is this correct?

There is the undocumented Order.clientId field. Would this be the way forward? Otherwise how can one really do it?

You have this method: string[] entryOrder = GetAtmStrategyEntryOrderStatus("orderId");

Growing stack of phantom orders that will seem to be here for eternity from every time I call that function and its friends above, without OnBarUpdate passing (again ridiculous logic). It literally freeze NinjaTrader half the time. It doesnt care about my Try { } Catch {Exception e}

These GetAtm* methods are the most dangerous / badly coded functions in NinjaTrader seriously. Please escalate to dev team to fix.


I tried waiting a few seconds after calling atm create function first, still crashes ninjatrader / causes general quirks


I am nearing the end of working out work-around after work-around of Ninjascript but it has been legitimately painful experience coding for NinjaTrader.

My work around for not bricking things by avoiding calls like GetAtmStrategyEntryOrderStatus() is by looping Account.orders and looking for the original atm entry ID generated in my code, and cancel that one if it still exists (hasn't yet been replaced by server side ID that there is no connection via another property for developers [that is a major headache] if it is in state "Working".

Why should I the dev, need to do this? Etc etc.

Really dubious that I Have to do all this to avoid API bugs. Please forward to the team to deal with. Scalpers aren't waiting for OnBarUpdate(). The examples in the docs are not that useful.

I don't think these are huge missions to resolve. They are what should of been fixed in 2022.



One final thing, AtmStrategyCancelEntryOrder(orderId) accepts an order ID of the atm you created. Great.

Whats not great is Account.orders by the time I call this, this order has a server side ID and I have no solid means to identify that Entry order created via the ATM Create method vs what is now live on the server. Seems pretty basic to provide this data to developers otherwise how can they know for certain what order locally is now the one sitting on the broker. I.e. Your local Order ID in NinjaTrader "ABC" is now the Live order on server with ID "123". Order.BrokerId or something (doesn't exist). Or give undocumented Order.ClientId a purpose instead of always returning -1.

Also there is no real differentiation in the docs to suggest this limitation that local orderID gets blown away and why/how AtmStrategyCancelEntryOrder(orderId) can still magically access things with order IDs that don't exist in Account.Orders nor in OnExecutionUpdate nor OnOrderUpdate.

You can see what a confusing and how hours can be burned away. You can argue it has a logic to it, but the logic is confusing and can be done better, being blunt. I'm going over my code and am actually confused how I got all this to work, half the IDs I call aren't public properties in objects I reference. Ninja Trader playing Ninja with the developer when it should be behaving like a Samurai instead.

Thanks for your help thus far working with the product. I got it to behave good enough. The code can definitely not do all the GUI can in terms of ATMs. I look forward to server side code ATMs being a thing in future.

Note: I am a 20 year software development veteran and have dealt with many APIs. I have provided what I believe is valuable feedback that should be considered. Again thanks for your help with my other questions in other posts.

[bltdavid]

This reply may (or may not) directly help you.

Yes, the documented field called OrderId is not persistent.

However, there is an undocumented field called Id that
is integer based and (from my personal testing) never
changes.

<begin rant>
The fact that NinjaTrader has never seen fit to officially
support or provide complete documentation for a unique
and guaranteed permanent/persistent identifier for their
own internal Order objects has always shocked me.

This oversight is grievous. It eventually pisses off every
advanced NinjaScript programmer who discovers their
need for this indispensable but missing feature.
<end rant>

Anyways, the Id field has worked for my needs.

From what I can tell, Id is precisely the unique and
persistent identifier that we all wish officially existed.

Perhaps knowing this may help you in your workarounds.

Just my 2˘.

Additional reading here.

[NinjaTrader_Jesse]

Hello firefoxforum12,

In regard to order id it is expected to work with the orders name and not the ID directly when using Managed or Unmanaged strategies. The orders ID can change through its lifecycle and the platform will keep track of that, the orders Name can be something unique that you make it so its easy to find later.

When using ATM that is different and you should not be using order ID's at all. ATM methods do expect you to work with an ATM order id which is different and should be a local variable that you have saved. if you followed the SampleATMStrategy logic that is the following line which generates a unique ID that is not going to change until the strategies logic calls this line of code again.

orderId = GetAtmStrategyUniqueId();

If you are having difficulty with creating a strategy that uses ATM I would suggest to make an exact copy of the SampleATMStrategy as a starting point. You can do that by opening the SampleATMStrategy and then Right click -> Save as. That sample is the required base logic that is needed to submit a single ATM at a time based on an entry criteria. If you are still having problems after making a copy of that script please make a new post and then include a single question at a time in your post so that we can walk through the problem with you.

[firefoxforum12]

Thank you! I did all sorts of witchcraft already but will definitely keep this in mind for future.

NinjaTrader team, please document the ID that never changes.

This reply may (or may not) directly help you.

Yes, the documented field called OrderId is not unique.

However, there is an undocumented field called Id that
is integer based and (from my personal testing) never
changes.

<begin rant>
The fact that NinjaTrader has never seen fit to officially
support or provide complete documentation for a unique
and guaranteed permanent/persistent identifier for
Order objects has always shocked me.

This oversight is grievous. It eventually pisses off every
advanced NinjaScript programmer who discovers their
need for this indispensable but missing feature.
<end rant>

Anyways, the Id field has worked for my needs.

From what I can tell, Id is precisely the unique and
permanent identifier that we all wish officially existed.

Perhaps knowing this may help you in your workarounds.

Just my 2˘.

Additional reading here.

[NinjaTrader_Jesse]

Hello firefoxforum12,

Just to clarify the Order ID and the variable in the NinjaScript strategy are not the same thing, there is nothing to document here. An ID for an Order is the ID that is generated by an exchange. the variable used in the SampleATMStrategy is a variable, not a specific of an order.

[firefoxforum12]

Thanks for clarifying. In that case, please expose an ID across the spectrum NinjaTrader to Broker to moon to sun to NinjaTrader that never changes, specifically unique and unchanging for every Order object.

[NinjaTrader_Jesse]

Hello firefoxforum12.

ATM is specific to NinjaTrader so local ID's are not something that needs to be shared. The broker/exchange is only looking for an order ID for tracking purposes.They will likely generate this id themselves.

[firefoxforum12]

I really disagree with this idea. How the documentation communicates this and such is also confusing.

ATM may be specific to NinjaTrader (Tradovate) but eventually those orders DO get sent to the broker, and then when they come back, we are lost and confused if something isn't working correctly.

Something has to be improved here to be honest. You know more than myself at the deep level, but I can vouch for many of us there is a lot of room for improvement here.

Perhaps one idea is to always ensure an ID that is the same across all platforms is present in Ninjatrader, and IF the programmer happens to try manipulate an ATM order outside the ATM functions, you just throw an error in code "Cannot manipulate ORder XXXX as it is part of an ATM Strategy". That would be MILES better than whats going on now, which is like trying to walk into a cave with a torch that blows out every 2 minutes.

My two cents. I think I speak for a lot of people though that there is room for improvement.