Sometimes you need to get data from cloud-based systems into an environment that doesn’t expose APIs or ports to the outside world. Webhooks help, but you still need something that accepts them and gets them across your firewall. That’s exactly where Solace PubSub+ Cloud comes in. I built a small webhook forwarder app that receives data from Solace and sends it onward without any of my systems being exposed to the internet.
I initially looked at PubNub for this, and while it mostly worked, there was one major gap. In some of my use cases, I needed the HTTP header information (like X-GitHub-Delivery or X-Hub-Signature when using GitHub webhooks), and PubNub couldn’t pass those through.
A friend, Jeremy Meiss, pointed me to Solace and said it would solve all my messaging needs. After some head-scratching and doc-reading, I got it working nicely. And honestly, one of their best features is probably that it’s free 😇!
By default, the Solace PubSub+ Cloud instance is set to “messaging” mode, which strips non-standard HTTP headers from messages. To fix that, you switch it to “microgateway” mode, which preserves any received HTTP header fields as metadata on the Solace message. In the web console, you can change this under Message VPN -> Connectivity — set the mode to “Gateway”.
With gateway mode enabled, the Solace microgateway adds all non-standard headers to your message as JMS_Solace_HTTP_field_<header>.
The other thing I ran into: most REST requests don’t include a correlation ID. The microgateway uses that field to correlate requests with responses. If it’s absent, the gateway generates an appMessageID and uses that instead.
The problem is that the default session.sendReply() method grabs the correlationID from the original message if you provide one to reply to (which I figured out after reading the API docs for the session object). When I manually construct the reply and set the destination and correlation ID headers myself, it works perfectly. The response should look like this:
var reply = solace.SolclientFactory.createMessage();
reply.setAsReplyMessage(true);
reply.setDestination(message.getReplyTo());
reply.setCorrelationId(message.getApplicationMessageId());
subscriber.session.sendReply(null,reply)This sends back an empty message, but the gateway responds with an HTTP/200 status. In my case, that means I can have GitHub send webhooks to the Intel NUC on my desk without the IT team opening firewall ports (I’m sure they’re very happy with that 😅). Solace made the IT and security team happy — and they’ve likely done the same for a lot of other companies too 😎
If you want to see the code, check out my GitHub repository and let me know your thoughts either on Twitter or here.
Cover image by Peter H from Pixabay
