This weekend I keep on getting this error when I tried to deploy a Microsoft Azure BizTalk Services solution;
“COQueueSource deployment failed at ‘https://biztalksoa.biztalk.windows.net/default/COXmlOneWayBridge/sources/COQueueSource’.
Failed to connect to the ServiceBus using specified configuration.”
I also observed this error in the MABS tracking portal.
This error had me stumped for awhile;
- This had worked months ago when I had followed a post by Steef-Jan Wiggers. I had followed his pattern to the letter.
- I could use the same connection string in the Service Bus Explorer to connect to the same queue without issue.
The default authentication mechanism for Service Bus namespace has changed from ACS to SAS since I had last tried to use a Queue source and I wondered if this was the cause. I had created the service bus using powershell commands to make sure that the queue source could use ACS in its connection string. I had then created the queue quickly rather than custom. This was the flaw as I will explain.
One of my colleagues Janardhan Chary mentioned he had struck the same issue and had only got around the issue when he did a custom create of the service bus queue and un-ticked the enable partition option.
After deleting and recreating the queue the error disappeared during deployment of the queue source and no error was observed in the tracking portal.
Monitor Azure Service Bus messages to get complete visibility by tracing them through the various business transaction stages and viewing their properties.
In summary if you are setting up a MABS queue source you must be careful how you set up the service bus and the queue; firstly set the service bus up using powershell to ensure the ACS is set and secondly set up the queue as custom and un-tick the enable partitioning option. I think this behaviour must have changed since Steef-Jan’s original article.
