Intelligent Management: routing and service policies

Intelligent Management: routing and service policies

Two types of policies are applied to a request: routing and service. We can create routing policies for HTTP and SOAP requests, and we 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

Route policy Description
permit:application_name
application_name is the application name to route to with an optional edition specifier.
permitMM:application_name
application_name is the application name to route to with an optional edition specifier. Routing in this way allows the request to continue as normal. Note that the server must be in maintenance mode.
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:

The response does not already have a SET-COOKIE that will establish server affinity, and

The corresponding request does not indicate that server affinity had already been established.
The serverID is the server identifier, and is also referred to as the clone ID. The 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: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.

Valid service policies

The valid service policies are the list of transaction class names. The transaction class refers to a single service class.

Subtopics

(dist)(zos) Intelligent Management: subexpression builder operands
Intelligent Management routing and service policy rules use the subexpression builder. The subexpression builder is an optional tool that helps you build complex rule conditions from subexpressions by using AND, OR, NOT and parenthetical grouping. An expression can be built from several subexpressions using logical operators.

Related tasks

Define a service policy
Set maintenance mode
Activating concurrent application editions
Validating an edition

Intelligent Management: subexpression builder operands

Related information:

Intelligent Management: rules for ODR routing policy administrative tasks
Intelligent Management: rules for ODR service policy administrative tasks

Route policy	Description
permit:application_name	application_name is the application name to route to with an optional edition specifier.
permitMM:application_name	application_name is the application name to route to with an optional edition specifier. Routing in this way allows the request to continue as normal. Note that the server must be in maintenance mode.
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: The response does not already have a SET-COOKIE that will establish server affinity, and The corresponding request does not indicate that server affinity had already been established. The serverID is the server identifier, and is also referred to as the clone ID. The 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: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.