Sie lesen gerade die Dokumentation zu Apigee Edge.
Apigee X-Dokumentation aufrufen. info
Am Dienstag, dem 29. April 2014, haben wir eine neue Cloud-Version von Apigee Edge veröffentlicht.
Neue Features und Verbesserungen
Im Folgenden sind die neuen Funktionen und Verbesserungen in diesem Release aufgeführt.
- Analyse-Dashboards
Edge bietet jetzt neue Analyseberichte zur Endpunktleistung, API-Proxy-Leistung und Cacheleistung, mit denen Sie die Leistung überwachen können.
Weitere Informationen finden Sie unter Analytics-Dashboards im Abschnitt „Die Operations-Dashboards“. - Benutzerdefinierte Messwerte für die Leistung zusammenfassen
Diese Funktion ist nicht mehr verfügbar.
Eine neue benutzerdefinierte Aggregationsfunktion verbessert die Analyseleistung, da Sie benutzerdefinierte Messwerte definieren können, die von Edge erfasst und gespeichert werden, wenn API-Aufrufe erfolgen. Wenn Sie Berichte aufrufen, greift Edge auf die bereits verfügbaren aggregierten Messwerte zu, anstatt sie spontan abzurufen. - Vorkonfiguriertes OAuth 2.0 in API-Proxys
Wenn Sie einen API-Proxy erstellen, wird er automatisch mit Richtlinien konfiguriert, die OAuth unterstützen, wenn Sie die neue Option „Mit OAuth 2.0-Zugriffstokens sichern“ auswählen.
Weitere Informationen finden Sie unter OAuth. - Datenmaskierung im Trace
Mit der API-Ressource „/maskconfigs“ können Sie sensible Daten wie Kreditkarteninformationen in API-Proxy-Trace-Sitzungen maskieren und so die Sicherheit von Nutzerdaten während der API-Entwicklung gewährleisten.
Fall:810723
Weitere Informationen finden Sie unter Daten maskieren und ausblenden. - Richtlinie zur Basisauthentifizierung
Mit der Richtlinie zur Basisauthentifizierung können Sie einem API-Proxy eine einfache Basisauthentifizierung hinzufügen. Dabei werden Nutzeranmeldedaten automatisch Base64-codiert und der HTTP-HeaderAuthorization: Basicwird ausgefüllt.
Weitere Informationen finden Sie unter Basisauthentifizierungsrichtlinie. - PostClientFlow
Mit dem PostClientFlow können Sie MessageLogging-Richtlinien hinzufügen, die nach dem Senden der Antwort ausgeführt werden. Dadurch wird die API-Proxy-Latenz verringert und es werden Informationen für die Protokollierung verfügbar gemacht, die erst nach dem Senden der Antwort berechnet werden, z. B. „client.sent.start.timestamp“ und „client.sent.end.timestamp“.
Fall: 814059
Fehlerkorrekturen
Folgende Fehler wurden in diesem Release behoben.
| Thema | Description |
|---|---|
| Validierung von Namen benutzerdefinierter Berichte | In Edge werden jetzt die Namen benutzerdefinierter Berichte validiert, um die Verwendung von Sonderzeichen zu verhindern. |
| Probleme mit dem Aufschlüsseln nach „developer_app“ melden | In benutzerdefinierten Berichten, in denen der Drilldown „developer_app“ verwendet wurde, wurden falsche Entwickler-Apps zurückgegeben. Dieses Problem wurde behoben. |
| Zeitraum funktioniert nicht in benutzerdefinierten Berichten | In benutzerdefinierten Berichten mit Filtern mit mehreren Ausdrücken in Klammern, z. B. (request_verb eq 'POST') or (request_verb eq
'GET'), hatte das Ändern des Zeitraums des Berichts keine Auswirkungen auf die Ergebnisse. Dieses Problem wurde behoben.Fall: 810753 |
| Diagramme werden in benutzerdefinierten Berichten nicht angezeigt | Ein Problem, bei dem Diagramme nicht in benutzerdefinierten Berichten angezeigt wurden, wurde behoben. Fall: 814623 |
| WSDL-Import |
|
| Konfiguration der Richtlinie für die gleichzeitige Ratenbegrenzung | Die Zielendpunktauswahl ist jetzt nur noch verfügbar, wenn einem API-Proxy eine Richtlinie für die gleichzeitige Ratenbegrenzung hinzugefügt wird. Der Ziel-Endpunkt gilt nicht für andere Richtlinien. |
| Unternehmenssupport für Entwickler | Bei Organisationen, für die Unternehmen aktiviert sind, können Sie jetzt beim Erstellen oder Bearbeiten eines Entwicklers ein Unternehmen angeben. Fall: 515246 |
| Entwickler, Apps und Produkte exportieren | Sie können jetzt Entwickler, Apps und Produkte über die Seite „Developers“ (Entwickler) in der Edge-Verwaltungsoberfläche in eine CSV-Datei exportieren. Diese Funktion ist derzeit für Organisationen, die die Monetarisierung aktiviert haben, nicht verfügbar. Fall: 747159 |
| Fenster „Entwickler-Apps“ hängt | Wenn ein Entwickler eine App im Edge Developer Portal gelöscht hat und ein Nutzer in der Edge-Verwaltungsoberfläche auf die App des Entwicklers geklickt hat, ist das Fenster hängen geblieben. Dieses Problem wurde behoben. |
| Kommentare in einer API-Proxy-Konfiguration | Kommentare in einer API-Proxykonfiguration sind jetzt in der Codeansicht des API-Proxy-Editors und in der Property Inspector sichtbar. |
| API-Proxys mit ungültigen Namen | In der Edge-Verwaltungsoberfläche konnten bisher API-Proxys erstellt werden, 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 bei der Erstellung validiert. Es sind nur alphanumerische Zeichen sowie „-“ und „_“ zulässig. Fall: 550390 |
| Groß-/Kleinschreibung bei der Benennung von API-Proxys | In Edge wurden API-Proxys mit Kleinbuchstabennamen erstellt, unabhängig von der eingegebenen Groß-/Kleinschreibung. Bei Edge wird jetzt die Groß- und Kleinschreibung des Namens des API-Proxys berücksichtigt. |
| Warnung beim Speichern von API-Proxys | Wenn Sie einen API-Proxy im API-Proxy-Editor speichern, stellt Edge den API-Proxy in allen Umgebungen bereit, in denen die Revision derzeit bereitgestellt wird, einschließlich Produktionsumgebungen. In der Edge-Verwaltungsoberfläche wird jetzt eine Warnung angezeigt, bevor der Proxy gespeichert wird. |
| Benutzerdefinierte Rolle ohne Berechtigungen wird in der Produktionsumgebung gespeichert | Wenn eine bereitgestellte API-Version aktualisiert wird, wird in bereitgestellten Umgebungen intern die Bereitstellung aufgehoben und die Version bereitgestellt. Mit einer benutzerdefinierten Rolle ohne die richtigen Berechtigungen für die Bereitstellung konnte ein API-Proxy bereitgestellt werden, indem er gespeichert wurde. Dieses Problem wurde durch die Erzwingung von Bereitstellungsberechtigungen behoben. Fall: 813084 |
| Doppelt vorhandener Zielserver | Beim Erstellen eines doppelten Zielservers hat Edge anstelle eines HTTP-409-Fehlers den vorhandenen Zielserver überschrieben und den Statuscode 201 zurückgegeben. Dieses Problem wurde behoben, indem ein 409-Fehler ausgegeben und der vorhandene Zielserver nicht überschrieben wird. |
| Trace-Sitzungen für API-Proxys können nicht erstellt werden | Für Umgebungen mit Message Processors, die nicht erreichbar waren, wurden keine Trace-Sitzungen erstellt. Dieses Problem wurde behoben, indem Tracing-Sitzungen nur an die erreichbaren und verfügbaren Message Processor angehängt werden. Fall: 812192 |
| Aktualisiertes Verhalten von JMSReplyTo | Standardmäßig sendet Edge die Antwort an die im JMSReplyTo-Header angegebene Warteschlange.
Wenn Sie jedoch möchten, dass der Back-End-Dienst die Antwort an die JMSReplyTo-Warteschlange sendet und nicht Edge, fügen Sie den Header X-Apigee-Ignore-JMSResponse der Antwort des API-Proxys in einem beliebigen Ablauf hinzu und legen Sie ihn auf „true“ fest:<Header name="X-Apigee-Ignore-JMSResponse">true</Header> |
| Hohe Anzahl von CLOSE_WAIT- und 502-Fehlern („Bad Gateway“) | Ein Problem, das zu hohen CLOSE_WAIT-Messwerten und 502-Bad-Gateway-Fehlern geführt hat, wurde behoben. Fälle: 814656, 814664, 814670 |
| Node.js-Temporärverzeichnis | Wenn ein Node.js-Script in Edge bereitgestellt wird, wird es in einer Sandbox ausgeführt, die den Dateisystemzugriff auf ein bestimmtes Verzeichnis beschränkt. os.tmpdir gibt jedoch einen Verzeichnisnamen wie /tmp oder /var/tmp zurück, der in der Edge Node.js-Sandbox nicht vorhanden war, was dazu führte, dass einige Skripts nicht mehr funktionierten. Die Edge Node.js-Sandbox enthält jetzt ein /tmp-Verzeichnis für os.tmpdir. |
| Nullzeiger-Ausnahmen bei API-Aufrufen | In der Assign Message-Richtlinie wurde bei einem Null-Antwortstatus eine NullPointerException ausgelöst, da Edge versucht hat, den Antwortcode für Messwerte zu erfassen. Dieses Problem wurde behoben. Fall: 815595 |