4.15.07.00 – Versionshinweise für Apigee Edge for Private Cloud

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

Am Dienstag, dem 8. September 2015, haben wir einen wichtigen Feature-Release von Apigee Edge for Private Cloud veröffentlicht.

Seit dem letzten vierteljährlichen Release von Edge for Private Cloud (4.15.04.00) sind die folgenden Releases erfolgt, die in diesem vierteljährlichen Release enthalten sind:

• Cloud: 15.04.15, 15.04.29, 15.05.27, 15.06.10 und 15.06.24
• Private Cloud: 4.15.04.01

Auf welche Edge-Versionen kann ein Upgrade auf 4.15.07.00 durchgeführt werden?

Je nach aktueller Version von Edge haben Sie folgende Möglichkeiten:

• Direktes Upgrade auf 4.15.07.00
• Führen Sie ein inkrementelles Upgrade durch. Das bedeutet, dass Sie von Ihrer aktuellen Version auf eine andere Version von Edge und dann auf 4.15.07.00 aktualisieren müssen.

Weitere Informationen finden Sie unter Welche Edge for Private Cloud-Versionen können auf 4.15.07.00 aktualisiert werden?.

Vor dem Upgrade von Version 4.15.01.x oder einer früheren Version

1. Prüfen Sie die Cassandra-SSTable-Version:
   1. Wechseln Sie in das Verzeichnis /<install-root>/apigee4/data/cassandra/data.
   2. Führen Sie einen „find“-Befehl aus:
      > find . -name *-ic-*
      Die Ergebnisse sollten eine Reihe von .db-Dateien zurückgeben, wenn Sie Cassandra 1.2 SSTable ausführen.
   3. Führen Sie diesen find-Befehl aus:
      > find . -name *-hf-*
      Die Ergebnisse sollten leer sein. Das bedeutet, dass keine .db-Dateien im Format hf vorhanden sind. Wenn keine Dateien im hf-Format angezeigt werden, sind Sie fertig und können auf Version 4.15.07.00 aktualisieren.
      
      Das hf-Format ist für Cassandra 1.0-SSTables. Wenn Sie *.db-Dateien im hf-Format haben, müssen Sie SSTable wie im weiteren Verlauf dieses Verfahrens beschrieben aktualisieren.
2. Wenn Sie *.db-Dateien im hf-Format finden, führen Sie auf jedem Cassandra-Knoten den folgenden Befehl aus, bis alle Cassandra-Knoten aktualisiert wurden:
   > /<install-root>/apigee4/share/apache-cassandra/bin/nodetool -h localhost upgradesstables -a
3. Wiederholen Sie Schritt 1, um zu prüfen, ob alle *.db-Dateien das ic-Format für Cassandra 1.2 haben.
4. Wiederholen Sie die Schritte 1 bis 3 auf jedem Cassandra-Knoten in Ihrer Edge-Installation.
5. Führen Sie ein Upgrade auf Edge 4.15.07.00 durch.
6. Prüfen Sie nach dem Upgrade auf Version 4.15.07.00 die *.db-Dateien, um sicherzustellen, dass alle auf den C* 2.0-SSTable-Stil aktualisiert wurden:
   > cd /<install-root>/apigee4/data/cassandra/data
   > find . -name *-jb-*
   Dieser Befehl sollte eine Reihe von .db-Dateien zurückgeben, wenn Sie Cassandra 2.0 ausführen.

Neue Features und Verbesserungen

Im Folgenden sind die neuen Funktionen und Verbesserungen in diesem Release aufgeführt.

Installation und Upgrade

Selektives Aktualisieren und Deinstallieren von Komponenten

Mit den Skripts „apigee-upgrade.sh“ und „apigee-uninstall.sh“ können Sie jetzt die Edge-Komponenten auswählen, die aktualisiert oder deinstalliert werden sollen. Bisher wurden alle Komponenten auf dem Knoten aktualisiert oder deinstalliert. (OPDK-1377, OPDK-1175)

Rollback für Upgrade

