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.
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.
NOTE
To invoke the ResolveItinerary policy shown in the Figure 8,
you would need to use the ESB Itinerary Selector component in one of
your on-ramps, and you would provide its ResolverConnectionString
parameter with the following: BRI:\\policy=ResolveItinerary;version=1.0;useMsg=false;.
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.
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.
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.
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.
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.
