BalanceBook? Account? OrderTracker?

[CriC]

Some parts of this message have been removed. Learn more about Nabble's security policy.

Hi , finally I've got something working, fetching candles live and backtesting.

I tried a simple average cross but there's still much confusion in my brian :-(

I'd like to keep trace of my orders for many reasons.

Is there a service to do this ?  I saw BalanceBook, but there's a sample about how to use it? others?

How is the Account wired with these services? any doc?

My effort is to setup a workable trading system with this features:

1. trading live ( ok)

2. backtesting (ok)

3. doing some reports

4. printing some equity / profit/ statistics

I didn't find anything similar in the example packages.  ????

:-) happy evening to everyone.

CriC

_______________________________________________
ccapi mailing list
ccapi@...
http://activestocks.de/cgi-bin/mailman/listinfo/ccapi

[CriC]

Some parts of this message have been removed. Learn more about Nabble's security policy.

Hi,

I cannot access to account from my system class.

BackTestConfig.java

---------------------------------------------------------------------------

    @Bean
    public Account account() throws Exception {
        if(account==null){
            account = new Account();
            // add one broker account
            brokerAccount = new BrokerAccount("PAPER", "1");
            account.addBrokerAccount(brokerAccount);
        }
        return account;
    }
   
   
    @Bean
    public IBroker broker() {
        return new ExecutingMockBroker();
    }

---------------------------------------------------------------------------

In my system I do this:

---------------------------------------------------------------------------

    @Inject private Account account;

    onCandle() I put the dumpAccount, just to debug

    public void dumpAccount(Account account){
        assert(account!=null);
        // dump out portfolio
        log.info(" === Portfolio dump start === ");
        Portfolio p = account.getPortfolio();
        for(Position pos : p.getPositions()){
            log.info(pos.toString());
        }
        log.info(" === Portfolio dump end === ");
    }

---------------------------------------------------------------------------

The output is always like this, even when I open position using the positionService.

2009-08-28 14:30:52,489 [main] INFO [TradeSystem] -  === Portfolio dump start ===
2009-08-28 14:30:52,504 [main] INFO [TradeSystem] -  === Portfolio dump end ===

This might have something to do with the ExecutingMockBroker() in the BackTestContext.

Any help?

...and the original configuration in the broker Bean was :

    @Bean
    public IBroker broker() {
        AccountManagingBrokerProxy ambp = new AccountManagingBrokerProxy(new ExecutingMockBroker(), brokerAccount);
        return ambp;
    }

BUT with this I got a NullPointer Exception:

2009-08-28 14:35:00,804 [Thread-835] INFO [org.activequant.broker.ExecutingMockBroker$OrderTracker] - dispatching new order event: OrderExecutionEvent: eventTimeStamp=null, message=null, quantity=1000.0, price=-1.0, commission=0.0

java.lang.NullPointerException
    at org.activequant.broker.AccountManagingBrokerProxy$OrderTrackerProxy.processExecution(AccountManagingBrokerProxy.java:110)
    at org.activequant.broker.AccountManagingBrokerProxy$OrderTrackerProxy.access$400(AccountManagingBrokerProxy.java:65)
    at org.activequant.broker.AccountManagingBrokerProxy$OrderTrackerProxy$1.eventFired(AccountManagingBrokerProxy.java:85)
    at org.activequant.broker.AccountManagingBrokerProxy$OrderTrackerProxy$1.eventFired(AccountManagingBrokerProxy.java:76)
    at org.activequant.util.pattern.events.Event.fire(Event.java:43)
    at org.activequant.broker.BrokerBase$OrderTrackerBase.fireOrderEvent(BrokerBase.java:288)
    at org.activequant.broker.ExecutingMockBroker$OrderTracker$1.run(ExecutingMockBroker.java:68)
    at java.lang.Thread.run(Thread.java:619)
java.lang.NullPointerException
    at org.activequant.broker.AccountManagingBrokerProxy$OrderTrackerProxy.processExecution(AccountManagingBrokerProxy.java:110)
    at org.activequant.broker.AccountManagingBrokerProxy$OrderTrackerProxy.access$400(AccountManagingBrokerProxy.java:65)
    at org.activequant.broker.AccountManagingBrokerProxy$OrderTrackerProxy$1.eventFired(AccountManagingBrokerProxy.java:85)
    at org.activequant.broker.AccountManagingBrokerProxy$OrderTrackerProxy$1.eventFired(AccountManagingBrokerProxy.java:76)
    at org.activequant.util.pattern.events.Event.fire(Event.java:43)
    at org.activequant.broker.BrokerBase$OrderTrackerBase.fireOrderEvent(BrokerBase.java:288)
    at org.activequant.broker.ExecutingMockBroker$OrderTracker$1.run(ExecutingMockBroker.java:68)
    at java.lang.Thread.run(Thread.java:619)

cric

 

----- Original Message -----

From: Cristina Colonna

Sent: 08/27/09 08:23 pm

To: ccapi2 and activeQuant discussion list

Subject: [ccapi] BalanceBook? Account? OrderTracker?

 

Hi , finally I've got something working, fetching candles live and backtesting.

I tried a simple average cross but there's still much confusion in my brian :-(

I'd like to keep trace of my orders for many reasons.

Is there a service to do this ?  I saw BalanceBook, but there's a sample about how to use it? others?

How is the Account wired with these services? any doc?

My effort is to setup a workable trading system with this features:

1. trading live ( ok)

2. backtesting (ok)

3. doing some reports

4. printing some equity / profit/ statistics

I didn't find anything similar in the example packages.  ????

:-) happy evening to everyone.

CriC

 

_______________________________________________
ccapi mailing list
ccapi@...
http://activestocks.de/cgi-bin/mailman/listinfo/ccapi

[Mike Kroutikov-2]

Cric,

Account management is (supposed to be) automatic, if you wrap your broker into AccountManagingBrokerProxy. This proxy looks to the outside world as a normal broker, and it does pass thru all the orders and events to/from the real broker (the wrapped one). In addition, it keeps track of all order executions by updating the account/portfolio beans. Make sure that context has only one @Bean of IBroker type, and that it actually is AccountManagingBrokerProxy.

I have no explanation for the NPE yet. It looks to me that ExecutingMockBroker can only deal with limit orders. What type of order are you sending? What kind of broker did you use before you tried to modify context to add accounting?

-Mike

On Fri, Aug 28, 2009 at 8:30 AM, Cristina Colonna <cristina.colonna@...> wrote:

Hi,

I cannot access to account from my system class.

BackTestConfig.java

---------------------------------------------------------------------------

    @Bean
    public Account account() throws Exception {
        if(account==null){
            account = new Account();
            // add one broker account
            brokerAccount = new BrokerAccount("PAPER", "1");
            account.addBrokerAccount(brokerAccount);
        }
        return account;
    }
   
   
    @Bean
    public IBroker broker() {
        return new ExecutingMockBroker();
    }

---------------------------------------------------------------------------

In my system I do this:

---------------------------------------------------------------------------

    @Inject private Account account;

    onCandle() I put the dumpAccount, just to debug

    public void dumpAccount(Account account){
        assert(account!=null);
        // dump out portfolio
        log.info(" === Portfolio dump start === ");
        Portfolio p = account.getPortfolio();
        for(Position pos : p.getPositions()){
            log.info(pos.toString());
        }
        log.info(" === Portfolio dump end === ");
    }

---------------------------------------------------------------------------

The output is always like this, even when I open position using the positionService.

2009-08-28 14:30:52,489 [main] INFO [TradeSystem] -  === Portfolio dump start ===
2009-08-28 14:30:52,504 [main] INFO [TradeSystem] -  === Portfolio dump end ===

This might have something to do with the ExecutingMockBroker() in the BackTestContext.

Any help?

...and the original configuration in the broker Bean was :

    @Bean
    public IBroker broker() {
        AccountManagingBrokerProxy ambp = new AccountManagingBrokerProxy(new ExecutingMockBroker(), brokerAccount);
        return ambp;
    }

BUT with this I got a NullPointer Exception:

2009-08-28 14:35:00,804 [Thread-835] INFO [org.activequant.broker.ExecutingMockBroker$OrderTracker] - dispatching new order event: OrderExecutionEvent: eventTimeStamp=null, message=null, quantity=1000.0, price=-1.0, commission=0.0

