Creating a TT Application Server

For each algo that you wish to implement, you must create a file named ‘metadata.xml’ which defines the algo’s parameters and how they should be displayed in the TT user interface. This definition file must then be deployed to the TT environment so the TT user interface can find it.

This file must describe the algorithm, its parameters and its graphical layout using FIXatdl. The following is an introduction to a subset of the FIXatdl functionality most commonly used in TT Algo SDK algos. For complete details, see the official FIXatdl web site.

The metadata.xml file describes the algo with the following XML element hierarchy:

The basic structure of this file includes the following sections:

• File header
• Algo name and description
• Algo parameter definitions
• Algo input parameters UI layout

The TT Algo SDK software package includes the necessary FIXatdl schema files. They can be used to create a conforming FIXatdl document. The portions of the specification that are not supported by TT Algo SDK algos have been commented out.

Section: file header

The file header consists of the following:

Section: algo name and description

The <Strategy> element’s xmlns attributes specify the basic information about the algo. In addition to the FixATDL namespaces and schema information, it includes algo-specific attributes.

The <Strategy> element must specify the following algo-specific attributes:

• name: Short name of the algo as displayed in the list of algos that a user has permission to launch

  

• uiRep: Full name of the algo as displayed in the algo’s parameter pane

  

• version: Developer-defined version of the algo

• providerID: ID of the firm providing the algorithm

• entryFile: Name of the algo’s shared object (.so) file

Section: algo parameter descriptions

Each input and output parameter must be defined with a separate <Parameter> element. The following code snippet shows several sample <Parameter> elements:

The <Parameter> element requires the following attributes:

• name: Name of the parameter

  No two parameters of any strategy may have the same name. Names are case-sensitive and must begin with an alpha character followed only by alpha-numeric characters that must not contain whitespace characters. The value is not case-sensitive.

  TT supports several special names which, when used, allow the user to launch the algo more quickly from MD Trader. These fields will be automatically populated with the corresponding values based on where the user clicks.

  Parameter Name	Description	Values
  __instr_id	Instrument ID
  __order_quantity	Order Quantity
  __account	Account
  __side	Order Side	SIDE_BUY = 1 SIDE_SELL = 2
  __price	Order price in decimal format
  __tif	Time-In-Force	TIME_IN_FORCE_DAY = 1 TIME_IN_FORCE_GOOD_TILL_CANCEL = 2 TIME_IN_FORCE_AT_THE_OPENING = 3 TIME_IN_FORCE_IMMEDIATE_OR_CANCEL = 4 TIME_IN_FORCE_FILL_OR_KILL = 5 TIME_IN_FORCE_GOOD_TILL_CROSSING = 6 TIME_IN_FORCE_GOOD_TILL_DATE = 7 TIME_IN_FORCE_AT_THE_CLOSE = 8 TIME_IN_FORCE_GOOD_THROUGH_CROSSING = 9 TIME_IN_FORCE_AT_CROSSING = 10 TIME_IN_FORCE_AUCTION = 13 TIME_IN_FORCE_GOOD_IN_SESSION = 14 TIME_IN_FORCE_DAY_PLUS = 15 TIME_IN_FORCE_GOOD_TILL_CANCEL_PLUS = 16 TIME_IN_FORCE_GOOD_TILL_DATE_PLUS = 17 TIME_IN_FORCE_GOOD_TILL_TIME = 18 TIME_IN_FORCE_CLOSING_PRICE_CROSS = 19 TIME_IN_FORCE_IMMEDIATE_OR_CANCEL_PLUS = 20 TIME_IN_FORCE_FILL_OR_KILL_PLUS = 21 TIME_IN_FORCE_MORNING_AT_THE_CLOSE = 22 TIME_IN_FORCE_AFTERNOON_AT_THE_CLOSE = 23
  __type	Order Type	ORDER_TYPE_MKT = 1 ORDER_TYPE_LIM = 2 ORDER_TYPE_SM = 3 ORDER_TYPE_SL = 4 ORDER_TYPE_ICE = 5 ORDER_TYPE_Block = 6 ORDER_TYPE_Cross = 7 ORDER_TYPE_BOC = 8 ORDER_TYPE_OCO = 9 ORDER_TYPE_MV = 10 ORDER_TYPE_MOO = 11 ORDER_TYPE_EFP_I = 12 ORDER_TYPE_EFP = 13 ORDER_TYPE_VOLA = 14 ORDER_TYPE_EFP_FI = 15 ORDER_TYPE_BL = 16 ORDER_TYPE_SBL = 17 ORDER_TYPE_IFBL = 18 ORDER_TYPE_SL_OSE = 19 ORDER_TYPE_MTL = 20 ORDER_TYPE_MLM = 21 ORDER_TYPE_COMMITTED = 22 ORDER_TYPE_BASIS = 23 ORDER_TYPE_GCROSS = 24 ORDER_TYPE_ASSETALLOC = 25 ORDER_TYPE_PROF = 26 ORDER_TYPE_ONESIDED = 27 ORDER_TYPE_COMBINATION = 28 ORDER_TYPE_AGAINSTACTUAL = 29 ORDER_TYPE_SMTL = 30 ORDER_TYPE_MIT = 31 ORDER_TYPE_LIT = 32 ORDER_TYPE_ITMTL = 33 ORDER_TYPE_EFS = 34 ORDER_TYPE_FLEXFUT = 35 ORDER_TYPE_FLEXOPT = 36 ORDER_TYPE_LPO = 37 ORDER_TYPE_MARKET_CLOSE_TODAY = 38 ORDER_TYPE_LIMIT_CLOSE_TODAY = 39 ORDER_TYPE_LIMIT_REDUCE_ONLY = 40 ORDER_TYPE_MARKET_REDUCE_ONLY = 41 ORDER_TYPE_DISCRETION = 42

  For example:

  <Parameter name=”__instr_id” xsi:type=”String_t” refValue=”OrderInstrumentID” required=”true” dir=”In” updateable=”false”/>

  <Parameter name=”__order_quantity” xsi:type=”Qty_t” refValue=”OrderQty” required=”true” dir=”In” updateable=”true”/>

  <Parameter name=”__account” xsi:type=”String_t” refValue=”OrderAccount” required=”true” dir=”In” updateable=”false”/>

  <Parameter name=”__side” xsi:type=”Int_t” refValue=”OrderSide” required=”true” dir=”In” updateable=”false”/>

  <Parameter name=”__price” xsi:type=”Price_t” refValue=”OrderPrice” required=”true” dir=”In” updateable=”true”/>

  <Parameter name=”__tif” xsi:type=”Int_t” refValue=”OrderTIF” required=”true” dir=”In” updateable=”false”/>

  <Parameter name=”__type” xsi:type=”Int_t” refValue=”OrderType” required=”true” dir=”In” updateable=”false”/>

