‫Google משתמשת בטכנולוגיית AI כדי לתרגם תוכן לשפה המועדפת עליך. בתרגומים כאלו עשויות להיות שגיאות.

תבניות נגד מיגרציה מ-Apigee Edge ל-Apigee X

אתם צופים במסמכי התיעוד של Apigee Edge.
כדאי לעיין במסמכי התיעוד של Apigee X. מידע

אם אתם לקוחות Apigee Edge, יכול להיות שתבחרו להעביר את ההתקנה שלכם אל Apigee X כדי ליהנות מיכולות חדשות או מזמינות אזורית שונה.

בדף הזה מוסבר על דפוסי אנטי-תבנית בהגדרה שלכם שצריך לטפל בהם לפני המעבר ל-Apigee X, וגם על שינויים אחרים בהתנהגות שחשוב להכיר לפני המעבר.

ברשימה המורחבת של דפוסי שימוש לא מומלצים ב-Apigee Edge מתוארות שיטות שימוש שכדאי להימנע מהן בכל מקרה. בדף הזה מתוארות שיטות שימוש ספציפיות שלא מומלצות, שיגרמו לחסימת ההעברה. כדי למנוע בעיות במהלך המעבר ל-Apigee X, צריך לפתור את הבעיות האלה עכשיו.

אפליקציות ללא מוצרי API

סיכום נדרשים שינויים בצד הלקוח? פתרון

יש אפליקציות בלי מוצרי API.

ההבדל בין Apigee Edge לבין Apigee X:

‫Apigee Edge	‫Apigee X
אפשר להגדיר אפליקציה ופרטי כניסה שלא משויכים למוצר API כלשהו. לאפליקציה הזו יש למעשה גישה לכל מוצרי ה-API.	צריך להגדיר לכל אפליקציה גישה למוצר API אחד לפחות. אין דרך לספק גישה לכל מוצרי ה-API באופן מרומז. אפשר להגדיר לאפליקציה גישה לכל מוצרי ה-API, אבל צריך לעשות זאת במפורש.

לא.

פתרון: אפליקציות ללא מוצרי API

משייכים כל אישור גישה לאפליקציה למוצר API אחד לפחות. מידע נוסף על אופן ההרשמה מופיע במאמר הרשמת אפליקציות וניהול מפתחות API.

דרך קלה היא להקצות לכל אפליקציה גישה לכל מוצרי ה-API. התוצאה תהיה זהה למה שאפשר לעשות ב-Apigee Edge. האתגר יהיה אם תרצו להשתמש בגישה של 'הרשאה מינימלית'. במקרה כזה, תצטרכו לקבוע את רשימת מוצרי ה-API המינימלית שלכל פרטי כניסה של אפליקציה צריכה להיות גישה אליהם. אפשר לנתח את הנתונים האלה באמצעות דוחות של Apigee Edge Analytics, על סמך מזהה לקוח.

מטמון ללא מועד תפוגה

סיכום נדרשים שינויים בצד הלקוח? פתרון

למטמון אין מועד תפוגה.

ההבדל בין Apigee Edge לבין Apigee X:

‫Apigee Edge	‫Apigee X
תמיכה ביצירה, בעדכון ובמחיקה של תיאורי משאבי מטמון.	לא תומך ביצירה, בעדכון או במחיקה של תיאורי משאבי מטמון.

לא

פתרון: מטמון ללא מועד תפוגה

הגדרת מועד תפוגה לכל המטמונים.

ביטויי סינון של JSONPath בנתיבים לא מוגדרים

סיכום נדרשים שינויים בצד הלקוח? פתרון

שאילתות על תוצאות של ביטויי סינון לא נכללות במפרט של JSONPath עבור נתיבים לא סופיים. מידע נוסף זמין בכתובת https://goessner.net/articles/JsonPath/.

ההבדל בין Apigee Edge לבין Apigee X:

כשמנווטים במבנה הדוגמה הזה,

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