java.lang.NullPointerException
    at org.activequant.broker.AccountManagingBrokerProxy$OrderTrackerProxy.processExecution(AccountManagingBrokerProxy.java:110)
    at org.activequant.broker.AccountManagingBrokerProxy$OrderTrackerProxy.access$400(AccountManagingBrokerProxy.java:65)
    at org.activequant.broker.AccountManagingBrokerProxy$OrderTrackerProxy$1.eventFired(AccountManagingBrokerProxy.java:85)
    at org.activequant.broker.AccountManagingBrokerProxy$OrderTrackerProxy$1.eventFired(AccountManagingBrokerProxy.java:76)
    at org.activequant.util.pattern.events.Event.fire(Event.java:43)
    at org.activequant.broker.BrokerBase$OrderTrackerBase.fireOrderEvent(BrokerBase.java:288)
    at org.activequant.broker.ExecutingMockBroker$OrderTracker$1.run(ExecutingMockBroker.java:68)
    at java.lang.Thread.run(Thread.java:619)
java.lang.NullPointerException
    at org.activequant.broker.AccountManagingBrokerProxy$OrderTrackerProxy.processExecution(AccountManagingBrokerProxy.java:110)
    at org.activequant.broker.AccountManagingBrokerProxy$OrderTrackerProxy.access$400(AccountManagingBrokerProxy.java:65)
    at org.activequant.broker.AccountManagingBrokerProxy$OrderTrackerProxy$1.eventFired(AccountManagingBrokerProxy.java:85)
    at org.activequant.broker.AccountManagingBrokerProxy$OrderTrackerProxy$1.eventFired(AccountManagingBrokerProxy.java:76)
    at org.activequant.util.pattern.events.Event.fire(Event.java:43)
    at org.activequant.broker.BrokerBase$OrderTrackerBase.fireOrderEvent(BrokerBase.java:288)
    at org.activequant.broker.ExecutingMockBroker$OrderTracker$1.run(ExecutingMockBroker.java:68)
    at java.lang.Thread.run(Thread.java:619)

cric

 

----- Original Message -----

From: Cristina Colonna

Sent: 08/27/09 08:23 pm

To: ccapi2 and activeQuant discussion list

Subject: [ccapi] BalanceBook? Account? OrderTracker?

 

Hi , finally I've got something working, fetching candles live and backtesting.

I tried a simple average cross but there's still much confusion in my brian :-(

I'd like to keep trace of my orders for many reasons.

Is there a service to do this ?  I saw BalanceBook, but there's a sample about how to use it? others?

How is the Account wired with these services? any doc?

My effort is to setup a workable trading system with this features:

1. trading live ( ok)

2. backtesting (ok)

3. doing some reports

4. printing some equity / profit/ statistics

I didn't find anything similar in the example packages.  ????

:-) happy evening to everyone.

CriC

 

_______________________________________________
ccapi mailing list
ccapi@...
http://activestocks.de/cgi-bin/mailman/listinfo/ccapi

_______________________________________________
ccapi mailing list
ccapi@...
http://activestocks.de/cgi-bin/mailman/listinfo/ccapi

[CriC]

Some parts of this message have been removed. Learn more about Nabble's security policy.

Hi Mike,

Yes I confirm account bean has been injected correctly and it has everything I need except it return NPE but

I am not sending limit order, I am sending market order like this:

                // open position               
                Order order = new Order();
                order.setInstrumentSpecification(spec);
                order.setOrderTimeStamp(new TimeStamp());
                order.setOrderSide(OrderSide.BUY);
                order.setOrderType(OrderType.MARKET);
                order.setQuantity(quantity);
               
                // EXECUTE
                position = positionService.openPosition(order);

So what does it mean? I cannot use market order with ExecutingMockBroker ??

Is there another XXXBroker class I can use instead of it?

Tell me if I can help in any way.

thank

cric

 

----- Original Message -----

From: Mike Kroutikov

Sent: 08/29/09 06:08 pm

To: ccapi2 and activeQuant discussion list

Subject: Re: [ccapi] BalanceBook? Account? OrderTracker?

 

Cric,

Account management is (supposed to be) automatic, if you wrap your broker into AccountManagingBrokerProxy. This proxy looks to the outside world as a normal broker, and it does pass thru all the orders and events to/from the real broker (the wrapped one). In addition, it keeps track of all order executions by updating the account/portfolio beans. Make sure that context has only one @Bean of IBroker type, and that it actually is AccountManagingBrokerProxy.

I have no explanation for the NPE yet. It looks to me that ExecutingMockBroker can only deal with limit orders. What type of order are you sending? What kind of broker did you use before you tried to modify context to add accounting?

-Mike

On Fri, Aug 28, 2009 at 8:30 AM, Cristina Colonna <cristina.colonna@...> wrote:

Hi,

I cannot access to account from my system class.

BackTestConfig.java

---------------------------------------------------------------------------

    @Bean
    public Account account() throws Exception {
        if(account==null){
            account = new Account();
            // add one broker account
            brokerAccount = new BrokerAccount("PAPER", "1");
            account.addBrokerAccount(brokerAccount);
        }
        return account;
    }
   
   
    @Bean
    public IBroker broker() {
        return new ExecutingMockBroker();
    }

---------------------------------------------------------------------------

In my system I do this:

---------------------------------------------------------------------------

    @Inject private Account account;

    onCandle() I put the dumpAccount, just to debug

    public void dumpAccount(Account account){
        assert(account!=null);
        // dump out portfolio
        log.info(" === Portfolio dump start === ");
        Portfolio p = account.getPortfolio();
        for(Position pos : p.getPositions()){
            log.info(pos.toString());
        }
        log.info(" === Portfolio dump end === ");
    }

---------------------------------------------------------------------------

The output is always like this, even when I open position using the positionService.

2009-08-28 14:30:52,489 [main] INFO [TradeSystem] -  === Portfolio dump start ===
2009-08-28 14:30:52,504 [main] INFO [TradeSystem] -  === Portfolio dump end ===

This might have something to do with the ExecutingMockBroker() in the BackTestContext.

Any help?

...and the original configuration in the broker Bean was :

    @Bean
    public IBroker broker() {
        AccountManagingBrokerProxy ambp = new AccountManagingBrokerProxy(new ExecutingMockBroker(), brokerAccount);
        return ambp;
    }

BUT with this I got a NullPointer Exception:

2009-08-28 14:35:00,804 [Thread-835] INFO [org.activequant.broker.ExecutingMockBroker$OrderTracker] - dispatching new order event: OrderExecutionEvent: eventTimeStamp=null, message=null, quantity=1000.0, price=-1.0, commission=0.0

java.lang.NullPointerException
    at org.activequant.broker.AccountManagingBrokerProxy$OrderTrackerProxy.processExecution(AccountManagingBrokerProxy.java:110)
    at org.activequant.broker.AccountManagingBrokerProxy$OrderTrackerProxy.access$400(AccountManagingBrokerProxy.java:65)
    at org.activequant.broker.AccountManagingBrokerProxy$OrderTrackerProxy$1.eventFired(AccountManagingBrokerProxy.java:85)
    at org.activequant.broker.AccountManagingBrokerProxy$OrderTrackerProxy$1.eventFired(AccountManagingBrokerProxy.java:76)
    at org.activequant.util.pattern.events.Event.fire(Event.java:43)
    at org.activequant.broker.BrokerBase$OrderTrackerBase.fireOrderEvent(BrokerBase.java:288)
    at org.activequant.broker.ExecutingMockBroker$OrderTracker$1.run(ExecutingMockBroker.java:68)
    at java.lang.Thread.run(Thread.java:619)
java.lang.NullPointerException
    at org.activequant.broker.AccountManagingBrokerProxy$OrderTrackerProxy.processExecution(AccountManagingBrokerProxy.java:110)
    at org.activequant.broker.AccountManagingBrokerProxy$OrderTrackerProxy.access$400(AccountManagingBrokerProxy.java:65)
    at org.activequant.broker.AccountManagingBrokerProxy$OrderTrackerProxy$1.eventFired(AccountManagingBrokerProxy.java:85)
    at org.activequant.broker.AccountManagingBrokerProxy$OrderTrackerProxy$1.eventFired(AccountManagingBrokerProxy.java:76)
    at org.activequant.util.pattern.events.Event.fire(Event.java:43)
    at org.activequant.broker.BrokerBase$OrderTrackerBase.fireOrderEvent(BrokerBase.java:288)
    at org.activequant.broker.ExecutingMockBroker$OrderTracker$1.run(ExecutingMockBroker.java:68)
    at java.lang.Thread.run(Thread.java:619)