Wenn das Skript „apigee-upgrade.sh“ während eines Upgrades fehlschlägt, können Sie das Upgrade jetzt mit dem Skript „apigee-rollback.sh“ rückgängig machen. Nachdem Sie alle Probleme mit dem Upgrade behoben haben, können Sie es noch einmal versuchen. (OPDK-1275)

Verkürzte Optionen für das Installationsskript

Die Installationsskripts unterstützen nicht mehr die Langform von Optionen wie „--help“. Sie akzeptieren jetzt nur noch Optionen mit einem einzelnen Buchstaben, z. B. -h. (OPDK-1356)

SmartDocs installieren

Wenn Sie SmartDocs mit dem Script setup-smartdocs.sh installieren, werden Sie aufgefordert, die Organisation, die Umgebung und den virtuellen Host einzugeben. So wird sichergestellt, dass SmartDocs am erwarteten Speicherort installiert wird. Bisher waren diese Werte im Skript hartcodiert. (OPDK-1310)

update-cass-pwd-in-config.sh ohne Aufforderungen ausführen

Das Skript „update-cass-pwd-in-config.sh“ kann ohne Aufforderungen ausgeführt werden, wenn Sie die Umgebungsvariablen ENABLE_CASS_AUTH, CASS_USERNAME und CASS_PASSWORD festlegen. (OPDK-1309)

Edge-Plattform

Im Folgenden sind die neuen Edge-Plattformfunktionen aufgeführt, die in dieser Version enthalten sind.

OpenJDK 1.7 wird von Edge Private Cloud unterstützt

Diese Version von Edge unterstützt Oracle JDK 1.7 und OpenJDK 7. Die Unterstützung für JDK 1.6 wurde entfernt. (OPDK-1187)

Betriebssystemunterstützung

Die Betriebssystemunterstützung für Apigee Edge for Private Cloud wurde auf Red Hat Enterprise Linux 6.6 und 7.0 (64-Bit), CentOS 6.5, 6.6 und 7.0 (64-Bit) sowie Oracle Linux 6.5 erweitert.

Cassandra 2.0.15 in OPDK 15.07 enthalten

Mit dieser Version wird Cassandra 2.0.15 installiert. Wenn Sie ein Upgrade von einer früheren Version durchführen, wird Ihre Cassandra-Version aktualisiert. (OPDK-1197)

SHA2-Unterstützung für das Hashing von OAuth-Tokens

Um OAuth-Tokens bei einer Sicherheitsverletzung der Datenbank besser zu schützen, unterstützt Edge SHA2-Algorithmen zum Hashen von OAuth-Tokens (zusätzlich zu SHA1). Mit neuen Eigenschaften auf Organisationsebene können Sie das Hashing für neue Tokens aktivieren und konfigurieren. Außerdem können Sie das Legacy-Hashing für alle Tokens beibehalten, die vor dieser neuen Funktion vorhanden waren. Bisher wurde in Edge for Private Cloud das automatische SHA1-Hashing von OAuth-Tokens durch das Attribut hash.oauth.tokens.enabled in der Datei keymanagement.properties (auf Ihrem Verwaltungsserver und Ihren Nachrichtenprozessoren) aktiviert. Dieses Attribut wird nicht mehr unterstützt.

Wenn Sie die Property „hash.oauth.tokens.enabled“ zuvor zum Aktivieren des SHA1-Hashing verwendet haben, werden die neuen Properties auf Organisationsebene automatisch durch das Upgrade-Script für diese Version generiert. So können Sie nach dem Upgrade prüfen, ob alles funktioniert: Führen Sie als Systemadministrator einen GET-Vorgang mit dieser API aus: https://{host}:{port}/v1/o/{your_org}.

• Informationen zum Aktivieren des Token-Hashing in Ihrer Organisation mit den neuen Attributen finden Sie im Thema Zugriffstokens anfordern unter „Tokens in der Datenbank hashen“.
• Informationen zum Bulk-Hashing vorhandener Tokens finden Sie im Edge for Private Cloud Operations Guide. (APIRT-1389)

Einfache Verzeichnisstruktur für Logdateien

Sie können Edge so konfigurieren, dass Logdateien in einer flachen Verzeichnisstruktur gespeichert werden. Dazu müssen Sie in der Datei „message-logging.properties“ ein neues enable.flat.directory.structure-Attribut auf „true“ setzen. Weitere Informationen finden Sie in der Richtlinie für Nachrichten-Logging. (APIRT-1394)

Umgebungscache-Leistung

Zur besseren Verwaltung und Nutzung des In-Memory-Cache wurden die Einstellungen für „Maximale Anzahl von Elementen im Arbeitsspeicher“ für Cache-Ressourcen der Umgebung eingestellt. Die Gesamtzahl der Elemente in allen Cache-Ressourcen (einschließlich des Standardcaches) hängt vom gesamten für den Cache zugewiesenen Arbeitsspeicher ab. Standardmäßig beträgt der für das In-Memory-Caching auf einem bestimmten Message Processor zugewiesene Gesamtspeicher 40% des insgesamt verfügbaren Speichers. Dieser wird durch die Cache-Property-Einstellungen in der Datei „cache.properties“ Ihres Message Processor-Caches bestimmt. Elemente werden nur dann aus dem In-Memory-Cache entfernt, wenn nicht genügend Cache-Speicher vorhanden ist oder die Elemente ablaufen.

Wenn Sie zum Verwalten des Caches wieder das alte Verhalten mit der Eigenschaft „Maximale Elemente im Arbeitsspeicher“ verwenden möchten, legen Sie die Eigenschaft overrideMaxElementsInCacheResource=false in der Datei „cache.properties“ fest. (APIRT-1140)

API-Dienste

Im Folgenden sind die neuen API Services-Funktionen aufgeführt, die in diesem Release enthalten sind.

Neuer Proxy-Editor als Standard

Der neue API-Proxy-Editor ist in der Verwaltungs-UI standardmäßig aktiviert. Der neue Editor bietet viele Verbesserungen in Bezug auf die Nutzerfreundlichkeit, darunter umfassendere Ansichten von bedingten Abläufen und Endpunkten auf der Seite „Übersicht“, die gesamte Konfiguration auf der Seite „Entwickeln“, intuitiveres Hinzufügen von bedingten Abläufen, Endpunkten und Richtlinien, vollständigere XML-Ansichten anstelle von kleinen Snippets sowie eine Suchfunktion, die Dateinamen und Text durchsucht. (MGMT-2279)

Neue Richtlinie zum Löschen von OAuth 2.0-Informationen

Mit der neuen Richtlinie „OAuth v2.0-Informationen löschen“ können Sie OAuth v2-Zugriffstokens und Autorisierungscodes löschen. Die Richtlinie ersetzt die Funktionen, die zuvor von der Management API bereitgestellt wurden. Weitere Informationen finden Sie unter DeleteOAuthV2Info-Richtlinie. (MGMT-2257)

Neue Richtlinie zum Löschen von OAuth v1.0-Informationen

Mit der neuen Richtlinie „OAuth v1.0-Informationen löschen“ können Sie OAuth v1.0-Anfragetokens, Zugriffstokens und Prüfcodes löschen. Die Richtlinie ersetzt die Funktionen, die zuvor von der Management API bereitgestellt wurden. Weitere Informationen finden Sie unter OAuth V1-Informationsrichtlinie löschen. (APIRT-1351)

Richtlinie zur Zugriffskontrolle

Die Richtlinie zur Zugriffssteuerung wurde verbessert, um eine detailliertere Auswertung von IP-Adressen für die Zulassungs- und Sperrliste zu ermöglichen, wenn IP-Adressen im HTTP-Header X-FORWARDED-FOR enthalten sind.

Wenn die Prüfung mehrerer IP-Adressen im Header aktiviert ist (wenden Sie sich an den Support, um die Funktion „feature.enableMultipleXForwardCheckForACL“ festzulegen), können Sie mit einem neuen <ValidateBasedOn>-Element in der Richtlinie die erste IP-Adresse, die letzte IP-Adresse oder alle IP-Adressen im Header prüfen. Weitere Informationen finden Sie unter Richtlinie zur Zugriffssteuerung.