עם הביטוי $..books[?(@.name == 'A')][0],

‫Apigee Edge	‫Apigee X
פלטים `‘{"name": "A"}’`	פלטים `[]`

עם הביטוי $..books[?(@.name == 'A')][0].name,

‫Apigee Edge	‫Apigee X
פלטים `"A"`	פלטים `[]`

כן

פתרון: ביטויי מסנן JSONPath בנתיבים לא מוגדרים

למצוא ולהחליף את השאילתות המושפעות.

ביטויים של JSONPath לאינדקסים שלא קיימים

סיכום נדרשים שינויים בצד הלקוח? פתרון

לביטויי JSONPath עם אינדקס שלא קיים יש התנהגויות שונות ב-Apigee X לעומת Apigee Edge. ‫Apigee X מחזיר שגיאה PathNotFoundException אם הנתיב לא נמצא.

ההבדל בין Apigee Edge לבין Apigee X:

כשמנווטים במבנה הדוגמה הזה,

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

עם הביטוי $.books[3],

‫Apigee Edge	‫Apigee X
פלטים `null`	פלט `PathNotFoundException` שגיאה

כן

רזולוציה: ביטויי JSONPath לאינדקסים שלא קיימים

למצוא ולהחליף את השאילתות המושפעות.

ביטויים של JSONPath עם אינדקס של מערך שלא מחזירים אובייקט של מערך

סיכום נדרשים שינויים בצד הלקוח? פתרון

ביטויי JSONPath עם אינדקס או פרוסות של מערך מחזירים אובייקט מערך ב-Apigee X.

ההבדל בין Apigee Edge לבין Apigee X:

כשמנווטים במבנה הדוגמה הזה,

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

עם הביטוי $.books,

‫Apigee Edge	‫Apigee X
פלטים `{“name”:”A”, “name”: “B”}`	פלטים `[{“name”:”A”, “name”: “B”}]`

עם הביטוי $.books[-1],

‫Apigee Edge	‫Apigee X
פלטים `{“name”: “B”}`	פלטים `[{“name”: “B”}]`

עם הביטוי $.books[-2:],

‫Apigee Edge	‫Apigee X
פלטים `{“name”:”A”, “name”: “B”}`	פלטים `[{“name”:”A”, “name”: “B”}]`

כן

פתרון: ביטויי JSONPath עם אינדקס מערך שלא מחזירים אובייקט מערך

חיפוש והחלפה של ביטויים שעשויים להחזיר תוצאות שונות אחרי השדרוג.

הגבלות על שמות של מאגרי מפתחות

סיכום נדרשים שינויים בצד הלקוח? פתרון

שמות של מאגרי מפתחות ב-Apigee X יכולים להכיל רק אותיות, מספרים ומקפים. ההגבלות האלה לא חלות על שמות של מאגר מפתחות ב-Edge.

לא

פתרון: הגבלות על שם מאגר המפתחות

בודקים את השמות של מאגרי המפתחות ומעדכנים אותם כדי להסיר תווים לא נתמכים, אם צריך.

כמה נתיבי בסיס שנפרסו ל-proxy ל-API

סיכום נדרשים שינויים בצד הלקוח? פתרון

כמה עדכונים של שרת proxy ל-API נפרסים בסביבה, ולכל עדכון יש נתיב בסיס שונה.

ההבדל בין Apigee Edge לבין Apigee X:

‫Apigee Edge	‫Apigee X
תומך בפריסה של כמה גרסאות של proxy ל-API, כאשר לכל גרסה יכול להיות נתיב בסיס שונה.	לא תומך בפריסה של כמה גרסאות של proxy ל-API, גם אם ל-proxy יש נתיבי בסיס שונים.

לא

פתרון: כמה נתיבי בסיס נפרסו עבור proxy ל-API

מעדכנים את כל החבילות כך שרק גרסה אחת של חבילה תופעל בסביבה, ללא קשר לנתיב הבסיס.

הודעות HTTP שלא עומדות בדרישות

