Public Smart Routing

BusinessConnect Container Edition 1.2.0 introduces the concept of public smart routing through which specific engines can be instructed to process messages that satisfy user-defined criteria. With this feature, you can use load balancing through the available IS engine to control inbound and outbound traffic at a high level.

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 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 is only supported for limited protocols, such as EZComm and EDI.
Note: For the HTTP/S, the Public Smart Routing component intercepts each incoming message and implements rule based logic in routing them to the internal clusters.
  • FTP Server is protocol specific and does not support inbound document smart routing.
  • SSH Server is protocol specific and does not support inbound document smart routing.

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. The Smart Routing component intercepts each inbound message and evaluates the corresponding list of attributes based on the transport type.
  2. Based on the set of rules configured for each available cluster, the Smart Routing component derives a destination cluster and publishes an inter-component message that notifies the selected cluster.
    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.

Public Smart Routing for Inbound and Outbound Documents

There are two types of public smart routing:

  • Inbound

  • Outbound

For inbound, the user can define public smart routing rules on the UI to categorize inbound traffic based on the type of transport and other attributes like message, size, and so on. Each inbound rule defines a cluster of IS engines that load balances the traffic matching that rule.

Inbound messages that do not match any defined rule are processed by a special NO_MATCHING_RULE cluster. One inbound cluster can have multiple IS engine instances and one IS engine instance can be part of many inbound clusters. This is defined by a separate UI page, for instance, mappings where you can also control if the IS engine handles inbound traffic, outbound traffic, or both.

Since rules are currently not supported for outbound traffic, all IS engines enabled for outbound are part of a single implicit cluster and load balance all outbound traffic.

If more IS engine instances are started than what is defined in the mapping UI, they are defaulted to perform both inbound and outbound. For inbound, they belong to the NO_MATCHING_RULE cluster. This is also the default smart routing configuration for all IS engines in the absence of this feature, which is, when rules and mappings are not defined on the UI.

Once the rules are defined, the GS engine routes messages comply with those rules to the corresponding cluster queue and hence, it is required to have IS engines explicitly mapped to those clusters in order to have enough IS engine instances run to satisfy all defined mappings. Similarly, it is also required to have at least one engine assigned for both inbound and outbound and also in the case of inbound at least one engine that is part of the NO_MATCHING_RULE cluster.

This is required to ensure that all traffic gets processed in the presence of smart routing rules and mappings. Similarly, if a cluster rule is deleted or disabled, it should be explicitly removed from any assigned instance mapping as traffic is not routed to this cluster. Also, any change in the public smart routing configuration requires a restart of the GS and IS engines.

Important: For this release, the smart routing is not supported for the SFTP, FTP/S, FILE, and EMAIL transports.

Example

The following example illustrates the above concepts,

Consider HTTP_All, a public smart routing rule that has been defined that categorizes all traffic belonging to the HTTP transport type. The following mappings have been defined for the IS engine runtime instances.

Serial no Inbound Enabled Inbound Rules Outbound Enabled

  1. True HTTP_All False

  2. True NO_MATCHING_RULES True

Assume that the user starts 3 IS engine instances. The first IS engine, denoted as IS Engine - 1, grabs the configuration defined for serial no 1 and based on that, listens only for the inbound HTTP traffic. The second IS engine, denoted as IS Engine - 2, grabs the configuration defined for serial no 2 and handles all inbound traffic that does not match any defined rule(s). In this case, it is all non-HTTP traffic. Any subsequent IS engine instances, for example, IS Engine - 3, would follow the default settings to the standard configuration of handling inbound traffic for the NO_MATCHING_RULES cluster as well as outbound traffic. Effectively, all NO_MATCHING_RULES traffic is load balanced between IS Engine 2 and IS Engine 3. Since instance 2 was also enabled for outbound, all outbound traffic is load balanced between IS Engines 2 and 3. The cluster assignments for IS engines in this case are as follows:

Inbound
HTTP_All (1)
NO_MATCHING_RULES(2,3)
Outbound
Implicit(2,3)