cric

 

----- Original Message -----

From: Cristina Colonna

Sent: 08/27/09 08:23 pm

To: ccapi2 and activeQuant discussion list

Subject: [ccapi] BalanceBook? Account? OrderTracker?

 

Hi , finally I've got something working, fetching candles live and backtesting.

I tried a simple average cross but there's still much confusion in my brian :-(

I'd like to keep trace of my orders for many reasons.

Is there a service to do this ?  I saw BalanceBook, but there's a sample about how to use it? others?

How is the Account wired with these services? any doc?

My effort is to setup a workable trading system with this features:

1. trading live ( ok)

2. backtesting (ok)

3. doing some reports

4. printing some equity / profit/ statistics

I didn't find anything similar in the example packages.  ????

:-) happy evening to everyone.

CriC

 

_______________________________________________
ccapi mailing list
ccapi@...
http://activestocks.de/cgi-bin/mailman/listinfo/ccapi

 

_______________________________________________
ccapi mailing list
ccapi@...
http://activestocks.de/cgi-bin/mailman/listinfo/ccapi

[Mike Kroutikov-2]

Cric,

there are two things to look at. First, there should be no NPE, even with ExecutingBroker. I have no clue why NPE is being thrown. This is something for me to research. Can you post (possibly simplified version of) your config files, so that I can reproduce it and debug?

Second, ExecutingBroker is no good, as its very primitive and is designed to handle limit orders only (afaik). Use PaperBroker for realistic simulation.

-Mike

On Sun, Aug 30, 2009 at 5:47 AM, Cristina Colonna <cristina.colonna@...> wrote:

Hi Mike,

Yes I confirm account bean has been injected correctly and it has everything I need except it return NPE but

I am not sending limit order, I am sending market order like this:

                // open position               
                Order order = new Order();
                order.setInstrumentSpecification(spec);
                order.setOrderTimeStamp(new TimeStamp());
                order.setOrderSide(OrderSide.BUY);
                order.setOrderType(OrderType.MARKET);
                order.setQuantity(quantity);
               
                // EXECUTE
                position = positionService.openPosition(order);

So what does it mean? I cannot use market order with ExecutingMockBroker ??

Is there another XXXBroker class I can use instead of it?

Tell me if I can help in any way.

thank

cric

 

----- Original Message -----

From: Mike Kroutikov

Sent: 08/29/09 06:08 pm

To: ccapi2 and activeQuant discussion list

Subject: Re: [ccapi] BalanceBook? Account? OrderTracker?

 

Cric,

Account management is (supposed to be) automatic, if you wrap your broker into AccountManagingBrokerProxy. This proxy looks to the outside world as a normal broker, and it does pass thru all the orders and events to/from the real broker (the wrapped one). In addition, it keeps track of all order executions by updating the account/portfolio beans. Make sure that context has only one @Bean of IBroker type, and that it actually is AccountManagingBrokerProxy.

I have no explanation for the NPE yet. It looks to me that ExecutingMockBroker can only deal with limit orders. What type of order are you sending? What kind of broker did you use before you tried to modify context to add accounting?

-Mike

On Fri, Aug 28, 2009 at 8:30 AM, Cristina Colonna <cristina.colonna@...> wrote:

Hi,

I cannot access to account from my system class.

BackTestConfig.java

---------------------------------------------------------------------------

    @Bean
    public Account account() throws Exception {
        if(account==null){
            account = new Account();
            // add one broker account
            brokerAccount = new BrokerAccount("PAPER", "1");
            account.addBrokerAccount(brokerAccount);
        }
        return account;
    }
   
   
    @Bean
    public IBroker broker() {
        return new ExecutingMockBroker();
    }

---------------------------------------------------------------------------

In my system I do this:

---------------------------------------------------------------------------

    @Inject private Account account;

    onCandle() I put the dumpAccount, just to debug

    public void dumpAccount(Account account){
        assert(account!=null);
        // dump out portfolio
        log.info(" === Portfolio dump start === ");
        Portfolio p = account.getPortfolio();
        for(Position pos : p.getPositions()){
            log.info(pos.toString());
        }
        log.info(" === Portfolio dump end === ");
    }

---------------------------------------------------------------------------

The output is always like this, even when I open position using the positionService.

2009-08-28 14:30:52,489 [main] INFO [TradeSystem] -  === Portfolio dump start ===
2009-08-28 14:30:52,504 [main] INFO [TradeSystem] -  === Portfolio dump end ===

This might have something to do with the ExecutingMockBroker() in the BackTestContext.

Any help?

...and the original configuration in the broker Bean was :

    @Bean
    public IBroker broker() {
        AccountManagingBrokerProxy ambp = new AccountManagingBrokerProxy(new ExecutingMockBroker(), brokerAccount);
        return ambp;
    }

BUT with this I got a NullPointer Exception:

2009-08-28 14:35:00,804 [Thread-835] INFO [org.activequant.broker.ExecutingMockBroker$OrderTracker] - dispatching new order event: OrderExecutionEvent: eventTimeStamp=null, message=null, quantity=1000.0, price=-1.0, commission=0.0

java.lang.NullPointerException
    at org.activequant.broker.AccountManagingBrokerProxy$OrderTrackerProxy.processExecution(AccountManagingBrokerProxy.java:110)
    at org.activequant.broker.AccountManagingBrokerProxy$OrderTrackerProxy.access$400(AccountManagingBrokerProxy.java:65)
    at org.activequant.broker.AccountManagingBrokerProxy$OrderTrackerProxy$1.eventFired(AccountManagingBrokerProxy.java:85)
    at org.activequant.broker.AccountManagingBrokerProxy$OrderTrackerProxy$1.eventFired(AccountManagingBrokerProxy.java:76)
    at org.activequant.util.pattern.events.Event.fire(Event.java:43)
    at org.activequant.broker.BrokerBase$OrderTrackerBase.fireOrderEvent(BrokerBase.java:288)
    at org.activequant.broker.ExecutingMockBroker$OrderTracker$1.run(ExecutingMockBroker.java:68)
    at java.lang.Thread.run(Thread.java:619)
java.lang.NullPointerException
    at org.activequant.broker.AccountManagingBrokerProxy$OrderTrackerProxy.processExecution(AccountManagingBrokerProxy.java:110)
    at org.activequant.broker.AccountManagingBrokerProxy$OrderTrackerProxy.access$400(AccountManagingBrokerProxy.java:65)
    at org.activequant.broker.AccountManagingBrokerProxy$OrderTrackerProxy$1.eventFired(AccountManagingBrokerProxy.java:85)
    at org.activequant.broker.AccountManagingBrokerProxy$OrderTrackerProxy$1.eventFired(AccountManagingBrokerProxy.java:76)
    at org.activequant.util.pattern.events.Event.fire(Event.java:43)
    at org.activequant.broker.BrokerBase$OrderTrackerBase.fireOrderEvent(BrokerBase.java:288)
    at org.activequant.broker.ExecutingMockBroker$OrderTracker$1.run(ExecutingMockBroker.java:68)
    at java.lang.Thread.run(Thread.java:619)

cric

 

----- Original Message -----

From: Cristina Colonna

Sent: 08/27/09 08:23 pm

To: ccapi2 and activeQuant discussion list

Subject: [ccapi] BalanceBook? Account? OrderTracker?

 

Hi , finally I've got something working, fetching candles live and backtesting.

I tried a simple average cross but there's still much confusion in my brian :-(

I'd like to keep trace of my orders for many reasons.

Is there a service to do this ?  I saw BalanceBook, but there's a sample about how to use it? others?

How is the Account wired with these services? any doc?

My effort is to setup a workable trading system with this features:

1. trading live ( ok)

2. backtesting (ok)

3. doing some reports

4. printing some equity / profit/ statistics

I didn't find anything similar in the example packages.  ????

:-) happy evening to everyone.