Neue Entitäten in der Access Entity-Richtlinie

Die Zugriffsrichtlinie für Entitäten bietet Zugriff auf die folgenden neuen Entitäten: consumerkey-scopes, authorizationcode, requesttoken und verifier. Weitere Informationen finden Sie unter Access Entity-Richtlinie.

Statistics Collector-Richtlinie: Automatische Umwandlung des Statistiknamens in Kleinbuchstaben

Wenn Sie im API-Proxy-Editor (Seite „Entwickeln“ > „Tools“ > „Benutzerdefinierte Analytics-Sammlung“) eine benutzerdefinierte Analytics-Sammlung erstellen, muss die Collector-Variable (Statistik) „Name“ in Kleinbuchstaben angegeben werden. Wenn Sie den Namen mit Großbuchstaben eingeben, wandelt das Tool den Statistiknamen in der Statistics Collector-Richtlinie automatisch in Kleinbuchstaben um. (MGMT-740)

Entfernung von „Classic Trace“ im API-Proxy-Editor

Die neueste Version der Trace-Funktion im API-Proxy-Editor ist von der Betaversion zur allgemeinen Verfügbarkeit übergegangen. Der Zugriff auf „klassische Traces“ über den Link „Auf die klassische Version von Trace zugreifen“ ist nicht mehr möglich.

Über das Hilfemenü der Verwaltungs-UI auf die Apigee Community zugreifen

Sie können über das Hilfemenü der Verwaltungsoberfläche auf die Apigee-Community zugreifen.

Fehlermeldungen in der Verwaltungs-UI

Die Fehlermeldungen in der Verwaltungs-UI wurden verbessert:

• Die Verwaltungs-UI, mit der alle Fehlermeldungen in der Benutzeroberfläche für die gesamte Anmeldesitzung gruppiert und angezeigt werden, sofern Sie sie nicht geschlossen haben. Mit diesem Update werden die Fehlermeldungen automatisch gelöscht, wenn Sie die Seite verlassen, auf der sie aufgetreten sind. (MGMT-2254)
• In der Benutzeroberfläche für die Verwaltung werden doppelte Fehlermeldungen nicht mehr unterdrückt. (MGMT-2242)

Verbesserungen der Benutzeroberflächenleistung und Fehlerbehebung

Es wurden allgemeine Verbesserungen an verschiedenen Bereichen der Verwaltungsoberfläche vorgenommen, darunter die Leistung der Seitendarstellung und die Bereinigung von Fehlermeldungen.

Rollen-Hyperlinks auf der Seite „Organisationsnutzer“ in der Verwaltungs-UI

Auf der Seite „Organisationsnutzer“ in der Verwaltungsoberfläche („Verwaltung“ > „Organisationsnutzer“) sind Rollennamen jetzt verlinkt. So können Sie schnell zu den Rollenseiten navigieren. (MGMT-1055)

Neue Zielvariablen im Nachrichtenfluss

Neue Variablen in Nachrichtenflüssen liefern vollständigere URL-Informationen für Zielendpunkte und Zielserver:

• TargetEndpoint: request.url ersetzt target.basepath.with.query.
• TargetServer: loadbalancing.targetserver ersetzt targetserver.name. Außerdem wird target.basepath nur ausgefüllt, wenn das Element <Path> im HTTPTargetConnection-Element <LoadBalancer> des TargetEndpoint verwendet wird.

Unterstützung von Server Name Indication (SNI)

Edge unterstützt die Verwendung von Server Name Indication (SNI) in Richtung Süden (vom Nachrichtenprozessor zu Zielendpunkten). Wenn Sie SNI verwenden möchten, wenden Sie sich an den Apigee Edge-Support.

Java 1.7 ist erforderlich.

Mit SNI, einer Erweiterung von TLS/SSL, können mehrere HTTPS-Ziele über dieselbe IP-Adresse und denselben Port bereitgestellt werden, ohne dass für alle Ziele dasselbe Zertifikat erforderlich ist.

Es ist keine Edge-spezifische Konfiguration erforderlich. Wenn Ihre Umgebung für Southbound-SNI konfiguriert ist (Edge Cloud ist standardmäßig), wird dies von Edge unterstützt.

Edge extrahiert automatisch den Hostname aus der Anfrage-URL und fügt ihn der SSL-Handshake-Anfrage hinzu. Wenn der Zielhost beispielsweise https://beispiel.de/request/path ist, fügt Edge die Erweiterung server_name wie unten gezeigt hinzu:

Weitere Informationen zu SNI finden Sie unter http://en.wikipedia.org/wiki/Server_Name_Indication.

„Signaturalgorithmus“ in den Details zu SSL-Zertifikaten

Den SSL-Zertifikatsdetails wurde ein neues Feld „Signaturalgorithmus“ hinzugefügt, das in der Verwaltungsoberfläche (Admin > SSL-Zertifikate) und in der Verwaltungs-API (Zertifikatsdetails aus einem Keystore oder Truststore abrufen) angezeigt wird. In diesem Feld wird je nach Art des Hash-Algorithmus, der zum Generieren des Zertifikats verwendet wurde, entweder „sha1WithRSAEncryption“ oder „sha256WithRSAEncryption“ angezeigt.

SSL-Zertifikate anzeigen, die bald ablaufen

Auf der Seite „SSL-Zertifikate“ in der Verwaltungs-UI („Admin“ > „SSL-Zertifikate“) wird angegeben, wann SSL-Zertifikate innerhalb von 10, 15, 30 oder 90 Tagen ablaufen. Das hängt von Ihrer Auswahl im neuen Drop-down-Feld „Ablauf“ ab.

Bedrohungsschutzfehlerkonfiguration

Standardmäßig löst Edge bei einem Fehler in einer JSON- oder XML Threat Protection-Richtlinie den HTTP 500-Statuscode „Internal Server Error“ und den Fehler „ExecutionFailed“ aus. Sie können dieses Fehlerverhalten mit einer neuen Property auf Organisationsebene ändern. Wenn Sie das Organisationsattribut features.isPolicyHttpStatusEnabled auf „true“ setzen, geschieht Folgendes:

• Anfrage: Wenn eine Bedrohungsschutzrichtlinie an einen Anfrageablauf angehängt wird, geben ungültige Nachrichten einen 400-Statuscode zusammen mit einer entsprechenden Richtlinienfehlermeldung zurück.
• Antwort: Wenn eine Bedrohungsschutzrichtlinie an einen Antwortablauf angehängt wird, wird bei ungültigen Nachrichten weiterhin der Statuscode 500 zurückgegeben und eine der entsprechenden Richtlinienfehlermeldungen wird ausgegeben (statt nur „ExecutionFailed“).

Cloud-Kunden müssen sich an den Apigee Edge-Support wenden, um die Organisationseigenschaft festzulegen. Diese Funktion wird für Edge Private Cloud-Kunden in der nächsten vierteljährlichen Private Cloud-Version verfügbar sein.

Aktualisierte Schemas für Endpunkte, Proxys und andere Elemente

Referenzschemas wurden für nicht richtlinienbezogene Entitäten wie TargetEndpoint, ProxyEndpoint und APIProxy aktualisiert. Weitere Informationen finden Sie unter https://github.com/apigee/api-platform-samples/tree/master/schemas. (APIRT-1249)

Entwicklerdienste

Im Folgenden sind die neuen Funktionen der Developer Services aufgeführt, die in dieser Version enthalten sind.

Allgemeine Verfügbarkeit von SmartDocs

SmartDocs ist nach dem Abschluss der Betaphase jetzt allgemein verfügbar. Updates und neue Funktionen:

