don't even need to go that far, Python offers a free Windows IDE download the Windows Python IDE is actually very simple, basically a text editor with some autocompletion feature for classes, very convenient to use without the hundreds of features and the UI distraction of a monster IDE like Visual Studio or Eclipse
my tutorial issimple. Your postings are scattered and unusable which is why I wrote mine. I cant understand what you are doing As for managing OrderIDs, just make it easy and tell people to add 1.
2rosy, your link is not a tutorial, you are simply publishing your source code which is a simple rewrite of subclass with wrappers with no meaningful explanation, completely useless in what we are trying to accomplish here.
Once the orders are placed, you can request to see opened trades, and if needed be, cancel a trade or "change" the quantity or price of that trade using the same OrderID. below is the code to get the opened trades from the IB Server and cancel a pending trade on the server Code: # LOAD the ib.ext and ib.opt Libraries from ib.ext.Contract import Contract from ib.ext.Order import Order from ib.opt import ibConnection, Connection, message # ... we assume that we keep the same handlers as before for all server replies... # see previous code for actual source code to be included here # Main code # Request All Pending Orders ibgw_conTradeChannel.reqOpenOrders() Output will be something like this: To cancel a trade, in this example the trade order with id = 6, we issue the following request: Code: # Cancel Trade Order ID = 6 ibgw_conTradeChannel.cancelOrder(6) Output will be something like this:
To build a simple ATS (not some crazy HFT ATS), you need to design your system with the following architecture in mind: 1. Classes or Functions to process and filter Data Feeds, may they be from your brokers or a different source. Data feeds can be more than simple quote streams, but also proprietary fundamental data from a Datawarehouse. More on this later. 2. Classes or Functions to load or select security candidates for trading. If the trading logic is done outside the IB execution domain, then this is a simple loading procedure of Security Symbol with target prices for BUY or SELL. More on this later. 3. Classes or Functions to send orders to a broker Server. If multiple brokers are involved, Classes or Functions will be needed to handle multiple brokers connections. Different APIs will be needed. 4. Capturing and managing the broker server messages in general. Error handling, capturing trades fills, checking order status, checking portfolio positions, checking security details. 5. Optionally, classes and functions to create securities for options trading (writing a call), or referencing complex securities for IB Built-in Options Trading strategies. This can be a vast topic in itself as the lines between execution and trading logic becomes blur.
It's a bit more complicated than this, even for a non-HF system. I think in general, one should be first aware of common design patterns for ATSs. Batch Pattern (simplest) - Basically you download historical data at some point in the day, re-run your models, and if your trade conditions are met a CSV is dumped out with trade to be imported into your EMS. Timer Based - AFAIK most open source ATSs are coded like this, you have a data stream coming in to be handled by some StrategyManager type class, then strategies poll the prices they need on a fixed timer (e.g. every 5 seconds). Event Driven - This is what I explained earlier, you basically have listeners for possible events that may occur and system logic is defined as such (e.g. doOnCancel, doOnBid, doOnAsk, doOnFill). This method will likely require the most thought. After deciding on a design pattern, then you think about what classes you need to implement.... This is where strategy, software engineering, and business development intersect, clearly you could build out something which handles all types of strategies but at what cost? I could probably run an EOD strategy in an event driven system, but I could also do it in a batch type system which took a fraction of the time to code. So I think it's important to keep in mind what your constraints are.
indeed, most OpenSource ATS are coded for "Timer Based" strategies, which is highly annoying because it's a very limited view of trading. Also, many of those have been developed by chartists for chartists. Trading strategies are more than simple analysis of charts and price patterns on charts, a common mistake made by many trading beginners.
I mean I think it's fine, esp if you're not doing HFT as event driven will tend to get computationally expensive as the number of strategies you're running increases. The implementation on the open-source side is just poor IMO. They mostly use fixed timers across the board, whereas I think it's a better practice to define polling frequency for a given strategy as every strategy has different requirements.
HFT is a whole different game, and this tutorial is definitely not for the HFT players. Some Python API is also dealing with Complex Event Processing (CEP) that will trap and filter all those different data streams that will trigger conditions for HFT trades. Like hacking, HFT is another state of mind in terms of programming.