CriC

 

_______________________________________________
ccapi mailing list
ccapi@...
http://activestocks.de/cgi-bin/mailman/listinfo/ccapi

 

_______________________________________________
ccapi mailing list
ccapi@...
http://activestocks.de/cgi-bin/mailman/listinfo/ccapi

_______________________________________________
ccapi mailing list
ccapi@...
http://activestocks.de/cgi-bin/mailman/listinfo/ccapi

[CriC]

Mike,

I attached the whole system,so  I think it is easier to test.
I tried with PaperBroker too but got another NPE.

Thank you.

mytest.zip

[Mike Kroutikov-2]

Definitely ExecutionBroker is no good - it seem to be designed to work only with LIMIT orders of a special kind. I changed to PaperBroker (which is a standard broker simulator in AQ), and it seem to be working now. Paper broker needs quote subscription feed, so I had to add simulated quote subscription. Check it out (attached). I believe I only changed YahooBacktestContextConfig.java, but attaching everyhting - just in case.

By the end of the simulated run you've lost about $12500 - sorry about that :-P

-Mike

On Sun, Aug 30, 2009 at 3:03 PM, CriC <cristina.colonna@...> wrote:

Mike,

I attached the whole system,so  I think it is easier to test.
I tried with PaperBroker too but got another NPE.

Thank you.

http://www.nabble.com/file/p25214590/mytest.zip mytest.zip
--
View this message in context: http://www.nabble.com/BalanceBook--Account--OrderTracker--tp25177571p25214590.html
Sent from the ActiveQuant mailing list archive at Nabble.com.

_______________________________________________
ccapi mailing list
ccapi@...
http://activestocks.de/cgi-bin/mailman/listinfo/ccapi

_______________________________________________
ccapi mailing list
ccapi@...
http://activestocks.de/cgi-bin/mailman/listinfo/ccapi

[Ulrich Staudinger-2]

maybe the parameters could be optimized :-)

On Mon, Aug 31, 2009 at 1:45 AM, Mike Kroutikov <pgmmpk@...> wrote:

Definitely ExecutionBroker is no good - it seem to be designed to work only with LIMIT orders of a special kind. I changed to PaperBroker (which is a standard broker simulator in AQ), and it seem to be working now. Paper broker needs quote subscription feed, so I had to add simulated quote subscription. Check it out (attached). I believe I only changed YahooBacktestContextConfig.java, but attaching everyhting - just in case.

By the end of the simulated run you've lost about $12500 - sorry about that :-P

-Mike

On Sun, Aug 30, 2009 at 3:03 PM, CriC <cristina.colonna@...> wrote:

Mike,

I attached the whole system,so  I think it is easier to test.
I tried with PaperBroker too but got another NPE.

Thank you.

http://www.nabble.com/file/p25214590/mytest.zip mytest.zip
--
View this message in context: http://www.nabble.com/BalanceBook--Account--OrderTracker--tp25177571p25214590.html
Sent from the ActiveQuant mailing list archive at Nabble.com.

_______________________________________________
ccapi mailing list
ccapi@...
http://activestocks.de/cgi-bin/mailman/listinfo/ccapi

_______________________________________________
ccapi mailing list
ccapi@...
http://activestocks.de/cgi-bin/mailman/listinfo/ccapi

--
Ulrich B. Staudinger

_______________________________________________
ccapi mailing list
ccapi@...
http://activestocks.de/cgi-bin/mailman/listinfo/ccapi

[CriC]

Hi Mike,

great!
Oh, dont look at the loss, I'm not so fool to trade a simple cross avg system :-)
hey, I dont know how to thank you for the prompt help!
:-)
cric

Mike Kroutikov-2 wrote:

Definitely ExecutionBroker is no good - it seem to be designed to work only
with LIMIT orders of a special kind. I changed to PaperBroker (which is a
standard broker simulator in AQ), and it seem to be working now. Paper
broker needs quote subscription feed, so I had to add simulated quote
subscription. Check it out (attached). I believe I only changed
YahooBacktestContextConfig.java, but attaching everyhting - just in case.

By the end of the simulated run you've lost about $12500 - sorry about that
:-P

-Mike

[CriC]

Hi again :-)
No more NPE but I still cant access account properties.

        account.getBalanceBook().getCurrentBalance();
 Or
        account.getBrokerAccount("PAPER").getBalanceBook().getCurrentBalance();

the balance is always 0.0.
I have to wire manually account bean to somethingelse?

cric

Mike Kroutikov-2 wrote:

Definitely ExecutionBroker is no good - it seem to be designed to work only
with LIMIT orders of a special kind. I changed to PaperBroker (which is a
standard broker simulator in AQ), and it seem to be working now. Paper
broker needs quote subscription feed, so I had to add simulated quote
subscription. Check it out (attached). I believe I only changed
YahooBacktestContextConfig.java, but attaching everyhting - just in case.

By the end of the simulated run you've lost about $12500 - sorry about that
:-P

-Mike

[Ulrich Staudinger-2]

Hi,
If i remember correctly, you need to use an AccountManagingBrokerProxy in front of the PaperBroker ...

Hth,
Ulrich

On Mon, Aug 31, 2009 at 10:43 AM, CriC <cristina.colonna@...> wrote:

Hi again :-)
No more NPE but I still cant access account properties.

       account.getBalanceBook().getCurrentBalance();
 Or

account.getBrokerAccount("PAPER").getBalanceBook().getCurrentBalance();

the balance is always 0.0.
I have to wire manually account bean to somethingelse?

cric


Mike Kroutikov-2 wrote:
>

> Definitely ExecutionBroker is no good - it seem to be designed to work
> only
> with LIMIT orders of a special kind. I changed to PaperBroker (which is a
> standard broker simulator in AQ), and it seem to be working now. Paper
> broker needs quote subscription feed, so I had to add simulated quote
> subscription. Check it out (attached). I believe I only changed
> YahooBacktestContextConfig.java, but attaching everyhting - just in case.
>
> By the end of the simulated run you've lost about $12500 - sorry about
> that
> :-P
>
> -Mike
>
>

--
View this message in context: http://www.nabble.com/BalanceBook--Account--OrderTracker--tp25177571p25220128.html

Sent from the ActiveQuant mailing list archive at Nabble.com.

_______________________________________________
ccapi mailing list
ccapi@...
http://activestocks.de/cgi-bin/mailman/listinfo/ccapi

--
Ulrich B. Staudinger

_______________________________________________
ccapi mailing list
ccapi@...
http://activestocks.de/cgi-bin/mailman/listinfo/ccapi

[CriC]

that's it:

        @Bean
        public IBroker broker() throws Exception {
                PaperBroker paperBroker = new PaperBroker();
                IQuoteSubscriptionSource qs = new TradeIndicationToQuoteSubscriptionSourceConverter(tradeIndicationSubscriptionSource());
                paperBroker.setQuoteSubscriptionSource(qs);
                AccountManagingBrokerProxy ambp = new AccountManagingBrokerProxy(paperBroker, account().getBrokerAccount("PAPER"));
brokerAccount);
                return ambp;
        }

and in the code I Inject the Account bean, it works beacuase I can read the account ID, but i cannot get the balance.

thks
cric

Ulrich Staudinger-2 wrote:

Hi,
If i remember correctly, you need to use an AccountManagingBrokerProxy in
front of the PaperBroker ...

Hth,
Ulrich


On Mon, Aug 31, 2009 at 10:43 AM, CriC <[e-mail]> wrote:

>
>
> Hi again :-)
> No more NPE but I still cant access account properties.
>
>        account.getBalanceBook().getCurrentBalance();
>  Or
>
> account.getBrokerAccount("PAPER").getBalanceBook().getCurrentBalance();
>
> the balance is always 0.0.
> I have to wire manually account bean to somethingelse?
>
> cric
>
>
> Mike Kroutikov-2 wrote:
> >
> > Definitely ExecutionBroker is no good - it seem to be designed to work
> > only
> > with LIMIT orders of a special kind. I changed to PaperBroker (which is a
> > standard broker simulator in AQ), and it seem to be working now. Paper
> > broker needs quote subscription feed, so I had to add simulated quote
> > subscription. Check it out (attached). I believe I only changed
> > YahooBacktestContextConfig.java, but attaching everyhting - just in case.
> >
> > By the end of the simulated run you've lost about $12500 - sorry about
> > that
> > :-P
> >
> > -Mike
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/BalanceBook--Account--OrderTracker--tp25177571p25220128.html
> Sent from the ActiveQuant mailing list archive at Nabble.com.
>
> _______________________________________________
> ccapi mailing list
> [e-mail]
> http://activestocks.de/cgi-bin/mailman/listinfo/ccapi
>



