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

Intelligent Management : règles pour les tâches d'administration de stratégie de routage ODR

Vous pouvez utiliser des tâches d'administration pour configurer les règles HTTP ou SIP (Session Initiation Protocol) pour la stratégie de routage du routeur On Demand.

Utilisez les règles ci-après pour configurer des stratégies de routage. Il s'agit de la méthode de configuration de stratégie de routage recommandée. Vous pouvez aussi configurer des stratégies de routage multicluster pour la reprise en ligne et l'équilibrage de charge. Pour en savoir plus sur cette procédure, lisez les informations sur la configuration du routeur On Demand pour le routage multicluster de la reprise en ligne et de l'équilibrage de charge.

Les principaux avantages de l'utilisation des commandes d'administration de stratégie de routage ODR sont les suivants :
  • Vous pouvez utiliser des expressions afin d'identifier les demandes qui sont affectées par la stratégie. La méthode de routage multicluster ne permet que le filtrage par application ou par module Web d'application.
  • Vous pouvez sélectionner la cible (routingLocations) par cluster, serveur ou module Web. La méthode de routage multicluster ne permet que de sélectionner le cluster cible.
  • Vous pouvez indiquer les protocoles SIP ou HTTP dans les commandes.
Remarque : Actuellement, le protocole SIP n'est pas pris en charge pour z/OS.

addRoutingRule

La commande addRoutingRule ajoute une règle pour une stratégie de routage.
Remarque : Si une stratégie de routage multicluster est définie dans une édition d'application existante et que vous installez une nouvelle édition, vous devez créer une nouvelle stratégie de routage multicluster pour la nouvelle édition.

Paramètres obligatoires

  • -protocol : Indique le nom du protocole à associer à la règle. (Chaîne, requise)
  • -priority : Valeur sous forme d'entier positif représentant la priorité d'une règle. Zéro est la priorité la plus élevée. (Chaîne, requise)
  • -expression : Indique l'expression de règle. L'expression doit être placée entre guillemets. Pour plus d'informations sur les paramètres que vous pouvez utilisez avec l'expression de règle, voir la rubrique sur les opérandes SIP et la rubrique sur les opérandes HTTP. (Chaîne, requise)
  • -actionType : Indique le type d'action à associer à une règle. (Chaîne, obligatoire)
    La liste suivante répertorie les types d'action que vous pouvez associer aux règles HTTP :
    • localResource : indique la ressource locale (fichier) à utiliser pour cette règle de routage.
    • permit : autoriser le routage vers des serveurs qui ne sont pas en mode maintenance.
    • redirect : rediriger la demande vers l'URL indiquée par l'option redirectURL.
    • reject : rejeter le routage avec le code retour défini par l'option errorcode.
    • permitsticky : autoriser le routage vers des serveurs qui ne sont pas en mode maintenance et effectuer une affinité active, c'est-à-dire préserver l'affinité même lorsqu'elle n'est pas requise pas l'application.
    • permitMM : autoriser le routage vers les serveurs en mode maintenance.
    • permitstickyMM : autoriser le routage vers les serveurs en mode maintenance et exécuter une affinité active.
    La liste suivante répertorie les types d'action que vous pouvez associer aux règles SIP :
    • permit : autoriser le routage vers des serveurs qui ne sont pas en mode Maintenance.
    • reject : rejeter le routage avec le code retour défini par l'option errorcode.

Paramètres facultatifs

  • -odrname : Indique le nom du routeur On Demand auquel s'applique la classe de travail de stratégie de routage. Le paramètre -odrname est requis uniquement si vous modifiez un routeur ORD ou un serveur Web.
  • -webservername : Spécifie le nom du serveur Web auquel s'applique la classe de travail de stratégie de routage.
  • -nodename : spécifie le nom du noeud où se trouve le routeur ORD ou le serveur Web. Le paramètre -nodename est requis uniquement si vous modifiez un routeur ORD ou un serveur Web.
  • -clustername : Indique le nom du cluster auquel s'applique la règle. Le paramètre -clustername est requis uniquement si vous modifiez un cluster ODR.
  • -dcname: spécifie le nom du cluster dynamique auquel la règle s'applique. Le paramètre -dcname est requis uniquement si vous modifiez un cluster ODR.
  • -multiclusterAction : La méthode de routage des demandes si plusieurs clusters d'emplacement de routage correspondent. Le paramètre -multiclusterAction s'applique à toutes les actions de type permit et il est requis uniquement si le paramètre actionType a la valeur permit, permitsticky, permitMM, ou permitstickyMM.
    • Failover : Recherche le premier cluster contenant un serveur disponible et effectue un équilibrage de charge dans ce cluster. L'ordre de la liste de clusters générée de façon dynamique n'est pas défini.
    • WRR : Equilibrage de charge pondéré par permutation circulaire. Pour la retransmission UDP, l'affinité est maintenue.
    • WLOR : Demande en suspens avec pondération minimale.
      Pratiques recommandées Pratiques recommandées: Il est recommandé d'utiliser la valeur WLOR à la place de la valeur WRR.bprac
    La liste suivante répertorie les valeurs admises pour les règles SIP :
    • Failover : Recherche le premier cluster contenant un serveur disponible et effectue un équilibrage de charge dans ce cluster. L'ordre de la liste de clusters générée de façon dynamique n'est pas défini.
    • WRR : Equilibrage de charge pondéré par permutation circulaire. Pour la retransmission UDP, l'affinité est maintenue.
    • Error : Si plusieurs serveurs sont présents, la sélection d'un seul serveur renvoie une erreur. Le paramètre attend un seul cluster.
  • -routingLocations : Indique une liste d'emplacements cible vers lesquels les demandes sont acheminées. Le paramètre -routingLocations est requis uniquement si actionType est égal à n'importe lequel des paramètres permit actionType.
    Chaque opérande de la liste utilise l'un des trois formats suivants et peut contenir le caractère générique *, qui remplace n'importe quelle valeur :
    • cluster=nomCellule/nomCluster
    • serveur=nomCellule/nomNoeud/nomServeur
    • module=nomCellule/nomApplication/versionApplication/nomModule
    Pour les stratégies de routage SIP uniquement, vous pouvez également définir des clusters cible à l'aide d'une expression de règle. Les opérateurs valides sont AND, OR, NOT et les groupes entre parenthèses. La liste suivante répertorie les formats possibles :
    • cluster=nomCellule/nomCluster
    • serveur=nomCellule/nomNoeud/nomServeur
    • module=nomCellule/nomApplication/versionApplication/nomModule
    • mode maintenance du serveur = true ou false
    • mode maintenance du noeud = true ou false
    • protocole = PROTO_VALEUR :
      PROTO_SIP = sip
      SIP sur TCP
      PROTO_SIPS = sips
      SIP sur SSL et TCP
      PROTO_SIPU = sipu
      SIP sur UDP
      PROTO_SIPX = sipx
      SIP sur XMEM
    Remarque : Si applicationVersion n'est pas défini pour une application, ne définissez pas de valeur applicationVersion : module=cellName/application//moduleName.
  • -errorcode : Code d'erreur sous forme d'entier utilisé pour rejeter une demande. Le paramètre -errorcode est requis uniquement si la valeur du paramètre actionType est reject.
  • -localResource: Cette option peut être utilisée avec le paramètre actionType. Si vous utilisez l'option -localResource avec le paramètre actionType, définissez également le paramètre localResourcePath. Le paramètre localResourcePath indique le chemin absolu ou relatif de la racine de profil.

Exemple d'utilisation en mode de traitement par lots

