Posts Tagged ‘BizTalk Server 2010’

BizTalk Health Monitor (BHM) is a BizTalk snap-in that can be added to the existing BizTalk Administration Console or can be run individually, that helps you monitor the health of your BizTalk Server environment. Basically it’s similar to the “old” BizTalk MsgBoxViewer tool that we used monitor a BizTalk environment by gathering all information of a BizTalk group and detecting any issues, non-critical or critical warnings to detect any potential problems in advance.

BHM is now in is third version, released in March 6, 2015 that you can download here and know more about it here.

The goal of this post is not to explain what it is the BizTalk Health Monitor, but instead if you already have a previous version – V1 or V2 – how can you update to the latest one – V3. Do you need to uninstall the previous one?

Note: If you don’t have a previous version of BizTalk Health Monitor installed then check the post to describe the installation steps required.

How to upgrade BizTalk Health Monitor to the latest version

Basically you don’t need to uninstall V2 (or V1) to upgrade to the latest version, you just need to register the snap-in of the new one but there are some consideration that you need to be aware.

  • First, if you have BizTalk Health Monitor integrated with the BizTalk Administration Console you need to close all the BizTalk Administration Console in all sessions, if not you need to close BizTalk Health Monitor in all sessions again, otherwise you cannot replace or delete the existing files.

Error-While-replacing-BHM-filesNote: You shouldn’t replace or create a new BHM folder under “C:\Program Files (x86)\Microsoft BizTalk Server 2013 R2\SDK\Utilities\Support Tools” otherwise you will have issues installing BizTalk cumulative updates (see BizTalk 2013 R2 CU1 install failing with “Package does not contain compatible branch patch”)

  • After closing all consoles, choose a proper location in your drive, for example:
    • “C:\Program Files (x86)\Microsoft BizTalk Server Support Tools\BizTalkHealthMonitor”
  • And unzip the version of the BHM zip file to this folder
    • You could also replace the existing files by the new ones, however I already encountered some issues while registering the new version of the snap-in after doing that
    • Or you can create a new folder with this new resources.

Note: Once you register the BizTalk Health Monitor Snap-In you cannot delete or change the folder path or BHM will stop working.

  • Open a command prompt as an administrator
  • Navigate to the directory folder where you have the BHM resources
    • For example: “C:\Program Files (x86)\Microsoft BizTalk Server Support Tools\BizTalkHealthMonitor”
  • And from the command prompt type:
    • InstallUtil.exe MBVSnapIn.dll
  • And hit enter. This step will register the new version of the Snap-In to be used

Because you already add the BizTalk Health Monitor integrated in the BizTalk Administration Console you don’t need to do nothing more. Just open the BizTalk Administration Console and the last version of the BHM will be available.

BizTalk-Administration-Console-BHM-V3

Notes:

  • If you replace the existing BHM files by the new ones and then try open the BizTalk Administration Console without registering the new BHM version you will receive the following error:
    • “MMC has detected an error in a snap-in and will unload it”

BHM-MMC-detected-error-snap-in-unload-it

  • If you replace the existing BHM files by the new ones and you find some kind of error while trying to register the snap-in then:
    • Delete all files from the directory and then copy again the files to the new BHM version to the folder
    • And register again the BHM span-in

Important Note: If you already replace some files under “C:\Program Files (x86)\Microsoft BizTalk Server 2013 R2\SDK\Utilities\Support Tools\BizTalkHealthMonitor” or created a new BHM folder under “C:\Program Files (x86)\Microsoft BizTalk Server 2013 R2\SDK\Utilities\Support Tools”, you should:

  • Move the BHM folder to a place outside the “C:\Program Files (x86)\Microsoft BizTalk Server 2013 R2\SDK\Utilities\Support Tools” folder, for example to the suggested path described above
  • Register the BHM Snap-In from this directory
  • And delete all the BHM folders under the Utilities folder

otherwise you will have issues installing BizTalk cumulative updates (see BizTalk 2013 R2 CU1 install failing with “Package does not contain compatible branch patch”)

BizTalk Health Monitor is a snap-in, basically it’s the same of BizTalk MsgBoxViewer tool that we used monitor a BizTalk environment by gathering all information of a BizTalk group and detecting any issues, non-critical or critical warnings to detect any potential problems in advance, but in this case is integrated more closely with the BizTalk Administration Console to provide BizTalk administrators a quick and complete dashboard of a BizTalk group which will help them monitor the health of their BizTalk platform.

