Sie sehen die Dokumentation zu Apigee Edge.
Zur Apigee X-Dokumentation weitere Informationen
Am Dienstag, dem 29. April 2014, wurde eine neue Cloud-Version von Apigee Edge veröffentlicht.
Neue Features und Verbesserungen
Im Folgenden sind die neuen Funktionen und Verbesserungen in dieser Version aufgeführt.
- Analyse-Dashboards
Edge bietet jetzt neue Berichte zur Endpunktleistung, zur API-Proxy-Leistung und zu Cache-Leistungsanalysen, mit denen Sie die Leistung überwachen können.
Siehe „Die Betriebs-Dashboards“ unter Analytics-Dashboards. - Zusammenfassung benutzerdefinierter Messwerte für die Leistung
Diese Funktion ist nicht mehr verfügbar.
Eine neue benutzerdefinierte Aggregationsfunktion verbessert die Analyseleistung, da Sie benutzerdefinierte Messwerte definieren können, die Edge beim Ausführen von API-Aufrufen erfasst und speichert. Wenn Sie Berichte anzeigen, greift Edge auf die bereits verfügbaren aggregierten Messwerte zu, anstatt sie direkt abzurufen. - Vorkonfigurierte OAuth 2.0 in API-Proxys
Beim Erstellen eines API-Proxys wird der API-Proxy durch die neue Option „Sicher mit OAuth v2.0-Zugriffstokens“ automatisch mit Richtlinien konfiguriert, die OAuth unterstützen.
Weitere Informationen finden Sie unter OAuth. - Datenmaskierung in Trace
Mit der API-Ressource „/maskconfigs“ können Sie sensible Daten wie Kreditkarteninformationen in API-Proxy-Trace-Sitzungen maskieren und so die Sicherheit der Nutzerdaten während der API-Entwicklung gewährleisten.
Case:810723
Weitere Informationen finden Sie unter Datenmaskierung und -ausblendung. - Richtlinie zur Basisauthentifizierung
Mit der Richtlinie zur Basisauthentifizierung können Sie einem API-Proxy eine einfache Basisauthentifizierung hinzufügen und so die automatische Base64-Codierung von Nutzeranmeldedaten und das Füllen des HTTP-Authorization: Basic-Headers sicherstellen.
Siehe Richtlinie zur Basisauthentifizierung. - PostClientFlow
Mit PostClientFlow können Sie MessageLogging-Richtlinien hinzufügen, die nach dem Senden der Antwort ausgeführt werden. Dadurch wird die API-Proxy-Latenz reduziert und Informationen für das Logging verfügbar gemacht, die erst nach dem Senden der Antwort berechnet werden, z. B. client.sent.start.timestamp und client.sent.end.timestamp.
Anfrage: 814059
Fehlerkorrekturen
Folgende Fehler wurden in diesem Release behoben.
| Thema | Beschreibung |
|---|---|
| Namevalidierung für benutzerdefinierten Bericht | Edge validiert jetzt die Namen von benutzerdefinierten Berichten, um die Verwendung von Sonderzeichen zu verhindern. |
| Probleme mit der Aufschlüsselung „developer_app“ melden | In benutzerdefinierten Berichten mit der Aufschlüsselung „developer_app“ wurden falsche Entwickler-Apps zurückgegeben. Dieses Problem wurde inzwischen behoben. |
| Zeitraum funktioniert bei benutzerdefinierten Berichten nicht | In benutzerdefinierten Berichten, die Filter mit mehreren geklammerten Ausdrücken enthielten, z. B. (request_verb eq 'POST') or (request_verb eq
'GET'), hatte eine Änderung des Berichtzeitraums keine Auswirkungen auf die Ergebnisse. Dieses Problem wurde behoben.Anfrage: 810753 |
| Diagramme werden in benutzerdefinierten Berichten nicht angezeigt | Ein Problem mit Diagrammen, die nicht in benutzerdefinierten Berichten angezeigt wurden, wurde behoben. Fall: 814623 |
| WSDL-Import |
|
| Konfiguration der Richtlinie für gleichzeitige Ratenbegrenzung | Die Auswahl des Zielendpunkts ist jetzt nur verfügbar, wenn einem API-Proxy eine Richtlinie für gleichzeitige Ratenbegrenzung hinzugefügt wird. Der Zielendpunkt gilt nicht für andere Richtlinien. |
| Unternehmenssupport für Entwickler | Für Organisationen, für die Unternehmen aktiviert sind, können Sie beim Erstellen oder Bearbeiten eines Entwicklers jetzt ein Unternehmen angeben. Fall: 515246 |
| Export von Entwicklern, Apps und Produkten | Sie können jetzt Entwickler, Apps und Produkte von der Seite „Entwickler“ in der Edge-Management-Benutzeroberfläche in eine CSV-Datei exportieren. Diese Funktion ist derzeit für Organisationen nicht verfügbar, die die Monetarisierung aktiviert haben. Fall: 747159 |
| Fenster für Entwickler-Apps hängt | Nachdem ein Entwickler eine App im Edge-Entwicklerportal gelöscht hat, würde das Klicken auf diese Entwickler-App in der Edge-Verwaltungs-UI dazu führen, dass sich das Fenster aufhängt. Dieses Problem wurde behoben. |
| Kommentare in einer API-Proxy-Konfiguration | Kommentare in einer API-Proxy-Konfiguration sind jetzt in der Codeansicht des API-Proxy-Editors und im Property Inspector sichtbar. |
| Mit ungültigen Namen erstellte API-Proxys | In der Edge-Management-Benutzeroberfläche war es zuvor möglich, API-Proxys zu erstellen, deren Namen nicht unterstützte Sonderzeichen enthielten. Dies führte zu ungültigen API-Proxys, die nicht gelöscht werden konnten. API-Proxy-Namen werden jetzt zum Zeitpunkt der Erstellung validiert. Es sind nur alphanumerische Zeichen, „-“ und „_“ zulässig. Anfrage: 550390 |
| Berücksichtigung der Groß-/Kleinschreibung bei der API-Proxy-Benennung | Edge erstellte API-Proxys mit Namen in Kleinbuchstaben, unabhängig von der eingegebenen Groß-/Kleinschreibung. Edge berücksichtigt jetzt die Groß-/Kleinschreibung des für den API-Proxy eingegebenen Namens. |
| Warnung zum Speichern des API-Proxys | Wenn Sie einen API-Proxy im API-Proxy-Editor speichern, stellt Edge den API-Proxy für alle Umgebungen bereit, in denen die Überarbeitung derzeit bereitgestellt wird, einschließlich Produktionsumgebungen. Die Edge-Management-Benutzeroberfläche zeigt jetzt eine Warnung an, bevor der Proxy gespeichert wird. |
| Benutzerdefinierte Rolle ohne Speichern von Berechtigungen in der Produktionsumgebung | Wenn eine bereitgestellte API-Überarbeitung aktualisiert wird, wird die Bereitstellung intern in den bereitgestellten Umgebungen zurückgenommen und bereitgestellt. Eine benutzerdefinierte Rolle ohne entsprechende Bereitstellungsberechtigungen konnte durch Speichern eines API-Proxys bereitgestellt werden. Dieses Problem wurde durch das Erzwingen von Deployment-Berechtigungen behoben. Anfrage: 813084 |
| Doppelter Zielserver | Beim Erstellen eines duplizierten Zielservers hat Edge den vorhandenen Zielserver anstelle eines HTTP 409-Fehlers überschrieben und den Status 201 zurückgegeben. Dieses Problem wurde behoben, indem ein 409-Fehler ausgegeben wurde und der vorhandene Zielserver nicht überschrieben wurde. |
| Trace-Sitzungen für API-Proxys können nicht erstellt werden | Für Umgebungen mit nicht erreichbaren Nachrichtenprozessoren wurden keine Trace-Sitzungen erstellt. Dieses Problem wurde behoben, indem Trace-Sitzungen nur an die erreichbaren und verfügbaren Nachrichtenprozessoren angehängt wurden Fall: 812192 |
| Aktualisiertes Verhalten für JMSReplyTo | Standardmäßig sendet Edge die Antwort an die im Header JMSReplyTo angegebene Warteschlange.
Wenn Sie jedoch möchten, dass der Back-End-Dienst die Antwort an die JMSReplyTo-Warteschlange und nicht an Edge sendet, fügen Sie dem API-Proxy response in jedem Ablauf den Header X-Apigee-Ignore-JMSResponse hinzu und setzen Sie ihn auf „true“:<Header name="X-Apigee-Ignore-JMSResponse">true</Header> |
| Hoher CLOSE_WAIT und Fehler 502 bei falschem Gateway | Ein Problem, das zu hohen CLOSE_WAIT-Messwerten und den Fehler „502_bad_gateway“ führte, wurde behoben. Fälle: 814656, 814664, 814670 |
| Temporäres Node.js-Verzeichnis | Wenn ein Node.js-Skript in Edge bereitgestellt wird, wird es in einer Sandbox ausgeführt, die den Dateisystemzugriff auf ein bestimmtes Verzeichnis einschränkt. „os.tmpdir“ gibt jedoch einen Verzeichnisnamen wie „/tmp“ oder „/var/tmp“ zurück, der in der Edge Node.js-Sandbox nicht vorhanden war. Dadurch funktionieren einige Skripts nicht richtig. Die Edge Node.js-Sandbox enthält jetzt ein /tmp-Verzeichnis für die Verwendung von os.tmpdir. |
| Null-Pointer-Ausnahmen bei API-Aufrufen | In der Richtlinie zum Zuweisen einer Nachricht hat der Antwortstatus Null eine Nullzeigerausnahme ausgelöst, als Edge versucht hat, den Antwortcode für Metriken zu erfassen. Dieses Problem wurde inzwischen behoben. Anfrage: 815595 |