Apama Capital Markets Foundation Documentation : Capital Markets Foundation : Legacy Finance Interfaces : The actors in com.apama.oms : Temporal rules
Temporal rules
The temporal rules for the com.apama.oms interface include the following:
Order updates for execution changes and for state changes should be temporally separated
To simplify the user's logic for any given update and to clearly separate the two types of change, an OrderUpdate event should either convey an execution, or a state change--but not both. If a fill causes an order to become final, two messages can be sent, first the execution, then the OrderUpdate with the inMarket flag set to false. Although by all packaged adapters do not obey this rule, it is a best practice.
No OrderUpdate events can be sent for a particular order before the NewOrder event
The com.apama.oms interface has not been designed to allow unsolicited feeds of order status to be processed. Order updates will only be sent after a new order event has been sent containing that order identifier. Adapters should also enforce this rule.
No AmendOrder or CancelOrder events can be sent can be sent before a NewOrder
The AmendOrder and CancelOrder events only make sense when they have been preceded by a NewOrder event with the same identifier. No publisher should send them before a NewOrder.
Amend order events can be sent as soon as a new order has been sent
The receiver must not assume that the publisher will wait for confirmation that the order is in the market. Amendments can be confirmed before the order itself is confirmed as in market. One example is where an adapter restricts the number of orders per second that can be sent to the exchange. In this situation, NewOrder events may be queued at the service monitor. Any AmendOrder sent corresponding to the order can be applied to the queued NewOrder directly. If this happens, the adapter will confirm the amendment by sending an OrderUpdate with the new price and quantity, before the user receives an order update with inMarket set to true.
Order receivers should acknowledge receipt of all order operations
As mentioned above, order receivers come in two types, some actually process and match orders, others, such as adapters, forward the requests on to another receiver downstream. If the receiver is actually processing the order, it can send an update immediately. If it is not, and is only forwarding on the request, the receiver should send an OrderUpdate event back to the publisher as an acknowledgment. This results in more informative status history in order blotters.
The following table contrasts the flow with and without acknowledgments:
Correct flow for a receiver
Flow without acknowledgments
order sent
order sent
order acknowledged by adapter
order in market
order in market
order amendment sent
order amendment sent
order amendment acknowledged by adapter
If the adapter never sent an acknowledgment, we would not know if it had received it or not. If we never got a response to an amendment, we would not know if the adapter had failed to receive the order amendment, or whether it was a downstream issue.
Another reason for doing this relates to new orders, as described in: Cardinality rules.
These acknowledgments of receipt for amend and cancel requests should be implemented by re-routing the latest OrderUpdate events with a change to only the status field. Note this in the case of a NewOrder event, an initial OrderUpdate with inMarket set to false and with quantity and price set to those in the NewOrder event.
These acknowledgments of receipt of amend and cancel requests should be implemented by re-routing the latest OrderUpdate with a change to only the status field. Not that in the case of a NewOrder an initial OrderUpdate with inMarket set to false and with quantity and price set to those in the NewOrder event.
No fills should be sent to the publisher until the order is inMarket
Orders are not considered tradeable until they have been marked as in market. This means that a trade should only be conveyed in an OrderUpdate event with inMarket set to true. Note that because updates containing fills and state changes should not be combined, receivers should not send the fill in the first OrderUpdate with inMarket set to true, but publishers should interpret such an OrderUpdate as a trade if they do catch it.
No order operations or order updates can be sent after an order is final
Once an order is considered final, the order receiver must send no more order updates and the publisher should send no more amend or cancel operations. This allows both the receiver and the publisher to tear down any listeners they have to free up resources from memory and hypertree entries.
When is an order final?
An order is final in either of the following cases:
*A canceled event has been received
*It was in the market but no longer is
Either of the following OrderUpdate events should result in an order being finalized:
*OrderUpdate(cancelled = true)
*OrderUpdate(inMarket = true) -> OrderUpdate(inMarket = false)
If all other rules are followed, these are the only two conditions that should result in finality. They might occur independently or at the same time. Typically only orders that have been fully filled will not terminate with the canceled flag set to true, but order publishers should not assume that the absence on a canceled flag means that an order was fully filled. That should only be determined by looking at the qtyRemaining field.
There is one more condition for finality. If an order has never been marked in market and has a qtyExecuted greater than 0, then the order publisher should interpret this as the order having been filled and canceled. Note that this can only happen if other rules are broken; namely that updates to an order’s state and executions on that order should not be conveyed in the same order update and that no fills should be sent until the receiver has been notified that the order is in market.
A quantity remaining being equal to 0 does not mean that an order is final. This is to avoid problems for adapters where execution reports and order status are not synchronized. In such adapters, an amendment that increases the size of an order may be in flight when a trade taking qtyRemaining to 0 is received. After this event, the amend event is confirmed, which takes the qtyRemaining back up above 0. The order was never final, but the qtyRemaining was reported as 0. In addition to this, certain order types, such as reservation orders in the firewall can have their trades reversed.
Copyright © 2013-2017 Software AG, Darmstadt, Germany. (Innovation Release)

Product LogoContact Support   |   Community   |   Feedback