Monday, June 28, 2004

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.

Thursday, June 24, 2004

Mike Taulty's WSE 2.0 Tracing Utility.

So you got all the certifications in place, and finally your secure SOAP service is receiving signed encrypted messages. Are you sure?

An essential tool to figure out what is happening (behind the SOAP scenes) when you use WSE 2.0: The WSE 2.0 Tracing Utility.

Friday, June 18, 2004

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)

Tuesday, June 15, 2004

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.


Wednesday, June 09, 2004

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!

Sunday, June 06, 2004

A Basic Introduction to Messaging with Microsoft BizTalk Server 2004

For a great introduction on Messaging in BizTalk 2004, read this article by Christof Claessens A Basic Introduction to Messaging with Microsoft BizTalk Server 2004. It is posted on MSDN Belgium - LuxemBourg.