2016-05-13 11 views
0

Ich habe ein Projekt, das eine JMSListener verwendet, um Nachrichten aus einer WebSphereMQ-Warteschlange zu lesen. Eine meiner Anforderungen hierfür ist, eine Verbindung zu mehreren Warteschlangen herzustellen und sie in die "Haupt" -Warteschlange zu stellen, an die der JMSListener angeschlossen ist. Dazu durchlaufe ich eine Liste von Warteschlangen und benutze IBMs MQ-Pakete, um das Durchsuchen von der Warteschlange in der Schleife und dann das Schreiben in die "Haupt" -Warteschlange durchzuführen. Das ist meine Lese- und Schreibmethoden (Nichts falsch mit ihnen, darunter nur aus Gründen der Information):Empfangen von MQMessage mithilfe von JMSListener führt zu einer Zeichenfolge mit durch Kommas getrennten Ganzzahlen

public String readFromErrorQueue(MyErrorQueue errorQueue, 
      MQGetMessageOptions getMsgOpts) throws MQException, IOException { 
     MQMessage msg = new MQMessage(); 
     String message = ""; 
     errorQueue.getQueue().get(msg, getMsgOpts); 
     message = msg.readStringOfCharLength(msg.getMessageLength()); 
     return message; 
    } 

    public void writeToHoldQueue(String message) throws IOException, 
      MQException { 
     MQMessage mqMessage = new MQMessage(); 
     mqMessage.writeString(message); 
     holdQueue.getQueue().put(mqMessage, putMsgOpts); 
    } 

Und das Haupt JMSListener ist in der Form:

@JmsListener(id ="mainQueue", destination = "${mq.queueName}") 
    public void processOrder(String message) throws Exception {...} 

Nun zu meiner Zwangslage. Wenn meine JMSListener die Nachricht empfängt, ist es in der Form "98, 122, 34, 190, ... , N" anstelle einer Kette von tatsächlichen Wörtern. Nur um zu bemerken, sind diese Werte willkürlich, da ich nicht weiß, ob die ganzen Zahlen zu einer bedeutungsvollen Nachricht entschlüsselt werden können und HIPPA ist ziemlich streng in Bezug auf dieses Zeug ... Wie auch immer, die Nachricht soll ein HL7 oder XML sein Botschaft.

Ein paar Dinge zu beachten in meinem Debugging; Ich kann die HL7/XML-Nachricht so sehen, wie sie sein soll, wenn ich die Warteschlange durchlaufe, so dass sie gut aussehen, wenn ich sie durchsuche. Bevor ich sie in die "Haupt" -Warteschlange schreibe, sehen sie gut aus. Und wenn sie in der Hauptwarteschlange sind, wenn ich den MQ Explorer öffne und den Inhalt der Nachrichten ansehe, die sich gerade in der Warteschlange befinden, sehen sie gut aus. Und schließlich zu beachten, wenn ich eine Testnachricht in die Warteschlange von MQ Explorer die JMSListener nimmt es in Ordnung.

Das führt mich zu dem Glauben, dass das Problem darin liegt, wie MQ Nachrichten in die Warteschlange mit Java-Code versetzt und wie die JMSListener sie auszieht. Und das einzige, was ich mir vorstellen kann ist, dass meine writeToHoldQueue die Nachricht als MQMessage einfügt, wo meine JMSListener einen String lesen will.

So sind meine Vermutungen richtig, was ist hier los? Warum bekomme ich statt eines Fehlers eine lange Reihe von scheinbar zufälligen, durch Komma getrennten Ganzzahlen?

Antwort

0

Das ist also ein wenig ironisch. Es stellte sich heraus, dass etwas mit meinem writeToHoldQueue() nicht stimmte. Nach dem Graben (und ehrlich mit diesem Beitrag als eine kleine Gummiente), erkannte ich, dass ich das MQMessage Format definieren kann. Im Grunde wurden alle meine Probleme mit dieser kleinen Linie gelöst ... mqMessage.format = MQConstants.MQFMT_STRING;. Jetzt nimmt mein Zuhörer unverstörte, richtige Saiten auf, wie ich sie brauche. Also mein Schreiber sieht nun wie:

public void writeToHoldQueue(String message) throws IOException, 
      MQException { 
     MQMessage mqMessage = new MQMessage(); 
     mqMessage.format = MQConstants.MQFMT_STRING; 
     mqMessage.messageType = MQConstants.MQMT_DATAGRAM; 

     mqMessage.writeString(message); 
     holdQueue.getQueue().put(mqMessage, putMsgOpts); 
    } 

Wenn jemand anderes über diese läuft ich diese beiden sorces nützlich fanden meine Lese in schriftlicher Form und schreiben: https://www.ibm.com/support/knowledgecenter/SSFKSJ_7.5.0/com.ibm.mq.dev.doc/q030840_.htm

und https://endrasenn.wordpress.com/2010/01/27/readwrite-to-ibm-mq-sample-java-code/

+0

Wenn Sie steuern die Wenn Sie an beiden Endpunkten codieren, ist 'MQFMT_STRING' für XML in Ordnung, aber seien Sie vorsichtig, wenn Sie mit' iso_1' oder 'cp1252' umgehen, sie werden wahrscheinlich durch die 'utf-8'-Kodierung verstümmelt. – Stavr00

+0

Danke für die Köpfe hoch. Ich bin mit diesen beiden Begriffen eigentlich nicht vertraut, ich werde mich darum kümmern. –