Bug in the BizTalk WCF-custom adapter

The bug described below, have been confirmed by Microsoft, and I’ve received and tested a private fix. According to Microsoft a simple fix like this will most likely be approved, and if so, it might be included in the BizTalk 2009 Cumulative Update 1 to be release soon (1-2 months).

Now for the details on the bug:

Lately I’ve been working with the WFC-custom adapter in several exception handling scenarios on BizTalk 2009.

Recently I’ve discovered a bug in the BizTalk WFC-custom adapters handling of WCF-faults in cases where we have:

1. a binding that uses sessions, say the default configuration of the wsHttpBinding, and
2. a WCF-custom send port that doesn’t propagate wcf faults

In this case, in the default configuration, the WCF service hangs after 10 typed WCF-faults.

If we use WCF service throttling on the server, setting maxConcurrentCalls, maxConcurrentInstances and maxConcurrentSessions the service hangs after min(maxConcurrentInstances, maxConcurrentSessions), that is after two call in the throttling example above.

Apparently, in the case of a typed WCF fault, the BizTalk WCF-custom adapter doesn’t end the connection properly. On the other hand, if the server returns the non typed WCF fault the service doesn’t hang (returning non typed WCF faults isn’t best practice though).

After reading Matevz Gacnik's Weblog:

http://www.request-response.com/blog/PermaLink,guid,f731e5cc-9490-4f1e-bc7d-efb91f357cd1.aspx

and a bit of experimenting with a simple WCF-client, we realize that different WCF exceptions need different actions when ending the connection: Handling a typed WCF fault should include a call to the client proxy method Close, as is the case for successful calls. On the other hand: handling, say TimeoutException, CommunicationException and non typed WCF faults should include calls to the client proxy method Abort.

This is due differences in the communication state of the client proxy in each situation. If the client state is faulted then abort should be called. If the client state is opened then Close should be called.

The bug in the adapter is due to the fact that the BizTalk WCF-custom adapter doesn’t call Close on the client proxy in the case of a typed WCF fault leading the service hang in the situation described above.

 Best regards

 Michael Brandt Lassen

Variable Types i BizTalk TransportTypeData CustomProps

Jeg har netop haft held med at konfigurere BizTalk 2009 til at kommunikere med en WCF-service over ws2007FederationHttpBinding (mere herom i en senere post).

Undervejs fald jeg over en lille ting som undrede mig:

Det viser sig, at bl.a. WCF adapterens (men fx også File adapterens) konfiguration af properties i noden TransportTypeData\CustomProps skal have tilføjet såkaldte Variable Types attributter. Fx kunne jeg ikke sætte egenskaben BindingConfiguration før end jeg tilføjede attributten vt="8" .

Tal-værdierne for disse Variable Type attributes svarer til værdierne for .NET Frameworkets VarEnum enumeration. Se http://msdn.microsoft.com/en-us/library/aa560756.aspx for en liste af relevante typer og deres værdier.

Heraf kan vi se, at vt="8" svarende til en BSTR string, mens fx vt="11" svarer til en boolean.

Her et udsnit fra min bindings fil:

Keyset does not exist - fejl ved WCF signering

For klientcertifikater til signering, er det nødvendigt, at den konto som kører processen har adgang til certifikatets privatnøgle, ellers vil man få en ”keyset does not exist”-fejl.

Hvis processens konto ikke er den samme, som installerede certifikatet, skal der gives rettighed til certifikatets privatnøgle.

Dette kan ske vha. MMC certificates snap-in på Windows Server 2008 (højreklik på det aktuelle certifikat og vælg all tasks --> Manage Private Keys):

Eller fra commandline vha toolet winhttpcertcfg.exe. Toolet kan downloades her:

http://www.microsoft.com/downloads/details.aspx?familyid=c42e27ac-3409-40e9-8667-c748e422833f&displaylang=en

Efter installation ligger toolet typisk her:

C:\Program Files (x86)\Windows Resource Kits\Tools

Husk at køre toolet som administrator.

Du kan med winhttpcertcfg.exe fx se hvilke konti der har adgang til certifikatets privatnøgle således:

winhttpcertcfg -l -c [certifikat store] -s [del af subject name]

Certifikat store er typisk LOCAL_MACHINE\My

Den der har installeret certifikatet kan som administrator give andre adgang til privatnøglen således:

winhttpcertcfg.exe -g -c [certifikat store] -s [del af subject name] -a [account]