Richtlinienzusammensetzung verwenden

<AssignMessage name="GenerateGeocodingRequest">
  <AssignTo createNew="true" type="request">GeocodingRequest</AssignTo>
  <Set>
    <QueryParams>
      <QueryParam name="address">{request.queryparam.postalcode}</QueryParam>
      <QueryParam name="region">{request.queryparam.country}</QueryParam>
      <QueryParam name="sensor">false</QueryParam>
    </QueryParams>
    <Verb>GET</Verb>
  </Set>
  <!-- Set variables for use in the final response -->
  <AssignVariable>
    <Name>PostalCode</Name>
    <Ref>request.queryparam.postalcode</Ref>
  </AssignVariable>
  <AssignVariable>
    <Name>Country</Name>
    <Ref>request.queryparam.country</Ref>
  </AssignVariable>
</AssignMessage>

Hier ist eine kurze Beschreibung der Elemente in dieser Richtlinie. Weitere Informationen zu dieser Richtlinie finden Sie unter Assign Message policy.

• <AssignMessage name> : Gibt dieser Richtlinie einen Namen. Der Name wird verwendet, wenn in einem Ablauf auf die Richtlinie verwiesen wird.
• <AssignTo> : Erstellt eine benannte Variable namens „GeocodingRequest“. Diese Variable kapselt das Anfrageobjekt, das von der ServiceCallout-Richtlinie an das Back-End gesendet wird.
• <QueryParams> : Legt die Abfrageparameter fest, die für den Back-End-API-Aufruf erforderlich sind. In diesem Fall muss die Geocoding API den Standort kennen, der mit einer Postleitzahl und einer Länder-ID angegeben wird. Der App-Nutzer gibt diese Informationen an und wir extrahieren sie hier einfach. Der sensor Parameter ist für die API erforderlich und ist entweder „true“ oder „false“. Wir codieren ihn hier einfach als „false“.
• <Verb> : In diesem Fall senden wir eine einfache GET-Anfrage an die API.
• <AssignVariable> : In diesen Variablen werden die Werte gespeichert, die wir an die API übergeben. In diesem Beispiel werden die Variablen später in der Antwort verwendet, die an den Client zurückgegeben wird.

Anfrage mit ServiceCallout senden

Der nächste Schritt in der Richtlinienkompositionssequenz ist das Erstellen einer ServiceCallout-Richtlinie. Die unten aufgeführte ServiceCallout-Richtlinie sendet das Anfrageobjekt, das wir in der vorherigen AssignMessage-Richtlinie erstellt haben, an den Google Geocoding-Dienst und speichert das Ergebnis in einer Variablen namens „GeocodingResponse“.

<ServiceCallout name="ExecuteGeocodingRequest">
  <Request variable="GeocodingRequest"/>
  <Response>GeocodingResponse</Response>
  <HTTPTargetConnection>
    <URL>http://maps.googleapis.com/maps/api/geocode/json</URL>
  </HTTPTargetConnection>
</ServiceCallout>

Hier ist eine kurze Beschreibung der Elemente dieser Richtlinie.

• <ServiceCallout> : Wie bei der vorherigen Richtlinie hat auch diese einen Namen.
• <Request variable> : Dies ist die Variable, die in der AssignMessage-Richtlinie erstellt wurde. Sie kapselt die Anfrage an die Back-End-API.
• <Response> : Dieses Element gibt eine Variable an, in der die Antwort gespeichert wird. Wie Sie sehen, wird später von der ExtractVariables Richtlinie auf diese Variable zugegriffen.
• <HTTPTargetConnection> : Gibt die Ziel-URL der Back-End API an. In diesem Fall geben wir an, dass die API eine JSON-Antwort zurückgeben soll.

Jetzt haben wir zwei Richtlinien: eine, die die Anfragedaten angibt, die für die Verwendung der Back-End-API (Google Geocoding API) erforderlich sind, und eine zweite, die die Anfrage tatsächlich an die Back-End-API sendet. Als Nächstes verarbeiten wir die Antwort.

<ExtractVariables name="ParseGeocodingResponse">
  <Source>GeocodingResponse</Source>
  <VariablePrefix>geocoderesponse</VariablePrefix>
  <JSONPayload>
    <Variable name="latitude">
       <JSONPath>$.results[0].geometry.location.lat</JSONPath>
    </Variable>
    <Variable name="longitude">
       <JSONPath>$.results[0].geometry.location.lng</JSONPath>
    </Variable>
  </JSONPayload>
</ExtractVariables>

Die wichtigsten Elemente der ExtractVariables-Richtlinie sind:

• <ExtractVariables name> : Auch hier wird der Richtlinienname verwendet, um auf die Richtlinie zu verweisen, wenn sie in einem Ablauf verwendet wird.
• <Source> : Gibt die Antwortvariable an, die wir in der ServiceCallout-Richtlinie erstellt haben. Aus dieser Variablen werden Daten von dieser Richtlinie extrahiert.
• <VariablePrefix> : Das Variablenpräfix gibt einen Namespace für andere Variablen an, die in dieser Richtlinie erstellt wurden. Das Präfix kann ein beliebiger Name sein, mit Ausnahme der reservierten Namen, die durch die vordefinierten Variablen von Edge definiert werden.
• <JSONPayload> : Dieses Element ruft die Antwortdaten ab, die für uns von Interesse sind, und fügt sie in benannte Variablen ein. Tatsächlich gibt die Geocoding API viel mehr Informationen als nur Breiten- und Längengrad zurück. Diese Werte sind jedoch die einzigen, die wir für dieses Beispiel benötigen. Eine vollständige Darstellung des von der Geocoding API zurückgegebenen JSON finden Sie in der Dokumentation der API. Die Werte von „geometry.location.lat“ und „geometry.location.lng“ sind einfach zwei der vielen Felder im zurückgegebenen JSON-Objekt.