סיכום נדרשים שינויים בצד הלקוח? פתרון

לקוחות או שרת proxy של API שולחים הודעות (בקשות או תשובות) שלא עומדות בתקן HTTP. לדוגמה, שמות כותרות לא תקינים, כפילויות בכמה כותרות מוגבלות וכו'.

אי אפשר לבצע מיגרציה ל-Apigee X אם בהרצת ה-API מופיעה אחת או יותר מהשגיאות הבאות:

שגיאה	פרטים
INVALID_CHARACTERS_IN_HEADER	נמצאו תו אחד או יותר לא חוקיים בכותרת שצוינה. שמות כותרות תקינים מורכבים מאותיות באנגלית, מספרים ומקפים.
MISSING_COLON	חסר הסימן `:` (נקודתיים) בצמד של שם הכותרת וערך הכותרת.
MULTIPLE_CONTENT_LENGTH	צוינו כמה ערכים בכותרת Content-Length.
CONTENT_LENGTH_NOT_INTEGER	הערך של הכותרת Content-Length הוא לא מספר שלם.
INVALID_UPGRADE	צריך להשתמש בכותרת Upgrade רק כדי להפעיל חיבורי WebSocket, אבל בפועל לא עושים את זה.
URL_HEADER_SIZE_TOO_LONG	הגודל הכולל של כתובת ה-URL של הבקשה והכותרות חורג מהגודל המקסימלי המותר של 15KB.
BODY_NOT_ALLOWED	אסור להשתמש בגוף ההודעה עם השיטות GET,‏ DELETE,‏ TRACE,‏ OPTIONS ו-HEAD.
UNSUPPORTED_HTTP_VERSION	הבקשה משתמשת בגרסת HTTP שאינה 1.1, ואין תמיכה בגרסה הזו.
ZERO_CONTENT_LENGTH_FOR_POST_OR_PUT	הוגדר ערך אפס ("0") בשדה הכותרת Content-Length (אורך התוכן) עבור שיטת POST או PUT.
UNSUPPORTED_RESPONSE_PREFIX	קידומת הכותרת X-Apigee- לא נתמכת והיא מופיעה בכותרת התגובה.

כן, יכול להיות.

פתרון: הודעות HTTP שלא עומדות בדרישות

צריך לתקן את כל השגיאות בפרוטוקולי HTTP לפני המעבר ל-Apigee X. אם השגיאה נובעת מאפליקציית לקוח, צריך לבקש ממפתח אפליקציית הלקוח לתקן את הבעיה.

תוקף הטוקן של OAuth 2.0 לא תקין

סיכום נדרשים שינויים בצד הלקוח? פתרון

הגבלות התפוגה של אסימוני OAuth 2.0 חורגות מהטווח שנקבע.

ההבדל בין Apigee Edge לבין Apigee X:

‫Apigee Edge	‫Apigee X
בשלב הזה לא מתבצעת אכיפה של מגבלות על תוקף אסימון OAuth 2.0, אבל אנחנו מתכננים לאכוף אותן בעתיד. אפשר לעיין בהנחיות בקטע בנושא OAuth בדף ההגבלות.	צריך להגדיר את זמן התפוגה של אסימון הגישה ושל טוקן הרענון עבור OAuth 2.0. הטווחים הנתמכים הם: ‫180 שניות <= זמן התפוגה של אסימון הגישה מסוג OAuth 2.0 <= 30 ימים יום אחד <= מועד התפוגה של טוקן הרענון מסוג OAuth 2.0 <= שנתיים

לא

פתרון: התוקף של טוקן OAuth 2.0 לא תקין

משתמשים במדיניות OAuthV2 ומציינים את מועד התפוגה ב-<ExpiresIn> וב-<RefreshTokenExpiresIn>.

חריגה מהגבלות על מוצרים

סיכום נדרשים שינויים בצד הלקוח? פתרון