L'exemple suivant présente le basculement de toutes les applications d'une cellule vers un cluster de serveurs génériques qui pointe vers une autre cellule :
  • A l'aide de Jacl :
    $AdminTask addRoutingRule {-webservername ws1 -nodename node1 -protocol HTTP -priority 0 -expression 
    "request.method = 'getOperation'" -actionType permit -multiclusterAction Failover 
    -routingLocations cluster=*/*}
  • Avec une chaîne Jython :
    AdminTask.addRoutingRule('-webservername ws1 -nodename node1 -protocol HTTP -priority 0 -expression 
    "queryparm$userid = \'123\'" -actionType permit -multiclusterAction Failover -routingLocations 
    "module=*/*/*/*,cluster=myCell/myFailoverGSCThatPointsToAnotherCell"') 
L'exemple suivant crée une stratégie de routage multicluster pour une nouvelle édition d'application :
  • A l'aide de Jacl :
    $AdminTask addRoutingRule {-odrname odr -nodename node1 -protocol 
    HTTP -priority 0 -expression "uri LIKEIN {'/contextRoot','/contextRoot/%'}" 
    -actionType permit -multiclusterAction Failover -routingLocations 
    cluster=cellName/clusterName}
  • Avec une chaîne Jython :
    AdminTask.addRoutingRule('-odrname odr -nodename node1 -protocol 
    HTTP -priority 0 -expression "uri LIKEIN (\'/contextRoot\',\'/contextRoot/%\')" 
    -actionType permit -multiclusterAction Failover -routingLocations 
    cluster=cellName/clusterName')

Exemple d'utilisation en mode interactif

  • A l'aide de Jacl :
    $AdminTask addRoutingRule {-interactive}
  • Avec la chaîne Jython :
    AdminTask.addRoutingRule ('[-interactive]')

changeRoutingDefaultRulesAction

La commande changeRoutingDefaultRulesAction modifie l'action par défaut de la stratégie de routage pour une règle.

Paramètres requis

  • -protocol : Indique le nom du protocole à associer à la règle. (Chaîne, requise)
  • -actionType : Indique le type d'action à associer à une règle. (Chaîne, obligatoire)
    La liste suivante répertorie les types d'action que vous pouvez associer aux règles HTTP :
    • localResource : indique la ressource locale (fichier) à utiliser pour cette règle de routage.
    • permit : autoriser le routage vers des serveurs qui ne sont pas en mode maintenance.
    • redirect : rediriger la demande vers l'URL indiquée par l'option redirectURL.
    • reject : rejeter le routage avec le code retour défini par l'option errorcode.
    • permitsticky : autoriser le routage vers des serveurs qui ne sont pas en mode maintenance et effectuer une affinité active, c'est-à-dire préserver l'affinité même lorsqu'elle n'est pas requise pas l'application.
    • permitMM : autoriser le routage vers les serveurs en mode maintenance.
    • permitstickyMM : autoriser le routage vers les serveurs en mode maintenance et exécuter une affinité active.
    La liste suivante répertorie les types d'action que vous pouvez associer aux règles SIP :
    • permit : autoriser le routage vers des serveurs qui ne sont pas en mode Maintenance.
    • reject : rejeter le routage avec le code retour défini par l'option errorcode.

Paramètres facultatifs

  • -odrname : Indique le nom du routeur On Demand auquel s'applique la classe de travail de stratégie de routage. Le paramètre -odrname est requis uniquement si vous modifiez un routeur ORD ou un serveur Web.
  • -webservername : Spécifie le nom du serveur Web auquel s'applique la classe de travail de stratégie de routage.
  • -nodename : spécifie le nom du noeud où se trouve le routeur ORD ou le serveur Web. Le paramètre -nodename est requis uniquement si vous modifiez un routeur ORD ou un serveur Web.
  • -clustername : Indique le nom du cluster auquel s'applique la règle. Le paramètre -clustername est requis uniquement si vous modifiez un cluster ODR.
  • -dcname: spécifie le nom du cluster dynamique auquel la règle s'applique. Le paramètre -dcname est requis uniquement si vous modifiez un cluster ODR.
  • -multiclusterAction : La méthode de routage des demandes si plusieurs clusters d'emplacement de routage correspondent. Le paramètre -multiclusterAction s'applique aux types d'actions autorisés et il est requis uniquement si actionType a la valeur permit, permitsticky, permitMM ou permitstickyMM.
    • Failover : Recherche le premier cluster contenant un serveur disponible et effectue un équilibrage de charge dans ce cluster. L'ordre de la liste de clusters générée de façon dynamique n'est pas défini.
    • WRR : Equilibrage de charge pondéré par permutation circulaire. Pour la retransmission UDP, l'affinité est maintenue.
    • WLOR : Demande en suspens avec pondération minimale.
      Pratiques recommandées Pratiques recommandées: Il est recommandé d'utiliser la valeur WLOR à la place de la valeur WRR.bprac
    La liste suivante répertorie les valeurs admises pour les règles SIP :
    • Failover : Recherche le premier cluster contenant un serveur disponible et effectue un équilibrage de charge dans ce cluster. L'ordre de la liste de clusters générée de façon dynamique n'est pas défini.
    • WRR : Equilibrage de charge pondéré par permutation circulaire. Pour la retransmission UDP, l'affinité est maintenue.
    • Error : Si plusieurs serveurs sont présents, la sélection d'un seul serveur renvoie une erreur. Le paramètre attend un seul cluster.
  • -routingLocations : Indique une liste d'emplacements cible vers lesquels les demandes sont acheminées. Le paramètre -routingLocations est requis uniquement si actionType correspond à un type d'action permit.
    Chaque opérande de la liste utilise l'un des trois formats suivants et peut contenir le caractère générique *, qui remplace n'importe quelle valeur :
    • cluster=nomCellule/nomCluster
    • serveur=nomCellule/nomNoeud/nomServeur
    • module=nomCellule/nomApplication/versionApplication/nomModule
    Pour les stratégies de routage SIP uniquement, vous pouvez également définir des clusters cible à l'aide d'une expression de règle. Les opérateurs valides sont AND, OR, NOT et les groupes entre parenthèses. La liste suivante répertorie les formats possibles :
    • cluster=nomCellule/nomCluster
    • serveur=nomCellule/nomNoeud/nomServeur
    • module=nomCellule/nomApplication/versionApplication/nomModule
    • mode maintenance du serveur = true ou false
    • mode maintenance du noeud = true ou false
    • protocole = PROTO_VALEUR :
      PROTO_SIP = sip
      SIP sur TCP
      PROTO_SIPS = sips
      SIP sur SSL et TCP
      PROTO_SIPU = sipu
      SIP sur UDP
      PROTO_SIPX = sipx
      SIP sur XMEM
    Remarque : Si applicationVersion n'est pas défini pour une application, ne définissez pas de valeur applicationVersion : module=cellName/application//moduleName.
  • -errorcode : Code d'erreur sous forme d'entier utilisé pour rejeter une demande. Le paramètre -errorcode est requis uniquement si la valeur du paramètre actionType est reject.
  • -localResource: Cette option peut être utilisée avec le paramètre actionType. Si vous utilisez l'option -localResource avec le paramètre actionType, définissez également le paramètre localResourcePath. Le paramètre localResourcePath indique le chemin absolu ou relatif de la racine de profil.

Exemple d'utilisation en mode de traitement par lots

  • A l'aide de Jacl :

    L'exemple suivant présente le basculement d'un cluster unique vers un cluster de serveurs génériques de basculement :

    $AdminTask changeRoutingDefaultRulesAction {-webservername ws1 -nodename node1 -protocol 
    HTTP -actionType permit -multiclusterAction Failover -routingLocations cluster=*/*}
  • A l'aide de la chaîne Jython :
    AdminTask.changeRoutingDefaultRulesAction('[-webservername ws1 -nodename node1 -protocol 
    HTTP -actionType permit -multiclusterAction Failover -routingLocations 
    "cluster=myCell/myPrimaryCluster,cluster=myCell/myFailoverCluster"]')