--
Ulrich B. Staudinger

_______________________________________________
ccapi mailing list
[e-mail]
http://activestocks.de/cgi-bin/mailman/listinfo/ccapi

[eland]

I'm still hung up on trying to figure out how AQ can be setup to manage executions that don't have a known order.  The only way I've seen so far that seems to require the least amount of changes is to incorporate the concept of an "orphan order".  The idea would have to be implemented by the originating real IBroker.  (See IBBroker.java attached for an example.)

I would really like to hear everyone's thoughts on this.  If someone sees an even better way to solve this problem please speak up!

Thanks in advance for everyone's input.

Eyon


Confidentiality Statement:
This message is confidential and may contain confidential information it is intended only for the individual[s] named herein. If this message is being sent from a member of the legal department, it may also be legally privileged.   If you are not the named addressee[s] you must delete this email immediately; do not disseminate, distribute or copy.

STATEMENT OF CONFIDENTIALITY: This message and any attachments are intended solely for the person or entity to which it is addressed and may contain confidential or privileged information. If the recipient of this message is not the addressee or a person responsible for delivering the message to the addressee, such recipient is prohibited from reading or using this message in any way. If you have received this message in error, please call the sender of this message immediately and delete the message from any computer.


_______________________________________________
ccapi mailing list
ccapi@...
http://activestocks.de/cgi-bin/mailman/listinfo/ccapi

[Mike Kroutikov-2]

Eyon,

I do not get it. How IB can have "orphan executions"? Do you want to support tracking of orders entered "by hand" into TWS?
What is the use case?

-Mike

On Thu, Sep 3, 2009 at 6:04 PM, Eyon Land <ELand@...> wrote:

I'm still hung up on trying to figure out how AQ can be setup to manage executions that don't have a known order.  The only way I've seen so far that seems to require the least amount of changes is to incorporate the concept of an "orphan order".  The idea would have to be implemented by the originating real IBroker.  (See IBBroker.java attached for an example.)

I would really like to hear everyone's thoughts on this.  If someone sees an even better way to solve this problem please speak up!

Thanks in advance for everyone's input.

Eyon


Confidentiality Statement:
This message is confidential and may contain confidential information it is intended only for the individual[s] named herein. If this message is being sent from a member of the legal department, it may also be legally privileged.   If you are not the named addressee[s] you must delete this email immediately; do not disseminate, distribute or copy.

STATEMENT OF CONFIDENTIALITY: This message and any attachments are intended solely for the person or entity to which it is addressed and may contain confidential or privileged information. If the recipient of this message is not the addressee or a person responsible for delivering the message to the addressee, such recipient is prohibited from reading or using this message in any way. If you have received this message in error, please call the sender of this message immediately and delete the message from any computer.

_______________________________________________
ccapi mailing list
ccapi@...
http://activestocks.de/cgi-bin/mailman/listinfo/ccapi

_______________________________________________
ccapi mailing list
ccapi@...
http://activestocks.de/cgi-bin/mailman/listinfo/ccapi

[Mike Kroutikov-2]

Cric,

I do not see a problem. I changed TradeSystemLogic.java to add current balance info to dumpAccount():

    public void dumpAccount(Account account){
        assert(account!=null);
        // dump out portfolio       
        log.info(" === Portfolio dump start [Account:"+account.getId()+"]=== ");
        Portfolio p = account.getPortfolio();
        for(Position pos : p.getPositions()){
            log.info(pos.toString());
        }
        double balance = account.getBrokerAccount("PAPER").getBalanceBook().getCurrentBalance();
        log.info("balance=" + balance);
        log.info(" === Portfolio dump end === ");
    }

and uncommented "dumpAccount()" line in "onCandle()". Then it prints current cash balance on every candle. And it seem to follow the position, e.g run ends with the following log entries:

2009-09-03 20:20:16,943 [main] INFO [test.TradeSystemLogic] -  === Portfolio dump start [Account:23456]===
2009-09-03 20:20:16,943 [main] INFO [test.TradeSystemLogic] - balance=-10755.999999999982
2009-09-03 20:20:16,943 [main] INFO [test.TradeSystemLogic] -  === Portfolio dump end ===
2009-09-03 20:20:16,943 [main] INFO [test.MainBacktest] - Backtester completed. Fired 6305 events in 3340 millis

Note non-zero account balance. Are you doing something different?

-Mike

On Mon, Aug 31, 2009 at 5:10 AM, CriC <cristina.colonna@...> wrote:

that's it:

       @Bean
       public IBroker broker() throws Exception {
               PaperBroker paperBroker = new PaperBroker();
               IQuoteSubscriptionSource qs = new
TradeIndicationToQuoteSubscriptionSourceConverter(tradeIndicationSubscriptionSource());
               paperBroker.setQuoteSubscriptionSource(qs);
               AccountManagingBrokerProxy ambp = new
AccountManagingBrokerProxy(paperBroker,
account().getBrokerAccount("PAPER"));
brokerAccount);
               return ambp;
       }

and in the code I Inject the Account bean, it works beacuase I can read the
account ID, but i cannot get the balance.

thks
cric

Ulrich Staudinger-2 wrote:
>
> Hi,
> If i remember correctly, you need to use an AccountManagingBrokerProxy in
> front of the PaperBroker ...
>
> Hth,
> Ulrich
>
>
> On Mon, Aug 31, 2009 at 10:43 AM, CriC <cristina.colonna@...> wrote:
>
>>
>>
>> Hi again :-)
>> No more NPE but I still cant access account properties.
>>
>>        account.getBalanceBook().getCurrentBalance();
>>  Or
>>
>> account.getBrokerAccount("PAPER").getBalanceBook().getCurrentBalance();
>>
>> the balance is always 0.0.
>> I have to wire manually account bean to somethingelse?
>>
>> cric
>>
>>
>> Mike Kroutikov-2 wrote:
>> >
>> > Definitely ExecutionBroker is no good - it seem to be designed to work
>> > only
>> > with LIMIT orders of a special kind. I changed to PaperBroker (which is
>> a
>> > standard broker simulator in AQ), and it seem to be working now. Paper
>> > broker needs quote subscription feed, so I had to add simulated quote
>> > subscription. Check it out (attached). I believe I only changed
>> > YahooBacktestContextConfig.java, but attaching everyhting - just in
>> case.
>> >
>> > By the end of the simulated run you've lost about $12500 - sorry about
>> > that
>> > :-P
>> >
>> > -Mike
>> >
>> >
>>
>> --
>> View this message in context:
>> http://www.nabble.com/BalanceBook--Account--OrderTracker--tp25177571p25220128.html
>> Sent from the ActiveQuant mailing list archive at Nabble.com.
>>
>> _______________________________________________
>> ccapi mailing list
>> ccapi@...
>> http://activestocks.de/cgi-bin/mailman/listinfo/ccapi
>>
>
>
>
> --
> Ulrich B. Staudinger
>
> _______________________________________________
> ccapi mailing list
> ccapi@...
> http://activestocks.de/cgi-bin/mailman/listinfo/ccapi
>
>

--

View this message in context: http://www.nabble.com/BalanceBook--Account--OrderTracker--tp25177571p25220416.html

Sent from the ActiveQuant mailing list archive at Nabble.com.

_______________________________________________
ccapi mailing list
ccapi@...
http://activestocks.de/cgi-bin/mailman/listinfo/ccapi

_______________________________________________
ccapi mailing list
ccapi@...
http://activestocks.de/cgi-bin/mailman/listinfo/ccapi

[Bill Pippin]

Eyon,

Please keep in mind in the following that though I've lurked on
your list for a long time and never posted, I still lack knowledge
of ccapi outside of what little I've learned from skimming the
posts on this list.  In particular, I haven't installed the ccapi
system, or yet read any comprehensive docs from the web site, if
such exist, say from:

