Opentick Input Adapter

Four elements in the Opentick configuration file set up the connection to an Opentick server:

All four elements are required in order to make a connection with an Opentick server. There must be one and only one <username> and <password> entry in each configuration file. These elements are used as parameters in a call to OTGenericClient.login() in the Opentick API.

There must be at least one <hostAndPort> element; there can be more than one, for example, to specify separate connections to the same server on different ports, or to specify separate connections to different servers. Each entry is used in a call to OTGenericClient.addHost().

The <loginTimeout> element is used to time out attempts to log in to an Opentick server. If the timeout value is reached, the Opentick adapter shuts down. In this case, the adapter can be restarted from the command prompt using the command sbadmin restart adapterName. There must be one <loginTimeout> element in the configuration file; there is no default value.

<username>YourUserName</username>
<password>YourPassword</password>
<loginTimeout>20000</loginTimeout>
<hostAndPort hostName="feed1.opentick.com" port="10015"></hostAndPort>

When the Opentick adapter receives an Opentick message, it formats that message as a tuple, then sends it downstream. A tuple is sent downstream on a specific port that has a specific schema. The schema of the output port is predetermined by the type of Opentick message requested. This means there must be an output port type for each incoming request type.

Output ports are specified in the configuration file with the <outputSchema> element. The value of the element corresponds to the Opentick message type supported by the Opentick adapter, as shown in the following table:

For example, if the Opentick adapter receives an Opentick message of type OTTrade, then it sends this data out on a port configured with the schema specified as TRADE.

Specify one <outputSchema> element for each type of Opentick data of interest. Note that this does not necessarily correspond to the number of static and dynamic data requests, because you can have multiple data requests for the same message type, and a single request can return data of more than one type, depending on the mask specified for that request.

If data of a certain type is received, but there is no output port schema configured for that type, then the data is discarded. Thus, for example, if a request returns trade data, but there's no output port configured for trade data, the trade data is dropped.

StreamBase Studio draws one output port on the Opentick adapter's icon for each <outputSchema> line in the configuration file.

<outputSchema>QUOTE</outputSchema>
<outputSchema>TRADE</outputSchema>
<outputSchema>MMQUOTE</outputSchema>

A variety of Opentick data can be requested with the Opentick adapter. The adapter creates an Opentick client, then uses this client to send requests to Opentick. The set of requests included in the configuration file are sent to Opentick when the adapter starts up.

The Opentick adapter currently supports a subset of the available Opentick requests. These correspond to the following requests available in the Opentick API's OTGenericClient class:

Use the following steps to translate any of the request formats above into an element to be used in the Opentick configuration file:

The applicationID attribute can be optionally applied to most <*Request> elements. Its value is an arbitrary string used as a tag to identify data returned by that request. For example, if a request is given an applicationID of localHistDataRequest, then each tuple that this request produces will include a field named applicationID with a value of localHistDataRequest. applicationID is not an available attribute for TickStreamRequests, because there can be only one active tick stream per symbol, and the symbol name is presumed to be a unique identifier for tuples produced from such requests.

Requests sent to an Opentick adapter while it is running are called dynamic requests. Dynamic requests are sent to the adapter by enqueuing them to streams. Streams created for this purpose are referred to as control streams. The use of control streams is discussed in the next section; this section describes how to enable control streams in the Opentick adapter's configuration file.

You can enable up to six different control streams in the Opentick adapter's configuration file. There is a separate control stream for each supported request type, as shown in the following table. Separate streams are necessary for each request type because each request takes a different set of arguments, which means each stream must have a different schema.

If a control stream is enabled in the configuration file, then the Opentick adapter creates an input port for it. In StreamBase Studio, an input stream would be dragged onto the canvas and hooked up to this port, and a schema for each input stream needs to be created, using the schemas described below. The Opentick adapter verifies that the schema for a each control stream has the fields that it expects.

Control streams are created in the order that they appear in the configuration file. For example, if the HistData control stream appears first in the configuration file, then the Opentick adapter creates its port first. When an input stream is hooked up to this port, the Opentick adapter validates that this input stream has the schema expected for a HistData control stream, including fields named command, applicationID, exchange, symbol, startDate, endDate, interval and mask.

Where the control schema is:

Where the control schema is:

In this example, the values for symbol and options are specified as null, so that all symbols in the Q exchange (NASDAQ) are returned.

Where the control schema is:

Where the control schema is:

Where the control schema is:

Where the control schema is: