Intelligent Management: rules for ODR routing policy administrative tasks

We can use administrative tasks to configure HTTP or Session Initiation Protocol(SIP) rules for the on demand router (ODR) routing policy.

Use the following rules to configure routing policies. These rules are the preferred routing policy configuration method. We can also configure multi-cluster routing policies for failover and load balancing. To learn more about this procedure, read about configuring the on demand router for multi-cluster failover and load balancing routing.

The main benefits of using the ODR routing policy administrative commands are:

• We can use expressions to determine which requests are affected by the policy. The multi-cluster routing method allows only filtering by application or application web module.

• We can select the target (routingLocations) by cluster, server or by web module. The multi-cluster routing method allows us to select only the target cluster.

• We can specify SIP or HTTP protocols in the commands.

• addRoutingRule

• changeRoutingDefaultRulesAction

• changeRoutingRuleAction

• changeRoutingRuleExpression

• changeRoutingRulePriority

• createRoutingRules

• listRoutingRules

• removeRoutingRule

addRoutingRule

The addRoutingRule command adds a routing policy rule.

If we have an existing application edition with a defined multi-cluster routing policy and you install a new edition, create a new multi-cluster routing policy for the new edition.

Required parameters

• protocol: 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: 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: 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.

• (v8550) -webservername: Name of the web server to which the routing policy work class applies.

• nodename: 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: Name of the cluster to which the rule applies. The -clustername parameter is required only if you modify an ODR cluster.

• dcname: Name of the dynamic cluster to which the rule applies. The -dcname parameter is required only if you modify an ODR cluster.

• multiclusterAction: 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: 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, we 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

  • module=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

  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 we 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

The following example shows a failover of all applications in a cell to a generic server cluster that points to another cell:

• Jacl:
  $AdminTask addRoutingRule {-webservername ws1 -nodename node1 -protocol HTTP -priority 0 -expression "request.method = 'getOperation'" -actionType permit -multiclusterAction Failover -routingLocations cluster=*/*}

• 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:

• Jacl:
  $AdminTask addRoutingRule {-odrname odr -nodename node1 -protocol HTTP -priority 0 -expression "uri LIKEIN {'/contextRoot','/contextRoot/%'}" -actionType permit -multiclusterAction Failover -routingLocations cluster=cellName/clusterName}

• 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

• Jacl:
  $AdminTask addRoutingRule {-interactive}

• Jython string...
  AdminTask.addRoutingRule ('[-interactive]')

changeRoutingDefaultRulesAction

The changeRoutingDefaultRulesAction command changes the routing policy default action for a rule.

Required parameters

• protocol: 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: 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: 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.

• (v8550) -webservername: Name of the web server to which the routing policy work class applies.

• nodename: 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: Name of the cluster to which the rule applies. The -clustername parameter is required only if you modify an ODR cluster.

• dcname: Name of the dynamic cluster to which the rule applies. The -dcname parameter is required only if you modify an ODR cluster.

• multiclusterAction: 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: 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, we 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

  • module=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

  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 we 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

• Jacl:

  The following examples shows a failover of a single cluster to the failover generic server cluster:

  $AdminTask changeRoutingDefaultRulesAction {-webservername ws1 -nodename node1 -protocol HTTP -actionType permit -multiclusterAction Failover -routingLocations cluster=*/*}

• Jython string...
  AdminTask.changeRoutingDefaultRulesAction('[-webservername ws1 -nodename node1 -protocol HTTP -actionType permit -multiclusterAction Failover -routingLocations "cluster=myCell/myPrimaryCluster,cluster=myCell/myFailoverCluster"]')

Interactive mode

• Jacl:
  $AdminTask changeRoutingDefaultRulesAction {-interactive}

• Jython string...
  AdminTask.changeRoutingDefaultRulesAction ('[-interactive]')

changeRoutingRuleAction

The changeRoutingRuleAction command changes a routing policy action for a rule.

Required parameters

• protocol: 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: 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.

• (v8550) -webservername: Name of the web server to which the routing policy work class applies.

• nodename: 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: Name of the cluster to which the rule applies. The -clustername parameter is required only if you modify an ODR cluster.

• dcname: Name of the dynamic cluster to which the rule applies. The -dcname parameter is required only if you modify an ODR cluster.

• multiclusterAction: 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: 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, we 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

  • module=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

  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 we 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

