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.

Processing Order

  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>

    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.
    Note:
    • 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 and Partner API key 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 or not the mapping is required for this request operation, it is configured using the Request Transform field on the ROUTING > Facade Operations tab or PARTNER > Facade Access tab.
    Note: If a request transform is configured at both places (Facade Operations and Facade Access), only the Facade Access transform is executed.
    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 Transaction Pipeline processing 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.