Subscribe

In the case of a EDA service that produces data the specification should add a subscribe operation in the specification. The specification will tell another service that

-hey, I publish data here you can subscribe to it

channels:
  '{sensorId}.temperature':
    parameters:
      sensorId:
        description: 'Id of the temperature sensor. Use # to get temperatures from all sensors'
        x-example: SENSOR-001
        schema:
          type: string
    subscribe:
      operationId: onSensorTemperatureChange
      description: Recieve a temperature change from a sensor
      message:
        correlationId:
          location: $message.header#/correlation_id
        name: Temperature
        payload:
          $ref: '#/components/schemas/temperature'
...

Channel

The most important part in the specification for the data producers are, The routing key with possible parameters and the exchange name with vhost.

Each channel represent the routing key, {sensorId}.temperature, used when binding a queue with the specified exchange. The parameters defined on the channel should describe the pattern a consumer could use to retrieve data. The x-example is a place where you can tell the consuming part how the routing key is composed. In this case the routing key contains the id of the sensor producing the temperatures. With this information the consumer can choose if it would like to recieve data from all sensors or just one specific sensor.

#.temperatures // listen for changes from all sensors
SENSOR-001.temperatures // listen for changes from one specific sensor

Channel bindings

On a channel you can specify AMQP specific values that is supposed to inform the consumer if there are a pre-existing queue you should use and what amqp channel specific properties you should use when connection to the queue.

 bindings:
      amqp:
        is: routingKey
        exchange:
          name: lkab.iot.temperature.v1.topic
          type: topic
          vhost: iot