🎄 Happy Holidays! 🥳
Most of Solace is closed December 24–January 1 so our employees can spend time with their families. We will re-open Thursday, January 2, 2024. Please expect slower response times during this period and open a support ticket for anything needing immediate assistance.
Happy Holidays!
Please note: most of Solace is closed December 25–January 2, and will re-open Tuesday, January 3, 2023.
Integration over Http
I am attempting to integrate our IBM mainframe reservation system with Solace as an alternative to IBM MQ hoping this will provide a secure and persistent delivery of messages to Kafka. The idea is that Solace will be deployed close to or on the mainframe (docker) and will provide guaranteed delivery between it and our AWS kafka instance across a number of direct links. I have managed to connect and send messages to Solace using http but have a problem in that I require the response http header to mirror a correlation id sent in the request, mainframe idiosyncrasies I am afraid. Is there a way to reflect an http request header in the response?
Best Answer
-
Hi,
I suspect you could use the Microgateway mode of the REST service to solve this.
Could you explain your flow in a bit more detail ...
How is the mainframe publishing events to Solace? Also via HTTP? If so I guess the publisher includes a correlation id as a HTTP header? The HTTP endpoint, that messages are pushed to - it will also attach the correlation id in a header in the HTTP response?Microgateway mode will preserve all HTTP headers in the request and response flow, it maps HTTP headers into the message's user properties
It may also work if the mainframe is publishing using JMS, SMF or similar but will require some more thought to make sure messages are published in a way that the Solace REST publisher (RDP) can generate the appropriate HTTTP request.Have a look at the documentation here bearing in mind that the transport layer under the covers is Solace messaging and therefore publisher and subscribers could be using other (non HTTP) protocols:
https://docs.solace.com/Configuring-and-Managing/Microgateways.htm
https://docs.solace.com/Overviews/Microgateway-Concepts/Microgateway-Use-Cases.htmYou may also find this thread and blog post useful:
https://solace.community/discussion/18/http-headers
https://retgits.com/2019/06/how-to-get-webhooks-into-your-system-using-solace-pubsub-cloud/5
Answers
-
Hi,
I suspect you could use the Microgateway mode of the REST service to solve this.
Could you explain your flow in a bit more detail ...
How is the mainframe publishing events to Solace? Also via HTTP? If so I guess the publisher includes a correlation id as a HTTP header? The HTTP endpoint, that messages are pushed to - it will also attach the correlation id in a header in the HTTP response?Microgateway mode will preserve all HTTP headers in the request and response flow, it maps HTTP headers into the message's user properties
It may also work if the mainframe is publishing using JMS, SMF or similar but will require some more thought to make sure messages are published in a way that the Solace REST publisher (RDP) can generate the appropriate HTTTP request.Have a look at the documentation here bearing in mind that the transport layer under the covers is Solace messaging and therefore publisher and subscribers could be using other (non HTTP) protocols:
https://docs.solace.com/Configuring-and-Managing/Microgateways.htm
https://docs.solace.com/Overviews/Microgateway-Concepts/Microgateway-Use-Cases.htmYou may also find this thread and blog post useful:
https://solace.community/discussion/18/http-headers
https://retgits.com/2019/06/how-to-get-webhooks-into-your-system-using-solace-pubsub-cloud/5 -
Thank you for your reply and yes the mainframe is streaming http messages over a a number of sticky connections and requires the correlation id to associate the request and response. We currently have an issue with assured delivery between our mainframe in Auckland and Confluent Kafka in the AWS cloud in Sydney and I am looking at an Auckland deployment of Solace providing this i.e. once the message is recieved and acknowledged by Solace then delivery to Sydney using the Confluent Solace source connector is assured, regardless of link status. Due to the mutable nature of the reservations system message replay is not an option and so we need to guarantee all messages will be delivered in sequence. Even with Solace this may not always be possible if the link between the mainframe and Solace is lost hence a docker instance on the mainframe which will shortly be an option for us. I did have a quick look at the Microgateway but will investigate more thoroughly and get back to you with any questions if that is ok. Many thanks
0