ExtractVariables-Richtlinie

Diese Seite gilt für Apigee und Apigee Hybrid.

Apigee Edge-Dokumentation aufrufen

Richtliniensymbol

Was

Die Richtlinie ExtractVariables extrahiert Inhalte aus einer Anfrage oder Antwort und legt den Wert einer Variablen auf diesen Inhalt fest. Sie können einen beliebigen Teil der Nachricht extrahieren, wie Header, URI-Pfade, JSON-/XML-Nutzlasten, Formularparameter und Abfrageparameter. Die Richtlinie wendet ein Textmuster auf den Nachrichteninhalt an und legt nach dem Finden einer Übereinstimmung eine Variable mit dem angegebenen Nachrichteninhalt fest.

Sie verwenden ExtractVariables zwar häufig zum Extrahieren von Informationen aus einer Anfrage- oder Antwortnachricht, können die Richtlinie aber auch zum Extrahieren von Informationen aus anderen Quellen, wie Entitäten, die von der AccessEntity-Richtlinie, XML-Objekten oder JSON-Objekten erstellt wurden, verwenden.

Nachdem Sie den angegebenen Nachrichteninhalt extrahiert haben, können Sie bei der Verarbeitung einer Anfrage und Antwort auf die Variable in anderen Richtlinien verweisen.

Diese Richtlinie ist eine erweiterbare Richtlinie und die Verwendung dieser Richtlinie kann je nach Apigee-Lizenz Auswirkungen auf die Kosten oder die Nutzung haben. Informationen zu Richtlinientypen und Auswirkungen auf die Nutzung finden Sie unter Richtlinientypen.

Videos

In folgenden Videos erfahren Sie mehr über die ExtractVariables-Richtlinie.

Video Beschreibung
Variablen aus XML-Nutzlast extrahieren Extrahieren Sie Variablen aus einer XML-Nutzlast mithilfe der Richtlinie „Variablen extrahieren“.
Variablen aus JSON-Nutzlast extrahieren Extrahieren Sie Variablen mithilfe der Richtlinie „Variablen extrahieren“ aus einer JSON-Nutzlast.
Variablen aus Parametern extrahieren Extrahieren Sie Variablen aus Parametern wie Abfrage, Header, Formular oder URI-Parameter.
Variablen aus Mehrwert-Parametern extrahieren Variablen aus Mehrwert-Parametern extrahieren.

Beispiele

Diese Codebeispiele veranschaulichen, wie Variablen aus den folgenden Artefaktarten extrahiert werden:

URIs

<ExtractVariables name="ExtractVariables-1">
   <DisplayName>Extract a portion of the url path</DisplayName>
   <Source>request</Source>
   <URIPath>
      <Pattern ignoreCase="true">/accounts/{id}</Pattern>
   </URIPath>
   <VariablePrefix>urirequest</VariablePrefix>
   <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>
</ExtractVariables>

Sehen Sie sich den oben aufgeführten Beispielcode an. Mit dem Element <URIPath> wird die ExtractVariables-Richtlinie angewiesen, Informationen aus dem URI-Pfad zu extrahieren. Das <Pattern>-Element gibt das Muster an, das auf den URI-Pfad angewendet werden soll. Das Muster wird als einfache Vorlage behandelt, wobei die geschweiften Klammern den abweichenden Teil des URI-Pfads enthalten.

Der Name der festzulegenden Variable wird durch den Wert bestimmt, der im Element <VariablePrefix> angegeben ist, sowie durch den Wert in geschweiften Klammern ({}) des Elements <Pattern>. Die beiden Werte werden durch einen dazwischenliegenden Punkt verbunden, was zu einem variablen Namen wie urirequest.id führt. Wenn kein <VariablePrefix>-Element vorhanden ist, ist der Variablenname einfach der Wert in geschweiften Klammern.

Betrachten Sie den obigen Beispielrichtliniencode, um die folgende eingehende Anfrage zu verwenden:

GET http://example.com/svc1/accounts/12797282

Angenommen, der Basispfad für den API-Proxy lautet /svc1. Wenn Apigee den ExtractVariables-Richtliniencode auf die eingehende Anfrage anwendet, wird die Variable urirequest.id auf 12797282 gesetzt. Nachdem Apigee die Richtlinie ausgeführt hat, können weitere Richtlinien oder Code im Verarbeitungsablauf auf die Variable urirequest.id verweisen, um den Stringwert 12797282 zu erhalten.

Die folgende AssignMessage-Richtlinie bettet beispielsweise den Wert dieser Variable in die Nutzlast einer neuen Anfragenachricht ein:

<AssignMessage async="false" continueOnError="false" enabled="true" name="AssignPayload">
  <DisplayName>AssignPayload</DisplayName>
    <Set>
      <Payload contentType="text/xml">
        <IdExtractedFromURI>{urirequest.id}</IdExtractedFromURI>
      </Payload>
    </Set>
  <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>
  <AssignTo createNew="true" transport="http" type="request">newRequest</AssignTo>
</AssignMessage>

Abfrageparameter

<ExtractVariables name="ExtractVariables-2">
   <DisplayName>Extract a value from a query parameter</DisplayName>
   <Source>request</Source>
   <QueryParam name="code">
      <Pattern ignoreCase="true">DBN{dbncode}</Pattern>
   </QueryParam>
   <VariablePrefix>queryinfo</VariablePrefix>
   <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>
</ExtractVariables>

Betrachten Sie den obigen Beispielrichtliniencode, um die folgende eingehende Anfrage zu verwenden:

GET http://example.com/accounts/12797282?code=DBN88271

Wenn Apigee den ExtractVariables-Richtliniencode auf die eingehende Anfrage anwendet, wird die Variable queryinfo.dbncode auf 88271 gesetzt. Nachdem Apigee die Richtlinie ausgeführt hat, können weitere Richtlinien oder Code im Verarbeitungsablauf auf die Variable queryinfo.dbncode verweisen, um den Stringwert 88271 zu erhalten.

Sie können jetzt auf die Variable queryinfo.dbncode in Ihrem Proxy zugreifen. Die folgende AssignMessage-Richtlinie kopiert beispielsweise die Variable in die Nutzlast der Anfrage:

<AssignMessage async="false" continueOnError="false" enabled="true" name="GetURIPath">
  <DisplayName>GetQP</DisplayName>
  <Set>
   <Payload contentType="text/xml">
    <ExtractQP>{queryinfo.dbncode}</ExtractQP>
   </Payload>
  </Set>
  <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>
  <AssignTo createNew="false" transport="http" type="request"/>
</AssignMessage>

Mehrere Parameter

