6
votes

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!

2

2 Answers

2
votes

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.

-1
votes

Making an Asynchronous datasource Synchronous can indeed be tricky. But I don't really see an issue with your request-reply strategy.

Try to use an request-reply with WMQ endpoint on both sides. Then monitor the queues and see that the message and reply arrives as they should. Do you use the same queue for the request and the reply? The simplest scenario would be to use different ones, is that possible for your use-case?