Context Document

The contents of the context document are described by the following XSD:

<?xml version="1.0" encoding="UTF-8"?>

If the incoming request is received from Apache HTTP server, the context document contains an entry with key set to asg:httpRequest, which conforms to

Mapping Schemas

|

</xs:simpleContent>

</xs:complexType>

</xs:element>

<xs:element name="body" type="xs:string" minOccurs="0"/>

</xs:sequence>

</xs:complexType>

</xs:element>

</xs:schema>

Routing

|

Routing

TIBCO ActiveMatrix Service Gateway provides the routing capabilities to determine the reference endpoint for an operation request. Routing allows you to map a single northbound request document to multiple southbound service interfaces.

The router component of the TIBCO ActiveMatrix Service Gateway receives the request as events and uses the rules engine to determine where requests are handled.

The Router typically works with the canonical version of the request and response documents.

The routing rules are driven by the routing policies, which operate on parameters like:

— Operation [Service Type]: Routing is done based on the requested service, such as a SOAP Action or URL string.

— Requestor [Client]: Routing is done based on the name, type or class of the requesting-application.

— Version: Routing is done based on the version of service APIs. TIBCO ActiveMatrix Service Gateway supports multiple concurrent versions of a service or a service implementation.

— Time-of-Day: Routing is done to different services (explicitly or through orchestrations) depending on time-of-day

— Authenticated Identity: Routing is done to different services based on the Identity of individual partners and consumers. (also supports attribute filtering of responses)

— Message content

— Message and Transport context

— Cross-References with external systems

Configuration

The router component routes the operation request to the service handler based on the configuration settings done on the Routing tab of the configuration GUI.

The Routing tab allows you to configure the Operation name, Service name and Routing key.

For an Operation configuration, if the Processing Body XLST is defined, then the incoming request is parsed as per the defined XSLT and the routing key is returned. The routing key is the key factor to determine the service handler for an operation. The routing key is extracted from the parsing of the request content as well as context done in the parsing step of the request processing pipeline.

Routing key is defined in the Routing tab of the GUI. It can have following values:

— default: If no XSLT files are defined for the operation, the routing key is default.

— undefined: If no value is returned from the XPath mapper, the routing key is undefined.

— routingKey: routingKey is the value returned from the parsing of the request document as per defined XSLT files.

Routing tab

The Routing tab of the configuration allows you to configure the settings required for routing. SeeRouting, page 35for details.

Schema document

In the request processing pipeline, the input document to the XSLT for parsing the northbound request is defined by the following schema:

<?xml version="1.0" encoding="UTF-8"?>

Routing

|

The following elements are available as input for the transformations and can be used to generate the routing key:

— Northbound request content (as defined by nbRequest element)

— Northbound request context (as defined by context element)

XLST Transformation for Routing

Following example section illustrates how you can use variables for request content and context as an input to the transformations.

Input:

nbRequestHrefis a reference to the nbRequest element which indicates the body of the northbound request. Below is an example of nbRequest:

the is an example of the XLST transformation used to extract routing key:

<xsl:variable name="nbRequestHref">

If you intend to use request context, it can be done as below:

<xsl:variable name="contextHref">

<xsl:value-of select="/transformation/context/@href"/>

The output in a transformation is a predefined interface expected from the transformation output. The fields from the output are available to set the values and populate it for routingKey generation using XPath.

<output>

Routing

|

<xsl:when test="$opCoId != ''"><xsl:value-of select="$opCoId"/></xsl:when>

<xsl:otherwise>undefined</xsl:otherwise>

</xsl:choose>

</routingKey>

<address><xsl:value-of select="$address"/></address>

</output>

Once the routing key is populated, it searches for the right operation defined for this routing key and determines the southbound service endpoint where this operation request is handled. If no routing key is defined in the transformation, it uses the configuration with default routing key.

Overriding Routing Key

In a typical request processing pipeline, routing key is derived based on the northbound request content and context.

TIBCO ActiveMatrix Service Gateway has the capability to overwrite the routing key at the southbound request transformation stage. This functionality is

supported using the Enumeration Orchestration. The routingKey is defined in the transformation document (XLST) using the

<asg_map:routingKey>getbookbyAuthor_AAA.HTTP</asg_map:routingKey>

element within the <asg_map:repeat> tag.

|