software - What approaches are there to order handling in automated trading?

I am currently developing a commercial automated trading program in which users can write their own proprietary code and develop strategies, like in NinjaTrader, MetaTrader etc. Right now I am working on the order handling part, which is really important. I can not figure out how to reference the orders entered during the execution of a strategy.

Suppose in a strategy, there is this piece of code:

if(some_condition)
  EnterLong("IBM",100)

My problem is some_condition can be set to true several times, which results in generating several buy orders. Somehow I have to provide the ability for users to modify or cancel some of these orders.

NinjaTrader, for example, has a feature called EntriesPerDirection, which limits the entry number for a direction (long or short). So you can have a certain number of order objects (or an array of orders) that are returned by order entry functions and say order1.Cancel(); However, this does not make any sense for an iceberging strategy in which thousands of orders could be generated. Both programs enable the user to iterate over the orders that have not led to a transaction yet. This again could be painful for iceberging purposes. I think those two programs are not specifically built for handling large numbers of orders or for developing execution algorithms (e.g., VWAP, Arrival Price, Implementation Shortfall) which are widely used among buy-side firms.

Also both NT and MT have events (OnOrderUpdate, OnExecution, OnTrade) that are fired when the status of an order is changed. This is a good idea, but I am not sure it is the best solution.

Are there any approaches or methodologies addressing my problem that are commonly used by other automated trading software?

Answer

Regarding your order management issue, every order should have a unique identifier that the user can reference; in FIX, this is the ClOrdID. The parameters of every order the user requests should be stored in a table keyed by this identifier.

If your goal is to prevent duplicate orders from going out, consider having a trade volume limit per each symbol. That way, subsequent order requests will be rejected by your order manager even if the condition has passed. A trade volume limit is also desirable to prevent moving the market (especially when coupled with a position limit) and can act as a safety mechanism if things get out of hand (we call this the blowout preventer at my current firm).

... both NT and MT have events (OnOrderUpdate, OnExecution, OnTrade) that are fired when the status of an order is changed.

Event-driven programming makes real-time trading much more manageable. This paradigm is known as "complex event processing" and is quite common in institutional trading.

I think those two programs are not spesifically built for handling large number of orders ...

That's because they were designed for day traders who want to pretend they're quants. No institutional trader would ever use those software packages.