Message Exchange Patterns

This section describes success and failure scenarios for common message exchange patterns.

A Solace PubSub+ event broker treats persistent and non-persistent message in the same manner. Therefore, the following diagrams are simplified and only show persistent messages.

REST Producer One-Way POST to Solace

HTTP Header Example

POST /TOPIC/test/news HTTP/1.1 
Host: sol-ny-prod-0001:8080 
Solace-Time-To-Live-In-ms: 20000
Solace-Delivery-Mode: persistent
Solace-DMQ-Eligible: true
Content-Length: 1000

Success Case Message Exchange

Solace One-Way POST to REST Consumer

HTTP Header Example

POST /Request/Target HTTP/1.1 
Host: sol-ny-prod-0001:8080 
Content-Length: 1000

Success Case Message Exchange

A REST consumer must respond with a success status code such as 200 OK if it successfully receives the message. The event broker will retry delivery of messages to the REST consumer for all failure status codes according to its provisioned configuration (one example being the Max Retry setting on the associated Queue).

In this example, the event broker discards any payload returned in the body of a 200 OK. Content in the body of a 200 OK is only processed in the request reply scenario as indicated by the presence of a reply-to destination in the Solace SMF message. Refer to REST Producer Request with Async Reply to Destination for details.

Failure Scenario Message Exchange

In this scenario, message error handling consists of the following:

If there are redelivery attempts that remain based on Queue settings, message redelivery will be attempted.
When retries are exhausted, then normal DMQ handling applies. This means that if message is DMQ eligible it will be placed on the DMQ. Otherwise the message will be discarded with a statistic.

REST Producer Request/Reply

HTTP Header Example

POST /TOPIC/test/news HTTP/1.1 
Host: sol-ny-prod-0001:8080
Solace-Reply-Wait-Time-In-ms: 10000
Content-Length: 1000

Success Case Message Exchange

A synchronous reply message from the event broker to the REST producer is a Direct message. This means that the reply message is not placed in a persistent queue before delivery regardless of whether the request message was persistent or Direct. It is not necessary to persist the reply message because if a failure occurs in returning the reply (for example, if a Solace PubSub+ event broker activity switch or REST producer reset occurs), then the HTTP connection will fail so there is no way to return the reply to the request.

If the consumer wants to provide a processing error in the reply message, it can encode the error message in the reply message body. The REST producer will then receive it as a 200 OK with the error contents as the body of the 200 OK status code. From a transport perspective, the 200 OK indicates that the request and reply were received successfully. The body of the reply indicates to the application whether the consumer correctly handled the request.

Failure Scenario Message Exchange

The following sequence diagram outlines the interactions that can occur for a request reply scenario.

REST Producer Request with Async Reply to Destination

HTTP Header Example

POST /QUEUE/test/news HTTP/1.1 
Host: sol-ny-prod-0001:8080 
Solace-Time-To-Live-In-ms: 20000
Solace-Delivery-Mode: persistent
Solace-DMQ-Eligible: true
Solace-Reply-To-Destination: /QUEUE/my/reply
Content-Length: 1000

Success Case Message Exchange

The following diagram shows an application that is acting as both a REST producer and as a REST consumer for asynchronous replies. In this example, a Solace persistent message is used. However, the message exchange pattern also applies to Direct messages.

Failure Scenario Message Exchange

This message exchange pattern is a combination of REST Producer One-Way POST to Solace and Solace One-Way POST to REST Consumer. Therefore, the failure scenarios are a combination of these two scenarios and are not restated here.

Solace Request/Reply to REST Consumer

This scenario is similar to that described in Solace One-Way POST to REST Consumer. The REST consumer receives a POST from the event broker, but this POST will contain the Solace-Reply-Wait-Time-In-ms header that indicates that the event broker expects a reply to this message.

A REST consumer can encode any reply in the body of the 200 OK POST response that it returns to the event broker. If the originating Solace request message contains a reply-to field, then a Solace reply message is generated with the body containing the contents of the 200 OK POST response. An empty 200 OK POST response generates an empty reply message. The event broker treats any such reply message as a direct message, though it may subsequently promote the direct message to a guaranteed message based on the reply-to queue or topic.

Again similar to Solace One-Way POST to REST Consumer, a REST consumer must respond with a success status code such as 200 OK if the message was successfully received. This is true even if the processing of the message results in an application error condition. Depending on the retry configuration in the CLI, the event broker can retry to deliver messages for all failure status codes. The REST consumer can encode any error details in the body of the 200 OK POST response.

HTTP Header Example

POST /Request/Target HTTP/1.1 
Host: sol-ny-prod-0001:8080 
Solace-Reply-Wait-Time-In-ms: 10000
Content-Length: 1000

Provide feedback