About AMQP
The Advanced Message Queueing Protocol (AMQP) is an open standard application layer protocol for message-oriented middleware. Its core features are message orientation, queuing, routing, security, reliability and interoperability. These features make it perfect for passing business messages between organizations and applications. AMQP can also be used as an Internet-of-Things (IoT) protocol.
Client-Server Message Pattern
In AMQP, applications that send messages (known as publishers) post messages to AMQP brokers that distribute them to applications that process messages (consumers).
The internal structure or an AMQP broker includes three types of entities: exchanges, queues and bindings. Messages posted to a broker first go to an exchange. Then, the exchange will route the message to a queue that is bound to the exchange using special rules called bindings. Each exchange can have zero or more queues bound to it. Lastly, consumers will receive the messages from the queue (they can be subscribed to it, or the user can fetch the messages manually).
Click the image to enlarge it.
Message routing
Both bindings and messages contain strings called routing keys that the broker uses to decide where to route the message.
The mode of routing messages from an exchange to a queue is based on the type of the exchange. There are four types of exchanges:
Direct
Direct exchanges route messages to queues that are bound to them if the binding routing key is identical to the message routing key.
Fanout
Fanout exchanges route messages to all the queues that are bound to them. The message routing key is ignored.
Topic
Topic exchanges route messages to bound queues if the message routing key matches the pattern specified in the binding routing key.
The routing keys of messages sent to a topic exchange must be a list of dot-separated words. Here are some examples:
office.server.update
office.client.test
The same applies to binding routing keys too, however, there can use wildcards instead of words:
| Symbol | Description |
|---|---|
| * | Substitutes one word. For example, a queue bound with the office.server.* routing key will receive messages with routing keys 1 and 2 from the example above, but not 3. |
| # | Substitutes zero or more words. For example, a queue bound with the office.# routing key will receive messages with routing keys 1, 2 and 3 from the example above. |
Headers
Headers exchanges route messages to bound queues based on multiple attributes expressed as message headers rather that the routing key.
AMQP testing in ReadyAPI
ReadyAPI can act both as a publisher and as a consumer for your AMQP broker. You can use it to create functional and load tests.
You need a ReadyAPI Test Pro license to perform AMQP testing in ReadyAPI. If you do not have it, you can request it on our web site or start a trial.
AMQP functional testing
To test the functionality of AMQP services, you can create a functional test that uses AMQP-related test steps.
| Test Step | Description |
|---|---|
| AMQP Declare Exchange | Creates an exchange on an AMQP broker. |
| AMQP Declare Queue | Creates a queue on an AMQP broker. |
| AMQP Bind Queue | Binds a queue to an exchange. |
| AQMP Publish | Sends a message to an exchange. |
| AMQP Receive | Fetches a message from a queue. |
The connection is established directly to the broker, so you do not need to use a WebSocket server for this.
ReadyAPI cannot mock the AMQP broker, so you will need to use a real AMQP broker.
AMQP load testing
To see how your AMQP services perform under a heavy load, you create a load test in ReadyAPI. You first create an AMQP test case, and then create a load test that simulates this test case with dozens and hundreds of virtual users running locally or on a remote machine. See the Load testing tutorial.