Downloading Fills
For efficiency reasons, TT Core SDK does not hold fills in memory. If you need to access past fills, you:
The following code snippet demonstrates an example of this process.
Modifying Orders
Once an order has been submitted, you can subsequently change it by:
The following code snippet demonstrates an example of this process.
Once an order has been submitted, you can subsequently change it by:
The following code snippet demonstrates an example of this process.
Position Reserve (PR) Orders
When an order is placed via TT Core SDK, it is routed to the TT risk system. If it passes the necessary risk checks, it is then routed to a TT component called the Order Connector which then routes it to the exchange. If it does not pass the necessary risk checks, it is rejected. Use of Position Reserve (PR) orders allows position risk to be reserved ahead of time so that the TT risk system can be skipped when orders are placed. This can result in a significant latency reduction in terms of routing new/change/cancel order messages.
To reserve position risk, you must specify:
It is intended for Position Reserve orders to be submitted when your application initializes or at least before any latency sensitive aspect of your application executes. Once successfully submitted, any subsequent orders for the same instrument and account will undergo a quick local risk check to confirm that they do not exceed the limits specified in the Position Reserve order. The behavior of this risk check varies depending upon whether you submit only a buy PR order, only a sell PR order, or both buy and sell PR orders for a given instrument / account.
Specifically:
Position Reserve orders are persistent in the TT system. As such, it is important that PR orders be deleted (released) as part of stopping your application.
The following code snippet demonstrates one way of using and managing Position Reserve orders when NOT running as an Application Server. If you are running as an Application Server, see the Initializing a Server Application section for further details.
The SDK also stores a collection of handles to PR orders. Access to specific PR orders can be obtained via the GetRiskBucket() function.
Receiving Only Specific Solicited Order / Fill Events
To receive specific solicited order / fill events, you need to:
A sample implementation of class derived from ttsdk::IOrderEventHandler is demonstrated in the following code snippet.
Receiving Solicited and Unsolicited Order / Fill Events
To receive solicited and unsolicited order / fill events, you need to:
An OnAccountDownloadEnd event is fired when an account is ready to be used for trading. And an OnOrderBookDownloadEnd event is fired when all accounts are ready.
The following code snippet demonstrates an example of this process.
Request IDs
When an application submits a new order or changes an existing
order, the TT Core SDK stores the request ID provided with the
request. The request IDs are then passed back in the event
callbacks (ExecutionReport::GetRequestId())
to allow developers to determine which order request that a
given event is in response to. When an application submits a
change request for an order, the TT Core SDK will immediately
route the message to the exchange if no other change request
is in flight.
If, however, there is another change request in flight, the TT
Core SDK will queue the submitted change request as well as
any further change requests for this order. Once a response
for the in flight change request has been received, the TT
Core SDK will conflate all request messages in the queue and
route a single change request to the exchange. In other words,
an application may not receive an order event for every
request that it submits. The request ID can be used to detect
when this happens.
For example, assume that the following order change messages
were submitted prior to the application receiving the
acknowledgment for the initial order submission.
Order 1: BUY 10 CME ZB-Mar18 @ 155’11 (Request ID = 1)
Order 1: Change price to 155’10 (Request ID = 2)
Order 1: Change price to 155’09 (Request ID = 3)
Order 1: Change quantity to 12 (Request ID = 4)
Order 1: Change price to 155’08 (Request ID = 5)
Order 1: Change price to 155’07 (Request ID = 6)
When the response is received for the initial order, a single
message would be routed to the exchange with a quantity of 12
and a price of 155’07. And the application would receive one
order event callback with request ID set to 6.
Submitting Orders
To submit an order and start receiving order/fill updates, you:
The following code snippet demonstrates an example of this process.
The OrderProfile class has a member named LeaveOnRestart. It is set to true by default. If you are writing a TT Application Server, setting this to false will result in the order being deleted after your application is restarted.
Working with Order and Fill Events
After the TT Core SDK initialization begins, it downloads:
- the accounts belonging to the user
- the orders associated with each account
- the positions associated with each account
TT Core SDK synchronizes the Order Book and positions by
account. As such, any given account can be used to trade
without needing to wait for all accounts to be ready.
If you want to receive order / fill events for all solicited
and unsolicited orders, you need to use the
ttsdk::IOrderBookEventHandler interface.
If you want to receive order/fill events for only those orders
that you choose, you need to use the
ttsdk::IOrderEventHandler interface.