Comment traiter les objets de réponse dans le transformateur de réponse pour un accusé de réception personnalisé dans Mirth 3.0?

Question

J'utilise Mirth 3.0.1.7051.

J'ai actuellement 2 canaux de travail sur la joie 2.2.2.6388.

canal 1) test_adt_hl7_to_xml Channel 2) Test_xml_ssender

canal 1 - reçoit un message HL7, la convertit en XML personnalisé et envoyez-le au canal 2. Channel 2 - reçoit un envoi XML à un auditeur HTTP. Cela fonctionne avec un accusé de réception de la réponse XML à partir de l'auditeur HTTP. La réponse est dans un format XML.

<ADTAck>
    <Status>ERROR</Status>
    <Message>Payload does not contain a value</Message>
</ADTAck>

Je suis capable de le traiter jusqu'au bout de l'application d'envoi. Jusqu'à ce que j'allume des "files d'attente persistantes". Une fois que cela se trouve, la réponse sera toujours mise en file d'attente de la destination comme prévu. L'utilisation de la réponse Envoyer ne fonctionne pas comme la réponse est au format XML.

J'ai déplacé ces chaînes à Mirth 3.0 pour utiliser le transformateur de réponse.

Dans le transformateur de réponse, j'ai le code suivant:

var ResponseMessage = response.getMessage();
logger.info("ResponseMessage: "+ ResponseMessage.toString());
var ResponseXML = new XML(ResponseMessage.toString());
logger.info("Response XML=" + ResponseXML.toString());   
responseMap.put('ACK', ResponseFactory.getSentResponse(ResponseXML));

dans le connecteur source, sous "Paramètres de réponse-> Réponse", j'ai sélectionné "ACK"

Je suis capable de voir le contenu du contenu de l'objet de réponse dans les journaux. Mais la réponse ne se fait pas de canaliser 1 (test_adt_hl7_to_xml).

Quand j'applique:

return "My Message response";

dans le "script post-processeur", je reçois une réponse. Mais je ne peux pas accéder à l'objet de réponse ("ACK") que le "transformateur de réponse" créé.

J'ai lu chaque fil "réponse" sur ce forum. Essayé Mirth version 2.x et maintenant la version 3. Mais je ne vous rapproche pas d'une solution.

Comment puis-je traiter correctement l'objet de réponse afin que le canal 1 reçoit la réponse XML?

Merci beaucoup d'avance pour votre aide.

Answer 1

Ma solution avec Mirth v3.01: Sur le transformateur de canaux source (Test_adt_hl7_to_xml):

globalMap.put("ADTRESPONSE","");
globalMap.put("ADTRESPONSEREADYFLAG","false");

sur le transformateur de réponse de canal final de réponse (Test_xml_sender) - Mettez à jour le drapeau de réponse.

if (response.getMessage() != '') 
{
    var ResponseMessage = response.getMessage()
    var ResponseXML = new XML(ResponseMessage.toString());
    globalMap.put("ADTRESPONSE",ResponseXML.toString());
    globalMap.put("ADTRESPONSEREADYFLAG","true");
}else{//wait if queued}

sur le canal final de réponse post-processeur (Test_xml_sender) - Définissez le paramètre de réponse sur "Poster le processeur" Ecrivez une boucle tandis que(Utilisez un temps-out si vous voulez ne pas vouloir attendre pour toujours)

var ADTResponseReadyFlag = globalMap.get("ADTRESPONSEREADYFLAG");

if(debug)logger.info("Start Response Wait")
while(ADTResponseReadyFlag == "false")
{
  ADTResponseReadyFlag = globalMap.get("ADTRESPONSEREADYFLAG");
}
if(debug) logger.info("End Response Wait")
return globalMap.get("ADTRESPONSE");

Answer 2

Réponse de: "Narupley" Employé de Mirth

Si votre destination a une file d'attente activée, il n'a aucun sens de répondre de cette destination (ou d'une variable personnalisée créée par le transformateur de réponse de la destination).L'ensemble du point de file d'attente de destination consiste à abandonner un message de réception dans une file d'attente et de passer à autre chose.Il n'y aurait rien à répondre, car votre destination n'a même pas encore envoyé le message.

Il y a des façons haçonneuses autour de cela, mais vous devriez probablement repenser votre flux de travail de message / canal.Généralement, cela se fait en déplaçant le point de faire la queue plus élevée dans la chaîne.Donc, si le canal 1 envoie au canal 2 qui envoie à un système sortant et que le canal 1 doit recevoir la réponse du système sortant, puis le canal 1 doit être celui avec la mise en file d'attente de destination activée et non canal 2. Bien sûr que cela signifie que laLe système d'origine envoyé au canal 1 en premier lieu ne pourrait pas recevoir cette réponse.