OnOrderUpdate using Interactive Brokers API

[FutureDragon]

NinjaTrader_Jim, NinjaTrader_Emily,
After creating several versions (Set__Methods, unmanaged, managed) of order management code for my strategies, I recently coded another managed version based on the ManagedRithmicIBFriendlyMultipleEntriesExample (assigning order objects in OnOrderUpdate, calculating average entry price, filled positions, and placing stop loss and profit target order in OnExecutionUpdate only referencing to execution.name. I used it recently traded the CPI event, and it worked for my Bulenox accounts (Rithmic) without problems.

Since this approach doesn't use any by ref object ( execution.name is a by-ref object in the literal sense, but I think it can be treated as a value object here), I think it might be a reasonable choice. I am not feel very comfortable deploying the unmanaged version to live accounts, as I keep finding issues that has been taken care of by the managed order framework.

Do you see any potential issues with this managed approach based on ManagedRithmicIBFriendlyMultipleEntriesExample? I'd like to hear your opinions on the pro's and con's of this approach vs the unmanaged sample that Jim provided.

[NinjaTrader_Emily]

NinjaTrader_Jim, NinjaTrader_Emily,
After creating several versions (Set__Methods, unmanaged, managed) of order management code for my strategies, I recently coded another managed version based on the ManagedRithmicIBFriendlyMultipleEntriesExample (assigning order objects in OnOrderUpdate, calculating average entry price, filled positions, and placing stop loss and profit target order in OnExecutionUpdate only referencing to execution.name. I used it recently traded the CPI event, and it worked for my Bulenox accounts (Rithmic) without problems.

Since this approach doesn't use any by ref object ( execution.name is a by-ref object in the literal sense, but I think it can be treated as a value object here), I think it might be a reasonable choice. I am not feel very comfortable deploying the unmanaged version to live accounts, as I keep finding issues that has been taken care of by the managed order framework.

Do you see any potential issues with this managed approach based on ManagedRithmicIBFriendlyMultipleEntriesExample? I'd like to hear your opinions on the pro's and con's of this approach vs the unmanaged sample that Jim provided.

Hello FutureDragon,

Thank you for your note.

Whether or not you use the unamanged or managed approach is ultimately up to you and your needs. It will depend on what you are looking to get out of your strategy. As you already mentioned, there is the managed order framework which has built in order handling rules to reduce unwanted positions:

https://ninjatrader.com/support/helpGuides/nt8/index.html?managed_approach.htm#InternalOrderHandlingRulesThatReduceUnwantedPositions

That being said, there are some limitations in the managed approach that might lead a developer to use the managed approach instead. It offers more flexibility to manually manage orders exactly how you would like without having to follow the order handling rules. One big difference between the two approaches is the unmanaged approach allows you to use OCO in the order methods, where the managed approach only uses OCO internally for orders submitted via the Set() methods. There is a high level overview of each approach in the help guide here:

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

If the managed approach meets your needs and is within your comfort level, using the ideas from the ManagedRithmicIbFriendlyMultipleEntriesExample should be fine as long as you plan to script within the bounds of the internal order handling rules that were previously mentioned. If those rules are restricting you and what you'd like to do with your strategy, then you would potentially need to look at scripting via the unmanaged approach.

Please let us know if we may be of further assistance.

[FutureDragon]

Emily, thanks for the reply. I use the versions of Enter/Exit methods with signal name. Do they use OCO internally based on the signal name?

[NinjaTrader_Emily]

Hello FutureDragon,

Thank you for your reply.

No, the Enter and Exit methods from the managed approach do not utilize OCO. When using the managed approach, OCO is only used if a profit target order with SetProfitTarget() is used in conjunction with a stop loss or trailing stop order using SetStopLoss() or SetTrailingStop(). This is noted on the help guide pages:

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

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

OCO is used so that if one order is filled, all other orders tied together via OCO are canceled. When using Exit methods as stops and targets, the default behavior is for limit orders to be canceled if the conditions to submit the order are no longer true. Otherwise, you could utilize advanced order handling and keep orders live until they are canceled by manually handling order objects and adding logic that will cancel orders when certain conditions are met. For example, you could have your strategy submit protective orders when a position is opened and if one of the protective orders (stop/target) is filled the logic cancels the remaining protective orders. The following reference samples are relevant to keeping orders alive, submitting protective orders with advanced order handling, and using CancelOrder() to cancel orders:

• Keeping orders alive: https://ninjatrader.com/support/help...ders_alive.htm
• Using OnOrderUpdate() and OnExecutionUpdate() to submit protective orders: https://ninjatrader.com/support/help...and_onexec.htm
• Using CancelOrder(): https://ninjatrader.com/support/help...thod_to_ca.htm
• Advanced Order Handling information: https://ninjatrader.com/support/help...r_handling.htm

As there are various options, it is up to you how you would like to submit and manage your orders.

Please feel free to reach out with any additional questions or concerns.