ההגדרה של Apigee Edge לא עומדת במגבלות המוצר שהוגדרו. חלק ממגבלות המוצרים שמתועדות אבל לא נאכפות ב-Apigee Edge נאכפות ב-Apigee X.

לא

פתרון: חריגה ממגבלות המוצרים

לפני המעבר ל-Apigee X, צריך לתקן את השימוש אם הוא חורג ממגבלות המוצר.

מדיניות ServiceCallout עם מפרטי חיבור של נקודת קצה (endpoint) ושל יעד נתיב

סיכום נדרשים שינויים בצד הלקוח? פתרון

במדיניות ServiceCallout, הרכיב <LocalTargetConnection> צריך לכלול את הרכיבים <APIProxy> ו-<ProxyEndpoint> או את הרכיב <Path>, אבל לא את שניהם. מידע נוסף זמין ברכיב <LocalTargetConnection>.

הדרישה הזו מתועדת ב-Apigee Edge, אבל לא נאכפת. אם המערכת נתקלת ב-<LocalTargetConnection> עם שתי ההגדרות, היא מפסיקה את העיבוד.

לא

פתרון: כללי מדיניות מסוג ServiceCallout עם מפרטי חיבור של נקודת קצה ושל נתיב

בודקים את ההגדרות של מדיניות ServiceCallout ומסירים את כל ההגדרות שלא עומדות בדרישות.<LocalTargetConnection>

הגבלות על שם שרת היעד

סיכום נדרשים שינויים בצד הלקוח? פתרון

שמות של שרתי יעד ב-Apigee X יכולים להכיל רק אותיות, מספרים, מקפים ונקודות. ההגבלות האלה לא חלות על שמות של שרתי יעד ב-Edge.

לא

פתרון: הגבלות על שם שרת היעד

בודקים את שמות שרתי היעד ומעדכנים את השמות כדי להסיר תווים לא נתמכים, אם יש צורך בכך.

אישור ניסיון במארח וירטואלי

סיכום נדרשים שינויים בצד הלקוח? פתרון

אחד או יותר מהמארחים הווירטואליים משתמשים באישור 'תקופת ניסיון בחינם' שסופק על ידי Apigee. כך המארח הווירטואלי מגיב לבקשות בדומיינים כמו ORG-ENV.apigee.net.

ההבדל בין Apigee Edge לבין Apigee X:

‫Apigee Edge	‫Apigee X
ההגדרה האוטומטית של מארח וירטואלי 'ברירת מחדל' כדי לתמוך בשם דומיין מהצורה `ORG-ENV.apigee.net`. יש אישור כללי (wildcard) שנקרא 'אישור תקופת הניסיון', שמאפשר TLS בדומיינים האלה.	דומיינים מדור קודם של Apigee מהצורה `ORG-ENV.apigee.net` לא זמינים ב-Apigee X. אתם צריכים להגדיר שם דומיין משלכם ולספק אישורים מתאימים.

כן

פתרון: אישור ניסיון בשרת וירטואלי

אתם צריכים להגדיר את הדומיין שלכם ולספק אישורים בהתאם.

כל אפליקציית לקוח שמסתמכת על שם הדומיין הקודם של הטופס ORG-ENV.apigee.net צריכה לעבור שינוי כדי לקרוא לדומיין החדש.

DNS לא מפוענח

סיכום נדרשים שינויים בצד הלקוח? פתרון

לנקודות הקצה של היעד יש שמות דומיין שלא נפתרו.

ההבדל בין Apigee Edge לבין Apigee X:

‫Apigee Edge	‫Apigee X
אם פענוח ה-DNS נכשל, Apigee מוסיפה `.apigee.com` לשם הדומיין, ופענוח ה-DNS מצליח עם קוד תגובה `4xx`.	אם פענוח ה-DNS נכשל, Apigee לא מבצע את הבקשה ומחזיר קוד תגובה `5xx`.

לא

רזולוציה: DNS לא מפוענח

מעדכנים את נקודת הקצה של היעד עם שם דומיין תקין.