Antimuster bei der Migration von Apigee Edge zu Apigee X

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

Als aktueller Apigee Edge-Kunde können Sie Ihre Installation zu Apigee X migrieren, um neue Funktionen oder eine andere regionale Verfügbarkeit zu nutzen.

Auf dieser Seite werden Antipatterns in Ihrer Konfiguration beschrieben, die Sie vor der Migration zu Apigee X beheben müssen. Außerdem werden andere Verhaltensänderungen beschrieben, die Sie vor der Migration berücksichtigen sollten.

In der umfassenderen Liste der Apigee Edge-Antimuster werden Nutzungspraktiken beschrieben, die in jedem Fall vermieden werden sollten. Auf dieser Seite werden die spezifischen nicht empfohlenen Nutzungspraktiken beschrieben, die eine Migration verhindern. Beheben Sie diese Probleme jetzt, um Probleme bei der Migration zu Apigee X zu vermeiden.

Apps ohne API-Produkte
Zusammenfassung Sind clientseitige Änderungen erforderlich? Lösung

Es gibt Apps ohne API-Produkte.

Unterschied zwischen Apigee Edge und Apigee X:

Apigee Edge Apigee X
Es ist möglich, eine App und Anmeldedaten zu konfigurieren, die keinem API-Produkt zugeordnet sind. Diese App hat effektiv Zugriff auf alle API-Produkte. Jede App muss für den Zugriff auf mindestens ein API-Produkt konfiguriert sein. Es gibt keine Möglichkeit, implizit Zugriff auf alle API-Produkte zu gewähren. Sie können eine App so konfigurieren, dass sie Zugriff auf alle API-Produkte hat. Dazu müssen Sie jedoch explizit die entsprechenden Einstellungen vornehmen.
Nein.

Lösung: Apps ohne API-Produkte

Verknüpfen Sie jede App-Anmeldedaten mit mindestens einem API-Produkt. Weitere Informationen dazu finden Sie unter Apps registrieren und API-Schlüssel verwalten.

Am einfachsten ist es, jeder App Zugriff auf alle API-Produkte zu gewähren. Dies entspricht den Möglichkeiten in Apigee Edge. Die Herausforderung besteht darin, dass Sie bei einem Ansatz mit dem Prinzip der geringsten Berechtigung die Mindestliste der API-Produkte festlegen müssen, auf die jede App-Anmeldedaten Zugriff haben müssen. Sie können dies mit Apigee Edge Analytics-Berichten auf Grundlage der Client-ID analysieren.

Cache ohne Ablaufzeit
Zusammenfassung Sind clientseitige Änderungen erforderlich? Lösung

Caches haben keine Ablaufzeit.

Unterschied zwischen Apigee Edge und Apigee X:

Apigee Edge Apigee X
Unterstützt das Erstellen, Aktualisieren und Löschen von Cache-Ressourcendeskriptoren. Das Erstellen, Aktualisieren oder Löschen von Cache-Ressourcendeskriptoren wird nicht unterstützt.
Nein

Lösung: Cache ohne Ablaufzeit

Legen Sie ein Ablaufdatum für alle Caches fest.

JSONPath-Filterausdrücke für nicht eindeutige Pfade
Zusammenfassung Sind clientseitige Änderungen erforderlich? Lösung

Bei nicht definitiven Pfaden ist das Abfragen des Ergebnisses eines Filterausdrucks nicht Teil der JSONPath-Spezifikation. Weitere Informationen finden Sie unter https://goessner.net/articles/JsonPath/.

Unterschied zwischen Apigee Edge und Apigee X:

Wenn Sie in dieser Beispielstruktur navigieren,

{
    "books": [
      {
        "name": "A",
      },
      {
        "name": "B",
      }
    ]
}

Mit dem Ausdruck $..books[?(@.name == 'A')][0]

Apigee Edge Apigee X
Ausgaben ‘{"name": "A"}’ Ausgaben []

Mit dem Ausdruck $..books[?(@.name == 'A')][0].name

