Apama Capital Markets Foundation Documentation : Capital Markets Foundation : Legacy Finance Interfaces : The actors in com.apama.oms : Test cases for order receivers
Test cases for order receivers
A minimum recommended set of test cases should be implemented for all order receivers to ensure compliance with the rules listed in this document. The following table describes these test cases:
Filter on serviceID
The receiver should always filter on the serviceID on new, amend and cancel order events. Just filtering on serviceID for the last two is not sufficient. The test should also explicitly check that empty serviceID is not matched.
Destination key extraParams are required
All order update events must contain the correct values for the SERVICE_NAME, Exchange, and Market parameters. The latter two are allowed to be missing if not used by the receiver, SERVICE_NAME must always be present.
No order updates should be sent after the order is final
The tests for the adapter should all make sure that the adapter sends no updates after the order is final. For example, after an event that indicates canceled, or after one that indicates in market and then one that indicates not in market.
Adapter handles amend and cancel as soon as it receives a new order
A common mistake for adapters is to start listening for amendments and cancellations after an order has been acknowledged by the market, rather than as soon as the new order is received.
Adapter supports concurrent amendments
A common problem in adapters is not properly supporting concurrent amendments.
Adapter does not change any fields in response to an amend/cancel
A common failing of adapters is to put the details of an amend or cancel into an order update before a response from the market is received. The only field that is allowed to change is the status field.
Adapter cleans up listeners for amend and cancel order events after order is final
This test should confirm that there are no listener leaks.
Adapters that fake amendments must make this transparent
It is a common failing for the quantity field and quantity executed field to represent only the new replacement order.
Adapters must send the correct events on an order that fills immediately
It is a common failing to forget to put the order inMarket, before it is marked as not being inMarket. If this happens then the publisher will not know that the order is finished. QtyRemaining = 0 does not mean an order is final. See Cardinality rules.
Adapters must listen to all cancel requests until an order is final
A common failing of an adapter is to have an on CancelOrder listener, rather than an on all CancelOrder listener. Cancellations can fail, so it is important to listen for more than one of them.
Adapters must always mark orders as final eventually
Either an order will be marked downstream because it is finished, or because the adapter connection was lost, or even the correlator was shutdown, but it must happen at some point. This usually requires ondie actions to be implemented.
Adapters must handle disconnection
It is a common failure not to handle adapter disconnection correctly. As mentioned above the order should be marked as stateUnknown and canceled.
Adapters must handle updates from downstream systems while amending/canceling
It is a common failing of an adapter to ignore updates from a downstream system while processing an amendment, or cancellation. This is often fill information.
Adapters must handle external amends
If a downstream system allows components other than the adapter to modify orders, the adapter must report these as external amendments.
Adapters should reject all unsupported amendments
Many adapters fail to realize that the user tried to amend the symbol, because they do not support this. The receiver must validate these fields and send an update with orderChangeRejected set to true and with an appropriate status message.
Adapters must be able to report rejected amendments and cancellations
Some adapters fail to do this.
Adapters must always send updates where quantity = qtyRemaining + qtyExecuted
Any event that does not have this property is invalid.
Adapters must only set inMarket when the market has confirmed the order and unset it when the order is final
It is a common mistake to set the inMarket flag prematurely and to forget to unset it when the order is final.
Adapters must always reject amendments when they have the modifiable flag set to false
It is a common mistake to not remember to set modifiable to true and accept amendments even if the flag is not set. Only orders that have been marked as modifiable, or for which no order update has yet been sent, can be modified.
Adapters must correctly implement average price calculation
Not all adapters implement the average price correctly. Either this field must be reported directly from the downstream system, or the cash executed must be tracked by the receiver.
Adapters that require user ids must provide a mapping facility
It is a common mistake implementing an adapter to expect the ownerId field to contain the user ID the downstream user will recognize. The value will be the dashboard user id when scenarios send orders, so the adapter must provide a mapping facility.
Adapters must be fully documented
There are a lot of features in the com.apama.oms protocol that are entirely adapter specific. These must be documented. Every adapter needs to detail:
*Supported order types
*Supported extra parameters, whether they are mandatory or optional
*Which fields and extra parameters can be amended
*The definition of quantity values in orders (particularly in FX)
*Supported markets and exchanges
*Details of broker and book support
*Details of session configuration (multi instance support)
*Details of user name mapping
Copyright © 2013-2017 Software AG, Darmstadt, Germany. (Innovation Release)

Product LogoContact Support   |   Community   |   Feedback