<ExtractVariables name="ExtractVariables-2">
  <DisplayName>Extract a value from a query parameter</DisplayName>
  <Source>request</Source>
  <QueryParam name="w">
    <Pattern ignoreCase="true">{firstWeather}</Pattern>
  </QueryParam>
  <QueryParam name="w.2">
    <Pattern ignoreCase="true">{secondWeather}</Pattern>
  </QueryParam>
  <VariablePrefix>queryinfo</VariablePrefix>
  <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>
</ExtractVariables>

Angenommen, das API-Design ermöglicht die Angabe mehrerer Abfrageparameter mit demselben Namen. Sie können eine ExtractVariables-Richtlinie verwenden, um den Wert mehrerer Instanzen des Abfrageparameters zu extrahieren. Wenn auf Abfrageparameter mit demselben Namen in der Richtlinie verwiesen werden soll, verwenden Sie Indexe, bei denen die erste Instanz des Abfrageparameters keinen Index hat, die zweite bei Index 2, die dritte bei Index 3 ist usw.

Betrachten Sie den obigen Beispielrichtliniencode, um die folgende eingehende Anfrage zu verwenden:

GET http://example.com/weather?w=Boston&w=Chicago

Wenn Apigee den ExtractVariables-Richtliniencode auf die eingehende Anfrage anwendet, wird die Variable queryinfo.firstWeather auf Boston und die Variable queryInfo.secondWeather auf Chicago gesetzt.

Sie können jetzt auf die Variable queryinfo.firstWeather und queryinfo.secondWeather in Ihrem Proxy zugreifen. Die folgende AssignMessage-Richtlinie kopiert beispielsweise die Variable in die Nutzlast der Anfrage:

<AssignMessage async="false" continueOnError="false" enabled="true" name="GetURIPath">
  <DisplayName>GetQP</DisplayName>
  <Set>
    <Payload contentType="text/xml">
      <ExtractQP1>{queryinfo.firstWeather}</ExtractQP1>
      <ExtractQP2>{queryinfo.secondWeather}</ExtractQP2>
    </Payload>
  </Set>
  <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>
  <AssignTo createNew="false" transport="http" type="request"/>
</AssignMessage>

Header

<ExtractVariables name='ExtractVariable-OauthToken'>
  <Source>request</Source>
  <Header name="Authorization">
    <Pattern ignoreCase="false">Bearer {oauthtoken}</Pattern>
  </Header>
  <VariablePrefix>clientrequest</VariablePrefix>
  <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>
</ExtractVariables>

Angenommen, Ihre API verwendet OAuth 2.0-Inhabertokens. Sehen Sie sich den obigen Beispielrichtliniencode an, um eine Anfrage mit einem OAuth v2.0-Token zu verwenden, das einen Header wie den folgenden enthält: Authorization: Bearer TU08xptfFfeM7aS0xHqlxTgEAdAM.

Angenommen, Sie möchten als API-Designer den Tokenwert (nicht den gesamten Header) als Schlüssel bei einer Cache-Suche verwenden. Sie können das Token mit dem oben aufgeführten Richtliniencode „ExtractVariables“ extrahieren.

Wenn Apigee den obigen ExtractVariables-Richtliniencode auf diesen Header anwendet, wird die Variable clientrequest.oauthtoken auf TU08xptfFfeM7aS0xHqlxTgEAdAM gesetzt.

Sie können jetzt auf die Variable clientrequest.oauthtoken in Ihrem Proxy zugreifen. Die folgende AssignMessage-Richtlinie kopiert beispielsweise die Variable in die Nutzlast der Anfrage:

<AssignMessage async="false" continueOnError="false" enabled="true" name="GetURIPath">
  <DisplayName>GetHeader</DisplayName>
  <Set>
    <Payload contentType="text/xml">
      <ExtractHeader>{clientrequest.oauthtoken}</ExtractHeader>
    </Payload>
  </Set>
  <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>
  <AssignTo createNew="false" transport="http" type="request"/>
</AssignMessage>

JSON

<ExtractVariables name="ExtractVariables-3">
  <Source>response</Source>
  <JSONPayload>
    <Variable name="latitude" type="float">
      <JSONPath>$.results[0].geometry.location.lat</JSONPath>
    </Variable>
    <Variable name="longitude" type="float">
      <JSONPath>$.results[0].geometry.location.lng</JSONPath>
    </Variable>
  </JSONPayload>
  <VariablePrefix>geocoderesponse</VariablePrefix>
</ExtractVariables>

Betrachten Sie die folgende JSON-Antwortnutzlast:

{
  "results": [{
    "geometry": {
      "location": {
        "lat": 37.42291810,
        "lng": -122.08542120
      },
      "location_type": "ROOFTOP",
      "viewport": {
        "northeast": {
          "lat": 37.42426708029149,
          "lng": -122.0840722197085
        },
        "southwest": {
          "lat": 37.42156911970850,
          "lng": -122.0867701802915
        }
      }
    }
  }]
}

Wenn Apigee den obigen ExtractVariables-Richtliniencode auf diese JSON-Nachricht anwendet, werden zwei Variablen festgelegt: geocoderesponse.latitude und geocoderesponse.longitude. Beide Variablen verwenden dasselbe Variablenpräfix von geocoderesponse. Das Suffix für diese Variablen wird explizit durch das Attribut name des Elements <Variable> angegeben.

Die Variable geocoderesponse.latitude ruft den Wert 37.42291810 ab. Die Variable geocoderesponse.longitude ruft den Wert -122.08542120 ab.

Sie können jetzt auf die Variable geocoderesponse.latitude in Ihrem Proxy zugreifen. Die folgende AssignMessage-Richtlinie kopiert beispielsweise die Variable in einen Header namens latitude in der Antwort:

<AssignMessage async="false" continueOnError="false" enabled="true" name="GetURIPath">
  <DisplayName>GetJSONVar</DisplayName>
  <Add>
    <Headers>
      <Header name="latitude">{geocoderesponse.latitude}</Header>
    </Headers>
  </Add>
  <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>
  <AssignTo createNew="false" transport="http" type="response"/> 
</AssignMessage>

XML

<ExtractVariables name="ExtractVariables-4">
   <Source>response</Source>
   <XMLPayload>
      <Namespaces>
         <Namespace prefix="dir">urn:43BFF88D-D204-4427-B6BA-140AF393142F</Namespace>
      </Namespaces>
      <Variable name="travelmode" type="string">
         <XPath>/dir:Directions/dir:route/dir:leg/dir:step/@mode</XPath>
      </Variable>
      <Variable name="duration" type="string">
         <XPath>/dir:Directions/dir:route/dir:leg/dir:step/dir:duration/dir:value</XPath>
      </Variable>
      <Variable name="timeunit" type="string">
         <XPath>/dir:Directions/dir:route/dir:leg/dir:step/dir:duration/dir:text</XPath>
      </Variable>
   </XMLPayload>
   <VariablePrefix>directionsresponse</VariablePrefix>
</ExtractVariables>

Betrachten Sie die folgende XML-Antwortnutzlast:

<Directions xmlns="urn:43BFF88D-D204-4427-B6BA-140AF393142F">
   <status>OK</status>
   <route>
      <summary>I-40 W</summary>
      <leg>
         <step mode="DRIVING">
            <start_location>
               <lat>41.8507300</lat>
               <lng>-87.6512600</lng>
            </start_location>
            <end_location>
               <lat>41.8525800</lat>
               <lng>-87.6514100</lng>
            </end_location>
            <duration>
                <value>19</value>
                <text>minutes</text>
            </duration>
         </step>
      </leg>
   </route>
</Directions>

Wenn Apigee den obigen ExtractVariables-Richtliniencode auf diese XML-Nachricht anwendet, werden drei Variablen festgelegt:

  • directionsresponse.travelmode: Ruft den Wert DRIVING ab.
  • directionsresponse.duration: Ruft den Wert 19 ab.
  • directionsresponse.timeunit: Ruft den Wert minutes ab.

Alle Variablen verwenden dasselbe Variablenpräfix von directionsresponse. Das Suffix für diese Variablen wird explizit durch das Attribut name des Elements <Variable> angegeben.

Sie können jetzt auf die Variable directionresponse.travelmode in Ihrem Proxy zugreifen. Die folgende AssignMessage-Richtlinie kopiert beispielsweise die Antwort in einen Header mit dem Namen tmode in der Antwort:

<AssignMessage async="false" continueOnError="false" enabled="true" name="GetURIPath">
  <DisplayName>GetXMLVar</DisplayName>
  <Add>
    <Headers>
      <Header name="tmode">{directionsresponse.travelmode}</Header>
    </Headers>
  </Add>
  <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>
  <AssignTo createNew="false" transport="http" type="request"/>
</AssignMessage>

Informationen zur Richtlinie „ExtractVariables“

API-Entwickler erstellen API-Proxys, die sich je nach Inhalt einer Nachricht anders verhalten. Darunter fallen Header, URI-Pfade, Nutzlasten und Abfrageparameter. Häufig extrahiert der Proxy einen Teil dieses Inhalts zur Verwendung in einer Bedingungsanweisung. Verwenden Sie dazu die Richtlinie „ExtractVariables“.

Beim Definieren der Richtlinie „ExtractVariables“ können Sie Folgendes auswählen:

  • Den Namen der festzulegenden Variable
  • Die Quelle der Variablen
  • Die Anzahl der Variablen, die extrahiert und festgelegt werden sollen

Bei der Ausführung wendet die Richtlinie ein Textmuster auf den Inhalt an und legt nach dem Finden einer Übereinstimmung den Wert der angegebenen Variable mit dem Inhalt fest. Andere Richtlinien und Code können diese Variablen dann verwenden, um das dynamische Verhalten zu aktivieren oder Geschäftsdaten an Apigee API Analytics zu senden.

Umfang

Variablen, die mit der Richtlinie „ExtractVariables“ festgelegt sind, haben den Bereich global. Das heißt, nachdem die ExtractVariables-Richtlinie eine neue Variable definiert hat, können Sie auf diese Variable von jeder Richtlinie oder jedem Code in jeder Phase des Ablaufs (der nach der ExtractVariables-Richtlinie ausgeführt wird) zugreifen. Dazu zählen:

  • PreFlow: ProxyEndpoint und TargetEndpoint (Anfrage und Antwort)
  • PostFlow: ProxyEndpoint und TargetEndpoint (Anfrage und Antwort)
  • PostClientFlow: ProxyEndpoint (nur Antwort, mit der MessageLogging-Richtlinie>)
  • Fehlerabläufe

Informationen zum Abgleichen und zum Erstellen von Variablen

Die Richtlinie „ExtractVariables“ extrahiert Informationen aus einer Anfrage oder Antwort und schreibt diese Informationen in eine Variable. Geben Sie bei allen Arten von Informationen, die Sie extrahieren können, z. B. URI-Pfade oder XML-Daten, das zu vergleichende Muster und den Namen der Variablen an, in der die extrahierten Informationen gespeichert werden.

Der Musterabgleich hängt jedoch von der Extraktionsquelle ab. In den folgenden Abschnitten werden die beiden grundlegenden Kategorien von Informationen beschrieben, die Sie extrahieren können.

Übereinstimmende URI-Pfade, Abfrageparameter, Header, Formularparametern und Variablen

Beim Extrahieren von Informationen aus einem URI-Pfad, Abfrageparametern, Kopfzeilen, Formularparametern und Variablen verwenden Sie das Tag <Pattern>, um ein oder mehrere abzugleichende Muster anzugeben. Das folgende Richtlinienbeispiel zeigt beispielsweise ein einzelnes Abgleichsmuster für den URI-Pfad:

<ExtractVariables name="ExtractVariables-1">
   <Source>request</Source>
   <URIPath>
      <Pattern ignoreCase="true">/a/{pathSeg}</Pattern>
   </URIPath>
   <VariablePrefix>urirequest</VariablePrefix>
   <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>
</ExtractVariables>

In diesem Beispiel wird die Variable urirequest.pathSeg auf einen beliebigen Wert in proxy.pathsuffix festgelegt, der nach /a/ angezeigt wird. Angenommen, der Basispfad für Ihren API-Proxy lautet /basepath/v1. Bei einer eingehenden Anfrage an http://myCo.com/basepath/v1/a/b wird die Variable auf b gesetzt.

Mehrere Muster angeben

Sie können mehrere übereinstimmende Muster angeben, die <Pattern>-Tags entsprechen. Dabei gilt:

  • Alle Muster werden auf Übereinstimmungen geprüft.
  • Wenn keines der Muster übereinstimmt, führt die Richtlinie nichts aus und die Variable(n) werden nicht erstellt.
  • Wenn mehrere Muster übereinstimmen, wird das Muster mit den längsten Pfadsegmenten für die Extraktion verwendet.
  • Wenn zwei übereinstimmende Muster die gleichen längsten Pfadsegmente haben, wird das in der Richtlinie zuerst angegebene Muster zur Extraktion verwendet.

Im nächsten Beispiel erstellen Sie eine Richtlinie, die drei übereinstimmende Muster für den URI-Pfad enthält:

<ExtractVariables name="ExtractVariables-1">
  <Source>request</Source>
  <URIPath>
    <Pattern ignoreCase="true">/a/{pathSeg}</Pattern>
    <Pattern ignoreCase="true">/a/b/{pathSeg}</Pattern>
    <Pattern ignoreCase="true">/a/b/c/{pathSeg}</Pattern>
  </URIPath>
  <VariablePrefix>urirequest</VariablePrefix>
  <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>
</ExtractVariables>

Angenommen, bei einem API-Proxy mit dem Basispfad /basepath/v1 sieht die eingehende Anfrage-URL an den API-Proxy so aus:

