MAXsys Venue API Specifics

Key Value State Stores (KVSS) Usage

State Store Identifiers

A Destination that is implemented using a KVSS for storage includes an identifier for the KVSS in the State Store Identifier prefix if the STOMP destination header.

Any semantics of the structure within this prefix is assumed to be store type specific. As the prefix identifies a store, it is not included as part of the key within the store.

As of writing, the only KVSS supported on thePC-MID is X/ - a.k.a The State Store.

The X KVSS Key Structure

The following is a description of a convention. This convention must be followed on the PCMID so as to both avoid key collisions within the X KVSS and to provide a keyed data model consistent with the user visible topic hierarchy expressed via the STOMP destinations that provide access to the store. Other stores may define different conventions.

Subject to Key Mapping

After stripping the State Store Identifier from the Destination and using it to identify/access the X KVSS, the Subject (the remainder of the _Destination_) is used to determine the KVSS key.

Direct Subject to Key Mappings

In simple cases the Subject is used directly as the key.

EGM Entity Destination

Because some subscribers to updates of EGM data, are only interested in EGMs having a particular protocol, the STOMP destination includes a protocol identifier between the EGM entity name and the [GMID] entity instance identifier so that the Destination format of, for example, an EGMMeterReading is:

EGM.[P].[GMID].EGMMeterReading

where [P] is a single letter protocol identifier:

• G for G2s,
• Q for QCOM
• X for X Series.

The KVSS key does not include [P] - there is only a single EGM_, of a single protocol, with a given _GMID at any time.

Schema Evolution and Versioning

Wherever possible the Avro schema will be evolved compatibly. Avro subscribers must be prepared to deal with such evolution without a coordinated update/deployment. In the context of Subjects and Keys this means that the value stored with a given key will always be able to be resolved from the writer (publisher) Avro schema to an older reader (subscriber) Avro schema by an Avro resolving decoder. A major version change to the Avro schema (a change that requires explicit support, not simply a resolving decoder, to be read/used by a subscriber) will not be released without a well strategy including a method to preserve compatibility with or migrate data from the old schema, together with an adequate period for transition.