0
votes

I am using BizTalk Server SB-Messaging adapter to retreive messages from Azure Service Bus Queue. I have successfully managed to send message to queue myself (using same adapter), and retreive message from queue and do further processing.

Problem arises when a 3rd party software supplier is sending messages to the queue, and for BizTalk Server to retreive and process message. I then receive the following additional "header"-information and control characters in the beginning of the message:

Message header including control characters, ACK, BS and SOH

In text: @ACKstringBShttp://schemas.microsoft.com/2003/10/Serialization/?$SOH

Seems like there is some sort of enveloped message, including headers to handle ACKnowledgement of the message to the queue.

SB-Messaging adapter gave following initial error message:

"The WCF service host at address has faulted and as a result no more messages can be received on the corresponding receive location. To fix the issue, BizTalk Server will automatically attempt to restart the service host."

And, another error message:

"No Disassemble stage components can recognize the data."

Did anyone hit this problem before, and, what can be the cause of the problem? Can character encoding be a possible cause of this problem?

2
The first error message is possibly a consequence of the first. As the message does not match your schema, hence it throws an error and not taking the message of the queue. So you have a poisoned message situation. Is it not possible to add a optional header to your schema so that it parses the message correctly? Does the rest of the message match your schema? If not you need to get back to your 3rd party and tell them their message is invalid - Dijkgraaf
Yes, error messages are only messages of symptoms, but will help someone to find this article and future solution while searching... Theory is that the adapter is not able to parse message headers (added by the service bus queue), and remove it before passing it on to BizTalk. Question is why adapter can not remove header? - JERKER

2 Answers

0
votes

Here comes the feedback!

Turned out 3rd party software supplier had a setting to send message as stream, instead of string. Turns out it is a .Net application using BrokeredMessage object. Using string makes message serialized, and meta-data is added to the message. Using stream, no such serialization takes place, and message is kept untouched.

So, problem was using string and automatic serialization when sending to Service Bus Queue.

0
votes

I have legacy Microsoft.ServiceBus.Messaging clients sending BrokeredMessage Xml content as <string> and I want to receive using the latest Microsoft.Azure.ServiceBus library and Message type.

Using Encoding.UTF8.GetString(message.Body) I get a unusable string prefaced with @\u0006string\b3http://schemas.microsoft.com/2003/10/Serialization/��#

My approach is to explicitly use XmlDictionaryReader binary deserialization to undo the hidden serialization magic from the legacy library

        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;
        }

References

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/