• Unterstützung für Swagger 2.0, einschließlich Import per Datei oder URL, einschließlich Unterstützung für benutzerdefinierte Sicherheitsbenennungsobjekte.
• Verbesserungen des visuellen Designs in den Vorlagen, mit denen SmartDocs generiert werden.
• Verbesserungen der Benutzerfreundlichkeit und des Workflows im Entwicklerportal, die über das Menü „Inhalte“ > „SmartDocs“ in Drupal verfügbar sind.
• Die bisher als „Benutzerdefiniertes Token“ bekannte Authentifizierung wird jetzt als „API-Schlüssel“ bezeichnet.
• Auf Revisionsebene definierte Authentifizierungssicherheitsobjekte.
• Konfiguration der Clientauthentifizierung auf Vorlagenebene. Bei neuen Überarbeitungen werden keine vorkonfigurierten SmartDocs-Clientanmeldedaten mehr zurückgesetzt.

Weitere Informationen zu den Funktionen finden Sie in diesem Blogpost.

Die SmartDocs-Dokumentation finden Sie unter APIs mit SmartDocs dokumentieren.

Name der Entwickler-App, der in der Verwaltungs-UI angezeigt wird

Entwickler-Apps in Edge haben sowohl einen internen Namen, der sich nicht ändert, als auch einen Anzeigenamen, den Sie ändern können. Auf einer Seite für Entwickler-Apps in der Verwaltungs-UI („Veröffentlichen“ > „Entwickler-Apps“ > „App-Name“) wird der interne „Name“ der App zusammen mit dem „Anzeigenamen“ angezeigt. So lassen sich Apps anhand ihrer internen Namen leichter visuell identifizieren, was die Fehlerbehebung und API-Verwaltung vereinfacht.

Analytics-Dienste

Im Folgenden sind die neuen Funktionen von Analytics Services aufgeführt, die in dieser Version enthalten sind.

Zeitlimit für die Aufbewahrung von Daten

Wenn Sie Analysenberichte über die Verwaltungs-UI oder die API erstellen, ist der Zugriff auf Daten, die älter als sechs Monate ab dem aktuellen Datum sind, nicht standardmäßig möglich. Wenn Sie auf Daten zugreifen möchten, die älter als sechs Monate sind, wenden Sie sich an den Apigee Edge-Support.

Klassische Version von benutzerdefinierten Berichten wird aus der Verwaltungs-UI entfernt

Die optionale klassische Version von benutzerdefinierten Analyseberichten ist in der Verwaltungs-UI nicht mehr verfügbar.

Leistung des Widgets für die Entwicklerinteraktion

Das Trichterdiagramm im Haupt-Analytics-Dashboard (Bereich „Entwicklerinteraktion“) wurde optimiert, um eine bessere Leistung zu bieten.

Monetarisierung

Im Folgenden sind die neuen Monetarisierungsfunktionen aufgeführt, die in dieser Version enthalten sind.

E-Mail-Benachrichtigungen zu Preisplänen

Mit dem neuen E‑Mail-Benachrichtigungstyp „Tarifpaket“ können Sie Entwickler benachrichtigen, wenn sie in den von ihnen erworbenen Tarifpaketen mit gestaffelten Preisen oder Bundle-Tarifpaketen ein bestimmtes Transaktions- oder Dollar-Limit erreicht haben. Weitere Informationen finden Sie unter Benachrichtigungen mit Benachrichtigungsvorlagen einrichten.

Synchronisierung von Zeiträumen für wiederkehrende Gebühren und Aggregationsgrundlage

In einem Tarif waren möglicherweise zwei verschiedene Zeiträume aktiv:

• Zeitraum für wiederkehrende Gebühren, der auf dem Tab „Gebühren“ eines Tarifpakets konfiguriert wurde und bestimmt, wann Entwicklern eine wiederkehrende Gebühr berechnet wurde.
• Der Zeitraum für die Aggregation, der auf der Preisliste für Tarife mit Volumenstaffelung oder Tarife mit Paketen definiert ist und bestimmt, wann die Paketnutzung für Entwickler zurückgesetzt wurde.

