BizTalk 2009 : The Enterprise Service Bus Toolkit 2.0 - The Functional Components (part 4) - Business Rule Engine

10. Business Rule Engine

Once you begin using the ESB Toolkit, the Business Rule Engine takes on significantly more importance than in the past. If you want to perform any kind of "intelligent" resolution of endpoints, maps, or itineraries, you are going to need to use the BRE.

You can think of all the other resolvers as simple "lookup" resolvers. You give them some parameters or keys, and they use this to retrieve corresponding data. They always look up the same data, however. They are not able to make any type of decision for you about what data is needed. You have to make this decision ahead of time and define it in the resolver connection string within your itinerary. This works fine if you know exactly what service you need to route a message to. However, if you need to make a decision at runtime about which service you need, then you need to use the rules engine. An experienced BizTalk developer will know how to perform context-based routing and content-based routing. However, the ESB Toolkit introduces significant changes, and you are going to need to understand how to leverage the Business Rule Engine.

To make it quicker and easier to work with ESB messages in the BRE, the ESB Toolkit includes several new vocabularies that you can use to access ESB-specific information about a message as well as to set ESB-specific properties. In the following section, we will show you how to use these to perform some common tasks.

10.1. Resolving an Itinerary Dynamically

One thing that most developers will need to know how to do is to dynamically resolve an itinerary using the Business Rule Engine Itinerary (BRI) resolver. The BRI resolver allows you to pass an incoming message and its context properties into a BRE policy. It then expects that the policy will provide it with the name and version number of the itinerary that needs to be assigned to the message. A developer will need to know how to create the rules that can provide this.

You will need to use the new ESB.Itinerary vocabulary, which allows you to set the name and version of the itinerary that you want to use. This vocabulary provides two core functions called Set Itinerary Name and Set Itinerary Version. You use these functions in the Actions section of a rule to define which itinerary you want to use. Figure 8 shows these functions in use.

Figure 8. A rule resolving an itinerary that the ESB Itinerary Selector pipeline component will load

In the previous figure, you can see a rule that has been set up to assign itinerary NewOrderItinerary to a message. In the Conditions section of this rule, you can see that this itinerary will be assigned to a message only if it has a message type of Order. The Context Message Type argument comes from the ESB.ContextInfo vocabulary, which ships with the ESB Toolkit. You can use this vocabulary to access a number of read-only properties associated with the incoming message. Figure 9 shows which properties can be accessed.

The rule shown in Figure 8 is a very basic rule, and you can obviously create much more complex conditions that do more than just check the message's type. However, the basic pattern for resolving an itinerary will always be similar to this. You specify a rule condition (likely using definitions from the ESB.ContextInfo vocabulary or by checking data in the message itself), and then you specify the itinerary name and version that you want to load from the Itinerary Database.

Figure 9. All of the context properties that you can access from the ESB.ContextInfo vocabulary

10.2. Resolving a Map Name Dynamically

Another common task that developers will have to do is to use the rules engine to tell the ESB Transformation Service which map it should run. For this task, you will need to usethe ESB.TransformInfo vocabulary. This vocabulary has a function called Set Transform Transform Type where you can set the name of the map that you want to execute. Figure 10 shows how you can create a rule that looks at the values of two context properties and then assigns a specific map to run if that rule is two.

Figure 10. A rule that tells the Transformation Service which map to execute

In the previous image, the full name of the map is not shown because of its length. The full value that was used is as follows:

GlobalBank.ESB.DynamicResolution.Transforms.
SubmitPurchaseOrderResponseCN_To_SubmitOrder
ResponseNA, GlobalBank.ESB.DynamicResolution.Transforms, Version=2.0.0.0,
Culture=neutral,PublicKeyToken=c2c8b2b87f54180a

This is a fully qualified name for a BizTalk map, and this is what you have to provide the Set Transform Transform Type function.

10.3. Resolving a Service Endpoint Dynamically

The Business Rule Engine can also be used to dynamically resolve the endpoint where a message needs to be routed to. To do this, you will need to use the ESB.EndPointInfo vocabulary. The ESB.EndPointInfo vocabulary gives you the ability to read and write all of the properties that the ESB requires in order to route a message. Figure 11 shows the ESB.EndPointInfo vocabulary.

Figure 11. All of the read/write functions exposed by the ESB.EndPointInfo vocabulary

Depending on what type of endpoint you want to route your message to (that is, FTP, SOAP, WCF, File, and so on), you will need to assign values to different context properties. Figure 12 shows how you can create a rule to route a message to a basic SOAP-based web service. You can see that four properties need to be set in order for the ESB to route the message. The Set End Point Outbound Transport Location is used to tell the ESB what the web service's URL is. The Set End Point Outbound Transport Type tells the ESB which adapter provider to use. The Set End Point Target Namespace is where you tell the ESB what namespace the remote web service uses. Finally, the Set End WCF Action is where you can put in which method you need to invoke in the service.

Figure 12. The structure for a rule if you want to route a message to a remote web service

One last vocabulary that you need to be familiar with is ESB.TransportTypes. In Figure 12 you can see that the Transport Type is set to WCF-BasicHttp. The value assigned to the Transport Type must match up with one of the adapter providers that are included in the ESB Toolkit. To make it easier for to assign this valid properly, the ESB.TransportTypes contains a list of all the valid adapter providers. To use this list, expand the ESB.Transport Types vocabulary, and you will see a vocabulary definition called Adapter Providers. You can drag this Adapter Providers definition and drop it into the argument field for the Set End Point Outbound Transport Type function. Once you do this, you can click the argument, and a drop-down list will appear showing all the default adapter providers. Figure 13 shows what this looks like.

Figure 13. The Adapter Providers list