Every year BizTalk360 releases with 3 or 4 major versions (with few minor patch releases addressing critical bugs) with new key features with every major release. From Version 8.2.2385.2511, we started to support BizTalk Server 2016 RTM. Once after the release, we faced a strange case that the customers were not able to view the Context properties and Message Content in BizTalk360, but the customer is able to view the properties and content in the BizTalk Server Administration Console.
Strange enough, before BizTalk Server 2016 RTM, we were able to view the Content properties and Message content in BizTalk360 with the BizTalk Server customer preview versions. Once after the upgrade to the RTM release, we started to face this case.
From the exception message, we found that some DLL is missing and when we asked to check that dll at the customer’s end, we found that it was missing. Then we proceeded the case on how the DLL was eliminated, we found that the DLL, Microsoft.BizTalk.Message.Interop.CompressionStreams, was removed by BizTalk itself.
Use of Microsoft.BizTalk.Message.Interop.CompressionStreams.dll
Let’s have a look at the use of Microsoft.BizTalk.Message.Interop.CompressionStreams. By default, BizTalk server stores the message body parts in the Parts table and context in the Spool table in the BizTalkMessageBoxDb. The message is inserted in the tables through the bts_InsertMessage Stored Procedure. The values in these columns of the message part and context are respectively encrypted or they might be compressed. The messages stay in the Spool table only while they’re in flight being processed by BizTalk. Then they are removed and optionally moved to the tracking database. If you stop the send port or orchestration that is subscribing to the messages (but leave them enlisted) they will sit on the Spool and Parts tables for you to check them out. There are also a few messages that stay in the Spool table that are for the messaging agent cache and not the usual BizTalk messages.
As the XML is compressed, the clue is to use a Microsoft.BizTalk.Message.Interop.CompressionStreams.Decompress method. From the Microsoft.BizTalk.Pipeline.dll the message body content and context can be retrieved and viewed. The bts_GetTrackedMessageParts stored procedure inside the tracking database expects the message GUID and will return the compressed message data back. We can then use reflection to invoke the Decompress method of the Microsoft.BizTalk.Message.Interop.CompressionStreams class inside Microsoft.BizTalk.Pipeline.dll to decompress the data returned from SQL.
Where the Microsoft.BizTalk.Message.Interop.CompressionStreams.dll went?
When we deeply investigated the case why the DLL is missing, we are able to find that the methods of the Microsoft.BizTalk.Message.Interop.CompressionStreams DLL were moved under Microsoft.BizTalk.StreamProcessing.
Use of Microsoft.BizTalk.StreamProcessing.dll
Stream processing saves programs from having to load data entirely into memory.
Instead, a program gets a hold on a stream instead of the actual data. The program then starts asking the stream to send a chunk of the data. BizTalk implements a forward-only streaming design. Forward-only means that the stream can only be read, and cannot be sought back. Out of the box pipelines are stream-based; they utilize streaming when fetching data from the adapter and as data passes from one stage to another. For example, out-of-the-box components such as the Flat-File Disassembler and the XML Disassembler, are built with streaming in mind.
We changed in the BizTalk360 source code to support BizTalk Server 2016 and refer to Microsoft.BizTalk.StreamProcessing.
If you have any suggestions or feedback, you can write to us at firstname.lastname@example.org. Have a try at our latest version by downloading a 14-day free trial of BizTalk360.
Read: BizTalk360 Supports for BizTalk Server 2016
For any product, customer support will be considered as the face of the product and company. They deal with the customers and try to solve the problems which customers are facing. As a test and product support engineer of BizTalk360, I would like to share some of my experiences.
Let’s start with a support ticket which I handled and learnt from. A year back we received a support ticket from one of our customers. They were trying to renew their BizTalk360 license, for which they had to send their environment details to issue new license key (for 7.10 version). It’s a very simple process, the customer needs to select the environment and Generate License code using the Generate License Request button. But after selecting the environment, the ‘Generate Request’ button was not enabled. We found that the customer was missing some steps in between the process because the page was not used frequently by customers and at last we helped him to generate new keys after which they upgraded to the latest version (8.0).
Also, read Challenges in BizTalk360 Licensing after Environment Changes.
Issue faced by the customer after upgrade
After the upgrade to the latest version, customers must use the newly provided License keys to activate the environment so that they will be able to use the product. But unfortunately, this customer was stuck in the Settings page, it was loading for hours and no result. This case was very strange to us because we didn’t face the same problem anywhere in our testing although our testing team put lots of efforts in testing migrations. So, we planned to help them immediately by a web meeting, even though it was a Non-production environment.
Once after upgrading to the 8.0 version, we observed that the database table “b360_admin_BizTalkEnvironment” was empty and hence the environment details were not reflected in the BizTalk360 application UI, without which they cannot move forward in the application.
Our foremost task was to make the application up and running so that the customer can explore the new features available. We asked the customer to confirm if they had by any chance deleted/modified the table but he was not sure about it. But we were sure that without any manual changes those data will not get truncated.
Also, read Our experience solving a Culture Variant Issue in BizTalk360.
Approaching the case with the different plans
There were two options available to resolve the case. Plan A was to restore the database and then move on with the upgrade. Plan B was to proceed with the fresh installation, in case if no backup is available. We suggested plan A first, to restore the database if they have taken any backup before the upgrade. If so, we can restore the database and then update to the latest one, so that we can find out the root cause of the problem. But unfortunately, they did not have any backup before the upgrade process and the one they had was very old (taken early in 2014 exactly 3 years old), but they had taken the whole machine backup. With the least hope we requested to restore if possible and closed the call.
What happened during the web meeting?
The next day we received a mail that they were not able to restore the whole server as it contained lot of data and conveyed that they got a backup of BizTalk360 database. So, we thought to get into the call once again with plan A, i.e. to restore the database. We asked them to restore before the call. During the 2nd call we understood that the customer was very frustrated because of the launching issue and they didn’t restore it. Then we came to know that the database backup was the very old one. We conveyed to the customer that the backup will not be useful as it was very old. By this time, the customer got more frustrated as it was very hard to find and get database backup. We have no other go to, so we decided to go with the very old database restore, which took 2:00 hours of time to restore after we found that the database belonged to BizTalk360 7.0.
It took 2:00 hours of time to restore the backup of Database without my involvement and I was there in the call. 🙁
Finally, with the restoration of the database backup, we were now ready to set the application up and running with the following steps:
- We uninstalled the current version and we installed the version 7.0 with the temporary Database name
- Deleted the newly created database
- Renamed the old one with the new name so that UI will be linked to the old database.
- It helped us to check if BizTalk360 was working properly with that and we found that the environment details were also available
- Followed by 7.0 we installed 7.2, 7.8 and 8.0 for the proper upgrade and we resolved the problem.
But, the call took 3 hours and 9 minutes exactly, involving one of our Product Leads.
Do’s and Don’ts in Support Call Handling
I was very proud for resolving the case and satisfying the customer who was frustrated due to the long call, and the customer was happy too! Then I came to know what I should and shouldn’t have done in the call.
- If something needs to be done on customer side, we should give them time to do what they want and should request to complete it – Restoring the database took 2:00 hours of time without my involvement while I was there in the call
- If anything is not really important and there is less chance to work, we should say directly to the customer – Very old database backup
- If we are not confident about some suggestions, we should not take the risk. Without knowing which version the old database supports, I restored the old database. At that time, if it did not match with the UI and had some issues, the customer would have got even more frustrated
- Should always approach the best way – Reinstalling the current version.
- Should convey the best approach to the customer even though the customer becomes frustrated.
We have taken these points seriously from that day and we do some basic homework before the call, like what need to be discussed and what all the information we need from the customer side. Now this makes our troubleshooting during the web meeting very short and edge, so that saves both customer’s and our time.
You can write to us at email@example.com or visit our support portal. Have a try at our latest version by downloading a 14-day free trial of BizTalk360.
In BizTalk360 support, we often face a lot of interesting issues and we thought we would bring out a series to discuss the different cases that come our way and how we dealt with them. A previous blog by my colleague spoke on the Culture variant issue, a very unique case. Recently we came across a very interesting support case.
The customer was not able to view BizTalk applications due to the reason that BizTalk admin group name present in BizTalk360 License information did not match with the customer’s domain BizTalk Administrator’s group.
What happens during the activation of License in BizTalk360?
During the activation of an environment in BizTalk360, BizTalk360 License will fetch the information about BizTalk Admin Group, BizTalk server Management SQL Instance, Management Database name and BizTalk version information from customer’s environment. These details are stored into BizTalk360 license database and are embedded with the License after activation. If anything has changed at the BizTalk environment level, it will reflect in BizTalk360 UI or in performance.
Say for example: BizTalk servers were removed/added, changing BizTalk Admin Group name, BizTalk Server Management SQL Instance name, Management Database name, upgrading BizTalk server in one machine in multi-server environment., these changes will not be reflected with the BizTalk360 License information that is stored in the License database and hence it will display an exception message in BizTalk360 UI.
Screenshot of License history from BizTalk360 License application manager
It is always recommended that before making any environment related changes, you need to perform the license deactivation or else to contact our BizTalk360 support team for updating the changes into the License information and also for any guidance required.
Say for example: If the customer was not sure about moving the BizTalk360 database from one server to another server as a part of migration, we request our customers to contact our support team for the guidance.
Prologue to this story
From the BizTalk360 version 8.0 onwards, you will not be allowed to perform any action in BizTalk360 UI without activating the License.
The problem faced by the customer was that the name of the BizTalk Administrator group didn’t match with the information in the license.
- BizTalk Environment Domain: BT360BizTalk360-SG-Kovai-Biztalk Administrators-Dev,
- License Key Domain: BT360BizTalk360-SG-?Kovai-Biztalk Administrators-Dev
BizTalk Administrators group has the least privileges necessary to perform most administrative tasks. Members of that group can perform administrative tasks through the BizTalk Administration console or directly using the WMI provider and can deploy solutions, manage applications, and resolve message processing issues. Users will be added into the BizTalk Administrator’s group so that they can perform these administrative tasks.
Customer can change the name of the BizTalk Administrators group from BT360BizTalk360-SG-Kovai-Biztalk Administrators-Dev to BT360BizTalk360-SG-?Kovai-Biztalk Administrators-Dev which may resolve their problem. But, if they make any changes in BizTalk Administrators group, it may affect the BizTalk server process via the users who are added to that group to perform any operations.
Screenshot of the exception from BizTalk360 UI
The exception what the customer exactly faced
We noticed that there was a question mark added in between the domain name and the BizTalk Administrator’s group (Domain: BT360BizTalk360-SG-? -Biztalk Administrators-Dev). The customer conveyed that they worked with the domain admin team and removed the question mark symbol. But we are very sure windows server/operating system doesn’t allow to create a name with ‘?’ question mark while creating the group or a user.
We wanted to investigate within customer environment and so we requested a screen sharing session to see what’s happening and from where the name was taken from. Before going to any customer call, we would prepare a list of questions related to the necessary information we wanted from the customer end and where all we want to check. Also, we will try to reproduce the same at our end.
How did we back track the case?
During the testing, we tried to replicate the same. So we just copied the same BizTalk Administrator’s group ‘BT360BizTalk360-SG- Kovai-Biztalk Administrators-Dev’ name from the exception and created a group in our test machine and we added to BizTalk360. Once after adding as a NT Group in BizTalk360 we found a strange thing it got created with a special character ‘?’ question mark BT360BizTalk360-SG-?Kovai-Biztalk Administrators-Dev. Then we checked by using PowerShell command, found a special character added which was like a mobile phone character.
Screenshot of the BizTalk Admin group by using PowerShell
We asked the customer to change the Group name manually in all places in the database and in Windows Groups as well. But, it still showed the same exception even after the changes made by the customer. We requested for the desktop sharing session and checked all the places where the fault might be. But, we did not get any clue.
The idea was to verify the group name by editing and checking each and every individual character in the name by moving the cursor (that’s how we found special character during the testing). But we were not able to find the special character in the database and in Windows Groups.
Finally, in the properties of BizTalk Groups at BizTalk server we checked the BizTalk Administrator Group by each individual character by moving the cursor and we found the special character was still persisting. We asked the customer to remove the special character. They contacted their admin to change/modify the name, after which the exception was gone. BizTalk360 started working and the customer was able to view the applications without any problem.
What needs to be avoided?
We should try to avoid copy/paste while creating the group/user names most of the time instead type the name manually. Sometimes, while copying from a clipboard and pasting it in a password field may show some mismatch error due to the addition of special characters.
This was a good experience as a support engineer and had a different experience to learn as well.
The post Challenges in BizTalk360 Licensing after Environment Changes appeared first on BizTalk360.