דף זה תורגם על ידי Cloud Translation API.

תבניות נגד מיגרציה מ-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.

לא

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

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

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

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

כמה עדכונים של שרת 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 עם מפרטים של חיבורים לנקודת קצה ולנתיב

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

במדיניות 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
הגדרה אוטומטית של מארח וירטואלי (vhost) 'ברירת מחדל' לתמיכה בשם דומיין מהצורה `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 לא מפוענח

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