You can see more info about BizTalk Health Monitor (BHM) at:

BHM was originally released as a new feature with BizTalk Server 2013 R2 but luckily for us Microsoft decided to release a standalone version of BHM for use with BizTalk Server 2010 and BizTalk Server 2013.

You can download the standalone version of BHM from Microsoft Download Center here: BizTalk Health Monitor

How to install BizTalk Health Monitor snap-in

Prerequisites:

  • BizTalk Server 2010 or 2013 should be installed and configured.
How to register BizTalk Health Monitor Snap-In

After you download and unzip the BHM.ZIP file from the Microsoft Download Center, you the “InstallUtil.exe” which comes with BizTalk Health Monitor tool to register the BHM snap in.

Important: You shouldn’t replace or create a new BHM folder under “C:\Program Files (x86)\Microsoft BizTalk Server 2013 R2\SDK\Utilities\Support Tools” otherwise you will have issues installing BizTalk cumulative updates (see BizTalk 2013 R2 CU1 install failing with “Package does not contain compatible branch patch”)

Important: Unzip the BHM.ZIP to a final destination before you register the snap-in for example: C:\Program Files (x86)\Microsoft BizTalk Support Tools\BHM. Once you register the BizTalk Health Monitor Snap-In you cannot delete the folder or BHM will stop working

Note: New versions of the BHM snap-in (version 3.1) don’t include anymore the “InstallUtil.exe” file

  • You can still use the old “InstallUtil.exe” file to register the snap-in (but you need to copy this file to the BHM folder)
  • But instead you should use now the “BHMSetup.exe” file which will register in more simpler way the snap-in (see BizTalk Health Monitor v3.1 released!)

 

To accomplished that we need to:

  • Open a command prompt as an administrator
  • Navigate to the directory file where you unzipped the BHM.ZIP file
    • For example: C:\Program Files (x86)\Microsoft BizTalk Support Tools\BHM
  • And from the command prompt type:
    • InstallUtil.exe MBVSnapIn.dll
  • And hit enter. This step will do some registry changes and register the SnapIn to be used

 

How to integrate BHM Snap-In into BizTalk Admin Console

Important note: BHM Snap-In can be used independently and need not to be integrated with BizTalk Administration Console. The handicap of this approach is that a BizTalk Administration will need to use two different places/tools to monitor and administrate the environment.

To be easier and more convenience for BizTalk Administrators BHM Snap-In can also be integrate it so that it can be used with BizTalk Administration Console.

To accomplished that we need to open a 32-bit Microsoft Management Console (MMC):

  • Click Start, click Run, type:
    • mmc /32
  • Press enter or click OK. This will open a new 32-bit version of MMC (MMC32).
  • From MMC console, go to File menu and select “Options…” option
    • In the text box, replace “Console1” for “BizTalk Administration Console”
    • In the Console mode combo box, select “User mode – full access”
    • And confirm that the option “Do not save changes to this console” is uncheck

MMC-console-properties

  • From MMC console, go to File menu and select “Add/Remove Snap-in…” option

MMC-window-Add-Remove-Snap-in

  • From the “Add or Remove Snap-ins” window, add following snap-ins and then click Ok
    • Microsoft BizTalk Server Administration
    • BizTalk Health Monitor

MMC-window-Add-or-Remove-Snap-ins-selection

    • You can add the snap-ins by selecting them from the “Available snap-ins” list and click “Add >”
    • Is recommend that you respect the order present in the “Selected snap-ins” list as showed in the picture above
  • This will generate for us a new MMC which contains both the BizTalk Server Administration and BizTalk Health Monitor. And by now your new MMC is ready which shows both the BizTalk Server Administration and BizTalk Health Monitor

new-BizTalk-Administration-Console

Now you might want to save this as a new .msc file so that you don’t have to repeat these steps again but before we complete the creation process of the “new” BizTalk Administration Console, I recommend that you navigate to the BizTalk Server Installation folder:

  • Example: C:\Program Files (x86)\Microsoft BizTalk Server 2010
  • And rename “BTSmmc.msc” file, for example: “BTSmmc-old.msc”

