Diese Seite wurde von der Cloud Translation API übersetzt.

16.09.21 – Versionshinweise zu Apigee Edge for Public Cloud

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

Am Donnerstag, dem 13. Oktober 2016, haben wir mit der Veröffentlichung einer neuen Version von Apigee Edge für die öffentliche Cloud begonnen.

Neue Features und Updates

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

Freigegebene Abläufe und Ablauf-Hooks zum Operationalisieren von API-Proxys (nur auf Anfrage als Beta verfügbar)

Mit dem neuen Feature „Freigegebene Abläufe“ können Sie Funktionen in API-Proxys operationalisieren. Wenn Sie bedingte Richtlinien und Ressourcen in einem freigegebenen Ablauf kombinieren, können Sie von jedem API-Proxy darauf verweisen, um wiederverwendbare Logik aus einer einzigen Quelle auszuführen. Ein freigegebener Ablauf kann beispielsweise den API-Schlüssel überprüfen, vor Spike-Arrests schützen und Daten protokollieren.

Sie definieren freigegebene Abläufe in der Verwaltungs-UI (APIs > Freigegebene Abläufe) und verweisen dann auf zwei verschiedene Arten darauf:

Mit einer neuen Ablauf-Callout-Richtlinie in einem API-Proxy
oder
In einem neuen Artefakt namens „Ablauf-Hooks“, das sich an den folgenden Stellen befindet:
- Anfrage: Vor dem ProxyEndpoint PreFlow, nach dem TargetEndpoint PostFlow
- Antwort: Vor dem TargetEndpoint PreFlow, nach dem ProxyEndpoint PostFlow
Mit diesen Anhängen können Sie Betriebslogik vor oder nach den Hauptablaufpunkten des einzelnen Proxys ausführen. Sie weisen freigegebene Abläufe diesen Ablauf-Hook-Standorten in der Verwaltungsoberfläche zu (APIs > Umgebungskonfiguration > Ablauf-Hooks).

Verschlüsselte Schlüssel/Wert-Paar-Zuordnungen

Sie können verschlüsselte Schlüssel/Wert-Zuordnungen (Key Value Maps, KVMs) erstellen, um vertrauliche Informationen wie Anmeldedaten oder personenbezogene Daten/HIPAA-Daten zu speichern. Diese Funktion unterscheidet sich vom vorhandenen Edge Secure Store (Vault) und soll diesen ersetzen, da auf Vault-Werte nur mit Node.js (zusätzlich zur Management API) zugegriffen werden kann. Sie können mit Node.js oder der Richtlinie „KeyValueMapOperations“ auf verschlüsselte KVM-Werte zugreifen.

Verschlüsselte KVMs erstellen

Verwenden Sie die vorhandenen KVM-APIs. Wenn Sie “encrypted”: “true” in die Nutzlastdefinition einfügen, wenn Sie eine KVM erstellen, verschlüsselt Edge die KVM und generiert einen Verschlüsselungsschlüssel, der denselben Bereich wie die KVM hat.
Sie können die Key Value Map Operations-Richtlinie nicht verwenden, um eine verschlüsselte KVM zu erstellen.
Sie können eine vorhandene unverschlüsselte KVM nicht verschlüsseln.

Verschlüsselte KVMs verwenden

Verwenden Sie die Richtlinie für Schlüssel/Wert-Zuordnungsvorgänge, um verschlüsselte KVM-Werte abzurufen und zu aktualisieren.
Wenn Sie einen verschlüsselten Schlüsselwert abrufen, stellen Sie der Variable, die den Wert enthält, das Präfix „private.“ voran. Beispiel: <Get assignTo="private.secretVar">. Die Variable private.secretVar enthält den entschlüsselten Wert.
Wenn Sie einen Wert mit der Richtlinie aktualisieren, müssen Sie nichts Besonderes tun. Der Wert wird in verschlüsselten KVMs automatisch verschlüsselt.
Sie können auch mit dem apigee-access-Modul in Node.js-Code auf den entschlüsselten Wert zugreifen. Verwenden Sie die Funktion getKeyValueMap(), um eine KVM anhand des Namens und des Bereichs abzurufen. Für das zurückgegebene Objekt sind zwei Funktionen verfügbar: getKeys(callback), um ein Array mit Schlüsselnamen abzurufen, und get(key, callback), um den Wert für einen bestimmten Schlüssel abzurufen. Beispiel:
```
var apigee = require('apigee-access');
  var encryptedKVM = apigee.getKeyValueMap('VerySecureKVM', 'apiproxy');
  encryptedKVM.get('secret1', function(err, secretValue) {
  // use the secret value here
});
```

(APIRT-1197)

Warnung:

KVM-PUT-Vorgänge mit Nullschlüsseln

Wenn in einer Richtlinie für Schlüsselwertzuordnungsvorgänge versucht wird, einen neuen Schlüssel/Wert in einer Schlüsselwertzuordnung (Key Value Map, KVM) mit einem Null-Schlüssel zu PUT, wird der folgende Schlüssel automatisch erstellt: __$$_EDGE_KVM_EMPTY_KEY_$$__

Das ist beispielsweise der Fall, wenn Sie einen Schlüssel mit einem Variablenverweis füllen und die referenzierte Variable null ist. Beim Versuch, neue PUT-Vorgänge mit Null-Schlüsseln zu verwenden, wird nur dieser Schlüssel verwendet, sodass vorhandene Werte für diesen Schlüssel bei jeder Ausführung der Richtlinie möglicherweise überschrieben werden.

Bisher wurde ein Schlüssel/Wert-Paar mit einem Null-Schlüssel nicht zur KVM hinzugefügt. Stattdessen verblieb der Eintrag im In-Memory-Cache des Message Processors und war vorübergehend für nachfolgende Get-Vorgänge verfügbar. Wenn Ihre KVM-Richtlinienimplementierung auf dem vorherigen Verhalten basiert, schlagen Get-Vorgänge für Nullschlüssel jetzt fehl, da sie nicht auf den neuen Schlüsselnamen (siehe oben) verweisen, der für Nullschlüssel erstellt wird. (APIRT-3530)

OpenAPI-Spezifikations-URLs, die in API-Proxy-Metadaten enthalten sind

Wenn Sie einen API-Proxy auf Grundlage einer OpenAPI-Spezifikation erstellen, wird der Speicherort der OpenAPI-Spezifikation in den API-Proxy-Metadaten gespeichert. Wenn Sie beispielsweise die Management API verwenden, um die Details einer Proxy-Revision abzurufen, enthalten die Metadaten den Pfad zur OpenAPI-Spezifikation im folgenden Format:

"spec" : "https://raw.githubusercontent.com/apigee/api-platform-samples/master/default-proxies/helloworld/openapi/mocktarget.yaml"

Diese Erweiterung unterstützt die nächste Generation von Edge, in der OpenAPI-Spezifikationen mit API-Proxys, API-Produkten und API-Referenzdokumenten im neuen Entwicklerportal verknüpft werden. (MGMT-2913)

Client-IP-Steuerung mit Sense

