Erstellen erweiterter Richtlinien

  • 3 Minuten

Diese Lerneinheit enthält eine Referenz für die folgenden API Management-Richtlinien:

  • Ablaufsteuerung – Bedingte Anwendung von Richtlinienanweisungen basierend auf den Ergebnissen der Auswertung von booleschen Ausdrücken
  • Anforderung weiterleiten – Leitet die Anforderung an den Back-End-Dienst.
  • Parallelität einschränken: verhindert die Ausführung der eingeschlossenen Richtlinien durch mehr als die angegebene Anzahl von Anforderungen gleichzeitig.
  • Protokoll an Event Hub – Sendet Nachrichten im angegebenen Format an einen von einem Protokollierungstool definierten Event Hub.
  • Modellantwort – bricht die Pipelineausführung ab und gibt die Modellantwort unmittelbar an den Aufrufer zurück.
  • Wiederholen – Wiederholt die Ausführung der eingeschlossenen Richtlinienanweisungen, falls und bis die Bedingung erfüllt ist. Die Ausführung wird in den angegebenen Zeitintervallen und bis zur angegebenen Anzahl Wiederholungsversuche wiederholt.

Ablaufsteuerung

Die choose-Richtlinie (Auswählen) wendet die eingeschlossenen Richtlinienanweisungen entsprechend dem Ergebnis der Auswertung von booleschen Ausdrücken an, ähnlich einer If-Then-Else- oder Switch-Anweisung in einer Programmiersprache.

<choose>
    <when condition="Boolean expression | Boolean constant">
        <!— one or more policy statements to be applied if the above condition is true  -->
    </when>
    <when condition="Boolean expression | Boolean constant">
        <!— one or more policy statements to be applied if the above condition is true  -->
    </when>
    <otherwise>
        <!— one or more policy statements to be applied if none of the above conditions are true  -->
</otherwise>
</choose>

Die Ablaufsteuerungsrichtlinie muss mindestens ein <when/>-Element enthalten. Das <otherwise/>-Element ist optional. Bedingungen in <when/>-Elementen werden in der Reihenfolge ihrer Anordnung in der Richtlinie ausgewertet. Richtlinienanweisungen, die in das erste <when/>-Element eingeschlossen sind, werden angewandt, wenn das Bedingungsattribut TRUE ist. Richtlinien, die in das <otherwise/>-Element eingeschlossen sind, falls vorhanden, werden angewandt, wenn alle Bedingungsattribute des <when/>-Elements FALSE sind.

Weiterleitungsanforderung

Die forward-request-Richtlinie (Weiterleitungsanforderung) leitet die eingehende Anforderung an den Back-End-Dienst weiter, der im Anforderungskontext angegeben ist. Die Back-End-Dienst-URL ist in den API-Einstellungen angegeben und kann mit der Richtlinie Back-End-Dienst festlegen geändert werden.

Durch das Entfernen dieser Richtlinie wird die Anforderung nicht an den Back-End-Dienst weitergeleitet. Die Richtlinien im Abschnitt „outbound“ werden sofort ausgewertet, wenn die Richtlinien im Abschnitt „inbound“ erfolgreich abgeschlossen wurden.

<forward-request timeout="time in seconds" follow-redirects="true | false"/>

Einschränken der Parallelität durch

Die Richtlinie limit-concurrency verhindert die Ausführung der eingeschlossenen Richtlinien durch mehr als die angegebene Anzahl von Anforderungen gleichzeitig. Wenn die Anforderungen diese Zahl überschreiten, schlagen neue Anforderungen sofort mit dem Statuscode 429 – Zu viele Anforderungen fehl.

<limit-concurrency key="expression" max-count="number">
        <!— nested policy statements -->
</limit-concurrency>

Protokoll an Event Hub

Mit der log-to-eventhub-Richtlinie werden Nachrichten im angegebenen Format an ein von einem Protokollierungstool definiertes Nachrichtenziel gesendet. Wie anhand des Namens bereits erkennbar ist, wird diese Richtlinie zum Speichern von ausgewählten Anforderungs- oder Antwortkontextinformationen für die Online- oder Offlineanalyse verwendet.

<log-to-eventhub logger-id="id of the logger entity" partition-id="index of the partition where messages are sent" partition-key="value used for partition assignment">
  Expression returning a string to be logged
</log-to-eventhub>

Modellantwort

Die mock-response wird, wie der Name impliziert, dazu verwendet, APIs und Vorgänge zu modellieren. Sie bricht die normale Pipelineausführung ab und gibt die Modellantwort an den Aufrufer zurück. Die Richtlinie versucht immer, möglichst realitätsnahe Antworten zurückgeben. Sie bevorzugt dabei Beispiele für Antwortinhalte, soweit verfügbar. Sie generiert Beispielantworten aus Schemas, sofern Schemas bereitgestellt werden, Beispiele hingegen nicht. Wenn keine Beispiele oder Schemas gefunden wurden, werden Antworten ohne Inhalt zurückgegeben.

<mock-response status-code="code" content-type="media type"/>

Erneut versuchen

Die retry-Richtlinie führt ihre untergeordneten Richtlinien einmal aus und versucht dann, die Ausführung zu wiederholen, bis condition für die Wiederholung false wird oder der Wert count für die Wiederholung ausgeschöpft ist.

<retry
    condition="boolean expression or literal"
    count="number of retry attempts"
    interval="retry interval in seconds"
    max-interval="maximum retry interval in seconds"
    delta="retry interval delta in seconds"
    first-fast-retry="boolean expression or literal">
        <!-- One or more child policies. No restrictions -->
</retry>

Antwort zurückgeben

Mit der return-response-Richtlinie wird die Pipelineausführung abgebrochen und entweder eine Standardantwort oder eine benutzerdefinierte Antwort an den Aufrufer zurückgegeben. Die Standardantwort ist 200 OK ohne Text. Die benutzerdefinierte Antwort kann über eine Kontextvariable oder Richtlinienanweisungen angegeben werden. Wenn beide angegeben werden, ändert die Richtlinienanweisung die Kontextvariable, bevor sie an den Aufrufer zurückgegeben wird.

<return-response response-variable-name="existing context variable">
  <set-header/>
  <set-body/>
  <set-status/>
</return-response>

Weitere Ressourcen