After rolling out BizTalk 2013R2 CU5 on a development server we experienced the following error when loading the group hub:
“Could not find stored procedure ‘ops_ClearOperationsProgress'”
It looked like something when wrong during the installation of the cumulative update. After investigation of the log file, the following SQL error showed up:
To conclude: the installation failed because of insufficient SQL access rights.
(To bad the installer didn’t check this requirement before starting the installation…)
In the end we were able to fix the issue by taking the following steps:
- Providing the SQL sysadmin role
- Uninstalling the CU5 update
- Restoring the BizTalkMsgBoxDb database prior the update
- Installing the CU5 update again
My key takeaways regarding BizTalk updates:
- Always test BizTalk updates before rolling them out!
- Create a backup of your BizTalk databases before installing anu update – even for your development environments!
- Read the installer log file!
How about an Azure Function to re-evaluate messages on a Service Bus dead-letter queue and send them back to the originating queue?
Great idea! Sadly, when you look at the docmentation regarding the Azure Functions Service Bus binding, it does not list the possibility to read messages from a dead-letter queue…
Trying to configure this manual in the UI seems not possible when you try to save it…
How about editing the function.json?
This file contains de queue names and other Service Bus related settings (such as the maxConcurrrentCalls setting).
Setting the DLQ queue name here, makes it possible to save and run the Function!
Putting it all together
Some sample code on how a ReprocessDLQ Function could look like:
Outline: In this post I will talk about the possibility to replace a SQL Database as the ADAL token cache in the default Visual Studio ASP.NET MVC Template. The replacement data store will be Azure Table Storage.
At a recent project we where using an ASP.NET MVC Website to present data located in Azure Table Storage. The application was using Azure Active Directory for its Authentication.
When creating an ASP.NET MVC Site and adding Azure Active Directory for Authentication, the Template will add a ConnectionString to a Database to use for the ADAL Token Caching:
When you deploy this to an Azure Website you will need to use an Azure SQL Database. Using LocalDb in Azure is not possible. (The Publish tool in Visual Studio guides you in this.)
After deploying this the first time to Azure we ended up with 2 storage backends: Azure SQL Databse (for Authentication) and Azure Table Storage (for the real Business Data). As the SQL Database was only used for the ADAL Tokens, we surely wanted to get rid of this beceause of the extra cost in Azure.
As we were already using Table Storage, we decided to go with that.
From Azure SQL to Azure Table Storage
- Add the Windows Azure Storage nuget package to your solution
- Setup a storage account and add the connection configuration to your web.config
- Add your custom AdalTokenCache implementation. Remove “AdalTokenCache.cs” and “ApplicationDbContext.cs”
- Use it in “Startup.Auth.cs” and “UserProfileController.cs”
AuthenticationContext authContext = new AuthenticationContext(Authority, new TableTokenCache(signedInUserID));
A complete working sample can be found on GitHub: https://github.com/joenmaes/TableTokenCacheSample