Apama Capital Markets Foundation Documentation : Capital Markets Foundation : Finance Smart Blocks for Developing Scenarios : CMF legacy finance support smart blocks : Order Manager v5.0
Order Manager v5.0
The Order Manager block allows a scenario to submit one or more orders to market service provider monitors that are loaded in the correlator, receive reports about the orders, and amend or cancel the orders.
Description
The scenario must submit an order before it can amend or cancel that order. The scenario cannot amend or cancel a completed order. Once a scenario places, modifies, or cancels an order, the market service provider monitor must acknowledge or reject that operation before it allows another operation on that same order. However, a scenario can perform consecutive operations on an order without waiting for replies from the market service provider monitor. The Order Manager block makes this possible by automatically queueing consecutive requests, and sending them when the market service provider monitor allows modifications to the order.
You can use multiple Order Manager blocks in a single scenario. There is very little performance penalty for using more than one Order Manager block. You might want more than one Order Manager block in the following situations:
*When you are trading one item against another you can use one block for each item. See Implementing a pairs trading strategy.
*When you are trading against two or more different adapters. You can use one Order Manager block for each adapter so that you do not need to repeatedly change adapter-specific parameters.
The Order Manager block has no timing dependencies. To make this block available to your scenario, you must add the Legacy Finance Support bundle to your project.
About Order Manager market service provider monitors
Market service provider monitors are outside the scenario. The Order Manager block communicates with these monitors by means of well-known events. These events are defined in the com.apama.oms package, which is included in the Legacy Finance Support bundle. For more information, see the ApamaDoc. When using the Order Manager block, you do not need to know the details of these well-known events.
During development, a market service provider monitor is a pure EPL simulation market. In a deployed application, a market service provider monitor is part of an adapter that communicates with an IAF process, which communicates with some market.
Most blocks are completely contained in a scenario instance, including any block wiring. However, order management requires communication with market service provider monitors, which are outside the scenario. The Order Manager block, and the Market Data blocks, provide access to resources outside the scenario.
Order states and statuses
An order is always in one of the following states:
An order can enter the Unknown state from any other state, and can leave the Unknown state and enter any other state. An order is in the Unknown state when the adapter cannot guarantee what state the order is in. This can happen, for example, if the network between the correlator and the market is down.
In the figure, the text in italics shows the status of the order while the order is in that state:
*in market — The order is known to the market. Modifications to the order might or might not be allowed.
*modifiable — The order is known to the market and modifications to the order are allowed.
*cancelled — The trader or the market stopped processing the order before it was fully filled. The order is known to the market.
*final — The order is no longer known to the market. Modifications are not allowed.
Each status is a Boolean field in the order status output feed.
An order in the unknown state can have a status of in market, cancelled, or modifiable.
The order status output feed also supplies Boolean fields for indicating the following for an order:
*change rejected — The most recent attempt to modify or cancel the order was rejected by the market. The change might have become impossible because a trade took it over the new requested quantity, or it might have been rejected by the market for any other reason.
*externally modified — The status message typically gives details for this.
*is visible — Some markets consider orders to be known to the market but invisible until a certain condition has been met, for example, stop orders are invisible until the trigger price is reached.
Upon modification or cancellation, the market might modify some fields of an order, including changing fields to values other than those requested. The actual price and quantity that are present in the market are reported in the order status output feed.
The Order Manager block normally cancels orders when the scenario enters the end state. You can disable this by setting the leave orders open on Scenario exit parameter to true.
About an order block’s order identifiers
The Order Manager block allows a scenario to place multiple orders through a single block. Each Order Manager block maintains an “order book” that indicates the state and status of each order placed from that block. In the order book, an order identifier distinguishes each order from every other order placed from that block. You always specify the order identifier as a parameter when you amend, cancel, retrieve, or clear an order.
An order identifier must be unique in an Order Manager block instance. You cannot submit an order if the order identifier parameter does not have a unique value. An empty string is a valid order identifier. A block that places a single order can use the default empty string as the value of the order identifier parameter. A scenario that uses two Order Manager block instances can specify the same order identifier in each instance. Also, two instances of the same scenario, which contains an Order Manager block, can each use the same order identifier.
The block’s order identifier is different from order identifiers used elsewhere. Most adapter services create their own order identifiers to send to the market. These identifiers might not include the block’s order identifier because markets often place limits on the length of order identifiers. Some services might supply the market order identifier in the order status output feed. This is the order identifier supplied by the market and is different from the block order identifier. You can use the market order identifier to track an order in the market. The market typically ensures that this is unique across all scenario instances.
The recommended practice is to set the auto-generate order identifier parameter of the Order Manager block to true. When this parameter is true, the Order Manager block generates the order identifier when you place an order. The generated identifier has the following format:
Order_n
You can obtain the generated order identifier from the order identifier field of the order status output feed. The Order Manager block sends data to this feed immediately after you place an order.
By default, the auto-generate order identifier is set to false, which means that you must specify a unique order identifier when you place an order. If you specify your own order identifiers, the recommendation is to use a numeric counter for placing successive orders from a single Order Manager block. This ensures that the block’s order identifier is unique for each order issued from that block. An Order Manager block ignores multiple orders with the same order identifier. Note that an Order Manager block’s order identifier is one part of a compound value that the scenario uses to ensure that each order identifier is globally unique. The Order Manager block order identifier is a crucial part of this compound identifier.
In its order book, an Order Manager block maintains counts of all orders initiated in that block. An Order Manager block exposes these counts in its order book status output feed. Most are self explanatory, and are counts of all orders that are in a certain state or have a certain condition set for them.
You can retrieve the status of an individual order with the retrieve order operation. The status of the order goes to the order status output feed.
Obtaining the status of orders placed
To obtain the status of each order placed from an Order Manager block, a scenario can iterate over the orders in an Order Manager block’s order book. Iteration sends the latest state of each order to the order status output feed. Iteration does not change any of the orders. You might also want to iterate through a block’s order book to calculate some statistic that is not provided by the order book status output feed.
If the scenario places any orders during the iteration, they are not included in the current iteration. The iteration iterates over all orders that are in the block’s order book when the scenario calls the iterate operation. A scenario can perform one iteration on a particular block at a time. If a scenario has multiple Order Manager blocks, it can be iterating over each block at the same time.
The iterate operation starts iterating over orders, and when the iteration is complete, the iteration complete output feed outputs a value of true. If the iteration complete output feed does not output true, an order status is available on the order status output feed. The iteration calls the next operation, which places the next order’s status on the order status output feed, or sends a value of true to the iteration complete output feed. Upon calling next, a scenario typically needs to re-enter the state it is in (and not remain in this state) in order to re-evaluate the rules for performing operations on the order, and thus call next again. For example, to iterate over all orders in the order book and count the number of orders in the market for the symbol in the symbol scenario variable, use the following rules:
Start iteration
i
Initialize the count variable, start the iteration, move into the iterate state. No block parameters are required for this process.
When
true
Then
*count = 0
*iterate [Order Manager]
*move to state [ iterate ]
Check iteration complete
i
If the iteration is complete, move into next state, where we do something with the count.
When
complete from Order Manager (iteration complete)
Then
move to state [ next state ]
Check order is for symbol and in market
i
If the order’s symbol is what we are looking for and it is currently working in the market, increment the count.
When
( symbol from Order Manager (order status) is equal to symbol ) and in market from Order Manager (order status)
Then
count = ( count + 1 )
Next iteration step
i
Always move onto the next iteration step. The iteration state must contain a rule that calls next, else the scenario might never leave the iteration state. Note that the action is to move to this state, which is different from remaining in this state (all rules are re-evaluated, even if they have not changed, such as this rule).
When
true
Then
*next [Order Manager]
*move to state [ iterate ]
Note that the "next iteration step" rule re-enters the iterate state, thus re-evaluating all rules unless the iteration is complete.
Issuing concurrent orders from the same block
As mentioned before, you can use the same Order Manager block to issue two or more concurrent orders. When you issue multiple orders, a common strategy is to set up timers that fire when you want to cancel an order. An example of this appears below. In the example, the Order Manager block and the Wait block share identifiers. The scenario issues an order with an identifier of 1 and then starts a timer with an identifier of 1. When a timer fires, it causes cancellation of the order that has the same identifier as the timer. In an actual scenario, you would also cancel a timer when an order is filled. In this example, all rules are in the same state, and they do not require any settings on the Order Manger block’s parameters.
SubmitOrder1
i
Issue an order to BUY 100 lots of APMA. Use an order identifier of "1". Set the timer’s trigger time to be 5 seconds and assign the same identifier to the timer. Start the timer. This creates a timer that fires after 5 seconds. When it fires, it returns the identifier assigned to the timer, which is 1 in this example.
When
true
Then
*order identifier from Order Manager = "1"
*symbol from Order Manager = "APMA"
*side from Order Manager = "BUY"
*quantity from Order Manager = 100
*submit order [Order Manager]
*time from Wait 1 = "5"
*timer id from Wait 1 = "1"
*start [Wait 1]
*remain in this state
SubmitOrder2
i
As above, but now the order identifier is "2" and the order is to SELL 200 lots of "ABCD".
When
true
Then
*order identifier from Order Manager = "2"
*symbol from Order Manager = "ABCD"
*side from Order Manager = "SELL"
*quantity from Order Manager = 200
*submit order [Order Manager]
*time from Wait 1 = "5"
*timer id from Wait 1 = "2"
*start [Wait 1]
*remain in this state
Wait for both orders to complete
i
Total number of orders in the market is zero, so both orders are complete.
When
in market from Order Manager (order book status) is equal to 0
Then
*move to state [end]
Wait for one of the timers to fire
i
When a timer fires, the scenario uses the timer’s identifier to point to the order in the order book that has the same identifier. The scenario then cancels that order, and leaves the other order untouched. The scenario resets the timer so that it is ready for the next time-up event.
When
time up from Wait 1 (timer)
Then
*order identifier from Order Manager = timer id from Wait 1 (timer)
*cancel order [Order Manager]
*reset [Wait 1]
*remain in this state
Clearing final orders from the order book
The Order Manager block maintains listeners and state for each final order. If a scenario is long-running, and placing a large number of orders, the memory that the block uses gradually increases. Consequently, it is beneficial to periodically clear final orders from the block’s order book.
However, before you clear final orders, make sure that you no longer need to know anything about them. For most markets, once an order reaches the Completed state there are no more modifications against that order. However, there are some exceptions to this. See Handling corrections to final orders.
To clear an order from the order book, set the block’s order identifier parameter to the order identifier of the order you want to clear, and call the clear order operation.
Information about cleared orders is not included in the summary information provided by the order book status output feed.
Handling corrections to final orders
Under some circumstances, some markets provide corrections for order executions that are in the Completed state. It is up to you to be aware of which markets might correct orders that are final.
If you are placing orders with a market that corrects order executions after the order is final you will want to track final orders. For example, after all of an order’s quantity has been executed, the market corrects the execution and the total quantity executed goes down. The order might go back into the Working in Market state. The exact behavior depends on the market. A corrected order might or might not re-enter the market for further executions.
For markets that correct order executions, an Order Manager block cannot guarantee that an order in the Completed state is truly final. If you are placing orders with such a market, you must specify what happens when there is a correction to a final order. Also, you want to define your scenario so that it ensures that the Order Manager block continues to keep track of the state of orders that are in the Completed state. (There is no option to set to take care of this.) In other words, you do not want to clear final orders for a market that might correct those orders.
Note that you cannot clear the final field of the order execution output feed.
Cancelling orders
To cancel an order, call the cancel order operation on a modifiable order. The order immediately enters state 6, pending cancel. This means that the scenario sent the cancellation request but has not yet been notified by the market about whether or not the order has been cancelled. An order that is in the pending cancel state is included in the visible and tradeable counts in the order book status output feed.
If you try to cancel an order that is not modifiable, the order does not move to the pending cancel state. The block rejects the cancel request.
The market can reject a cancellation request. Consequently, after an order is in the pending cancel state, it can move to any of the following states:
*State 7 — Cancelled
*State 3 — Completed. For example, a market might complete an order before it tries to cancel that order.
*State 2 — Working in market. For example, the market might reject the cancellation request because the order is of a type that cannot be cancelled.
Implementing a pairs trading strategy
In a scenario, you might want to implement a pairs trading strategy in which, for example, when you buy one stock in an industry you sell another stock usually in the same industry. One way to do this is to use two Order Manager blocks — one for each instrument.
The advantages of using two blocks are:
*You do not need to modify the value of the symbol parameter in the block.
*It is easy to determine which instrument’s order was executed.
*Each Order Manager block’s order book status output feed provides summary information for one instrument.
A simple scenario that places a single order for each instrument would specify the following parameters in each block:
*Quantity to trade
*Price for each trade
*Market or limit type
*Buy or sell side
*Any other required fields
The Scenario would execute the submit order operation in each block. If the scenario places multiple orders for each instrument, the recommendation is to set the auto-generate order identifier parameter to true for each block. Otherwise, you need to implement a strategy for ensuring unique order identifiers.
A scenario that places multiple orders for a variable number of instruments probably needs to use a single instance of the Order Manager block. Again, if you set the auto-generate order identifier parameter to true, the block generates each order identifier for you, which ensures a unique order identifier for each order.
Blocks commonly used with order manager blocks
It is common to use the Position Calculator block and P&L Calculator block with the Order Manager block. This lets you maintain position information and deliver trading performance metrics. In the Block Wiring tab, position the blocks as follows:
The wiring between the Order Manager block and the Position Calculator block is as follows:
The wiring between the Position Calculator block and the P&L Calculator block is as follows:
The scenario can output information about the position and profit as follows:
profit = profit from P&L Calculator 1 (P&L)
position = position from Position Calculator 1 (position)
Parameters
Parameter
Description
order identifier
A unique identifier in the scope of the Order Manager block. The block uses this identifier to perform operations on the order.
service identifier
The name of the market service provider monitor to use, or an empty string to use any market service provider monitor.
broker identifier
The name of the broker to send the order to. To determine whether you need to specify this parameter, and obtain more information about the meaning of this parameter, see the documentation (this is often a README file) for the adapter you are using. If the documentation does not mention this parameter, you do not need to specify it.
book identifier
The name of the book the order should be accounted against. To determine whether you need to specify this parameter, and obtain more information about the meaning of this parameter, see the documentation for the adapter you are using. If the documentation does not mention this parameter, you do not need to specify it.
market identifier
The name of the market to send the order to. To determine whether you need to specify this parameter, and obtain more information about the meaning of this parameter, see the documentation for the adapter you are using. If the documentation does not mention this parameter, you do not need to specify it.
exchange
The name of the exchange to send the order to. To determine whether you need to specify this parameter, and obtain more information about the meaning of this parameter, see the documentation for the adapter you are using. If the documentation does not mention this parameter, you do not need to specify it.
symbol
The instrument to trade.
price
The price to trade at, or 0 for a market order.
quantity
The amount to trade. For example, the number of shares to buy or sell.
side
BUY or SELL. Some services also support other values such as BUY MINUS or SELLSHORT.
type
MARKET or LIMIT. Some services also support other values such as STOPMARKET or STOPLIMIT. If left blank, the order is placed as a LIMIT if a price is specified or a MARKET order if no price is specified (or is 0).
extra parameters
Any extra parameters for the service.
leave orders open on scenario exit
If true, the block does not cancel orders when the scenario enters the end state. This leaves the orders uncontrollable in the market.
clear orders in final state
If true, removes references in the order book to the order after the order enters the Completed state. You cannot retrieve such an order with a retrieve order or iterate operation, and the order book status output feed does not include cleared orders in its counts.
auto-generate order identifier
If true, the Order Manager block generates the order identifier for you when you place an order. The generated identifier has the following format:
Order_n
Obtain the generated order identifier from the order identifier field of the order status output feed. The Order Manager block sends data to this feed immediately after you place an order.
The default is that this parameter is set to false, which means that you must explicitly specify a unique order identifier when you submit an order. (This ensures that scenarios created with Order Manager block versions from before this parameter was added can continue to work without modification.)
add scenario info to extra params
If true, the Order Manager block adds scenario information to the extraParams field of events generated by the OrderManagerSupport monitor. The default is that this parameter is false.
You might need to set this parameter if you are writing a monitor to be used in the service layer. Such a monitor accepts messages from the Order Manager block and sends messages to the market. If you are not writing a service layer monitor, you would not need to modify this parameter. For information about the service layer, see the OrderManagerSupport monitor, which is in the monitors\finance directory of your Apama installation directory.
When this parameter is true, the Order Manager block adds the following information:
*Current Scenario Id — in the extraParams dictionary, the key is ScenarioName.
*Current Scenario display name — the key is ScenarioDisplayName.
*Current Scenario instance Id — the key is ScenarioInstance.
After your Order Manager block executes a submit order, modify order, or cancel order operation, the Order Manager block adds the above listed scenario information to the extraParams field of the NewOrder, AmendOrder, or CancelOrder event that the OrderManagerSupport monitor generates.
Setting this parameter is useful when there are many scenarios in your system, and you need to know which scenario sent a new order, or cancelled or amended an order. You can set up monitors that listen for the NewOrder, AmendOrder, and CancelOrder events, inspect their extraParams member, and extract the scenario information.
In your dashboard, you might display a list of the orders sent. If so, it is useful to see both the scenario display name of the scenario that created that order (so you can see which of your algorithms initiated the order) and also the scenario instance ID (so you can track the order back to the specific instance that generated it).
Operations
Operation
Description
submit order
Send the order to the market. The order automatically enters state 1, waiting for acknowledgment.
modify order
Change the order in the market. The order automatically enters state 5, pending change, unless the order is not modifiable at this time.
cancel order
Cancel the order in the market. The order automatically enters state 6, pending cancel, unless the order is not modifiable at this time. The market can reject a cancellation. Consequently, after an order is in the pending cancel state, it can become cancelled, completed, or, if the cancellation is rejected, working.
retrieve order
Retrieve information about the order specified by the order identifier parameter. You can obtain the state of a previously placed order even if other orders have been processed since the specified order.
clear
Clears the order status and iteration complete output feeds. This operation has no effect on the market state. If you have output feeds connected directly to your user interface, you might call this operation to refresh the user interface.
cancel all orders
Cancel all orders. Note that the market might reject some cancellations.
iterate
Begin iterating over all orders in the Order Manger block’s order book. The iteration is complete when the iteration complete output feed becomes true. For an example, see Obtaining the status of orders placed.
next
Continue to the next order in the iteration. The order in which the next operation visits orders in the order book is undefined.
clear book
Delete information about all orders that have been placed, including any that are still active. Initiate this operation with great care. It is dangerous to lose track of orders if they are still active. This operation empties the internal order book. Immediately following this operation, the value of the total executed field of the order book status output feed is zero.
clear order
Delete information about the order identified by the order identifier parameter, even if that order is still active. There are no further trades for this order. In general, you should not clear an active order because you can then no longer amend or cancel that order, nor obtain information about that order, such as how much money was made or lost as a result of that order.
Input feeds
This block has no input feeds. Instead, the Order Manager block maintains listeners that listen to events from the market service provider monitors. Since the Order Manager block does not have any input feeds, you cannot wire another block to the Order Manager block.
Output feeds
The Order Manager block generates output in response to events from the market service provider monitors, and Order Manager block operations. You can wire an Order Manager block output feed to another block, such as the Position Calculator block.
The Order Manager block provides the following output feeds:
*order status — The Order Manager block generates the order status output feed upon placement, modification, or cancellation of an order. This feed reports all information about each order. Each time there is a change in the order, such as a state or status change, the order status feed provides output.
Some markets provide quantity information at quite some time after pricing information. The order status feed has no means to express this later-arriving information. In this situation, the order execution feed reports the quantity traded, but not the price.
*order book status — This feed provides summaries about the orders in the order book. For example, it indicates how many orders placed in this block are in each state
*iteration complete — This feed indicates when an iteration through the order book is complete.
*order execution — This feed reports information if the quantity traded for a particular fill has changed since the order status feed reported information about that fill. If the quantity traded does not change after the order status feed reports the fill, the order execution feed does not provide any output about that fill.
*order quantity — This feed reports fills without pricing information, as they happen.
Feed
Fields
Description
order status
order identifier
The Order Manager block’s unique identifier, which was specified or generated when this order was placed. This identifier distinguishes this order from every other order placed by this block.
market order identifier
An identifier supplied by the market, typically unique across all orders in that market.
symbol
Identifier for the instrument being traded.
price
The price requested either when the order was submitted or the latest modification. A price of 0.0 signifies a market order.
quantity
The total number of units, such as shares, to trade, or the number the order has been amended to.
side
The side of the order — BUY, SELL, or some other side supported by the market.
type
The type of the order — MARKET, LIMIT, or some other type supported by the market.
state
The order’s state indicated by 0-9. See Order states and statuses.
money executed
The sum of price * quantity for all fills of this order, or 0.0 if no fills have occurred.
average price executed
The volume-weighted average price over all fills, or 0.0 if no fills have occurred. For example, suppose you place an order to buy 100 shares of IBM at up to $10.00 per share. You bought 20 shares at $9.95 and 20 shares at $9.97. The average price executed is $9.96.
last price executed
The price obtained per item for the last fill, or 0.0 if no fills have occurred.
last quantity executed
The number of items traded in the last fill, or 0 if no fills of this order have occurred.
quantity executed
The number of items traded so far, or 0 if no fills of this order have occurred.
quantity remaining
The number of items left to trade in the market as part of this order.
in market
true if the order is known to the market.
is visible
true if the order is visible in the market. Some markets consider orders to be invisible until a certain condition has been met, for example, stop orders are invisible until the trigger price is hit.
modifiable
true if the order can be modified immediately. The Order Manager block queues any attempts to modify an order when it is not modifiable. The queued modification cannot occur if the order enters a final state before becoming modifiable.
cancelled
true if the order has been rejected or cancelled, possibly before being entered into the market. A cancelled order might have had some quantity traded.
change rejected
true if the most recent modification or cancellation was rejected by the market. An explanation might be available in the status message field.
externally modified
true if the order has been modified by anything other than the scenario, for example, the market or a third party.
final
true if the quantity specified for the order has been traded, or if the order was cancelled.
status message
A message from either the market service provider monitor or the market explaining what has happened. The format and meaning of the message varies from service to service and market to market.
extra parameters
String that specifies additional parameters, which contain more information about the instrument being traded.
order book status
number of orders
The number of orders that are in the block’s order book. This is the number of orders that have been placed from this instance of the Order Manager block, including those that are in a final state, but not those orders that have been cleared from the order book
total placed
The total number of shares for which an order has been placed from this instance of the Order Manager block, where the order has reached the market. This includes orders that have been cancelled, rejected, and completed, as well as orders that are in the market.
total executed
The sum of the quantities executed for all orders. For example, the quantity executed for a particular order might be the number of shares that have already been sold. If there are two orders that each sold 100 shares, they would add 200 to the value of total executed. This number does not include any orders that have been cleared from the order book.
total working
The sum of the quantities remaining to be traded for all orders that are in the market. As you might expect, this includes orders in states 2, 5, 6, and 8. However, it also includes orders that are in state 1, that is, orders that have been submitted to the market but not yet accepted. For example, if you place an order to buy 100 shares and so far 75 shares have been bought, the value of total working is 25.
waiting for acknowledgement
The number of orders in the order book that are in state 1 — waiting for acknowledgment from the market service provider monitor.
working
The number of orders in the order book that are in the market and modifiable. These are the orders that are in state 2 (in the market) and they are not in state 5 (pending change) or state 6 (pending cancel).
complete
The number of orders in the order book that are in state 3 (completely filled).
rejected
The number of orders in the order book that are in state 4 (rejected).
pending change
The number of orders in the order book that are in state 5 (pending change).
pending cancel
The number of orders in the order book that are in state 6 (pending cancel). For additional details, see Cancelling orders.
cancelled
The number of orders in the order book that are in state 7 (cancelled).
suspended
The number of orders in the order book that are in state 8 (suspended).
in market
The number of orders in the order book that are in the market but not necessarily modifiable. These are the orders that are in state 2 (in the market) or state 5 (pending change) or state 6 (pending cancel).
visible
The number of orders that are visible in the market. For example, stop orders are invisible until they have been triggered.
modifiable
The number of orders that are modifiable.
tradeable
The number of orders that might trade. This count includes every order that is not final. If a scenario waits until it has no outstanding orders in the market, it should wait for the tradeable field to become 0.
iteration complete
complete
true if the iteration has completed
order execution
order identifier
The Order Manager block’s unique identifier that was specified or generated when this order was placed. This identifier distinguishes this order from every other order placed by this block.
symbol
Identifier for the instrument being traded.
side
The side of the order – BUY or SELL.
money executed
The total amount of money that has been exchanged for all fills of this order. This is the sum of the amounts exchanged for each order. For each order, this is price * quantity.
average price executed
The volume-weighted average price per item over all fills of this order.
quantity executed
The sum of the number of items, such as shares, traded in each fill of this order.
last money executed
The amount of money exchanged for the last fill of this order. This is: last price executed * last quantity executed.
last price executed
The price per item in the last fill of this order.
last quantity executed
The number of items traded in the last fill of this order.
final
true if the quantity specified for the order has been traded.
extra parameters
A string that contains any other information from the market. See Optional and extra parameters.
order quantity
order identifier
The Order Manager block’s unique identifier that was specified or generated when this order was placed. This identifier distinguishes this order from every other order placed by this block.
symbol
Identifier for the instrument being traded.
side
The side of the order – BUY or SELL.
quantity executed
The total number of items, perhaps shares, traded in every fill of this order.
last quantity executed
The number of items, perhaps shares, traded in the last fill of this order.
final
true if the quantity specified for the order has been traded.
extra parameters
A string that contains any other information from the market. See Optional and extra parameters.
Copyright © 2013-2016 Software AG, Darmstadt, Germany.

Product LogoContact Support   |   Community   |   Feedback