Как я просматриваю сообщение Websphere MQ, не удаляя его?

Вам действительно стоит это с отдельными очередями. Обработка конца дня должна иметь собственную очередь. После обработки своей части сообщения вы отправляете его в очередь EOD.

С помощью опции «Обзор» вам нужно будет отслеживать, какие сообщения вы уже где-то обработали.

Кроме того, вы можете установить тайм-аут ожидания для GET. Так что вам не нужно «ждать 1 секунду перед проверкой очереди». Как написано прямо сейчас, вы не можете выполнить условие отсутствия доступного сообщения, потому что вы не установили NOWAIT в параметрах получения сообщения.

Ради потомков, вот (я думаю) значительно улучшенная версия метода, основанная на ответах мамбокинга и джмукьелло.

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

Я понимаю, что вступаю в это обсуждение немного поздно, и вы, вероятно, уже разработали это приложение. На случай, если вам когда-нибудь понадобится изменить его, или для любого другого человека, которому может понадобиться сделать что-то подобное, у меня есть пара замечаний.

Во-первых, если вы можете сделать это с v7 QMgr и v7 WMQ клиентом, это было бы предпочтительным решением. В v7 поддержка .Net была перенесена из SupportPac в часть базового продукта. Появилась значительная новая функциональность, исправлены некоторые ошибки и улучшена производительность. Кроме того, в v7 вы можете использовать pub-sub... что подводит меня к моему второму замечанию.

Основываясь на описании в исходном сообщении, я бы сделал это в Pub-Sub. Приложению, которое размещает сообщение, нужно разместить только одно, и ему даже не нужно знать, что оно размещает сообщение в теме. Вы можете создать псевдоним для темы, что сделает ее похожей на очередь для производителя сообщений. Затем ваши приложения-потребители могут либо подписаться, либо вы можете сделать две административные подписки, чтобы опубликованные сообщения отправлялись в две очереди, которые вы назначите. Тогда у каждого вашего приложения будет своя выделенная очередь, а производитель и пакетное приложение не будут изменять кодировку, это просто конфигурация. Конечно, приложение, управляющее транзакциями, должно будет фактически потреблять сообщения, а не просматривать их.

Преимуществ здесь несколько:

• По мере заполнения очереди сообщениями индексирование сбрасывается на диск, и при превышении определенного порога вы увидите падение производительности, которое может быть значительным. Поэтому текущий метод не очень хорошо масштабируется.
• При использовании метода pub-sub вы можете иметь несколько экземпляров приложений реального времени, пакетных приложений или обоих, и они могут быть на одном или разных QMgr. Масштабирование происходит легко.
• Вы устраняете зависимость между приложениями реального времени и пакетными приложениями, которые должны находиться на одном QMgr.
• Более прозрачное администрирование. Если вы видите, что сообщения накапливаются в очереди реального времени, вы знаете, что у вас проблема.

Здесь также есть пара совершенно других вопросов. Одна из них - использование опции Fail if Quiescing. Цель этого заключается в том, что когда QMgr выключается чисто, эта опция заставляет ваш вызов API завершаться с кодом возврата, указывающим на то, что QMgr выключается. Если вы не включите эту опцию, то при двух или более подключенных приложениях возможно, что QMgr никогда не выключится чисто, и его придется выключать принудительно или убивать его процессы грубой силой. Как правило, всегда используйте Fail if Quiescing во всех вызовах API, которые его поддерживают. Он существует для тех, кому нужна транзакционность XA, но по какой-то причине не может ее использовать. В этом сценарии CONNECT и первый вызов GET или PUT используют Fail if Quiescing set, а последующие операции GET или PUT - нет. Это заставляет QMgr ждать завершения всего набора вызовов GET/PUT, но затем следующий CONNECT или GET/PUT использует Fail if Quiescing, так что у QMgr есть шанс отключиться, если это необходимо.

Другим замечанием здесь является то, что в коде нет Catch. Я предполагаю, что он находится дальше по стеку вызовов? Всегда рекомендуется распечатывать код возврата WMQ из исключения, чтобы можно было отследить первопричину. На консультациях я всегда советую клиентам, что невозможность распечатать код возврата (или связанное исключение для JMS/XMS кода) является показательной ошибкой, которая должна предотвратить продвижение приложения в Production. Это действительно так важно. Даже если у вас есть catch в коде, который вызывает getMessage(), кто-то, повторив приведенный здесь фрагмент кода, может не понять, что этот важный элемент отсутствует.