Postman is perhaps the most popular tool for quickly bootstrapping RESTful interactions. Since Solace PubSub+ Software Event Broker natively supports several protocols including HTTP, it makes sense to explore some of what PubSub+ Event Broker offers using Postman.
In this tutorial, we’ll use a rudimentary request and reply scenario to produce HTTP to the broker and consume the request as JMS on the backend. Notice that we don’t need to write any API transformation. PubSub+ Event Broker seamlessly translates between HTTP and JMS for us.
Specifically:
Figure 1: Simple Application for Postman
For brevity we avoid the use of TLS on either end. Also, the reply is sent on a dynamically generated reply topic, which I haven’t shown.
Simple Springboot JMS Consumer
This is probably the easiest step in the entire tutorial! We setup a cloud instance of the broker to allow for communication between Postman and our backend consumer, as depicted in Figure 1.
If you already have an account, you can skip this step.
Before we wire up any applications, let’s set up Postman to interact with the broker.
/T/service/request to the Host URL in Postman. This routes the request to the T/service/request topic on the broker.
Our Springboot JMS consumer replies to any requests received on T/service/request. Spring handles the JMS configuration boilerplate, leaving us free to focus on the relevant application logic.
Using JMS with Spring is a deep topic outside the scope of this tutorial. Read this tutorial to learn the details.
We import Solace’s Springboot starter to make life easier.
<dependency> <groupId>com.solace.spring.boot</groupId> <artifactId>solace-jms-spring-boot-starter</artifactId> <version>3.2.0</version> </dependency>
This is the primary class that processes messages received on T/service/request and replies appropriately. As you can see, all the code does is reply with “Hello” prepended to the request body.
package com.solace.jmshelloworld;
import org.springframework.jms.annotation.JmsListener;
import org.springframework.stereotype.Component;
@Component
public class Receiver {
@JmsListener(destination = "${app.jms.topic}", containerFactory = "myFactory")
public String receiveMessage(String message) {
System.out.printf("Received <%s>\n", message);
return "Hello " + message + "!";
}
}
We set the various properties used by both our service and the Solace PubSub+ Springboot starter.
You can get the PubSub+ Event Broker properties from Solace Messaging > Solace JMS API under the Connect tab of your Solace PubSub+ Event Broker: Cloud instance. Be sure to select View By: Protocol in the top right hand.
#Solace properties solace.jms.host = tcp://mr1ilyoa01l8fn.messaging.solace.cloud:20352 solace.jms.msgVpn = msgvpn-1nljqp0y1add solace.jms.clientUsername= <u>solace-cloud-client solace.jms.clientPassword= <u>a29qovgiu8io1buvub6pm3gbv4 #Topic for incoming request app.jms.topic = T/service/request
We start the service from the command line using mvn clean spring-boot:run
Assuming everything was configured correctly, the application should fire up and begin listening for request messages.
Since this is a request/reply exercise, we need to ask PubSub+ Event Broker to keep the HTTP session open for a reply. We do this by setting the Solace-Reply-Wait-Time-In-ms to a reasonable value in milliseconds. This also has the effect of creating a temporary reply-topic on the broker where our Springboot service will send responses.
Finally, put your name (or any string, really) in the Body.
Time to test what we built! You should have the following configured and running:
T/service/requestSave your Postman request and click Send. If everything goes well, Postman will receive a greeting from the backend service.
That’s it! In a few easy steps, we were able to:
The PubSub+ Event Broker took care of all the necessary API and protocol transformations for us.
Subscribe to Our Blog
Get the latest trends, solutions, and insights into the event-driven future every week.
By submitting this form, you agree to Solace’s privacy policy: solace.com/privacy-policy/