16.08.17 – Versionshinweise zu Apigee Edge for Public Cloud

<ph type="x-smartling-placeholder"></ph> Sie sehen die Dokumentation zu Apigee Edge.
Gehen Sie zur Apigee X-Dokumentation.
Weitere Informationen

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

<ph type="x-smartling-placeholder">

Neue Features und Updates

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

JSON-Nutzlasten in „Zuweisen“ Fehler melden und melden

Beim Festlegen einer JSON-Nutzlast mit einer Richtlinie zum Zuweisen von Nachrichten oder zum Auslösen eines Fehlers wurden Nutzer manchmal erforderlich, um Problemumgehungen zu verwenden, um sicherzustellen, dass eine JSON-Nachricht zur Laufzeit richtig formatiert wurde, z. B. am Anfang der Nutzlast mit einem umgekehrten Schrägstrich "\" oder die Angabe von „variablePrefix“ und „variableSuffix“ das Payload-Element hinzufügen, auch wenn in der Nachricht keine Variablen verwendet wurden.

Bei dieser Verbesserung sind keine Behelfslösungen erforderlich, um die korrekte Formatierung von JSON-Nachrichten sicherzustellen. Variablen können mit geschweiften Klammern angegeben werden, ohne dass ein ungültiges JSON-Format erstellt wird. Beispiel: Der Parameter Mit dem folgenden Code wird der Wert von message.content in die JSON-Nachricht eingefügt:

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

Wenn Sie eine Behelfslösung angewendet haben, funktioniert Ihr Code weiterhin unverändert. Sie können auch variablePrefix und variableSuffix anstelle von geschweiften Klammern kennzeichnen Variablen.

Siehe <Set><Payload> in der Richtlinie zum Zuweisen von Nachrichten und Richtlinie zur Fehlererhöhung Referenzdokumente. (APIRT-1160)

Verbesserungen der XML-zu-JSON-Richtlinie

Die Richtlinie „XML zu JSON“ wurde um die folgenden Funktionen erweitert. Sie können die Richtlinie, um:

  • Einige XML-Elemente während der Konvertierung als Arrays behandeln, wodurch die Werte quadriert werden eckige Klammern '[ ]' im JSON-Dokument.
  • Entfernen oder entfernen Sie Ebenen der XML-Dokumenthierarchie im endgültigen JSON-Dokument.

Weitere Informationen finden Sie unter XML gemäß der JSON-Richtlinie. (APIRT-1144)

Mehrere Platzhalter in API-Produktressourcenpfade

