OnExecution vs OnOrderUpdate

[soulfx]

Distinction between the above 2...

in the past in N7 a distinction was made and how I designed/developed strategies was that

OnExecution() is called after OnOrderUpdate() which ensures strategy receives the execution. And so stop/target orders were made in OnExecution() once the order was filled.

With the advent of addons in N8 and the interface for this - i wanted to check on the distinction and in looking over the sample addonframework - stop/target orders are made in OnOrderUpdate - with OnExecution being referred to as new executions coming in/existing execution is amended or execution is removed (ie by broker)

So can you outline what is the recommended approach now for this in N8 addon useage .. as it seems confusing and i would like to follow the correct approach :

What am i now doing in N8 addon with onExecution ? monitoring rejections cancellations or?

please advise
thanks

[NinjaTrader_JoshG]

Hello,

Thanks for your post.

OnExecutionUpdate() is called on an incoming execution, so that will be used to monitor order executions. Similar to NT7 OnExecutionUpdate() is always called after OnOrderUpdate().

OnOrderUpdate() will be used to monitor cancellations and rejections. This method is called each time an order managed by a strategy changes state, and guarantees that you will see each order state change in sequence.

If you have any further questions please let me know.

[soulfx]

Hello, thanks for reply,

So to confirm as above - the process is very similar from N7 to N8 and would be advisable to make the take profit/stop submissions in the OnExecution() where i can still check the orderstate

and checking cancellations and rejections in OnOrderUpdate

I just wondered why the sample code and the Help documentation illustrates the opposite - would it not be better to emphasise this in the documentation as it was in N7 - ie more reliable to submit targets/stops in OnExecution() ?

thanks

[NinjaTrader_JoshG]

Hello,

Thanks for your note.

Yes, this is correct, the process is the same from NT7 to NT8. You can still make stop submissions through that method and as long as you follow the note in the help guide regarding how to reference the properties on the IOrder object inside OnExecution(), you should be fine. You are also correct to check cancellations and rejections in OnOrderUpdate().

I am unsure though on what differences you are referring to in the help guide— both should be explaining mostly the same information. If you have a question about a particular part in the help guide I would be happy to help explain it.

Please let me know if you have any further questions.

[soulfx]

What i was referring to in the documentation is that for Addon order processing methods for ExecutionUpdate and OrderUpdate subscriptions on the Account - it is the OrderUpdate examples that sets the stop and take profit orders.

In following the approach where i set the stop and take profit orders in ExecutionUpdate callback ....
as per the strategy documentation for N8 it states to ALWAYS use the Order component of the Execution passed through as an argument - so for the Addon subscription this will be

private void OnExecutionUpdate(object sender, ExecutionEventArgs e)
{

e.Execution.Order to reference the properties of the order.

I am testing for paritial fills and the processing of this within OnExecutionUpdate callback for the ExecutionUpdate subscription ..

the field e.Execution.Order.Quantity

i am printing this value out along with whether the OrderState == Filled or PartFilled

If it is partfilled from the original entry order ... i want to keep track of the quantity

Will the e.Execution.Order.Quantity change as each partfill comes in ? so that i can keep track if i am short of the original entry submission?

Does this make sense?

Also in using the SIM101 account with a live data connection is there a limit to the number of contracts that can be submitted .. i tried submitting 10 several times but only got a fill for 8 with 2 cancelled? just wondered if something connected to SIM101 is limited or is related to the volume at the time ie was using 6E.

thanks

[NinjaTrader_JoshG]

Hello,

Thanks for your note.

It sounds like you are already tracking your partial filled orders with your own logic. e.Execution.Filled would be what you want to use to know what was filled for that execution.

The e.Execution.Order.Quantity will reflect how many orders were actually executed, so yes, each partial fill will effect that number.

The following forum post has a great sample script on how we recommend order tracking with OnExecutionUpdate().

https://ninjatrader.com/support/foru...ead.php?t=7499

In regards to those two orders being canceled on the 6E— This is not a limitation of the SIM101 account. It just sounds like there was not enough volume to fill the entire order but we would need more information to know for sure what happened.

If you have any further questions please let me know.