API Support Forum
OEC API > API Support > Seeking options best practices or example
Author Topic: Seeking options best practices or example
(13 messages, Page 1 of 1)
Moderators: VPfau
jlanawalt
Posts: 88
Joined: Feb 12, 2009


Posted: Apr 05, 2012 @ 01:48 PM             Msg. 1 of 13
We've been experimenting with the Options portions of the OEC One Link COM API and trying to get our heads around the best way to work with it. Our only reference I've seen is how you deal with them in OEC Trader.

In OEC Trader we use the options chain tool. It appears to find the strikes for the nearest to expire month and subscribes to the "near" ones pretty quickly.


    Somehow convert ES to OES
    RequestContracts(OES)
    Calculate "near" window
    Subscribe(OESJ2 C|P"near") // in loop


If I switch to Range:All it seems to already know what all the other available strikes are, and as I scroll up or down prices fill in. If I make the window too tall, I get a system error for my subscription limit. This makes it appear that as I slide up and down and pause the software is subscribing to the newly visible strikes and unsubscribing from the ones that are no longer visible. It seems I can scroll up and down a lot without any errors like "too many requests" and I never get the subscription limit error unless my window is tall.


    Unsubscribe(options no longer on screen, eg OESJ2 C1380) // in loop
    Subscribe(options now on screen, eg OESJ2 P1405) // in loop



Is this basically the way it works and the way the API is designed to handle it?
DmitriyG
Posts: 9
Joined: Oct 26, 2011


Posted: Apr 05, 2012 @ 02:22 PM             Msg. 2 of 13
Yes, you understand the logic right.

API does not subscribe automatically to option chain prices for requested base, you need to manage it manually.

Dmitriy Gorbachyov
jlanawalt
Posts: 88
Joined: Feb 12, 2009


Posted: Apr 05, 2012 @ 03:02 PM             Msg. 3 of 13
What if I were to leave the Options Chain window open for a long time and the market moves. Might not new strikes be added if we are in a long upward or downward trend?

How often would you re-request contracts?
DmitriyG
Posts: 9
Joined: Oct 26, 2011


Posted: Apr 05, 2012 @ 03:57 PM             Msg. 4 of 13
Just subscribe to OECClient.OnContractsChanged and check if needed option base is updated.

Dmitriy Gorbachyov
jlanawalt
Posts: 88
Joined: Feb 12, 2009


Posted: Apr 05, 2012 @ 04:46 PM             Msg. 5 of 13
Ah. We hadn't expected that since it is RequestContracts and not SubscribeContracts (with a corresponding UnsubscribeContracts). We expected that we were just getting the "right now" list when we would request contracts.

We of course get the results of RequestContracts from OnContractsChanged currently. Thank you.
jlanawalt
Posts: 88
Joined: Feb 12, 2009


Posted: Apr 05, 2012 @ 04:49 PM             Msg. 6 of 13
> Somehow convert ES to OES

Currently we do this by having a hard coded map. Is there anything in the API to do the same, to figure out the options BaseContract symbol from a given futures BaseContract symbol?
DmitriyG
Posts: 9
Joined: Oct 26, 2011


Posted: Apr 05, 2012 @ 05:00 PM             Msg. 7 of 13
Try something like:

var criteria = new API.SymbolLookupCriteria();
criteria.DesiredResultCount = 1;
criteria.Mode = SymbolLookupMode.ExactMatch;
criteria.OptionsRequired = true;
criteria.SearchText = "ES";
OECClient.Global.SymbolLookup(criteria);


Dmitriy Gorbachyov
jlanawalt
Posts: 88
Joined: Feb 12, 2009


Posted: Apr 05, 2012 @ 05:58 PM             Msg. 8 of 13
Thank you, I will give that a try. I hadn't played with the SymbolLookupCriteria.

We would like to bulk-load initial quotes for all the strikes. Our current method is to look at the Count of our current Subscriptions list, subtract off a buffer, and then Subscribe to a bunch at once. As the responses come back in OnPriceChanged, we Unsubscribe and then subscribe to another strike in our list of pending strikes to update or refresh. This mostly works, except when we get "Too many requests" and sometimes hit the subscription limit despite attemping to stay under it with a buffer. If we don't get a response back, our "try the next one" isn't triggered.

Is there a better way to bulk-load?

Do you foresee other issues with this way getting an initial view of the data?

Do you asynchronously subscribe to a bunch as the options chain window slides up or down or do you go one at a time (triggering the next request off of the completion of the previous)?
Edited by jlanawalt on Apr 5, 2012 at 18:56:05
DmitriyG
Posts: 9
Joined: Oct 26, 2011


Posted: Apr 09, 2012 @ 12:00 PM             Msg. 9 of 13
Currently, there is no way to do bulk-load of price snapshots.
I suggest to reduce number of API request.

Trader Option chain window subscribe all visible contracts one-by one without unsubscribing them, for user to monitor options prices. It unsubscribe contracts when they became invisible. All calls are in main UI thread.

Dmitriy Gorbachyov
DmitriyG
Posts: 9
Joined: Oct 26, 2011


Posted: Apr 09, 2012 @ 03:40 PM             Msg. 10 of 13
You can also increase subscription limit by sending an email to support@openecry.com with username and environment

Dmitriy Gorbachyov
jlanawalt
Posts: 88
Joined: Feb 12, 2009


Posted: Apr 13, 2012 @ 01:38 PM             Msg. 11 of 13
We have let go of the bulk-loading idea. It was fragile and causing too many problems. Going with the "subscribe to visible" model as OEC Trader's options chain does is working much better. We aren't seeing the too many requests or subscription limit messages (with a reasonable window size) and the data appears very quickly.

We had tried the bulk load because we wanted at least cached values for quick reference, but this way appears to be fast enough.

The trouble we were having with bulk loading is similar to trouble we've had other times when we try to work this way: request something and wait (on callback, not blocking) for the response to know it's requested. This works well when subscribing most of the time because you quickly respond with an old price, we don't have to wait for the market to move to get a price. It doesn't work if we were autosubscribed due to an order and failed to catch the first response. In that case we wait for the market to move or we have to be careful to have caught the previous response.

Thank you for your help on this so far.
jlanawalt
Posts: 88
Joined: Feb 12, 2009


Posted: Apr 13, 2012 @ 01:46 PM             Msg. 12 of 13
Does the API provide a way to know if I'm "subscribed" to the contracts for a base contract, specifically to an options base contract?

I had tried looking up the futures contract, checking if it HasOptions, and if it's Options list Count was greater than 0, because after a successful RequestContracts for the options BaseContract I had found that the futures Contract Options list had the related options contracts.

This method of checking breaks if I have orders on any options contract that expires into the futures contract. It appears that I am subscribed to those options strikes and they are on the futures Contract Options list, but just those strikes are there.

I am cautious to call RequestContracts too much because the documentation cautions against its use (for futures, stating it is suppose to just be used for options) and I wonder if my calling of it, and not Subscribe/Unsubscribe, was getting the "Too many requests" error because my current method does Subscribe/Unsubscribe a lot when I scroll up and down on my list, but I do not see "Too many requests" and I do not RequestContracts more than once if I can help it.
DmitriyG
Posts: 9
Joined: Oct 26, 2011


Posted: Apr 13, 2012 @ 02:01 PM             Msg. 13 of 13
RequestContracts is not a subscription request. And it generates only one request to server.
OnContractsChanged is fired every time list of contracts has been changed for some base.

Use SymbolLookup to get option base and RequestContracts to get the option chain

Throttle Subscribe/Unsubscribe requests by timer to avoid overloading of the server.

Dmitriy Gorbachyov