[AIX Solaris HP-UX Linux Windows][z/OS]

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.

Os principais benefícios de usar os comandos administrativos da política de roteamento do ODR são:
  • É 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.
Nota: O Protocolo de Inicialização de Sessão (SIP) não é suportado atualmente para z/OS.

addRoutingRule

O comando addRoutingRule inclui uma regra de política de roteamento.
Nota: Se você tiver uma edição de aplicativo existente com uma política de roteamento de múltiplos clusters definida e instalar uma nova edição, crie uma nova política de roteamento de múltiplos clusters para a nova edição.

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

O exemplo a seguir mostra um failover de todos os aplicativos em uma célula para um cluster de servidor genérico que aponta para outra célula:
  • 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"') 
O exemplo a seguir cria uma política de roteamento com múltiplos clusters para uma nova edição do aplicativo:
  • 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 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 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]')

Ícone que indica o tipo de tópico Tópico de Referência



Ícone de registro de data e hora Última atualização: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=rwve_xdhttprules
Nome do arquivo: rwve_xdhttprules.html