I'm trying to make WebMQ act synchronously in MULE in order to turn the message queue into a REST api for an internal project. Unfortunately, I know very little about MULE.
After a good bit of work, I started understanding the Request-Reply scope and tried to use the WMQ Connector with it, only to find out that WMQ only sends once the flow has ended.
I've tried putting the request into a different flow using VM to trigger it
but so far that just leads to it waiting forever on WMQ that will never happen.
I've also tried using VMs for back and forth:
But it seems to do the same thing as without, where it just ignores the input.
Now I know the input and output for the WMQ are working, as I previously setup a flow that used http to communicate with itself and let it know when a message went through.
What I essentially want is this, but using HTTP instead of AJAX
My latest, and perhaps closest attempt looks like thus:
The XML being:
<?xml version="1.0" encoding="UTF-8"?>
<mule xmlns:vm="http://www.mulesoft.org/schema/mule/vm" xmlns:http="http://www.mulesoft.org/schema/mule/http" version="EE-3.6.0" xmlns="http://www.mulesoft.org/schema/mule/core" xmlns:ajax="http://www.mulesoft.org/schema/mule/ajax" xmlns:core="http://www.mulesoft.org/schema/mule/core" xmlns:doc="http://www.mulesoft.org/schema/mule/documentation" xmlns:ee="http://www.mulesoft.org/schema/mule/ee/core" xmlns:json="http://www.mulesoft.org/schema/mule/json" xmlns:spring="http://www.springframework.org/schema/beans" xmlns:stdio="http://www.mulesoft.org/schema/mule/stdio" xmlns:test="http://www.mulesoft.org/schema/mule/test" xmlns:tracking="http://www.mulesoft.org/schema/mule/ee/tracking" xmlns:wmq="http://www.mulesoft.org/schema/mule/ee/wmq" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.mulesoft.org/schema/mule/ajax http://www.mulesoft.org/schema/mule/ajax/current/mule-ajax.xsd
http://www.mulesoft.org/schema/mule/ee/wmq http://www.mulesoft.org/schema/mule/ee/wmq/current/mule-wmq-ee.xsd
http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-current.xsd
http://www.mulesoft.org/schema/mule/core http://www.mulesoft.org/schema/mule/core/current/mule.xsd
http://www.mulesoft.org/schema/mule/ee/core http://www.mulesoft.org/schema/mule/ee/core/current/mule-ee.xsd
http://www.mulesoft.org/schema/mule/stdio http://www.mulesoft.org/schema/mule/stdio/current/mule-stdio.xsd
http://www.mulesoft.org/schema/mule/test http://www.mulesoft.org/schema/mule/test/current/mule-test.xsd
http://www.mulesoft.org/schema/mule/json http://www.mulesoft.org/schema/mule/json/current/mule-json.xsd
http://www.mulesoft.org/schema/mule/ee/tracking http://www.mulesoft.org/schema/mule/ee/tracking/current/mule-tracking-ee.xsd
http://www.mulesoft.org/schema/mule/http http://www.mulesoft.org/schema/mule/http/current/mule-http.xsd
http://www.mulesoft.org/schema/mule/vm http://www.mulesoft.org/schema/mule/vm/current/mule-vm.xsd">
<wmq:connector channel="MAGENTO.SVRCONN" doc:name="WMQ Connector" hostName="[ip]" name="wmqConnector" port="1414" queueManager="MAGENTO" transportType="CLIENT_MQ_TCPIP" validateConnections="true" />
<vm:connector name="VM" validateConnections="true" doc:name="VM">
<vm:queue-profile maxOutstandingMessages="500">
<default-persistent-queue-store/>
</vm:queue-profile>
</vm:connector>
<http:listener-config name="HTTP_Listener_Configuration" host="0.0.0.0" port="8081" doc:name="HTTP Listener Configuration"/>
<flow name="Input">
<http:listener config-ref="HTTP_Listener_Configuration" path="/mq" doc:name="HTTP"/>
<set-payload value="#[message.inboundProperties.'http.query.params'.xml]" doc:name="Set Payload"/>
<logger message="Entering Request-Reply Payload: #[payload]" level="INFO" doc:name="Logger"/>
<request-reply doc:name="Request-Reply">
<vm:outbound-endpoint exchange-pattern="one-way" path="mq" connector-ref="VM" doc:name="VM_TriggerSend" />
<vm:inbound-endpoint exchange-pattern="request-response" path="mq-return" connector-ref="VM" doc:name="VM_Receive" />
</request-reply>
<logger message="Request-Reply has ended. Payload: #[payload]" level="INFO" doc:name="Logger"/>
</flow>
<flow name="Send_Message">
<vm:inbound-endpoint exchange-pattern="one-way" path="mq" connector-ref="VM" doc:name="VM_Send"/>
<logger message="(Preparing to Dispatch) Payload: #[payload]" level="INFO" doc:name="Logger"/>
<wmq:outbound-endpoint queue="PUT_QUEUE" connector-ref="wmqConnector" doc:name="WMQ"/>
<logger message="Message presumably being dispatched after this log" level="INFO" doc:name="Logger"/>
</flow>
<flow name="Receive_Message">
<wmq:inbound-endpoint queue="GET_QUEUE" connector-ref="wmqConnector" doc:name="WMQ_Receive" />
<logger message="Triggering Receive" level="INFO" doc:name="Logger"/>
<vm:outbound-endpoint exchange-pattern="request-response" path="mq-return" connector-ref="VM" doc:name="VM_TriggerReceive" />
</flow>
</mule>
Which almost works, but it hangs indefinitely without sending a response back to the HTTP server. Setting the vm:inbound-endpoint in the Request-Reply flow to one-way keeps it from hanging, but doesn't send the new payload that's been received, but instead the previous payload (as if it's being skipped over).
Any help at all would be greatly appreciated!
Synchronous and Asynchronous Consumption There are two ways an MQ C client can consume messages: either synchronously or asynchronously.
WebSphere MQ synchronous. A figure shows the basic mechanism of program-to-program communication using a synchronous communication model.
If I understood correctly you are just trying to expose a request on a queue and a response on a well known queue as a REST api.
There is no need of VM queues there, and neither request-reply elements as the JMS transport can simulate the request response exchange pattern.
JMS queues are just one way. You have to necesarily reply on a different queue. The logic behind a request-response scenario is an outbound-endpoint that having an outbound property: MULE_REPLYTO
. This property should be set with the name of your well known reply to queue: GET_QUEUE (if no such header is provided a temporary queue will be created).
The MULE_REPLY to header will become the standard JMSReplyTo
when the mesasge is received at the service. The service has to honor this header sending the reply back to that queue. If the service is implemented on Mule this will happen automatically, otherwise it might not happen. You should double check its being honored.
If you want to use a request-reply scope with to one-way endpoints rather than one request-reponse endpoint, it is fine, should work the same but with more code.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With