Apigee Edge Apigee X
Ausgaben "A" Ausgaben []
Ja

Lösung: JSONPath-Filterausdrücke für nicht eindeutige Pfade

Betroffene Anfragen suchen und ersetzen

JSONPath-Ausdrücke für nicht vorhandene Indexe
Zusammenfassung Sind clientseitige Änderungen erforderlich? Lösung

JSONPath-Ausdrücke mit einem Index, der nicht vorhanden ist, haben in Apigee X ein anderes Verhalten als in Apigee Edge. Apigee X gibt einen PathNotFoundException-Fehler zurück, wenn der Pfad nicht gefunden wird.

Unterschied zwischen Apigee Edge und Apigee X:

Wenn Sie in dieser Beispielstruktur navigieren,

{
    "books": [
      {
        "name": "A",
      },
      {
        "name": "B",
      }
    ]
}

Mit dem Ausdruck $.books[3]

Apigee Edge Apigee X
Ausgaben null Ausgaben PathNotFoundException-Fehler
Ja

Lösung: JSONPath-Ausdrücke für nicht vorhandene Indexe

Betroffene Anfragen suchen und ersetzen

JSONPath-Ausdrücke mit einem Array-Index, die kein Array-Objekt zurückgeben
Zusammenfassung Sind clientseitige Änderungen erforderlich? Lösung

JSONPath-Ausdrücke mit einem Arrayindex oder Slices geben in Apigee X ein Arrayobjekt zurück.

Unterschied zwischen Apigee Edge und Apigee X:

Wenn Sie in dieser Beispielstruktur navigieren,

{
    "books": [
      {
        "name": "A",
      },
      {
        "name": "B",
      }
    ]
}

Mit dem Ausdruck $.books

Apigee Edge Apigee X
Ausgaben {“name”:”A”, “name”: “B”} Ausgaben [{“name”:”A”, “name”: “B”}]

Mit dem Ausdruck $.books[-1]

Apigee Edge Apigee X
Ausgaben {“name”: “B”} Ausgaben [{“name”: “B”}]

Mit dem Ausdruck $.books[-2:]

Apigee Edge Apigee X
Ausgaben {“name”:”A”, “name”: “B”} Ausgaben [{“name”:”A”, “name”: “B”}]
Ja

Lösung: JSONPath-Ausdrücke mit einem Array-Index, die kein Array-Objekt zurückgeben

Suchen und Ersetzen von Ausdrücken, die nach dem Upgrade möglicherweise unterschiedliche Ergebnisse zurückgeben.

Einschränkungen für Namen von Schlüsselspeichern
Zusammenfassung Sind clientseitige Änderungen erforderlich? Lösung

Apigee X-Keystore-Namen dürfen nur Buchstaben, Ziffern und Bindestriche enthalten. Für Edge-Keystore-Namen gelten diese Einschränkungen nicht.

Nein

Lösung: Einschränkungen für Namen von Schlüsselspeichern

Prüfen Sie die Keystore-Namen und entfernen Sie bei Bedarf nicht unterstützte Zeichen.

Mehrere Basispfade für einen API-Proxy bereitgestellt
Zusammenfassung Sind clientseitige Änderungen erforderlich? Lösung

Mehrere Revisionen eines API-Proxys werden in einer Umgebung bereitgestellt und jede Revision hat einen anderen Basispfad.

Unterschied zwischen Apigee Edge und Apigee X:

Apigee Edge Apigee X
Unterstützt die Bereitstellung mehrerer Revisionen eines API-Proxys, wobei jede Revision einen anderen Basispfad haben kann. Unterstützt nicht die Bereitstellung mehrerer Revisionen eines API-Proxys, auch wenn der Proxy unterschiedliche Basispfade hat.
Nein

Lösung: Mehrere Basispfade für einen API-Proxy bereitgestellt

Aktualisieren Sie alle Bundles so, dass unabhängig vom Basispfad nur eine Revision eines Bundles in einer Umgebung bereitgestellt wird.

