Order Submission Messages
| This documentation is for FX Professional 2.18 and earlier. From version 2.19 (2 Jun 2019), FX Professional requires back end adapters to implement the FX Integration API 3. For documentation on FX Integration API 3 messages, see FX Integration API. |
The following trade model and set of messages describe the fields and values required to successfully submit a Limit Order trade using the FX Professional Motif 2. Note that this trade model only deals with submission. All other events regarding the order after submission, such as its execution, cancellation and progression are sent as updates to the order blotter.
For each of the messages below, [c] denotes that the message is sent by the client, and [s] denotes that the message is sent by the server.
Architecture
For the front-end client, the trademodel library handles the processing of these messages. Streamlinkis used to send messages to the back end. For Limit Order, the Client must send a message that submits the order, known as the submit message. The server will then send a set of responses informing the client of the progress of the order submission which either ends successfully and activates the order, or ends with an error.
For the back-end adapters, the FXIntegrationAPI consumes the client messages. The requests for Order Submissions are handled by an Adapter that instantiates the FXOrdersAdapter object and registers an OrderSubmissionListener (see the FX Integration API documentation for more information on Adapters). The order submission is handled by the FX Integration API using implementations of the OrderStrategy. There is an implementation for each of the StrategyTypes (see below). These implementations contain the Responders and Events required to send messages from the server side, in order to transition the trade model to the final state.
Strategy Types and Setups
The following describes the order strategies available in the FX Professional Motif 2, and how they must be set up.
-
SINGLE - Trade, Leg (id1)
-
OCO - Trade, TP or SL Leg (id1), TP or SL Leg (id2). The orders must consist of a TP and an SL (you cannot have two TPs, for example).
-
IF-DONE - Trade, Parent Order Leg (id1), TP or SL Leg (id2)
-
IF-DONE-OCO - Trade, Parent Order Leg (id1), TP or SL Leg (id2), TP or SL Leg (id3). The OCO orders must consist of a TP and an SL (you cannot have two TPs, for example).
Trade Model State Diagram
Blue arrows denote a message sent by the client, or a system timeout, green arrows denote messages sent by the server.
States that allow the server to send messages, can aslo send the Error and Reject message. These two transitions are therefore not shown on the diagram above.
Submit Message [s]
This is the message that the client sends to submit a limit order.
| Field Name | Value | Example |
|---|---|---|
RequestID |
The client generated ID that is unique for this user and trade. The client-side trading library generates this. |
112314243333 |
MsgType |
The transition that the server wants to make in the state model |
Submit |
CurrencyPair |
The currencyPair for all orders in this strategy |
GBPUSD |
Account |
The account to trade on |
Acct1 |
ActivationDate |
What date the Order should be activated |
"GFA" or an ISO date "20130606" (GFA is Good From Activation) |
ActivationTime |
What time the Order should be activated if the ActivationDate was in the format of yyyymmdd |
12:12:12 |
ActivationLocation |
When location should be used to evaluate the time to activate if the ActivationDate was in the format of yyyymmdd |
'new york' |
ActivationUTCOffset |
The activation date UTC offset for the client’s location as defined by the browser |
Send a value of 00:00 if the location is anything other than "LOCAL" Send the offset e.g. +05:00 when the location is "LOCAL" |
ExpirationDate |
What date the Order should be expired |
GTC, GFD, 20130606 GTC=Good Till Cancelled GFD=Good For Day (valid for the current trading day only). |
ExpirationTime |
What time the Order should be activated if the ExpirationDate was in the format of yyyymmdd |
12:12:12 |
ExpirationLocation |
When location should be used to evaluate the time to expire if the ExpirationDate was in the format of yyyymmdd |
'new york' |
ExpirationUTCOffset |
The expiration date UTC offset for the client’s location as defined by the browser |
Send a value of 00:00 if the location is anything other than "LOCAL" Send the offset e.g. +05:00 when the location is "LOCAL" |
StrategyType |
The Strategy that this trade object represents |
SINGLE, OCO, IF-DONE, IF-DONE-OCO |
AlertType |
The types of alerts that should be sent for this order |
SMS, EMAIL (comma separated list, zero or more values) |
Account |
The settlement account to use |
SetAcc1 |
All leg fields should be prepended with L*_ where * represents the leg id. For a multi-leg order, the second order would have L2 instead of L1, and the third order L3. The L1 fields are considered the parent order.
| Field Name | Values | Example |
|---|---|---|
L1_ExecutionType |
How this order should be executed. CALL-ORDER, TAKE-PROFIT, STOP-LOSS, MARKET, or BENCHMARK. CALL-ORDER and BENCHMARK are only valid for single-legged strategies. MARKET is only valid for a parent order in a multi-legged strategy. |
TAKE-PROFIT |
L1_BuySell |
The trade direction of the base currency, from the perspective of the user. Valid values: "BUY", "SELL". |
BUY |
L1_BenchmarkType |
The type of benchmark to fix to. |
A string defined by the back-end trading system. eg. WMR, ECB |
L1_Amount |
Amount |
100000.00 |
L1_FillRate |
The rate at which this order should be filled |
1.1232 |
L1_DealtCurrency |
The currency that the amount is specified in |
GBP |
L1_Remarks |
Comment/remarks by the client |
Call John when filled |
SubmitAck Message [s]
This is the message the server sends in order to acknowledge that the Submit Message has been received by the back-end adapters.
| Field Name | Value | Example |
|---|---|---|
RequestID |
The client generated ID that is unique for this user and trade. The client-side trading library generates this. |
112314243333 |
MsgType |
The transition that the server wants to make in the state model |
SubmitAck |
Accepting Message [s]
This is the message the server sends to tell the client that the order has been received by the back-end trading system and is being processed.
| Field Name | Value | Example |
|---|---|---|
RequestID |
The client generated id that is unique for this user and trade. The client-side trading library generates this. |
112314243333 |
MsgType |
The transition that the server wants to make in the state model |
Accepting |
Accept Message [s]
This is the message the server sends to tell the client that the order is now accepted by the back-end trading system.
| Field Name | Value | Example |
|---|---|---|
RequestID |
The client generated id that is unique for this user and trade. The client-side trading library generates this. |
112314243333 |
MsgType |
The transition that the server wants to make in the state model |
Accepted |
OrderID |
The ID assigned to the accepted order by the trading system. |
5.1.30086 |
Reject Message [s]
Error Message [s]
See also: