![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
![[z/OS]](../images/ngzos.gif)
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.
- 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.
addRoutingRule
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: 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
- 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"')
- 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: 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: 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]')