Copyright © TIBCO Software Inc. All Rights Reserved
Copyright © TIBCO Software Inc. All Rights Reserved


Chapter 7 Smart Routing : Public Smart Routing

Public Smart Routing
TIBCO BusinessConnect allows you to define simple business rules to route inbound public messages coming from your trading partners to be processed by multiple clusters of load balanced engines.
By defining the proper rules, you can strategically configure multiple clusters to prioritize and distribute workloads among a group of runtime engines so that you can optimize your hardware resources and maximize throughput. Here are a few examples:
Public Smart Routing utilizes a rule based engine that evaluates based on a set of fixed and known attributes that are available for each transport type. These attributes are checked against an inbound public message and the cluster that fits the best is designated for processing.
Inbound public transports that are supported for Public Smart Routing are as follows:
The following sections discuss the concepts in details and describe the components that facilitate the functionality of Public Smart Routing:
Distributing Workload Among Engines
In a single cluster deployment, a machine called Scheduler is selected and is responsible for dispatching each incoming document to a Worker engine for processing. Each Worker engine is configured identically to process documents in the same way, which results into a variety of documents being assigned to the Worker engine in a single queue. Under high load scenarios, workloads could become a backlog and processing of documents pending in the queue can be delayed.
A rule-based mechanism alleviates the likelihood of bottlenecks in cases such as:
Processing of Inbound Documents
In TIBCO BusinessConnect, the inbound documents from trading partners are received through inbound public transports that reside either in the Gateway engines, or on one of the interior runtime engines in the cluster behind the firewall.
Gateway Engines
Gateway engines host many services, which are also called public transports:
HTTP/S   HTTP/S is supported for almost all protocols. Many message packaging and delivery standards such as AS2, S/MIME, and SOAP are also based on HTTP/S and are supported.
Inbound File Poller   This transport is only supported for limited protocols, such as EZComm and EDI.
FTP Server   This transport is protocol specific and does not support inbound document smart routing.
PartnerExpress   This transport is protocol specific and does not support inbound document smart routing.
TCM Server   This transport is protocol specific and does not support inbound document smart routing.
SSH Server   This transport is protocol specific and does not support inbound document smart routing.
Interior Runtime Engines
The Interior runtime engines host the following:
The inbound Email and FTP-Get pollers transports are running behind the firewall and are responsible for receiving public messages on the POP and FTP servers. For these transports, the Public Smart Routing component intercepts each incoming Email and File message implements rule based logic in routing them to the internal clusters.
Rule Based Message Processing
Each transport type contains a set of fixed and known attributes available through the MIME headers, such as content type, content size, subject, URI, and so on. These attributes serve as the criteria to define rules and determine a designated unit for processing.
Here is how the messages are processed:
1.
2.
If no rules are defined, the Smart Routing component is disabled by default and the one and only one cluster always receives notification for each public inbound message.
The inter-component message essentially triggers the processing of the inbound message by the corresponding selected cluster.
Routing Messages to the Designated Clusters
The public event sources are responsible for routing the messages to the designated cluster using a message queue.
A Scheduler machine within the cluster of runtime engines that participate in the message queue dispatches the message to a Worker engine for processing. The consumer of the message queue receives a notification messages from the public transport receivers and starts processing the messages from the queue.
Each runtime engine can be configured to process messages from more than one message queue, and can be load-balanced with more than one group of runtime engines.
Figure 18 shows three message queues processed by three clusters that consist of six runtime engines, where three of these engines are simultaneously participating in two clusters.
Figure 18 Message Queues and Clusters
Defining Rules for Public Smart Routing
The Smart Routing component is responsible for placing the inbound public messages to the appropriate queue for processing. It evaluates an incoming message against a set of rules in a predefined order of precedence. Each rule is bound to a single cluster and a cluster can be bound to multiple rules.
A destination cluster is selected when the first rule satisfies the conditions set forth in each rule. The Smart Routing rule is defined as a set of available email criteria based on the transport type, such as the following:
Email size is less than 1MB (Content_Size less than 1.000.0 bytes)
The sender address is john@acme.com (Sender = john@acme.com)
Depending on the configurations, a rule is satisfied when all or any of the criteria are met.
For the multiple clusters of runtime engines, the following definitions apply:
Attributes, Operators, and Operands
The rules for defining clusters consist of the following elements:
Attributes    These are objects of a given type that extends the operand implementation by adding a name, default value, and transport property.
Operators   These objects determine the relationship between two (or more) operands.
Operators follow this rule:
numeric operands support the following operators: =, greater_than (>), less_than (<), and range
Operands   These are objects that are a string, numeric, or Boolean.
For TIBCO BusinessConnect Public Smart Routing, a condition can have one attribute, operator, and one or more operands (in that order.
After you have defined all conditions, a rule for the routing mechanism is put together and displayed.
The routing mechanism based on the rules you have defined using the configurable conditions is now displayed in the field Rule Expressions, such as the following:
((Content_Size greater than 1000.0) and (Secure_SSL is false))
In this case, Smart Routing will occur when the file size is larger than 1KB and client authentication is not required.
Creating Smart Routing Rules
In many cases, you can create rules for different variations of the same protocol by using generic routing attributes. To rout messages received using a certain protocol, you can create the following rules:
You can also use predefined (preconfigured) properties in expressions.
Server Groups and Clusters
You will assign servers to fault tolerant groups using the procedure described in TIBCO BusinessConnect Interior Server Administration, Enable Service.
These fault tolerant groups of servers are later assigned to a cluster, or have rules configured which define the way they will be used in the system. Assigning (or adding) a group to a cluster does not mean that you are actually moving a group from one cluster to another: clusters can overlap and groups can share loads.
Assigning Groups to Clusters
An example of server groups assignments to multiple clusters is shown in Figure 19.
Figure 19 Server Group Assignment
In this example, the server groups Group A and Group B are assigned as follows:
When the described cluster rules are implemented, email messages will be routed as follows:
Assignment Order
Inbound messages will be delivered to the cluster that is defined by the first matching rule. In the example in Figure 19, there are the following defined rules for the existing clusters:
Cluster AS1 Email: Sender = "john@acme.com"
Cluster HHTP: Content_Size less_than 1000.0 bytes; Secure_SSL is false
If an inbound message comes in that corresponds to the rules
Sender = "john@acme.com"
and
Content_Size less_than 1000.0 bytes,
the following will happen:
If the rule Sender = "john@acme.com" comes first and is true, the message will be assigned to the cluster AS1 Email.
If the rule Content_Size less_than 1000.0 bytes comes first and is true, then the cluster HTTP will be used.
Any message may be evaluated as true for more than one rule and, therefore, the first matching rule will decide the group assignment.
NO MATCHING RULES
One group can belong to multiple clusters, including the cluster called NO MATCHING RULES (the cluster with no rules defined). When an inbound document is received that does not match any of the defined rules, it is sent to this cluster. By default, all service instances are added to this cluster and later can be assigned to another cluster. After you assign a fault tolerant group to a specific cluster, it is still listed under the cluster NO MATCHING RULES, where it can be added or removed at any time.
If there are no groups assigned to this cluster, all non-corresponding messages will be discarded.

Copyright © TIBCO Software Inc. All Rights Reserved
Copyright © TIBCO Software Inc. All Rights Reserved