![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
![[z/OS]](../images/ngzos.gif)
Intelligent Management: Regeln für Verwaltungstasks für ODR-Routing-Richtlinien
Sie können Verwaltungstasks verwenden, um HTTP-Regeln oder SIP-Regeln (Session Initiation Protocol) für die ODR-Routing-Richtlinie (On Demand Router) zu konfigurieren.
Verwenden Sie zum Konfigurieren der Routing-Richtlinien die folgenden Regeln. Diese Regeln stellen die bevorzugte Methode zur Konfiguration von Routing-Richtlinien dar. Sie können auch Multi-Cluster-Routing-Richtlinien für Failover und Lastausgleich verwenden. Weitere Informationen zu dieser Prozedur finden Sie in der Beschreibung der Konfiguration des On Demand Router für Multi-Cluster-Routing für Failover und Lastausgleich.
- Sie können Ausdrücke verwenden, um festzulegen, welche Anforderungen von der Richtlinie betroffen sind. Mit der Multi-Cluster-Routing-Methode können Sie nur nach Anwendung oder Anwendungswebmodul filtern.
- Sie können das Ziel (routingLocations) nach Cluster oder Webmodul auswählen. Bei der Multi-Cluster-Routing-Methode können Sie nur den Zielcluster auswählen.
- Sie können SIP- oder HTTP-Protokolle in den Befehlen angeben.
addRoutingRule
Erforderliche Parameter
- -protocol: Gibt den Namen des Protokolls an, das einer Regel zugeordnet werden soll. (String, erforderlich)
- -priority: Positiver ganzzahliger Wert, der die Priorität einer Regel darstellt. Null ist die höchste Priorität. (String, erforderlich)
- -expression: Gibt den Regelausdruck an. Der Ausdruck muss in Anführungszeichen gesetzt werden. Weitere Informationen zur Angabe der Parameter für den Regelausdruck finden Sie im Artikel zu den SIP-Operanden und im Artikel zu den HTTP-Operanden. (String, erforderlich)
- -actionType: Gibt den Typ der Aktion an, die einer Regel zugeordnet werden soll. (String, erforderlich)In der folgenden Liste sind die Aktionstypen aufgeführt, die den HTTP-Regeln zugeordnet werden sollen:
- localResource: Gibt die lokale Ressource (Datei) an, die für diese Routing-Regel verwendet werden soll.
- permit: Routing an Server zulassen, die nicht im Wartungsmodus sind.
- redirect: Anforderung an den mit der Option redirectURL angegebenen URL weiterleiten.
- reject: Routing mit dem Rückkehrcode zurückweisen, der mit der Option errorcode angegeben wurde.
- permitsticky: Routing an Server, die nicht im Wartungsmodus sind, mit aktiver Affinität zulassen, d. h., die Affinität wird selbst dann beibehalten, wenn dies nicht von der Anwendung angefordert wird.
- permitMM: Routing nur an Server im Wartungsmodus zulassen.
- permitstickyMM: Routing nur an Server im Wartungsmodus mit aktiver Affinität zulassen.
In der folgenden Liste sind die Aktionstypen aufgeführt, die den SIP-Regeln zugeordnet werden sollen:- permit: Routing an Server zulassen, die nicht im Wartungsmodus sind.
- reject: Routing mit dem Rückkehrcode zurückweisen, der mit der Option errorcode angegeben wurde.
Optionale Parameter
- -odrname: Gibt den Namen des ODR an, für den die Arbeitsklasse der Servicerichtlinie gilt. Der Parameter -odrname ist nur erforderlich, wenn Sie einen ODR oder Web-Server ändern.
- -webservername: Gibt den Namen des Web-Server an, für den die Arbeitsklasse der Routing-Richtlinie gilt.
- -nodename: Gibt den Namen des Knotens an, auf dem sich der ODR bzw. Web-Server befindet. Der Parameter -nodename ist nur erforderlich, wenn Sie einen ODR oder Web-Server ändern.
- -clustername: Gibt den Namen des Clusters an, für das die Regel gilt. Der Parameter -clustername ist nur erforderlich, wenn Sie einen ODR-Cluster ändern.
- -dcname: Gibt den Namen des dynamischen Clusters an, für den die Regel gilt. Der Parameter -dcname ist nur erforderlich, wenn Sie einen ODR-Cluster ändern.
- -multiclusterAction: Gibt die Methode für die Weiterleitung von Anforderungen an, wenn es mehrere Übereinstimmungen bei den Routing-Clustern gibt. Der Parameter
-multiclusterAction ist auf alle permit-actionTypes anwendbar und nur erforderlich, wenn
für actionType die Option permit, permitsticky, permitMM
oder permitstickyMM angegeben ist.
- Failover: Den ersten Cluster mit einem verfügbaren Server suchen und die Last gleichmäßig auf diesen Cluster verteilen. Die Anordnung der Cluster in einer dynamisch generierten Liste ist nicht festgelegt.
- WRR: Lastverteilung nach dem Round-Robin-Prinzip mit Gewichtung. Für erneute UDP-Übertragungen wird die Affinität aufrechterhalten.
- WLOR: Ausstehende Anforderungen mit niedrigster Gewichtung.
Bewährtes Verfahren: Es wird empfohlen, den Wert WLOR und nicht den Wert WRR zu verwenden. bprac
In der folgenden Liste sind die gültigen Werte für SIP-Regeln aufgeführt:- Failover: Den ersten Cluster mit einem verfügbaren Server suchen und die Last gleichmäßig auf diesen Cluster verteilen. Die Anordnung der Cluster in einer dynamisch generierten Liste ist nicht festgelegt.
- WRR: Lastverteilung nach dem Round-Robin-Prinzip mit Gewichtung. Für erneute UDP-Übertragungen wird die Affinität aufrechterhalten.
- Error: Wenn mehrere Cluster vorhanden sind und Server aus diesen ausgewählt wurden, wird ein Fehler ausgegeben. Es darf nur ein einziger Cluster verwendet werden.
- -routingLocations: Gibt eine Liste von Zielpositionen an, an die Anforderungen weitergeleitet werden können. Der Parameter -routingLocations
ist nur erforderlich, wenn actionType einem der permit-Aktionstypen entspricht.
Jeder Operand in der Liste hat eines der folgenden drei Formate und kann einen Wert für das Platzhalterzeichen * enthalten:
- cluster=cellName/clusterName
- server=cellName/nodeName/serverName
- module=cellName/applicationName/applicationVersion/moduleName
Sie können Zielcluster nur mit Regeln für SIP-Routing über einen Regelausdruck alternativ definieren. Die gültigen Operatoren sind: AND, OR, NOT und Zusammenfassungen mit Klammern. Verwenden Sie ein Format gemäß der folgenden Liste:- cluster=cellName/clusterName
- server=cellName/nodeName/serverName
- module=cellName/applicationName/applicationVersion/moduleName
- server maintenance mode=true oder false
- node maintenance mode=true oder false
- protocol=PROTO_WERT:
- PROTO_SIP = sip
- SIP over TCP
- PROTO_SIPS = sips
- SIP over SSL and TCP
- PROTO_SIPU = sipu
- SIP over UDP
- PROTO_SIPX = sipx
- SIP over XMEM
Anmerkung: Lassen Sie für Anwendungen, die keinen Wert für applicationVersion haben, den Wert für applicationVersion leer: module=cellName/application//moduleName. - -errorcode : Ganzzahliger Fehlercode für die Zurückweisung einer Anforderung. Der Parameter -errorcode ist nur erforderlich, wenn für actionType der Wert reject angegeben wird.
- -localResource: Diese Option kann zusammen mit dem Parameter actionType verwendet werden. Wenn Sie die Option -localResource mit dem Parameter actionType verwenden, geben Sie auch den Parameter localResourcePath an. Der Parameter localResourcePath gibt den absoluten oder relativen Pfad zum Profilstammverzeichnis an.
Verwendungsbeispiel für den Stapelmodus
- Mit Jacl:
$AdminTask addRoutingRule {-webservername ws1 -nodename node1 -protocol HTTP -priority 0 -expression "request.method = 'getOperation'" -actionType permit -multiclusterAction Failover -routingLocations cluster=*/*}
- Mit Jython (String):
AdminTask.addRoutingRule('-webservername ws1 -nodename node1 -protocol HTTP -priority 0 -expression "queryparm$userid = \'123\'" -actionType permit -multiclusterAction Failover -routingLocations "module=*/*/*/*,cluster=myCell/myFailoverGSCThatPointsToAnotherCell"')
- Mit Jacl:
$AdminTask addRoutingRule {-odrname odr -nodename node1 -protocol HTTP -priority 0 -expression "uri LIKEIN {'/contextRoot','/contextRoot/%'}" -actionType permit -multiclusterAction Failover -routingLocations cluster=cellName/clusterName}
- Mit Jython (String):
AdminTask.addRoutingRule('-odrname odr -nodename node1 -protocol HTTP -priority 0 -expression "uri LIKEIN (\'/contextRoot\',\'/contextRoot/%\')" -actionType permit -multiclusterAction Failover -routingLocations cluster=cellName/clusterName')
Verwendungsbeispiel für den Dialogmodus
- Mit Jacl:
$AdminTask addRoutingRule {-interactive}
- Mit Jython (String):
AdminTask.addRoutingRule ('[-interactive]')
changeRoutingDefaultRulesAction
Der Befehl changeRoutingDefaultRulesAction ändert die Standardaktion der Routing-Richtlinie für eine Regel.
Erforderliche Parameter
- -protocol: Gibt den Namen des Protokolls an, das einer Regel zugeordnet werden soll. (String, erforderlich)
- -actionType: Gibt den Typ der Aktion an, die einer Regel zugeordnet werden soll. (String, erforderlich)In der folgenden Liste sind die Aktionstypen aufgeführt, die den HTTP-Regeln zugeordnet werden sollen:
- localResource: Gibt die lokale Ressource (Datei) an, die für diese Routing-Regel verwendet werden soll.
- permit: Routing an Server zulassen, die nicht im Wartungsmodus sind.
- redirect: Anforderung an den mit der Option redirectURL angegebenen URL weiterleiten.
- reject: Routing mit dem Rückkehrcode zurückweisen, der mit der Option errorcode angegeben wurde.
- permitsticky: Routing an Server, die nicht im Wartungsmodus sind, mit aktiver Affinität zulassen, d. h., die Affinität wird selbst dann beibehalten, wenn dies nicht von der Anwendung angefordert wird.
- permitMM: Routing nur an Server im Wartungsmodus zulassen.
- permitstickyMM: Routing nur an Server im Wartungsmodus mit aktiver Affinität zulassen.
In der folgenden Liste sind die Aktionstypen aufgeführt, die den SIP-Regeln zugeordnet werden sollen:- permit: Routing an Server zulassen, die nicht im Wartungsmodus sind.
- reject: Routing mit dem Rückkehrcode zurückweisen, der mit der Option errorcode angegeben wurde.
Optionale Parameter
- -odrname: Gibt den Namen des ODR an, für den die Arbeitsklasse der Servicerichtlinie gilt. Der Parameter -odrname ist nur erforderlich, wenn Sie einen ODR oder Web-Server ändern.
- -webservername: Gibt den Namen des Web-Server an, für den die Arbeitsklasse der Routing-Richtlinie gilt.
- -nodename: Gibt den Namen des Knotens an, auf dem sich der ODR bzw. Web-Server befindet. Der Parameter -nodename ist nur erforderlich, wenn Sie einen ODR oder Web-Server ändern.
- -clustername: Gibt den Namen des Clusters an, für das die Regel gilt. Der Parameter -clustername ist nur erforderlich, wenn Sie einen ODR-Cluster ändern.
- -dcname: Gibt den Namen des dynamischen Clusters an, für den die Regel gilt. Der Parameter -dcname ist nur erforderlich, wenn Sie einen ODR-Cluster ändern.
- -multiclusterAction: Gibt die Methode für die Weiterleitung von Anforderungen an, wenn es mehrere Übereinstimmungen bei den Routing-Clustern gibt. Der
Parameter -multiclusterAction gilt für alle permit-Aktionstypen
und ist nur erforderlich, wenn actionType den Wert
permit, permitsticky, permitMM
oder permitstickyMM hat.
- Failover: Den ersten Cluster mit einem verfügbaren Server suchen und die Last gleichmäßig auf diesen Cluster verteilen. Die Anordnung der Cluster in einer dynamisch generierten Liste ist nicht festgelegt.
- WRR: Lastverteilung nach dem Round-Robin-Prinzip mit Gewichtung. Für erneute UDP-Übertragungen wird die Affinität aufrechterhalten.
- WLOR: Ausstehende Anforderungen mit niedrigster Gewichtung.
Bewährtes Verfahren: Es wird empfohlen, den Wert WLOR und nicht den Wert WRR zu verwenden. bprac
In der folgenden Liste sind die gültigen Werte für SIP-Regeln aufgeführt:- Failover: Den ersten Cluster mit einem verfügbaren Server suchen und die Last gleichmäßig auf diesen Cluster verteilen. Die Anordnung der Cluster in einer dynamisch generierten Liste ist nicht festgelegt.
- WRR: Lastverteilung nach dem Round-Robin-Prinzip mit Gewichtung. Für erneute UDP-Übertragungen wird die Affinität aufrechterhalten.
- Error: Wenn mehrere Cluster vorhanden sind und Server aus diesen ausgewählt wurden, wird ein Fehler ausgegeben. Es darf nur ein einziger Cluster verwendet werden.
- -routingLocations: Gibt eine Liste von Zielpositionen an, an die Anforderungen weitergeleitet werden können. Der Parameter -routingLocations
ist nur erforderlich, wenn für actionType einer der
permit-Aktionstypen angegeben ist.
Jeder Operand in der Liste hat eines der folgenden drei Formate und kann einen Wert für das Platzhalterzeichen * enthalten:
- cluster=cellName/clusterName
- server=cellName/nodeName/serverName
- module=cellName/applicationName/applicationVersion/moduleName
Sie können Zielcluster nur mit Regeln für SIP-Routing über einen Regelausdruck alternativ definieren. Die gültigen Operatoren sind: AND, OR, NOT und Zusammenfassungen mit Klammern. Verwenden Sie ein Format gemäß der folgenden Liste:- cluster=cellName/clusterName
- server=cellName/nodeName/serverName
- module=cellName/applicationName/applicationVersion/moduleName
- server maintenance mode=true oder false
- node maintenance mode=true oder false
- protocol=PROTO_WERT:
- PROTO_SIP = sip
- SIP over TCP
- PROTO_SIPS = sips
- SIP over SSL and TCP
- PROTO_SIPU = sipu
- SIP over UDP
- PROTO_SIPX = sipx
- SIP over XMEM
Anmerkung: Lassen Sie für Anwendungen, die keinen Wert für applicationVersion haben, den Wert für applicationVersion leer: module=cellName/application//moduleName. - -errorcode : Ganzzahliger Fehlercode für die Zurückweisung einer Anforderung. Der Parameter -errorcode ist nur erforderlich, wenn für actionType der Wert reject angegeben wird.
- -localResource: Diese Option kann zusammen mit dem Parameter actionType verwendet werden. Wenn Sie die Option -localResource mit dem Parameter actionType verwenden, geben Sie auch den Parameter localResourcePath an. Der Parameter localResourcePath gibt den absoluten oder relativen Pfad zum Profilstammverzeichnis an.
Verwendungsbeispiel für den Stapelmodus
- Mit Jacl:
Die folgenden Beispiele zeigen die Überbrückung eines einzelnen Clusters in einen generischen Server-Cluster (generic) für Failover:
$AdminTask changeRoutingDefaultRulesAction {-webservername ws1 -nodename node1 -protocol HTTP -actionType permit -multiclusterAction Failover -routingLocations cluster=*/*}
- Mit Jython (String):
AdminTask.changeRoutingDefaultRulesAction('[-webservername ws1 -nodename node1 -protocol HTTP -actionType permit -multiclusterAction Failover -routingLocations "cluster=myCell/myPrimaryCluster,cluster=myCell/myFailoverCluster"]')
Verwendungsbeispiel für den Dialogmodus
- Mit Jacl:
$AdminTask changeRoutingDefaultRulesAction {-interactive}
- Mit Jython (String):
AdminTask.changeRoutingDefaultRulesAction ('[-interactive]')
changeRoutingRuleAction
Der Befehl changeRoutingRuleAction ändert die Aktion der Routing-Richtlinie für eine Regel.
Erforderliche Parameter
- -protocol: Gibt den Namen des Protokolls an, das einer Regel zugeordnet werden soll. (String, erforderlich)
- -priority: Positiver ganzzahliger Wert, der die Priorität einer Regel darstellt. Null ist die höchste Priorität. (String, erforderlich)
Optionale Parameter
- -odrname: Gibt den Namen des ODR an, für den die Arbeitsklasse der Servicerichtlinie gilt. Der Parameter -odrname ist nur erforderlich, wenn Sie einen ODR oder Web-Server ändern.
- -webservername: Gibt den Namen des Web-Server an, für den die Arbeitsklasse der Routing-Richtlinie gilt.
- -nodename: Gibt den Namen des Knotens an, auf dem sich der ODR bzw. Web-Server befindet. Der Parameter -nodename ist nur erforderlich, wenn Sie einen ODR oder Web-Server ändern.
- -clustername: Gibt den Namen des Clusters an, für das die Regel gilt. Der Parameter -clustername ist nur erforderlich, wenn Sie einen ODR-Cluster ändern.
- -dcname: Gibt den Namen des dynamischen Clusters an, für den die Regel gilt. Der Parameter -dcname ist nur erforderlich, wenn Sie einen ODR-Cluster ändern.
- -multiclusterAction: Gibt die Methode für die Weiterleitung von Anforderungen an, wenn es mehrere Übereinstimmungen bei den Routing-Clustern gibt. Der Parameter
-multiclusterAction ist auf alle permit-actionTypes anwendbar und nur erforderlich, wenn für
actionType die Option permit, permitsticky, permitMM oder permitstickyMM angegeben ist.
- Failover: Den ersten Cluster mit einem verfügbaren Server suchen und die Last gleichmäßig auf diesen Cluster verteilen. Die Anordnung der Cluster in einer dynamisch generierten Liste ist nicht festgelegt.
- WRR: Lastverteilung nach dem Round-Robin-Prinzip mit Gewichtung. Für erneute UDP-Übertragungen wird die Affinität aufrechterhalten.
- WLOR: Ausstehende Anforderungen mit niedrigster Gewichtung.
Bewährtes Verfahren: Es wird empfohlen, den Wert WLOR und nicht den Wert WRR zu verwenden. bprac
In der folgenden Liste sind die gültigen Werte für SIP-Regeln aufgeführt:- Failover: Den ersten Cluster mit einem verfügbaren Server suchen und die Last gleichmäßig auf diesen Cluster verteilen. Die Anordnung der Cluster in einer dynamisch generierten Liste ist nicht festgelegt.
- WRR: Lastverteilung nach dem Round-Robin-Prinzip mit Gewichtung. Für erneute UDP-Übertragungen wird die Affinität aufrechterhalten.
- Error: Wenn mehrere Cluster vorhanden sind und Server aus diesen ausgewählt wurden, wird ein Fehler ausgegeben. Es darf nur ein einziger Cluster verwendet werden.
- -routingLocations: Gibt eine Liste von Zielpositionen an, an die Anforderungen weitergeleitet werden können. Der Parameter -routingLocations
ist nur erforderlich, wenn für actionType einer der
permit-actionTypes angegeben wird.Jeder Operand in der Liste hat eines der folgenden drei Formate und kann einen Wert für das Platzhalterzeichen * enthalten:
- cluster=cellName/clusterName
- server=cellName/nodeName/serverName
- module=cellName/applicationName/applicationVersion/moduleName
Sie können Zielcluster nur mit Regeln für SIP-Routing über einen Regelausdruck alternativ definieren. Die gültigen Operatoren sind: AND, OR, NOT und Zusammenfassungen mit Klammern. Verwenden Sie ein Format gemäß der folgenden Liste:- cluster=cellName/clusterName
- server=cellName/nodeName/serverName
- module=cellName/applicationName/applicationVersion/moduleName
- server maintenance mode=true oder false
- node maintenance mode=true oder false
- protocol=PROTO_WERT:
- PROTO_SIP = sip
- SIP over TCP
- PROTO_SIPS = sips
- SIP over SSL and TCP
- PROTO_SIPU = sipu
- SIP over UDP
- PROTO_SIPX = sipx
- SIP over XMEM
Anmerkung: Lassen Sie für Anwendungen, die keinen Wert für applicationVersion haben, den Wert für applicationVersion leer: module=cellName/application//moduleName. - -errorcode : Ganzzahliger Fehlercode für die Zurückweisung einer Anforderung. Der Parameter -errorcode ist nur erforderlich, wenn für actionType der Wert reject angegeben wird.
- -localResource: Diese Option kann zusammen mit dem Parameter actionType verwendet werden. Wenn Sie die Option -localResource mit dem Parameter actionType verwenden, geben Sie auch den Parameter localResourcePath an. Der Parameter localResourcePath gibt den absoluten oder relativen Pfad zum Profilstammverzeichnis an.
Verwendungsbeispiel für den Stapelmodus
- Mit Jacl:
$AdminTask changeRoutingRuleAction {-webservername ws1 -nodename node1 -protocol HTTP -priority 0 -multiclusterAction Failover -routingLocations cluster=*/*
- Mit Jython (String):
AdminTask.changeRoutingRuleAction('[-webservername ws1 -nodename node1 -protocol HTTP -priority 0 -multiclusterAction WRR -routingLocations "cluster=myCell/*"]')
Verwendungsbeispiel für den Dialogmodus
- Mit Jacl:
$AdminTask changeRoutingRuleAction {-interactive}
- Mit Jython (String):
AdminTask.changeRoutingRuleAction ('[-interactive]')
changeRoutingRuleExpression
Der Befehl changeRoutingRuleExpression ändert den Regelausdruck einer Routing-Richtlinie.
Erforderliche Parameter
- -protocol: Gibt den Namen des Protokolls an, das einer Regel zugeordnet werden soll. (String, erforderlich)
- -priority: Positiver ganzzahliger Wert, der die Priorität einer Regel darstellt. Null ist die höchste Priorität. (String, erforderlich)
- -expression: Gibt den Regelausdruck an. Der Ausdruck muss in Anführungszeichen gesetzt werden. Weitere Informationen zur Angabe der Parameter für den Regelausdruck finden Sie im Artikel zu den SIP-Operanden und im Artikel zu den HTTP-Operanden. (String, erforderlich)
Optionale Parameter
- -odrname: Gibt den Namen des ODR an, für den die Arbeitsklasse der Servicerichtlinie gilt. Der Parameter -odrname ist nur erforderlich, wenn Sie einen ODR oder Web-Server ändern.
- -webservername: Gibt den Namen des Web-Server an, für den die Arbeitsklasse der Routing-Richtlinie gilt.
- -nodename: Gibt den Namen des Knotens an, auf dem sich der ODR bzw. Web-Server befindet. Der Parameter -nodename ist nur erforderlich, wenn Sie einen ODR oder Web-Server ändern.
- -clustername: Gibt den Namen des Clusters an, für das die Regel gilt. Der Parameter -clustername ist nur erforderlich, wenn Sie einen ODR-Cluster ändern.
- -dcname: Gibt den Namen des dynamischen Clusters an, für den die Regel gilt. Der Parameter -dcname ist nur erforderlich, wenn Sie einen ODR-Cluster ändern.
Verwendungsbeispiel für den Stapelmodus
- Mit Jacl:
$AdminTask changeRoutingRuleExpression {-odrname ODR -nodename Knoten1 -protocol SIP -priority 0 -expression "request.method = 'getOperation0'"}
- Mit Jython (String):
AdminTask.changeRoutingRuleExpression('[-odrname odr -nodename node1 -protocol HTTP -priority 0 -expression "queryparm$userid = \'123\'"]')
Verwendungsbeispiel für den Dialogmodus
- Mit Jacl:
$AdminTask changeRoutingRuleExpression {-interactive}
- Mit Jython (String):
AdminTask.changeRoutingRuleExpression ('[-interactive]')
changeRoutingRulePriority
Der Befehl changeRoutingRulePriority ändert die Regelpriorität einer Routing-Richtlinie.
Erforderliche Parameter
- -protocol: Gibt den Namen des Protokolls an, das einer Regel zugeordnet werden soll. (String, erforderlich)
- -priority: Positiver ganzzahliger Wert, der die Priorität einer Regel darstellt. Null ist die höchste Priorität. (String, erforderlich)
- -expression: Gibt den Regelausdruck an. Der Ausdruck muss in Anführungszeichen gesetzt werden. Weitere Informationen zur Angabe der Parameter für den Regelausdruck finden Sie im Artikel zu den SIP-Operanden und im Artikel zu den HTTP-Operanden. (String, erforderlich)
Optionale Parameter
- -odrname: Gibt den Namen des ODR an, für den die Arbeitsklasse der Servicerichtlinie gilt. Der Parameter -odrname ist nur erforderlich, wenn Sie einen ODR oder Web-Server ändern.
- -webservername: Gibt den Namen des Web-Server an, für den die Arbeitsklasse der Routing-Richtlinie gilt.
- -nodename: Gibt den Namen des Knotens an, auf dem sich der ODR bzw. Web-Server befindet. Der Parameter -nodename ist nur erforderlich, wenn Sie einen ODR oder Web-Server ändern.
- -clustername: Gibt den Namen des Clusters an, für das die Regel gilt. Der Parameter -clustername ist nur erforderlich, wenn Sie einen ODR-Cluster ändern.
- -dcname: Gibt den Namen des dynamischen Clusters an, für den die Regel gilt. Der Parameter -dcname ist nur erforderlich, wenn Sie einen ODR-Cluster ändern.
Verwendungsbeispiel für den Stapelmodus
- Mit Jacl:
$AdminTask changeRoutingRulePriority {-odrname ODR -nodename Knoten1 -protocol SIP -priority 0 -expression "request.method = 'getOperation0'"}
- Mit Jython (String):
AdminTask.changeRoutingRulePriority('[-odrname odr -nodename node1 -protocol HTTP -priority 1 -expression "queryparm$userid = \'123\'"]')
Verwendungsbeispiel für den Dialogmodus
- Mit Jacl:
$AdminTask changeRoutingRulePriority {-interactive}
- Mit Jython (String):
AdminTask.changeRoutingRulePriority ('[-interactive]')
createRoutingRules
Der Befehl createRoutingRules erstellt eine Regelliste für eine Routing-Richtlinie.
Erforderliche Parameter
- -protocol: Gibt den Namen des Protokolls an, das einer Regel zugeordnet werden soll. (String, erforderlich)
Optionale Parameter
- -odrname: Gibt den Namen des ODR an, für den die Arbeitsklasse der Servicerichtlinie gilt. Der Parameter -odrname ist nur erforderlich, wenn Sie einen ODR oder Web-Server ändern.
- -webservername: Gibt den Namen des Web-Server an, für den die Arbeitsklasse der Routing-Richtlinie gilt.
- -nodename: Gibt den Namen des Knotens an, auf dem sich der ODR bzw. Web-Server befindet. Der Parameter -nodename ist nur erforderlich, wenn Sie einen ODR oder Web-Server ändern.
- -clustername: Gibt den Namen des Clusters an, für das die Regel gilt. Der Parameter -clustername ist nur erforderlich, wenn Sie einen ODR-Cluster ändern.
- -dcname: Gibt den Namen des dynamischen Clusters an, für den die Regel gilt. Der Parameter -dcname ist nur erforderlich, wenn Sie einen ODR-Cluster ändern.
Verwendungsbeispiel für den Stapelmodus
- Mit Jacl:
$AdminTask createRoutingRules {-odrname odr -nodename node1 -protocol SIP}
- Mit Jython (String):
AdminTask.createRoutingRules('-odrname ODR -nodename Knoten1 -protocol SIP')
Verwendungsbeispiel für den Dialogmodus
- Mit Jacl:
$AdminTask createRoutingRules {-interactive}
- Mit Jython (String):
AdminTask.createRoutingRules ('[-interactive]')
listRoutingRules
Mit dem Befehl listRoutingRules werden Regeln für Routing-Richtlinien aufgelistet.
Erforderliche Parameter
- -protocol: Gibt den Namen des Protokolls an, das einer Regel zugeordnet werden soll. (String, erforderlich)
Optionale Parameter
- -odrname: Gibt den Namen des ODR an, für den die Arbeitsklasse der Servicerichtlinie gilt. Der Parameter -odrname ist nur erforderlich, wenn Sie einen ODR oder Web-Server ändern.
- -webservername: Gibt den Namen des Web-Server an, für den die Arbeitsklasse der Routing-Richtlinie gilt.
- -nodename: Gibt den Namen des Knotens an, auf dem sich der ODR bzw. Web-Server befindet. Der Parameter -nodename ist nur erforderlich, wenn Sie einen ODR oder Web-Server ändern.
- -clustername: Gibt den Namen des Clusters an, für das die Regel gilt. Der Parameter -clustername ist nur erforderlich, wenn Sie einen ODR-Cluster ändern.
- -dcname: Gibt den Namen des dynamischen Clusters an, für den die Regel gilt. Der Parameter -dcname ist nur erforderlich, wenn Sie einen ODR-Cluster ändern.
Verwendungsbeispiel für den Stapelmodus
- Mit Jacl:
$AdminTask listRoutingRules {-odrname ODR -nodename Knoten1 -protocol SIP}
- Mit Jython (String):
AdminTask.listRoutingRules('-odrname ODR -nodename Knoten1 -protocol SIP')
Verwendungsbeispiel für den Dialogmodus
- Mit Jacl:
$AdminTask listRoutingRules {-interactive}
- Mit Jython (String):
AdminTask.listRoutingRules ('[-interactive]')
removeRoutingRule
Der Befehl removeRoutingRule entfernt eine Regel für eine Routing-Richtlinie.
Erforderliche Parameter
- -protocol: Gibt den Namen des Protokolls an, das einer Regel zugeordnet werden soll. (String, erforderlich)
- -priority: Positiver ganzzahliger Wert, der die Priorität einer Regel darstellt. Null ist die höchste Priorität. (String, erforderlich)
- -expression: Gibt den Regelausdruck an. Der Ausdruck muss in Anführungszeichen gesetzt werden. Weitere Informationen zur Angabe der Parameter für den Regelausdruck finden Sie im Artikel zu den SIP-Operanden und im Artikel zu den HTTP-Operanden. (String, erforderlich)
Optionale Parameter
- -odrname: Gibt den Namen des ODR an, für den die Arbeitsklasse der Servicerichtlinie gilt. Der Parameter -odrname ist nur erforderlich, wenn Sie einen ODR oder Web-Server ändern.
- -webservername: Gibt den Namen des Web-Server an, für den die Arbeitsklasse der Routing-Richtlinie gilt.
- -nodename: Gibt den Namen des Knotens an, auf dem sich der ODR bzw. Web-Server befindet. Der Parameter -nodename ist nur erforderlich, wenn Sie einen ODR oder Web-Server ändern.
- -clustername: Gibt den Namen des Clusters an, für das die Regel gilt. Der Parameter -clustername ist nur erforderlich, wenn Sie einen ODR-Cluster ändern.
- -dcname: Gibt den Namen des dynamischen Clusters an, für den die Regel gilt. Der Parameter -dcname ist nur erforderlich, wenn Sie einen ODR-Cluster ändern.
Verwendungsbeispiel für den Stapelmodus
- Mit Jacl:
$AdminTask removeRoutingRule {-odrname ODR -nodename Knoten1 -protocol SIP -expression "request.method = 'getOperation'"}
- Mit Jython (String):
AdminTask.removeRoutingRule('[-odrname odr -nodename node1 -protocol HTTP -expression "queryparm$userid = \'123\'"]')
Verwendungsbeispiel für den Dialogmodus
- Mit Jacl:
$AdminTask removeRoutingRule {-interactive}
- Mit Jython (String):
AdminTask.removeRoutingRule ('[-interactive]')