Copyright © Cloud Software Group, Inc. All Rights Reserved

Transaction Pipeline processing

TIBCO API Exchange Gateway uses a staged event-driven architecture. TIBCO API Exchange Gateway supports the processing of the transactions into a set of stages for high performance.

The transaction pipeline processing consists of the following:

•	Request pipeline processing

•	Response pipeline processing

Request Pipeline Processing

The request processing cycle indicates the normal life cycle of the incoming request message and consists of the following phases. This life cycle assumes that there are no errors in any of the processing stages.

1.	Transport Level Authentication

When the RV module of TIBCO API Exchange Gateway is used with Apache server for a partner to send a request using the HTTP transport, the first level of authentication is performed at the Apache server depending on the first part of URI. The authentication type is configured in the Apache server configuration file as asg_mod.conf. See Configure Apache Server for Basic HTTP Authentication for details.

The following types of authentication are supported:

−	No Authentication - This indicates that the request does not have any user credentials. In this case, the request is processed as an anonymous user.

−	Basic Authentication - This indicates that the request has the user credentials. In this case, the user is authenticated.

−	Digest Authentication

−	Mutual (SSL) Authentication.

For example, No Authentication is defined as follows:

   <Location / >

   SetHandler asg_rv_inbound_handler

   AsgSubject _LOCAL.asg.north.request

   AsgTimeout 30

   </Location>

After the request is processed by Apache server for authentication, the request is passed to the Core Engine over Rendezvous transport.

• When the Apache server is used as reverse proxy in front of the native HTTP channel of the TIBCO API Exchange Gateway, the same types of authentication can be configured at the Apache Server using the Apache directives. See Configure Apache HTTP Server as Reverse Proxy. • When the native HTTP Channel is used, the HTTP channel can be configured to provide basic authentication and SSL(mutual) authentication. See Enable Facade HTTPS Transport for the SSL authentication configuration details.

2.	Operation Identification

When TIBCO API Exchange Gateway receives a request , the gateway identifies the operation based on URI and headers of the request. See Operation Identification for details.

3.	Partner Identification

After the operation is identified, the partner is identified from the request context message. See Partner Identification for details.

4.	Request Parsing (Optional)

After the operation and partner are identified from the incoming request, the next step is to parse the request. The parse step is an optional preprocessing of the facade request. See Parsing Step for details on the parsing step of request processing.

5.	Authorization

The Core Engine checks if the identified partner is authorized to access the requested operation. The partner and the associated operation is configured in the Facade Access under PARTNER tab of the Config UI.

6.	Request Message Validation

If the flag for request validation is enabled, the request message is validated for syntax against XSD for the incoming northbound request message.

7.	Facade Throttling

You can enforce the commercial throttles for service level agreements for a partner request using the facade throttling. Facade Throttling is applied on the partner, partner group, and partner operations.

After the request reaches this stage in the processing pipeline, how often this partner can invoke the operation is checked.

8.	Forward Northbound Mapping

After the request passes the facade throttle check, the request is processed by the northbound mapper for any transformations required from the operation request message to the canonical request message. Whether the mapping is required for this request operation or not, it is configured using the Request Transform field on the ROUTING > Facade Operations tab. The transformation details are defined in the MAPPING > Mappings tab of the Config UI.

By default, if no mappings are defined, the request message is just copied as the output request message at this stage.

9.

Routing

Based on the operation name and routing key defined in the ROUTING > Routing tab of the Config UI, the Core Engine determines the target operation endpoint for the incoming request. See Routing for details.

10.	Service Throttling

After the name of the southbound service endpoint is derived for the invoked operation, the service throttling policy is applied. Service throttles are technical throttles implemented to protect the overuse of the service endpoints.

11.	Forward Southbound Mapping

If the service throttle is not violated, the request message is processed by the southbound mapper for any transformations required from the canonical request message to the service request message. Whether the mapping is required for this request operation or not, it is configured using the Request Transform field on the ROUTING > Target Operations tab. The transformation details are defined in MAPPING > Mappings tab of the Config UI.

By default, if no mappings are defined, the request message is just copied as the output request message at this stage.

12.	Invoke Southbound Service

This is the final stage where the Core Engine invokes the southbound service for the requested operation.

Response Pipeline Processing

The response processing cycle indicates the life cycle of the response message and consists of the following phases:

1.	Reverse Southbound Mapping

After the response is received from the southbound service, the response document is processed for any transformations required from the service response message to the canonical response message. Whether the mapping is required for this request operation or not, it is configured using the Response Transform Mapping field on the ROUTING > Target Operations tab. The transformation details are defined in the Mappings tab of the Config UI.

By default, if no mappings are defined, then the response message is just copied as the output response message at this stage.

2.	Reverse Northbound Mapping

Using the reverse northbound mapping, you can transform the canonical response message to the northbound response message. Whether the mapping is required for this request operation or not, it is configured using the Reverse Mapping field on the Operations tab. The transformation details are defined in the Mappings tab of the Config UI.

This mapping can be used for the censor response policy. Using the censor response policy, you can hide certain fields from the response message so that they are not exposed to the requestor.

3.	Termination

The response message is finally sent back to the original requestor in this stage.

Generate Transaction

After the request and response messages are processed, the Core Engine generates the events to audit log the transaction details. The Central Logger component receives the events and logs the transaction details in a database.

Copyright © Cloud Software Group, Inc. All Rights Reserved