Just Bizzie

Learn about the BizTalk Business rules Engine

2011-08-15T15:19:00.000-07:00

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.

Schema referenced by Map has been deleted. The local, cached version of the BizTalk Server group configuration is out of date.

2011-01-13T08:21:00.001-08:00

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.

BizTalk 2010 pipeline buildorder lost when using MsBuild.exe

2011-01-04T01:18:00.001-08:00

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.

BizTalk 2010 Setup fails when Trend Micro OfficeScan is installed

2010-11-29T05:08:00.000-08:00

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:

[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.

Migrating BizTalk 2006R2 sources to BizTalk 2010 without (too much) pain

2010-10-29T05:34:00.001-07:00

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.

Configuring the BizTalk Adapterpack 1.0 for use with BizTalk 2010 and Visual Studio 2010

2010-09-29T14:10:00.001-07:00

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.

BizTalk 2010 Setup fails at SSO Install.

2010-09-28T14:14:00.001-07:00

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.

Speeding up the BizTalk Administrator MMC

2010-02-12T05:20:00.001-08:00

I reached a patience limit when the BizTalk administrator took over 2 minutes from launch to showing me my application resources on my (rather slow) VM. I could not remember this ever taking that much time. Of course, BTA console never was a real fastloader, but this was getting excessive.

When I asked a co-worker to logon to the same machine and try the same actions, I was astonished see him do the same job on the same machine in less than 30 seconds. Clearly it was user, and thus, profile related.

I created a clean profile for myself to test this and was proven right. It took less than 30 seconds to get the app running and the resources loaded.

I then started to replace original content from my old profile and tested until I, again, reached a 2 minute+ loading time. Problem recreated, cause found.

It appears there is a settings file that controls, amongst others, the window and grid layout of the management console. Over time this file has grown in size from a mere 2kb default to over 600kb. Loading this file seemed to take too much resources and caused a delay that went to 2 minutes.

I simply deleted the file and things went back to normal. Here is the guilty party:
Microsoft.BizTalk.Administration.SnapIn.dll.config

You can find it in C:\Documents and Settings\-your account here-\Local Settings\Application Data\Microsoft Corporation\Microsoft BizTalk Server 2006\

Problem: BizTalk makes full backup every 15 minutes

2010-02-04T06:07:00.001-08:00

We recently encountered a problem where the BizTalk SQL Agent job that executes the backup procedure resulted in a full backup every run in stead of once every day.

We became aware of the issue when disk space events were fired by our monitoring software.

We found the problem when we looked into the table adm_BackupHistory in de BizTalkMgmtDb. For some reason someone had felt the need to manually execute the backup job and somehow managed to enter a date in the future as the last-run entry.

In stead of february 3rd, march 2nd was entered (European dd-mm-yyyy vs US mm-dd-yyyy mix-up.) A classic by al means.

This caused the backup's job logic to determine if it was time for a full backup to fail and always return true.

Once this part of the history was corrected, the Backup Job went back to normal operation.

Integrating with SAP using BizTalk 2009 64-bit

2009-12-18T16:27:00.001-08:00

Recently I found myself challenged to proof BizTalk (and the 2.0 adapter pack) were a relatively easy way to dig up the chest with RFC treasures buried within my clients SAP R3 installation.

Up untill this point SAP had been a well avoided obstacle in my career but now I thought, why not. How tough can it be.

It turned out to be relatively simple, ONCE you had all drivers in place :)

Using my brand new Windows Server 2008R2 VHD image with BizTalk 2009 running in Sun Virtualbox, I went on to install the necessary 64-bit SAP client dll's and 64-bit BizTalk adapterpack 2.0.

At the site I was then pleasantly surprised with several errors.

First several entries in the machine.config were not set by the installer. This was promptly corrected using the info found here

Second, Visual Studio informed of the fact that the SAP client dll's were not valid win32 images. That made sense: I was running 64-bit stuff. So what was the problem here?

It seems that the Visual Studio 2008 Consume Adapter Service dialog has a 32-bit dependancy. So you need both 32-bit AND 64-bit versions of BOTH the BizTalk adapter pack and the SAP client dll's.

Also you need to place the 64-bit SAP dll's into your Windows\System32 folder and the 32-bit dll's into the SysWOW64 folder.

Remember though that you may only install one version (64-bit of course) of the LOB Adapter SDK.

After all this the wizard did what it was supposed to do, offering the SAP binding. After creating schema's for a few sample RFC's the client was interested in, setting up a generic test and demonstrating the results we were done well within an hour.

So the steps:
1) Instal LOB Adapter SDK 64-bit with latest SP
2) Install 32-bit BizTalk Adapter pack 2.0*
3) Install 64-bit BizTalk Adapter pack 2.0
4) Install SAP client 32-bit dll's in SysWOW64*
5) Install SAP client 64-bit dll's in System32

Happy Sapping

*This is only needed on development stations. 64-bit Production servers do not need 32-bit installations of the adapter pack or the SAP client dll's UNLESS you are somehow required to run a 32-bit adapter, host instance or client. Then all, client, host and adapter, need to be 32-bit

Introduction

2009-11-16T05:44:00.000-08:00

Being an experienced BizTalk Developer, Architect and Consultant I have had the fortune that so many many of us post their knowledge and findings to the internet. It helped me understand the deeper workings and architecture of BizTalk and it's place in the .Net universe.

I have to thank the ' Big Names' like Paolo, Scott, Brian, Marty and Joshi for pushing this to begin with. Some know me, most don't but I am grateful to all of them.

It is time to return the favor: here I will post whatever I find and the experiences I had with BizTalk, be it coding components, tricking the messagebox or BP's for development, deployment and, the big neglected factor, positioning and maintenance within the enterprise

As an extra I have plans to take anything SOA related that could be interesting to the BizTalk community and put it up here. Be patient though, my time is limited and insufficient to fulfil all my ambitions in life :)