http://www.activestocks.eu/?q=wiki/the_activequant_documentation

So, the following is focused on the IB tws api and lacks knowledge
of ccapi.  Also, if what follows is obvious to the developers on
the list, I look forward to reading your comparison/contrast of
these ideas with the ccapi approach.

> I would really like to hear everyone's thoughts on [orphan order
> discovery].  If someone sees an even better way to solve this
> problem please speak up!

I would not have replied to your question, except that you seem to
sincerely want a wide range of input, have posted on this topic
before, and there has been relatively little reply.  What follows
is by no means a complete solution, only some observations.

About unknown orders, perhaps discovered via order status or execution
report messages of the IB tws api:

> I'm still hung up on trying to figure out how AQ can be setup to
> manage executions that don't have a known order.  The only way I've
> seen so far that seems to require the least amount of changes is to
> incorporate the concept of an "orphan order".  The idea would have
> to be implemented by the originating real IBroker.

In brief, the IB tws api puts specific limits on how and what you can
learn about orders, and I've concluded that a useful order manipulating
application for that api, e.g., the trading-shim that I've worked on,
should:

    1.  have a persistent orders journal;
    2.  capture order [PlaceOrder] requests and order messages ---
        status, open, position, and execution --- in denormalized
        form to that journal;
    3.  read the request side of the journal at startup, to allow
        for cross-session order management; and
    4.  require users who wish to work with orders not represented by
        request records to update the journal by adding such records,
        perhaps by mapping an execution report record to a PlaceOrder
        request record or record pair, about which more later.

In the above, by request is meant an event sent to the IB tws api
by the downstream, and message, an event received from the IB tws
api socket.  I realize your system may already provide much of 1 -- 3,
and if so, consider those bullets just context for item (4), which
seems to be what you're considering now.

There are two session level parameters that are critical to
manipulating existing orders correctly, the account code and client
id, the latter also known as the connection id, and it's critical
that these be captured to journal records as well, so that IB tws
api events are not by themselves sufficient to define their related
journal record.  [Recall that, under normal circumstances, account
code, connection id, order id triples uniquely identify an IB tws
api order.]  It's probably obvious that trading system isolation
may be fostered by dedicating specific connection ids to each
trading system, and avoiding connection id 0 except perhaps for a
read-only, no trading role.

One key design choice in the list above is driven by real-world
experience with alternatives; the records for order related messages
from the api should be denormalized, with one event per record,
because it is important for the system to capture all possible orders
data across the api event stream to the journal, and so message
consistency checks must be postponed for later processing.  Although
I prefer to normalize the contract and symbols information elsewhere
in the database, for order events I've found that flat per-event
records are nearly the only way to go.

Recall that I mention above the notion of a order request journal
record pair.  This brings me to the only exception for the journal
flatness rule, the client-originated requests themselves, where it
makes sense to track order creation and modification events
separately, with modification events referring back to the parent
creation event record.  It's convenient as well to factor out various
types of IB-defined order configuration to an order template, and the
order creation event may refer to such a template as well.

Also, since it's awkward for users to track (account code, client id,
order id) triples, I've found it useful to require users to assign a
text key to each order when it's created, and for the trading system,
given the session context of account code and client id, to be
responsible for mapping the text key to the IB tws api order id.

So, I can sum up the process of adding information for an orphan
order, given, e.g., an IB tws api open order or execution report
message, as follows:

    4.1.  require some new user-defined text key, unique across
          existing orders once given the account code and client id;
    4.2.  map order configuration information from the open order or
          execution report message to an order template;
    4.3.  create an order creation record consisting of the account,
          client id, user-defined text key, related IB tws api order
          id index, order template pointer, and contract description,
          where the order id and contract description come directly
          from the open order or execution report message; and
    4.4.  create a dummy order state change record referring back to
          the order creation record from (4.3), to reflect the given
          fact that the order has been submitted to and transmitted
          by the IB tws api, and possibly add other dummy order
          event records as well, if submitted orders do not have a
          start state in your order flow definition.

At this point, and after your app has (re)consulted the journal,
then given that the order is not yet executed, so that your system
originally learned of it via an open order message, an ordinary
modification request may be generated from the create/change info,
and other wise, given an execution report, a related exit order,
e.g., a child limit or stop --- or for that matter an OCA group of
orders sharing the original as a parent --- may be computed by your
app, again using the request-side journal info, and building on
that via its ordinary cross-session exit strategy processing.

I should note that, though the trading-shim takes care of 1 -- 3
above, it doesn't perform any of 4.1 through 4.4.  Since the
latter steps all boil down to database change operations, one
approach is to inflict the effort of 4.1 -- 4.4 on the user, as
responsible for executing the related sql insert statements once
an orphan order has been recognized.  Presumably requiring such
effort would reduce the frequency and likelihood of orphan orders.

By the way, with respect to order state, and:

    http://activestocks.de/?q=wiki/order_state_flow

I'd like to mention that an alternative is to keep the states
identified above for the request side of the journal, and also, for
the case where an order has been sent to and received by the IB tws,
so that status messages or other messages have occurred, to track
the IB tws api order states that they define and send as well.

The states that may be indicated via IB tws api messages are,
according to their documentation, the following:

    IB tws api          corresponding ccapi order state flow
    ------------        ------------------------------------
    PreSubmitted        Processing?
    Submitted           Processing?
    Cancelled           Cancelled
    Filled              Filled
    Inactive            Expired?

Although they define two other states, PendingSubmit and
PendingCancel, these map directly to states you've defined on
the request side of journalled order state, and since they can't
occur in order messages, may reasonably be ignored.  You also
may want to supplement your request-side order flow states with
some notion of a flag for the place order request transmit/not
yet released flag, since it makes sense to stage orders, let them
pass any initial server-side checks by IB, and then modify/submit
in response to events.  This two-stage processing is particularly
useful for bracket orders.  I realize this last may be too IB tws
api specific, just mentioning it.

Thanks,

Bill Pippin

_______________________________________________
ccapi mailing list
ccapi@...
http://activestocks.de/cgi-bin/mailman/listinfo/ccapi

[CriC]

Mike,

I still got 0.0 :-(

2009-09-04 12:22:34,264 [main] INFO [TradeSystemLogic] -  === Portfolio dump start [Account:23456]===
2009-09-04 12:22:34,264 [main] INFO [TradeSystemLogic] - balance=0.0
2009-09-04 12:22:34,264 [main] INFO [TradeSystemLogic] -  === Portfolio dump end ===
2009-09-04 12:22:34,264 [main] INFO [MainBacktest] - Backtester completed. Fired 1261 events in 2672 millis

And the only thing different from your code and mine is this:
activequant-packages-1.0-SNAPSHOT-jar-with-dependencies.jar
created 17/08/2009  ( 38.418K )

It might be the problem...

:-)
thank you!

Mike Kroutikov-2 wrote:

Cric,

