maandag 15 augustus 2011
Learn about the BizTalk Business rules Engine
One of the strong points of the BizTalk Server Integration suite is the inclusion of a very versatile, flexible and extendable Business rules engine.
This versatility, however, is the same thing that makes it widely underused in deployments using BizTalk Server. Even today, being on the market in various versions for more than 6 years, I see people often struggle with it.
The root problem: the same flexibility and versatility comes with a rather steep learning curve to master.
To help you get started, Microsoft has packed a hands-on learning guide into a Virtual Lab. You can get to it here.
Try it, you won't be disappointed.
donderdag 13 januari 2011
Schema referenced by Map has been deleted. The local, cached version of the BizTalk Server group configuration is out of date.
When deploying schema's and related maps to BizTalk Server 2010, you may receive the following error when undeploying the map:
Schema referenced by Map "*****" has been deleted. The local, cached version of the BizTalk Server group configuration is out of date. You must refresh the BizTalk Server group configuration before making further changes.
Me and a colleague discovered that this may be related to the Map project and the Schema project sharing the same .Net namespace.
When we deploy a solution that has 1 single namespace like company.application for all projects, we always encounter this error.
When we deploy solutions that have different namespaces per project, like company.application.schemas and company.application.maps, this will not occur.
This behaviour (bug?) is different from behaviour in BizTalk 2004 and 2006R2. I have not tested this in BizTalk 2009.
To remedy this problem, manualy undeploy the maps first, than the schemas.
If you have schemas and maps in a single project (not a best practice) you also have no problems.
Schema referenced by Map "*****" has been deleted. The local, cached version of the BizTalk Server group configuration is out of date. You must refresh the BizTalk Server group configuration before making further changes.
Me and a colleague discovered that this may be related to the Map project and the Schema project sharing the same .Net namespace.
When we deploy a solution that has 1 single namespace like company.application for all projects, we always encounter this error.
When we deploy solutions that have different namespaces per project, like company.application.schemas and company.application.maps, this will not occur.
This behaviour (bug?) is different from behaviour in BizTalk 2004 and 2006R2. I have not tested this in BizTalk 2009.
To remedy this problem, manualy undeploy the maps first, than the schemas.
If you have schemas and maps in a single project (not a best practice) you also have no problems.
dinsdag 4 januari 2011
BizTalk 2010 pipeline buildorder lost when using MsBuild.exe
When building solutions outside Visual Studio 2010 that contain both a pipeline project and a pipeline components project, building may fail.
As it seems, determining the buildorder for the components seems to be inclusive, leading for some solutions to fail with the message that references to the pipeline components cannot be resolved.
Cause for this is the fact that the reference is always to the GAC, not to a project. Somehow Visual Studio 'knows' this and acts accordingly, and when using MSBUILS this might fail. I say might, as we have solutions that do build consistently aswell as solutions that do fail consistently.
In order to 'fix' this, you have to manualy set your projects dependency.
In Visual Studio, right-click the solution and select Properties.
On the propertyscreen select Project Dependencies
There, select your Pipeline project and check the dependency with the Pipeline component.
Klik Apply, then save the solution.
As it seems, determining the buildorder for the components seems to be inclusive, leading for some solutions to fail with the message that references to the pipeline components cannot be resolved.
Cause for this is the fact that the reference is always to the GAC, not to a project. Somehow Visual Studio 'knows' this and acts accordingly, and when using MSBUILS this might fail. I say might, as we have solutions that do build consistently aswell as solutions that do fail consistently.
In order to 'fix' this, you have to manualy set your projects dependency.
In Visual Studio, right-click the solution and select Properties.
On the propertyscreen select Project Dependencies
There, select your Pipeline project and check the dependency with the Pipeline component.
Klik Apply, then save the solution.
maandag 29 november 2010
BizTalk 2010 Setup fails when Trend Micro OfficeScan is installed
When you try to install BizTalk Server on a system that has Trend Micro Officescan installed, you might run into an error.
It will do this when trying to stop windows services, as shown in this setup screen fragment:
When examining the logfile you will encounter this entry:
When analyzing the detaild log, you find this entry:
Reason for this is that BizTalk Setup tries to stop and start the WMI Service. As Officescan is dependent on this, it would als need to be stopped and started and that might be disabled as a policy. As a result setup fails.
To check if this is indeed the cause, try to stop the WMI Service by hand using the services manager in Administrative Tools. If it gives a list containing the service OfficeScan NT Listener.
In order to succeed, you need have Trend services disabled by a domain administrator. I suggest installing a scanning tool that does not rely on heavily used services.
It will do this when trying to stop windows services, as shown in this setup screen fragment:
When examining the logfile you will encounter this entry:
[2:18:33 PM Info] Action 14:18:33: StopServices. Stopping services
[2:18:37 PM Info] Detailed Log information for product E:\Msi\Microsoft BizTalk Server 2010_64.msi is available at DetailedLog
[2:18:37 PM Info] MSI installation returned 1601 - The Windows Installer Service could not be accessed. This can occur if the Windows Installer is not correctly installed. Contact your support personnel for assistance.
When analyzing the detaild log, you find this entry:
MSI (s) (5C:E8) [14:18:33:961]: Executing op: ServiceControl(,Name=WinMgmt,Action=2,Wait=1,)
MSI (s) (5C:E8) [14:18:37:493]: Internal Exception during install operation: 0xc00000fd at 0x000000007723A725.
Reason for this is that BizTalk Setup tries to stop and start the WMI Service. As Officescan is dependent on this, it would als need to be stopped and started and that might be disabled as a policy. As a result setup fails.
To check if this is indeed the cause, try to stop the WMI Service by hand using the services manager in Administrative Tools. If it gives a list containing the service OfficeScan NT Listener.
In order to succeed, you need have Trend services disabled by a domain administrator. I suggest installing a scanning tool that does not rely on heavily used services.
vrijdag 29 oktober 2010
Migrating BizTalk 2006R2 sources to BizTalk 2010 without (too much) pain
I ran into it. You probably did too. You tried to convert your BizTalk 2006R2 solution to BizTalk 2010 (or 2009) and found that your solution was OK, your C# libraries went just fine, but none of your BizTalk projects had been converted.
Then, when you retried this from the converted solution, or tried to load a .btproj directly, you got that dreaded message: Error converting project file. The element <BIZTALK> beneath element <VisualStudioProject> is unrecognized.
I 'blame' the BizTalk Deployment framework for this as Microsoft clearly thought noone would ever try to move away from the suggested Deployment and Development build configurations. So if you, as we did, change it to Debug and Release when we moved to the BTDF, you are in for a bit of work.
Now I have for you the best way to get going. I found it just out of sheer desperation trying to get things working the way they should.
The best part? It takes just about 5 minutes per solution, independent of the size of it!!. It has worked for all solutions I have tried so far.
Now, How to do it.(NOTE: This walkthrough demonstrates the principle. There are several optimizations possible, especially when executing text search and replace actions on files)
1) Make sure you have a backup of your solution file BEFORE trying any conversions. You need the clean 2006R2 version. (or : you can of course also use an Undo Pending Changes option of you TFS). Also, as pointed out by other users of this method, delete any .user files within the solution you want to convert.
2)Just open the solution in Visual Studio 2010 as you want to. This will prompt the upgrade wizard to do what it does best.
3)Review the loaded solution. You should have a converted solution, loaded C# libraries and unloaded BizTalk projects.
4) Close all windows in Visual Studio.
5) Right-click each unloaded project file and select Edit to open it in text mode. You now should have all files open in text mode.
6) Using basic search and replace do a replace on all open documents replacing Name = "Debug" by Name = "Development" and replacing Name = "Release" with Name = "Deployment". Each replace should give a count of items replaced equal to the number op open BizTalk projects.
7) Now the big trick: Either close your solution and put back the backed up .sln file you made earlier and then re-open your solution OR just select Undo Pending changes on your solution file (AND JUST THE SOLUTION FILE...)
8) The Migration Wizard will trigger again and now will convert your BizTalk projects as expected.
9) Now we are almost done, except that you BizTalk project has a configuration base (Deployment/Development) that has not been defined in the solution (Release/Debug).
You need to get this back in sync. To do this, unload all BizTalk projects from the solution (right-click, select unload) and once again open them in textmode (all other windows closed)
10) Now reverse the replace: replace "Development" with "Debug" and replace "Deployment" with "Release". Save all files, then close all files.
11) Close and reopen you solution, as for some reason, Visual Studio complains about reloading projects that are already opened under the solution if you try to reload them now. Even when they are closed...
12) Reload all BizTalk projects in the solution, save and we are done.
So. I hope this just will get you going. Any comments, as always, are appreciated to make this work better, make note of exceptions to the rule etc etc.
As an add-on: Of course it is also possible to migrate an entire collection of solutions under TFS this way. You still need to open each and every solution in between the two find/replace actions. You can use VS's find/replace in Files option when viewing your source-control page to process all .btproj files from a given location down.
Then, when you retried this from the converted solution, or tried to load a .btproj directly, you got that dreaded message: Error converting project file. The element <BIZTALK> beneath element <VisualStudioProject> is unrecognized.
I 'blame' the BizTalk Deployment framework for this as Microsoft clearly thought noone would ever try to move away from the suggested Deployment and Development build configurations. So if you, as we did, change it to Debug and Release when we moved to the BTDF, you are in for a bit of work.
Now I have for you the best way to get going. I found it just out of sheer desperation trying to get things working the way they should.
The best part? It takes just about 5 minutes per solution, independent of the size of it!!. It has worked for all solutions I have tried so far.
Now, How to do it.(NOTE: This walkthrough demonstrates the principle. There are several optimizations possible, especially when executing text search and replace actions on files)
1) Make sure you have a backup of your solution file BEFORE trying any conversions. You need the clean 2006R2 version. (or : you can of course also use an Undo Pending Changes option of you TFS). Also, as pointed out by other users of this method, delete any .user files within the solution you want to convert.
2)Just open the solution in Visual Studio 2010 as you want to. This will prompt the upgrade wizard to do what it does best.
3)Review the loaded solution. You should have a converted solution, loaded C# libraries and unloaded BizTalk projects.
4) Close all windows in Visual Studio.
5) Right-click each unloaded project file and select Edit
6) Using basic search and replace do a replace on all open documents replacing Name = "Debug" by Name = "Development" and replacing Name = "Release" with Name = "Deployment". Each replace should give a count of items replaced equal to the number op open BizTalk projects.
7) Now the big trick: Either close your solution and put back the backed up .sln file you made earlier and then re-open your solution OR just select Undo Pending changes on your solution file (AND JUST THE SOLUTION FILE...)
8) The Migration Wizard will trigger again and now will convert your BizTalk projects as expected.
9) Now we are almost done, except that you BizTalk project has a configuration base (Deployment/Development) that has not been defined in the solution (Release/Debug).
You need to get this back in sync. To do this, unload all BizTalk projects from the solution (right-click, select unload) and once again open them in textmode (all other windows closed)
10) Now reverse the replace: replace "Development" with "Debug" and replace "Deployment" with "Release". Save all files, then close all files.
11) Close and reopen you solution, as for some reason, Visual Studio complains about reloading projects that are already opened under the solution if you try to reload them now. Even when they are closed...
12) Reload all BizTalk projects in the solution, save and we are done.
So. I hope this just will get you going. Any comments, as always, are appreciated to make this work better, make note of exceptions to the rule etc etc.
As an add-on: Of course it is also possible to migrate an entire collection of solutions under TFS this way. You still need to open each and every solution in between the two find/replace actions. You can use VS's find/replace in Files option when viewing your source-control page to process all .btproj files from a given location down.
woensdag 29 september 2010
Configuring the BizTalk Adapterpack 1.0 for use with BizTalk 2010 and Visual Studio 2010
I have a problem. A big monkey problem. I have been using the BizTalk Adapterpack 1.0 at my customer site to unlock precious Oracle 8.1.7 resources about 2 years ago.
No problem? Yes it is. The Oracle Client 10g is the last version to support connections to these databases. This means I cannot use Adapterpack 2.0 or the new BizTalk Adapterpack 2010. Of course, the client COULD upgrade the databases, but my guess is that these systems will be around for another year or two. They could live through one more generation if I could somehow use the Adapterpack 1.0 with BizTalk 2010.
Luckily it is not that hard to configure the Adapterpack 1.0 for use with BizTalk 2010. Here is how to do it. (NOTE: I did not describe the Oracle client dependencies. If you need those, drop me a note.)
1) Install the LOB WCF Adapter SDK 2010 for use with your platform (32 or 64 bit).
2) Install the BizTalk Adapterpack 1.0 for 32-bit and, if applicable, 64-bit.
Now normally this would be it. But since .Net 4.0 we have a new machine.config that is not known to the Adapterpack 1.0 installer. So we have to manually register the adapters to the machine.config in the %windir%\Microsoft.Net\Framework\v4.0.30319\CONFIG\machine.config
If you have a 64-bit platform you need to repeat this for the %windir%\Microsoft.Net\Framework64\v4.0.30319\CONFIG\machine.config.
What settings do you need to copy from the 2.x machine.config. Below is a list for all the adapters in the pack. If you chose to just install the Oracle Adapter, you can ignore all the steps/lines that mention SAP or SIEBEL. Just do not copy them.
Configuring the 32-bit adapters
from <system.data><DbProviderFactories> copy the following lines to the <system.data><DbProviderFactories> section in the .Net 4.0 machine.config:
<add name="SiebelClient Data Provider" invariant="Microsoft.Data.SiebelClient"
description=".NET Framework Data Provider for Siebel eBusiness Applications"
type="Microsoft.Data.SiebelClient.SiebelClientFactory,Microsoft.Data.SiebelClient, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />
<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=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />
from <system.serviceModel><extensions><bindingElementExtensions> you need to copy these lines to the <system.serviceModel><extensions><bindingElementExtensions> node in the .Net 4.0 machine.config:
<add name="siebelAdapter" type="Microsoft.Adapters.Siebel.SiebelAdapterExtensionElement,Microsoft.Adapters.Siebel, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />
<add name="sapAdapter" type="Microsoft.Adapters.SAP.SAPAdapterExtensionElement,Microsoft.Adapters.SAP, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />
<add name="oracleDBAdapter" type="Microsoft.Adapters.OracleDB.OracleDBAdapterExtensionElement,Microsoft.Adapters.OracleDB, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />
from <system.serviceModel><extensions><bindingExtensions> you need to copy these lines to the corresponding place in the .Net 4.0 machine.config:
<add name="siebelBinding" type="Microsoft.Adapters.Siebel.SiebelAdapterBindingSection,Microsoft.Adapters.Siebel, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />
<add name="sapBinding" type="Microsoft.Adapters.SAP.SAPAdapterBindingSection,Microsoft.Adapters.SAP, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />
<add name="oracleDBBinding" type="Microsoft.Adapters.OracleDB.OracleDBAdapterBindingSection,Microsoft.Adapters.OracleDB, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />
from <system.serviceModel><client> you need to copy these lines:
<endpoint binding="siebelBinding" contract="IMetadataExchange"
name="siebel" />
<endpoint binding="sapBinding" contract="IMetadataExchange" name="sap" />
<endpoint binding="oracleDBBinding" contract="IMetadataExchange"
name="oracledb" />
Configuring the 64-bit adapters
You have to copy the exact same entries on a 64-bit machine to the %windir%\Microsoft.Net\Framework64\v4.0.30319\CONFIG\machine.config with one exception: the Siebel adapter does not have a 64-bit version.
Warning
The catch to this is the following: You cannot use the Adapterpack 1.0 with other versions side-by-side due to dependencies.
== UNTESTED : DO TRY THIS AT HOME FIRST :) ==
If you really need the functionality of different packs, I guess you could have a dedicated host, only to run on a dedicated BizTalk node in the group which has an other (or this) version installed. Configuring this, however, is a problem as you need to manage the group from two different(!) machines which also have these adapterpacks installed this way... better (not) try it.
No problem? Yes it is. The Oracle Client 10g is the last version to support connections to these databases. This means I cannot use Adapterpack 2.0 or the new BizTalk Adapterpack 2010. Of course, the client COULD upgrade the databases, but my guess is that these systems will be around for another year or two. They could live through one more generation if I could somehow use the Adapterpack 1.0 with BizTalk 2010.
Luckily it is not that hard to configure the Adapterpack 1.0 for use with BizTalk 2010. Here is how to do it. (NOTE: I did not describe the Oracle client dependencies. If you need those, drop me a note.)
1) Install the LOB WCF Adapter SDK 2010 for use with your platform (32 or 64 bit).
2) Install the BizTalk Adapterpack 1.0 for 32-bit and, if applicable, 64-bit.
Now normally this would be it. But since .Net 4.0 we have a new machine.config that is not known to the Adapterpack 1.0 installer. So we have to manually register the adapters to the machine.config in the %windir%\Microsoft.Net\Framework\v4.0.30319\CONFIG\machine.config
If you have a 64-bit platform you need to repeat this for the %windir%\Microsoft.Net\Framework64\v4.0.30319\CONFIG\machine.config.
What settings do you need to copy from the 2.x machine.config. Below is a list for all the adapters in the pack. If you chose to just install the Oracle Adapter, you can ignore all the steps/lines that mention SAP or SIEBEL. Just do not copy them.
Configuring the 32-bit adapters
from <system.data><DbProviderFactories> copy the following lines to the <system.data><DbProviderFactories> section in the .Net 4.0 machine.config:
<add name="SiebelClient Data Provider" invariant="Microsoft.Data.SiebelClient"
description=".NET Framework Data Provider for Siebel eBusiness Applications"
type="Microsoft.Data.SiebelClient.SiebelClientFactory,Microsoft.Data.SiebelClient, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />
<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=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />
from <system.serviceModel><extensions><bindingElementExtensions> you need to copy these lines to the <system.serviceModel><extensions><bindingElementExtensions> node in the .Net 4.0 machine.config:
<add name="siebelAdapter" type="Microsoft.Adapters.Siebel.SiebelAdapterExtensionElement,Microsoft.Adapters.Siebel, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />
<add name="sapAdapter" type="Microsoft.Adapters.SAP.SAPAdapterExtensionElement,Microsoft.Adapters.SAP, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />
<add name="oracleDBAdapter" type="Microsoft.Adapters.OracleDB.OracleDBAdapterExtensionElement,Microsoft.Adapters.OracleDB, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />
from <system.serviceModel><extensions><bindingExtensions> you need to copy these lines to the corresponding place in the .Net 4.0 machine.config:
<add name="siebelBinding" type="Microsoft.Adapters.Siebel.SiebelAdapterBindingSection,Microsoft.Adapters.Siebel, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />
<add name="sapBinding" type="Microsoft.Adapters.SAP.SAPAdapterBindingSection,Microsoft.Adapters.SAP, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />
<add name="oracleDBBinding" type="Microsoft.Adapters.OracleDB.OracleDBAdapterBindingSection,Microsoft.Adapters.OracleDB, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />
from <system.serviceModel><client> you need to copy these lines:
<endpoint binding="siebelBinding" contract="IMetadataExchange"
name="siebel" />
<endpoint binding="sapBinding" contract="IMetadataExchange" name="sap" />
<endpoint binding="oracleDBBinding" contract="IMetadataExchange"
name="oracledb" />
Configuring the 64-bit adapters
You have to copy the exact same entries on a 64-bit machine to the %windir%\Microsoft.Net\Framework64\v4.0.30319\CONFIG\machine.config with one exception: the Siebel adapter does not have a 64-bit version.
Warning
The catch to this is the following: You cannot use the Adapterpack 1.0 with other versions side-by-side due to dependencies.
== UNTESTED : DO TRY THIS AT HOME FIRST :) ==
If you really need the functionality of different packs, I guess you could have a dedicated host, only to run on a dedicated BizTalk node in the group which has an other (or this) version installed. Configuring this, however, is a problem as you need to manage the group from two different(!) machines which also have these adapterpacks installed this way... better (not) try it.
dinsdag 28 september 2010
BizTalk 2010 Setup fails at SSO Install.
While installing the recently released BizTalk 2010 Developer Edition, I ran into an unexpected installation error.
The Enterprise Single Sign-On installation failed complaining that it was unable to 'find the path specified'.
Manually installing ENT SSO from the \BT Server\Platform\SSO64 did not do me much good; the installation failed as stand-alone also.
In the end I found that the problem was that I was installing from a network location, even though it was mapped to a drive letter.
To be exact: I was installing onto a VMWare Windows 2008R2 64-bit image, mapping a shared folder on the host holding the installation files.
I have found that there are two ways that will get you out of this:
1) Create an ISO and mount it from the VMWare image as CD.
2) Copy it to a virtual disk local to the VMWare image.
Problem solved.
The Enterprise Single Sign-On installation failed complaining that it was unable to 'find the path specified'.
Manually installing ENT SSO from the \BT Server\Platform\SSO64 did not do me much good; the installation failed as stand-alone also.
In the end I found that the problem was that I was installing from a network location, even though it was mapped to a drive letter.
To be exact: I was installing onto a VMWare Windows 2008R2 64-bit image, mapping a shared folder on the host holding the installation files.
I have found that there are two ways that will get you out of this:
1) Create an ISO and mount it from the VMWare image as CD.
2) Copy it to a virtual disk local to the VMWare image.
Problem solved.
Abonneren op:
Posts (Atom)