This because we will save the “new” BizTalk Administration Console as “BTSmmc.msc” so that you don’t need to create new shortcuts or having different ways to access the BizTalk Administration Console – however this step is optional!

To finished the creation process of the “new” BizTalk Administration Console

  • From MMC console, go to File menu and select “Save As…” option:
    • Give a name and then save it.
      • Access to BizTalk Server Installation folder
        • C:\Program Files (x86)\Microsoft BizTalk Server 2010
      • Save the file as “BTSmmc.msc”

From next time onwards, when you open the BizTalk Server Administration Console

start-BizTalk-Administration-Console

The “new” BizTalk Administration Console will be incorporated with the BizTalk Health Monitor

BizTalk-Administration-Console-with-BizTalk-Health-Monitor

You can download the standalone version of BHM from Microsoft Download Center here: BizTalk Health Monitor

I have a BizTalk Server 2010 Test Environment that was working properly for some time, all the adapters from BizTalk Server Adapter Pack 2010 were installed with the last cumulative updates and also working properly, in this environment we use the SQL Server Adapter.

However the last time the team try to configure the receive location present in the application they unexpected got the following error:

“Unable to create binding configuration element for editing. Check the values of the bindyingType and BindingConfiguration properties. (Microsoft.BizTalk.Adapter.Wcf.Converters.CreateBindingException) Unable to get binding type for binding extension “sqlBinding”. Verify the binding extension is registered in the machine.config.”

WCF-Custom-Transport-Properties-Error

Also every time they try to enable the Receive Location they automatically become disabled again. When I checked the Event Viewer I also found this two errors:

“The Messaging Engine failed to add a receive location “WcfReceiveLocation_SqlAdapterBinding_TypedPolling ” with URL “mssql://SERVER:PORT/INSTANCE/DB?InboundId=id” to the adapter “WCF-Custom”. Reason: “Microsoft.BizTalk.Adapter.Wcf.Converters.CreateBindingException: Unable to get binding type for binding extension “sqlBinding”. Verify the binding extension is registered in machine.config.”

“The receive location “WcfReceiveLocation_SqlAdapterBinding_TypedPolling ” with URL ” mssql://SERVER:PORT/INSTANCE/DB?InboundId=id ” is shutting down. Details:”The Messaging Engine failed while notifying an adapter of its configuration. “.”

 

WCF-Custom-Ports-disabled

Suspecting the problem but curious to understand the problem I try to create a new Receive Location and I found out that the SQL binding was not present:

WCF-Custom-Transport-Properties-list-bindings-without-sql

CAUSE

The SQL Database adapter (also the Oracle Adapter or the Oracle E-Business Suite) is a WCF custom binding, which is registered under System.ServiceModel in the machine.config file.

Important note: A 64-bit platform has two machine.config files, one used by the 32-bit applications and the other used by the 64-bit applications. Actually they have several machine.config for different .NET Frameworks, however in this case we are talking about the last .NET Framework v4.0.30319 normally present in BizTalk Server 2010 environment which you can find in the following folders:

  • 32-bits: C:\Windows\Microsoft.NET\Framework\v4.0.30319\Config
  • 64-bits: C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Config

When you install the 64-bit version of the BizTalk Adapter Pack, the setup wizard registers the bindings in the 64-bit version of the machine.config file. However, BizTalk Server Administration console runs as a 32-bit process and hence when you configure a port for the adapter, it checks for the bindings in the 32-bit version of the machine.config file and fails giving an error. This is also the reason why you should always installed 32 and 64 bits version of the adapters.

However in my particular case that wasn’t the problem because I had both version of the adapter installed and they were working properly. So in my case the problem started to happen because one of the members installed a new .NET Framework version (4.5.2) in the BizTalk Server machines and then uninstalled. After this all the adapters present in the BizTalk Adapter Pack stopped to work.

SOLUTION

It depends on the configuration of your environment.

Solution 1:

If 32-bit versions of the BizTalk Adapter Pack are note installed in your machine you should:

  • Install both the 32-bit and 64-bit versions of the BizTalk Adapter Pack on a 64-bit WCF LOB Adapter SDK installation.
    • Note: You must only have a 64-bit WCF LOB Adapter SDK installation. Side-by-side installation of 32-bit and 64-bit WCF LOB Adapter SDK on a single computer is not supported.

Solution 2

Otherwise you should check in the machine.config if the custom binding extension are configured properly in both 32 and 64-bit files.

To check or register the adapter bindings or the .NET Framework Data Providers:

  • Navigate to the machine.config file on the computer.
  • Open the file using a text editor or using the SvcConfigEditor.exe util to edit the config file. It is easy to add the binding extensions in this utility otherwise with a common text editor like notepad is very easy to make errors while editing the config file.
  • Check if there are present the adapter bindings otherwise you should register them:
    • Search for the element “<client>” under “<system.serviceModel>”:

machine-config-system-serviceModel-client

      • If not present add the following line under it:
<client>
   <endpoint binding="sapBinding" contract="IMetadataExchange" name="sap" />
   <endpoint binding="siebelBinding" contract="IMetadataExchange" name="siebel" />
   <endpoint binding="oracleDBBinding" contract="IMetadataExchange" name="oracleDb" />
   <endpoint binding="oracleEBSBinding" contract="IMetadataExchange" name="oracleEBS" />
   <endpoint binding="sqlBinding" contract="IMetadataExchange" name="mssql" />
</client>
    • Search for the element “<bindingElementExtensions>” under “<system.serviceModel><extensions>”

machine-config-system-serviceModel-extensions

      • Look for the missing adapter binding and if they are not present add the following lines under the “<bindingElementExtensions>” node:
<add name="sqlAdapter" type="Microsoft.Adapters.Sql.SqlAdapterBindingElementExtensionElement, Microsoft.Adapters.Sql, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />
<add name="sapAdapter" type="Microsoft.Adapters.SAP.SAPAdapterExtensionElement, Microsoft.Adapters.SAP, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />
<add name="oracleDBAdapter" type="Microsoft.Adapters.OracleDB.OracleDBAdapterExtensionElement, Microsoft.Adapters.OracleDB, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />
<add name="oracleEBSAdapter" type="Microsoft.Adapters.OracleEBS.OracleEBSBindingElementExtensionElement, Microsoft.Adapters.OracleEBS, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />
<add name="siebelAdapter" type="Microsoft.Adapters.Siebel.SiebelAdapterExtensionElement,Microsoft.Adapters.Siebel, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />
  • To check and register the .NET Framework Data Providers:
    • Search for the element “<DbProviderFactories>” under the “<system.data>” node.
    • Look for the missing .NET Framework Data Providers. Add the following sections under the “<DbProviderFactories>” node, depending on the missing provider. You must register all the providers if the setup wizard fails to register any.
<add name="SAPClient Data Provider" invariant="Microsoft.Data.SAPClient" description=".NET Framework Data Provider for mySAP Business Suite" type="Microsoft.Data.SAPClient.SAPClientFactory,Microsoft.Data.SAPClient, Version=<version>, Culture=neutral, PublicKeyToken=<public key>" />
<add name="SiebelClient Data Provider" invariant="Microsoft.Data.SiebelClient" description=".NET Framework Data Provider for Siebel eBusiness Applications" type="Microsoft.Data.SiebelClient.SiebelProviderFactory,Microsoft.Data.SiebelClient, Version=<version>, Culture=neutral, PublicKeyToken=<public key>" />
  • Save and close the machine.config file.

After I edit and fixed the machine.config file the WCF-SQL adapter started to work again.

WCF-Custom-Transport-Properties-list-bindings

WCF-Custom-Ports-enabled

When we configure Deployment Settings in Visual Studio projects, our database settings (“Configuration Database” and “Server”) and BizTalk Settings (“Application Name”) are only stored in a personal “*.btproj.user” file. By default these files are ignored in your check-ins, but that may not be the desired effect. We recommend that those settings are also stored in your source control (forever) to preserve testing configurations and help you and other team members pick your archived project easily.

In one of my previous post, “Failed to add resource(s). Resource (…) is already in store and is either associated with another application or with another type”, I explained a common deployment problem that can happen when we work with BizTalk Server project and Team Foundation Server. In this post I will try to explain how can we avoid this problem and how can we store deployment settings in TFS so that can be shared by our team members.

sharing-team-members

Firstly, is important for you to know that Visual Studio, I believe since BizTalk 2009 onwards, stores the deployment setting of BizTalk projects in the Project user option file: “*.btproj.user” file. This is a XML file that contains not only the BizTalk deployment Settings but also several personal user settings like References path, test file names and so on.

Regarding to BizTalk deployment properties all this setting are stored in the “*.btproj.user” file:

  • Application Name (ApplicationName): Is the name of the BizTalk application that we want to deploy the assemblies in this project. If the application already exists, the assemblies will be added to it when you deploy the project. If the application does not exist, the application will be created. If this field is blank, the assemblies will be deployed to the default BizTalk application in the current group (“BizTalk Application 1”). Names that include spaces must be enclosed by double quotation marks (“).
  • Configuration Database (ConfigurationDatabase): Is the name of the BizTalk Management database for the group, the default value is “BizTalkMgmtDb”.
  • Server (Server): Is the name of the SQL Server instance that hosts the BizTalk Management database on the local computer. By default this is usually the name of the local computer.
  • Redeploy (Redeploy): Boolean property that indicates if you want to allow redeployments from within Visual Studio. Setting this to “True” (the default) enables you to redeploy the BizTalk assemblies without changing the version number.
  • Install to Global Assembly Cache (Register): Setting this to “True” (the default) installs the assemblies to the Global Assembly Cache (GAC) on the local computer when you install the application. Set this to False only if you plan to use other tools for this installation, such as gacutil.
  • Restart Host Instances (RestartHostInstance): Setting this to “True” automatically restart all host instances running on the local computer when the assembly is redeployed. If set to False (the default), you must manually restart the host instances when you redeploy an assembly.

Let’s see an example of this file:

<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <PropertyGroup Condition="'$(Configuration)|$(Platform)' == 'Debug|AnyCPU'">
    <Server>BTS2013LAB01</Server>
    <ConfigurationDatabase>BizTalkMgmtDb</ConfigurationDatabase>
    <ApplicationName>MyTestApplication</ApplicationName>
    <Redeploy>True</Redeploy>
    <Register>True</Register>
    <RestartHostInstances>False</RestartHostInstances>
  </PropertyGroup>
  <ProjectExtensions>
    <VisualStudio>
      <FlavorProperties GUID="{EF7E3281-CD33-11D4-8326-00C04FA0CE8D}">
        <Files>
		<File Path="NormalizeAndRemoveUnnecessaryData\Client.xsd">
			<ValidateTestMapInput>True</ValidateTestMapInput>
			<ValidateTestMapOutput>True</ValidateTestMapOutput>
			<TestMapInputInstanceFilename></TestMapInputInstanceFilename>
			<TestMapOutputInstanceFilename></TestMapOutputInstanceFilename>
			<TestMapSourceType>0</TestMapSourceType>
			<TestMapTargetType>0</TestMapTargetType>
			<EditorOutputInstanceFilename></EditorOutputInstanceFilename>
			<EditorInputInstanceFilename></EditorInputInstanceFilename>
			<GenerateInstanceOutputType>0</GenerateInstanceOutputType>
			<ValidateInstanceInputType>0</ValidateInstanceInputType>
			<PropertySchemaFileName>PropertySchema.xsd</PropertySchemaFileName>
			<AutoRefreshSchema>0</AutoRefreshSchema>
		</File>
	</Files>
      </FlavorProperties>
    </VisualStudio>
  </ProjectExtensions>
</Project>

Secondly, you must keep in mind that these file (“*.btproj.user”) are typically not under source control. The reason is that the Visual Studio deployment feature main focus is for development scenarios where one user settings might differ from another. And it will be up to you, or your client, to decide if you want these files to be checked in and available to all of the developers on your team.

However when the team shares the same BizTalk developer environment, is expected that all build related information required at the time of build can be shared between developers in an easy way… unfortunately there is no easy way and one of the possible solutions is to force storing “*.btproj.user” files in the source control so that this setting can be shared by all the team members.

Although I know that the “*.btproj.user” Files are not supposed to be shared because they contain personal settings (as explained before) sometimes this approach can be considered a good practice.

Of course that this “workaround” can lead to additional problems, simple because this files contains some user settings, that can be different that yours (for example schema file properties only allows a valid full path file names) that can change your setting and probably don’t work in your developer station and need to be reconfigured, but this can be minimized with some precautions and good practices.

How can we check if “*.btproj.user” Files are stored in TFS and how to add them?
  • Open Visual Studio 2010 and select the “View” Menu and choose “Team Explorer” to connect to your TFS
  • Access to “Source Control” and from the source control tree you must browse to the project that you want.