I do not see a problem. I changed TradeSystemLogic.java to add current
balance info to dumpAccount():

    public void dumpAccount(Account account){
        assert(account!=null);
        // dump out portfolio
        log.info(" === Portfolio dump start [Account:"+account.getId()+"]===
");
        Portfolio p = account.getPortfolio();
        for(Position pos : p.getPositions()){
            log.info(pos.toString());
        }
        double balance =
account.getBrokerAccount("PAPER").getBalanceBook().getCurrentBalance();
        log.info("balance=" + balance);
        log.info(" === Portfolio dump end === ");
    }

and uncommented "dumpAccount()" line in "onCandle()". Then it prints current
cash balance on every candle. And it seem to follow the position, e.g run
ends with the following log entries:

2009-09-03 20:20:16,943 [main] INFO [test.TradeSystemLogic] -  === Portfolio
dump start [Account:23456]===
2009-09-03 20:20:16,943 [main] INFO [test.TradeSystemLogic] -
balance=-10755.999999999982
2009-09-03 20:20:16,943 [main] INFO [test.TradeSystemLogic] -  === Portfolio
dump end ===
2009-09-03 20:20:16,943 [main] INFO [test.MainBacktest] - Backtester
completed. Fired 6305 events in 3340 millis

Note non-zero account balance. Are you doing something different?

-Mike

On Mon, Aug 31, 2009 at 5:10 AM, CriC <[e-mail]> wrote:

>
> that's it:
>
>        @Bean
>        public IBroker broker() throws Exception {
>                PaperBroker paperBroker = new PaperBroker();
>                IQuoteSubscriptionSource qs = new
>
> TradeIndicationToQuoteSubscriptionSourceConverter(tradeIndicationSubscriptionSource());
>                paperBroker.setQuoteSubscriptionSource(qs);
>                AccountManagingBrokerProxy ambp = new
> AccountManagingBrokerProxy(paperBroker,
> account().getBrokerAccount("PAPER"));
> brokerAccount);
>                return ambp;
>        }
>
> and in the code I Inject the Account bean, it works beacuase I can read the
> account ID, but i cannot get the balance.
>
> thks
> cric
>
>
>
> Ulrich Staudinger-2 wrote:
> >
> > Hi,
> > If i remember correctly, you need to use an AccountManagingBrokerProxy in
> > front of the PaperBroker ...
> >
> > Hth,
> > Ulrich
> >
> >
> > On Mon, Aug 31, 2009 at 10:43 AM, CriC <[e-mail]> wrote:
> >
> >>
> >>
> >> Hi again :-)
> >> No more NPE but I still cant access account properties.
> >>
> >>        account.getBalanceBook().getCurrentBalance();
> >>  Or
> >>
> >> account.getBrokerAccount("PAPER").getBalanceBook().getCurrentBalance();
> >>
> >> the balance is always 0.0.
> >> I have to wire manually account bean to somethingelse?
> >>
> >> cric
> >>
> >>
> >> Mike Kroutikov-2 wrote:
> >> >
> >> > Definitely ExecutionBroker is no good - it seem to be designed to work
> >> > only
> >> > with LIMIT orders of a special kind. I changed to PaperBroker (which
> is
> >> a
> >> > standard broker simulator in AQ), and it seem to be working now. Paper
> >> > broker needs quote subscription feed, so I had to add simulated quote
> >> > subscription. Check it out (attached). I believe I only changed
> >> > YahooBacktestContextConfig.java, but attaching everyhting - just in
> >> case.
> >> >
> >> > By the end of the simulated run you've lost about $12500 - sorry about
> >> > that
> >> > :-P
> >> >
> >> > -Mike
> >> >
> >> >
> >>
> >> --
> >> View this message in context:
> >>
> http://www.nabble.com/BalanceBook--Account--OrderTracker--tp25177571p25220128.html
> >> Sent from the ActiveQuant mailing list archive at Nabble.com.
> >>
> >> _______________________________________________
> >> ccapi mailing list
> >> [e-mail]
> >> http://activestocks.de/cgi-bin/mailman/listinfo/ccapi
> >>
> >
> >
> >
> > --
> > Ulrich B. Staudinger
> >
> > _______________________________________________
> > ccapi mailing list
> > [e-mail]
> > http://activestocks.de/cgi-bin/mailman/listinfo/ccapi
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/BalanceBook--Account--OrderTracker--tp25177571p25220416.html
> Sent from the ActiveQuant mailing list archive at Nabble.com.
>
> _______________________________________________
> ccapi mailing list
> [e-mail]
> http://activestocks.de/cgi-bin/mailman/listinfo/ccapi
>

_______________________________________________
ccapi mailing list
[e-mail]
http://activestocks.de/cgi-bin/mailman/listinfo/ccapi

[Kirill Jacobson]

CriC,

Would you be kind to post your code here as an attachment? I am at the beginning of the path that you just have finished and your code could save me a lot of grief. Unfortunately the learning curve for this project is very and  I haven't got beyond compiling the code and running the sample with a mock provider.

Thank you,
Kirill

CriC wrote:

_______________________________________________
ccapi mailing list
[e-mail]
http://activestocks.de/cgi-bin/mailman/listinfo/ccapi

[eland]

Some parts of this message have been removed. Learn more about Nabble's security policy.

Yes,

I’m trying to capture orders and watch positions that have been entered by hand on TWS.  Here’s an attempt for a use case:

 

Goal

To leverage a TradingSystem that is able to execute trades from event changes in the actual position in addition to the events generated from quotes and trade indications.

 

Summary

The idea is to allow for users to quickly put on a trade externally and allow the system to watch for exit strategy.   The need for such a system is primarily for risk control.    Let’s say that news is pending that might move a currency strongly in a particular direction.    Entry on the trade is determined by the headlines of the event and is manually entered.  Once entered, the desired exit strategy is too complex and cannot be implemented on the user’s broker provided GUI.  Here comes active quant to the rescue to help the user get out of the trade at a maximum profit.

 

Actors

The AQ implementation.  The trader.  The external broker provided GUI.

 

Preconditions

The trade must have been entered external to AQ.

 

Triggers

When the “rogue execution” appears to the source IBroker implementation

 

Basic course of events

1.       The risk conrol and optimal exit strategy algorithm is implemented in AQ and running.

2.       The user enters the trade on the desired direction immediately after the news arrives.

3.       The AQ code receives the changes to the position and monitors the quotes and trades on the events.

4.       The AQ code exists the code appropriately.

 

 

 

Does this help?  Thanks everyone for considering this special case!

Eyon

 

 

From: ccapi-bounces@... [mailto:ccapi-bounces@...] On Behalf Of Mike Kroutikov
Sent: Thursday, September 03, 2009 7:11 PM
To: ccapi2 and activeQuant discussion list
Subject: Re: [ccapi] The concept of orphan orders and rogue executions...

 

Eyon,

I do not get it. How IB can have "orphan executions"? Do you want to support tracking of orders entered "by hand" into TWS?
What is the use case?

-Mike

On Thu, Sep 3, 2009 at 6:04 PM, Eyon Land <ELand@...> wrote:

I'm still hung up on trying to figure out how AQ can be setup to manage executions that don't have a known order.  The only way I've seen so far that seems to require the least amount of changes is to incorporate the concept of an "orphan order".  The idea would have to be implemented by the originating real IBroker.  (See IBBroker.java attached for an example.)

I would really like to hear everyone's thoughts on this.  If someone sees an even better way to solve this problem please speak up!

Thanks in advance for everyone's input.

Eyon


Confidentiality Statement:
This message is confidential and may contain confidential information it is intended only for the individual[s] named herein. If this message is being sent from a member of the legal department, it may also be legally privileged.   If you are not the named addressee[s] you must delete this email immediately; do not disseminate, distribute or copy.

STATEMENT OF CONFIDENTIALITY: This message and any attachments are intended solely for the person or entity to which it is addressed and may contain confidential or privileged information. If the recipient of this message is not the addressee or a person responsible for delivering the message to the addressee, such recipient is prohibited from reading or using this message in any way. If you have received this message in error, please call the sender of this message immediately and delete the message from any computer.

_______________________________________________
ccapi mailing list
ccapi@...
http://activestocks.de/cgi-bin/mailman/listinfo/ccapi

 

Confidentiality Statement:
This message is confidential and may contain confidential information it is intended only for the individual[s] named herein. If this message is being sent from a member of the legal department, it may also be legally privileged. If you are not the named addressee[s] you must delete this email immediately; do not disseminate, distribute or copy.

STATEMENT OF CONFIDENTIALITY: This message and any attachments are intended solely for the person or entity to which it is addressed and may contain confidential or privileged information. If the recipient of this message is not the addressee or a person responsible for delivering the message to the addressee, such recipient is prohibited from reading or using this message in any way. If you have received this message in error, please call the sender of this message immediately and delete the message from any computer.

_______________________________________________
ccapi mailing list
ccapi@...
http://activestocks.de/cgi-bin/mailman/listinfo/ccapi

[eland]

Thanks for the detailed feedback!

I have implemented a system (not using ccapi) that is capable of pulling in executions from TWS and from a FIX connection provided by IB.  The TWS connection and the FIX connection provided redundant information in the event that one failed.  I mention this to expand on your thoughts below about creating what I've come to know as a "business key".  IN a FIX based system you typically use the account, execution id, trade date and source to uniquely identify the execution and prevent duplications.  The TWS Api provides the execution id in com.ib.client.Execution.m_execId and this will/should correspond to the actual FIX message should they give you a drop copy.  Source was something I would configure in xml that was simply an extra unique string that helped ensure that the TWS connection and the FIX connection were associated.  In other words, they had the same source string.

