Content-based Routing
If you have a native API that is hosted at two or more endpoints, you can use the content-based routing protocol to route specific types of messages to specific endpoints. You can route messages to different endpoints based on specific values that appear in the request message. You might use this capability, for example, to determine which operation the consuming application has requested, and route requests for complex operations to an endpoint on a fast machine. For example, if your entry protocol is HTTP or HTTPS, you can select the Content-based routing. The requests are routed according to the content-based routing rules you create. You may specify how to authenticate requests.
Property | Description |
---|---|
Default Route To: Specifies the URLs of two or more native services in a pool to which the requests are routed. | |
Endpoint URI | Specifies the URI of the native API
endpoint to route the request to in case all routing rules evaluate to False.
Service registries that have been added to the webMethods API Gateway instance are also
included in the list.
If you choose a service registry, webMethods API Gateway sends a request to the service registry to discover the IP address and port at which the native service is running. webMethods API Gateway replaces the service registry alias in the Endpoint URI with the IP address and port returned by the service registry. For example, if your service is hosted at the URL:
As this property supports variable framework, you can make
use of the available variables. For example, you can configure the endpoint URI
using hard coded URL, simple alias, endpoint alias, and variable syntax or any
of these combination. If you define the endpoint URI as
For details about the variables available in webMethods API Gateway, see Variables Available in API Gateway. Note: If you use endpoint alias, make sure the endpoint alias
is created before you define it in the policy. For example, if you define
${alias} syntax in the policy before creating the
alias as endpoint alias,
webMethods API Gateway
considers ${alias} as custom variable or simple alias and tries to resolve
against those. So in that case, after creating endpoint alias you have to edit
and save the API or policy to associate ${alias} syntax with the endpoint
alias.
|
HTTP Method | This is applicable for REST-based APIs. Specifies the available routing methods: GET, POST, PUT, DELETE, and CUSTOM (default). When CUSTOM is selected, the HTTP method in the incoming request is sent to the native service. When other methods are selected, the selected method is used in the request sent to the native service. Note: It is recommended to use Request Transformation > Method
Transformation to achieve this as other transformations can also
be done under the same policy.
|
SOAP Optimization Method | This is applicable for SOAP-based APIs.
Specifies the optimization methods that webMethods API Gateway can use to parse SOAP requests to the native API. Select one of the following options:
|
HTTP Connection Timeout (seconds) | Specifies the time interval (in seconds)
after which a connection attempt times out.
The precedence of the Connection Timeout configuration is as follows:
|
Read Timeout (seconds) | Specifies the time interval (in seconds)
after which a socket read attempt times out.
The precedence of the Read Timeout configuration is as follows:
|
Native Service Timeout (seconds) |
Specifies the time interval (in seconds) after which an HTTP connection attempt when calling the Integration Server HTTP backend service pub.client:http for REST APIs times out. The precedence of the Native Service Timeout configuration is as follows.
When a native service timeout is defined for an API, both the connection timeout and the read timeout values are set to the value of the native service timeout during the connection process to the native service. |
Pass WS-Security Headers | This is applicable for SOAP-based APIs.
Selecting this indicates that webMethods API Gateway should pass the WS-Security headers of the incoming requests to the native API. |
SSL Configuration. Configures keystore, key alias, and truststore for securing connections to native APIs. | |
Keystore Alias | Specifies the keystore alias configured
in
webMethods API Gateway.
This value (along with the value of Client Certificate Alias) is used for
performing SSL client authentication.
Lists all available keystores. If you have not configured any keystore, the list is empty. |
Key Alias | Specifies the alias for the private key, which must be stored in the keystore specified by the keystore alias. |
Truststore Alias | Specifies the alias for the truststore
that contains the list of CA certificates that webMethods API Gateway uses to validate the
trust relationship with the native API.
If you do not configure any truststore alias, it implies that webMethods API Gateway does not validate the certificates provided by native APIs. |
Service Registry Configuration | |
Service Discovery Endpoint Parameter | Values required for constructing the
discovery service URI.
For example: if the service registry configuration of the service registry that you have selected in Endpoint URI has Service discovery path set to /catalog/service/{serviceName} (and the {serviceName} alias is intended for passing the service name), you must enter {serviceName} as Parameter and the name of the service as Value. As the Value field supports variable framework, you can make use of the available variables as path parameters. For example, if you provide a parameter as
{serviceName}( in
Service discovery path while you
define a service registry) and the corresponding values for the path parameter
as
For details about the variables available in webMethods API Gateway, see Variables Available in API Gateway. |
Rule: Defines the routing decisions based on one of the following routing options. Click Add Rule and provide the following information. | |
Payload Identifier | Specifies using the payload identifier to identify the client,
extract the custom authentication credentials supplied in the request
represented using the payload identifier, and verify the client's identity.
In the Payload identifier section, click Add payload identifier, provide the following information, and click Add. Expression type.
Specifies the type of expression, which is used for identification. You can
select one the following expression type:
You can add multiple payload identifiers as required. Note: Only one payload identifier of each type is allowed. For example, you can
add a maximum of three payload identifiers, each being of a different type.
|
Route To. Specifies the Endpoint URI of native APIs in a pool to which the requests are routed. | |
Endpoint URI | Specifies the URI of the native API
endpoint to route the request to.
You can use service registries in a similar manner as described in the main Endpoint URI above. For example, if your service is hosted at the URL:
As this property supports variable framework, you can make
use of the available variables. For example, you can configure the endpoint URI
using hard coded URL, simple alias, endpoint alias, and variable syntax or any
of these combination. If you define the endpoint URI as
For details about the variables available in webMethods API Gateway, see Variables Available in API Gateway. Note: If you use endpoint alias, make sure the endpoint alias
is created before you define it in the policy. For example, if you define
${alias} syntax in the policy before creating the
alias as endpoint alias,
webMethods API Gateway
considers ${alias} as custom variable or simple alias and tries to resolve
against those. So in that case, after creating endpoint alias you have to edit
and save the API or policy to associate ${alias} syntax with the endpoint
alias.
|
HTTP Method | This is applicable for REST-based APIs.
Specifies the available routing methods: GET, POST, PUT, DELETE, and CUSTOM (default). When CUSTOM is selected, the HTTP method in the incoming request is sent to the native service. When other methods are selected, the selected method is used in the request sent to the native service. |
Soap Optimization Method | This is applicable for SOAP-based APIs.
Specifies the optimization methods that webMethods API Gateway can use to parse SOAP requests to the native API. Select one of the following options:
|
HTTP Connection Timeout (seconds) | Specifies the time interval (in seconds)
after which a connection attempt times out.
The precedence of the Connection Timeout configuration is as follows:
|
Read Timeout (seconds) | Specifies the time interval (in seconds)
after which a socket read attempt times out.
The precedence of the Read Timeout configuration is as follows:
|
Native Service Timeout (seconds) |
Specifies the time interval (in seconds) after which an HTTP connection attempt when calling the Integration Server HTTP backend service pub.client:http for REST APIs times out. pg.endpoint.nativeServiceTimeout is disabled by default. The default value is set to blank. You can also set the value to 0 to disable it. This is a global property that applies to the endpoints of all APIs. If you prefer to specify a native service timeout for the endpoints of an API individually, set the Native Service Timeout field in the API's's Routing Protocols processing step or configure it in the End point alias of that API. The precedence of the Native Service Timeout configuration is as follows.
When a native service timeout is defined for an API, both the connection timeout and the read timeout values are set to the value of the native service timeout during the connection process to the native service. |
Pass WS-Security Headers | This is applicable for SOAP-based APIs.
Selecting this indicates that webMethods API Gateway should pass the WS-Security headers of the incoming requests to the native API. |
SSL Configuration | Configures keystore, key alias, and
truststore for securing connections to native APIs.
Provide the following information:
|
Service Registry Configuration | |
Service Discovery Endpoint Parameter | Values required for constructing the
discovery service URI.
For example: if the service registry configuration of the service registry that you have selected in Endpoint URI has Service discovery path set to /catalog/service/{serviceName} (and the {serviceName} alias is intended for passing the service name), you must enter {serviceName} as Parameter and the name of the service as Value. As the Value field supports variable framework, you can make use of the available variables as path parameters. For example, if you provide a parameter as
{serviceName}( in
Service discovery path while you
define a service register) and the corresponding values for the path parameter
as
For details about the variables available in webMethods API Gateway, see Variables Available in API Gateway. |