Comment puis-je rechercher une Websphere MQ message sans l'enlever?

Je suis en train d'écrire une .NET Windows Forms application qui vous permettra d'envoyer un message à un Websphere MQ file d'attente et d'interroger une autre file d'attente pour une réponse. Si une réponse est renvoyée, l'application sera partiellement processus de la réponse en temps réel. Mais la réponse doit rester dans la file d'attente pour qu'un lot quotidien de travail, qui se lit aussi à partir de la file d'attente de réponse, peut faire le reste du traitement.

J'ai été aussi loin que la lecture du message. Ce que je n'ai pas été en mesure de savoir comment le lire sans le supprimer.

Voici ce que j'ai obtenu jusqu'à présent. Je suis un MQ newbie, donc toutes les suggestions seront appréciées. Et n'hésitez pas à réagir en C#.

Public Function GetMessage(ByVal msgID As String) As MQMessage
    Dim q = ConnectToResponseQueue()
    Dim msg As New MQMessage()
    Dim getOpts As New MQGetMessageOptions()
    Dim runThru = Now.AddMilliseconds(CInt(ConfigurationManager.AppSettings("responseTimeoutMS")))
    System.Threading.Thread.Sleep(1000) 'Wait for one second before checking for the first response'
    While True
        Try
            q.Get(msg, getOpts)
            Return msg
        Catch ex As MQException When ex.Reason = MQC.MQRC_NO_MSG_AVAILABLE
            If Now > runThru Then Throw ex
            System.Threading.Thread.Sleep(3000)
        Finally
            q.Close()
        End Try
    End While
    Return Nothing 'Should never reach here'
End Function

REMARQUE: je n'ai pas vérifié que mon code fait supprime le message. Mais c'est comme ça que je comprends MQ pour travailler, et cela semble être ce qui se passe. Veuillez me corriger si ce n'est pas le comportement par défaut.

+1 - je souhaite que j'avais découvert à cette question avant que j'ai eu à le comprendre par moi-même.

OriginalL'auteur John M Gant | 2009-06-24

11

Vous devez ouvrir la file d'attente avec MQOO_BROWSE option. Ensuite, sur votre de lire d'abord vous faire un GET à l'aide de la MQGMO_BROWSE_FIRST option. Enfin, de votre GET doit utiliser le MQGMO_BROWSE_NEXT option.

Remarque: MQOO est MQ options d'ouverture et de MQGMO est MQ Obtenir les Options de Message.

Qui l'a obtenu. Merci beaucoup.
Brillante réponse. J'ai sauvé ma peau aujourd'hui. Je vous remercie.

OriginalL'auteur mamboking
1

Vous devriez vraiment le faire avec des files d'attente distinctes. La Fin de la Journée de traitement doit avoir sa propre file d'attente. Après le traitement de votre partie du message, l'envoyer à l'EOD de la file d'attente.

Avec l'option Parcourir, vous allez avoir à garder une trace de ce que les messages que vous avez déjà traité quelque part.

Aussi, vous pouvez définir un délai d'attente sur le. Si vous n'avez pas besoin "d'attendre 1 sec avant de vérifier la file d'attente". Comme l'écrit à droite maintenant, vous ne pouvez pas frapper le pas de msg disponibles condition, parce que vous n'avez pas défini de NOWAIT dans le message d'options.

+1 Bon point. Je n'ai pas mentionné dans mon post que je suis en train de faire une seule requête et de la réponse à un moment. L'ID de corrélation de la réponse doit correspondre à l'ID de message de la demande, afin de garder une trace des messages que j'ai déjà traité ne devrait pas être un problème. Aussi loin que le délai d'attente, je l'avais vu, mais n'avait pas compris quoi faire avec elle. J'ai fait un peu plus de recherche basé sur votre suggestion et nettoyés de la méthode considérablement utilisant cette approche. Merci beaucoup!

OriginalL'auteur jmucchiello

Dans un souci de postérité, voici une (je pense) beaucoup version améliorée de la méthode basée sur mamboking et jmucchiello réponses.

Public Function GetMessage(ByVal correlID As Byte()) As MQMessage
    Dim waitInterval = CInt(ConfigurationManager.AppSettings("responseTimeoutMS"))
    Dim q As MQQueue = Nothing
    Try
        Dim msg As New MQMessage()
        Dim getOpts As New MQGetMessageOptions()
        q = ConnectToResponseQueue()
        msg.MessageId = MQC.MQMI_NONE
        msg.CorrelationId = correlID
        getOpts.MatchOptions = MQC.MQMO_MATCH_CORREL_ID
        getOpts.WaitInterval = waitInterval
        getOpts.Options = MQC.MQGMO_BROWSE_FIRST Or MQC.MQGMO_WAIT
        q.Get(msg, getOpts)
        Return msg
    Finally
        If q IsNot Nothing AndAlso q.IsOpen() Then q.Close()
    End Try
