Очередь служебной шины Azure предоставляет управляющие символы в полученном сообщении

Я использую адаптер BizTalk Server SB-Messaging для получения сообщений из очереди служебной шины Azure. Мне удалось самостоятельно отправить сообщение в очередь (используя тот же адаптер), получить сообщение из очереди и выполнить дальнейшую обработку.

Проблема возникает, когда сторонний поставщик программного обеспечения отправляет сообщения в очередь, а BizTalk Server извлекает и обрабатывает сообщение. Затем я получаю следующую дополнительную «заголовочную» информацию и управляющие символы в начале сообщения:

Заголовок сообщения, включая управляющие символы, ACK, BS и SOH

В тексте: @ACKstringBShttp://schemas.microsoft.com/2003/10/Serialization/?$SOH

Похоже, что есть какое-то обернутое сообщение, включая заголовки для обработки подтверждения сообщения в очереди.

Адаптер SB-Messaging выдал следующее начальное сообщение об ошибке:

«На узле службы WCF по адресу произошел сбой, и в результате в соответствующем месте получения больше не могут быть получены сообщения. Чтобы устранить проблему, BizTalk Server автоматически попытается перезапустить узел службы».

И еще одно сообщение об ошибке:

«Ни один из компонентов этапа дизассемблирования не может распознать данные».

Кто-нибудь сталкивался с этой проблемой раньше, и что может быть причиной проблемы? Может ли кодировка символов быть возможной причиной этой проблемы?


azure-servicebus-queues biztalk special-characters
person JERKER    schedule 07.12.2018    source источник
comment
Первое сообщение об ошибке, возможно, является следствием первого. Поскольку сообщение не соответствует вашей схеме, следовательно, выдает ошибку и не принимает сообщение из очереди. Итак, у вас есть ситуация с отравленным сообщением. Нельзя ли добавить в вашу схему необязательный заголовок, чтобы он правильно анализировал сообщение? Соответствует ли остальная часть сообщения вашей схеме? Если нет, вам нужно вернуться к третьей стороне и сказать им, что их сообщение недействительно.   -  person Dijkgraaf    schedule 08.12.2018
comment
Да, сообщения об ошибках — это только сообщения о симптомах, но они помогут кому-то найти эту статью и будущее решение при поиске... Теоретически адаптер не может анализировать заголовки сообщений (добавленные очередью служебной шины) и удалять их. прежде чем передать его в BizTalk. Вопрос в том, почему адаптер не может удалить заголовок?   -  person JERKER    schedule 11.12.2018

Ответы (2)


arrow_upward
0
arrow_downward

А вот и обратная связь!

Оказалось, что у стороннего поставщика программного обеспечения была настройка для отправки сообщения в виде потока, а не строки. Оказывается, это приложение .Net, использующее объект BrokeredMessage. Использование строки делает сообщение сериализованным, и к сообщению добавляются метаданные. При использовании потока такой сериализации не происходит, и сообщение остается нетронутым.

Итак, проблема заключалась в использовании строки и автоматической сериализации при отправке в очередь служебной шины.

person JERKER    schedule 24.01.2019

arrow_upward
0
arrow_downward

У меня есть устаревшие клиенты Microsoft.ServiceBus.Messaging, отправляющие BrokeredMessage Xml-контент как <string>, и я хочу получать его, используя новейшую библиотеку Microsoft.Azure.ServiceBus и тип Message.

Используя Encoding.UTF8.GetString(message.Body), я получаю непригодную для использования строку с префиксом @\u0006string\b3http://schemas.microsoft.com/2003/10/Serialization/��#.

Мой подход заключается в явном использовании двоичной десериализации XmlDictionaryReader для отмены скрытой магии сериализации из устаревшей библиотеки.

        private static string GetMessageBodyHandlingLegacyBrokeredMessage(Message message)
        {
            string str = null;
            if (message.ContentType == null)
            {
                using (var reader = XmlDictionaryReader.CreateBinaryReader(
                    new MemoryStream(message.Body),
                    null,
                    XmlDictionaryReaderQuotas.Max))
                {
                    var doc = new XmlDocument();
                    doc.Load(reader);
                    str = doc.InnerText;
                }
            }
            else
                throw new NotImplementedException("Unhandled Service Bus ContentType " + message.ContentType);
            return str;
        }

использованная литература

https://docs.microsoft.com/en-us/azure/service-bus-messaging/service-bus-messages-payloads#payload-serialization

https://carlos.mendible.com/2016/07/17/step-by-step-net-core-azure-service-bus-and-amqp/

person golfalot    schedule 19.11.2020