Exemple d'utilisation en mode interactif

  • A l'aide de Jacl :
    $AdminTask changeRoutingDefaultRulesAction {-interactive}
  • Avec la chaîne Jython :
    AdminTask.changeRoutingDefaultRulesAction ('[-interactive]')

changeRoutingRuleAction

La commande changeRoutingRuleAction modifie une action de stratégie de routage pour une règle.

Paramètres requis

  • -protocol : Indique le nom du protocole à associer à la règle. (Chaîne, requise)
  • -priority : Valeur sous forme d'entier positif représentant la priorité d'une règle. Zéro est la priorité la plus élevée. (Chaîne, requise)

Paramètres facultatifs

  • -odrname : Indique le nom du routeur On Demand auquel s'applique la classe de travail de stratégie de routage. Le paramètre -odrname est requis uniquement si vous modifiez un routeur ORD ou un serveur Web.
  • -webservername : Spécifie le nom du serveur Web auquel s'applique la classe de travail de stratégie de routage.
  • -nodename : spécifie le nom du noeud où se trouve le routeur ORD ou le serveur Web. Le paramètre -nodename est requis uniquement si vous modifiez un routeur ORD ou un serveur Web.
  • -clustername : Indique le nom du cluster auquel s'applique la règle. Le paramètre -clustername est requis uniquement si vous modifiez un cluster ODR.
  • -dcname: spécifie le nom du cluster dynamique auquel la règle s'applique. Le paramètre -dcname est requis uniquement si vous modifiez un cluster ODR.
  • -multiclusterAction : La méthode de routage des demandes si plusieurs clusters d'emplacement de routage correspondent. Le paramètre -multiclusterAction s'applique à tout actionTypes de type permit et il est requis uniquement si le paramètre actionType a la valeur permit, permitsticky, permitMM ou permitstickyMM.
    • Failover : Recherche le premier cluster contenant un serveur disponible et effectue un équilibrage de charge dans ce cluster. L'ordre de la liste de clusters générée de façon dynamique n'est pas défini.
    • WRR : Equilibrage de charge pondéré par permutation circulaire. Pour la retransmission UDP, l'affinité est maintenue.
    • WLOR : Demande en suspens avec pondération minimale.
      Pratiques recommandées Pratiques recommandées: Il est recommandé d'utiliser la valeur WLOR à la place de la valeur WRR.bprac
    La liste suivante répertorie les valeurs admises pour les règles SIP :
    • Failover : Recherche le premier cluster contenant un serveur disponible et effectue un équilibrage de charge dans ce cluster. L'ordre de la liste de clusters générée de façon dynamique n'est pas défini.
    • WRR : Equilibrage de charge pondéré par permutation circulaire. Pour la retransmission UDP, l'affinité est maintenue.
    • Error : Si plusieurs serveurs sont présents, la sélection d'un seul serveur renvoie une erreur. Le paramètre attend un seul cluster.
  • -routingLocations : Indique une liste d'emplacements cible vers lesquels les demandes sont acheminées. Le paramètre -routingLocations est requis uniquement si la valeur du paramètre actionType est une action de type permit.
    Chaque opérande de la liste utilise l'un des trois formats suivants et peut contenir le caractère générique *, qui remplace n'importe quelle valeur :
    • cluster=nomCellule/nomCluster
    • serveur=nomCellule/nomNoeud/nomServeur
    • module=nomCellule/nomApplication/versionApplication/nomModule
    Pour les stratégies de routage SIP uniquement, vous pouvez également définir des clusters cible à l'aide d'une expression de règle. Les opérateurs valides sont AND, OR, NOT et les groupes entre parenthèses. La liste suivante répertorie les formats possibles :
    • cluster=nomCellule/nomCluster
    • serveur=nomCellule/nomNoeud/nomServeur
    • module=nomCellule/nomApplication/versionApplication/nomModule
    • mode maintenance du serveur = true ou false
    • mode maintenance du noeud = true ou false
    • protocole = PROTO_VALEUR :
      PROTO_SIP = sip
      SIP sur TCP
      PROTO_SIPS = sips
      SIP sur SSL et TCP
      PROTO_SIPU = sipu
      SIP sur UDP
      PROTO_SIPX = sipx
      SIP sur XMEM
    Remarque : Si applicationVersion n'est pas défini pour une application, ne définissez pas de valeur applicationVersion : module=cellName/application//moduleName.
  • -errorcode : Code d'erreur sous forme d'entier utilisé pour rejeter une demande. Le paramètre -errorcode est requis uniquement si la valeur du paramètre actionType est reject.
  • -localResource: Cette option peut être utilisée avec le paramètre actionType. Si vous utilisez l'option -localResource avec le paramètre actionType, définissez également le paramètre localResourcePath. Le paramètre localResourcePath indique le chemin absolu ou relatif de la racine de profil.

