Apama 10.3.1 | Apama Capital Markets Foundation Documentation | Capital Markets Foundation | Legacy Finance Interfaces | Market data package overview | Value constraint rules
 
Value constraint rules
Value constraint rules for SubscribeDepth and SubscribeTick are symmetric and include the following:
*serviceId: identifies which publisher (adapter) needs to process the request.
*marketId: part of the composite datasource key, use of it is the same as for the market identifier in a NewOrder event.
*symbol: identifies the instrument that the consumer wants market data for.
*extraParams: dictionary field key used like the corresponding field in a new order event. Some publishers will interpret fields to decide if depth data should be level 1 (best only), level 2 (market by price) or level 3 (market by order). Note that where these extra parameters are supported, they must be considered as part of the source key. This means that consumers must filter based on these extra parameters, and the publisher must put them in the extra parameters of depth events. The MarketDataKey and DepthPublisher objects in the CMF handle this situation. There is no exchange field in a subscribe depth/tick event, so the consumer must send the exchange extra parameter in this event. The publisher should filter based on exchange. No extra parameter set is interpreted as "Exchange"="".
UnsubscribeDepth and UnsubscribeTick are identical to the subscription events. The same rules apply for all their fields.
Use of DepthSubscriptionError and TickSubscriptionError events is discouraged, because they do not contain enough fields to identify where the error occurred. Instead the publisher and consumer should communicate depth or tick subscription errors using the com.apama.statusreport interface. They contain the following fields:
*symbol: identifies the symbol that had the error.
*status: a human readable status message, which must describe the error. An empty status string indicates that any previous error condition has now been cleared.
*fault: states whether the error message represents a permanent fault. If this field is true, the market data consumer should assume that its subscription has been canceled and that it must re-subscribe in order to receive more data. If this field is false, the error is a transient one and consumers can expect to receive more data eventually. After sending an error event with fault=true, a publisher should ensure that the reference count for the relevant subscription is reset to zero and that no more data is sent for the subscription until a new consumer subscribes.
The Depth event is used to represent the depth in the market. Note that the depth event does not contain any details of the composite source key in its primary fields. The consumer of the data must filter the market data using the extra parameters. The CMF MarketDataKey makes doing this much easier. All publishers must ensure that the sequences representing prices are the same length as the sequences for quantities such as, bid price and quantity, ask price and quantity. This will allow the consumer to safely use the same index to access entries in both sequences, without excessive safety tests.
A Depth event includes the following fields:
*symbol: the symbol to which the market data pertains. It will match the subscription.
*bidPrices: a sequence of bid prices. They must be arranged best price to worst, that is, the largest number to the smallest.
*askPrices: a sequence of ask prices. They must be arranged best price to worst i.e. smallest number to largest. Occasionally some adapters will convey Market By Order data through what was originally intended to display Market By Price data. When the do this, the same price may be listed more than once. This must be clearly documented when it occurs.
*midPrices: this field is effectively deprecated. The field was originally intended to give several levels of mid prices, but because no sensible definition of these is possible and because even one mid price can be calculated in multiple different ways, publishers should leave this field empty and allow the consumer to calculate their own mid price using their method of choice. This also helps keep the size of the event down.
*bidQuantities: the depth available in the market. Each quantity maps to the price at the same index in the bidPrices field. For this reason, the two sequences must be the same length. The value is the total contract quantity in the market, not the number of orders in the market.
*askQuantities: the depth available in the market. Each quantity maps to the price at the same index in the askPrices field. For this reason, the two sequences must be the same length. The value is the total contract quantity in the market, not the number of orders in the market.
*extraParams: can be used by the publisher to transmit any information it likes to the consumer, such as the VWAP of the market. Note that, because there are none of the composite datasource keys in the main event, they must all be provided in the extra parameters. The publisher must provide them and the consumer should use the CMF MarketDataKey object to filter depth events based on them. The values should be in SERVICE_NAME, Exchange and Market. Remember too that another extra parameter containing the depth subscription type may need to be present.
Tick events contain the following fields:
*symbol: the symbol to which the market data pertains. It will match the subscription.
*price: the price of the last trade.
*quantity: the quantity of the last trade.
*extraParams: can be used by the publisher to transmit any information to the consumer, such as the trade type. Note that, because there are none of the composite datasource keys in the main event, they must all be provided in the extra parameters. The publisher must provide them and the consumer should use the CMF MarketDataKey object to filter events based on them. The values should be in SERVICE_NAME, Exchange and Market. Remember too that another extra parameter containing the depth subscription type may need to be present.

Copyright © 2013-2019 | Software AG, Darmstadt, Germany and/or Software AG USA, Inc., Reston, VA, USA, and/or its subsidiaries and/or its affiliates and/or their licensors.