The com.apama.oms interface does not guarantee a response to NewOrder events. New orders contain a service identifier, and if no order receiver is listening to that identifier, the order will be ignored. Due to this limitation, order publishers should setup a timeout when submitting new orders. If they receive no update in that amount of time, they should send a cancel order event. To reduce the risk off false timeouts, receivers should always take care to acknowledge receipt of new order events as soon as they receive them.

When a receiver processes a NewOrder event, the last update it sends must imply that an order is final. See the rules for determining when an order is final in Temporal rules. The receiver must send exactly one update telling the publisher the order is final. Then, the receiver must not send any updates for that order. If the receiver does not send an order update implying finality, the publisher will never know that the order is final. This will cause resource leaks. If the receiver sends an update after sending one that implies the order is final, the update will be ignored. Thus, it is vital that the update implying finality is the last update sent for that order.

As soon as a NewOrder event has been sent, that publisher can send as many amendments and cancellation operations as they like. Note that the temporal rules means that none can be sent after an order is final. If any amend or cancel events are sent after an order is final, they will be silently ignored. AmendOrder events can be sent after CancelOrder events. For example, cancel events might be rejected because some exchanges will not allow you to cancel an order that has been in the market less than a specified time. If an amend event is received after a cancel event, it will only be applied if the cancel event is rejected. The order must be considered amending until one of the following occurs: