by Jeroen | Apr 8, 2016 | BizTalk Community Blogs via Syndication
The Problem:
After configuring a brand new BizTalk 2013R2 production environment and requesting the needed firewall exclusions to the security department, we were unable to send messages to Azure ServiceBus using the SB-Messaging adapter in BizTalk 2013R2 (using ACS authentication). We found the following warning in the EventLog:
The adapter “SB-Messaging” raised an error message. Details “System.ServiceModel.EndpointNotFoundException: The X.509 certificate CN=servicebus.windows.net is not in the trusted people store. The X.509 certificate CN=servicebus.windows.net chain building failed. The certificate that was used has a trust chain that cannot be verified. Replace the certificate or change the certificateValidationMode. A certificate chain could not be built to a trusted root authority.
The Solution:
Thanks to this post on StackOverflow I was able to fix the problem by “auto installing” the missing certificate.
The following steps solved our problem:
- Configure the company web proxy needed for internet connectivity on the server used by BizTalk for ServiceBus connectivity
- Use a .NET console test application to send/receive a dummy message to an Azure ServiceBus test queue
- Remove the web proxy config
- Repeat on every server
- Test using the BizTalk SB-Messaging Adapter
After using the console test application, we got the following info message in the eventlog:
Small sidenote regarding the .NET console test application, make sure you use the “AutoDetect” connectivity mode:
1
|
ServiceBusEnvironment.SystemConnectivity.Mode = ConnectivityMode.AutoDetect;
|
by Jeroen | Dec 12, 2015 | BizTalk Community Blogs via Syndication
What we learned when migrating a BizTalk Server 2006 farm (with multiple solutions/projects) to BizTalk Server 2013R2:
1. You need an intermediate step
Migrating BizTalk 2006 solutions directly to BizTalk 2013R2 (Visualt Studio 2013) is not supported. You will need to migrate the solution to BizTalk 2010 (Visual Studio 2010) first as an intermediate step. More information here in a MSDN forum thread. (nothing fancy in this one I must admit, but you need to take this step into account when estimating an upgrade…)
2. Install the latest BizTalk CU on your development machine
The fact that we needed an extra intermediate step in the migration process was no big deal in our situatuion. We had an emtpy VM with BizTalk 2010 and Visual Studio 2010 in place. This machine was installed a few years ago by a developer, but was never used. It had no BizTalk Cumulative Updates installed.
We didn’t have any issues when migrating simple BizTalk 2006 solutions. We migrated to BizTalk 2010 and then migrated to BizTalk 2013R2 on an other machine.
When migrating the more complex solutions (big orchestrations and lots of ASMX web ports), we started to experience some weird behaviour in Visual Studio 2010:
That last error lead us in the right direction: BizTalk Server 2010 CU2:
This issue might also occur when you try to build a BizTalk Server 2010 solution that was converted from a Microsoft BizTalk Server 2006 R2 or Microsoft BizTalk Server 2009 solution in Visual Studio 2010.
After installing BizTalk Server 2010 CU8 on our development machine (the latest update at that moment), we restarted the migration (from the original BizTalk 2006 solution) of those complex projects, without the need to replace anything. The whole migration process completed without any error!
So, spare yourself the misery and start with a fully up to date BizTalk 2010 development environment. Other blogs on the internet might suggest to fix the “mismatched ‘braces’ ‘{}’ error” error by manually editting the .odx file. This was not the correct fix in our case as the error kept returning after every other change in the orchestration.
by Jeroen | Dec 12, 2015 | BizTalk Community Blogs via Syndication
What we learned when migrating a BizTalk Server 2006 farm (with multiple solutions/projects) to BizTalk Server 2013R2:
1. You need an intermediate step
Migrating BizTalk 2006 solutions directly to BizTalk 2013R2 (Visualt Studio 2013) is not supported. You will need to migrate the solution to BizTalk 2010 (Visual Studio 2010) first as an intermediate step. More information here in a MSDN forum thread. (nothing fancy in this one I must admit, but you need to take this step into account when estimating an upgrade…)
2. Install the latest BizTalk CU on your development machine
The fact that we needed an extra intermediate step in the migration process was no big deal in our situatuion. We had an emtpy VM with BizTalk 2010 and Visual Studio 2010 in place. This machine was installed a few years ago by a developer, but was never used. It had no BizTalk Cumulative Updates installed.
We didn’t have any issues when migrating simple BizTalk 2006 solutions. We migrated to BizTalk 2010 and then migrated to BizTalk 2013R2 on an other machine.
When migrating the more complex solutions (big orchestrations and lots of ASMX web ports), we started to experience some weird behaviour in Visual Studio 2010:
That last error lead us in the right direction: BizTalk Server 2010 CU2:
This issue might also occur when you try to build a BizTalk Server 2010 solution that was converted from a Microsoft BizTalk Server 2006 R2 or Microsoft BizTalk Server 2009 solution in Visual Studio 2010.
After installing BizTalk Server 2010 CU8 on our development machine (the latest update at that moment), we restarted the migration (from the original BizTalk 2006 solution) of those complex projects, without the need to replace anything. The whole migration process completed without any error!
So, spare yourself the misery and start with a fully up to date BizTalk 2010 development environment. Other blogs on the internet might suggest to fix the “mismatched ‘braces’ ‘{}’ error” error by manually editting the .odx file. This was not the correct fix in our case as the error kept returning after every other change in the orchestration.
by Jeroen | Dec 5, 2015 | BizTalk Community Blogs via Syndication
In a current integration scenario we are heavily using dynamic transforms in our solution. The combination with the Business Rules Engine (that holds the logic to determine the required output message version) makes it possible to map to the desired message format and version for a given partner.
The problem in our case was that we don’t now the version of the assembly that holds the BizTalk maps (caused by our build server setup). Otherwise we would have been able to store the MapName and AssemblyName in the BRE like showcased in this MSDN sample. Thanks to this query against the BizTalkMgmtDb we are able to find the correct map currently deployed on BizTalk Server. The query needs the incoming message type and the destination message type. (in our solution the destination message type is dynamically returned by the BRE)
Sample output of the query:
by Jeroen | Dec 5, 2015 | BizTalk Community Blogs via Syndication
In a current integration scenario we are heavily using dynamic transforms in our solution. The combination with the Business Rules Engine (that holds the logic to determine the required output message version) makes it possible to map to the desired message format and version for a given partner.
The problem in our case was that we don’t now the version of the assembly that holds the BizTalk maps (caused by our build server setup). Otherwise we would have been able to store the MapName and AssemblyName in the BRE like showcased in this MSDN sample. Thanks to this query against the BizTalkMgmtDb we are able to find the correct map currently deployed on BizTalk Server. The query needs the incoming message type and the destination message type. (in our solution the destination message type is dynamically returned by the BRE)
Sample output of the query:
by Jeroen | Dec 5, 2015 | BizTalk Community Blogs via Syndication
In a current integration scenario we are heavily using dynamic transforms in our solution. The combination with the Business Rules Engine (that holds the logic to determine the required output message version) makes it possible to map to the desired message format and version for a given partner.
The problem in our case was that we don’t now the version of the assembly that holds the BizTalk maps (caused by our build server setup). Otherwise we would have been able to store the MapName and AssemblyName in the BRE like showcased in this MSDN sample. Thanks to this query against the BizTalkMgmtDb we are able to find the correct map currently deployed on BizTalk Server. The query needs the incoming message type and the destination message type. (in our solution the destination message type is dynamically returned by the BRE)
Sample output of the query:
by Jeroen | Nov 29, 2015 | BizTalk Community Blogs via Syndication
Normally when you receive an exception with the message “The document type does not match any of the given schemas” in BizTalk, this means your schemas are not (yet) deployed, your are missing an application reference to the project containing your schemas or you have a configuration mistake in your pipeline.
This time, unfortunately, it was not the normal case.
The integration scenario
The cause
In our ESB Itinerary Processing stage, we copy/alter most of the incoming context properties. One of the properties copied is the “DocumentSpecName”. This one, was the one responsible for chocking up our send pipeline. (Read this post by Johann for some more info on the subject and other possible scenarios where you might experience this behaviour)
The fix
We choose to reset (= write null) the value of the “DocumentSpecName” property in the “Pre-Assemble” stage in our send pipeline. To make sure the XML Assembler doesn’t choke up.
The code used to reset the the DocumentSpecName in the “Set DocumentSpecName” PipelineComponent:
1
2
3
4
5
6
7
8
9
|
private void DoWrite(Microsoft.BizTalk.Message.Interop.IBaseMessage inmsg)
{
if (!string.IsNullOrEmpty(DocumentSpecName))
inmsg.Context.Write("DocumentSpecName", "http://schemas.microsoft.com/BizTalk/2003/xmlnorm-properties", DocumentSpecName);
else
inmsg.Context.Write("DocumentSpecName", "http://schemas.microsoft.com/BizTalk/2003/xmlnorm-properties", null);
outMsg = inmsg;
}
|
by Jeroen | Nov 29, 2015 | BizTalk Community Blogs via Syndication
Normally when you receive an exception with the message “The document type does not match any of the given schemas” in BizTalk, this means your schemas are not (yet) deployed, your are missing an application reference to the project containing your schemas or you have a configuration mistake in your pipeline.
This time, unfortunately, it was not the normal case.
The integration scenario
The cause
In our ESB Itinerary Processing stage, we copy/alter most of the incoming context properties. One of the properties copied is the “DocumentSpecName”. This one, was the one responsible for chocking up our send pipeline. (Read this post by Johann for some more info on the subject and other possible scenarios where you might experience this behaviour)
The fix
We choose to reset (= write null) the value of the “DocumentSpecName” property in the “Pre-Assemble” stage in our send pipeline. To make sure the XML Assembler doesn’t choke up.
The code used to reset the the DocumentSpecName in the “Set DocumentSpecName” PipelineComponent:
1
2
3
4
5
6
7
8
9
|
private void DoWrite(Microsoft.BizTalk.Message.Interop.IBaseMessage inmsg)
{
if (!string.IsNullOrEmpty(DocumentSpecName))
inmsg.Context.Write("DocumentSpecName", "http://schemas.microsoft.com/BizTalk/2003/xmlnorm-properties", DocumentSpecName);
else
inmsg.Context.Write("DocumentSpecName", "http://schemas.microsoft.com/BizTalk/2003/xmlnorm-properties", null);
outMsg = inmsg;
}
|
by Jeroen | Nov 29, 2015 | BizTalk Community Blogs via Syndication
Normally when you receive an exception with the message “The document type does not match any of the given schemas” in BizTalk, this means your schemas are not (yet) deployed, your are missing an application reference to the project containing your schemas or you have a configuration mistake in your pipeline.
This time, unfortunately, it was not the normal case.
The integration scenario
The cause
In our ESB Itinerary Processing stage, we copy/alter most of the incoming context properties. One of the properties copied is the “DocumentSpecName”. This one, was the one responsible for chocking up our send pipeline. (Read this post by Johann for some more info on the subject and other possible scenarios where you might experience this behaviour)
The fix
We choose to reset (= write null) the value of the “DocumentSpecName” property in the “Pre-Assemble” stage in our send pipeline. To make sure the XML Assembler doesn’t choke up.
The code used to reset the the DocumentSpecName in the “Set DocumentSpecName” PipelineComponent:
1
2
3
4
5
6
7
8
9
|
private void DoWrite(Microsoft.BizTalk.Message.Interop.IBaseMessage inmsg)
{
if (!string.IsNullOrEmpty(DocumentSpecName))
inmsg.Context.Write("DocumentSpecName", "http://schemas.microsoft.com/BizTalk/2003/xmlnorm-properties", DocumentSpecName);
else
inmsg.Context.Write("DocumentSpecName", "http://schemas.microsoft.com/BizTalk/2003/xmlnorm-properties", null);
outMsg = inmsg;
}
|
by Jeroen | Jan 31, 2015 | BizTalk Community Blogs via Syndication
Today I published one of my little projects on GitHub. It’s called BTFGui and in essence it is just a simple GUI around the BizTalkFactory Management Automation (SDK) to do some basic BizTalk Administration.
Currently it has the following features:
- Stop/Restart HostInstances
- Stop/Restart Applications
- Remote Applications
- Export Application Bindings
- Terminate Suspended Instances
You can find It here on GitHub.
The main reason why I put this little thing together is simple: the BizTalk Administration Console can be very slow and time wasting if you just want to restart a hostinstance or export a binding. Therefore I created BTFGui and I can tell you that it saves me a lot of time when developing on my local BizTalk Server instance.
