Hooking BizTalk up to an Azure Service Bus is a straightforward enough process, thanks to the SB-Messaging adaptor. When creating Receive Locations and Send Ports that make use of this adapter, you specify the Service Bus endpoint that you want to connect to and give it the shared access policy name and authorisation key.
But what if you have a company policy that dictates that all access keys need to be rolled once a month?
Or even if you don’t have such a policy, but a situation arises where you need to roll the keys in order to prevent access by a third party?
You could manually open each SB-Messaging Send Port and Receive Location in the BizTalk Administration console and update all the keys. But what if you have 100 such entities? And then replicate that across other environments that may also need to be updated? This has now turned in to a very time-consuming undertaking, during which you may have non-functioning Receive Locations and Send Ports.
Fortunately, there is another way. By making use of WMI, the BizTalk ExplorerOM, and Azure PowerShell you can almost completely automate the process.
There are just a couple of caveats however:
As long as that is the case, then the basic process flow is as follows:
In addition to being used in the event of having to roll keys, this method of updating the Service Bus keys can also be incorporated into the process of deploying BizTalk applications, in conjunction with BizTalk Deployment Framework.
A custom target can be added to the BTDF so at deploy time the correct key is retrieved from the relevant Service Bus Queue. This can be a good alternative to storing sensitive configuration data in the BTDF settings spreadsheets.