16.08.17 – Versionshinweise zu Apigee Edge for Public Cloud

Sie lesen gerade die Dokumentation zu Apigee Edge.
Apigee X-Dokumentation aufrufen.
info

Am Dienstag, dem 30. August 2016, haben wir eine neue Version von Apigee Edge für die öffentliche Cloud veröffentlicht.

Neue Features und Updates

Im Folgenden sind die neuen Features und Aktualisierungen in diesem Release aufgeführt:

JSON-Nutzlasten in „Assign Message“ und „Raise Fault“

Wenn eine JSON-Nutzlast mit einer AssignMessage- oder RaiseFault-Richtlinie festgelegt wurde, mussten Nutzer manchmal Umgehungen verwenden, um sicherzustellen, dass eine JSON-Nachricht zur Laufzeit richtig formatiert wurde. Dazu gehörte beispielsweise, die Nutzlast mit einem Backslash „\“ zu beginnen oder ein „variablePrefix“ und „variableSuffix“ für das Payload-Element anzugeben, auch wenn keine Variablen in der Nachricht verwendet wurden.

Durch diese Verbesserung sind keine Workarounds mehr erforderlich, um eine korrekte Formatierung von JSON-Nachrichten zu gewährleisten. Variablen können mit geschweiften Klammern angegeben werden, ohne dass ungültiges JSON entsteht. Im folgenden Beispiel wird der Wert von „message.content“ in die JSON-Nachricht eingefügt:

<Payload contentType="application/json">{"message" : "{message.content}"}</Payload>

Wenn Sie einen Workaround verwendet haben, funktioniert Ihr Code weiterhin wie bisher. Sie können auch „variablePrefix“ und „variableSuffix“ anstelle von geschweiften Klammern verwenden, um Variablen anzugeben.

Weitere Informationen finden Sie in der Assign Message-Richtlinie und der Raise Fault-Richtlinie. (APIRT-1160)

Verbesserungen bei der „XML-to-JSON“-Richtlinie

Die XML-zu-JSON-Richtlinie wurde um die folgenden Funktionen erweitert. Sie können die Richtlinie so konfigurieren:

  • Einige XML-Elemente werden bei der Konvertierung als Arrays behandelt, wodurch die Werte im JSON-Dokument in eckige Klammern „[ ]“ gesetzt werden.
  • Entfernen Sie Ebenen der XML-Dokumenthierarchie im endgültigen JSON-Dokument.

Weitere Informationen finden Sie unter XML-to-JSON-Richtlinie. (APIRT-1144)

Mehrere Platzhalter in API-Produkt-Ressourcenpfaden