Die beiden Zeiträume sind jetzt synchronisiert. Wenn in einem Tarif sowohl eine wiederkehrende Gebühr ungleich null als auch eine Preisliste mit Volumengruppen oder eine Bundle-Preisliste vorhanden sind, wird der Zeitraum für die wiederkehrende Gebühr für beide verwendet. Wenn beispielsweise eine monatlich wiederkehrende Gebühr anfällt, werden auch die Ratenkarten-Pakete monatlich zurückgesetzt (standardmäßig zu Monatsbeginn).

Wenn keine wiederkehrende Gebühr vorhanden ist, werden die Pakete basierend auf der in der Preisliste definierten Aggregationsgrundlage zurückgesetzt. Wenn ein Entwickler beispielsweise am 19. eines Monats beginnt, eine Ratenkarte zu verwenden, und die Aggregationsgrundlage monatlich ist, wird die Nutzung des Pakets einen Monat nach dem 19. zurückgesetzt.

„Aggregation Basis“ wird eingestellt und in einer zukünftigen Version aus der Monetarisierung entfernt. Weitere Informationen finden Sie unter Details zum Ratenkartenplan angeben.

Benutzerdefinierte Attribute in Berichten zur Umsatzzusammenfassung

Mit Richtlinien zur Transaktionsaufzeichnung können Sie optional Daten zu benutzerdefinierten Attributen aus Transaktionen erfassen. Diese benutzerdefinierten Transaktionsattribute lassen sich jetzt in zusammenfassende Umsatzberichte einbeziehen. Wenn Sie Ihrer Organisation die Eigenschaft MINT.SUMMARY_CUSTOM_ATTRIBUTES hinzufügen, können Sie angeben, welche benutzerdefinierten Attribute den Datenbanktabellen zur Verwendung in Berichten hinzugefügt werden.

Apigee Edge for Private Cloud-Kunden können das Flag mit dem folgenden API-Aufruf und den Anmeldedaten des Systemadministrators festlegen.

curl -u email:password -X PUT -H "Content-type:application/xml" http://host:8080/v1/o/myorg -d \
"<Organization type="trial" name="MyOrganization">
    <Properties>
        <Property name="features.isMonetizationEnabled">true</Property>
        <Property name="MINT.SUMMARY_CUSTOM_ATTRIBUTES">[&quot;my_attribute_1&quot;,&quot;my_attribute_2&quot;]</Property>
        <Property name="features.topLevelDevelopersAreCompanies">false</Property>
    </Properties>
</Organization>"

Das Array benutzerdefinierter Attribute im API-Aufruf ist URL-codiert.

SmartDocs-Upgrade

Wenn Sie SmartDocs bereits in der Betaphase verwendet haben, müssen Sie SmartDocs in Ihrem Entwicklerportal aktualisieren, um die neuen Funktionen und Möglichkeiten der allgemein verfügbaren Version nutzen zu können.

Alle SmartDocs-Seiten, die bereits in Ihrem Entwicklerportal veröffentlicht wurden, funktionieren weiterhin. Sie müssen jedoch den Aktualisierungsprozess durchlaufen, bevor Sie Änderungen an bestehenden oder neuen Seiten bearbeiten oder veröffentlichen.

SmartDocs können zwar in Ihrem Entwicklerportal gerendert und veröffentlicht werden, sie werden jedoch aus dem API-Modell generiert, das sich in den Edge API Management Services von Apigee befindet. Alle Änderungen, die Sie an einem API-Modell in Edge vornehmen, sind in allen Ihren Pantheon-Umgebungen gleich (ähnlich wie Entwickler in Pantheon-Umgebungen vorhanden sind).

Von der SmartDocs-Betaversion auf die General Availability-Version upgraden

1. Aktualisieren und testen Sie die Version 15.05.27 in Ihren dev- oder test-Umgebungen auf Pantheon.
2. Erstellen Sie ein neues Modell, um alle vorhandenen API-Modelle zu ersetzen, die Sie verwendet haben.
   • Wenn Sie Swagger- oder WADL-Dokumente importiert haben, importieren Sie sie noch einmal in eine neue Revision.
   • Wenn Sie Ihr API-Modell über das SmartDocs-Modul verwaltet haben, exportieren Sie es als SmartDocs-JSON und importieren Sie es über einen Dateianhang in Ihr neues Modell.
