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.
Routing policy | Description |
---|---|
permit:application_name | application_name is the application name to route to with an optional edition specifier. |
permitMM:application_name |
|
permitsticky:application_name | The permitsticky routing policy is the same as the permit routing policy, except that the on demand router (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. 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:
|
permitstickyMM:application_name |
|
reject:HTTP_error_code | This routing policy causes the ODR to reject the request and return the specified HTTP error code. For example, reject:503 returns a 503 Service is unavailable error. |
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. |
The valid service policies are the list of transaction class names. The transaction class refers to a single service class.