BizTalk-Project-Source-Control-Explorer

  • Right click in the project folder and select “Add Items to Folder…” option

BizTalk-Project-Add-Items-to-folder

  • Select the BizTalk project folders present in the solution, and click “Next”

BizTalk-Project-Add-Items-to-Source-Control

  • From this windows we can see that the “*.btproj.user” files are not include in the source code

BizTalk-Project-Add-Items-to-Source-Control-Items-to-add

  • To add them, you just need to select them and then click “Finish”.
Testing this workaround

After applying this wokaround, when I try to access and get the last version of the project with a different user, all the settings where correctly properly fulfilled:

BizTalk-deployment-setting-fulfilled

And after a battery of tests that I performed very quickly with a member of my team, here are some suggestions to avoid some problems that sometimes happens and we face in our tests:

  1. Make a Label in the “*.btproj.user” file to properly and easily identify a clean BizTalk Application Deployment Settings with all important deployment settings and without any personal settings. This way you can, at any time, force to get that specific version of the file

NewLabel

  1. If you already have a local version of the project in your environment, you should get the last version and force to overwrite all the files by:
    1. Access to source code, in the project folder, right click and choose the option “Get Specific Version…”
    2. Check all the option in the Get Windows:
      1. Project folder
      2. “Overwrite writeable files that are not checked out” option
      3. “Overwrite all files even if the local version matches the specified version” option
      4. Choose the type “Latest Version” and click “Get”

BizTalk-Project-Source-Control-Explorer-get-Specific-version

In addition, once you have the correct settings, even if each individual users change locally their personal settings they are not committed to the source control by default, which means that it will not spoil the settings of other users every time someone does a check in. Again if you want to change this setting in the source control you need to force this to happen.

Final notes

Probably this is not the best approach for sharing the BizTalk Application Deployment Settings across all the team, but is a valid way and much better than each member manually add to their solution. I will try to find a better way and if you already have it, feel free to comment and share it here.

References:

Once again I want to thank José António Silva, my ALM guru for the help! And thanks Bruno Zacarias for helping me testing this workaround.

After two days ago we released version 1.7.0.0 for BizTalk Server 2013, today is the time of BizTalk Mapper Extensions UtilityPack for BizTalk Server 2010 to be published and available for download!

This release will include all the new functionalities implemented by René Brauwers that were described in my last post: BizTalk Mapper Extensions UtilityPack for BizTalk Server 2013 Updated to v1.7.0.0

This means that we are still maintaining all the features available for BizTalk Server 2013 and 2010.

You can also find a shorter version of this project with less features for BizTalk Server 2009/2006 here: BizTalk Mapper Extensions UtilityPack for BizTalk Server 2006/2009

You can found and download Source Code, Application Binaries and Documentation in CodePlex BizTalk Mapper Extensions UtilityPack home page:

BizTalk Mapper Extensions UtilityPack
CodePlex

 

or from MSDN Code Gallery:

BizTalk Mapper Extensions UtilityPack for BizTalk Server 2010 (905.0 KB)
Microsoft | MSDN Code Gallery

Today I want to talk about a very common problem that can occur when we are invoking BizTalk Orchestrations exposed as a synchronous services (Request-Response Receive ports):

"System.Net.WebException: The operation has timed out"

System-Net-WebException-The-operation-has-timed-out-BizTalk-Orchestration

In my case I was trying to invoke an orchestration exposed as a WCF service. And of course this can be very straightforward problem, most of the times easy to detect and probably also to fix… but sometimes BizTalk tries to play with us and throw a few good surprises…

TYPICAL CAUSES AND SOLUTIONS

Typically this problem is usually associated with network problems or lack of Error Handling inside Orchestrations:

  • You are trying to invoke an external system inside the orchestration and it take too much time to respond and naturally we get a time out error.
    • The SOAP.ClientConnectionTimeout property can be used on a Web service that take a long time to return a response to try to solve or address this problem. See more here.
  • You can have a High Volume of request and you can overload the external service with too many concurrent calls or you can have limits of max connections to a certain address and will naturally this can cause affect the performance and provably will take too much time to respond.
  • This error can also occur when the BizTalk performance get degraded and it start responding slow. If the BizTalk jobs are not well configured and running the size of BizTalk Databases can grow extremely and responding very slow and we get stuck with this error.
    • You need to validate the jobs and the database and if necessary you need to configure the jobs and clean the databases with the Terminator tool and provably shrinking also the databases to resolve the problem.
  • Also you can get this error because you don’t want to handler errors inside orchestrations, so for example if you don’t handler WCF Fault messages from your external service or you are invoking a C# code and it raise an exception, and you are note handling this situations in your orchestration, the orchestration will be suspended an you will get a timed out exception.