3. Legen Sie die Sicherheitseigenschaften der Revision Ihres Modells fest. Wählen Sie auf der Seite Inhalte > SmartDocs > Modell die Option Sicherheitseinstellungen aus.
   
4. Prüfen Sie auf der Seite mit den Modelleinstellungen (Inhalte > SmartDocs) alle vorkonfigurierten Authentifizierungen, indem Sie in der Spalte „Vorgänge“ auf Einstellungen klicken.
   
5. Aktualisieren Sie alle benutzerdefinierten Vorlagen, damit sie die Version 6 der CSS- und JS-Assets verwenden, und nehmen Sie Änderungen vor, um neue Objektnamen wie „authSchemes“ und „apiSchema“ zu berücksichtigen. Informationen zum Aktualisieren von SmartDocs-Vorlagen finden Sie unter SmartDocs zum Dokumentieren von APIs verwenden.
6. Rendern Sie die Modellrevision noch einmal und veröffentlichen Sie sie.
7. Nachdem Sie die neue Dokumentation geprüft haben, aktualisieren Sie Ihr Produktionsportal auf die Version vom 27.05.15.

Wenn Sie ein Edge-Unternehmenskunde sind und Fragen oder Bedenken zum Upgrade-Prozess haben, senden Sie bitte eine E-Mail an marsh@apigee.com und cnovak@apigee.com. Andernfalls nutzen Sie bitte die Apigee-Community, um die beste Antwort zu erhalten.

Zukünftige Änderungen und Verbesserungen an Funktionen

In diesem Abschnitt finden Sie eine Vorschau auf erwartete zukünftige Änderungen und Verbesserungen an Funktionen:

Änderung des Verhaltens von ResponseCache-Richtlinien

In einem zukünftigen Release (Termin noch nicht festgelegt) ändert sich das Standardverhalten des Elements <ExcludeErrorResponse> der Response Cache-Richtlinie.

Aktuelles Verhalten:Das Element <ExcludeErrorResponse> in der ResponseCache-Richtlinie ist standardmäßig auf „false“ gesetzt. Das bedeutet, dass Antworten mit jedem möglichen HTTP-Statuscode (einschließlich 3xx) standardmäßig von der Response Cache-Richtlinie im Cache gespeichert werden.

Zukünftiges Verhalten:Das Element <ExcludeErrorResponse> in der ResponseCache-Richtlinie wird standardmäßig auf „true“ gesetzt. Das bedeutet, dass standardmäßig nur Antworten mit HTTP-Statuscodes von 200 bis 205 im Cache gespeichert werden. Wenn Sie dieses Verhalten überschreiben und Antworten für alle Statuscodes im Cache speichern möchten, müssen Sie das Element <ExcludeErrorResponse> explizit auf „true“ setzen.

Aktueller Workaround : Wenn Sie in Private Cloud 4.15.07.00 und älteren Versionen nur Antworten mit den Statuscodes 200 bis 205 im Cache speichern möchten, müssen Sie das Element <ExcludeErrorResponse> explizit auf „true“ setzen.

Fehlerkorrekturen

Folgende Fehler wurden in diesem Release behoben.

Bekannte Probleme

Dieser Release weist die folgenden bekannten Probleme auf.

> source /{install-dir}/apigee4/bin/apigee-env.sh

> VER=`basename $(find $SHARE_DIR/installer/monetization -name "mint-*.zip") | cut -d "-" -f 2,3,4`

> sed -i "s/^MONETIZATION_VERSION=.*/MONETIZATION_VERSION=$VER/" /install-dir/apigee4/bin/apigee-env.sh

> rm /install-dir/apigee4/share/monetization

**************************************
In order to complete the monetization upgrade please run:
sudo /opt/apigee4/share/monetization/schema/migration/MOPDK4.15.04.00/
365-create-notification-condition.sh
**************************************

connect.ranges.denied=10.0.0.0/8,192.168.0.0/16,127.0.0.1/32

<install_dir>/apigge4/bin/apigee-service message-processor restart