• Jacl:
  $AdminTask changeRoutingRuleAction {-webservername ws1 -nodename node1 -protocol HTTP -priority 0 -multiclusterAction Failover -routingLocations cluster=*/*

• Jython string...
  AdminTask.changeRoutingRuleAction('[-webservername ws1 -nodename node1 -protocol HTTP -priority 0 -multiclusterAction WRR -routingLocations "cluster=myCell/*"]')

Interactive mode

• Jacl:
  $AdminTask changeRoutingRuleAction {-interactive}

• Jython string...
  AdminTask.changeRoutingRuleAction ('[-interactive]')

changeRoutingRuleExpression

The changeRoutingRuleExpression command changes a routing policy rule expression.

Required parameters

• protocol: 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: 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.

• (v8550) -webservername: Name of the web server to which the routing policy work class applies.

• nodename: 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: Name of the cluster to which the rule applies. The -clustername parameter is required only if you modify an ODR cluster.

• dcname: 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

• Jacl:
  $AdminTask changeRoutingRuleExpression {-odrname odr -nodename node1 -protocol SIP -priority 0 -expression "request.method = 'getOperation0'"}

• Jython string...
  AdminTask.changeRoutingRuleExpression('[-odrname odr -nodename node1 -protocol HTTP -priority 0 -expression "queryparm$userid = \'123\'"]')

Interactive mode

• Jacl:
  $AdminTask changeRoutingRuleExpression {-interactive}

• Jython string...
  AdminTask.changeRoutingRuleExpression ('[-interactive]')

changeRoutingRulePriority

The changeRoutingRulePriority command changes a routing policy rule priority.

Required parameters

• protocol: 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: 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.

• (v8550) -webservername: Name of the web server to which the routing policy work class applies.

• nodename: 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: Name of the cluster to which the rule applies. The -clustername parameter is required only if you modify an ODR cluster.

• dcname: 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

• Jacl:
  $AdminTask changeRoutingRulePriority {-odrname odr -nodename node1 -protocol SIP -priority 0 -expression "request.method = 'getOperation0'"}

• Jython string...
  AdminTask.changeRoutingRulePriority('[-odrname odr -nodename node1 -protocol HTTP -priority 1 -expression "queryparm$userid = \'123\'"]')

Interactive mode

• Jacl:
  $AdminTask changeRoutingRulePriority {-interactive}

• Jython string...
  AdminTask.changeRoutingRulePriority ('[-interactive]')

createRoutingRules

The createRoutingRules command creates a routing policy rule list.

Required parameters

• protocol: Name of the protocol to associate with a rule. (String, required)

Optional parameters

• odrname: 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.

• (v8550) -webservername: Name of the web server to which the routing policy work class applies.

• nodename: 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: Name of the cluster to which the rule applies. The -clustername parameter is required only if you modify an ODR cluster.

• dcname: 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

• Jacl:
  $AdminTask createRoutingRules {-odrname odr -nodename node1 -protocol SIP}

• Jython string...
  AdminTask.createRoutingRules('-odrname odr -nodename node1 -protocol SIP')

Interactive mode

• Jacl:
  $AdminTask createRoutingRules {-interactive}

• Jython string...
  AdminTask.createRoutingRules ('[-interactive]')

listRoutingRules

The listRoutingRules deletes a dynamic cluster from the configuration.

Required parameters

• protocol: Name of the protocol to associate with a rule. (String, required)

Optional parameters

• odrname: 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.

• (v8550) -webservername: Name of the web server to which the routing policy work class applies.

• nodename: 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: Name of the cluster to which the rule applies. The -clustername parameter is required only if you modify an ODR cluster.

• dcname: 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

• Jacl:
  $AdminTask listRoutingRules {-odrname odr -nodename node1 -protocol SIP}

• Jython string...
  AdminTask.listRoutingRules('-odrname odr -nodename node1 -protocol SIP')

Interactive mode

• Jacl:
  $AdminTask listRoutingRules {-interactive}

• Jython string...
  AdminTask.listRoutingRules ('[-interactive]')

removeRoutingRule

The removeRoutingRule command removes a routing policy rule.

Required parameters

• protocol: 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: 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.

• (v8550) -webservername: Name of the web server to which the routing policy work class applies.

• nodename: 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: Name of the cluster to which the rule applies. The -clustername parameter is required only if you modify an ODR cluster.

• dcname: 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

• Jacl:
  $AdminTask removeRoutingRule {-odrname odr -nodename node1 -protocol SIP -expression "request.method = 'getOperation'"}

• Jython string...
  AdminTask.removeRoutingRule('[-odrname odr -nodename node1 -protocol HTTP -expression "queryparm$userid = \'123\'"]')

Interactive mode

• Jacl:
  $AdminTask removeRoutingRule {-interactive}

• Jython string...
  AdminTask.removeRoutingRule ('[-interactive]')

Related concepts

Route policy action types

Overview of request flow prioritization

Related tasks

Configure the on demand router for multi-cluster failover and load balancing routing

Configure ODRs

Create a static cluster of ODRs

Intelligent Management: SIP operands

Intelligent Management: HTTP operands

Related information:

Intelligent Management: rules for ODR service policy administrative tasks