Nothing fit in the problem. What can it be?

But … and when all this is checked and doesn’t fit in the problem that is happening. What can it be? Before explain let me describe my scenario:

  • I have a simple demo service that receive a small message, invoke an external service and return the message to the source system.
  • Because of API limitation I decide to invoke this external services with C# and control Exception inside orchestrations.
  • I know by using HAT and debugging in DEV environment that the external service was giving me a known error that I was controlling and throwing the error in order to create a response with the error description, inside the orchestration, to be returned to the original system.

So nothing to fancy and very simple stuff. However every time I tried to test the orchestration the orchestration was stuck in the message box in suspended state… the external service was invoked, the error was catch in the code, logged and the exception was raised for the orchestration and after that nothing … the engine seemed unaware and did not understand what was happening, crazy I know.

0XC0C01B52-Orchestration-Engine-Error

When I investigated the Event Viewer to try to find more information I found this description:

xlang/s engine event log entry: Uncaught exception (see the ‘inner exception’ below) has suspended an instance of service ‘MyOrchestration(728766c9-9df2-609b-004e-fa2e7c3079c4)’.
The service instance will remain suspended until administratively resumed or terminated.
If resumed the instance will continue from its last persisted state and may re-throw the same unexpected exception.
InstanceId: 4dfd6041-d52f-4110-8d0d-92efc48f0c38
Shape name: InvokeExternalService Shape
ShapeId: eff276fd-f289-4778-ba47-ff66309ae8c6
Exception thrown from: segment 2, progress 8
Inner exception: Fault Response: My Error Description

The first thing I thought was that I incorrectly published some resource (DLL) … but after validating and publishing the solution again, the problem prevailed.

CAUSE

The Orchestration Designer can play some tricks to developers. And be very careful when you copy shapes from one orchestration to others!

What I did was open a similar solution and copy the main scope (body of the orchestration) to a new solution that I had created. This will also copy all the shapes inside the scope… and of course I change the shapes to fit my new requirements, by deleting some shapes and change the code inside others… Why? To be faster and not lose much time creating the main sketch of the orchestration.

But be aware that the Orchestration design don’t like some of this operations (for me it’s a bug inside Orchestration design), and for some reason the designer doesn’t interpret well the shapes (“refactoring” or the “graphical interpretation”). He compile when the solution but in runtime we get stuck with the error “The service instance will remain suspended until administratively resumed or terminated. If resumed the instance will continue from its last persisted state and may re-throw the same unexpected exception.”

I don’t know if some also detect this behavior before but I already experience this twice.

SOLUTION

To solve this strange behavior you need to redesign the same Orchestration flow by:

  • Dragging new shapes to the Orchestration design and copy the exact same code inside the existing shapes to the new ones… you can also give the same names!
  • At the end delete the existing shapes (which had been copied).
  • Compile and deploy the project again.

Without doing anything more this solved my problem.

For the last weeks I have been preparing my demos for BizTalk Innovation day in Norway and Italy that will occur during September and October were I will talk about BizTalk Mapping Patterns and Best Practices. Functoids will definitely be one of the topics that I will discuss and the reason I published a new release of this project was the need of this new functoid for one of my labs.

Sometimes the functoids I create are inspired in real scenarios for the need of my clients, others requested by community members and sometimes for playing like this one… but always if I think for some reason that they will be useful in real scenarios. But regardless of the reasons, I am very glad that this project is constantly evolving and have already 23 functoids!

Project Description

BizTalk Mapper Extensions UtilityPack is a set of libraries with several useful functoids to include and use it in a map, which will provide an extension of BizTalk Mapper capabilities. This is the list of previous functoids available:

What’s new in this version?

In the BizTalk Business Rules Engine you can define a vocabulary which is essentially parameters which can be used within the execution of a rules policy. These vocabularies can be accessed from C# code so the idea here is that you could define constants in a vocabulary which you could deploy to the BRE which you would then access from a helper class to get your configuration data.

