![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
![[z/OS]](../images/ngzos.gif)
Intelligent Management: Regras para Tarefas Administrativas de Política de Roteamento do ODR
É possível usar tarefas administrativas para configurar regras de HTTP ou Session Initiation Protocol (SIP) para a política de roteamento do On Demand Router (ODR).
Use as seguintes regras para configurar as políticas de roteamento. Essas regras são o método de configuração preferencial da política de roteamento. Também é possível configurar políticas de roteamento de diversos clusters para failover e balanceamento de carga. Para saber mais sobre esse procedimento, leia sobre como configurar o On Demand Router para failover e roteamento de balanceamento de carga de diversos clusters.
- É possível usar as expressões para determinar quais solicitações são afetadas pela política. O método de roteamento de diversos clusters permite filtrar apenas por aplicativo ou por módulo da web do aplicativo.
- É possível selecionar o destino (routingLocations) por cluster, servidor ou módulo da web. O método de roteamento de diversos clusters permite selecionar apenas o cluster de destino.
- É possível especificar protocolos SIP ou HTTP nos comandos.
addRoutingRule
Parâmetros necessários
- -protocol: Especificar o nome do protocolo para associar a uma regra. (Sequência, obrigatória)
- -priority: Valor de número inteiro positivo representando a prioridade de uma regra. Zero é a prioridade mais alta. (Sequência, obrigatória)
- -expression: Especificar a expressão da regra. A expressão deve ser delimitada por aspas duplas. Para obter informações adicionais sobre como especificar os parâmetros para a expressão da regra, consulte os tópicos de operandos SIP e HTTP. (Sequência, obrigatória)
- -actionType: Especificar o tipo de ação para associar a uma
regra. (Sequência, obrigatória) A seguinte lista contém os tipos de ações a serem associadas às regras de HTTP:
- localResource: Especifica o recurso local (arquivo) a ser utilizado para esta regra de roteamento.
- permit: Permitir roteamento a servidores não em modo de manutenção.
- redirect: Redirecionar a solicitação à URL especificada pela opção redirectURL.
- reject: Rejeita o roteamento com o código de retorno especificado pela opção errorcode.
- permitsticky: Permitir roteamento a servidors não em modo de manutenção e executar afinidade ativa; isto é , a afinidade é sempre preservada mesmo quando não solicitada pelo aplicativo.
- permitMM: Permite o roteamento apenas para servidores em modo de manutenção.
- permitstickyMM: Permite o roteamento somente para servidores em modo de manutenção e executar afinidade ativa.
A seguinte lista contém os tipos de ações a serem associadas às regras de SIP:- permitir: Permitir roteamento para servidores que não estão no modo de manutenção.
- reject: Rejeita o roteamento com o código de retorno especificado pela opção errorcode.
Parâmetros Opcionais
- -odrname: Especificar o nome do ODR ao qual a classe de trabalho da política de roteamento se aplica. O parâmetro -odrname será necessário somente se você modificar um ODR ou um servidor da web.
- -webservername: Especifica o nome do servidor da web ao qual a classe de trabalho da política de roteamento se aplica.
- -nodename: Especifica o nome do nó no qual o ODR ou o servidor da web reside. O parâmetro -nodename será necessário somente se você modificar um ODR ou um servidor da web.
- -clustername : Especificar o nome do cluster ao qual a regra se aplica. O parâmetro -clustername é necessário somente se você modificar um cluster do ODR.
- -dcname: Especifica o nome do cluster dinâmico ao qual a regra se aplica. O parâmetro -dcname será necessário somente se você modificar um cluster ODR.
- -multiclusterAction: Especificar o método para rotear pedidos se
múltiplos clusters de local de roteamento corresponderem. O parâmetro -multiclusterAction se aplica a qualquer um dos actionTypes permit, e será necessário apenas se actionType for igual a permit, permitsticky, permitMM ou permitstickyMM.
- Failover: Localizar o primeiro cluster com um servidor disponível e o balanceamento de carga através do cluster. A ordem de uma lista de clusters gerada dinamicamente é indefinida.
- WRR: Balanceamento de carga Weighted Round Robin. Para a retransmissão de UDP, mantenha a afinidade.
- WLOR: Weighted Least Outstanding Request.
Boas Práticas: A recomendação é usar o valor de WLOR em vez do valor de WRR.bprac
A seguinte lista contém os valores possíveis para regras de SIP:- Failover: Localizar o primeiro cluster com um servidor disponível e o balanceamento de carga através do cluster. A ordem de uma lista de clusters gerada dinamicamente é indefinida.
- WRR: Balanceamento de carga Weighted Round Robin. Para a retransmissão de UDP, mantenha a afinidade.
- Erro: Se houver vários clusters, será emitido um erro, se forem selecionados. Um e apenas um cluster é esperado.
- -routingLocations: Especifica uma lista de locais de destino
para pedidos de rota.
O parâmetro -routingLocations será necessário apenas se actionType for igual a qualquer um de permit ou actionType.Cada operando na lista segue um dos três formatos, e pode conter um valor de curinga *, que corresponde a qualquer valor:
- cluster=cellName/clusterName
- servidor=cellName/nodeName/serverName
- módulo=cellName/applicationName/applicationVersion/moduleName
Com apenas regras de roteamento do SIP, é possível definir alternativamente os clusters de destino através de uma expressão da regra. Os operadores válidos são AND, OR, NOT e agrupamento parentético. Formato de acordo com a seguinte lista:- cluster=cellName/clusterName
- servidor=cellName/nodeName/serverName
- módulo=cellName/applicationName/applicationVersion/moduleName
- modo de manutenção do servidor=verdadeiro ou falso
- modo de manutenção do nó=verdadeiro ou falso
- protocolo=PROTO_VALUE:
- PROTO_SIP = sip
- SIP sobre TCP
- PROTO_SIPS = sips
- SIP sobre SSL e TCP
- PROTO_SIPU = sipu
- SIP sobre UDP
- PROTO_SIPX = sipx
- SIP sobre XMEM
Nota: Para aplicativos que não tiverem nenhum valor applicationVersion, deixe o valor applicationVersion em branco: module=cellName/application//moduleName. - -errorcode : Código de erro de número inteiro para rejeitar o pedido. O parâmetro -errorcode é necessário somente se actionType for igual a reject.
- -localResource: Esta opção pode ser usada em associação com o parâmetro actionType. Se você usar a opção -localResource com o parâmetro actionType, especifique também o parâmetro localResourcePath. O parâmetro localResourcePath indica o caminho absoluto ou relativo para a raiz do perfil.
Exemplo de uso do modo em lote
- Utilizando Jacl:
$AdminTask addRoutingRule {-webservername ws1 -nodename node1 -protocol HTTP -priority 0 -expression "request.method = 'getOperation'" -actionType permit -multiclusterAction Failover -routingLocations cluster=*/*}
- Utilizando a cadeia Jython:
AdminTask.addRoutingRule('-webservername ws1 -nodename node1 -protocol HTTP -priority 0 -expression "queryparm$userid = \'123\'" -actionType permit -multiclusterAction Failover -routingLocations "module=*/*/*/*,cluster=myCell/myFailoverGSCThatPointsToAnotherCell"')
- Utilizando Jacl:
$AdminTask addRoutingRule {-odrname odr -nodename node1 -protocol HTTP -priority 0 -expression "uri LIKEIN {'/contextRoot','/contextRoot/%'}" -actionType permit -multiclusterAction Failover -routingLocations cluster=cellName/clusterName}
- Utilizando a cadeia Jython:
AdminTask.addRoutingRule('-odrname odr -nodename node1 -protocol HTTP -priority 0 -expression "uri LIKEIN (\'/contextRoot\',\'/contextRoot/%\')" -actionType permit -multiclusterAction Failover -routingLocations cluster=cellName/clusterName')
Exemplo de uso do modo interativo
- Utilizando Jacl:
$AdminTask addRoutingRule {-interactive}
- Utilizando a cadeia Jython:
AdminTask.addRoutingRule ('[-interactive]')
changeRoutingDefaultRulesAction
O comando changeRoutingDefaultRulesAction altera a ação padrão da política de roteamento para uma regra.
Parâmetros necessários
- -protocol: Especificar o nome do protocolo para associar a uma regra. (Sequência, obrigatória)
- -actionType: Especificar o tipo de ação para associar a uma
regra. (Sequência, obrigatória) A seguinte lista contém os tipos de ações a serem associadas às regras de HTTP:
- localResource: Especifica o recurso local (arquivo) a ser utilizado para esta regra de roteamento.
- permit: Permitir roteamento a servidores não em modo de manutenção.
- redirect: Redirecionar a solicitação à URL especificada pela opção redirectURL.
- reject: Rejeita o roteamento com o código de retorno especificado pela opção errorcode.
- permitsticky: Permitir roteamento a servidors não em modo de manutenção e executar afinidade ativa; isto é , a afinidade é sempre preservada mesmo quando não solicitada pelo aplicativo.
- permitMM: Permite o roteamento apenas para servidores em modo de manutenção.
- permitstickyMM: Permite o roteamento somente para servidores em modo de manutenção e executar afinidade ativa.
A seguinte lista contém os tipos de ações a serem associadas às regras de SIP:- permitir: Permitir roteamento para servidores que não estão no modo de manutenção.
- reject: Rejeita o roteamento com o código de retorno especificado pela opção errorcode.
Parâmetros Opcionais
- -odrname: Especificar o nome do ODR ao qual a classe de trabalho da política de roteamento se aplica. O parâmetro -odrname será necessário somente se você modificar um ODR ou um servidor da web.
- -webservername: Especifica o nome do servidor da web ao qual a classe de trabalho da política de roteamento se aplica.
- -nodename: Especifica o nome do nó no qual o ODR ou o servidor da web reside. O parâmetro -nodename será necessário somente se você modificar um ODR ou um servidor da web.
- -clustername : Especificar o nome do cluster ao qual a regra se aplica. O parâmetro -clustername é necessário somente se você modificar um cluster do ODR.
- -dcname: Especifica o nome do cluster dinâmico ao qual a regra se aplica. O parâmetro -dcname será necessário somente se você modificar um cluster ODR.
- -multiclusterAction: Especificar o método para rotear pedidos se
múltiplos clusters de local de roteamento corresponderem. O parâmetro -multiclusterAction se aplica a qualquer um dos tipos de ação permit e será necessário apenas se actionType for igual a permit, permitsticky, permitMM ou permitstickyMM.
- Failover: Localizar o primeiro cluster com um servidor disponível e o balanceamento de carga através do cluster. A ordem de uma lista de clusters gerada dinamicamente é indefinida.
- WRR: Balanceamento de carga Weighted Round Robin. Para a retransmissão de UDP, mantenha a afinidade.
- WLOR: Weighted Least Outstanding Request.
Boas Práticas: A recomendação é usar o valor de WLOR em vez do valor de WRR.bprac
A seguinte lista contém os valores possíveis para regras de SIP:- Failover: Localizar o primeiro cluster com um servidor disponível e o balanceamento de carga através do cluster. A ordem de uma lista de clusters gerada dinamicamente é indefinida.
- WRR: Balanceamento de carga Weighted Round Robin. Para a retransmissão de UDP, mantenha a afinidade.
- Erro: Se houver vários clusters, será emitido um erro, se forem selecionados. Um e apenas um cluster é esperado.
- -routingLocations: Especifica uma lista de locais de destino
para pedidos de rota.
O parâmetro -routingLocations será necessário apenas se actionType for igual a qualquer um dos tipos de ação permit.Cada operando na lista segue um dos três formatos, e pode conter um valor de curinga *, que corresponde a qualquer valor:
- cluster=cellName/clusterName
- servidor=cellName/nodeName/serverName
- módulo=cellName/applicationName/applicationVersion/moduleName
Com apenas regras de roteamento do SIP, é possível definir alternativamente os clusters de destino através de uma expressão da regra. Os operadores válidos são AND, OR, NOT e agrupamento parentético. Formato de acordo com a seguinte lista:- cluster=cellName/clusterName
- servidor=cellName/nodeName/serverName
- módulo=cellName/applicationName/applicationVersion/moduleName
- modo de manutenção do servidor=verdadeiro ou falso
- modo de manutenção do nó=verdadeiro ou falso
- protocolo=PROTO_VALUE:
- PROTO_SIP = sip
- SIP sobre TCP
- PROTO_SIPS = sips
- SIP sobre SSL e TCP
- PROTO_SIPU = sipu
- SIP sobre UDP
- PROTO_SIPX = sipx
- SIP sobre XMEM
Nota: Para aplicativos que não tiverem nenhum valor applicationVersion, deixe o valor applicationVersion em branco: module=cellName/application//moduleName. - -errorcode : Código de erro de número inteiro para rejeitar o pedido. O parâmetro -errorcode é necessário somente se actionType for igual a reject.
- -localResource: Esta opção pode ser usada em associação com o parâmetro actionType. Se você usar a opção -localResource com o parâmetro actionType, especifique também o parâmetro localResourcePath. O parâmetro localResourcePath indica o caminho absoluto ou relativo para a raiz do perfil.
Exemplo de uso do modo em lote
- Utilizando Jacl:
Os exemplos a seguir mostram um failover e um único cluster para o failover de cluster de servidor genérico:
$AdminTask changeRoutingDefaultRulesAction {-webservername ws1 -nodename node1 -protocol HTTP -actionType permit -multiclusterAction Failover -routingLocations cluster=*/*}
- Utilizando a cadeia Jython:
AdminTask.changeRoutingDefaultRulesAction('[-webservername ws1 -nodename node1 -protocol HTTP -actionType permit -multiclusterAction Failover -routingLocations "cluster=myCell/myPrimaryCluster,cluster=myCell/myFailoverCluster"]')
Exemplo de uso do modo interativo
- Utilizando Jacl:
$AdminTask changeRoutingDefaultRulesAction {-interactive}
- Utilizando a cadeia Jython:
AdminTask.changeRoutingDefaultRulesAction ('[-interactive]')
changeRoutingRuleAction
O comando changeRoutingRuleAction altera uma ação da política de roteamento para uma regra.
Parâmetros necessários
- -protocol: Especificar o nome do protocolo para associar a uma regra. (Sequência, obrigatória)
- -priority: Valor de número inteiro positivo representando a prioridade de uma regra. Zero é a prioridade mais alta. (Sequência, obrigatória)
Parâmetros Opcionais
- -odrname: Especificar o nome do ODR ao qual a classe de trabalho da política de roteamento se aplica. O parâmetro -odrname será necessário somente se você modificar um ODR ou um servidor da web.
- -webservername: Especifica o nome do servidor da web ao qual a classe de trabalho da política de roteamento se aplica.
- -nodename: Especifica o nome do nó no qual o ODR ou o servidor da web reside. O parâmetro -nodename será necessário somente se você modificar um ODR ou um servidor da web.
- -clustername : Especificar o nome do cluster ao qual a regra se aplica. O parâmetro -clustername é necessário somente se você modificar um cluster do ODR.
- -dcname: Especifica o nome do cluster dinâmico ao qual a regra se aplica. O parâmetro -dcname será necessário somente se você modificar um cluster ODR.
- -multiclusterAction: Especificar o método para rotear pedidos se
múltiplos clusters de local de roteamento corresponderem. O parâmetro -multiclusterAction aplica-se a qualquer actionTypes permitido e é necessário apenas se actionType for igual a permit, permitsticky, permitMM,
ou permitstickyMM.
- Failover: Localizar o primeiro cluster com um servidor disponível e o balanceamento de carga através do cluster. A ordem de uma lista de clusters gerada dinamicamente é indefinida.
- WRR: Balanceamento de carga Weighted Round Robin. Para a retransmissão de UDP, mantenha a afinidade.
- WLOR: Weighted Least Outstanding Request.
Boas Práticas: A recomendação é usar o valor de WLOR em vez do valor de WRR.bprac
A seguinte lista contém os valores possíveis para regras de SIP:- Failover: Localizar o primeiro cluster com um servidor disponível e o balanceamento de carga através do cluster. A ordem de uma lista de clusters gerada dinamicamente é indefinida.
- WRR: Balanceamento de carga Weighted Round Robin. Para a retransmissão de UDP, mantenha a afinidade.
- Erro: Se houver vários clusters, será emitido um erro, se forem selecionados. Um e apenas um cluster é esperado.
- -routingLocations: Especifica uma lista de locais de destino
para pedidos de rota.
O parâmetro -routingLocations apenas será necessário, se actionType for igual a qualquer um dos actionTypes permit.Cada operando na lista segue um dos três formatos, e pode conter um valor de curinga *, que corresponde a qualquer valor:
- cluster=cellName/clusterName
- servidor=cellName/nodeName/serverName
- módulo=cellName/applicationName/applicationVersion/moduleName
Com apenas regras de roteamento do SIP, é possível definir alternativamente os clusters de destino através de uma expressão da regra. Os operadores válidos são AND, OR, NOT e agrupamento parentético. Formato de acordo com a seguinte lista:- cluster=cellName/clusterName
- servidor=cellName/nodeName/serverName
- módulo=cellName/applicationName/applicationVersion/moduleName
- modo de manutenção do servidor=verdadeiro ou falso
- modo de manutenção do nó=verdadeiro ou falso
- protocolo=PROTO_VALUE:
- PROTO_SIP = sip
- SIP sobre TCP
- PROTO_SIPS = sips
- SIP sobre SSL e TCP
- PROTO_SIPU = sipu
- SIP sobre UDP
- PROTO_SIPX = sipx
- SIP sobre XMEM
Nota: Para aplicativos que não tiverem nenhum valor applicationVersion, deixe o valor applicationVersion em branco: module=cellName/application//moduleName. - -errorcode : Código de erro de número inteiro para rejeitar o pedido. O parâmetro -errorcode é necessário somente se actionType for igual a reject.
- -localResource: Esta opção pode ser usada em associação com o parâmetro actionType. Se você usar a opção -localResource com o parâmetro actionType, especifique também o parâmetro localResourcePath. O parâmetro localResourcePath indica o caminho absoluto ou relativo para a raiz do perfil.
Exemplo de uso do modo em lote
- Utilizando Jacl:
$AdminTask changeRoutingRuleAction {-webservername ws1 -nodename node1 -protocol HTTP -priority 0 -multiclusterAction Failover -routingLocations cluster=*/*
- Utilizando a cadeia Jython:
AdminTask.changeRoutingRuleAction('[-webservername ws1 -nodename node1 -protocol HTTP -priority 0 -multiclusterAction WRR -routingLocations "cluster=myCell/*"]')
Exemplo de uso do modo interativo
- Utilizando Jacl:
$AdminTask changeRoutingRuleAction {-interactive}
- Utilizando a cadeia Jython:
AdminTask.changeRoutingRuleAction ('[-interactive]')
changeRoutingRuleExpression
O comando changeRoutingRuleExpression altera uma expressão de regra de política de roteamento.
Parâmetros necessários
- -protocol: Especificar o nome do protocolo para associar a uma regra. (Sequência, obrigatória)
- -priority: Valor de número inteiro positivo representando a prioridade de uma regra. Zero é a prioridade mais alta. (Sequência, obrigatória)
- -expression: Especificar a expressão da regra. A expressão deve ser delimitada por aspas duplas. Para obter informações adicionais sobre como especificar os parâmetros para a expressão da regra, consulte os tópicos de operandos SIP e HTTP. (Sequência, obrigatória)
Parâmetros Opcionais
- -odrname: Especificar o nome do ODR ao qual a classe de trabalho da política de roteamento se aplica. O parâmetro -odrname será necessário somente se você modificar um ODR ou um servidor da web.
- -webservername: Especifica o nome do servidor da web ao qual a classe de trabalho da política de roteamento se aplica.
- -nodename: Especifica o nome do nó no qual o ODR ou o servidor da web reside. O parâmetro -nodename será necessário somente se você modificar um ODR ou um servidor da web.
- -clustername : Especificar o nome do cluster ao qual a regra se aplica. O parâmetro -clustername é necessário somente se você modificar um cluster do ODR.
- -dcname: Especifica o nome do cluster dinâmico ao qual a regra se aplica. O parâmetro -dcname será necessário somente se você modificar um cluster ODR.
Exemplo de uso do modo em lote
- Utilizando Jacl:
$AdminTask changeRoutingRuleExpression {-odrname odr -nodename node1 -protocol SIP -priority 0 -expression "request.method = 'getOperation0'"}
- Utilizando a cadeia Jython:
AdminTask.changeRoutingRuleExpression('[-odrname odr -nodename node1 -protocol HTTP -priority 0 -expression "queryparm$userid = \'123\'"]')
Exemplo de uso do modo interativo
- Utilizando Jacl:
$AdminTask changeRoutingRuleExpression {-interactive}
- Utilizando a cadeia Jython:
AdminTask.changeRoutingRuleExpression ('[-interactive]')
changeRoutingRulePriority
O comando changeRoutingRulePriority altera uma prioridade de regra de política de roteamento.
Parâmetros necessários
- -protocol: Especificar o nome do protocolo para associar a uma regra. (Sequência, obrigatória)
- -priority: Valor de número inteiro positivo representando a prioridade de uma regra. Zero é a prioridade mais alta. (Sequência, obrigatória)
- -expression: Especificar a expressão da regra. A expressão deve ser delimitada por aspas duplas. Para obter informações adicionais sobre como especificar os parâmetros para a expressão da regra, consulte os tópicos de operandos SIP e HTTP. (Sequência, obrigatória)
Parâmetros Opcionais
- -odrname: Especificar o nome do ODR ao qual a classe de trabalho da política de roteamento se aplica. O parâmetro -odrname será necessário somente se você modificar um ODR ou um servidor da web.
- -webservername: Especifica o nome do servidor da web ao qual a classe de trabalho da política de roteamento se aplica.
- -nodename: Especifica o nome do nó no qual o ODR ou o servidor da web reside. O parâmetro -nodename será necessário somente se você modificar um ODR ou um servidor da web.
- -clustername : Especificar o nome do cluster ao qual a regra se aplica. O parâmetro -clustername é necessário somente se você modificar um cluster do ODR.
- -dcname: Especifica o nome do cluster dinâmico ao qual a regra se aplica. O parâmetro -dcname será necessário somente se você modificar um cluster ODR.
Exemplo de uso do modo em lote
- Utilizando Jacl:
$AdminTask changeRoutingRulePriority {-odrname odr -nodename node1 -protocol SIP -priority 0 -expression "request.method = 'getOperation0'"}
- Utilizando a cadeia Jython:
AdminTask.changeRoutingRulePriority('[-odrname odr -nodename node1 -protocol HTTP -priority 1 -expression "queryparm$userid = \'123\'"]')
Exemplo de uso do modo interativo
- Utilizando Jacl:
$AdminTask changeRoutingRulePriority {-interactive}
- Utilizando a cadeia Jython:
AdminTask.changeRoutingRulePriority ('[-interactive]')
createRoutingRules
O comando createRoutingRules cria uma lista de regras de política de roteamento.
Parâmetros necessários
- -protocol: Especificar o nome do protocolo para associar a uma regra. (Sequência, obrigatória)
Parâmetros Opcionais
- -odrname: Especificar o nome do ODR ao qual a classe de trabalho da política de roteamento se aplica. O parâmetro -odrname será necessário somente se você modificar um ODR ou um servidor da web.
- -webservername: Especifica o nome do servidor da web ao qual a classe de trabalho da política de roteamento se aplica.
- -nodename: Especifica o nome do nó no qual o ODR ou o servidor da web reside. O parâmetro -nodename será necessário somente se você modificar um ODR ou um servidor da web.
- -clustername : Especificar o nome do cluster ao qual a regra se aplica. O parâmetro -clustername é necessário somente se você modificar um cluster do ODR.
- -dcname: Especifica o nome do cluster dinâmico ao qual a regra se aplica. O parâmetro -dcname será necessário somente se você modificar um cluster ODR.
Exemplo de uso do modo em lote
- Utilizando Jacl:
$AdminTask createRoutingRules {-odrname odr -nodename node1 -protocol SIP}
- Utilizando a cadeia Jython:
AdminTask.createRoutingRules('-odrname odr -nodename node1 -protocol SIP')
Exemplo de uso do modo interativo
- Utilizando Jacl:
$AdminTask createRoutingRules {-interactive}
- Utilizando a cadeia Jython:
AdminTask.createRoutingRules ('[-interactive]')
listRoutingRules
O comando listRoutingRules lista as regras de política de roteamento.
Parâmetros necessários
- -protocol: Especificar o nome do protocolo para associar a uma regra. (Sequência, obrigatória)
Parâmetros Opcionais
- -odrname: Especificar o nome do ODR ao qual a classe de trabalho da política de roteamento se aplica. O parâmetro -odrname será necessário somente se você modificar um ODR ou um servidor da web.
- -webservername: Especifica o nome do servidor da web ao qual a classe de trabalho da política de roteamento se aplica.
- -nodename: Especifica o nome do nó no qual o ODR ou o servidor da web reside. O parâmetro -nodename será necessário somente se você modificar um ODR ou um servidor da web.
- -clustername : Especificar o nome do cluster ao qual a regra se aplica. O parâmetro -clustername é necessário somente se você modificar um cluster do ODR.
- -dcname: Especifica o nome do cluster dinâmico ao qual a regra se aplica. O parâmetro -dcname será necessário somente se você modificar um cluster ODR.
Exemplo de uso do modo em lote
- Utilizando Jacl:
$AdminTask listRoutingRules {-odrname odr -nodename node1 -protocol SIP}
- Utilizando a cadeia Jython:
AdminTask.listRoutingRules('-odrname odr -nodename node1 -protocol SIP')
Exemplo de uso do modo interativo
- Utilizando Jacl:
$AdminTask listRoutingRules {-interactive}
- Utilizando a cadeia Jython:
AdminTask.listRoutingRules ('[-interactive]')
removeRoutingRule
O comando removeRoutingRule remove uma regra de política de roteamento.
Parâmetros necessários
- -protocol: Especificar o nome do protocolo para associar a uma regra. (Sequência, obrigatória)
- -priority: Valor de número inteiro positivo representando a prioridade de uma regra. Zero é a prioridade mais alta. (Sequência, obrigatória)
- -expression: Especificar a expressão da regra. A expressão deve ser delimitada por aspas duplas. Para obter informações adicionais sobre como especificar os parâmetros para a expressão da regra, consulte os tópicos de operandos SIP e HTTP. (Sequência, obrigatória)
Parâmetros Opcionais
- -odrname: Especificar o nome do ODR ao qual a classe de trabalho da política de roteamento se aplica. O parâmetro -odrname será necessário somente se você modificar um ODR ou um servidor da web.
- -webservername: Especifica o nome do servidor da web ao qual a classe de trabalho da política de roteamento se aplica.
- -nodename: Especifica o nome do nó no qual o ODR ou o servidor da web reside. O parâmetro -nodename será necessário somente se você modificar um ODR ou um servidor da web.
- -clustername : Especificar o nome do cluster ao qual a regra se aplica. O parâmetro -clustername é necessário somente se você modificar um cluster do ODR.
- -dcname: Especifica o nome do cluster dinâmico ao qual a regra se aplica. O parâmetro -dcname será necessário somente se você modificar um cluster ODR.
Exemplo de uso do modo em lote
- Utilizando Jacl:
$AdminTask removeRoutingRule {-odrname odr -nodename node1 -protocol SIP -expression "request.method = 'getOperation'"}
- Utilizando a cadeia Jython:
AdminTask.removeRoutingRule('[-odrname odr -nodename node1 -protocol HTTP -expression "queryparm$userid = \'123\'"]')
Exemplo de uso do modo interativo
- Utilizando Jacl:
$AdminTask removeRoutingRule {-interactive}
- Utilizando a cadeia Jython:
AdminTask.removeRoutingRule ('[-interactive]')