Hello,

In global mode account the IEngine getOrders() list is out of sync when a position is entered.

The result when the attached strategy run on a flat, global mode account:
09:27:09 Orders:0
09:27:09 Order filled
09:27:09 IsGlobal:true


If I run the same strategy on a flat, hedge mode account, the getOrders() list is in sync:
09:27:10 Orders:1
09:27:10 Order filled
09:27:10 IsGlobal:false

Stassen

Does the getOrders() behaviour on global account acknowledged as a bug?
If yes , when the fix will be available?

Thanks,
Stassen

the issue is under investigation.

This is not a bug, this is according to the Global account order/position workflow - we have drawn a diagram for this, see the "Global" tab here:
https://www.dukascopy.com/wiki/#Order_state/Market_order_states_diagram

If this is not a bug , then how can I query the account position in real time?
The strategy that run properly on hedge mode is break apart in global mode because of this.

Regards,
Stassen

The following way:

package jforex.orders;

import com.dukascopy.api.*;

public class GlobalAccountInstrumentPosition implements IStrategy {

    private IEngine engine;  
    private IConsole console;
    private IContext context;

    @Override
    public void onStart(IContext context) throws JFException {
        engine = context.getEngine();
        console = context.getConsole();
        this.context = context;
    }

    @Override
    public void onTick(Instrument instrument, ITick tick) throws JFException {}

    @Override
    public void onBar(Instrument instrument, Period period, IBar askBar, IBar bidBar) throws JFException {
        if(instrument!= Instrument.EURUSD || period !=Period.TEN_SECS){
            return;
        }
        for(Instrument i : context.getSubscribedInstruments()){
            for(IOrder order : engine.getOrders(i)){
               //Instrument position is a fully filled IOrder available from IEngine.getOrders
                if(order.getState() == IOrder.State.FILLED 
                        && Double.compare(order.getRequestedAmount(), order.getAmount()) == 0
                ){
                    console.getInfo().format("%s position=%s", i, order).println();
                    break;
                }
            }
            
        }
    }

    @Override
    public void onMessage(IMessage message) throws JFException {
        IOrder order = message.getOrder();
        if(order != null 
                && order.getState() == IOrder.State.FILLED 
                && message.getType() == IMessage.Type.ORDER_CHANGED_OK
                && Double.compare(order.getRequestedAmount(), order.getAmount()) == 0
        ){
            console.getOut().format("%s position updated", order).println();
        }
    }

    @Override
    public void onAccount(IAccount account) throws JFException {
    }

    @Override
    public void onStop() throws JFException {
    }

}

Since when onBar update is real time?
Even if the position query would be in ontick , the event driven control flow is broken.
If you can not sync up the getOrders(), I suggest a getGlobalPosition() method , callable from onMessage.

The onBar implementation is an additional summary information - simply remove this if you don't need this. Did you have a look at the onMessage implementation?
Please specify what you can't achieve with the current JForex-API functionality.

As per stassen's original post and thread found here - Post subject: Net mode account

He is claiming that IEngine.getOrders() does not maintain a consistent state within a GLOBAL ACCOUNT when called as below from onMessage such that he is unable to obtain the very order provided by message.getOrder() [state==FILLED] by calling engine.getOrders():

public void onMessage(IMessage message) throws JFException
{
    if (message.getType() == IMessage.Type.ORDER_FILL_OK)
    {
        // order just filled
        IOrder orderJustFilled = message.getOrder();

        // obtain list of filled orders from IEngine while within onMesage() - (GLOBAL ACCOUNT CASE)
        List orders = engine.getOrders();

        // search list of filled orders for the order we were just informed was filled
        for(IOrder ordersFound : orders)
        {
           if(ordersFound == orderJustFilled)
           {
               System.out.println(" *** He claims this will never be outputted while running under a GLOBAL ACCOUNT *** ");
           }
        }
    }
}

I did request his further assistance in the 'Net mode account' thread but his tests and experimentation have convinced him that the above usecase is buggy.

We reiterate that global accounts have different order logic. Hence, different order update sequence. In particular - full fill is the "end of life" of an entry order's IOrder object - it does not "become" a position as it is in hedged account case. The instrument position's update arrives just after each entry order's fill and that is another object.

I understand the point you reiterate above.

You are able to fully conclude this discussion now spanning two threads and approximately one month by using your intimate knowledge of the order sequence logic to elaborate on this "other object".

If you examine the end of the conversation in the thread I have referenced, you will see a clear request for clarification with respect to how it is one is able to capture/observe the existing position (or indeed position update object/information as it may be the case). You will note my enthusiasm to help resolve his desire to progress using the platform but you here confirm that the information I provided for him isn't accurate (namely that engine.getOrders() will access open filled positions in ALL cases - the javadoc doesn't indicate otherwise).

stassen clearly indicates that while using a Global Account, he is able to capture order entries with no problem.

His main query (as it is now mine since I am now also confused) is:

How do you obtain access to the existing POSITION (or indeed "position update" information) while using the API under a GLOBAL account if a Position as such isn't accessible via engine.getOrders() ?

In the Global diagram 'Instrument's position amount changes -> ORDER_CHANGED_OK' makes logical sense, as does 'Instrument's Position is always filled. if it's amount is 0, position is not among engine.getorders()' but the query is for insight at the code level to correctly capture the "position information" as he is unable to do so while amount is > 0. The onMessage() implementation above makes sense and follows the Global diagram.

The onBar() implementation calls engine.getOrders(), checks FILLED and requested amount == amount and this is the "position". But he is getting '0' orders in that order list.

