How to club stop order and limit order in to one group

My order submission code looks like this :
==========================
mainOrder = cxt.createStopOrder(entryOrderAction, TIF.GTC, qty, entryPoint);

stoploss = cxt.createStopOrder(mainOrder.getOrderId(), exitOrderAction, TIF.GTC, qty, stopLossVal);
target = cxt.createLimitOrder(mainOrder.getOrderId(), exitOrderAction, TIF.GTC, qty, takeProfitVal);

cxt.submitOrders(mainOrder, stoploss, target);
==========================

This works well on simulation
 
I believe you need to this in an event-driven manner. Submit the entry order. Then, onOrderFiIled, get the order.getOrderID and submit the other stoploss and target orders. Annpying;y it doesn't seem to work as a single oco submission for Rithmic. Though I see you are using CQG. Unfortunatley, this won't be testable until the futures market reopens on Sunday evening.
I'm not 100% sure wherer we should be using Order.getOrderId or Order.getReferenceId. There is a warnign in the docs that the referenceId can change with some providers @Spin any idea?
 
@pandalover Thanks for your reply. There is a reason I wanted to do single OCO. As of what I observed, if we do event driven then there is a slight delay when onOrderFilled gets called and actual filling of the order. That is not ideal.
But, I understand what you are saying, if OCO is not working then will have to go with event driven manner.
 
@John A it's not ideal but I haven't ofudn a way to simply use an OCO order directly against a Rithmic broker. I fell back to the event driven manner about a year ago.
 
View attachment 2993

@Spin looks like not:( this is probably the reason why. What I don't understand is that whenever I place orders by hand with brackets enabled I can see the grouping, so clearly motivewave does something that makes it work. Don't really understand why hedging support is a requirement for order grouping, but I just wanted to achieve the same thing with a strategy since doing it by hand is possible :D
@gk1101 were you able to resolve this issue?
 
@John A it's not ideal but I haven't ofudn a way to simply use an OCO order directly against a Rithmic broker. I fell back to the event driven manner about a year ago.
alright. I am waiting for reply from cqg. lets see what hey have to say. Else, I will move to the event driven thing only.
 
I think the answer from CQG may not be relevant. Rithmic also supports submittal of OCO in 1 step. The issue is MotiveWave's SDK. I think I could submit directly to Rithmic using their API direct API.
 
try Order.orderId and Order.getReferenceId. In the case of referenceId it can change depending on the broker so I would suggest trying both methods against your broker to make sure. Either way it should be fine as long as you are using the order passed in Study.onOrderFilled but you may want to check (its been a while). Make sure to check the properties of Order to make sure that you are properly handling partial fills as well.
 
@gk1101 were you able to resolve this issue?
Unfortunately I was not. https://www.motivewave.com/sdk/java...rder_mgmt/OrderContext.html#supportsHedging() was returning false and I figured that's why I wasn't able to create OCO orders. But it makes no sense because manually OCO orders are created just fine (and I could see them on rithmic side, so they were not fake OCO orders). So I agree something's not right with motivewave sdk, but it's extremely unlikely they're gonna fix it
 
Unfortunately I was not. https://www.motivewave.com/sdk/java...rder_mgmt/OrderContext.html#supportsHedging() was returning false and I figured that's why I wasn't able to create OCO orders. But it makes no sense because manually OCO orders are created just fine (and I could see them on rithmic side, so they were not fake OCO orders). So I agree something's not right with motivewave sdk, but it's extremely unlikely they're gonna fix it
Thanks for the update. So, I will be using even-driven method as suggested by pandalover earlier.
 
Last edited:
Top