• required: Whether the parameter is required. Valid values are “true” or “false”. The value is not case-sensitive.

• initValue: Initial value for the parameter.

• dir: Whether a parameter is an input (“In”), an output (“Out”), or both (“Both”). The value is not case-sensitive.

• updateable: Whether the parameter can be updated after the algo is launched. Valid values are “true” or “false”. The value is not case-sensitive.

• xsi:type: Data type corresponding to the parameter value:

  • Int_t: Integer value.
  • Float_t: Decimal value.
  • Qty_t: Value representing an instrument, fill or order quantity.
  • Price_t: Value representing an instrument, fill or order price.
  • PriceOffset_t: Value representing the number of ticks to offset a price.

    Note: All of the above types support the following attributes:

    • minValue: Minimum value of the parameter accepted by the algorithm provider.
    • maxValue: Maximum value of the parameter accepted by the algorithm provider.
    • constValue: Value of a parameter that is constant and is not presented in the UI. This value must be sent on the wire by the order generating application.
  • String_t: String value. This type supports the following attributes:
    • minLength: Minimum allowable length of the string.
    • maxLength: Maximum allowable length of the string.
    • constValue: String value that is constant and is not presented in the UI. This value must be sent on the wire by the order-generating application.
  • Boolean_t: Boolean value. Valid values are “true” or “false”. The value is not case-sensitive.
  • UTCTimestamp_t: UTC timestamp.

In TT, instruments and accounts are uniquely identified by 64-bit integers. As FIXatdl does not define this data type, you must use the String_t type to pass 64-bit integers.

Each <Parameter> element can include optional <EnumPair> sub-elements to enumerate a list of valid values.

The <EnumPair> element supports the following attributes:

• enumID: List item identifier. No two list items may have the same name.

  Names must begin with an alpha character followed only by alpha-numeric characters and must not contain whitespace characters.

