Intelligent Management: routing and service policies
Two types of policies are applied to a request: routing and service. You can create routing policies for HTTP and SOAP requests, and you can create service policies for HTTP, IIOP, SOAP, JMS, and SIP requests. Additionally, work classes can contain classification rules for both policy types with the exception of JMS. Classification rules are not supported for JMS work classes.
Valid routing policies
Routing policy | Description |
---|---|
permit:application_name |
|
permitMM:application_name |
|
permitsticky:application_name |
The The
permitsticky action means
that the ODR actively establishes affinity between the client and
server if affinity was not already established by the application.
The ODR accomplishes this by adding a SET-COOKIE: WSJSESSIONID=xx:serverID ; path=webModuleContextRoot to
the response if:
webModuleContextRoot is
the context root of the Web module to which the request was mapped. |
permitstickyMM:application_name |
This routing policy is the same as the permit routing policy, except that the ODR also maintains client to server affinity for any future requests that come from the same client. In this case, the ODR adds a SET-COOKIE header to the response before it sends the response to the client. Note that the server must be in maintenance mode. |
reject:HTTP_error_code |
This routing policy causes the ODR
to reject the request and return the specified HTTP error code. For
example, |
reject:URL |
With this routing policy, the ODR redirects the request to the specified URL. The URL has the pattern of protocol://URI. An example of a valid URL is http://w3.ibm.com. |
Valid service policies
The valid service policies are the list of transaction class names. The transaction class refers to a single service class.