Stock Accessors

Stock accessors provide real-time stock data through the selected broker. Each accessor gives access to a specific provider. Even when the system is designed to offer different providers we currently support exclusively the Interdin broker due to several problems (the main problem is that each broker uses different tickets for the same stock and it's not possible to generate automatic mappings).

To make accessors generic all of them must adhere to an interface that defines all the available methods. They will create a generic collection of objects containing all the possible data that can be read from the provider.

It the duty of the accessors to maintain the connection alive and reconnect when its needed.


The following are generic classes used by all the accessors:


  • AccessorFactory: has the responsibility of creating an instance of an IStockDataAccessor and an IOrderExecutor allowing these classes to remain internal and isolating the real Accessor from the application.
  • IStockDataAccessor: defines the methods that all providers must implement. They are:
    • Methods to connect, disconnect and check connection status.
    • Methods to get the read information from the accessor. There is property that offers a list with all the accessorgroups. They should be thread-safe so a lock mechanism must be present to avoid them being modified while they are read. This list can have nulls inside if the required group is not offered by the accessor or if the data has not been read yet for the first time when the property is read.
    • Methods to manually open the provider.
  • IOrderExecutor: defines the methods a provider implementing orders must have. It is a separated interface from the IStockDataAccessor because objects using this interface do not need (and must not have) access to these methods. This interface is used only by plugins and they won't connect / disconnect / etc the main accessor. The interface has methods to execute market orders and limited orders but the last are intended only for debugging, probably when the system is tested and reliable only the market orders will remain. The interface also allows to enable a simulation mode were no real orders must be executed, this will enable testing the system before putting it into production. It still does not support orders on opening bid but implementing this is on the high priority queue.
  • IStockDataAccessorInformation: defines the properties that shows the state of IStockDataAccessor. 
  • AccessorStockQuote: represents an item read from an accessor. It implements all the possible fields and all of them are nullable. The consumer must check if they are present or not.
  • AccessorStockGroup: represent a group of related items read from an accessor. It is the equivalent of the StockGroup from an Accessor point of view.
  • InvalidConnectionDataException: is the exception that will be thrown when the connection data used to connect to the provider is not valid.
  • OperationExecutionResult: contains the information returned after executing a market operation. This allows us to know when was executed and how much was the final operation amount.
  • OrderExecutionException: will be thrown be the IOrderExecutor each time an order cannot be executed. Allows us to differentiate them from the other exceptions as these ones have a higher priority.

The following are specific classes related to the Interdin accessor. The Interdin pages group related items in this way:

The whole system is modeled using the following structure (this is the diagram when order execution was not implemented):

And the following diagram models the order execution structure. It's the first version of the system and I'm not very happy on how it looks like so I probably refactor it sooner or latter:

Model Classes

  • WebItem: represents a generic item displayed at the provider. Contains what is common between a WebFuture and a WebCfd. It is composed of a list of  strings that represent each column shown at the web pages. The class and its descendants provides properties to obtain the values inside the items. As the values are shown in a web page, all the properties are retrieved as strings, it is the responsibility of the converter from WebItem to AccessorStock to convert the string to the right type. It also contains an array of strings containing the parameters needed to open the detail window. The WebItem provides all the parameters as simple strings, its the duty of the caller to give them the right meaning.
  • WebCfs: models the way a Cfd is shown at the Interdin pages.
  • WebFuture: models the way a Future is shown at the Interdin pages. You can see how a WebFuture looks like on the first image.
  • WebGroup: represents a generic group displayed at the provider. Contains what is common between a FuturesWebGroup and a CfdWebGroup. It is composed of a xml document containing all the html rows and columns that contain the web representation of the group. We set the data into a xml container because this way we can query its content with LINQ. 
  • FuturesWebGroup: models the way a group of Futures are shown at the Interdin pages. You can see how a FuturesWebGroup looks like on the first image. It contains a list of WebFutures.
  • CfdWebGroup: models the way a group of Cfd is shown at the Interdin pages. It contains a list of WebCfd.
  • WebPage: represents a generic web page read from Interdin. Contains what is common between a CfdWebPage and a FuturesWebPage, mainly the html data presented as a string and a method to extract the WebGroups the page contains.
  • CfdWebPage: models the Interdin page that contains the Cfds read by the CfdPageReader.
  • FuturesWebPage: models the Interdin page that contains the Futures read by the FuturesPageReader. You can see how a FuturesWebPage looks like on the first image.
  • WebItemToAccessorStockConverter: its responsibility is to convert one WebItem to one AccessorStock converting the string data present at the WebItem to the required type.
  • OrderType: models the different types of orders supported by the accessor. Currently market, limited and stop orders are supported by Interdin.
  • OrderExecutionLink: models the link that points directly  to the execution of an order (the action done when pressing the Execute button at the details page). Currently we support market and limited.
  • DetailsPage: models the page that is opened when accessing the details of a stock. This page contains all the available market information, different market levels and links to orders. Currently we are only parsing the data to generate the required links, the other data is not processed yet.
  • DetailsLink: models the link that opens the details window of an stock. 

Engine Classes

As all the calls to the Accessor like Connect, Disconnect must be asynchronous and also due to  page readers working in parallel and the need to stop all of them if one encounters one error, disconnect from the provider and reconnect again a decoupled system has been done where an engine has a thread running continuously to execute the orders that other queue on it. The model is the following one:

  • Accessor: it implements the IStockDataAccessor and the IOrderExecutor for the Interdin provider. Its main responsibility is to read the data available at the whole Interdin site and return it as a list of AccessorStockGroups to be processed by others. The Accessor relies on the AccessorEngine to do all the work in an asynchronous way. The accessor will stop if the connection data (user/password/contract) is wrong to avoid the lock of the provider account. It has also the responsibility of executing orders, to maintain one single responsibility this feature is implemented by the OrderExecutor.
  • AccessorInformation: it implements the IStockDataAccessorInformation and provides information on the status of the Accessor. To avoid coupling the AccessorEngine thread with the rest of the application the events raised by the AccessorInformation (property changed events) are raised by a different thread.
  • AccessorEngine: is designed to be always running. It will stop only on application exit or if invalid data is sent to the provider in which case the whole application will need a restart as that data is read through settings at the startup. Due to this behavior the class do not dispose anything on stop. It is just a thread continuously checking if it has AccessorEngineOrders to execute.
  • AccessorEngineOrders: its an enum containing all the orders the AccessorEngine can execute:
    • None: when this order is received the engine will sleep for 100msec before checkin again if there is an order.
    • Connect: this order makes the engine to connect to the Interdin site and to log in. The engine will retry the connection until it succeeds.
    • Disconnect: this order makes the engine to diconnect from the Interdin site and to log off.
    • Reconnect: this order is executed when an error is received (like network disconnection) and makes the engine to disconnect and connect again. A Reconnect won't be executed if the previous order was a Disconnect.
    • Stop: this order stops the engine forever requiring a complete restart of the application to start it again. It is used on connection info invalid or when shutting down the application.
    • ReadOnce: reads the accessor data once. When the data is read the connected property becomes true. The call to disconnect must be done after the ReadOnce.
  • ConnectionManager: its main responsibility is to connect, disconnect and log in into the Interdin site. It also stores the cookies required to work with the site.
  • PageReader: its responsibility is to read pages from the Interdin provider and to extract all the required information. Contains what is common between a CfdPageReader and a FuturesPageReader, mainly required connection data and a method to extract page contents.
  • FuturesPageReader: its responsibility is to read the FuturesWebPage from the provider and to transform its set of FutureWebGroups into a set of AccessorGroups. The AccessorEngine and the Accessor will take this data and offer it as public data.
  • CfdPageReader: its responsibility is to read the CfdWebPage from the provider and to transform its set of CfdWebGroups into a set of AccessorGroups. The AccessorEngine and the Accessor will take this data and offer it as public data.
  • OrderExecutor: its main responsibility is to execute the requested orders. Currently it only supports market and limited orders (the designed plugins only require market orders as they need the certainty of its execution). Other order types would require extra coding to detect when orders have been executed or not. The market orders are expected to be executed always or to return an errorcode. The case when the order is set on the opening bid has to be considered.
  • DetailsPageReader: its main duty is to read the details page of an stock using the link that points to it.
  • DetailsLinkManager: its one of the key points of the order subsystem. Its main responsibility is to maintain a dictionary of stock symbols and the links to their detail pages. When the OrderExecutor has to execute an order its first action is to look into the DetailsLinkManager to find the link that points to the details window.

Last edited Feb 18, 2013 at 10:04 AM by somos, version 56


No comments yet.