• wireValue: Corresponding index sent on the wire.

The following code snippet shows a sample <Parameter> element with some <EnumPair> elements:

Section: algo input parameters UI layout

You need to specify how each input parameter will be displayed. The most basic structure of the XML for specifying the layout of parameters uses the <lay:StrategyLayout> as follows:

The layout of each input parameter must be defined with a separate <lay:Control> element.

The <lay:Control> element supports the following attributes:

• ID: Unique ID for the control.

• parameterRef: The name attribute of the <Parameter> element that corresponds to the control.

• dependentParam: The name attribute of the <Parameter> element on which this control depends.

• tooltip: Tooltip text for the parameter.

• label: String to display next to the control.

• xsi:type: Type of UI control:

  • lay:MarketExplorer_t
  • lay:TTAccounts_t
  • lay:TextField_t
  • lay:Slider_t
  • lay:CheckBox_t
  • lay:SingleSpinner_t
  • lay:Clock_t
  • lay:DropDownList_t
  • lay:RadioButton_t

Each <lay:Control> element can use optional <lay:ListItem> sub-elements to enumerate a list of valid values.

The <lay:ListItem>element supports the following attributes:

• enumID: The enumID of the corresponding <EnumPair> element.
• uiRep: String to display for the control.

The following code snippet shows a completed sample <lay:StrategyLayout> element based on all of the <Parameter> elements defined above.

Note that the instr_acct_ctrl_1 and order_price_ctrl_1 controls have their dependentParam attribute set to “instr_id_1”. As a result, the list of accounts displayed in the Account drop-down list will be filtered to show only those accounts that have permissions to trade this instrument. And when the user clicks the left or right mouse buttons while focus is on the Order Price single-spinner control, the price displayed will be decremented or incremented by one tick.

Notice the following about the sample:

• The instr_acct_ctrl_1 and order_price_ctrl_1 controls have their dependentParam attribute set to “instr_id_1”. As a result, the list of accounts displayed in the Account drop-down list will be filtered to show only those accounts that have permissions to trade this instrument.
• When the user clicks the left or right mouse buttons while focus is on the Order Price single-spinner control, the price displayed will be decremented or incremented by one tick.
• The order_side_ctrl_1 element populates a drop-down list that ensures the user can choose only valid values (Bid or Ask).

As noted, this example shows basic functionality. See the FIXatdl schema files included in the TT Algo SDK package as well as the official FIXatdl web site for complete details.

Once you have created the metadata file for your algo, you must deploy it to make it visible in the TT user interface. Deploying it is accomplished by executing the Python script named “deploy.py” that is provided as part of the TT Core SDK.

where “<appkey:secret>” is an application key that you have created and “<environment>” is either “ext-uat-cert”, “ext-prod-sim”, or “ext-prod-live”. For example:

You can undeploy a previously deployed algo using the Python script named “undeploy.py” that is provided as part of the TT Core SDK as follows:

where “<appkey:secret>” is an application key that you have created and “

You can share a previously deployed algo using the Python script named “share.py” that is provided as part of the TT Core SDK as follows:

where “<appkey:secret>” is an application key that you have created, “<email>” is the email address of the user with whom you want to share the algo and “<environment>” is either “ext-uat-cert”, “ext-prod-sim”, or “ext-prod-live”. For example:

*** IMPORTANT: All algos must be shared with the user who will be running the TT Application Server. Furthermore, the user running the TT Application Server must have at least the same permissions as the user who launches an algo in terms of market data, etc.

You can unshare a previously deployed algo using the Python script named “unshare.py” that is provided as part of the TT Core SDK as follows:

where “<appkey:secret>” is an application key that you have created, “<email>” is the email address of the user with whom you want to unshare the algo and “<environment>” is either “ext-uat-cert”, “ext-prod-sim”, or “ext-prod-live”. For example:

To build this type of application, you must:

The following code snippet demonstrates an example of this process.

With TT Core SDK, you can create a separate application for each algo that you plan to execute. Or you can create a single application with multiple algos coded into it. Either way, you must also devise controls within each application to allow the user to manage the algos.

Or you can take advantage of the built-in mechanism within TT Core SDK that allows users to control the algos from TT’s front end user interface. Specifically, TT Core SDK provides functionality that allows you to build a TT Application Server which services requests from TT’s user interface to launch and manage the custom algos that you have built. This means that you can focus on building algos and leave the user interaction aspects to TT. It also means that users can launch and manage the algos that you have created in the same way as all other algos in the TT platform.

