You can use administrative tasks to configure HTTP or
Session Initiation Protocol (SIP) rules for the on demand router
(ODR) routing policy.
The following rules are the preferred way to configure routing
policies, but using the multi-cluster routing property (MCRP) custom
property is another option. See the custom properties topic provided
in the related links at the end of this topic. The advantage of using
the following rules is that an expression can be used to determine
which requests are affected by the policy, whereas MCRP custom properties
only allow filtering by an application or and application's web module.
The other advantage of these rules is that you can select the target
(routingLocations) by cluster, server or web module, as opposed to
just cluster.
You can specify
SIP or HTTP protocols in the
commands.
addRoutingRule
The
addRoutingRule command
adds a routing policy rule.
Note: If you have an existing application
edition with a defined multi-cluster routing policy and you install
a new edition, you must create a new multi-cluster routing policy
for the new edition.
Required
parameters
- -protocol: Specifies the
name of the protocol to associate with a rule. (String, required)
- -priority: Positive integer
value representing the priority of a rule. Zero is the highest priority.
(String, required)
- -expression: Specifies
the rule expression. The expression must be enclosed in double quotes.
For more information about specifying the parameters for the rule
expression, refer to the SIP operands topic
and the HTTP operands topic. (String, required)
- -actionType: Specifies the
type of action to associate with a rule. (String, required)
The
following list contains the types of actions to associate with HTTP
rules:
- localResource: Specifies the local resource
(file) to use for this routing rule.
- permit: Permit routing to servers not in
a maintenance mode.
- redirect: Redirect the request to the URL
specified by the redirectURL option.
- reject: Reject routing with return code
specified by the errorcode option.
- permitsticky: Permit routing to servers
not in maintenance mode and perform active affinity; that is, affinity
is always preserved even when not requested by the application.
- permitMM: Permit routing only to servers
in maintenance mode.
- permitstickyMM: Permit routing only to
servers in maintenance mode and perform active affinity.
The following list contains the types of actions to associate
with SIP rules:
- permit: Permit routing to servers not in
maintenance mode.
- reject: Reject routing with return code
specified by the errorcode option.
Optional parameters
- -odrname: Specifies the
name of the ODR to which the routing policy work class applies. The -odrname parameter
is required only if you modify an ODR or a web server.
-webservername:
Specifies the name of the web server to which the routing policy work
class applies.
- -nodename: Specifies the
name of the node on which the ODR or web server resides. The -nodename parameter
is required only if you modify an ODR or a web server.
- -clustername: Specifies
the name of the cluster to which the rule applies. The -clustername parameter
is required only if you modify an ODR cluster.
- -dcname: Specifies
the name of the dynamic cluster to which the rule applies. The -dcname parameter
is required only if you modify an ODR cluster.
- -multiclusterAction: Specifies the method
to route requests if multiple routing location clusters are matched.
The -multiclusterAction parameter applies to
any of the permit actionTypes, and is required only if actionType is
equal to permit, permitsticky, permitMM,
or permitstickyMM.
- Failover: Find the first cluster with an
available server and load balance across that cluster. The order of
a dynamically generated list of clusters is undefined.
- WRR: Weighted Round Robin load balance.
For UDP retransmission, maintain affinity.
- WLOR: Weighted least outstanding request.
Best practice: The recommendation is to use the
WLOR value
instead of the
WRR value.
bprac
The following list contains the possible values for SIP
rules:
- Failover: Find the first cluster with an
available server and load balance across that cluster. The order of
a dynamically generated list of clusters is undefined.
- WRR: Weighted Round Robin load balance.
For UDP retransmission, maintain affinity.
- Error: If there are multiple clusters,
to select from it throws an error. it expects one and only one cluster.
- -routingLocations: Specifies a list of target
locations to route requests. The -routingLocations parameter
is required only if actionType is equal to any
of the permit actionType.
Each
operand in the list follows one of three formats, and can contain
a wildcard * value, which matches any value:
- cluster=cellName/clusterName
- server=cellName/nodeName/serverName
- module=cellName/applicationName/applicationVersion/moduleName
With SIP routing rules only, you can alternatively define
target clusters through a rule expression. The valid operators are
AND, OR, NOT and parenthetical grouping. Format according to the following
list:
- cluster=cellName/clusterName
- server=cellName/nodeName/serverName
- modules=cellName/applicationName/applicationVersion/moduleName
- server maintenance mode=true or false
- node maintenance mode=true or false
- protocol=PROTO_VALUE:
- PROTO_SIP = sip
- SIP over TCP
- PROTO_SIPS = sips
- SIP over SSL and TCP
- PROTO_SIPU = sipu
- SIP over UDP
- PROTO_SIPX = sipx
- SIP over XMEM
Note: For applications that have no applicationVersion value,
leave the applicationVersion value blank: module=cellName/application//moduleName.
- -errorcode: Integer error
code to reject request. The -errorcode parameter
is required only if actionType is equal to reject.
- -localResource:
This option can be used in association with the actionType parameter.
If you use the -localResource option with the actionType parameter,
also specify the localResourcePath parameter.
The localResourcePath parameter indicates the
absolute or relative path to the profile root.
Batch mode example usage
The
following example shows a failover of all applications in a cell to
a generic server cluster that points to another cell:
- Using Jacl:
$AdminTask addRoutingRule {-webservername ws1 -nodename node1 -protocol HTTP -priority 0 -expression
"request.method = 'getOperation'" -actionType permit -multiclusterAction Failover
-routingLocations cluster=*/*}
- Using Jython string:
AdminTask.addRoutingRule('-webservername ws1 -nodename node1 -protocol HTTP -priority 0 -expression
"queryparm$userid = \'123\'" -actionType permit -multiclusterAction Failover -routingLocations
"module=*/*/*/*,cluster=myCell/myFailoverGSCThatPointsToAnotherCell"')
The following example creates a multi-cluster routing
policy for a new application edition:
- Using Jacl:
$AdminTask addRoutingRule {-odrname odr -nodename node1 -protocol
HTTP -priority 0 -expression "uri LIKEIN {'/contextRoot','/contextRoot/%'}"
-actionType permit -multiclusterAction Failover -routingLocations
cluster=cellName/clusterName}
- Using Jython string:
AdminTask.addRoutingRule('-odrname odr -nodename node1 -protocol
HTTP -priority 0 -expression "uri LIKEIN (\'/contextRoot\',\'/contextRoot/%\')"
-actionType permit -multiclusterAction Failover -routingLocations
cluster=cellName/clusterName')
Interactive mode example usage
- Using Jacl:
$AdminTask addRoutingRule {-interactive}
- Using Jython string:
AdminTask.addRoutingRule ('[-interactive]')
changeRoutingDefaultRulesAction
The changeRoutingDefaultRulesAction command
changes the routing policy default action for a rule.
Required parameters
- -protocol: Specifies the
name of the protocol to associate with a rule. (String, required)
- -actionType: Specifies the
type of action to associate with a rule. (String, required)
The
following list contains the types of actions to associate with HTTP
rules:
- localResource: Specifies the local resource
(file) to use for this routing rule.
- permit: Permit routing to servers not in
a maintenance mode.
- redirect: Redirect the request to the URL
specified by the redirectURL option.
- reject: Reject routing with return code
specified by the errorcode option.
- permitsticky: Permit routing to servers
not in maintenance mode and perform active affinity; that is, affinity
is always preserved even when not requested by the application.
- permitMM: Permit routing only to servers
in maintenance mode.
- permitstickyMM: Permit routing only to
servers in maintenance mode and perform active affinity.
The following list contains the types of actions to associate
with SIP rules:
- permit: Permit routing to servers not in
maintenance mode.
- reject: Reject routing with return code
specified by the errorcode option.
Optional parameters
- -odrname: Specifies the
name of the ODR to which the routing policy work class applies. The -odrname parameter
is required only if you modify an ODR or a web server.
-webservername:
Specifies the name of the web server to which the routing policy work
class applies.
- -nodename: Specifies the
name of the node on which the ODR or web server resides. The -nodename parameter
is required only if you modify an ODR or a web server.
- -clustername: Specifies
the name of the cluster to which the rule applies. The -clustername parameter
is required only if you modify an ODR cluster.
- -dcname: Specifies
the name of the dynamic cluster to which the rule applies. The -dcname parameter
is required only if you modify an ODR cluster.
- -multiclusterAction: Specifies the method
to route requests if multiple routing location clusters are matched.
The -multiclusterAction parameter applies to
any of the permit action types, and is required only if actionType is
equal to permit, permitsticky, permitMM,
or permitstickyMM.
- Failover: Find the first cluster with an
available server and load balance across that cluster. The order of
a dynamically generated list of clusters is undefined.
- WRR: Weighted Round Robin load balance.
For UDP retransmission, maintain affinity.
- WLOR: Weighted least outstanding request.
Best practice: The recommendation is to use the
WLOR value
instead of the
WRR value.
bprac
The following list contains the possible values for SIP
rules:
- Failover: Find the first cluster with an
available server and load balance across that cluster. The order of
a dynamically generated list of clusters is undefined.
- WRR: Weighted Round Robin load balance.
For UDP retransmission, maintain affinity.
- Error: If there are multiple clusters,
to select from it throws an error. it expects one and only one cluster.
- -routingLocations: Specifies a list of target
locations to route requests. The -routingLocations parameter
is required only if actionType is equal to any
of the permit action types.
Each operand
in the list follows one of three formats, and can contain a wildcard
* value, which matches any value:
- cluster=cellName/clusterName
- server=cellName/nodeName/serverName
- module=cellName/applicationName/applicationVersion/moduleName
With SIP routing rules only, you can alternatively define
target clusters through a rule expression. The valid operators are
AND, OR, NOT and parenthetical grouping. Format according to the following
list:
- cluster=cellName/clusterName
- server=cellName/nodeName/serverName
- modules=cellName/applicationName/applicationVersion/moduleName
- server maintenance mode=true or false
- node maintenance mode=true or false
- protocol=PROTO_VALUE:
- PROTO_SIP = sip
- SIP over TCP
- PROTO_SIPS = sips
- SIP over SSL and TCP
- PROTO_SIPU = sipu
- SIP over UDP
- PROTO_SIPX = sipx
- SIP over XMEM
Note: For applications that have no applicationVersion value,
leave the applicationVersion value blank: module=cellName/application//moduleName.
- -errorcode: Integer error
code to reject request. The -errorcode parameter
is required only if actionType is equal to reject.
- -localResource:
This option can be used in association with the actionType parameter.
If you use the -localResource option with the actionType parameter,
also specify the localResourcePath parameter.
The localResourcePath parameter indicates the
absolute or relative path to the profile root.
Batch mode example usage
Interactive mode example usage
- Using Jacl:
$AdminTask changeRoutingDefaultRulesAction {-interactive}
- Using Jython string:
AdminTask.changeRoutingDefaultRulesAction ('[-interactive]')
changeRoutingRuleAction
The changeRoutingRuleAction command
changes a routing policy action for a rule.
Required parameters
- -protocol: Specifies the
name of the protocol to associate with a rule. (String, required)
- -priority: Positive integer
value representing the priority of a rule. Zero is the highest priority.
(String, required)
Optional parameters
- -odrname: Specifies the
name of the ODR to which the routing policy work class applies. The -odrname parameter
is required only if you modify an ODR or a web server.
-webservername:
Specifies the name of the web server to which the routing policy work
class applies.
- -nodename: Specifies the
name of the node on which the ODR or web server resides. The -nodename parameter
is required only if you modify an ODR or a web server.
- -clustername: Specifies
the name of the cluster to which the rule applies. The -clustername parameter
is required only if you modify an ODR cluster.
- -dcname: Specifies
the name of the dynamic cluster to which the rule applies. The -dcname parameter
is required only if you modify an ODR cluster.
- -multiclusterAction: Specifies the method
to route requests if multiple routing location clusters are matched.
The -multiclusterAction parameter applies to
any of the permit actionTypes, and is required
only if actionType is equal to permit, permitsticky, permitMM,
or permitstickyMM.
- Failover: Find the first cluster with an
available server and load balance across that cluster. The order of
a dynamically generated list of clusters is undefined.
- WRR: Weighted Round Robin load balance.
For UDP retransmission, maintain affinity.
- WLOR: Weighted least outstanding request.
Best practice: The recommendation is to use the
WLOR value
instead of the
WRR value.
bprac
The following list contains the possible values for SIP
rules:
- Failover: Find the first cluster with an
available server and load balance across that cluster. The order of
a dynamically generated list of clusters is undefined.
- WRR: Weighted Round Robin load balance.
For UDP retransmission, maintain affinity.
- Error: If there are multiple clusters,
to select from it throws an error. it expects one and only one cluster.
- -routingLocations: Specifies a list of target
locations to route requests. The -routingLocations parameter
is required only if actionType is equal to any
of the permit actionTypes.
Each operand in
the list follows one of three formats, and can contain a wildcard
* value, which matches any value:
- cluster=cellName/clusterName
- server=cellName/nodeName/serverName
- module=cellName/applicationName/applicationVersion/moduleName
With SIP routing rules only, you can alternatively define
target clusters through a rule expression. The valid operators are
AND, OR, NOT and parenthetical grouping. Format according to the following
list:
- cluster=cellName/clusterName
- server=cellName/nodeName/serverName
- modules=cellName/applicationName/applicationVersion/moduleName
- server maintenance mode=true or false
- node maintenance mode=true or false
- protocol=PROTO_VALUE:
- PROTO_SIP = sip
- SIP over TCP
- PROTO_SIPS = sips
- SIP over SSL and TCP
- PROTO_SIPU = sipu
- SIP over UDP
- PROTO_SIPX = sipx
- SIP over XMEM
Note: For applications that have no applicationVersion value,
leave the applicationVersion value blank: module=cellName/application//moduleName.
- -errorcode: Integer error
code to reject request. The -errorcode parameter
is required only if actionType is equal to reject.
- -localResource:
This option can be used in association with the actionType parameter.
If you use the -localResource option with the actionType parameter,
also specify the localResourcePath parameter.
The localResourcePath parameter indicates the
absolute or relative path to the profile root.
Batch mode example usage
- Using Jacl:
$AdminTask changeRoutingRuleAction {-webservername ws1 -nodename node1 -protocol
HTTP -priority 0 -multiclusterAction Failover -routingLocations cluster=*/*
- Using Jython string:
AdminTask.changeRoutingRuleAction('[-webservername ws1 -nodename node1 -protocol
HTTP -priority 0 -multiclusterAction WRR -routingLocations "cluster=myCell/*"]')
Interactive mode example usage
- Using Jacl:
$AdminTask changeRoutingRuleAction {-interactive}
- Using Jython string:
AdminTask.changeRoutingRuleAction ('[-interactive]')
changeRoutingRuleExpression
The changeRoutingRuleExpression command
changes a routing policy rule expression.
Required
parameters
- -protocol: Specifies the
name of the protocol to associate with a rule. (String, required)
- -priority: Positive integer
value representing the priority of a rule. Zero is the highest priority.
(String, required)
- -expression: Specifies
the rule expression. The expression must be enclosed in double quotes.
For more information about specifying the parameters for the rule
expression, refer to the SIP operands topic
and the HTTP operands topic. (String, required)
Optional parameters
- -odrname: Specifies the
name of the ODR to which the routing policy work class applies. The -odrname parameter
is required only if you modify an ODR or a web server.
-webservername:
Specifies the name of the web server to which the routing policy work
class applies.
- -nodename: Specifies the
name of the node on which the ODR or web server resides. The -nodename parameter
is required only if you modify an ODR or a web server.
- -clustername: Specifies
the name of the cluster to which the rule applies. The -clustername parameter
is required only if you modify an ODR cluster.
- -dcname: Specifies
the name of the dynamic cluster to which the rule applies. The -dcname parameter
is required only if you modify an ODR cluster.
Batch mode example usage
- Using Jacl:
$AdminTask changeRoutingRuleExpression {-odrname odr -nodename node1 -protocol
SIP -priority 0 -expression "request.method = 'getOperation0'"}
- Using Jython string:
AdminTask.changeRoutingRuleExpression('[-odrname odr -nodename node1 -protocol
HTTP -priority 0 -expression "queryparm$userid = \'123\'"]')
Interactive mode example usage
- Using Jacl:
$AdminTask changeRoutingRuleExpression {-interactive}
- Using Jython string:
AdminTask.changeRoutingRuleExpression ('[-interactive]')
changeRoutingRulePriority
The changeRoutingRulePriority command
changes a routing policy rule priority.
Required
parameters
- -protocol: Specifies the
name of the protocol to associate with a rule. (String, required)
- -priority: Positive integer
value representing the priority of a rule. Zero is the highest priority.
(String, required)
- -expression: Specifies
the rule expression. The expression must be enclosed in double quotes.
For more information about specifying the parameters for the rule
expression, refer to the SIP operands topic
and the HTTP operands topic. (String, required)
Optional parameters
- -odrname: Specifies the
name of the ODR to which the routing policy work class applies. The -odrname parameter
is required only if you modify an ODR or a web server.
-webservername:
Specifies the name of the web server to which the routing policy work
class applies.
- -nodename: Specifies the
name of the node on which the ODR or web server resides. The -nodename parameter
is required only if you modify an ODR or a web server.
- -clustername: Specifies
the name of the cluster to which the rule applies. The -clustername parameter
is required only if you modify an ODR cluster.
- -dcname: Specifies
the name of the dynamic cluster to which the rule applies. The -dcname parameter
is required only if you modify an ODR cluster.
Batch mode example usage
- Using Jacl:
$AdminTask changeRoutingRulePriority {-odrname odr -nodename node1 -protocol
SIP -priority 0 -expression "request.method = 'getOperation0'"}
- Using Jython string:
AdminTask.changeRoutingRulePriority('[-odrname odr -nodename node1 -protocol
HTTP -priority 1 -expression "queryparm$userid = \'123\'"]')
Interactive mode example usage
- Using Jacl:
$AdminTask changeRoutingRulePriority {-interactive}
- Using Jython string:
AdminTask.changeRoutingRulePriority ('[-interactive]')
createRoutingRules
The createRoutingRules command
creates a routing policy rule list.
Required
parameters
- -protocol: Specifies the
name of the protocol to associate with a rule. (String, required)
Optional parameters
- -odrname: Specifies the
name of the ODR to which the routing policy work class applies. The -odrname parameter
is required only if you modify an ODR or a web server.
-webservername:
Specifies the name of the web server to which the routing policy work
class applies.
- -nodename: Specifies the
name of the node on which the ODR or web server resides. The -nodename parameter
is required only if you modify an ODR or a web server.
- -clustername: Specifies
the name of the cluster to which the rule applies. The -clustername parameter
is required only if you modify an ODR cluster.
- -dcname: Specifies
the name of the dynamic cluster to which the rule applies. The -dcname parameter
is required only if you modify an ODR cluster.
Batch mode example usage
- Using Jacl:
$AdminTask createRoutingRules {-odrname odr -nodename node1 -protocol SIP}
- Using Jython string:
AdminTask.createRoutingRules('-odrname odr -nodename node1 -protocol SIP')
Interactive mode example usage
- Using Jacl:
$AdminTask createRoutingRules {-interactive}
- Using Jython string:
AdminTask.createRoutingRules ('[-interactive]')
listRoutingRules
The listRoutingRules deletes
a dynamic cluster from the configuration.
Required
parameters
- -protocol: Specifies the
name of the protocol to associate with a rule. (String, required)
Optional parameters
- -odrname: Specifies the
name of the ODR to which the routing policy work class applies. The -odrname parameter
is required only if you modify an ODR or a web server.
-webservername:
Specifies the name of the web server to which the routing policy work
class applies.
- -nodename: Specifies the
name of the node on which the ODR or web server resides. The -nodename parameter
is required only if you modify an ODR or a web server.
- -clustername: Specifies
the name of the cluster to which the rule applies. The -clustername parameter
is required only if you modify an ODR cluster.
- -dcname: Specifies
the name of the dynamic cluster to which the rule applies. The -dcname parameter
is required only if you modify an ODR cluster.
Batch mode example usage
- Using Jacl:
$AdminTask listRoutingRules {-odrname odr -nodename node1 -protocol SIP}
- Using Jython string:
AdminTask.listRoutingRules('-odrname odr -nodename node1 -protocol SIP')
Interactive mode example usage
- Using Jacl:
$AdminTask listRoutingRules {-interactive}
- Using Jython string:
AdminTask.listRoutingRules ('[-interactive]')
removeRoutingRule
The removeRoutingRule command
removes a routing policy rule.
Required
parameters
- -protocol: Specifies the
name of the protocol to associate with a rule. (String, required)
- -priority: Positive integer
value representing the priority of a rule. Zero is the highest priority.
(String, required)
- -expression: Specifies
the rule expression. The expression must be enclosed in double quotes.
For more information about specifying the parameters for the rule
expression, refer to the SIP operands topic
and the HTTP operands topic. (String, required)
Optional parameters
- -odrname: Specifies the
name of the ODR to which the routing policy work class applies. The -odrname parameter
is required only if you modify an ODR or a web server.
-webservername:
Specifies the name of the web server to which the routing policy work
class applies.
- -nodename: Specifies the
name of the node on which the ODR or web server resides. The -nodename parameter
is required only if you modify an ODR or a web server.
- -clustername: Specifies
the name of the cluster to which the rule applies. The -clustername parameter
is required only if you modify an ODR cluster.
- -dcname: Specifies
the name of the dynamic cluster to which the rule applies. The -dcname parameter
is required only if you modify an ODR cluster.
Batch mode example usage
- Using Jacl:
$AdminTask removeRoutingRule {-odrname odr -nodename node1 -protocol SIP -expression
"request.method = 'getOperation'"}
- Using Jython string:
AdminTask.removeRoutingRule('[-odrname odr -nodename node1 -protocol HTTP -expression
"queryparm$userid = \'123\'"]')
Interactive mode example usage
- Using Jacl:
$AdminTask removeRoutingRule {-interactive}
- Using Jython string:
AdminTask.removeRoutingRule ('[-interactive]')