http://myCo.com/basepath/v1/a/b

In diesem Beispiel entspricht das erste Muster dem URI und die Variable urirequest.pathSeg ist auf b gesetzt.

Wenn die Anfrage-URL so aussieht:

http://myCo.com/basepath/v1/a/b/c/d

… stimmt das dritte Muster überein und die Variable urirequest.pathSeg wird auf d gesetzt.

Muster mit mehreren Variablen angeben

Sie können mehrere Variablen im Übereinstimmungsmuster angeben. Sie geben beispielsweise ein Übereinstimmungsmuster mit zwei Variablen an:

<ExtractVariables name="ExtractVariables-1">
  <Source>request</Source>
  <URIPath>
    <Pattern ignoreCase="true">/a/{pathSeg}</Pattern>
    <Pattern ignoreCase="true">/a/b/{pathSeg}</Pattern>
    <Pattern ignoreCase="true">/a/{pathSeg1}/c/{pathSeg2}</Pattern>
  </URIPath>
  <VariablePrefix>urirequest</VariablePrefix>
  <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>
</ExtractVariables>

Nehmen wir wieder einen API-Proxy mit dem Basispfad /basepath/v1 für die URL der eingehenden Anfrage an:

http://myCo.com/basepath/v1/a/b/c/d

Die Variable urirequest.pathSeg1 ist auf b und die Variable urirequest.pathSeg2 auf d gesetzt.

Mehrere Instanzen im Muster abgleichen

Sie können Muster auch dann abgleichen, wenn mehrere Instanzen eines Elements mit demselben Namen vorhanden sind. Sie können beispielsweise eine Anfrage stellen, die mehrere Abfrageparameter oder mehrere Header mit demselben Namen enthält. Die folgende Anfrage enthält zwei Abfrageparameter namens „w“:

http://myCo.com/basepath/v1/a/b/c/d?w=1&w=2

Wenn Sie in der Richtlinie „ExtractVariables“ auf diese Abfrageparameter verweisen möchten, verwenden Sie Indexe, bei denen die erste Instanz des Abfrageparameters keinen Index hat, die zweite bei Index 2, die dritte bei Index 3 ist usw. Beispielsweise extrahiert die folgende Richtlinie den Wert des zweiten Abfrageparameters mit dem Namen „w“ in der Anfrage:

<ExtractVariables name="ExtractVariables-1">
  <Source>request</Source>
  <QueryParam name="w.2">
    <Pattern ignoreCase="true">{secondW}</Pattern>
  </QueryParam>
  <VariablePrefix>urirequest</VariablePrefix>
  <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>
</ExtractVariables>

Die Variable urirequest.secondW ist auf „2“ gesetzt. Wenn der zweite Abfrageparameter in der Anfrage ausgelassen wird, ist die Variable urirequest.secondW leer. Wenn in der Anfrage mehrere Elemente mit demselben Namen enthalten sind, sollten Sie die Indexierung verwenden.

Sonderzeichen im Muster verwenden

Beim Abgleich von URI-Pfaden können Sie im Muster die Platzhalterzeichen „*“ und „**“ verwenden, wobei Folgendes gilt:

  • „*“ entspricht allen Segmenten im Pfad
  • „**“ stimmt mit mehreren Segmenten des Pfads überein

Geben Sie beispielsweise Muster für das Element <URIPath> wie unten dargestellt an:

<URIPath>
  <Pattern ignoreCase="true">/a/*/{id}</Pattern>
  <Pattern ignoreCase="true">/a/**/{id}</Pattern>
</URIPath>

Das erste Muster gleicht Anfragen mit Pfadsuffixen ab (dem Teil des URI-Pfads nach dem Basispfad), z. B. „/a/b/c“, „/a/foo/bar“ usw. Das zweite Muster entspricht einer beliebigen Anzahl von Pfadsegmenten nach „/a/“, z. B. „/a/foo/bar/baz/c“, sowie „/a/b/c“ und „/a/foo/bar“.

Bei der Angabe von Mustern für Suchparameter, Header und Formularparameter gibt das Zeichen „*“ an, dass eine beliebige Anzahl von Zeichen abgeglichen werden soll. Wenn Sie beispielsweise einen Header abgleichen, geben Sie das Muster so an:

*;charset={encoding}

Dieses Muster entspricht den Werten „text/xml;charset=UTF-16“ und „application/xml;charset=ASCII“.