ccapi (what I had been calling AQ) depends on a key called a "brokerAssignedId" to uniquely identify and track the order and subsequent execution events.  Obviously it uses the order id, but perhaps it should also include the account, source and order date as well.

I mention these as candidates for the business key(s) rather than the ones you mentioned below simply because I've found them in many systems.  For example, I've only heard of a connection id with respect to TWS.  There is no direct equivalent (to my knowledge) in a FIX based system.


One thing to point out, is that Object Oriented Programming often provides the latitude to avoid extensive use of business keys by using composition.  For example, ccapi knows about account, which knows about the order (and order date), which knows about the execution event (and its trade date).  The only missing piece is really the execution id to help uniquely identify the execution event within the context of the order and catch duplication (For example when the system is trying to recover from an unexpected prior termination.)

More thoughts later...
Eyon


-----Original Message-----
From: ccapi-bounces@... [mailto:ccapi-bounces@...] On Behalf Of Bill Pippin
Sent: Thursday, September 03, 2009 8:41 PM
To: ccapi2 and activeQuant discussion list
Subject: Re: [ccapi] The concept of orphan orders and rogue executions...

Eyon,

Please keep in mind in the following that though I've lurked on
your list for a long time and never posted, I still lack knowledge
of ccapi outside of what little I've learned from skimming the
posts on this list.  In particular, I haven't installed the ccapi
system, or yet read any comprehensive docs from the web site, if
such exist, say from:

http://www.activestocks.eu/?q=wiki/the_activequant_documentation

So, the following is focused on the IB tws api and lacks knowledge
of ccapi.  Also, if what follows is obvious to the developers on
the list, I look forward to reading your comparison/contrast of
these ideas with the ccapi approach.

> I would really like to hear everyone's thoughts on [orphan order
> discovery].  If someone sees an even better way to solve this
> problem please speak up!

I would not have replied to your question, except that you seem to
sincerely want a wide range of input, have posted on this topic
before, and there has been relatively little reply.  What follows
is by no means a complete solution, only some observations.

About unknown orders, perhaps discovered via order status or execution
report messages of the IB tws api:

> I'm still hung up on trying to figure out how AQ can be setup to
> manage executions that don't have a known order.  The only way I've
> seen so far that seems to require the least amount of changes is to
> incorporate the concept of an "orphan order".  The idea would have
> to be implemented by the originating real IBroker.

In brief, the IB tws api puts specific limits on how and what you can
learn about orders, and I've concluded that a useful order manipulating
application for that api, e.g., the trading-shim that I've worked on,
should:

    1.  have a persistent orders journal;
    2.  capture order [PlaceOrder] requests and order messages ---
        status, open, position, and execution --- in denormalized
        form to that journal;
    3.  read the request side of the journal at startup, to allow
        for cross-session order management; and
    4.  require users who wish to work with orders not represented by
        request records to update the journal by adding such records,
        perhaps by mapping an execution report record to a PlaceOrder
        request record or record pair, about which more later.

In the above, by request is meant an event sent to the IB tws api
by the downstream, and message, an event received from the IB tws
api socket.  I realize your system may already provide much of 1 -- 3,
and if so, consider those bullets just context for item (4), which
seems to be what you're considering now.

There are two session level parameters that are critical to
manipulating existing orders correctly, the account code and client
id, the latter also known as the connection id, and it's critical
that these be captured to journal records as well, so that IB tws
api events are not by themselves sufficient to define their related
journal record.  [Recall that, under normal circumstances, account
code, connection id, order id triples uniquely identify an IB tws
api order.]  It's probably obvious that trading system isolation
may be fostered by dedicating specific connection ids to each
trading system, and avoiding connection id 0 except perhaps for a
read-only, no trading role.

One key design choice in the list above is driven by real-world
experience with alternatives; the records for order related messages
from the api should be denormalized, with one event per record,
because it is important for the system to capture all possible orders
data across the api event stream to the journal, and so message
consistency checks must be postponed for later processing.  Although
I prefer to normalize the contract and symbols information elsewhere
in the database, for order events I've found that flat per-event
records are nearly the only way to go.

Recall that I mention above the notion of a order request journal
record pair.  This brings me to the only exception for the journal
flatness rule, the client-originated requests themselves, where it
makes sense to track order creation and modification events
separately, with modification events referring back to the parent
creation event record.  It's convenient as well to factor out various
types of IB-defined order configuration to an order template, and the
order creation event may refer to such a template as well.

Also, since it's awkward for users to track (account code, client id,
order id) triples, I've found it useful to require users to assign a
text key to each order when it's created, and for the trading system,
given the session context of account code and client id, to be
responsible for mapping the text key to the IB tws api order id.

So, I can sum up the process of adding information for an orphan
order, given, e.g., an IB tws api open order or execution report
message, as follows:

    4.1.  require some new user-defined text key, unique across
          existing orders once given the account code and client id;
    4.2.  map order configuration information from the open order or
          execution report message to an order template;
    4.3.  create an order creation record consisting of the account,
          client id, user-defined text key, related IB tws api order
          id index, order template pointer, and contract description,
          where the order id and contract description come directly
          from the open order or execution report message; and
    4.4.  create a dummy order state change record referring back to
          the order creation record from (4.3), to reflect the given
          fact that the order has been submitted to and transmitted
          by the IB tws api, and possibly add other dummy order
          event records as well, if submitted orders do not have a
          start state in your order flow definition.

At this point, and after your app has (re)consulted the journal,
then given that the order is not yet executed, so that your system
originally learned of it via an open order message, an ordinary
modification request may be generated from the create/change info,
and other wise, given an execution report, a related exit order,
e.g., a child limit or stop --- or for that matter an OCA group of
orders sharing the original as a parent --- may be computed by your
app, again using the request-side journal info, and building on
that via its ordinary cross-session exit strategy processing.

I should note that, though the trading-shim takes care of 1 -- 3
above, it doesn't perform any of 4.1 through 4.4.  Since the
latter steps all boil down to database change operations, one
approach is to inflict the effort of 4.1 -- 4.4 on the user, as
responsible for executing the related sql insert statements once
an orphan order has been recognized.  Presumably requiring such
effort would reduce the frequency and likelihood of orphan orders.

By the way, with respect to order state, and:

    http://activestocks.de/?q=wiki/order_state_flow

I'd like to mention that an alternative is to keep the states
identified above for the request side of the journal, and also, for
the case where an order has been sent to and received by the IB tws,
so that status messages or other messages have occurred, to track
the IB tws api order states that they define and send as well.

The states that may be indicated via IB tws api messages are,
according to their documentation, the following:

    IB tws api          corresponding ccapi order state flow
    ------------        ------------------------------------
    PreSubmitted        Processing?
    Submitted           Processing?
    Cancelled           Cancelled
    Filled              Filled
    Inactive            Expired?

Although they define two other states, PendingSubmit and
PendingCancel, these map directly to states you've defined on
the request side of journalled order state, and since they can't
occur in order messages, may reasonably be ignored.  You also
may want to supplement your request-side order flow states with
some notion of a flag for the place order request transmit/not
yet released flag, since it makes sense to stage orders, let them
pass any initial server-side checks by IB, and then modify/submit
in response to events.  This two-stage processing is particularly
useful for bracket orders.  I realize this last may be too IB tws
api specific, just mentioning it.

Thanks,

Bill Pippin

_______________________________________________
ccapi mailing list
ccapi@...
http://activestocks.de/cgi-bin/mailman/listinfo/ccapi

Confidentiality Statement:
This message is confidential and may contain confidential information it is intended only for the individual[s] named herein. If this message is being sent from a member of the legal department, it may also be legally privileged.   If you are not the named addressee[s] you must delete this email immediately; do not disseminate, distribute or copy.
STATEMENT OF CONFIDENTIALITY: This message and any attachments are intended solely for the person or entity to which it is addressed and may contain confidential or privileged information. If the recipient of this message is not the addressee or a person responsible for delivering the message to the addressee, such recipient is prohibited from reading or using this message in any way. If you have received this message in error, please call the sender of this message immediately and delete the message from any computer.
_______________________________________________
ccapi mailing list
ccapi@...
http://activestocks.de/cgi-bin/mailman/listinfo/ccapi