Test | Details |
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 sending 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 |