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

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.

Die Verwendung der Verwaltungsbefehle der ODR-Routing-Richtlinie bietet die folgenden Hauptvorteile:
  • 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.
Anmerkung: SIP (Session Initiation Protocol) wird momentan nicht für z/OS unterstützt.

addRoutingRule

Der Befehl addRoutingRule fügt eine Regel für eine Routing-Richtlinie hinzu.
Anmerkung: Wenn Sie eine vorhandene Anwendungsedition mit einer definierten Multi-Cluster-Routing-Richtlinie haben und eine neue Edition installieren, müssen Sie eine neue Multi-Cluster-Routing-Richtlinie für die neue Edition erstellen.

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

Das folgende Beispiel zeigt die Überbrückung aller Anwendungen einer Zelle in einen generischen Server-Cluster (generic), der auf eine andere Zelle verweist:
  • 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"') 
Das folgende Beispiel zeigt eine Multi-Cluster-Routing-Richtlinie für eine neue Anwendungsedition:
  • 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 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 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]')

Symbol, das den Typ des Artikels anzeigt. Referenzartikel



Symbol für Zeitmarke Letzte Aktualisierung: 25.05.2016
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=rwve_xdhttprules
Dateiname:rwve_xdhttprules.html