Wenn der an die Richtlinie ExtractVariables übergebene Wert ein Sonderzeichen enthält, wie z.B. „{“, verwenden Sie das Zeichen „%“, um es zu maskieren. Im folgenden Beispiel werden die Zeichen „{“ und „}“ im Muster umgangen, da sie als Literalzeichen im Wert des Abfrageparameters verwendet werden:

<QueryParam>
  <Pattern ignoreCase="true">%{user%} {name}</Pattern>
</QueryParam>

In diesem Beispiel stimmt das Muster mit dem Wert „{user} Steve“ überein, aber nicht mit dem Wert „user Steve“.

JSON- und XML-Dateien abgleichen

Wenn Sie Daten aus JSON und XML extrahieren, geben Sie in der Richtlinie ein oder mehrere <Variable>-Tags an. Das Tag <Variable> gibt den Namen der Zielvariable an, in der die extrahierten Informationen gespeichert sind, und den JsonPath (JSON) oder XPATH (XML) zu den extrahierten Informationen.

Alle <Variable>-Tags in der Richtlinie werden ausgewertet, sodass Sie mehrere Variablen aus einer einzelnen Richtlinie befüllen können. Wenn das <Variable>-Tag bei keinem gültigen Feld in der JSON- oder XML-Datei ausgewertet wird, wird die entsprechende Variable nicht erstellt.

Das folgende Beispiel zeigt eine ExtractVariables-Richtlinie, die zwei Variablen aus dem JSON-Text einer Antwort füllt:

<ExtractVariables name="ExtractVariables-3">
   <Source>response</Source>
   <JSONPayload>
      <Variable name="latitude" type="float">
         <JSONPath>$.results[0].geometry.location.lat</JSONPath>
      </Variable>
      <Variable name="longitude" type="float">
         <JSONPath>$.results[0].geometry.location.lng</JSONPath>
      </Variable>
   </JSONPayload>
   <VariablePrefix>geocoderesponse</VariablePrefix>
</ExtractVariables>

An mehreren Stelle in dieselbe Variable schreiben

Überlegen Sie sich gut, welche Variablen Sie festlegen möchten. Die Richtlinie wird sequenziell vom ersten Extraktionsmuster bis zum letzten ausgeführt. Wenn die Richtlinie von mehreren Stellen aus einen Wert in dieselbe Variable schreibt, bestimmt der letzte Schreibvorgang in der Richtlinie den Wert der Variable. (Vielleicht ist es das, was Sie möchten.)

Sie möchten beispielsweise einen Tokenwert extrahieren, der entweder in einen Abfrageparameter oder in einen Header übergeben wird, wie unten gezeigt:

<!-- If token only in query param, the query param determines the value. 
     If token is found in both the query param and header, header sets value. -->
<QueryParam name="token">
  <Pattern ignoreCase="true">{tokenValue}</Pattern>
</QueryParam>
 
<!-- Overwrite tokenValue even if it was found in query parameter. -->
<Header name="Token">
  <Pattern ignoreCase="true">{tokenValue}</Pattern>
</Header>

Kontrollieren, was geschieht, wenn keine Übereinstimmung auftritt

Wenn das Muster nicht übereinstimmt, wird die entsprechende Variable nicht erstellt. Wenn andere Richtlinien auf die Variable verweisen, kann dies zu einem Fehler führen.

Eine Möglichkeit ist, <IgnoreUnresolvedVariables> in einer Richtlinie, die auf die Variable verweist, auf true zu setzen, um die Richtlinie so zu konfigurieren, dass jede nicht auflösbare Variable als leere Zeichenfolge (null) behandelt wird:

<IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>

Elementverweis

Die Elementreferenz beschreibt die Elemente und Attribute der ExtractVariables-Richtlinie.

<ExtractVariables async="false" continueOnError="false" enabled="true" name="Extract-Variables-1">
   <DisplayName> 1</DisplayName>
   <Source clearPayload="true|false">request</Source>
   <VariablePrefix>myprefix</VariablePrefix>
   <IgnoreUnresolvedVariables>true|false</IgnoreUnresolvedVariables>
   <URIPath>
      <Pattern ignoreCase="false">/accounts/{id}</Pattern>
   </URIPath>
   <QueryParam name="code">
      <Pattern ignoreCase="true">DBN{dbncode}</Pattern>
   </QueryParam>
   <Header name="Authorization">
      <Pattern ignoreCase="false">Bearer {oauthtoken}</Pattern>
   </Header>
   <FormParam name="greeting">
      <Pattern>hello {user}</Pattern>
   </FormParam>
   <Variable name="request.content">
       <Pattern>hello {user}</Pattern>
   </Variable>
   <JSONPayload>
      <Variable name="name">
         <JSONPath>{example}</JSONPath>
      </Variable>
   </JSONPayload>
   <XMLPayload stopPayloadProcessing="false">
      <Namespaces/>
      <Variable name="name" type="boolean">
         <XPath>/test/example</XPath>
      </Variable>
   </XMLPayload>
</ExtractVariables>

Attribute des Typs <ExtractVariables>

<ExtractVariables async="false" continueOnError="false" enabled="true" name="Extract-Variables-1">

In der folgenden Tabelle werden Attribute beschrieben, die für alle übergeordneten Richtlinienelemente gelten:

Attribut Beschreibung Standard Presence
name

Der interne Name der Richtlinie. Der Wert des Attributs name kann Buchstaben, Ziffern, Leerzeichen, Bindestriche, Unterstriche und Punkte enthalten. Dieser Wert darf 255 Zeichen nicht überschreiten.

Optional können Sie das Element <DisplayName> verwenden, um die Richtlinie im Proxy-Editor der Verwaltungs-UI mit einem anderen Namen in einer natürlichen Sprache zu versehen.

 – Erforderlich
continueOnError

Legen Sie false fest, um einen Fehler zurückzugeben, wenn eine Richtlinie fehlschlägt. Dies ist für die meisten Richtlinien das erwartete Verhalten.

Legen Sie true fest, damit die Ablaufausführung auch nach dem Fehlschlagen einer Richtlinie fortgesetzt wird. Siehe auch:

 false Optional
enabled

Setzen Sie den Wert auf true, um die Richtlinie zu erzwingen.

Legen Sie false fest, um die Richtlinie zu deaktivieren. Die Richtlinie wird nicht erzwungen, selbst wenn sie mit einem Ablauf verknüpft ist.

 true Optional
async

Dieses Attribut wurde verworfen.

 false Verworfen

<DisplayName>-Element

Wird zusätzlich zum Attribut name verwendet, um die Richtlinie im Proxy-Editor der Verwaltungs-UI mit einem anderen Namen in einer natürlichen Sprache zu versehen.

<DisplayName>Policy Display Name</DisplayName>
Standard

–

Wenn Sie dieses Element weglassen, wird der Wert des Namensattributs name der Richtlinie verwendet.
Presence Optional
Typ String

<Source>-Element

(Optional) Gibt die zu parsende Variable an. Der Wert von <Source> ist standardmäßig message. Der Wert message ist kontextabhängig. In einem Anfragefluss löst message die Anfragenachricht auf. In einem Antwortfluss löst message die Antwortnachricht auf.

Obwohl Sie diese Richtlinie häufig zum Extrahieren von Informationen aus einer Anfrage- oder Antwortnachricht verwenden, können Sie sie zum Extrahieren von Informationen aus einer beliebigen Variable verwenden. Sie können sie beispielsweise verwenden, um Informationen aus einer Entität zu extrahieren, die durch die AccessEntity-Richtlinie erstellt wurde, durch Daten, die von der ServiceCallout-Richtlinie zurückgegeben wurden, oder um Daten aus einem XML- oder JSON-Objekt zu extrahieren.

Wenn <Source> nicht aufgelöst werden kann oder in einen Nicht-Nachrichtentyp aufgelöst wird, reagiert die Richtlinie nicht.

<Source clearPayload="true|false">request</Source>
Standard: Nachricht
Präsenz: Optional
Typ: String

Attribute

Attribut Beschreibung Standard Presence Typ
clearPayload

Setzen Sie den Wert auf true, wenn Sie die in <Source> angegebene Nutzlast löschen möchten, nachdem Sie Daten daraus extrahiert haben.

Verwenden Sie die Option <clearPayload> nur, wenn die Quellnachricht nach der Ausführung von ExtractVariables nicht erforderlich ist. Durch die Einstellung true wird der von der Nachricht verwendete Arbeitsspeicher freigegeben.

false

 Optional Boolesch

<VariablePrefix>-Element

(Optional) Der vollständige Variablenname wird durch Zusammenführen von <VariablePrefix>, einem Punkt und dem Namen erstellt, den Sie im Element <Pattern> oder <Variable> in {geschweifte Klammern} definieren. Beispiel: myprefix.id, myprefix.dbncode oder myprefix.oauthtoken.

<VariablePrefix>myprefix</VariablePrefix>

Nehmen wir zum Beispiel an, der Wert von „name“ sei „user“.

  • Wenn <VariablePrefix> nicht angegeben ist, werden die extrahierten Werte einer Variable namens user zugewiesen.
  • Wenn <VariablePrefix> als myprefix angegeben wird, werden die extrahierten Werte einer Variable namens myprefix.user zugewiesen.
Standard: –
Präsenz: Optional
Typ: String

<IgnoreUnresolvedVariables>-Element

Optional: Setzen Sie diesen Wert auf true, um alle nicht aufgelösten Variablen als leeren String zu behandeln (null). Setzen Sie den Wert auf false, wenn die Richtlinie einen Fehler auslösen soll, wenn eine referenzierte Variable nicht aufgelöst werden kann.

<IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>
Standard: Falsch
Präsenz: Optional
Typ: Boolesch

<URIPath>-Element

(Optional, aber weitere Informationen finden Sie in der Zeile Präsenz in der Tabelle unten). Extrahiert einen Wert aus dem proxy.pathsuffix einer request-Quellnachricht. Der für das Muster angewendete Pfad ist proxy.pathsuffix, der nicht den Basispfad für den API-Proxy enthält. Wenn die Quellnachricht in den Nachrichtentyp response aufgelöst wird, führt dieses Element nichts aus.

<URIPath>
   <Pattern ignoreCase="false">/accounts/{id}</Pattern>
</URIPath>

Es ist möglich, mehrere <Pattern>-Elemente zu verwenden:

<URIPath>
   <Pattern ignoreCase="false">/accounts/{id}</Pattern>
   <Pattern ignoreCase="false">/accounts/{id}/transactions/{index}</Pattern>
</URIPath>
Standard: –
Präsenz: Optional. Sie müssen jedoch mindestens eine der folgenden Optionen hinzufügen: <URIPath>, <QueryParam>, <Header>, <FormParam>, <JSONPayload>, or <XMLPayload>.
Typ: –

Attribute

Attribut Beschreibung Standard Presence Typ
ignoreCase Gibt an, dass die Groß-/Kleinschreibung beim Abgleich mit dem Muster ignoriert wird.

false

 Optional Boolesch

<QueryParam>-Element

(Optional, aber weitere Informationen finden Sie in der Zeile Präsenz in der Tabelle unten). Extrahiert einen Wert aus dem angegebenen Suchparameter einer request-Quellnachricht. Wenn die Quellnachricht in den Nachrichtentyp response aufgelöst wird, führt dieses Element nichts aus.

<QueryParam name="code">
   <Pattern ignoreCase="true">DBN{dbncode}</Pattern>
</QueryParam>

Wenn mehrere Suchparameter denselben Namen haben, verweisen Sie mit Indexen auf die Parameter:

<QueryParam name="w.2">
   <Pattern ignoreCase="true">{secondW}</Pattern>
</QueryParam>
Standard: –
Präsenz: Optional. Sie müssen jedoch mindestens eine der folgenden Optionen hinzufügen: <URIPath>, <QueryParam>, <Header>, <FormParam>, <JSONPayload>, or <XMLPayload>.
Typ: –

Attribute

Attribut Beschreibung Standard Presence Typ
Name Gibt den Namen des Suchparameters an. Wenn mehrere Suchparameter denselben Namen haben, verwenden Sie indexierte Verweise, bei denen die erste Instanz des Suchparameters keinen Index hat, die zweite an Index 2 verwiesen wird, die dritte an Index 3 usw.

–

 Erforderlich String

<Header>-Element

(Optional, aber weitere Informationen finden Sie in der Zeile Präsenz in der Tabelle unten). Extrahiert einen Wert aus dem angegebenen HTTP-Header der angegebenen request- oder response-Nachricht. Wenn mehrere Header denselben Namen haben, werden ihre Werte in einem Array gespeichert.

<!-- The name is the actual header name. -->
<Header name="Authorization">
<!-- Provide a name for your new custom variable here. -->
   <Pattern ignoreCase="false">Bearer {oauthtoken}</Pattern>
</Header>

Wenn mehrere Header denselben Namen haben, verweisen Sie mit Indexen auf einzelne Header im Array:

<Header name="myHeader.2">
   <Pattern ignoreCase="true">{secondHeader}</Pattern>
</Header>

Alternativ können Sie auch alle Header im Array auflisten:

<Header name="myHeader.values">
   <Pattern ignoreCase="true">{myHeaders}</Pattern>
</Header>
Standard: –
Präsenz: Optional. Sie müssen jedoch mindestens eine der folgenden Optionen hinzufügen: <URIPath>, <QueryParam>, <Header>, <FormParam>, <JSONPayload>, or <XMLPayload>.
Typ: –

Attribute

Attribut Beschreibung Standard Presence Typ
Name Gibt den Namen des Headers an, aus dem der Wert extrahiert wird. Wenn mehrere Header denselben Namen haben, verwenden Sie indexierte Verweise, bei denen die erste Instanz des Headers keinen Index hat, die zweite sich bei Index 2, die dritte bei Index 3 usw. befindet. Verwenden Sie .values, um alle Header im Array abzurufen.

–

 Erforderlich String

<FormParam>-Element

(Optional, aber weitere Informationen finden Sie in der Zeile Präsenz in der Tabelle unten). Extrahiert einen Wert aus dem angegebenen Formularparameter der angegebenen request- oder response-Nachricht. Formularparameter können nur dann extrahiert werden, wenn der Content-Type-Header der angegebenen Nachricht application/x-www-form-urlencoded lautet.

<FormParam name="greeting">
    <Pattern>hello {user}</Pattern>
</FormParam>
Standard: –
Präsenz: Optional. Sie müssen jedoch mindestens eine der folgenden Optionen hinzufügen: <URIPath>, <QueryParam>, <Header>, <FormParam>, <JSONPayload>, or <XMLPayload>.
Typ: –

Attribute

Attribut Beschreibung Standard Presence Typ
Name Der Name des Formularparameters, aus dem der Wert extrahiert wird.

–

 Erforderlich String

<Variable>-Element

(Optional, aber weitere Informationen finden Sie in der Zeile Präsenz in der Tabelle unten). Gibt den Namen einer Variablen an, aus der ein Wert extrahiert werden soll. 

<Variable name="myVar">
    <Pattern>hello {user}</Pattern>
</Variable>

So extrahieren Sie zwei Werte aus der Variable:

<Variable name="myVar">
   <Pattern>hello {firstName} {lastName}</Pattern>
</Variable>
Standard: –
Präsenz: Optional. Sie müssen jedoch mindestens eine der folgenden Optionen hinzufügen: <URIPath>, <QueryParam>, <Header>, <FormParam>, <JSONPayload>, or <XMLPayload>.
Typ: –

Attribute

Attribut Beschreibung Standard Presence Typ
Name Der Name der Variablen, aus der der Wert extrahiert werden soll.

–

 Erforderlich String

<JSONPayload>-Element

(Optional, aber weitere Informationen finden Sie in der Zeile Präsenz in der Tabelle unten). Gibt die XML-formatierte Nachricht an, aus der der Wert der Variablen extrahiert wird. Die JSON-Extraktion wird nur durchgeführt, wenn der Content-Type-Header der Nachricht application/json ist.

<JSONPayload>
   <Variable name="name" type="string">
      <JSONPath>{example}</JSONPath>
   </Variable>
</JSONPayload>
Standard: –
Präsenz: Optional. Sie müssen jedoch mindestens eine der folgenden Optionen hinzufügen: <URIPath>, <QueryParam>, <Header>, <FormParam>, <JSONPayload>, or <XMLPayload>.
Typ: –

<JSONPayload>/<Variable> Element

(Erforderlich innerhalb des JSONPayload-Elements.) Gibt die Variable an, der der extrahierte Wert zugewiesen ist. Sie können mehrere <Variable>-Tags in das <JSONPayload>-Element einfügen, um mehrere Variablen zu befüllen.

<Variable name="name" type="string">
   <JSONPath>{example}</JSONPath>
</Variable>
Standard: –
Präsenz: Erforderlich innerhalb des JSONPayload-Elements.
Typ: –

Attribute

Attribut Beschreibung Standard Presence Typ
Name

Gibt den Namen der Variablen an, der der extrahierte Wert zugewiesen wird.

Name

 Erforderlich String
Typ Gibt den Datentyp des Variablenwerts an. – Optional

String. Auswählen aus:

  • String
  • boolean
  • Ganzzahl
  • long
  • float
  • double
  • nodeset (gibt das JSON-Fragment zurück)

<JSONPayload>/<Variable>/<JSONPath> Element

(Erforderlich innerhalb des JSONPayload:Variable-Elements) Gibt den JSON-Pfad an, der zum Extrahieren eines Werts aus einer JSON-formatierten Nachricht verwendet wird. 

<Variable name="name">
  <JSONPath>$.rss.channel.title</JSONPath>
</Variable>
Standard: –
Präsenz: Erforderlich
Typ: String

<XMLPayload>-Element

(Optional, aber weitere Informationen finden Sie in der Zeile Präsenz in der Tabelle unten). Gibt die XML-formatierte Nachricht an, aus der der Wert der Variablen extrahiert wird. XML-Nutzlasten werden nur extrahiert, wenn der Content-Type-Header der Nachricht text/xml, application/xml oder application/*+xml ist.

<XMLPayload stopPayloadProcessing="false">
  <Namespaces>
    <Namespace prefix="apigee">http://www.apigee.com</Namespace>
    <Namespace prefix="gmail">http://mail.google.com</Namespace>
  </Namespaces>
  <Variable name="name" type="boolean">
    <XPath>/apigee:test/apigee:example</XPath>
  </Variable>
</XMLPayload>
Standard: –
Präsenz: Optional. Sie müssen jedoch mindestens eine der folgenden Optionen hinzufügen: <URIPath>, <QueryParam>, <Header>, <FormParam>, <JSONPayload>, or <XMLPayload>.
Typ: –

Attribute

Attribut Beschreibung Standard Presence Typ
stopPayloadProcessing

Legen Sie true, fest um die XPath-Bewertung zu beenden, wenn eine Variable befüllt ist. Das bedeutet, dass nur eine einzelne Variable von der Richtlinie befüllt wird.

false

 Optional Boolesch

<XMLPayload>/<Namespaces> Element

(Optional) Gibt den Namespace an, der bei der XPath-Bewertung verwendet werden soll. Wenn Sie in Ihren XPath-Ausdrücken Namespaces verwenden, müssen Sie die Namespaces hier angeben, wie im folgenden Beispiel gezeigt.

<XMLPayload stopPayloadProcessing="false">
  <Namespaces>
     <Namespace prefix="apigee">http://www.apigee.com</Namespace>
     <Namespace prefix="gmail">http://mail.google.com</Namespace>
  </Namespaces>
  <Variable name="legName" type="string">
    <XPath>/apigee:Directions/apigee:route/apigee:leg/apigee:name</XPath>
  </Variable>
</XMLPayload>

Wenn Sie in Ihren XPath-Ausdrücken keine Namespaces verwenden, können Sie das Element <Namespaces> auslassen oder kommentieren, wie im folgenden Beispiel gezeigt:

<XMLPayload stopPayloadProcessing="false">
  <!-- <Namespaces/> -->
  <Variable name="legName" type="string">
    <XPath>/Directions/route/leg/name</XPath>
  </Variable>
</XMLPayload>
Standard: –
Präsenz: Optional
Typ: String

Attribute

Attribut Beschreibung Standard Presence Typ
prefix

Das Namespace-Präfix.

–

 Erforderlich String

<XMLPayload>/<Variable> Element

(Optional) Gibt die Variable an, der der extrahierte Wert zugewiesen wird.

<Variable name="name" type="boolean">
   <XPath>/test/example</XPath>
</Variable>
Standard: –
Präsenz: Optional
Typ: –

Attribute

Attribut Beschreibung Standard Presence Typ
Name

Gibt den Namen der Variablen an, der der extrahierte Wert zugewiesen wird.

Name

 Erforderlich String
Typ Gibt den Datentyp des Variablenwerts an. Boolesch Optional

String. Auswählen aus:

  • String
  • boolean
  • Ganzzahl
  • long
  • float
  • double
  • nodeset (gibt ein XML-Fragment zurück)

<XMLPayload>/<Variable>/<XPath>-Element

(Erforderlich innerhalb des XMLPayloads:Variable-Elements) Gibt den für die Variable definierten XPath an. Es werden nur XPath 1.0-Ausdrücke unterstützt.

<Variable name="name" type="boolean">
   <XPath>/test/example</XPath>
</Variable>

Beispiel mit einem Namespace. Wenn Sie in Ihren XPath-Ausdrücken Namespaces verwenden, müssen Sie die Namespaces im Bereich <XMLPayload><Namespaces> der Richtlinie angeben.

<Variable name="name" type="boolean">
   <XPath>/foo:test/foo:example</XPath>
</Variable>
Standard: –
Präsenz: Erforderlich
Typ: String

Fehlerreferenz

In diesem Abschnitt werden die zurückgegebenen Fehlercodes und Fehlermeldungen beschrieben, die von Apigee festgelegt werden, wenn die Richtlinie einen Fehler auslöst. Diese Informationen sind wichtig, wenn Sie Fehlerregeln zur Verarbeitung von Fehlern entwickeln. Weitere Informationen finden Sie unter Was Sie über Richtlinienfehler wissen müssen und Fehler beheben.

Laufzeitfehler

Diese Fehler können bei Ausführung der Richtlinie auftreten.

Fehlercode HTTP-Status Ursache Beheben
steps.extractvariables.ExecutionFailed 500

Dieser Fehler tritt in folgenden Fällen auf:

  • die Eingabe-Nutzlast (JSON, XML) leer ist.
  • die an die Richtlinie übergebene Eingabe (JSON, XML usw.) ungültig oder fehlerhaft ist.
steps.extractvariables.ImmutableVariable 500 Eine in der Richtlinie verwendete Variable ist unveränderlich. Diese Variable konnte von der Richtlinie nicht festgelegt werden. –
steps.extractvariables.InvalidJSONPath 500 Dieser Fehler tritt auf, wenn im JSONPath-Element der Richtlinie ein ungültiger JSON-Pfad verwendet wird. Wenn beispielsweise eine JSON-Nutzlast das Objekt Name nicht enthält, Sie aber Name als Pfad in der Richtlinie angeben, tritt dieser Fehler auf.
steps.extractvariables.JsonPathParsingFailure 500 Dieser Fehler tritt auf, wenn die Richtlinie einen JSON-Pfad nicht parsen und keine Daten aus der im Element Source angegebenen Flussvariable extrahieren kann. Dies geschieht normalerweise, wenn die im Element Source angegebene Flussvariable im aktuellen Ablauf nicht vorhanden ist.
steps.extractvariables.SetVariableFailed 500 Dieser Fehler tritt auf, wenn die Richtlinie den Wert nicht auf eine Variable setzen konnte. Der Fehler tritt in der Regel auf, wenn Sie Werte für mehrere Variablen zuweisen möchten, deren Namen mit den gleichen Begriffen in einem verschachtelten, durch Punkte getrennten Format beginnen.
steps.extractvariables.SourceMessageNotAvailable 500 Dieser Fehler tritt auf, wenn auf die Variable message, die im Element Source der Richtlinie angegeben ist, einer der folgenden Punkte zutrifft:
  • außerhalb des Geltungsbereichs (nicht im spezifischen Ablauf verfügbar, in dem die Richtlinie ausgeführt wird) oder
  • kann nicht gelöst werden (ist nicht definiert)
steps.extractvariables.UnableToCast 500 Dieser Fehler tritt auf, wenn die Richtlinie den extrahierten Wert nicht in eine Variable umwandeln konnte. Dies ist in der Regel der Fall, wenn Sie versuchen, den Wert eines Datentyps auf die Variable eines anderen Datentyps festzulegen.

Bereitstellungsfehler

Diese Fehler können auftreten, wenn Sie einen Proxy mit dieser Richtlinie bereitstellen.

Fehlername Ursache Beheben
NothingToExtract Wenn die Richtlinie keines der Elemente URIPath, QueryParam, Header, FormParam, XMLPayload oder JSONPayload enthält, schlägt die Bereitstellung des API-Proxys fehl, weil es nichts zu extrahieren gibt.
NONEmptyPrefixMappedToEmptyURI Dieser Fehler tritt auf, wenn im Namespace-Element unter dem XMLPayload-Element ein Präfix definiert ist, aber kein URI.
DuplicatePrefix Dieser Fehler tritt auf, wenn in der im Element Namespace unter dem Element XMLPayload dasselbe Element mehrmals definiert ist.
NoXPathsToEvaluate Wenn die Richtlinie im Element XMLPayload das Element XPath nicht enthält, schlägt die Bereitstellung des API-Proxys mit diesem Fehler fehl.
EmptyXPathExpression Wenn die Richtlinie im Element XMLPayload einen leeren XPath-Ausdruck enthält, schlägt die Bereitstellung des API-Proxys fehl.
NoJSONPathsToEvaluate Wenn die Richtlinie im Element JSONPayload das Element JSONPath nicht enthält, schlägt die Bereitstellung des API-Proxys mit diesem Fehler fehl.
EmptyJSONPathExpression Wenn die Richtlinie im Element XMLPayload einen leeren XPath-Ausdruck enthält, schlägt die Bereitstellung des API-Proxys fehl.
MissingName Wenn die Richtlinie das Attribut name in keinem der Richtlinienelemente wie QueryParam, Header, FormParam oder Variable enthält, wo dies erforderlich ist, dann schlägt die Bereitstellung des API-Proxys fehl.
PatternWithoutVariable Wenn in der Richtlinie im Element Pattern keine Variable angegeben ist, schlägt die Bereitstellung des API-Proxys fehl. Das Element Pattern erfordert den Namen der Variablen, in der extrahierte Daten gespeichert werden.
CannotBeConvertedToNodeset Wenn die Richtlinie einen Ausdruck XPath enthält, bei dem der Typ Variable als nodeset definiert ist, der Ausdruck jedoch nicht in ein Knotengruppe konvertiert werden kann, dann wird die Bereitstellung der API bereitgestellt. Proxy schlägt fehl.
JSONPathCompilationFailed Die Richtlinie konnte keinen angegebenen JSON-Pfad kompilieren. –
InstantiationFailed Die Richtlinie konnte nicht instanziiert werden. –
XPathCompilationFailed Wenn das Präfix oder der Wert, der im Element XPath verwendet wird, zu keinem der angegebenen Namespaces in der Richtlinie gehört, schlägt die Bereitstellung des API-Proxys fehl.
InvalidPattern Wenn die Definition des Pattern-Elements in einem der Elemente wie URIPath, QueryParam, Header, FormParam, XMLPayload oder JSONPayload in der Richtlinie ungültig ist, dann schlägt die Bereitstellung des API-Proxys fehl.

Fehlervariablen

Diese Variablen werden festgelegt, wenn diese Richtlinie zur Laufzeit einen Fehler auslöst. Weitere Informationen finden Sie unter Was Sie über Richtlinienfehler wissen müssen.

Variablen Wo Beispiel
fault.name="fault_name" fault_name ist der Name des Fehlers, der in der obigen Tabelle Laufzeitfehler aufgeführt ist. Der Fehlername ist der letzte Teil des Fehlercodes. fault.name = "SourceMessageNotAvailable"
extractvariables.policy_name.failed policy_name ist der benutzerdefinierte Name der Richtlinie, die den Fehler ausgelöst hat. extractvariables.EV-ParseJsonResponse.failed = true

Beispiel für eine Fehlerantwort

{
   "fault":{
      "detail":{
         "errorcode":"steps.extractvariables.SourceMessageNotAvailable"
      },
      "faultstring":"request message is not available for ExtractVariable: EV-ParseJsonResponse"
   }
}

Beispiel für eine Fehlerregel

<FaultRule name="Extract Variable Faults">
    <Step>
        <Name>AM-CustomErrorMessage</Name>
        <Condition>(fault.name = "SourceMessageNotAvailable") </Condition>
    </Step>
    <Condition>(extractvariables.EM-ParseJsonResponse.failed = true) </Condition>
</FaultRule>

Schemas

Weitere Informationen

Referenz zu Ablaufvariablen