2015-06-16 6 views
6

Ich versuche, WebMQ synchron in MULE zu agieren, um die Nachrichtenwarteschlange in eine REST-API für ein internes Projekt umzuwandeln. Leider weiß ich sehr wenig über MULE.WebMQ synchron machen

Nach ein bisschen Arbeit, begann ich zu verstehen, die Request-Reply-Bereich und versuchte, den WMQ Connector damit zu verwenden, nur um herauszufinden, dass WMQ sendet nur, wenn der Ablauf beendet ist.

Ich habe versucht, die Anfrage in einen anderen Fluss setzen VM verwenden sie auslösen

aber so weit das führt nur um es für immer auf WMQ warten, die nie passieren wird.

Ich habe auch für wieder mit VMs versucht und her:

Aber es scheint, als ohne das Gleiche zu tun, wo es einfach ignoriert die Eingabe.

Jetzt weiß ich, dass die Eingabe und Ausgabe für die WMQ arbeiten, wie ich zuvor einen Fluss eingerichtet, der HTTP verwendet, um mit sich selbst zu kommunizieren und lassen Sie es wissen, wenn eine Nachricht durchging.

Was will ich im Wesentlichen ist dies, aber HTTP anstelle von AJAX

Meine letzte und vielleicht sieht am nächsten Versuch wie so:

Die XML Sein:

<?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> 

Was fast funktioniert, aber es hängt auf unbestimmte Zeit, ohne eine Antwort an den HTTP-Server zu senden. Wenn der vm: inbound-endpoint im Request-Reply-Flow auf unidirektional gesetzt wird, verhindert er, dass er hängt, sendet aber nicht die neue Payload, die empfangen wurde, sondern stattdessen die vorherige Payload (als ob sie übersprungen wird).

Jede Hilfe würde sehr geschätzt werden!

Antwort

2

Wenn ich richtig verstanden habe, versuchen Sie nur, eine Anfrage in einer Warteschlange und eine Antwort auf eine bekannte Warteschlange als eine REST API offenzulegen.

Dort sind keine VM-Warteschlangen erforderlich und auch keine Request-Reply-Elemente, da der JMS-Transport das Austauschmuster der Anfrageantwort simulieren kann.

JMS-Warteschlangen sind nur eine Möglichkeit. Sie müssen unbedingt auf eine andere Warteschlange antworten. Die Logik hinter einem Anfrage-Antwort-Szenario ist ein Outbound-Endpunkt mit einer Outbound-Eigenschaft: MULE_REPLYTO.Diese Eigenschaft sollte mit dem Namen Ihrer bekannten Antwort auf die Warteschlange festgelegt werden: GET_QUEUE (wenn keine solche Kopfzeile bereitgestellt wird, wird eine temporäre Warteschlange erstellt).

Die MULE_REPLY zu Header wird der Standard JMSReplyTo werden, wenn das Mesasge am Dienst empfangen wird. Der Dienst muss diesem Header, der die Antwort zurück an diese Warteschlange sendet, zu Ehren. Wenn der Dienst auf Mule implementiert wird, geschieht dies automatisch, andernfalls könnte dies nicht passieren. Sie sollten überprüfen, ob es geehrt wird.

Wenn Sie einen Anfrage-Antwort-Bereich mit Einweg-Endpunkten anstatt einem Anfrage-Antwort-Endpunkt verwenden möchten, ist es in Ordnung, sollte das gleiche, aber mit mehr Code funktionieren.

-1

Eine asynchrone Datenquelle erstellen Synchron kann in der Tat schwierig sein. Aber ich sehe kein Problem mit Ihrer Anfrage-Antwort-Strategie.

Versuchen Sie eine Anfrage-Antwort mit WMQ-Endpunkt auf beiden Seiten zu verwenden. Überwachen Sie dann die Warteschlangen und stellen Sie sicher, dass die Nachricht und die Antwort wie erwartet ankommen. Verwenden Sie die gleiche Warteschlange für die Anfrage und die Antwort? Das einfachste Szenario wäre, andere zu verwenden, ist das für Ihren Anwendungsfall möglich?

+0

Sie sind verschiedene Warteschlangen. Das Problem mit wmq in der Request-Antwort ist, dass das Senden an wmq erst ausgeführt wird, wenn der Flow gemäß der Dokumentation von mule abgeschlossen ist – Navarr

Verwandte Themen