Exemple d'utilisation en mode de traitement par lots

  • A l'aide de Jacl :
     $AdminTask changeRoutingRuleAction {-webservername ws1 -nodename node1 -protocol 
       HTTP -priority 0 -multiclusterAction Failover -routingLocations cluster=*/*
  • A l'aide de la chaîne Jython :
    AdminTask.changeRoutingRuleAction('[-webservername ws1 -nodename node1 -protocol 
    HTTP -priority 0 -multiclusterAction WRR -routingLocations "cluster=myCell/*"]')

Exemple d'utilisation en mode interactif

  • A l'aide de Jacl :
    $AdminTask changeRoutingRuleAction {-interactive}
  • Avec la chaîne Jython :
    AdminTask.changeRoutingRuleAction ('[-interactive]')

changeRoutingRuleExpression

La commande changeRoutingRuleExpression modifie une expression de règle pour une stratégie de routage.

Paramètres requis

  • -protocol : Indique le nom du protocole à associer à la règle. (Chaîne, requise)
  • -priority : Valeur sous forme d'entier positif représentant la priorité d'une règle. Zéro est la priorité la plus élevée. (Chaîne, requise)
  • -expression : Indique l'expression de règle. L'expression doit être placée entre guillemets. Pour plus d'informations sur les paramètres que vous pouvez utilisez avec l'expression de règle, voir la rubrique sur les opérandes SIP et la rubrique sur les opérandes HTTP. (Chaîne, requise)

Paramètres facultatifs

  • -odrname : Indique le nom du routeur On Demand auquel s'applique la classe de travail de stratégie de routage. Le paramètre -odrname est requis uniquement si vous modifiez un routeur ORD ou un serveur Web.
  • -webservername : Spécifie le nom du serveur Web auquel s'applique la classe de travail de stratégie de routage.
  • -nodename : spécifie le nom du noeud où se trouve le routeur ORD ou le serveur Web. Le paramètre -nodename est requis uniquement si vous modifiez un routeur ORD ou un serveur Web.
  • -clustername : Indique le nom du cluster auquel s'applique la règle. Le paramètre -clustername est requis uniquement si vous modifiez un cluster ODR.
  • -dcname: spécifie le nom du cluster dynamique auquel la règle s'applique. Le paramètre -dcname est requis uniquement si vous modifiez un cluster ODR.

Exemple d'utilisation en mode de traitement par lots

  • A l'aide de Jacl :
    $AdminTask changeRoutingRuleExpression {-odrname odr -nodename noeud1 -protocol SIP -priority 0 -expression "request.method = 'getOperation0'"}
  • A l'aide de la chaîne Jython :
    AdminTask.changeRoutingRuleExpression('[-odrname odr -nodename node1 -protocol 
    HTTP -priority 0 -expression "queryparm$userid = \'123\'"]')

Exemple d'utilisation en mode interactif

  • A l'aide de Jacl :
    $AdminTask changeRoutingRuleExpression {-interactive}
  • Avec la chaîne Jython :
    AdminTask.changeRoutingRuleExpression ('[-interactive]')

changeRoutingRulePriority

La commande changeRoutingRulePriority modifie la priorité d'une règle pour une stratégie de routage.

Paramètres requis

  • -protocol : Indique le nom du protocole à associer à la règle. (Chaîne, requise)
  • -priority : Valeur sous forme d'entier positif représentant la priorité d'une règle. Zéro est la priorité la plus élevée. (Chaîne, requise)
  • -expression : Indique l'expression de règle. L'expression doit être placée entre guillemets. Pour plus d'informations sur les paramètres que vous pouvez utilisez avec l'expression de règle, voir la rubrique sur les opérandes SIP et la rubrique sur les opérandes HTTP. (Chaîne, requise)

Paramètres facultatifs

  • -odrname : Indique le nom du routeur On Demand auquel s'applique la classe de travail de stratégie de routage. Le paramètre -odrname est requis uniquement si vous modifiez un routeur ORD ou un serveur Web.
  • -webservername : Spécifie le nom du serveur Web auquel s'applique la classe de travail de stratégie de routage.
  • -nodename : spécifie le nom du noeud où se trouve le routeur ORD ou le serveur Web. Le paramètre -nodename est requis uniquement si vous modifiez un routeur ORD ou un serveur Web.
  • -clustername : Indique le nom du cluster auquel s'applique la règle. Le paramètre -clustername est requis uniquement si vous modifiez un cluster ODR.
  • -dcname: spécifie le nom du cluster dynamique auquel la règle s'applique. Le paramètre -dcname est requis uniquement si vous modifiez un cluster ODR.

Exemple d'utilisation en mode de traitement par lots

  • A l'aide de Jacl :
    $AdminTask changeRoutingRulePriority {-odrname odr -nodename noeud1 -protocol SIP -priority 0 -expression "request.method = 'getOperation0'"}
  • A l'aide de la chaîne Jython :
    AdminTask.changeRoutingRulePriority('[-odrname odr -nodename node1 -protocol 
    HTTP -priority 1 -expression "queryparm$userid = \'123\'"]')

Exemple d'utilisation en mode interactif

  • A l'aide de Jacl :
    $AdminTask changeRoutingRulePriority {-interactive}
  • Avec la chaîne Jython :
    AdminTask.changeRoutingRulePriority ('[-interactive]')

createRoutingRules

La commande createRoutingRules crée une liste de règles pour les stratégies de routage.

Paramètres requis

  • -protocol : Indique le nom du protocole à associer à la règle. (Chaîne, requise)

Paramètres facultatifs

  • -odrname : Indique le nom du routeur On Demand auquel s'applique la classe de travail de stratégie de routage. Le paramètre -odrname est requis uniquement si vous modifiez un routeur ORD ou un serveur Web.
  • -webservername : Spécifie le nom du serveur Web auquel s'applique la classe de travail de stratégie de routage.
  • -nodename : spécifie le nom du noeud où se trouve le routeur ORD ou le serveur Web. Le paramètre -nodename est requis uniquement si vous modifiez un routeur ORD ou un serveur Web.
  • -clustername : Indique le nom du cluster auquel s'applique la règle. Le paramètre -clustername est requis uniquement si vous modifiez un cluster ODR.
  • -dcname: spécifie le nom du cluster dynamique auquel la règle s'applique. Le paramètre -dcname est requis uniquement si vous modifiez un cluster ODR.

Exemple d'utilisation en mode de traitement par lots

  • A l'aide de Jacl :
    $AdminTask createRoutingRules {-odrname odr -nodename noeud1 -protocol SIP}
  • A l'aide de la chaîne Jython :
    AdminTask.createRoutingRules('-odrname odr -nodename noeud1 -protocol SIP')

Exemple d'utilisation en mode interactif

  • A l'aide de Jacl :
    $AdminTask createRoutingRules {-interactive}
  • Avec la chaîne Jython :
    AdminTask.createRoutingRules ('[-interactive]')

listRoutingRules

La commande listRoutingRules affiche la liste des règles de stratégie de routage.

Paramètres requis

  • -protocol : Indique le nom du protocole à associer à la règle. (Chaîne, requise)

Paramètres facultatifs

  • -odrname : Indique le nom du routeur On Demand auquel s'applique la classe de travail de stratégie de routage. Le paramètre -odrname est requis uniquement si vous modifiez un routeur ORD ou un serveur Web.
  • -webservername : Spécifie le nom du serveur Web auquel s'applique la classe de travail de stratégie de routage.
  • -nodename : spécifie le nom du noeud où se trouve le routeur ORD ou le serveur Web. Le paramètre -nodename est requis uniquement si vous modifiez un routeur ORD ou un serveur Web.
  • -clustername : Indique le nom du cluster auquel s'applique la règle. Le paramètre -clustername est requis uniquement si vous modifiez un cluster ODR.
  • -dcname: spécifie le nom du cluster dynamique auquel la règle s'applique. Le paramètre -dcname est requis uniquement si vous modifiez un cluster ODR.

Exemple d'utilisation en mode de traitement par lots

  • A l'aide de Jacl :
    $AdminTask listRoutingRules {-odrname odr -nodename noeud1 -protocol SIP} 
  • A l'aide de la chaîne Jython :
    AdminTask.listRoutingRules('-odrname odr -nodename noeud1 -protocol SIP')

Exemple d'utilisation en mode interactif

  • A l'aide de Jacl :
    $AdminTask listRoutingRules {-interactive}
  • Avec la chaîne Jython :
    AdminTask.listRoutingRules ('[-interactive]')

removeRoutingRule

La commande removeRoutingRule supprime une règle de stratégie de routage.

Paramètres requis

  • -protocol : Indique le nom du protocole à associer à la règle. (Chaîne, requise)
  • -priority : Valeur sous forme d'entier positif représentant la priorité d'une règle. Zéro est la priorité la plus élevée. (Chaîne, requise)
  • -expression : Indique l'expression de règle. L'expression doit être placée entre guillemets. Pour plus d'informations sur les paramètres que vous pouvez utilisez avec l'expression de règle, voir la rubrique sur les opérandes SIP et la rubrique sur les opérandes HTTP. (Chaîne, requise)

Paramètres facultatifs

  • -odrname : Indique le nom du routeur On Demand auquel s'applique la classe de travail de stratégie de routage. Le paramètre -odrname est requis uniquement si vous modifiez un routeur ORD ou un serveur Web.
  • -webservername : Spécifie le nom du serveur Web auquel s'applique la classe de travail de stratégie de routage.
  • -nodename : spécifie le nom du noeud où se trouve le routeur ORD ou le serveur Web. Le paramètre -nodename est requis uniquement si vous modifiez un routeur ORD ou un serveur Web.
  • -clustername : Indique le nom du cluster auquel s'applique la règle. Le paramètre -clustername est requis uniquement si vous modifiez un cluster ODR.
  • -dcname: spécifie le nom du cluster dynamique auquel la règle s'applique. Le paramètre -dcname est requis uniquement si vous modifiez un cluster ODR.

Exemple d'utilisation en mode de traitement par lots

  • A l'aide de Jacl :
    $AdminTask removeRoutingRule {-odrname odr -nodename noeud1 -protocol SIP -expression 
    "request.method = 'getOperation'"}
  • A l'aide de la chaîne Jython :
    AdminTask.removeRoutingRule('[-odrname odr -nodename node1 -protocol HTTP -expression 
    "queryparm$userid = \'123\'"]')

Exemple d'utilisation en mode interactif

  • A l'aide de Jacl :
    $AdminTask removeRoutingRule {-interactive}
  • Avec la chaîne Jython :
    AdminTask.removeRoutingRule ('[-interactive]')

Icône indiquant le type de rubrique Rubrique de référence



Icône d'horodatage Dernière mise à jour: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=rwve_xdhttprules
Nom du fichier : rwve_xdhttprules.html