Nicht konforme HTTP-Nachrichten
Zusammenfassung Sind clientseitige Änderungen erforderlich? Lösung

Clients oder der API-Proxy senden Nachrichten (Anfragen oder Antworten), die nicht dem HTTP-Standard entsprechen. Beispiele sind ungültige Headernamen oder Duplikate in einigen eingeschränkten Headern.

Sie können nicht zu Apigee X migrieren, wenn bei der Ausführung Ihrer API einer oder mehrere der folgenden Fehler auftreten:

Fehler Details
INVALID_CHARACTERS_IN_HEADER Im angegebenen Header wurden ein oder mehrere unzulässige Zeichen gefunden. Gültige Headernamen bestehen aus Buchstaben, Ziffern und Bindestrichen.
MISSING_COLON Im Header-Namen und ‑Wert-Paar fehlt ein : (Doppelpunkt).
MULTIPLE_CONTENT_LENGTH Für den Content-Length-Header wurden mehrere Werte angegeben.
CONTENT_LENGTH_NOT_INTEGER Der Headerwert „Content-Length“ ist keine Ganzzahl.
INVALID_UPGRADE Der Upgrade-Header muss nur zum Aktivieren von WebSocket-Verbindungen verwendet werden, was aber nicht der Fall ist.
URL_HEADER_SIZE_TOO_LONG Die Gesamtgröße der Anfrage-URL und der Header überschreitet die maximal zulässige Größe von 15 KB.
BODY_NOT_ALLOWED Ein Nachrichtentext ist bei den Methoden „GET“, „DELETE“, „TRACE“, „OPTIONS“ und „HEAD“ nicht zulässig.
UNSUPPORTED_HTTP_VERSION Für die Anfrage wird eine andere HTTP-Version als 1.1 verwendet, die nicht unterstützt wird.
ZERO_CONTENT_LENGTH_FOR_POST_OR_PUT Für eine „POST“- oder „PUT“-Methode wurde ein Content-Length-Headerfeldwert von null („0“) festgelegt.
UNSUPPORTED_RESPONSE_PREFIX Im Antwortheader war ein nicht unterstütztes „X-Apigee-“-Headerpräfix vorhanden.
Ja, möglicherweise.

Lösung: Nicht konforme HTTP-Nachrichten

Sie müssen alle Fehler in HTTP-Protokollen beheben, bevor Sie zu Apigee X migrieren. Wenn ein Fehler in einer Clientanwendung auftritt, müssen Sie den Entwickler der Client-App bitten, das Problem zu beheben.

Ablaufzeit des OAuth 2.0-Tokens ungültig
Zusammenfassung Sind clientseitige Änderungen erforderlich? Lösung

Die Ablaufgrenzen für OAuth 2.0-Tokens liegen außerhalb des vorgeschriebenen Bereichs.

Unterschied zwischen Apigee Edge und Apigee X:

Apigee Edge Apigee X
Derzeit wird keine Beschränkung für die Ablaufzeit des OAuth 2.0-Tokens erzwungen, dies ist jedoch geplant. Weitere Informationen finden Sie im OAuth-Abschnitt auf der Seite „Einschränkungen“. Sie müssen eine Ablaufzeit für das Zugriffstoken und das Aktualisierungstoken für OAuth 2.0 festlegen. Folgende Bereiche werden unterstützt:
  • 180 Sekunden <= Ablaufzeit des OAuth 2.0-Zugriffstokens <= 30 Tage
  • 1 Tag <= Ablaufzeit des OAuth 2.0-Aktualisierungstokens <= 2 Jahre
Nein

Lösung: Ablaufzeit des OAuth 2.0-Tokens ungültig

Verwenden Sie die OAuthV2-Richtlinie und geben Sie die Ablaufzeit in <ExpiresIn> und <RefreshTokenExpiresIn> an.

Produktlimits überschritten
Zusammenfassung Sind clientseitige Änderungen erforderlich? Lösung

Die Konfiguration von Apigee Edge entspricht nicht den definierten Produktlimits. Einige Produktlimits, die dokumentiert, aber nicht in Apigee Edge erzwungen werden, werden in Apigee X erzwungen.