OnStartRequest()

There are several ways to design a mechanism to launch algos within your process. One such approach is to first create a pure virtual base class that defines the semantics for managing the algo. For example:

Each algo would then be defined by a class which derives from and provides implementation for:

For Example:

We can then add a collection to store instances of the algos being launched to the SDKAlgoManager class.

OnUpdateRequest()

Once an algo has been started, external update messages are forwarded to it from the TT UI as follows:

OnStopRequest()

Once an algo has been started, external stop messages are forwarded to it from the TT UI as follows:

OnPauseRequest()

Once an algo has been started, external pause messages are forwarded to it from the TT UI as follows:

OnResumeRequest()

Once an algo has been started, external resume messages are forwarded to it from the TT UI as follows:

A response must be sent for each external algo request. Failure to do so within ten seconds will result in In-Flight-Order-Action (IFOA) errors being displayed in the TT user interface. This is one such example.

There are two parameters that are passed to almost all of the external algo request callback functions: ttsdk::SDKAlgoPtr algoOrder and ttsdk::SDKAlgoRequestPtr req. The ttsdk::SDKAlgoPtr parameter contains methods to get information about the current state of the algo as well as methods to send responses, including:

• virtual const char* GetOrderId() const;
  • Returns the unique TT order id of this algo.
• virtual InstrumentPtr GetInstrument() const;
  • Returns the instrument referenced by the algo. Might be null if the user did not specify an instrument in the tradition manner in the algo requests.
• virtual AlgoDefinitionPtr GetAlgoDefinition() const;
  • Returns information related to the algo’s definition.
• virtual ExecutionReportPtr GetCurrentState() const;
  • Returns the current state of the algo.
• virtual bool GenerateSyntheticFill(const double fillPrc, const double fillQty)
  • Generates and sends a fill message for the given qty and price. May not be applicable for all algo types.
• virtual bool GenerateUserResponse(const char* msg, const ttsdk::UserParameter params[], const size_t numParams)
  • Generates and sends a restatement message to the user containing the given information. Generally used to send an update which is not in response to a direct request.
• virtual bool FailAlgo(const char* message)
  • Sets this algo as failed and sends a message to the user indicating failed status.
• virtual bool StopAlgo(const char* message)
  • Sets this algo as finished and sends a message to the user indicating finished status.
• virtual void OnPendingRequestCompleted(const AlgoResponseCode code, const char* message = nullptr)
  • Must be called when a request from the user is completed. If the algo request action was successful, return AlgoResponseCode::ok; otherwise pass in a code that describes the reason for failure.

The ttsdk::SDKAlgoRequestPtr parameter contains methods to get information about the algo itself, including:

• virtual const char* GetOrderId() const
• virtual ttsdk::OrderType GetOrderType() const
• virtual ttsdk::OrderSide GetSide() const
• virtual ttsdk::TimeInForce GetTimeInForce() const
• virtual double GetPrice() const
• virtual double GetQuantity() const
• virtual uint64_t GetUserId() const
• virtual uint64_t GetCurrentUserId() const
• virtual uint64_t GetAccountId() const
• virtual const char* GetClearingAccount() const
• virtual uint64_t GetInstrumentId() const
• virtual uint64_t GetAlgoDefinitionId() const
• virtual const char* GetText() const
• virtual const char* GetTextA() const
• virtual const char* GetTextB() const
• virtual const char* GetTextC() const
• virtual const char* GetTextTT() const
• virtual uint32_t GetUserParameterCount() const
• virtual UserParameter GetUserParameter(const uint32_t index) const

Position Reserve (PR) orders are discussed in detail in the Position Reserve Orders section. If you plan to utilize them when running as a TT Application Server, you would call the SDKAlgo::ReserveRisk() method, preferably from the strategy’s Start() method.

When the request to reserve risk returns, the SDKAlgoManager::OnRiskReserved() method will be called. You can then notify the strategy which made the request as follows:

To process this call, you must override the BaseStrategy:: OnRiskReserved() method in your specific strategy. For example:

Similarly, you can then release Position Reserve orders by calling the SDKAlgo::ReleaseRisk() method. You can notify the strategy which made the request in the same way.