CentraSite Documentation : Runtime Governance with CentraSite : Virtualized Services in CentraSite : Configuring SOAP-based Virtual Services : The Routing Protocols Step (SOAP) : “Content-based” Routing (SOAP)
“Content-based” Routing (SOAP)
 
Creating a Routing Rule for “Content-based” Routing (SOAP)
If your Entry Protocol is HTTP or HTTPS, you can choose to use the “Content-based” routing protocol. (Alternatively, you can choose “Straight Through”, “Context-based” or “Load Balancing” routing.)
If you have a native service 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.
The requests are routed according to the content-based routing rules you create. That is, they are routed based on the successful evaluation of one or more XPath expressions that are constructed utilizing the content of the request payload. For example, a routing rule might allow requests for half of the methods of a particular service to be routed to Service A, and the remaining methods to be routed to Service B.
You may also specify how to authenticate requests (as with all routing protocols).
If a SOAP request contains a WS-Security header, Mediator passes it to the native service.
To configure “Content-Based” routing
1. In CentraSite Control, display the details page of SOAP virtual service. If you need procedures for this step, see Viewing or Editing Virtualized Services.
2. Open the Processing Steps profile.
3. Select the Routing Protocols tab, specify the following fields and click Save.
Field
Description
HTTP or JMS
Select HTTP.
Routing Type
Select Content Based.
Routing Rules
For instructions for creating a routing rule, see Creating a Routing Rule for “Content-based” Routing (SOAP).
Default To
A native service endpoint to route the request to in case all routing rules evaluate to False. Click the Endpoint button and select the URL of the native service to route the request to.
Alternatively, Mediator offers “Local Optimization” capability if the native service and the virtual service (in Mediator) are located on the same machine. With local optimization, service invocation happens in-memory and not through a network hop. In the Default To field, specify the native service in either of the following forms:
local://<service_full_path>
OR
local://<server>:<port>/ws/<service_full_path>
For example:
local://MediatorTestServices:NewMediatorTestServices_Port
which points to the endpoint service NewMediatorTestServices_Port which is present under the folder MediatorTestServices in Integration Server. This works for HTTP endpoints only, for all types of Routing Protocols.
HTTP Authentication
Authentication Scheme: Specify the mode of authentication: Basic Authentication (default), NTLM, OAuth2, or None.
Basic Authentication. Select one of the following options:
*Use credentials from incoming request: (default): Authenticates requests based on the credentials specified in the HTTP header. Mediator passes the “Authorization” header present in the original client request to the native service.
*Use specified credentials: Authenticates requests according to the values you specify in the User, Password and Domain fields.
NTLM. Note that if Mediator is used to access a native service protected by NTLM (which is typically hosted in IIS), then the native service in IIS should be configured to use NTLM as the authentication scheme. If the authentication scheme is configured as “Windows”, then “NTLM” should be in its list. The “Negotiate” handshake will be supported in the near future. This note applies to all three of the following options for NTLM:
*Use credentials from incoming request: Default. Mediator uses the user credentials passed in the request header for an NTLM handshake with the server.
*Use specified credentials: Mediator uses the values you specify in the User, Password and Domain fields for an NTLM handshake with the server.
*Transparent: If the property watt.pg.disableNtlmAuthHandler is set to false (the default), then Mediator will behave in “pass by” mode, allowing an NTLM handshake to occur between the client and server. If the property watt.pg.disableNtlmAuthHandler is set to true, then Mediator performs the Kerberos Windows authentication (and not NTLM Windows authentication). This property is located in Integration Server_directory\instances\instance_name\config\server.cnf. Note: If the client is a WCF application, then the client should be configured with clientCredentialType set to NTLM.
OAuth2. Select one of the following options:
*Use credentials from incoming request: Default. This is known as “pass through” mode, in which the consumer includes an OAuth2 access token (a “Bearer” type token) in the request. Mediator then passes the access token unchanged to the native OAuth server.
*Use specified token: In this mode, the consumer does not include an OAuth2 access token in the request. Instead, the provider generates an OAuth2 access token for each consumer, and Mediator stores the access tokens in Passman. When consumers send requests, Mediator obtains the OAuth2 access tokens from Passman and uses them to access the native services. Specify an OAuth access token to be deployed by Mediator. If you select this option, the consumer need not pass the OAuth token during service invocation. Click the Show Token button to view the OAuth access token. Users who do not have the permissions to create and manage virtual services will not see this button.
Specify an OAuth access token to be deployed by Mediator by clicking the Show Token button and selecting an OAuth access token. Users who do not have the permissions to create and manage virtual services will not see this button. For more information, see Who Can Create and Manage Virtual Services?.
Note:  
Keep the following in mind:
*You must set the Integration Server property watt.server.auth.skipForMediator to “true” and then restart Integration Server for the change to take effect. This property is located in the server configuration file (server.cnf), which is located in the Integration Server_directory\config directory. For details, see the webMethods Integration Server Administrator's Guide.
*The run-time actions “Require HTTP Basic Authentication” and “Identify Consumer” (with the value HTTP Authentication Token as the identifier) will not be enforced when using the authentication scheme OAuth2.
None. Select the following option:
*Invoke Service Anonymously: Does not authenticate requests.
HTTP Headers
The HTTP headers that you want to use to authenticate the requests.
*Use Existing: Use the HTTP headers that are contained in the requests.
*Customize: Use the HTTP headers that you specify in the Name and Value columns below. If you need to specify multiple headers, use the plus button to add rows.
Copyright © 2005-2015 Software AG, Darmstadt, Germany.
Product LogoContact Support   |   Community   |   Feedback