![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
![[z/OS]](../images/ngzos.gif)
Intelligent Management: reglas para tareas administrativas de políticas de direccionamiento de ODR
Puede utilizar tareas administrativas para configurar reglas HTTP o Session Initiation Protocol (SIP) para la política de direccionamiento del direccionador On Demand (ODR).
Utilice las reglas siguientes para configurar políticas de direccionamiento. Estas reglas son el método preferido para la configuración de políticas de direccionamiento. También puede configurar políticas de direccionamiento de varios clústeres para migración tras error y equilibrio de carga. Para obtener más información sobre este procedimiento, lea los temas de configuración del direccionador On demand para el direccionamiento de varios clústeres para migración tras error y equilibrio de carga.
- Puede utilizar expresiones para determinar a qué solicitudes afecta la política. El método de direccionamiento de varios clústeres sólo permite filtrar por aplicación o por módulo web de aplicación.
- Puede seleccionar el destino (routingLocations) por clúster, servidor o por módulo web. El método de direccionamiento de varios clústeres sólo le permite seleccionar el clúster de destino.
- Puede especificar protocolos SIP o HTTP en los mandatos.
addRoutingRule
Parámetros necesarios
- -protocol: especifica el nombre del protocolo que asociar a una regla. (String, obligatorio)
- -priority: el valor entero positivo que representa la prioridad de una regla. Cero es la prioridad máxima. (String, obligatorio)
- -expression: especifica la expresión de regla. La expresión se debe especificar entre comillas. Para obtener más información sobre la especificación de parámetros para la expresión de regla, consulte el tema de operandos SIP y el tema de operandos HTTP. (String, obligatorio)
- -actionType: especifica el tipo de acción que asociar a una regla.
(String, obligatorio)
La siguiente lista contiene los tipos de acciones que se van a asociar a reglas HTTP:
- localResource: especifica el recurso local (archivo) que se debe utilizar para esta regla de direccionamiento.
- permit: permitir el direccionamiento a servidores que no están en la modalidad de mantenimiento.
- redirect: redirigir la solicitud al URL especificado por la opción redirectURL.
- reject: rechazar el direccionamiento con el código de retorno especificado por la opción errorcode.
- permitsticky: permitir el direccionamiento a servidores que no están en la modalidad de mantenimiento y realizar la afinidad activa; es decir, la afinidad siempre se mantiene aunque no lo solicite la aplicación.
- permitMM: permitir el direccionamiento a servidores en modalidad de mantenimiento.
- permitstickyMM: permitir el direccionamiento a servidores en modalidad de mantenimiento y realizar la afinidad activa.
La siguiente lista contiene los tipos de acciones que se van a asociar a reglas SIP:- permit: permitir el direccionamiento a servidores que no están en modalidad de mantenimiento.
- reject: rechazar el direccionamiento con el código de retorno especificado por la opción errorcode.
Parámetros opcionales
- -odrname: especifica el nombre del ODR en el que se aplica la clase de trabajo de la política de direccionamiento. El parámetro -odrname sólo es necesario si modifica un ODR o un servidor web.
- -webservername: especifica el nombre del servidor web en el que se aplica la clase de trabajo de la política de direccionamiento.
- -nodename: especifica el nombre del nodo en el que reside el ODR o el servidor web. El parámetro -nodename sólo es necesario si modifica un ODR o un servidor web.
- -clustername: especifica el nombre del clúster al que se aplica la regla. El parámetro -clustername sólo es necesario si modifica un clúster de ODR.
- -dcname: especifica el nombre del clúster dinámico al que se aplica la regla. El parámetro -dcname sólo es necesario si modifica un clúster de ODR.
- -multiclusterAction: especifica el método para direccionar las solicitudes si coinciden varios clústeres de direccionamiento.
El parámetro -multiclusterAction se aplica a todos los actionTypes permitidos (permit) y sólo es necesario si actionType es igual a permit, permitsticky, permitMM o permitstickyMM.
- Failover: buscar el primer clúster con un servidor disponible y equilibrar la carga en todo ese clúster. El orden de una lista de clústeres generada dinámicamente no se ha definido.
- WRR: equilibrio de carga circular ponderada. Para la retransmisión de UDP, mantener la afinidad.
- WLOR: solicitud pendiente mínima ponderada.
Best practice: La recomendación es utilizar el valor WLOR en lugar del valor WRR.bprac
La siguiente lista contiene los valores posibles para las reglas SIP:- Failover: buscar el primer clúster con un servidor disponible y equilibrar la carga en todo ese clúster. El orden de una lista de clústeres generada dinámicamente no se ha definido.
- WRR: equilibrio de carga circular ponderada. Para la retransmisión de UDP, mantener la afinidad.
- Error: si hay varios clústeres entre los que seleccionar, se genera un error. Espera que haya un único clúster.
- -routingLocations: especifica una lista de ubicaciones de destino para direccionar solicitudes.
El parámetro -routingLocations sólo es necesario si
actionType es igual a cualquiera de los
permit actionType.
Cada operando de la lista sigue uno de tres mandatos y puede incluir un valor comodín *, que coincide con cualquier valor:
- cluster=cellName/clusterName
- server=cellName/nodeName/serverName
- module=cellName/applicationName/applicationVersion/moduleName
Sólo con las reglas de direccionamiento SIP puede definir de forma alternativa clústeres de destino mediante una expresión de reglas. Los operadores válidos son AND, OR, NOT y la agrupación de paréntesis. Formatee de acuerdo con la siguiente lista:- cluster=cellName/clusterName
- server=cellName/nodeName/serverName
- module=cellName/applicationName/applicationVersion/moduleName
- server maintenance mode=true or false
- node maintenance mode=true or false
- protocol=PROTO_VALUE:
- PROTO_SIP = sip
- SIP sobre TCP
- PROTO_SIPS = sips
- SIP sobre SSL y TCP
- PROTO_SIPU = sipu
- SIP sobre UDP
- PROTO_SIPX = sipx
- SIP sobre XMEM
Nota: Para las aplicaciones que no tienen el valor applicationVersion, deje el valor de applicationVersion en blanco: module=cellName/application//moduleName. - -errorcode: código de error entero para rechazar la solicitud. El parámetro -errorcode sólo es necesario si actionType es igual a reject.
- -localResource: esta opción se puede utilizar junto con el parámetro actionType. Si utiliza la opción -localResource con el parámetro actionType, debe especificar además el parámetro localResourcePath. El parámetro localResourcePath indica la vía de acceso relativa o absoluta a la raíz del perfil.
Ejemplo de uso de la modalidad de proceso por lotes
- En Jacl:
$AdminTask addRoutingRule {-webservername ws1 -nodename node1 -protocol HTTP -priority 0 -expression "request.method = 'getOperation'" -actionType permit -multiclusterAction Failover -routingLocations cluster=*/*}
- Utilizando la serie Jython:
AdminTask.addRoutingRule('-webservername ws1 -nodename node1 -protocol HTTP -priority 0 -expression "queryparm$userid = \'123\'" -actionType permit -multiclusterAction Failover -routingLocations "module=*/*/*/*,cluster=myCell/myFailoverGSCThatPointsToAnotherCell"')
- En 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 la serie Jython:
AdminTask.addRoutingRule('-odrname odr -nodename node1 -protocol HTTP -priority 0 -expression "uri LIKEIN (\'/contextRoot\',\'/contextRoot/%\')" -actionType permit -multiclusterAction Failover -routingLocations cluster=cellName/clusterName')
Ejemplo de utilización de la modalidad interactiva
- En Jacl:
$AdminTask addRoutingRule {-interactive}
- Utilizando la serie Jython:
AdminTask.addRoutingRule ('[-interactive]')
changeRoutingDefaultRulesAction
El mandato changeRoutingDefaultRulesAction cambia la acción predeterminada de la política de direccionamiento para una regla.
Parámetros necesarios
- -protocol: especifica el nombre del protocolo que asociar a una regla. (String, obligatorio)
- -actionType: especifica el tipo de acción que asociar a una regla.
(String, obligatorio)
La siguiente lista contiene los tipos de acciones que se van a asociar a reglas HTTP:
- localResource: especifica el recurso local (archivo) que se debe utilizar para esta regla de direccionamiento.
- permit: permitir el direccionamiento a servidores que no están en la modalidad de mantenimiento.
- redirect: redirigir la solicitud al URL especificado por la opción redirectURL.
- reject: rechazar el direccionamiento con el código de retorno especificado por la opción errorcode.
- permitsticky: permitir el direccionamiento a servidores que no están en la modalidad de mantenimiento y realizar la afinidad activa; es decir, la afinidad siempre se mantiene aunque no lo solicite la aplicación.
- permitMM: permitir el direccionamiento a servidores en modalidad de mantenimiento.
- permitstickyMM: permitir el direccionamiento a servidores en modalidad de mantenimiento y realizar la afinidad activa.
La siguiente lista contiene los tipos de acciones que se van a asociar a reglas SIP:- permit: permitir el direccionamiento a servidores que no están en modalidad de mantenimiento.
- reject: rechazar el direccionamiento con el código de retorno especificado por la opción errorcode.
Parámetros opcionales
- -odrname: especifica el nombre del ODR en el que se aplica la clase de trabajo de la política de direccionamiento. El parámetro -odrname sólo es necesario si modifica un ODR o un servidor web.
- -webservername: especifica el nombre del servidor web en el que se aplica la clase de trabajo de la política de direccionamiento.
- -nodename: especifica el nombre del nodo en el que reside el ODR o el servidor web. El parámetro -nodename sólo es necesario si modifica un ODR o un servidor web.
- -clustername: especifica el nombre del clúster al que se aplica la regla. El parámetro -clustername sólo es necesario si modifica un clúster de ODR.
- -dcname: especifica el nombre del clúster dinámico al que se aplica la regla. El parámetro -dcname sólo es necesario si modifica un clúster de ODR.
- -multiclusterAction: especifica el método para direccionar las solicitudes si coinciden varios clústeres de direccionamiento. El parámetro -multiclusterAction se aplica a todos los tipos de acción permitidos y sólo es necesario si actionType es igual a permit, permitsticky, permitMM o permitstickyMM.
- Failover: buscar el primer clúster con un servidor disponible y equilibrar la carga en todo ese clúster. El orden de una lista de clústeres generada dinámicamente no se ha definido.
- WRR: equilibrio de carga circular ponderada. Para la retransmisión de UDP, mantener la afinidad.
- WLOR: solicitud pendiente mínima ponderada.
Best practice: La recomendación es utilizar el valor WLOR en lugar del valor WRR.bprac
La siguiente lista contiene los valores posibles para las reglas SIP:- Failover: buscar el primer clúster con un servidor disponible y equilibrar la carga en todo ese clúster. El orden de una lista de clústeres generada dinámicamente no se ha definido.
- WRR: equilibrio de carga circular ponderada. Para la retransmisión de UDP, mantener la afinidad.
- Error: si hay varios clústeres entre los que seleccionar, se genera un error. Espera que haya un único clúster.
- -routingLocations: especifica una lista de ubicaciones de destino para direccionar solicitudes.
El parámetro -routingLocations sólo es necesario si
actionType es igual a cualquiera de los tipos de acción permit
Cada operando de la lista sigue uno de tres mandatos y puede incluir un valor comodín *, que coincide con cualquier valor:
- cluster=cellName/clusterName
- server=cellName/nodeName/serverName
- module=cellName/applicationName/applicationVersion/moduleName
Sólo con las reglas de direccionamiento SIP puede definir de forma alternativa clústeres de destino mediante una expresión de reglas. Los operadores válidos son AND, OR, NOT y la agrupación de paréntesis. Formatee de acuerdo con la siguiente lista:- cluster=cellName/clusterName
- server=cellName/nodeName/serverName
- module=cellName/applicationName/applicationVersion/moduleName
- server maintenance mode=true or false
- node maintenance mode=true or false
- protocol=PROTO_VALUE:
- PROTO_SIP = sip
- SIP sobre TCP
- PROTO_SIPS = sips
- SIP sobre SSL y TCP
- PROTO_SIPU = sipu
- SIP sobre UDP
- PROTO_SIPX = sipx
- SIP sobre XMEM
Nota: Para las aplicaciones que no tienen el valor applicationVersion, deje el valor de applicationVersion en blanco: module=cellName/application//moduleName. - -errorcode: código de error entero para rechazar la solicitud. El parámetro -errorcode sólo es necesario si actionType es igual a reject.
- -localResource: esta opción se puede utilizar junto con el parámetro actionType. Si utiliza la opción -localResource con el parámetro actionType, debe especificar además el parámetro localResourcePath. El parámetro localResourcePath indica la vía de acceso relativa o absoluta a la raíz del perfil.
Ejemplo de uso de la modalidad de proceso por lotes
- En Jacl:
Los ejemplos siguientes muestran una migración tras error de un solo clúster al clúster de servidores genéricos de migración tras error.
$AdminTask changeRoutingDefaultRulesAction {-webservername ws1 -nodename node1 -protocol HTTP -actionType permit -multiclusterAction Failover -routingLocations cluster=*/*}
- Utilizando la serie Jython:
AdminTask.changeRoutingDefaultRulesAction('[-webservername ws1 -nodename node1 -protocol HTTP -actionType permit -multiclusterAction Failover -routingLocations "cluster=myCell/myPrimaryCluster,cluster=myCell/myFailoverCluster"]')
Ejemplo de utilización de la modalidad interactiva
- En Jacl:
$AdminTask changeRoutingDefaultRulesAction {-interactive}
- Utilizando la serie Jython:
AdminTask.changeRoutingDefaultRulesAction ('[-interactive]')
changeRoutingRuleAction
El mandato changeRoutingRuleAction cambia una acción de política de direccionamiento para una regla.
Parámetros necesarios
- -protocol: especifica el nombre del protocolo que asociar a una regla. (String, obligatorio)
- -priority: el valor entero positivo que representa la prioridad de una regla. Cero es la prioridad máxima. (String, obligatorio)
Parámetros opcionales
- -odrname: especifica el nombre del ODR en el que se aplica la clase de trabajo de la política de direccionamiento. El parámetro -odrname sólo es necesario si modifica un ODR o un servidor web.
- -webservername: especifica el nombre del servidor web en el que se aplica la clase de trabajo de la política de direccionamiento.
- -nodename: especifica el nombre del nodo en el que reside el ODR o el servidor web. El parámetro -nodename sólo es necesario si modifica un ODR o un servidor web.
- -clustername: especifica el nombre del clúster al que se aplica la regla. El parámetro -clustername sólo es necesario si modifica un clúster de ODR.
- -dcname: especifica el nombre del clúster dinámico al que se aplica la regla. El parámetro -dcname sólo es necesario si modifica un clúster de ODR.
- -multiclusterAction: especifica el método para direccionar las solicitudes si coinciden varios clústeres de direccionamiento. El parámetro -multiclusterAction se aplica a todos los actionTypes permitidos (permit) y sólo es necesario si actionType es igual a permit, permitsticky, permitMM o permitstickyMM.
- Failover: buscar el primer clúster con un servidor disponible y equilibrar la carga en todo ese clúster. El orden de una lista de clústeres generada dinámicamente no se ha definido.
- WRR: equilibrio de carga circular ponderada. Para la retransmisión de UDP, mantener la afinidad.
- WLOR: solicitud pendiente mínima ponderada.
Best practice: La recomendación es utilizar el valor WLOR en lugar del valor WRR.bprac
La siguiente lista contiene los valores posibles para las reglas SIP:- Failover: buscar el primer clúster con un servidor disponible y equilibrar la carga en todo ese clúster. El orden de una lista de clústeres generada dinámicamente no se ha definido.
- WRR: equilibrio de carga circular ponderada. Para la retransmisión de UDP, mantener la afinidad.
- Error: si hay varios clústeres entre los que seleccionar, se genera un error. Espera que haya un único clúster.
- -routingLocations: especifica una lista de ubicaciones de destino para direccionar solicitudes.
El parámetro -routingLocations sólo es necesario si
actionType es igual a cualquiera de los tipos de acción permit
Cada operando de la lista sigue uno de tres mandatos y puede incluir un valor comodín *, que coincide con cualquier valor:
- cluster=cellName/clusterName
- server=cellName/nodeName/serverName
- module=cellName/applicationName/applicationVersion/moduleName
Sólo con las reglas de direccionamiento SIP puede definir de forma alternativa clústeres de destino mediante una expresión de reglas. Los operadores válidos son AND, OR, NOT y la agrupación de paréntesis. Formatee de acuerdo con la siguiente lista:- cluster=cellName/clusterName
- server=cellName/nodeName/serverName
- module=cellName/applicationName/applicationVersion/moduleName
- server maintenance mode=true or false
- node maintenance mode=true or false
- protocol=PROTO_VALUE:
- PROTO_SIP = sip
- SIP sobre TCP
- PROTO_SIPS = sips
- SIP sobre SSL y TCP
- PROTO_SIPU = sipu
- SIP sobre UDP
- PROTO_SIPX = sipx
- SIP sobre XMEM
Nota: Para las aplicaciones que no tienen el valor applicationVersion, deje el valor de applicationVersion en blanco: module=cellName/application//moduleName. - -errorcode: código de error entero para rechazar la solicitud. El parámetro -errorcode sólo es necesario si actionType es igual a reject.
- -localResource: esta opción se puede utilizar junto con el parámetro actionType. Si utiliza la opción -localResource con el parámetro actionType, debe especificar además el parámetro localResourcePath. El parámetro localResourcePath indica la vía de acceso relativa o absoluta a la raíz del perfil.
Ejemplo de uso de la modalidad de proceso por lotes
- En Jacl:
$AdminTask changeRoutingRuleAction {-webservername ws1 -nodename node1 -protocol HTTP -priority 0 -multiclusterAction Failover -routingLocations cluster=*/*
- Utilizando la serie Jython:
AdminTask.changeRoutingRuleAction('[-webservername ws1 -nodename node1 -protocol HTTP -priority 0 -multiclusterAction WRR -routingLocations "cluster=myCell/*"]')
Ejemplo de utilización de la modalidad interactiva
- En Jacl:
$AdminTask changeRoutingRuleAction {-interactive}
- Utilizando la serie Jython:
AdminTask.changeRoutingRuleAction ('[-interactive]')
changeRoutingRuleExpression
El mandato changeRoutingRuleExpression cambia una expresión de regla de política de direccionamiento.
Parámetros necesarios
- -protocol: especifica el nombre del protocolo que asociar a una regla. (String, obligatorio)
- -priority: el valor entero positivo que representa la prioridad de una regla. Cero es la prioridad máxima. (String, obligatorio)
- -expression: especifica la expresión de regla. La expresión se debe especificar entre comillas. Para obtener más información sobre la especificación de parámetros para la expresión de regla, consulte el tema de operandos SIP y el tema de operandos HTTP. (String, obligatorio)
Parámetros opcionales
- -odrname: especifica el nombre del ODR en el que se aplica la clase de trabajo de la política de direccionamiento. El parámetro -odrname sólo es necesario si modifica un ODR o un servidor web.
- -webservername: especifica el nombre del servidor web en el que se aplica la clase de trabajo de la política de direccionamiento.
- -nodename: especifica el nombre del nodo en el que reside el ODR o el servidor web. El parámetro -nodename sólo es necesario si modifica un ODR o un servidor web.
- -clustername: especifica el nombre del clúster al que se aplica la regla. El parámetro -clustername sólo es necesario si modifica un clúster de ODR.
- -dcname: especifica el nombre del clúster dinámico al que se aplica la regla. El parámetro -dcname sólo es necesario si modifica un clúster de ODR.
Ejemplo de uso de la modalidad de proceso por lotes
- En Jacl:
$AdminTask changeRoutingRuleExpression {-odrname odr -nodename node1 -protocol SIP -priority 0 -expression "request.method = 'getOperation0'"}
- Utilizando la serie Jython:
AdminTask.changeRoutingRuleExpression('[-odrname odr -nodename node1 -protocol HTTP -priority 0 -expression "queryparm$userid = \'123\'"]')
Ejemplo de utilización de la modalidad interactiva
- En Jacl:
$AdminTask changeRoutingRuleExpression {-interactive}
- Utilizando la serie Jython:
AdminTask.changeRoutingRuleExpression ('[-interactive]')
changeRoutingRulePriority
El mandato changeRoutingRulePriority cambia una prioridad de regla de política de direccionamiento.
Parámetros necesarios
- -protocol: especifica el nombre del protocolo que asociar a una regla. (String, obligatorio)
- -priority: el valor entero positivo que representa la prioridad de una regla. Cero es la prioridad máxima. (String, obligatorio)
- -expression: especifica la expresión de regla. La expresión se debe especificar entre comillas. Para obtener más información sobre la especificación de parámetros para la expresión de regla, consulte el tema de operandos SIP y el tema de operandos HTTP. (String, obligatorio)
Parámetros opcionales
- -odrname: especifica el nombre del ODR en el que se aplica la clase de trabajo de la política de direccionamiento. El parámetro -odrname sólo es necesario si modifica un ODR o un servidor web.
- -webservername: especifica el nombre del servidor web en el que se aplica la clase de trabajo de la política de direccionamiento.
- -nodename: especifica el nombre del nodo en el que reside el ODR o el servidor web. El parámetro -nodename sólo es necesario si modifica un ODR o un servidor web.
- -clustername: especifica el nombre del clúster al que se aplica la regla. El parámetro -clustername sólo es necesario si modifica un clúster de ODR.
- -dcname: especifica el nombre del clúster dinámico al que se aplica la regla. El parámetro -dcname sólo es necesario si modifica un clúster de ODR.
Ejemplo de uso de la modalidad de proceso por lotes
- En Jacl:
$AdminTask changeRoutingRulePriority {-odrname odr -nodename node1 -protocol SIP -priority 0 -expression "request.method = 'getOperation0'"}
- Utilizando la serie Jython:
AdminTask.changeRoutingRulePriority('[-odrname odr -nodename node1 -protocol HTTP -priority 1 -expression "queryparm$userid = \'123\'"]')
Ejemplo de utilización de la modalidad interactiva
- En Jacl:
$AdminTask changeRoutingRulePriority {-interactive}
- Utilizando la serie Jython:
AdminTask.changeRoutingRulePriority ('[-interactive]')
createRoutingRules
El mandato createRoutingRules crea una lista de reglas de política de direccionamiento.
Parámetros necesarios
- -protocol: especifica el nombre del protocolo que asociar a una regla. (String, obligatorio)
Parámetros opcionales
- -odrname: especifica el nombre del ODR en el que se aplica la clase de trabajo de la política de direccionamiento. El parámetro -odrname sólo es necesario si modifica un ODR o un servidor web.
- -webservername: especifica el nombre del servidor web en el que se aplica la clase de trabajo de la política de direccionamiento.
- -nodename: especifica el nombre del nodo en el que reside el ODR o el servidor web. El parámetro -nodename sólo es necesario si modifica un ODR o un servidor web.
- -clustername: especifica el nombre del clúster al que se aplica la regla. El parámetro -clustername sólo es necesario si modifica un clúster de ODR.
- -dcname: especifica el nombre del clúster dinámico al que se aplica la regla. El parámetro -dcname sólo es necesario si modifica un clúster de ODR.
Ejemplo de uso de la modalidad de proceso por lotes
- En Jacl:
$AdminTask createRoutingRules {-odrname odr -nodename node1 -protocol SIP}
- Utilizando la serie Jython:
AdminTask.createRoutingRules('-odrname odr -nodename node1 -protocol SIP')
Ejemplo de utilización de la modalidad interactiva
- En Jacl:
$AdminTask createRoutingRules {-interactive}
- Utilizando la serie Jython:
AdminTask.createRoutingRules ('[-interactive]')
listRoutingRules
El mandato listRoutingRules lista las reglas de política de direccionamiento.
Parámetros necesarios
- -protocol: especifica el nombre del protocolo que asociar a una regla. (String, obligatorio)
Parámetros opcionales
- -odrname: especifica el nombre del ODR en el que se aplica la clase de trabajo de la política de direccionamiento. El parámetro -odrname sólo es necesario si modifica un ODR o un servidor web.
- -webservername: especifica el nombre del servidor web en el que se aplica la clase de trabajo de la política de direccionamiento.
- -nodename: especifica el nombre del nodo en el que reside el ODR o el servidor web. El parámetro -nodename sólo es necesario si modifica un ODR o un servidor web.
- -clustername: especifica el nombre del clúster al que se aplica la regla. El parámetro -clustername sólo es necesario si modifica un clúster de ODR.
- -dcname: especifica el nombre del clúster dinámico al que se aplica la regla. El parámetro -dcname sólo es necesario si modifica un clúster de ODR.
Ejemplo de uso de la modalidad de proceso por lotes
- En Jacl:
$AdminTask listRoutingRules {-odrname odr -nodename node1 -protocol SIP}
- Utilizando la serie Jython:
AdminTask.listRoutingRules('-odrname odr -nodename node1 -protocol SIP')
Ejemplo de utilización de la modalidad interactiva
- En Jacl:
$AdminTask listRoutingRules {-interactive}
- Utilizando la serie Jython:
AdminTask.listRoutingRules ('[-interactive]')
removeRoutingRule
El mandato removeRoutingRule elimina una regla de política de direccionamiento.
Parámetros necesarios
- -protocol: especifica el nombre del protocolo que asociar a una regla. (String, obligatorio)
- -priority: el valor entero positivo que representa la prioridad de una regla. Cero es la prioridad máxima. (String, obligatorio)
- -expression: especifica la expresión de regla. La expresión se debe especificar entre comillas. Para obtener más información sobre la especificación de parámetros para la expresión de regla, consulte el tema de operandos SIP y el tema de operandos HTTP. (String, obligatorio)
Parámetros opcionales
- -odrname: especifica el nombre del ODR en el que se aplica la clase de trabajo de la política de direccionamiento. El parámetro -odrname sólo es necesario si modifica un ODR o un servidor web.
- -webservername: especifica el nombre del servidor web en el que se aplica la clase de trabajo de la política de direccionamiento.
- -nodename: especifica el nombre del nodo en el que reside el ODR o el servidor web. El parámetro -nodename sólo es necesario si modifica un ODR o un servidor web.
- -clustername: especifica el nombre del clúster al que se aplica la regla. El parámetro -clustername sólo es necesario si modifica un clúster de ODR.
- -dcname: especifica el nombre del clúster dinámico al que se aplica la regla. El parámetro -dcname sólo es necesario si modifica un clúster de ODR.
Ejemplo de uso de la modalidad de proceso por lotes
- En Jacl:
$AdminTask removeRoutingRule {-odrname odr -nodename node1 -protocol SIP -expression "request.method = 'getOperation'"}
- Utilizando la serie Jython:
AdminTask.removeRoutingRule('[-odrname odr -nodename node1 -protocol HTTP -expression "queryparm$userid = \'123\'"]')
Ejemplo de utilización de la modalidad interactiva
- En Jacl:
$AdminTask removeRoutingRule {-interactive}
- Utilizando la serie Jython:
AdminTask.removeRoutingRule ('[-interactive]')