Nein

Lösung: Produktlimits überschritten

Korrigieren Sie jegliche Nutzung, die die Produktlimits überschreitet, bevor Sie zu Apigee X migrieren.

ServiceCallout-Richtlinien mit sowohl Endpunkt- als auch Pfad-Zielverbindungsspezifizierern
Zusammenfassung Sind clientseitige Änderungen erforderlich? Lösung

Das <LocalTargetConnection>-Element in der ServiceCallout-Richtlinie sollte entweder die Elemente <APIProxy> und <ProxyEndpoint> oder das Element <Path> enthalten, aber nicht beides. Weitere Informationen finden Sie unter Element <LocalTargetConnection>.

Diese Anforderung wird in Apigee Edge dokumentiert, aber nicht erzwungen. Die Verarbeitung in Apigee X wird beendet, wenn eine <LocalTargetConnection> mit beiden Konfigurationen gefunden wird.

Nein

Lösung: ServiceCallout-Richtlinien mit sowohl Endpunkt- als auch Pfad-Zielverbindungsspezifizierern

Prüfen Sie die ServiceCallout-Richtlinienkonfigurationen und entfernen Sie alle nicht konformen <LocalTargetConnection>-Konfigurationen.

Einschränkungen für den Namen des Zielservers
Zusammenfassung Sind clientseitige Änderungen erforderlich? Lösung

Apigee X-Zielservernamen dürfen nur Buchstaben, Ziffern, Bindestriche und Punkte enthalten. Für Edge-Zielservernamen gelten diese Einschränkungen nicht.

Nein

Lösung: Einschränkungen für Zielservernamen

Prüfen Sie die Namen der Zielserver und aktualisieren Sie sie, um nicht unterstützte Zeichen zu entfernen, falls erforderlich.

Testzertifikat in einem virtuellen Host
Zusammenfassung Sind clientseitige Änderungen erforderlich? Lösung

Für einen oder mehrere virtuelle Hosts wird das von Apigee bereitgestellte „Free Trial“-Zertifikat verwendet. Dadurch reagiert der virtuelle Host auf Anfragen für Domains wie ORG-ENV.apigee.net.

Unterschied zwischen Apigee Edge und Apigee X:

Apigee Edge Apigee X
Konfiguriert den „default“-VHost automatisch für die Unterstützung eines Domainnamens im Format ORG-ENV.apigee.net. Es gibt ein Platzhalterzertifikat, das als „Zertifikat für den kostenlosen Testzeitraum“ bezeichnet wird und TLS für diese Domains ermöglicht. Legacy-Apigee-Domains im Format ORG-ENV.apigee.net sind in Apigee X nicht verfügbar. Sie müssen Ihren eigenen Domainnamen konfigurieren und Zertifikate entsprechend bereitstellen.
Ja

Lösung: Testzertifikat in einem virtuellen Host

Sie müssen Ihre eigene Domain konfigurieren und Zertifikate entsprechend bereitstellen.

Alle Clientanwendungen, die vom alten Domainnamen des Formulars ORG-ENV.apigee.net abhängen, müssen so geändert werden, dass sie die neue Domain aufrufen.

DNS nicht aufgelöst
Zusammenfassung Sind clientseitige Änderungen erforderlich? Lösung

Die Zielendpunkte haben nicht aufgelöste Domainnamen.

Unterschied zwischen Apigee Edge und Apigee X:

Apigee Edge Apigee X
Wenn die DNS-Auflösung fehlschlägt, hängt Apigee .apigee.com an den Domainnamen an und die DNS-Auflösung ist mit dem Antwortcode 4xx erfolgreich. Wenn die DNS-Auflösung fehlschlägt, führt Apigee die Anfrage nicht aus und gibt den Antwortcode 5xx zurück.
Nein

Lösung: Nicht aufgelöste DNS

Aktualisieren Sie den Zielendpunkt mit einem gültigen Domainnamen.