Rule Engine Config Get Functoid

This functoid allows you to obtain a definition value from a Vocabulary in the Business Rules Engine.

Parameters

The functoid takes one mandatory input parameters:

  1. String that represents the definition name (e.g. Value1).
  2. String that represents the vocabulary name (i.e. Config).

The output of the functoid is a string with the value of the definition name from a specify vocabulary on the Business Rule Engine: “Set dynamic constant using Business Rule Engine”

Rule-Engine-Config-Get-functoid

You can find the advantages and disadvantages for storing configurations in a Vocabulary in the Rules Engine in this post from Michael Stephenson: Where do I store my custom configuration for a BizTalk solution
You can found and download Source Code, Application Binaries and Documentation in CodePlex BizTalk Mapper Extensions UtilityPack home page:

BizTalk Mapper Extensions UtilityPack
CodePlex

 

or from MSDN Code Gallery:

BizTalk Mapper Extensions UtilityPack for BizTalk Server 2013 (538.1 KB)
Microsoft | MSDN Code Gallery

 

BizTalk Mapper Extensions UtilityPack for BizTalk Server 2010 (747.7 KB)
Microsoft | MSDN Code Gallery

Due to lot of work and a presentations mainly on BizTalk Innovation day events, I still had not managed to create new articles on TechNet Wiki this year, despite having lots of ideas and ongoing projects.

Unfortunately, with the weather not inviting outdoor activities in Portugal, a lot of rain, I got some free time at home to be able to research for my several projects and also to keep me updated. However while I was doing this research I noticed that I was constantly looking for the same resources over and over again. As a result I decided to create these two articles on TechNet Wiki, that although they are not technically difficult to create, are behind many hours (days) in research.

BizTalk Server: Presentations Gallery

Often we need to prepare presentations, whether for clients or for public speaking at a conference or event, and we end up always searching for these resources on the internet to provide inspiration, reference or simply to reuse certain features, design, content or animations. Or you simply like to have these resources for study or future references.

With about 100 presentation about BizTalk Server, since version 2000 to the latest product version: BizTalk Server 2013, this article is intended to be a knowledge base of all BizTalk slides presentations that are available.

BizTalk-Server-Presentations-Gallery

See the full article here: BizTalk Server: Presentations Gallery

BizTalk Server: Glossary

I just finished compiling this article yesterday and I spend all week work on it, and for me this is beyond a doubt a proper piece of beauty. Everything common term you can think of for BizTalk you may found here, ordered alphabetically.

While researching, I also found several Glossaries (here and here) on MSDN, which served as support to this article.

BizTalk-Server-Glossary

See the full article here: BizTalk Server: Glossary

And of course, if you can think in another term or have a presentation that isn’t there, add it yourself. Feel free to edit, change and add content! And I hope you will find these articles useful.

And the good thing about this two weeks of “work” is that I was two times (in two weeks) award as a Top Contributors in TechNet Wiki Sorriso.

Top-Contributor-Awards

Of course, this It’s not why I contribute on TechNet Wiki, but I find it funny and prestigious to see our work highlighted and referenced.

In the last months I have been working on some personal projects that are finally gaining life. One of them, I’ve already had the pleasure to announce here on my blog: New version of BizTalk Scheduled Task Adapter is now available on CodePlex.

And this is my last one!

BizTalk Multi-part Message Attachments Zipper Pipeline Component is a pipeline component for BizTalk Server 2010 which can be used in a send pipeline and is intended to replace all attachments of a multi-part message for its zipped equivalent.

BizTalk-Multi-part-Message-Attachments-Zipper-Pipeline-Component

The capabilities are similar to those available in compression software such as WinZip or 7-zip:

  • Attachments Compression – Extracts, in a send pipeline, all message parts include in a multi-part message that are not included in the message body (Message Body Part = False), compresses it and attaches the compressed attachment back to the message.

Requirements

The Multi-part Message Attachments Zipper will work with:

  • BizTalk Server 2010
  • .NET Framework 4.0

No compression/decompression software needs to be installed in the BizTalk Server.
BizTalk Multi-part Message Attachments Zipper Pipeline Component (65.6 KB)
Microsoft Code Gallery

or on CodePlex: BizTalk Multi-part Message Attachments Zipper Pipeline Component