Wenn Sie Ressourcenpfade im API-Produkt definieren, können Sie Platzhalter an mehreren Stellen in einem Ressourcenpfad. Beispielsweise erlaubt /team/*/invoices/** API-Aufrufe mit beliebigen ein Wert nach /team und alle Ressourcenpfade nach dem invoices/. Ein zulässiger URI in einem API-Aufruf würde proxyBasePath/team/finance/invoices/company/a sein.

Wenn Ihre vorhandenen API-Produktressourcenpfade nach dieser Version nicht mehr wie erwartet funktionieren, legen Sie die folgende Property in Ihrer Organisation an, um zur vorherigen Verhalten: features.enableStandardWildCardMatchForAPIProductResources = true

(MGMT-3273)

Kryptografische Funktionen in JavaScript

Neue leistungsstarke JavaScript-crypto-Funktionen verfügbar zum Erstellen, Abrufen und Aktualisieren der folgenden Objekte enthält: MD5, SHA-1, SHA256, SHA512. Mit dem crypto-Objekt können Sie außerdem das Objekt abrufen. in verschiedenen Formaten. Weitere Informationen finden Sie unter JavaScript-Objektmodell. (APIRT-2886)

Java-Callout-JAR-Version Girokonto

Beim Hochladen einer Java-JAR-Ressource auf einen API-Proxy wird ein HTTP 400-Statuscode zurückgegeben. (anstelle von 500), wenn die Version der Java-Ressource nicht mit dem unterstützten Edge kompatibel ist. die unter Unterstützte Software und unterstützten Versionen. (MGMT-3420)

Validierung der API-Proxy-Ressourcen

Wenn Sie API-Proxy-Ressourcendateien (wie JavaScript- oder Java-JARs) im Verzeichnis auf Organisationsebene oder Umgebung festgelegt, müssen Sie im Rahmen des Validierungs-Frameworks Nehmen Sie diese Ressourcen auf API-Proxy-Ebene in ein Proxy-Bundle auf, damit der Import zur Validierung besteht. Die Ressourcenvalidierung erfolgt jetzt zum Zeitpunkt der Bereitstellung, nicht zum Zeitpunkt des Imports. (MGMT-1430)

Zeitlimit konfigurieren für einzelne API-Proxys

Sie können API-Proxys so konfigurieren, dass sie nach einer bestimmten Zeit (mit einem 504-Gateway-Zeitlimit) überschritten werden. Status). Der primäre Anwendungsfall ist für Private Cloud-Kunden mit API-Proxys, die länger dauert. Beispiel: Sie benötigen bestimmte Proxys nach 3 Minuten. Sie können Verwenden Sie in der Konfiguration für einen API-Proxy ein neues api.timeout-Attribut. Und so gehts verwenden Sie das 3-Minuten-Beispiel:

  1. Konfigurieren Sie zuerst den Load-Balancer, den Router und den Nachrichtenprozessor für eine Zeitüberschreitung. nach 3 Minuten.
  2. Konfigurieren Sie anschließend die relevanten Proxy-Zeitüberschreitungen nach 3 Minuten. Geben Sie den Wert in Millisekunden. Beispiel:
    <ProxyEndpoint name="default">
      <HTTPProxyConnection>
        <BasePath>/v1/weather</BasePath> 
        <Properties> 
          <!-- api.timeout is in milliseconeds -->
          <Property name="api.timeout">180000</Property>
        </Properties>
        ...
  3. Eine Erhöhung der Systemzeitüberschreitungen kann jedoch zu Leistungsproblemen führen, verwenden alle Proxys ohne api.timeout-Einstellung den neuen, höheren Load-Balancer, Router und Zeitüberschreitungen für Message Processor. Konfigurieren Sie also andere API-Proxys, die keine längeren Zeitüberschreitungen erfordern kürzere Timeouts zu verwenden. Das folgende Beispiel legt für einen API-Proxy eine Zeitüberschreitung nach 1 fest. Minute:
    <Property name="api.timeout">60000</Property>

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

Sie können den Wert nicht mit einer Variablen füllen. Diese Eigenschaft wird in den Referenz zu Endpunktattributen (APIRT-1778)

TLS/SSL für das Nachrichten-Logging Richtlinie

<KeyStore> und <TrustStore> können festgelegt werden in der SSLInfo-Konfiguration in der Nachrichten-Logging-Richtlinie, Ein- und Zweiwege-TLS/SSL-Verbindung mit einem Logging-Dienst zulassen SSLInfo wird für die Richtlinie zur Nachrichtenprotokollierung auf dieselbe Weise konfiguriert wie auf einem Proxy TargetEndpoint. Beim Nachrichten-Logging mit TLS/SSL wird jedoch nur das TCP-Protokoll 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 Beschreibung
SECENG-609 Laufzeitaufrufe schlagen während des Löschens des verknüpften Truststores oder Wenn das gültige Zertifikat im Truststore gelöscht wird
MGMT-3404 Das Anzeigen/Abrufen von Node.js-Logs und das Bereitstellen von Proxys langsam
MGMT-3400 Der Aufruf an die /userroles Management API schlägt fehl, wenn der aufrufende Nutzer „+“ den Namen anmelden
MGMT-3368 java.lang.ArrayIndexOutOfBoundsException: 1, beim Importieren eines API-Proxy-Bundles das Verzeichnis „resources/node/resources“ enthält
MGMT-3364 OAuthV2: redirect_uri check
MGMT-3319 Das Auflisten von Einträgen in einem Tresor mit einem Nullwert in einem der Einträge funktioniert nicht für Organisationen (CPS und Nicht-CPS)
MGMT-3226 Durch Abfragen auf Organisations-/Umgebungsebene sollten nicht alle Daten abgerufen werden, die die API verursachen nicht bestanden
In Release_160302 ist ein Fehler aufgetreten, bei dem die Auflistung von Ressourcen auf Organisationsebene/Umgebung Stufe fehlgeschlagen, wenn die kumulative Größe der Ressourcen über 16 MB liegt. Diese Lösung wird behoben. .
AXAPP-2429 Die Analytics API mit „response_status_code“ gibt Datenzugriff zurück Fehler
AXAPP-2386 Probleme mit leeren Berichten in täglichen Analytics-E-Mail-Berichten beheben
AXAPP-2347 Ich erhalte keine täglichen Zusammenfassungs-E-Mails zu Analysen
APIRT-3141 Java-Callouts schlagen fehl, wenn new ExecutionResult() aufgerufen wird, da der Konstruktor wurde als privat gekennzeichnet
APIRT-3140 ServiceCallout-Richtlinie funktioniert nicht in HEAD-API-Aufrufen
APIRT-3131 Falsch "createBy" für einen API-Proxy angezeigt, wenn die Monetarisierung mit einem externer Authentifizierungsanbieter
APIRT-3121 Die Änderung der Organisationsressource ist nicht zu 100% wirksam
APIRT-3117 MP hat eine CPU-Auslastung von 100% erreicht und stellt keinen Traffic mehr bereit
APIRT-3016 Router: Zeitüberschreitung beim Anruf Fehler bei Bereitstellungen
APIRT-2975 Zertifikat-Bundle-Upload fehlgeschlagen
APIRT-2955 Bestimmte Attribute von JSON-Antwortdaten können für FHIR-Beschwerden nicht maskiert werden Content-Type-Header „application/json+fhir“
APIRT-2946 Die Richtlinie „OAuthV2-RefreshToken“ blendet Attribute nicht aus, obwohl „Anzeige“ festgelegt ist auf Falsch
APIRT-2908 Das Erzwingen von TLS1.2 für den internen API-Aufruf ist nach dem TLS1.2-Update erforderlich virtueller Gastgeber
APIRT-2901 Mit gzip komprimierte Antworten, die aus dem Cache zurückgegeben werden, werden doppelt komprimiert
APIRT-2873 MPs geben NullPointerException in Bezug auf „VerifyAPIKey“ aus, nachdem von products/developers/proxies
APIRT-2871 IOIntensive-Richtlinien werden in Trace zweimal angezeigt
APIRT-2825 Grammatischer Fehler in der Antwort auf den Zugriffstokenfehler
APIRT-2750 Hohe Traffic-Fehler in einer bestimmten Organisation
APIRT-2685 Traffic kann aufgrund eines unbekannten Fehlers nicht fließen
APIRT-2647 „Der zugrunde liegende Eingabestream hat null Byte zurückgegeben“ Fehler bei nonprod/dev
APIRT-2630 Zeitweilige Probleme beim Versuch, einen Wert aus dem Cache zu lesen
APIRT-2620 Separater Thread-Pool für einige Blockierschritte
APIRT-2610 java.lang.ClassCastException mit Antwort-Cache-Richtlinie
APIRT-2608 Fehler beim Parsen der Header „Zuletzt geändert“ in den Richtlinien für den Antwortcache
APIRT-2605 „Organisation“ und „Environment“. Variablen dürfen nicht überschrieben werden über Richtlinien
APIRT-2566 Die OAuthV2-Richtlinie gibt einen ungültigen WWW-Authenticate-Header zurück
APIRT-2491 Die TargetServer-Aktualisierung ist aufgrund einer RPC-Zeitüberschreitung zwischen Verwaltung und fehlgeschlagen m
APIRT-2386 In einem API-Produkt mit leerem „Allowed OAuth“ wird ein leerer Stringbereich erstellt Umfang
APIRT-2383 XSL-Transformationsrichtlinien scheinen keine Daten auf einem Fehler
APIRT-2364 OAuth-Fehlerflussvariablen werden bei einem Fehler nicht aktualisiert
APIRT-2216 Vom Server gesendete Ereignisse – der Ereignisstream hat Probleme in der Produktion
APIRT-2079 DEBUG-cURL-Aufruf wird nach Ablauf des Zeitlimits für die erstellte Sitzung
APIRT-1495 XML Threat Protection erkennt fhir-Inhaltstyp nicht
APIRT-347 Die XSL-Richtlinie wird beim Import nicht ordnungsgemäß validiert (es werden keine Ergebnisse zugewiesen) um Variablen wie dokumentiert auszugeben)