Wenn Sie Routing-Produkte wie Akamai verwenden, können Sie mit Sense den Standort der Client-IP mit einer additionalIPVars-Variablen definieren, um genauer zu steuern, wo IP-Adressen für die Sense-Bot-Erkennung zu finden sind. Sie können beispielsweise additionalIPVars festlegen, um den true-client-ip-Header zu verwenden, der die richtige IP-Adresse von Akamai enthält, die in Bot-Regeln ausgewertet werden soll. (APIRT-3332)

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
APIRT-3507	Zeitweilige Fehler (z. B. SNI-Fehler) bei JavaScript-Service-Callouts
APIRT-3408	MP-Release 160817: Das Modul „apigee-access analytics“ verarbeitet Nachrichten anders
APIRT-3390	Änderung der Fehlerantwort, die von der Richtlinie zum Aktualisieren von Zugriffstokens zurückgegeben wird Warnung:Änderung des OAuthV2-Fehlercodes „invalid_client“ Beachten Sie die folgende Änderung an einem Fehlercode, der von den Vorgängen GenerateAccessToken und RefreshAccessToken der OAuthV2-Richtlinie ausgegeben wird, wenn die Eigenschaft <GenerateResponse> der OAuthV2-Richtlinie auf false festgelegt ist: `{"ErrorCode" : "invalid_client", "Error" :"Client identifier is required"}` wurde geändert zu: `{"ErrorCode" : "InvalidClientIdentifier", "Error" :"Client identifier is required"}` Es wird empfohlen, alle Bedingungen für Fehlerregeln, die „`invalid_client`“ erfassen, so zu ändern, dass sowohl die alten als auch die neuen Codes erfasst werden. Ändern Sie in Ihrer Fehlerregel beispielsweise Folgendes: `(fault.name = "invalid_client")` zu `(fault.name = "invalid_client") OR (fault.name = "InvalidClientIdentifier")`
APIRT-3389	Warnung: Fehler beim Hochladen von Node.js-Nutzlasten über 25 KB Das Hochladen von Node.js-Nutzlasten über 25 KB ist jetzt zulässig.
APIRT-3381	Hohe Latenzen bei Produktionsproxys von Kunden
APIRT-3366	Javascript-Richtlinien schlagen bei allen neuen Testorganisationen fehl
APIRT-3363	Beim Parsen einer ungültigen URL wird der Status „500“ mit „ApplicationNotFound“ zurückgegeben.
APIRT-3356	Meldung zu ungültigen OAuth-Tokens
APIRT-3355	Zeitweiliger 403-Fehler beim OAuth-Proxy
APIRT-3285	Warnung:Inkonsistenter Ablauf von OAuth2-Tokens Wenn Sie ein OAuth-Token mit der OAuth v2.0-Richtlinie generieren, können Sie den Ablauf des Tokens entweder per Referenz oder mit einem fest codierten Standardwert festlegen. Beispiel: `<ExpiresIn ref="kvm.oauth.expires_in">1800000</ExpiresIn>`. Als das Tokenablaufdatum zum ersten Mal per Referenz festgelegt wurde, hat Edge diesen Wert gespeichert und für jedes neue Tokenablaufdatum verwendet. Dieser Fehler wurde behoben. Es wird entweder der Referenzwert oder, falls kein Referenzwert angegeben ist, das in der Richtlinie definierte Standardablaufdatum verwendet. Diese Korrektur kann die Dauer des Tokenablaufs ändern. Möglicherweise treten Nebenwirkungen wie häufigere Fehler aufgrund ungültiger Tokens auf. In diesem Fall müssen Sie möglicherweise häufigere Tokenaktualisierungen implementieren oder den Standardablauf in Ihren OAuth-Richtlinien ändern.
APIRT-3261	Anmeldedaten werden anhand einer anderen Entwickler-App in der Produktion validiert
APIRT-3234	Node.js-App gibt NPE zurück
APIRT-3223	Problem mit veraltetem Apigee-Cache
APIRT-3193	Node.js-Zielserver reagiert nach der Migration zu ASG nicht mehr
APIRT-3152	Der Verwaltungsaufruf für zwischengespeicherte Logs führt dazu, dass Logmeldungen aufgeteilt werden.
APIRT-3117	MP hat 100% CPU-Auslastung erreicht und stellt keinen Traffic mehr bereit
APIRT-3064	Router – benutzerdefinierte 503-Fehlermeldung vom Router
APIRT-2620	Separater Threadpool für einige blockierende Schritte zur Verbesserung der Lastverarbeitung
CORESERV-774	Zugriff mit gültigem Schlüssel und ungültigem API-Produktverweis führt zu internem Serverfehler