Vendor adapters

Table of Contents

1. Summary

A live vendor adapter is a separate service. It meets the contract in An adapter and the service meet at four messages and adds a vendor session behind it. It announces one provider, receives demand sets, and publishes ticks with the vendor's own ids and fields. The service treats it exactly as it treats the simulator.

2. Detail

2.1. What the adapter must do

  1. Announce its provider and universe.
  2. Open vendor subscriptions for the ids in each demand set and close the others. This is how the platform pays only for what a party demands.
  3. Translate each vendor update into a tick with the vendor's id scheme, id, field, value and time.
  4. Reply to a demand with the accepted ids and the rejected ids, such as not_entitled.
  5. Send a heartbeat, reconnect to the vendor and resend its demand on a new session.

2.2. What it holds that the simulator does not

2.3. What it does not hold

A mapping to oresmd, a tenant, a party, a rate card, or storage. The service holds them.

2.4. Several live sources

One provider can have more than one live adapter: for example a production session and a vendor test environment. Each has a source of its own kind (live or test). Routes choose between them. See A party routes to exactly one source for each provider.

2.5. Fit with the rest

The adapter reads like any other source in the catalogue, with a rate card taken from the real contract. The cost model applies unchanged. See A rate card on the source turns usage into a bill the platform shares.

3. See also

Emacs 29.3 (Org mode 9.6.15)