Book Offer: Microsoft BizTalk Server 2004 unleashe…

The book (by Scott Woodgate, Stephen Mohr, Brian Loesgen ISBN 0-672-32598-5) seems to be getting into it’s final stage. There was a page advertisement in the MSDN magazine of November 2004 (Vol 19 NO 11 Page 108) offering a 30% discount for ordering the book from SamsPublishing.com (plus free shipping).

On Sams website I could not find any link or discount coupon. I opened an issue with Customer Service and they are contacting the Sams Marketing to inquire how we can get the 30% discount.

Update (18 Oct 2004):

I received an email from the Sams Marketing with the following information: In order to get the 30% discount you have to use the coupon code BIZTALK (note it must be all caps!). You enter the coupon code on the ‘Payment Method’ page in the order process. A review of the discount will be shown on the ‘Place Order’ page. The offer is valid till the Dec 15.

In a couple of days Sams website will provide a direct link.

Windows XP SP2 – BizTalk 2004

The Service Pack 2 release for Microsoft XP has a lot of improvements on security settings. As a side-effect the regular install of the BizTalk 2004 Developers edition will fail at the Single Sign-On service.

It is all well documented by Microsoft, and easy to google if you know that the SP2 is responsible for the install failure, but just in case you did not make the link, read the article

The install failure is:

An unexpected error occurred while configuring the Single Sign-On server.

The service cannot be started, either because it is disabled or because it has no enabled devices associated with it.

Microsoft support article 841893 explains in detail how to resolve the issue by:

  • Using Gpedit.msc to enforce the authentication of client calls
  • or

  • Using Registry Editor to enforce the authentication of client calls

Watch your type

A simple rule:

Conditions:

Case:/Root/Income/BasicSalary
is less than or equal to
75.000
Actions:
Case:/Root/IncomeStatus = approved

Would a basic salary of only 800 be approved? Or rephrasing: would the rule fire?

I expected it would. But the answer is “It depends”. It depeneds on the type of BasicSalary! If the BasicSalary is of type System.String it will not!

CONDITION EVALUATION TEST (MATCH) 6/28/2004 12:29:10 PM

Rule Engine Instance Identifier: 29fea928-...
Ruleset Name: Simple
Test Expression: TypedXmlDocument: Case:/Root/Income.BasicSalary <= 75.000
Left Operand Value: 800
Right Operand Value: 75.000
Test Result: False

It seems that the rule engine allows string comparison. And in case of string comparison “800” would be larger than “75.000”! So watch your types! An interesting item to explain to the rule writer!

What about converting the BasicSalary to an Int32?

I tried to add a .NET class in the Business Rules Composer. Selected the mscorlib to add as an assembly and changed the condition to:

Conditions:

Int32.Parse(Case:/Root/Income/BasicSalary)
is less than or equal to 75.000
Actions:
Case:/Root/IncomeStatus = approved

Don’t know how to handle exceptions here, but let’s see what happens:

I reloaded the policy, and mysteriously the 75.000 value was changed to 75! But hey, they also changed the type from System.String to System.Double. Close, but no cigar.

Should I put in 75,000? No: that got interpreted as an error where a string can not be compared with an Int32. And the policy could not be saved.

Let’s continue and remove any thousand separator:

Conditions:

Int32.Parse(Case:/Root/Income/BasicSalary)
is less than or equal to 75000
Actions:
Case:/Root/IncomeStatus = approved

Reloading the policy and we notice that the 75000 literal has type System.Int32. So we got the right type in place now.

Enterering the next stage: Testing if the rule actual fires. We can not define an instance of System.Int32 because of a missing interface. We need a fact creator. Although the Int32.Parse function is just a static method, we still have to assert the fact in the rule engine. Testing without the fact creation results in no rule-firing.

Hang in there, we are getting close. We only have to create a helper class that implements the Microsoft.RuleEngine.IFactCreator (located in the Microsoft.RuleEngine.dll)


namespace MarcoSoft.Utils
{
///
/// Summary description for Converter
///

public class Converter: Microsoft.RuleEngine.IFactCreator {
public Converter() {
}

public int stringToInt32(string value){
return Int32.Parse(value);
}

#region IFactCreator Members
public object[] CreateFacts(RuleSetInfo ruleSetInfo) {
return new object[]{new Converter()};
}

public Type[] GetFactTypes(RuleSetInfo ruleSetInfo) {
Type converterType = this.GetType();
return new Type[]{converterType};
}
#endregion
}
}

This code has to be compiled with a strong name, and be placed in the Global Assembly Cache. On the Facts Explorer view of the MS Business Rule Composer we can add the created .NET assembly.

We update the condition with:

Conditions:

Converter.stringToInt32(Case:/Root/Income/BasicSalary)
is less than or equal to 75000
...

And in the Test Dialog we add a Fact.Creator of the MarcoSoft.Utils.Converter

Running the code, and voila:


CONDITION EVALUATION TEST (MATCH) 6/28/2004 5:22:18 PM
Rule Engine Instance Identifier: 52c89cd5-...
Ruleset Name: Simple
Test Expression: MarcoSoft.Utils.Converter.stringToInt32 <= 75000
Left Operand Value: 800
Right Operand Value: 75000
Test Result: True

The result what I was expecting all along.

WSE 2.0 configuration challenge

Security is important, especially when we have a B2B scenario where sensitive information has to be sent. Not too long ago, Microsoft released the Web Service Enhancement 2.0 package(WSE 2.0). Among other features like sending attachments with SOAP messages, it enables us to sent secure SOAP messages.

The amount of code to achieve this is not too much as shown with the shipped examples, but it’s the configuration of the client and server machine what is the challenge. There is good documentation what will get you a long way. But I ran into a little issue on “How to: Make X.509 Certificates Accessible to WSE”

Give the account under which WSE is running read access to the file containing the private key associated with the X.509 certificate.

  1. Open the WSE X.509 Certificate Tool (WseCertificate2.exe)
  2. Set the certificate location and store name where the certificate is located.
  3. Click Select the certificate from the store, choose the certificate you

    want to set the permissions for, and then click OK.
  4. Click Open Private Key File Properties, click the Security tab, add the ASPNET or Network Service account, depending on which version of IIS the Web service is running under, and then select the Read option.


The missing documentation is that if the Security tab is not showing you have to make sure the following:
  1. You need the NTFS file format.
  2. Open the explorer and go to ->Folder Options, click on the View Tab, and deselect “Use simple file sharing [recommended]”



Step d. should now show the Security tab, and the Read access to the security file can

be set for the IE account (ASPNET or Network Service for IE 6.0)

XML rule engine – QuickRules

Another Java based XML rule engine – QuickRules, I was not aware of. They also have a DecisionTable editor. The .NET integration goes through COM, so that is just a marketing line. There is also some workflow editing provided. But not on the level as the BizTalk 2004 orchestration. Anyway have a closer look at this product if Java (J2EE) is your target application server.

Idiom’s: Decisions and Formulas

So who was first Idiom or Microsoft? They both use the concept of defining the datamodel by XSD schema’s and use drag-and-drop to place these elements in rule constructs. The advantage of Idiom here is that you seem to be able to show multiple rules at once. This is really missing in the Business Rule Capturing environment of MS Biztalk 2004. They also seem to be able to integrate with BPEL so that must be pretty close to Biztalk rules format. Have a look at their Decisions and Formulas demo.

What still surpise me is that also Idiom expects the Rule writer to define XSD schema’s. Why can’t we leave the technical binding to XSD, Databse, Java beans or C# components out of the Rule Definitions? Writing good business rules is already complicated enough!