Applies to ReadyAPI 2.7, last modified on June 25, 2019

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).

Message delivery in AMQP

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.test
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.

AMQP functional testing

To test the functionality of AMQP services, you can create a SoapUI 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 LoadUI. You first create an AMQP test case in SoapUI, 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 LoadUI tutorial.

See Also

About Assertions

Highlight search results