IB API HOWTOs and Guidelines - For Beginners

Quote from slickpick:

I suggest just installing cygwin (if you're using windows), then using pip/easy_install for all module installs. Then use ipython for your interpreter/ide.
More...

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
 
Quote from Butterfly:

that's not a tutorial at all, but just another undocumented framework for IB API

I understand a lot of developers confuse listing their source code with documenting their code, but really, that link above is just another example of poor documentation for the IB API in Python. I came across a dozens of those already and they are not helping at all.

Next example, how to manage "OrderIDs" for successive trades
More...

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:

IB: Server Response = openOrder <openOrder orderId=6, contract=<ib.ext.Contract.Contract object at 0x012C3B50>, order=<ib.ext.Order.Order object at 0x012C3B30>,
orderState=<ib.ext.OrderState.OrderState object at 0x012C3C30>>
IB: Server Response = orderStatus <orderStatus orderId=6, status=Submitted, filled=0, remaining=200, avgFillPrice=0.0, permId=XXXXXX, parentId=0, lastFillPrice=0.0, clientId=123, whyHeld=None>
IB: Server Response = openOrderEnd <openOrderEnd>
More...

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:

IB: Server Error = <error id=6, errorCode=202, errorMsg=Order Canceled - reason:>
IB: Server Response = error <error id=6, errorCode=202, errorMsg=Order Canceled - reason:>
IB: Server Response = orderStatus <orderStatus orderId=6, status=Cancelled, filled=0, remaining=200,
avgFillPrice=0.0, permId=XXXXXX, parentId=0, lastFillPrice=0.0, clientId=123, whyHeld=None>
More...
 
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.
 
Quote from Butterfly:

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.
More...

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.
 
Quote from Butterfly:

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.
More...

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.
 
You must log in or register to reply here.
Back
Top