Demand drives what an adapter publishes
Table of Contents
1. Summary
An adapter publishes only the ids that parties need. The service computes the demand set of each adapter from the subscriptions and the routes of its parties, and sends the set by request and reply. A live adapter then pays the vendor for those ids only. The same demand intervals feed metering.
2. Detail
2.1. How the set is computed
The demand set of an adapter is the union, over all parties routed to the adapter, of the external ids that the parties' items map to. A party's items come from its explicit requirements and from the composites it uses. A composite adds the ids of all its inputs.
2.2. When the service sends it
- When an adapter becomes
ready, and after it recovers fromstale. - When a route, a subscription or a requirement changes.
- The set always replaces the previous set. The service does not send deltas, so a lost message cannot leave the adapter with a wrong set.
2.3. The reply
The adapter answers with the ids it accepts and the ids it rejects. A reason
goes with each rejection, such as unknown_id or not_entitled. The service
shows the rejected ids on the source's screen.
2.4. Demand intervals
The service records when each (party, instrument) pair enters and leaves the set. See Usage is recorded as events and priced later. Demand is therefore both a control signal and a billing fact.
3. See also
- The market data path: a public fixing, a curve, a report — the structure note that orders this cluster, and where to read this page in it.
- Market Data Architecture — the structure note that orders this cluster.
- An adapter and the service meet at four messages — completes: the message that carries the set.
- A party routes to exactly one source for each provider — completes: the input that decides which adapter a party uses.
- Usage is recorded as events and priced later — completes: the use of demand intervals as a driver of cost.