Wenn Sie Ressourcenpfade in einem API-Produkt definieren, können Sie Platzhalter an mehreren Stellen in einem Ressourcenpfad einfügen. Mit /team/*/invoices/** sind beispielsweise API-Aufrufe mit einem beliebigen Wert nach /team und beliebigen Ressourcenpfaden nach invoices/ möglich. Ein zulässiger URI für einen API-Aufruf wäre proxyBasePath/team/finance/invoices/company/a.

Wenn Ihre vorhandenen API-Produktressourcenpfade nach dieser Version nicht mehr wie erwartet funktionieren, legen Sie die folgende Eigenschaft für Ihre Organisation fest, um zum vorherigen Verhalten zurückzukehren: features.enableStandardWildCardMatchForAPIProductResources = true

(MGMT-3273)

Kryptofunktionen in JavaScript

Es ist eine neue Reihe von leistungsstarken JavaScript-crypto-Funktionen verfügbar, mit denen die folgenden Hash-Objekte erstellt, abgerufen und aktualisiert werden können: MD5, SHA-1, SHA256, SHA512. Mit dem crypto-Objekt können Sie das Datum auch in verschiedenen Formaten abrufen. Weitere Informationen finden Sie unter JavaScript-Objektmodell. (APIRT-2886)

Java-Callout-JAR-Version prüfen

Wenn Sie eine Java-JAR-Ressource in einen API-Proxy hochladen, wird der HTTP-Statuscode 400 (anstatt 500) zurückgegeben, wenn die Version der Java-Ressource nicht mit der von Edge unterstützten Java-Version kompatibel ist, die unter Unterstützte Software und unterstützte Versionen aufgeführt ist. (MGMT-3420)

Überprüfung von API-Proxy-Ressourcen

Wenn Sie API-Proxy-Ressourcendateien (z. B. JavaScript- oder Java-JARs) auf Umgebungsebene oder Organisationsebene gespeichert haben, müssen Sie diese Ressourcen nicht mehr auch auf API-Proxy-Ebene in ein Proxy-Bundle einfügen, damit der Import die Validierung besteht. Die Ressourcenvalidierung erfolgt jetzt bei der Bereitstellung und nicht beim Import. (MGMT-1430)

Zeitlimit für einzelne API-Proxys konfigurieren

Sie können API-Proxys so konfigurieren, dass nach einer bestimmten Zeit eine Zeitüberschreitung auftritt (mit dem Status „504 Gateway Timeout“). Der primäre Anwendungsfall ist für Private Cloud-Kunden, deren API-Proxys länger für die Ausführung benötigen. Angenommen, Sie benötigen bestimmte Proxy-Zeitüberschreitungen nach 3 Minuten. Sie können eine neue api.timeout-Property in der Konfiguration für einen API-Proxy verwenden. So gehts:

  1. Konfigurieren Sie zuerst den Load-Balancer, den Router und den Nachrichtenprozessor so, dass nach 3 Minuten eine Zeitüberschreitung auftritt.
  2. Konfigurieren Sie anschließend die relevanten Proxy-Zeitüberschreitungen nach 3 Minuten. Geben Sie den Wert in Millisekunden an. Beispiel:
    <ProxyEndpoint name="default">
      <HTTPProxyConnection>
        <BasePath>/v1/weather</BasePath>
        <Properties>
          <!-- api.timeout is in milliseconeds -->
          <Property name="api.timeout">180000</Property>
        </Properties>
        ...
  3. Beachten Sie jedoch, dass das Erhöhen der Systemzeitüberschreitungen zu Leistungsproblemen führen kann, da alle Proxys ohne die Einstellung „api.timeout“ den neuen, höheren Load-Balancer, Router und Nachrichtenprozessorzeitüberschreitungen verwenden. Konfigurieren Sie daher andere API-Proxys, die keine längeren Zeitüberschreitungen erfordern, um niedrigere Zeitüberschreitungen zu verwenden. Im folgenden Beispiel wird festgelegt, dass ein API-Proxy nach einer Minute mit einer Zeitüberschreitung abläuft:
    <Property name="api.timeout">60000</Property>

Cloud-Kunden, die die Edge-Zeitüberschreitungen nicht ändern können, können auch ein API-Proxy-Zeitlimit konfigurieren, solange das Zeitlimit kürzer als das standardmäßige Edge-Nachrichtenprozessor-Zeitlimit von 57 Sekunden ist.

Sie können den Wert nicht mit einer Variable festlegen. Dieses Attribut wird in der Referenz für Endpunktattribute beschrieben. (APIRT-1778)

TLS/SSL für die MessageLogging-Richtlinie

<KeyStore> und <TrustStore> können in der SSLInfo-Konfiguration der Richtlinie zum Nachrichtenlogging festgelegt werden, sodass unidirektionales und bidirektionales TLS/SSL mit einem Logging-Dienst möglich ist. Sie konfigurieren SSLInfo in der Message Logging-Richtlinie auf dieselbe Weise wie in einem TargetEndpoint des Proxys. Das TCP-Protokoll wird jedoch nur für TLS/SSL für das Nachrichten-Logging unterstützt. (APIRT-1858)

Fehlerkorrekturen

Folgende Fehler wurden in diesem Release behoben. Diese Liste ist hauptsächlich für Nutzer gedacht, die prüfen möchten, ob ihre Support-Tickets erfolgreich bearbeitet wurden. Sie enthält keine detaillierten Informationen für allgemeine Nutzer.

Problem-ID Description
SECENG-609 Laufzeitaufrufe schlagen nicht fehl, wenn der zugehörige Truststore gelöscht wird oder wenn das gültige Zertifikat im Truststore gelöscht wird
MGMT-3404 Das Aufrufen/Abrufen von Node.js-Logs und das Bereitstellen von Proxys ist sehr langsam.
MGMT-3400 Aufruf der Management-API für /userroles schlägt fehl, wenn der Nutzer, der den Aufruf ausführt, ein „+“-Zeichen im Namen hat
MGMT-3368 java.lang.ArrayIndexOutOfBoundsException: 1 beim Importieren eines API-Proxy-Bundles, das das Verzeichnis „resources/node/resources“ enthält
MGMT-3364 OAuthV2: redirect_uri-Prüfung
MGMT-3319 Listeneinträge in einem Tresor mit einem Nullwert in einem der Einträge funktionieren nicht für Organisationen (CPS und nicht CPS)
MGMT-3226 Beim Abfragen auf Organisations-/Umgebungsebene sollten nicht alle Daten abgerufen werden, was zu einem API-Fehler führt.
In Release 160302 gab es einen Fehler, bei dem die Auflistung von Ressourcen auf Organisations-/Umgebungsebene fehlschlug, wenn die kumulative Größe der Ressourcen über 16 MB lag. Dieser Fehler wurde behoben.
AXAPP-2429 Analytics API gibt mit response_status_code einen Datenzugriffsfehler zurück
AXAPP-2386 Leere Berichte in täglichen Analytics-E‑Mail-Berichten korrigieren
AXAPP-2347 Ich erhalte keine täglichen Analytics-Zusammenfassungs-E-Mails.
APIRT-3141 Java-Callouts schlagen fehl, wenn „new ExecutionResult()“ aufgerufen wird, da der Konstruktor privat ist
APIRT-3140 ServiceCallout-Richtlinie funktioniert nicht bei HEAD-API-Aufrufen
APIRT-3131 Falscher Wert für „createdBy“ für einen API-Proxy, wenn die Monetarisierung mit einem externen Authentifizierungsanbieter verwendet wird
APIRT-3121 Änderung an der Organisationsressourcendatei wird nicht zu 100% wirksam
APIRT-3117 MP hat 100% CPU-Auslastung erreicht und stellt keinen Traffic mehr bereit
APIRT-3016 Fehler vom Typ „Zeitüberschreitung bei Anruf“ für Router bei Bereitstellungen
APIRT-2975 Fehler beim Hochladen des Zertifikats
APIRT-2955 Bestimmte Attribute von JSON-Antwortdaten für FHIR-kompatiblen Content-Type-Header 'application/json+fhir' können nicht maskiert werden
APIRT-2946 OAuthV2-RefreshToken-Richtlinie blendet Attribute nicht aus, obwohl „display“ auf „false“ gesetzt ist
APIRT-2908 TLS 1.2 für interne API-Aufrufe muss nach der TLS 1.2-Aktualisierung für den virtuellen Host erzwungen werden.
APIRT-2901 Aus dem Cache zurückgegebene gezippte Antworten werden doppelt komprimiert
APIRT-2873 MPs throw NullPointerException related to VerifyAPIKey after deletion of products/developers/proxies (MPs lösen NullPointerException im Zusammenhang mit VerifyAPIKey nach dem Löschen von Produkten/Entwicklern/Proxys aus)
APIRT-2871 IOIntensive-Richtlinien werden zweimal im Trace angezeigt
APIRT-2825 Grammatikfehler in der Fehlerantwort für das Zugriffstoken
APIRT-2750 Hohe Anzahl von Traffic-Fehlern in bestimmter Organisation
APIRT-2685 Traffic kann nicht fließen, da ein unbekannter Fehler ausgegeben wird
APIRT-2647 Fehler „Underlying input stream returned zero bytes“ (Der zugrunde liegende Eingabestream hat null Byte zurückgegeben) in Nicht-Produktions-/Entwicklungsumgebungen
APIRT-2630 Zeitweise Probleme beim Lesen von Werten aus dem Cache
APIRT-2620 Separate Thread-Pools für einige blockierende Schritte
APIRT-2610 java.lang.ClassCastException mit der Antwort-Cache-Richtlinie
APIRT-2608 Fehler beim Parsen von „Last-Modified“-Headern in ResponseCache-Richtlinien
APIRT-2605 Die Variablen „organization“ und „environment“ dürfen nicht über Richtlinien überschrieben werden.
APIRT-2566 Die OAuthV2-Richtlinie gibt einen fehlerhaften WWW-Authenticate-Header zurück.
APIRT-2491 TargetServer-Update ist aufgrund von RPC-Zeitüberschreitung zwischen Management und MPS fehlgeschlagen
APIRT-2386 In einem API-Produkt mit leeren „Zulässige OAuth-Bereiche“ wird ein leerer Stringbereich erstellt.
APIRT-2383 Bei einem Fehler werden in XSL-Transformationsrichtlinien anscheinend keine Daten protokolliert.
APIRT-2364 OAuth-Fehlerablaufvariablen werden bei einem Fehler nicht aktualisiert
APIRT-2216 Server-Sent Events – Probleme mit Eventstream in der Produktion
APIRT-2079 DEBUG-cURL-Aufruf wird nach Ablauf des Zeitlimits für die erstellte Sitzung nicht beendet
APIRT-1495 XML-Bedrohungsschutz erkennt den FHIR-Content-Type nicht
APIRT-347 Die XSL-Richtlinie wird beim Import nicht richtig validiert (es werden keine Ergebnisse den Ausgabevariablen zugewiesen, wie dokumentiert).