Sie lesen gerade die Dokumentation zu Apigee Edge.
Zur Dokumentation zu
Apigee X. info
Am Dienstag, 29. April 2014, haben wir eine neue Cloud-Version von Apigee Edge veröffentlicht.
Neue Features und Verbesserungen
Im Folgenden sind die neuen Features und Verbesserungen in diesem Release aufgeführt.
- Analyse-Dashboards
Edge bietet jetzt neue Berichte zur Endpunktleistung, API-Proxy-Leistung und Cache-Leistung, mit denen Sie die Leistung überwachen können.
Weitere Informationen finden Sie unter "Die Dashboards für den Betrieb" unter Analyse-Dashboards. - Benutzerdefinierte Messwertaggregation für die Leistung
Diese Funktion ist nicht mehr verfügbar.
Eine neue Funktion für die benutzerdefinierte Aggregation verbessert die Analyseleistung, indem Sie benutzerdefinierte Messwerte definieren können, die von Edge erfasst und gespeichert werden, wenn API-Aufrufe erfolgen. Wenn Sie Berichte ansehen, 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 mit der neuen Option „Mit OAuth v2.0-Zugriffstokens sichern“ der API-Proxy 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. So können Sie die Datensicherheit der Nutzer bei der API-Entwicklung gewährleisten.
Fall:810723
Weitere Informationen finden Sie unter Daten maskieren und ausblenden. - Richtlinie für die Basisauthentifizierung
Mit der Richtlinie für die Basisauthentifizierung können Sie einem API-Proxy eine einfache Basisauthentifizierung hinzufügen. Dabei werden die Nutzeranmeldedaten automatisch in Base64 codiert und der HTTPAuthorization: BasicHeader wird ausgefüllt.
Weitere Informationen finden Sie unter Basisauthentifizierungsrichtlinie. - PostClientFlow
Mit PostClientFlow können Sie MessageLogging-Richtlinien hinzufügen, die nach dem Senden der Antwort ausgeführt werden. Dadurch wird die Latenz des API-Proxys reduziert und es werden Informationen für das Logging zur Verfügung gestellt, die erst berechnet werden, nachdem die Antwort gesendet wurde, z. B. client.sent.start.timestamp und client.sent.end.timestamp.
Ladecase: 814059
Fehlerkorrekturen
Folgende Fehler wurden in diesem Release behoben.
| Thema | Beschreibung |
|---|---|
| Validierung des Namens benutzerdefinierter Berichte | In Edge werden jetzt die Namen benutzerdefinierter Berichte validiert, um die Verwendung von Sonderzeichen zu verhindern. |
| Probleme mit dem Drilldown „developer_app“ melden | In benutzerdefinierten Berichten, in denen der Drilldown „developer_app“ verwendet wurde, wurden falsche Entwickler-Apps zurückgegeben. Dieses Problem wurde inzwischen behoben. |
| Zeitraum funktioniert nicht in benutzerdefinierten Berichten | In benutzerdefinierten Berichten mit Filtern mit mehreren Klammerausdrücken
, 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 inzwischen behoben.Fall: 810753 |
| Diagramme werden in benutzerdefinierten Berichten nicht angezeigt | Ein Problem, bei dem Diagramme in benutzerdefinierten Berichten nicht angezeigt wurden, wurde behoben. Fall: 814623 |
| WSDL-Import |
|
| Konfiguration der Richtlinie für die gleichzeitige Ratenbegrenzung | Die Auswahl des Zielendpunkts ist jetzt nur verfügbar, wenn Sie einem API-Proxy eine Richtlinie für die gleichzeitige Ratenbegrenzung hinzufügen. Der Zielendpunkt gilt nicht für andere Richtlinien. |
| Unternehmenssupport für Entwickler | Für Organisationen, in denen Unternehmen aktiviert sind, können Sie jetzt ein Unternehmen angeben, wenn
einen Entwickler erstellen oder bearbeiten. Fall: 515246 |
| Export von Entwicklern, Apps und Produkten | Sie können jetzt Entwickler, Apps und Produkte auf der Seite „Entwickler“ in der Edge-Verwaltungsoberfläche in eine CSV-Datei exportieren. Diese Funktion ist derzeit für Organisationen, in denen die Monetarisierung aktiviert ist, nicht verfügbar. Case: 747159 |
| Fenster „Entwickler-Apps“ hängt | Nachdem ein Entwickler eine App im Edge-Entwicklerportal gelöscht hatte, hing das Fenster, wenn Sie in der Edge-Verwaltungsoberfläche auf diese Entwickler App geklickt haben. Dieses Problem wurde inzwischen 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. |
| API-Proxys mit ungültigen Namen erstellt | In der Edge-Verwaltungsoberfläche konnten zuvor API-Proxys erstellt werden, deren Namen
nicht unterstützte Sonderzeichen enthielten. Dadurch wurden ungültige API-Proxys erstellt, 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 Kleinbuchstaben erstellt, unabhängig von der eingegebenen Groß-/Kleinschreibung. In Edge wird jetzt die Groß-/Kleinschreibung des für den API-Proxy eingegebenen Namens 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 Überarbeitung 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 in der Produktionsumgebung gespeichert | Wenn eine bereitgestellte API-Überarbeitung aktualisiert wird, wird in den
bereitgestellten Umgebungen intern die Bereitstellung aufgehoben und neu bereitgestellt. Eine benutzerdefinierte Rolle ohne die entsprechenden Berechtigungen für die Bereitstellung konnte
bereitgestellt werden, indem ein API-Proxy gespeichert wurde. Dieses Problem wurde behoben, indem Berechtigungen für die Bereitstellung
erzwungen werden. Fall: 813084 |
| Doppelter Zielserver | Beim Erstellen eines doppelten Zielservers hat Edge den vorhandenen Zielserver überschrieben und den Status „201“ zurückgegeben, anstatt einen HTTP-Fehler „409“ zu senden. Dieses Problem wurde behoben, indem ein Fehler „409“ ausgelöst und der vorhandene Zielserver nicht überschrieben wird. |
| Trace-Sitzungen für API-Proxys können nicht erstellt werden | Für Umgebungen mit nicht erreichbaren Message Processors wurden keine Trace-Sitzungen erstellt. Dieses Problem wurde behoben, indem Trace-Sitzungen nur an die
erreichbaren und verfügbaren Message Processors angehängt werden. Fall: 812192 |
| Aktualisiertes Verhalten von JMSReplyTo | Standardmäßig sendet Edge die Antwort an die Warteschlange, die im JMSReplyTo-Header angegeben ist.
Wenn Sie jedoch möchten, dass der Backend-Dienst die Antwort an die JMSReplyTo
Warteschlange sendet, anstatt Edge, fügen Sie in einem beliebigen Ablauf den X-Apigee-Ignore-JMSResponse Header zur Antwort des API
Proxys hinzu und setzen Sie ihn auf „true“:<Header name="X-Apigee-Ignore-JMSResponse">true</Header> |
| Hohe CLOSE_WAIT- und 502-Fehler (Fehlerhaftes Gateway) | Ein Problem, das zu hohen CLOSE_WAIT-Messwerten und 502-Fehlern (Fehlerhaftes Gateway) geführt hat, wurde behoben.
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 Zugriff auf das Dateisystem 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 funktionierten. Die Edge-Node.js-Sandbox enthält jetzt ein /tmp-Verzeichnis, das von os.tmpdir verwendet werden kann. |
| Nullzeiger-Ausnahmen bei API-Aufrufen | In der Richtlinie „Assign Message“ hat ein Null-Antwortstatus eine Nullzeiger-Ausnahme ausgelöst, da
Edge versucht hat, den Antwortcode für Messwerte zu erfassen. Dieses Problem wurde inzwischen behoben. Case: 815595 |