AMQP Setup

Overview #

webhookie can receive events from your architecture via the Advanced Message Queueing Protocol (AMQP). The configuration for the AMQP setup is done in the Docker Compose File. Messages are sent to webhookie via a consumer queue. If there are validation errors with the message then webhookie will send the message back via a consumer missing header queue.

Connecting webhookie to your AMQP Instance #

The following configurations can be added to your Docker Compose File to connect to your AMQP instance.

Hostname #

WH_AMQP_HOST=vulture.rmq.cloudamqp.com

Virtual Host #

WH_AMQP_V_HOST=nbcwv012

Username #

WH_AMQP_USERNAME=nbcwv012

Password #

WH_AMQP_PASSWORD=lkadkjadjdkaldlal

Consumer Queue #

The consumer queue is where webhookie will consume the events.

WH_CONSUMER_QUEUE=wh-consumer.event

Consumer Missing Header Queue #

If events, that webhookie receives, are missing the mandatory headers, wh-topic and content_type, it will return the message to the Consumer Missing Header Exchange with the Consumer Missing Header Routing Key. WH_CONSUMER_MISSING_HEADER_EXCHANGE=wh-consumer

WH_CONSUMER_MISSING_HEADER_ROUTING_KEY=wh-missing-header

Sending messages to webhookie #

Messages that are sent to webhookie can have any content type. webhookie does not validate the content type or the content so it is the provider’s prerogative to ensure that the content matches the content type and the schema definition documented in the ASYNC API specification. The messages can have the following headers:

Header	Mandatory	Description
wh-topic	Yes	The wh-topic must match one of the channels provided in an ASYNC API specification.
content_type	Yes	The content type of the message content. Can be any content type e.g. application/json
wh-trace-id	No	The trace id is the unique identifier for the event being recieved by webhookie. While optional it is recommended it is provided to give you end to end traceability. If not provided webhookie will create a unique trace id upon receipt.
wh-authorized-subscriber	No	By default any subscriber to the topic will recieve the event. However as a provider you do have the choice to specify which authorized subscribers should recieve the event. These need to match the entity ids as defined by your Identity Provider. If an authorized subscriber is provided then only those subscribers will recieve that event.