This topic didn't have to progress to a 'bug report' and I suspected before posting there is no bug just a lack of information (which is why I pressed stassen for more information at the end of that thread to help draw out the eventual conclusion). Anyone viewing the referenced thread can see it remains unresolved as per the main query there.

Above you have mentioned "another object" but you must try to appreciate that you are the ones with the intimate knowledge not us, so it can be truly helpful/beneficial to elaborate liberally towards full conclusion allowing users to move on and progress with the platform instead of having their "issues"/"doubts" persist almost 1 month later.

I do truly appreciate the scale of demand Support resources face and it's extremely clear the job you guys do is EXCEPTIONAL - I defy anyone to identify a stronger technical support team anywhere in the industry.

But I also truly appreciate how debilitating it can be to end-user productivity to have a key concern not find a satisfactory answer from within the only forum we JForex users can turn to when we are at a loss.

As soon as the instrument's position amount > 0, it becomes accessible.
Our example shows how to do that.
You are now mixing up our example and his - our example only considers instrument's position while his works with both entry orders and instrument positions. As we already said in our previous post - the entry order fill is as follows:

1. Entry order gets fully FILLED - this is the "end of life" of it and it "disappears" from the IEngine.getOrders().
2. IEngine.getOrders().size()==0 because the instrument's position update is yet to arrive.
3. Instrument's position update arrives and IEngine.getOrders().size()==1.

Please suggest what kind of additional documentation would be required to help grasp the idea of the global account order workflow logic.

The post above this one, in addition to your code sample PLUS the "GLOBAL ORDER FLOW DIAGRAM" in my mind now constitute adequate explanation and elaboration on what is going on in the GLOBAL ACCOUNT case and how it is one is able to maintain or get a hold on the existing "position". Specifically that any call to engine.getOrders() can be premature if such a call is associated with ORDER_FILL events prior to position update events.

Your code sample now makes 100% sense. With some additional comments the above code sample alone would assist someone new to the thread in understanding what is happening.

Your onMessage() clearly demonstrates how to capture the "position change" event that occurs following the "order fill" event.

The onBar() most people know can be called before and after the calls to onMessage() so without extra commenting it is not clear studying the code sample alone (without running it) that the output in onBar() i.e. engine.getOrders() actually returning something, will only take place after the corresponding "position change" event being received in onMessage(). Of course subsequent to that, the onBar() output will continue to show the position until it's end of life.

The primary reference for me are the JavaDocs. They are very good but also don't reveal some of the intricacies for example covered in this discussion. I'm not suggesting any changes however, just trying to explain where doubts and false expectations around the API begin.

I'm very slow on friday mornings and I get everything 100% now. I'm willing to bet that stassen now considers his original query answered although I do not want to speak for him.

Having benefited from excellent Support yet again, I will update the other thread to reflect the facts and link the Order Flow Diagrams so hopefully anyone else searching will be able to expedite their knowledge gathering and progress their use of the API and platform.

I can't access the filled order from the ORDER_CHANGED_OK

The print shows that the message.getOrder() contains the account position , and not the order.

Here is a simple code snippet:

  

    public void onStart(IContext context) throws JFException 
    {
        this.engine = context.getEngine();
        this.console = context.getConsole();
        this.history = context.getHistory();
        this.context = context;
        this.indicators = context.getIndicators();
        this.userInterface = context.getUserInterface();
        this.account=context.getAccount();
        
        console.getOut().println("IsGlobal:"+account.isGlobal());  
        engine.submitOrder("order1", Instrument.EURUSD,IEngine.OrderCommand.BUY,0.1);
         
    }

  public void onMessage(IMessage message) throws JFException
    {     
        if (message.getType() == IMessage.Type.ORDER_CHANGED_OK)
        {
           console.getOut().println(message.getOrder().toString());
        }
    }

and the result is:
12:57:11 [691270EUR/USD]-FILLED / EUR/USD / 1.35621 / 0.1 / 0.1
12:57:09 IsGlobal:true

The label clearly shows that this is not the filled order.

Regards,
Stassen

Stassen, sir, you haven't been paying attention

Run your example again and keep everything you have up there but this time include a separate conditional check and output for ORDER_FILLED_OK within onMessage()

That LABEL you see 691270EUR/USD is a system label holding your active position in EURUSD. If you buy more (add to the position) or sell more (subtract from the position) that position in EURUSD is the one that is affected.

The actual Orders you are generating in submitOrder() with your own labels, those orders DIE after they are filled.

So given what you have above. If you submitted "order2" for another 0.1.

The ORDER_CHANGED_OK would output the same position it did the first time, but you would see 0.2 (total position exposure based on previous two orders).

Your "order1" and "order2" after this point would be gone and their labels with them.

Go back to the thread in which we started where I mention that you can have 100 orders ('order1' to 'order100') all serving to add to or subtract from the open position ('691270EUR/USD'). The position ('691270EUR/USD') is created with the order creating initial exposure to the currency.

Allow us to revisit the workflow one more time:

1. Entry order gets fully FILLED - this is the "end of life" of it and it "disappears" from the IEngine.getOrders(). The message will be ORDER_FILLED_OK.
2. For a moment IEngine.getOrders().size()==0 because the instrument's position update is yet to arrive.
3. Instrument's position update arrives. Only now the message will be ORDER_CHANGED_OK.
4. And now IEngine.getOrders().size()==1.

Hence, you need to access the filled entry order when processing the ORDER_FILLED_OK messages.