2015-06-16 10 views
6

Sto tentando di far sì che WebMQ funzioni in modo sincrono in MULE per trasformare la coda dei messaggi in una API REST per un progetto interno. Sfortunatamente, so molto poco di MULE.Creazione di WebMQ Synchronous

Dopo un po 'di lavoro, ho iniziato a comprendere l'ambito di richiesta di risposta e ho provato a utilizzare il connettore WMQ con esso, solo per scoprire che WMQ invia solo una volta terminato il flusso.

Ho provato a mettere la richiesta in un flusso diverso utilizzando VM per innescare lo

ma finora che porta solo ad esso in attesa per sempre su WMQ che non accadrà mai.

Ho anche provato ad utilizzare macchine virtuali per avanti e indietro:

ma sembra di fare la stessa cosa, senza, dove solo ignora l'input.

Ora so che l'input e l'output per il WMQ funzionano, poiché ho precedentemente configurato un flusso che utilizzava http per comunicare con se stesso e far sapere quando un messaggio è passato.

Quello che in sostanza voglio è questo, ma utilizzando HTTP invece di AJAX

Il mio ultimo, e forse il tentativo più vicino assomiglia così:

L'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> 

Che quasi funziona, ma si blocca indefinitamente senza inviare una risposta al server HTTP. L'impostazione di vm: endpoint in entrata nel flusso di richiesta di risposta a senso unico evita che si blocchi, ma non invia il nuovo payload che è stato ricevuto, ma invece il payload precedente (come se venisse saltato).

Qualsiasi aiuto sarebbe molto apprezzato!

risposta

2

Se ho capito correttamente, si sta solo tentando di esporre una richiesta su una coda e una risposta su una coda ben nota come API REST.

Non vi è alcuna necessità di code di macchine virtuali e gli elementi di richiesta-risposta come il trasporto JMS possono simulare il modello di scambio di risposte di richiesta.

Le code JMS sono solo un modo. Devi necessariamente rispondere su una coda diversa. La logica dietro uno scenario di richiesta-risposta è un endpoint in uscita che ha una proprietà in uscita: MULE_REPLYTO.Questa proprietà deve essere impostata con il nome della ben nota risposta alla coda: GET_QUEUE (se non viene fornita alcuna intestazione di questo tipo, verrà creata una coda temporanea).

L'intestazione MULE_REPLY to diventa lo standard JMSReplyTo quando il mesasge viene ricevuto al servizio. Il servizio deve onorare questa intestazione che invia la risposta a tale coda. Se il servizio è implementato su Mule, ciò avverrà automaticamente, altrimenti potrebbe non accadere. Dovresti controllare che sia onorato.

Se si desidera utilizzare un ambito di richiesta-risposta con endpoint unidirezionali anziché un endpoint di richiesta-risposta, va bene, dovrebbe funzionare allo stesso modo ma con più codice.

-1

Creazione di un'origine dati asincrona Sincrona può essere davvero complicata. Ma in realtà non vedo un problema con la tua strategia di richiesta-risposta.

Provare a utilizzare una richiesta-risposta con endpoint WMQ su entrambi i lati. Quindi controlla le code e verifica che il messaggio e la risposta arrivino come dovrebbero. Usi la stessa coda per la richiesta e la risposta? Lo scenario più semplice sarebbe quello di utilizzare quelli diversi, è possibile per il tuo caso d'uso?

+0

Sono code diverse. Il problema con wmq nella risposta alla richiesta è che l'invio a wmq non viene eseguito fino a quando il flusso non viene completato secondo la documentazione di mule – Navarr