End Function

OriginalL'auteur John M Gant

1

Je me rends compte que je suis venue à cette discussion un peu tard et vous avez probablement déjà codé de cette application. Dans le cas où vous auriez besoin de les modifier ou de toute autre personne qui pourrait avoir besoin pour faire quelque chose de similaire, j'ai un couple d'observations.

D'abord, si vous pouvez le faire avec une v7 QMgr et une v7 WMQ client ce serait la meilleure solution. En v7, la .Net de soutien a été déplacé à partir d'un SupportPac à une partie du produit de base. Il ya beaucoup de nouvelles fonctionnalités, quelques corrections de bugs et une meilleure performance. Aussi, sur la v7, vous pouvez utiliser pub-sub...ce qui m'amène à ma deuxième observation.

Basée sur la description dans le post original, je l'aurais fait cette Pub-Sub. L'application qui met le message ne mettez qu'un seul et il n'a même pas besoin de savoir c'est mettre à un sujet. Vous pouvez effectivement mis en place un alias sur un sujet qui la fait ressembler à une file d'attente pour le message producteur. Votre consommation apps pouvez ensuite vous abonner ou vous pouvez faire deux administrative des abonnements, de sorte que les messages publiés aller à deux files d'attente que vous désignez. Votre apps, puis de chaque une file d'attente et pas de modifications de codage sont impliqués pour le producteur et le lot de l'app, c'est juste de la configuration. Bien sûr, l'application de conduire les opérations auront besoin de consommer les messages plutôt que de les parcourir.

Les avantages sont nombreux:
- Que la file d'attente se remplit de messages, l'indexation obtient vidé sur le disque et au-dessus d'un seuil que vous verrez un gain de performance qui peuvent être importants. Par conséquent, la méthode actuelle n'est pas tout ce que bien.
- Avec la pub-sub méthode, vous pouvez avoir plusieurs instances de la, soit en temps réel ou par lots applications ou les deux, et ceux-ci peuvent être les mêmes ou différents QMgr. Mise à l'échelle est facile.
- Vous éliminer la dépendance entre le temps réel et batch applications qui ont besoin d'être sur la même QMgr.
- Plus transparent de l'administration. Si vous voyez des messages s'accumulent dans le temps réel de la file d'attente que vous savez que vous avez un problème.
Un couple de différents problèmes ici. Un de ces moyens est l'utilisation de l'Échec si la Suspension de l'option. Le but de ceci est que, lorsque le QMgr est fermée correctement cette option permet à votre appel d'API à la fin, avec un code retour indiquant la QMgr est en cours d'arrêt. Si vous n'incluez pas cette option, alors il est possible que deux ou plusieurs applications connectées que le QMgr sera jamais arrêter proprement et doivent être forcé ou de ses processus tué avec la force brute. En règle générale, utilisez toujours Échouer si la Suspension sur tous les appels d'API qui le prennent en charge. La raison pour laquelle il n'existe à tous est pour les gens qui ont besoin XA transactionality mais pour une raison quelconque ne peut pas l'utiliser. Dans ce scénario, la connexion et le premier GET ou PUT appeler utilise Échouer si la Suspension d'ensemble et suivantes GET ou PUT l'exploitation n'est pas. Cela provoque la QMgr attendre pour l'ensemble des OBTENIR/METTRE des appels, mais alors la prochaine connexion ou GET/PUT utilise Échouer si la Suspension de sorte que le QMgr a une chance de l'arrêter si nécessaire.

L'autre observation, c'est qu'il n'ya pas de piège dans le code ici. Je devine qu'il y a une portée plus haut dans la pile d'appel? Il est toujours conseillé d'imprimer le WMQ code de retour d'une exception, de sorte que vous pouvez traquer la cause de racine. Sur des missions de conseil, j'ai toujours conseiller les clients que l'échec d'imprimer le code de retour (ou l'exception de JMS/XMS code) est un écueil qui devraient empêcher la promotion d'une application à la Production. C'est vraiment important. Même si vous avez un hic dans le code qui appelle getMessage(), quelqu'un de réutiliser l'exemple de fragment de code ici ne pouvez pas réaliser cette importante pièce est manquante.

OriginalL'auteur T.Rob

Vous devez vous connecter pour publier un commentaire.