Our experience solving a Culture Variant Issue in BizTalk360

As a developer, one of the things that provide us the most satisfaction is when you solve a problem by creating a new solution. While we enjoy solving complex problems, fixing an existing issue in the form of a bug is also a part of the development. Bugs usually have a distinct problem that needs to be solved. Bugs go hidden, unseen in unit tests, uncaught by the QA team and reach production. Sometimes it’s just a minor issue, sometimes it’s major bug. Whatever it is, the bug has to be fixed! Surely there isn’t a bug that is unfixable, right? Here’s our story of how we fixed an interesting problem in BizTalk360.

Prologue to this story

We released BizTalk360 v8.2 in early November last year, and many of our customers started moving to the latest version. Unfortunately, customers upgrading from v8.0 and earlier versions were unable to activate their licenses after the upgrade process. It all started with a collection of related support tickets in our Assist portal. All seemingly minor bugs, we provided our standard workaround(s) to solve them. It worked for few customers but the issue persisted for others. As a result, few of our L2 support engineers had to jump in and spend considerable amount of time to debug this issue. Here’s the exception we received on this issue.

Value was either too large or too small for an unsigned byte.

Finding the root cause of the problem

Considering the seriousness of this issue, we took this up with high priority to get it fixed. After the initial screen sharing sessions with the customers, we identified a peculiar scenario i.e., we found the customers reporting this issue had their server machine language preferences settings in regional language rather than English. This triggered a thought that this could be a culture variant issue! Now if you are wondering how did this affect a customer from activating their license after the upgrade — Not all cultures use the same format for dates and decimal/currency values. For example, this will matter for you when you are converting input values (read) that are stored as strings to DateTime, float, double or decimal. It will also matter if you try to format the aforementioned data types to strings (write) for display or storage. As a process of increasing the security settings in BizTalk360, from version 8.1 we introduced a couple of technical changes to the backend code.

Encrypting the password details in BizTalk360 in areas like gateway settings, Azure subscriptions etc.

When you change the preference language from English to your regional language or change the decimal symbol values in your machine, backend code in BizTalk360 does not handle the changes during password encryption process, resulting in erroneous values.

Version check capability during the upgrade process

We introduced this functionality in the v8.2 release. This makes the upgrade process simple as the function checks for the currently installed version and upgrades only the missing functionalities from the latest version. From the screenshot, you can see that 4 tables are migrated while successfully upgrading from v8.1 to v8.2. If your language preference in your server is other than English, then you will face this issue when upgrading from v8.0/earlier versions to v8.2. In this case, some tables will not be migrated successfully as shown below.

How did we solve this Culture Variant issue?

When planning for an upgrade, we always recommend our customers to take a backup of the BizTalk360 database. Therefore, as a temporary workaround, we asked the customers to roll back to their existing version and start the process again.

• Roll back the upgrade process
• Migrate from the existing version to v8.1
• Migrate to v8.2

As a permanent fix to this issue, we changed our backend logic from culture-sensitive data to invariant culture to support global variants for number format and to support for regional languages. This change will ensure proper migration of the database tables during the upgrade process. Later, we released the fix for this problem as a patch version and made available for public use. Download the latest version of BizTalk360 and get started with your 14 Day Free Trial!