Es ist vielleicht nicht offensichtlich, aber es ist wichtig zu wissen, dass ExtractVariables zwei Variablen erzeugt, deren Namen aus dem Variablenpräfix (geocoderesponse) und den tatsächlichen Variablennamen bestehen, die in der Richtlinie angegeben sind. Diese Variablen werden im API-Proxy gespeichert und sind für andere Richtlinien im Proxyablauf verfügbar, wie Sie sehen werden. Die Variablen sind:

• geocoderesponse.latitude
• geocoderesponse.longitude

Die meiste Arbeit ist jetzt erledigt. Wir haben eine Komposition aus drei Richtlinien erstellt, die eine Anfrage bilden, eine Back-End-API aufrufen und die zurückgegebenen JSON-Daten parsen. In den letzten Schritten werden wir Daten aus diesem Teil des Ablaufs in eine weitere AssignMessage-Richtlinie einfügen, die zweite Back-End- API (Google Elevation API) aufrufen und unsere kombinierten Daten an den App-Entwickler zurückgeben.

<AssignMessage name="AssignElevationParameters">
<Remove>
    <QueryParams>
      <QueryParam name="country"/>
      <QueryParam name="postalcode"/>
    </QueryParams>
  </Remove>
  <Set>
    <QueryParams>
      <QueryParam name="locations">{geocoderesponse.latitude},{geocoderesponse.longitude}</QueryParam>
      <QueryParam name="sensor">false</QueryParam>
    </QueryParams>
  </Set>
</AssignMessage>

Wenn Sie sich die Google Elevation API ansehen, werden Sie feststellen, dass sie zwei Abfrageparameter akzeptiert. Der erste heißt locations und sein Wert ist der Breiten- und Längengrad (durch Kommas getrennte Werte). Der andere Parameter ist sensor, der erforderlich ist und entweder „true“ oder „false“ sein muss. Das Wichtigste an dieser Stelle ist, dass für die hier erstellte Anfragenachricht keine ServiceCallout-Richtlinie erforderlich ist. Wir müssen die zweite API an dieser Stelle nicht über eine ServiceCallout-Richtlinie aufrufen, da wir die Back-End-API über den TargetEndpoint des Proxys aufrufen können. Wenn Sie darüber nachdenken, haben wir alle Daten, die wir zum Aufrufen der Google Elevation API benötigen. Für die in diesem Schritt generierte Anfragenachricht ist keine ServiceCallout-Richtlinie erforderlich, da die Anfrage für die Hauptanfragepipeline generiert wurde und daher einfach vom ProxyEndpoint an den TargetEndpoint weitergeleitet wird, gemäß der für diesen API-Proxy konfigurierten RouteRule. Der TargetEndpoint verwaltet die Verbindung mit der Remote API. Die URL für die Elevation API ist in der HTTPConnection für den TargetEndpoint definiert. Dokumentation zur Elevation API Die zuvor gespeicherten QueryParams country und postalcode werden nicht mehr benötigt und daher hier entfernt.

Kurze Pause: Zurück zum Ablauf

An dieser Stelle fragen Sie sich vielleicht, warum wir keine weitere ServiceCallout-Richtlinie erstellen. Wir haben schließlich eine weitere Nachricht erstellt. Wie wird diese Nachricht an das Ziel, die Google Elevation API, gesendet? Die Antwort finden Sie im Element <RouteRule> des Ablaufs. <RouteRule> gibt an, was mit allen verbleibenden Anfragenachrichten geschehen soll, nachdem der Teil <Request> von dem Ablauf ausgeführt wurde. Der von dieser <RouteRule> angegebene TargetEndpoint weist den API-Proxy an, die Nachricht an http://maps.googleapis.com/maps/api/elevation/xml zu senden.

Wenn Sie den Beispiel-API-Proxy heruntergeladen haben, finden Sie die TargetProxy-XML-Datei unter doc-samples/policy-mashup-cookbook/apiproxy/targets/default.xml.

<TargetEndpoint name="default">
  <HTTPTargetConnection>
    <!-- This is where we define the target. For this sample we just use a simple URL. -->
    <URL>http://maps.googleapis.com/maps/api/elevation/xml</URL>
  </HTTPTargetConnection>
</TargetEndpoint>

Jetzt müssen wir nur noch die Antwort von der Google Elevation API verarbeiten und sind fertig.

$ curl "http://{myorg}-test.apigee.net/policy-mashup-cookbook?country=us&postalcode=08008"

Die Antwort enthält den geocodierten Standort für das Zentrum der vom App-Endnutzer angegebenen Postleitzahl in Kombination mit der Höhe an diesem geocodierten Standort. Die Daten wurden aus zwei Back-End-APIs abgerufen, mit Richtlinien kombiniert, die an den API-Proxy angehängt wurden, und in einer einzigen Antwort an den Client zurückgegeben.

{  
   "country":"us",
   "postalcode":"08008",
   "elevation":{  
      "meters":0.5045232,
      "feet":1.6552599030345978
   },
   "location":{  
      "latitude":39.75007129999999,
      "longitude":-74.1357407
   }
}

Zusammenfassung

In diesem Cookbook-Thema wurde erläutert, wie Sie mit dem Muster der Richtlinienkomposition ein Mashup aus Daten aus mehreren Back-End-Quellen erstellen. Die Richtlinienkomposition ist ein gängiges Muster, das bei der API Proxy-Entwicklung verwendet wird, um Ihrer API kreative Funktionen hinzuzufügen.