הפניית תצורה של שרת proxy ל-API

מוצג התיעוד של Apigee Edge.
נכנסים למסמכי התיעוד של Apigee X.
מידע

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

אם אתם לומדים איך ליצור שרתי proxy של API, מומלץ להתחיל עם הנושא בניית שרת proxy פשוט ל-API.

הדרכים הנפוצות ביותר לעריכת הגדרות של שרת proxy הן:

פיתוח מקומי של הגדרות שרת proxy

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

הקטע הזה מתאר כיצד להשתמש בממשק המשתמש כדי להוריד גרסה קיימת של שרת proxy, לערוך אותו ואז להעלות אותו חזרה ל-Edge לצורך פריסה. אפשר גם להשתמש ב-apigeetool כדי להוריד ולפרוס תצורה חדשה של שרת proxy (באמצעות הפקודות fetchproxy ו-deployproxy, בהתאמה).

כדי לערוך הגדרה של שרת proxy באופן מקומי באמצעות ממשק המשתמש:

  1. הורדת ההגדרה הנוכחית של שרת ה-Proxy בממשק המשתמש של Edge. (בתצוגה של API proxy, בוחרים באפשרות Project > Download Revision.)
  2. במחשב המקומי, יוצרים ספרייה חדשה ומרחיבים אליה את קובץ ה-ZIP שהורדתם.

    כדי להרחיב את קובץ ה-ZIP, אפשר להשתמש בכלי כמו unzip, כמו בדוגמה הבאה:

    mkdir myappdir
    unzip ./my-app_app_rev3_2019_04_20.zip -d myappdir

    התוכן המורחב של קובץ ה-ZIP צריך להיות דומה למבנה שמתואר במאמר מבנה של שרת proxy ל-API.

  3. עורכים את קובצי המקור לפי הצורך. לתיאור של קובצי המקור בהגדרות של שרת proxy אפשר לעיין במאמר קובצי תצורה ומבנה הספריות של שרת proxy ל-API.

    לדוגמה, כדי להפעיל מעקב אחר תקינות בשרת ה-API של ה-API, צריך לערוך את קובץ התצורה של TargetEndpoint בספרייה /apiproxy/targets/. קובץ ברירת המחדל בספרייה הזו הוא default.xml, אבל יכולים להיות קבצים עם שמות שונים אם משתמשים ביעדים מותנים.

    במקרה הזה, אם קובץ התצורה של TargetEndpoint והספרייה שלו לא קיימים, יוצרים אותם.

  4. כשמסיימים לערוך את קובצי התצורה של שרת ה-proxy, חשוב לשמור את השינויים.
  5. עוברים לספרייה החדשה שיצרתם כשהרחבתם את קובצי ה-ZIP (השורש של קובצי התצורה המורחבים).

    לדוגמה, אם הרחבתם את הקבצים לספרייה /myappdir, עוברים לספרייה הזו, כמו בדוגמה הבאה:

    cd myappdir

    צריך לעבור לספרייה הזו לפני שמעבירים לארכיון מחדש את קובצי התצורה של שרת ה-proxy, כי לא רוצים שספריית /myappdir תיכלל בקובץ ה-ZIP. הספרייה ברמה העליונה בקובץ ה-ZIP חייבת להיות /apiproxy.

  6. מעבירים מחדש לארכיון את קובצי התצורה של שרת ה-proxy, כולל הקבצים החדשים או הקבצים שהשתנו. אפשר להשתמש בכלי כמו zip, כמו בדוגמה הבאה:
    zip my-new-proxy.zip -r .

    הספרייה ברמה העליונה בקובץ ה-ZIP חייבת להיות /apiproxy.

    אין דרישות מיוחדות לשם של קובץ ה-ZIP. לדוגמה, אין צורך להגדיל את מספר הגרסה או לציין את התאריך בשם הקובץ, אבל זה יכול להיות שימושי לניפוי באגים או לבקרת מקורות.

    Edge מגדיל את מספר הגרסה של תצורת שרת ה-proxy החדשה עבורך כשמעלים אותה.

  7. העלאת ההגדרה החדשה של שרת proxy באמצעות ממשק המשתמש של Edge. (בתצוגה APIs proxy, בוחרים באפשרות Project > Upload a New Revision (העלאת גרסה חדשה).

    אם מופיעה שגיאה כמו Bundle is invalid. Empty bundle., צריך לוודא שהספרייה ברמה העליונה של קובץ ה-ZIP היא /apiproxy. אם לא, מעבירים מחדש לארכיון את קובצי התצורה של שרת ה-proxy מהשורש של הספרייה המורחבת.

    אחרי העלאת ההגדרות האישיות של שרת ה-proxy החדש, Edge מגדילה את מספר הגרסה ומציגה אותו בתצוגה סיכום גרסאות.

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

  8. פורסים את הגרסה הקודמת.

למידע נוסף, ראו מדריך: איך להוריד שרת proxy באמצעות ממשק המשתמש ו-Management API בקהילת Apigee.

מבנה של שרת proxy ל-API

שרת proxy של API מורכב מהתצורה הבאה:

הגדרות בסיסיות הגדרות אישיות ראשיות לשרת proxy ל-API. למידע נוסף, ראו הגדרות בסיסיות.
הגדרת ProxyEndpoint ההגדרות לחיבור ה-HTTP הנכנס (מבקשת אפליקציות ל-Apigee Edge), תהליכי הבקשה והתגובה וקבצים מצורפים למדיניות. ראו ProxyEndpoint.
הגדרת נקודת הקצה (TargetEndpoint) הגדרות לחיבור HTTP יוצא (מ-Apigee Edge לשירות הקצה העורפי), זרימות של בקשות ותגובה וקבצים מצורפים למדיניות. ראו TargetEndpoint
זרימות צינורות עיבוד הבקשות והתגובה של ProxyEndpoint ו-TargetEndpoint שאליהם אפשר לצרף את כללי המדיניות למידע נוסף, ניתן לעיין בזרימות.
כללי מדיניות קובצי תצורה בפורמט XML שתואמים לסכימות המדיניות של Apigee Edge. לפרטים נוספים, אפשר לעיין במדיניות.
מקורות מידע סקריפטים, קובצי JAR וקובצי XSLT שכללי המדיניות מפנים אליהם כדי להפעיל לוגיקה בהתאמה אישית. ראו משאבים.

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

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

מציג את מבנה הספרייה שבה apiproxy הוא הבסיס. ישירות בספריית apiproxy נמצאים כללי המדיניות, שרתי ה-proxy, המשאבים וספריות היעדים, וגם את הקובץ weatherapi.xml.

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

בקטע הזה נסביר על קובצי התצורה ומבנה הספריות של שרת proxy ל-API.

הגדרות בסיסיות

/apiproxy/weatherapi.xml

תצורת הבסיס של שרת proxy ל-API, שמגדירה את השם של שרת ה-proxy של ה-API. השם חייב להיות ייחודי בארגון.

תצורה לדוגמה:

<APIProxy name="weatherapi">
</APIProxy>

רכיבים של תצורת בסיס

שם תיאור ברירת המחדל חובה?
APIProxy
name השם של שרת ה-proxy ל-API, חייב להיות ייחודי בתוך ארגון. התווים שמותר לך להשתמש בהם בשם מוגבלים הבאים: A-Za-z0-9_- לא רלוונטי כן
revision מספר הגרסה של תצורת שרת ה-proxy ל-API. אין צורך להגדיר במפורש את מספר הגרסה, כי Apigee Edge עוקב באופן אוטומטי אחר הגרסה הנוכחית של שרת ה-proxy של ה-API. לא רלוונטי לא
ConfigurationVersion גרסת סכימת התצורה של שרת proxy ל-API שאליה תואם שרת ה-proxy הזה של API. הערך הנתמך היחיד בשלב זה הוא largeVersion 4 ו-secondaryVersion 0. יכול להיות שנשתמש בהגדרה הזו בעתיד כדי לאפשר את הפיתוח של פורמט שרת ה-API ל-API. 4.0 לא
Description תיאור טקסטואלי של שרת ה-API של שרת ה-proxy. אם הוספת תיאור, הוא יוצג בממשק המשתמש לניהול Edge. לא רלוונטי לא
DisplayName שם ידידותי למשתמש שעשוי להיות שונה מהמאפיין name של הגדרת שרת ה-proxy ל-API. לא רלוונטי לא
Policies רשימה של כללי מדיניות בספרייה /policies של שרת ה-API הזה. בדרך כלל הרכיב הזה יופיע רק כששרת ה-API של שרת ה-proxy נוצר באמצעות ממשק המשתמש לניהול Edge. זוהי פשוט הגדרת 'מניפסט' שנועדה לספק שקיפות לגבי התוכן של שרת ה-proxy ל-API. לא רלוונטי לא
ProxyEndpoints רשימה של ProxyEndpoints בספרייה /proxies של שרת ה-API הזה. בדרך כלל הרכיב הזה יופיע רק כששרת ה-API של שרת ה-proxy נוצר באמצעות ממשק המשתמש לניהול Edge. זוהי פשוט הגדרת 'מניפסט' שנועדה לספק שקיפות לגבי התוכן של שרת ה-proxy ל-API. לא רלוונטי לא
Resources רשימת משאבים (JavaScript, Python, Java, XSLT) בספרייה /resources של שרת ה-proxy הזה ל-API. בדרך כלל הרכיב הזה יופיע רק כששרת ה-API של שרת ה-proxy נוצר באמצעות ממשק המשתמש לניהול Edge. זוהי פשוט הגדרת 'מניפסט' שנועדה לספק חשיפה לתוכן של שרת ה-proxy ל-API. לא רלוונטי לא
Spec מזהה את מפרט OpenAPI שמשויך לשרת ה-proxy של ה-API. הערך מוגדר ככתובת URL או לנתיב במאגר של המפרט.

הערה: חנות המפרטים זמינה בממשק החדש של Edge בלבד. למידע נוסף על חנות המפרטים, ראו ניהול ושיתוף של מפרטים.
לא רלוונטי לא
TargetServers רשימה של שרתי TargetServer שיש הפניה אליהם בכל TargetEndpoints של שרת ה-API הזה. בדרך כלל הרכיב הזה יופיע רק כששרת ה-API של שרת ה-proxy נוצר באמצעות ממשק המשתמש לניהול Edge. זוהי פשוט הגדרת 'מניפסט' שנועדה לספק שקיפות לגבי התוכן של שרת ה-proxy ל-API. לא רלוונטי לא
TargetEndpoints רשימה של TargetEndpoints בספרייה /targets של שרת ה-proxy הזה ל-API. בדרך כלל הרכיב הזה יופיע רק כששרת ה-API של שרת ה-proxy נוצר באמצעות ממשק המשתמש לניהול Edge. זוהי פשוט הגדרת 'מניפסט' שנועדה לספק שקיפות לגבי התוכן של שרת ה-proxy ל-API. לא רלוונטי לא

ProxyEndpoint

התמונה הבאה מציגה את זרימת הבקשה/תגובה:

מוצג לקוח שמתקשר לשירות HTTP. הבקשה עוברת דרך נקודת הקצה של שרת ה-proxy ואז דרך נקודת הקצה של היעד לפני
  שהיא מעובדת על ידי שירות ה-HTTP. התגובה עוברת דרך היעד הסופי ולאחר מכן דרך נקודת הקצה של שרת ה-proxy לפני שהיא מוחזרת ללקוח.

/apiproxy/proxies/default.xml

ההגדרה של ProxyEndpoint מגדירה את הממשק הנכנס (הגלוי ללקוח) עבור שרת proxy ל-API. כשאתם מגדירים נקודת גישה ל-ProxyEndpoint, אתם קובעים הגדרת רשת שמגדירה איך אפליקציות לקוח ('אפליקציות') יפעילו את ה-API דרך שרת proxy.

ההגדרה הבאה של ProxyEndpoint תאוחסן במסגרת /apiproxy/proxies:

<ProxyEndpoint name="default">
  <PreFlow/>
  <Flows/>
  <PostFlow/>
  <HTTPProxyConnection>
    <BasePath>/weather</BasePath>
    <VirtualHost>default</VirtualHost>
  </HTTPProxyConnection>
  <FaultRules/>
  <DefaultFaultRule/>
  <RouteRule name="default">
    <TargetEndpoint>default</TargetEndpoint>
  </RouteRule>
</ProxyEndpoint>

רכיבי התצורה הנדרשים ב-ProxyEndpoint בסיסי הם:

רכיבי תצורת ProxyEndpoint

שם תיאור ברירת המחדל חובה?
ProxyEndpoint
name השם של ProxyEndpoint. חייב להיות ייחודי בתצורת ה-API של שרת ה-proxy, כאשר (במקרים נדירים) מוגדרות מספר ProxyEndpoints. התווים שמותר לך להשתמש בהם מוגבלים לתווים הבאים: A-Za-z0-9._\-$ %. לא רלוונטי כן
PreFlow הגדרת המדיניות בתהליך PreFlow של בקשה או תגובה. לא רלוונטי כן
Flows
הגדרת המדיניות בתהליכים המותנים של בקשה או תגובה.
לא רלוונטי כן
PostFlow
מגדיר את המדיניות בתהליך ה-PostFlow של בקשה או תגובה.
לא רלוונטי כן
HTTPProxyConnection הגדרה של כתובת הרשת ונתיב ה-URI שמשויכים לשרת ה-proxy ל-API
BasePath

מחרוזת נדרשת שמזהה באופן ייחודי את נתיב ה-URI שמשמש את Apigee Edge לניתוב הודעות נכנסות לשרת ה-API המתאים.

BasePath הוא מקטע URI (לדוגמה /weather) שמצורף לכתובת ה-URL הבסיסית של שרת proxy ל-API (לדוגמה, http://apifactory-test.apigee.net). ה-BasePath חייב להיות ייחודי בסביבה. הייחודיות מאומתת כשנוצר או מיובא שרת proxy ל-API.

שימוש בתו כללי לחיפוש בנתיבים בסיסיים

אפשר להשתמש בתו כללי לחיפוש "*" אחד או יותר בנתיבי הבסיס של שרת ה-proxy ל-API. לדוגמה, נתיב בסיסי של /team/*/members מאפשר ללקוחות להפעיל את https://[host]/team/blue/members ואת https://[host]/team/green/members בלי שיהיה צורך ליצור שרתי proxy חדשים ל-API כדי לתמוך בצוותים חדשים. לתשומת ליבך: התו /**/ לא נתמך.

חשוב: ב-Apigee אין תמיכה בשימוש בתו כללי לחיפוש '*' בתור האלמנט הראשון של נתיב הבסיס. לדוגמה, אין תמיכה באפשרות הזו: /*/search. התחלת הנתיב הבסיסי באמצעות "*" עלולה להוביל לשגיאות לא צפויות, בגלל האופן שבו Edge מזהה נתיבים חוקיים.

/ כן
VirtualHost

משייך שרת proxy של API לכתובות בסיס ספציפיות של סביבה. VirtualHost הוא הגדרה בעלת שם שמגדירה כתובת URL אחת או יותר של סביבה.

שמות מארחים וירטואליים שמוגדרים ל-ProxyEndpoint קובעים את הדומיינים והיציאות שבהם נחשף שרת proxy של API, ולכן, כתוצאה מכך, את כתובת ה-URL שבה אפליקציות משתמשות כדי להפעיל שרת proxy של API.

כברירת מחדל, מוגדרים שני מארחים וירטואליים בעלי שם לסביבה: default ו-secure. ארגון יכול גם להגדיר דומיינים מותאמים אישית. כדי לוודא ששרת proxy של API זמין רק ב-HTTPS, למשל, מגדירים את VirtualHost ב-HTTPProxyConnection ל-secure.

ברירת מחדל לא
Properties ניתן לקבוע קבוצה של הגדרות אופציונליות ב-HTTP כמאפיינים של <ProxyEndpoint>. לא רלוונטי לא
FaultRules
הגדרת האופן שבו ProxyEndpoint מגיב לשגיאה. כלל כשל מציין שני פריטים:
  • תנאי שמציין את התקלה שיש לטפל בה על סמך הקטגוריה, קטגוריית המשנה או השם של התקלה שהוגדרו מראש
  • מדיניות אחת או יותר המגדירה את ההתנהגות של כלל התקלה עבור התנאי המתאים

למידע נוסף, ראו טיפול בפגמים.

לא רלוונטי לא
DefaultFaultRule

טיפול בשגיאות (מערכת, העברה, העברת הודעות או מדיניות) שלא מטופלות במפורש על ידי כלל שגיאה אחר.

למידע נוסף, ראו טיפול בפגמים.

לא רלוונטי לא
RouteRule מגדיר את היעד של הודעות בקשה נכנסות לאחר עיבוד על ידי צינור עיבוד הנתונים של ProxyEndpoint. בדרך כלל, ה-RouteRule מצביע על תצורת TargetEndpoint בעלת שם, אבל הוא יכול גם להפנות ישירות לכתובת URL.
Name מאפיין חובה שמספק שם ל-RouteRule. התווים שמותר לך להשתמש בהם בשם מוגבלים לתווים הבאים: A-Za-z0-9._\-$ %. לדוגמה, Cat2 %_ הוא שם חוקי. לא רלוונטי כן
Condition הצהרה מותנית אופציונלית שמשמשת לניתוב דינמי בזמן ריצה. כללי מסלול מותנים שימושיים, לדוגמה, כדי להפעיל ניתוב מבוסס-תוכן שיתמוך בניהול גרסאות של הקצה העורפי. לא רלוונטי לא
TargetEndpoint

מחרוזת אופציונלית שמזהה תצורה בעלת שם של TargetEndpoint. 'TargetEndpoint' בעל שם הוא כל 'TargetEndpoint' שמוגדר באותו שרת proxy ל-API בספרייה /targets).

כשנותנים שם ל-TargetEndpoint, מציינים לאן צריך להעביר הודעות בקשה אחרי עיבוד על ידי צינור עיבוד הנתונים של ProxyEndpoint. לתשומת ליבך, זוהי הגדרה אופציונלית.

ProxyEndpoint עשוי לקרוא לכתובת URL ישירות. לדוגמה, משאב JavaScript או Java, שמתפקד בתפקיד לקוח HTTP, עשוי לבצע את התפקיד הבסיסי של TargetEndpoint, שהוא העברת בקשות לשירות קצה עורפי.

לא רלוונטי לא
כתובת URL מחרוזת אופציונלית שמגדירה כתובת רשת יוצאת שנקראת ProxyEndpoint, ועוקפת כל תצורות TargetEndpoint שעשויות להיות שמורות ב-/targets לא רלוונטי לא

כיצד להגדיר כללי מסלול

TargetEndpoint בעל שם מתייחס לקובץ תצורה תחת /apiproxy/targets, שאליו ה-RouteRule מעביר בקשה אחרי עיבוד על ידי ProxyEndpoint.

לדוגמה, ה-RouteRule הבא מתייחס לתצורה /apiproxy/targets/myTarget.xml:

<RouteRule name="default">
  <TargetEndpoint>myTarget</TargetEndpoint>
</RouteRule>

הפעלה ישירה של כתובת URL

נקודת ProxyEndpoint יכולה גם להפעיל שירות קצה עורפי באופן ישיר. הפעלה ישירה של כתובת URL עוקפת כל הגדרה בשם TargetEndpoints במסגרת /apiproxy/targets. לכן, TargetEndpoint הוא הגדרה אופציונלית של שרת proxy ל-API, אבל בפועל לא מומלץ להפעיל ישירות מ-ProxyEndpoint.

לדוגמה, ה-RouteRule הבא מבצע קריאת HTTP ל-http://api.mycompany.com/v2.

<RouteRule name="default">
  <URL>http://api.mycompany.com/v2</URL> 
</RouteRule>

נתיבים מותנים

ניתן לשרשר את כללי הנתיב כדי לתמוך בניתוב דינמי בזמן הריצה. אפשר לנתב בקשות נכנסות לתצורות של TargetEndpoint בעלות שם, ישירות לכתובות URL או לשילוב של השניים, על סמך כותרות HTTP, תוכן ההודעה, פרמטרים של שאילתות או מידע הקשרי כמו השעה ביום, הלוקאל וכו'.

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

לדוגמה, השילוב הבא של RouteRule מעריך תחילה את הבקשה הנכנסת כדי לאמת את הערך של כותרת ה-HTTP. אם בכותרת ה-HTTP routeTo יש את הערך TargetEndpoint1, הבקשה תועבר ל-TargetEndpoint בשם TargetEndpoint1. אם לא, הבקשה הנכנסת תועבר אל http://api.mycompany.com/v2.

<RouteRule name="MyRoute">
  <Condition>request.header.routeTo = "TargetEndpoint1"</Condition>
  <TargetEndpoint>TargetEndpoint1</TargetEndpoint>
</RouteRule>
<RouteRule name="default">
  <URL>http://api.mycompany.com/v2</URL>
</RouteRule>

מסלולים אפסיים

אפשר להגדיר RouteRule ריק כדי לתמוך בתרחישים שבהם אין צורך להעביר את הודעת הבקשה ל-TargetEndpoint. האפשרות הזו שימושית כש-ProxyEndpoint מבצע את כל העיבוד הנדרש, לדוגמה, באמצעות JavaScript כדי לקרוא לשירות חיצוני או מאחזר נתונים מחיפוש במאגר המפתחות/הערך של שירותי ה-API.

לדוגמה, הדוגמה הבאה מגדירה נתיב null:

<RouteRule name="GoNowhere"/>

נתיבי null מותנים יכולים להיות שימושיים. בדוגמה הבאה, השדה null Route מוגדר להפעלה כשיש לכותרת ה-HTTP request.header.X-DoNothing ערך שהוא לא null.

<RouteRule name="DoNothingOnDemand">
  <Condition>request.header.X-DoNothing != null</Condition>
</RouteRule>

חשוב לזכור שאפשר לשרשר את הכללים של Route Rules, כך שנתיב null מותנה הוא בדרך כלל רכיב אחד מתוך קבוצה של כללי Route Rules שנועדו לתמוך בניתוב מותנה.

שימוש מעשי בנתיב null מותנה יתמוך בשמירה במטמון. באמצעות הערך של המשתנה שמוגדר במדיניות מטמון, אפשר להגדיר שרת proxy ל-API שיבצע את הנתיב הריק כשמוצגת רשומה מהמטמון.

<RouteRule name="DoNothingUnlessTheCacheIsStale">
  <Condition>lookupcache.LookupCache-1.cachehit is true</Condition>
</RouteRule>

TargetEndpoint

מוצג לקוח שמתקשר לשירות HTTP. הבקשה עוברת דרך נקודת הקצה של שרת ה-proxy ואז דרך נקודת הקצה של היעד לפני
  שהיא מעובדת על ידי שירות ה-HTTP. התגובה עוברת דרך היעד הסופי ולאחר מכן דרך נקודת הקצה של שרת ה-proxy לפני שהיא מוחזרת ללקוח.

TargetEndpoint הוא המקבילה היוצאת של ProxyEndpoint. TargetEndpoint מתפקד כלקוח בשירות או ב-API של קצה עורפי – הוא שולח בקשות ומקבל תגובות.

לשרת proxy של API לא צריכים להיות TargetEndpoints. אפשר להגדיר את ProxyEndpoints לקרוא לכתובות URL ישירות. שרת proxy ל-API ללא TargetEndpoints מכיל בדרך כלל נקודת ProxyEndpoint שקוראת לשירות לקצה העורפי באופן ישיר, או שמוגדר להפעלת שירות באמצעות Java או JavaScript.

הגדרה של נקודת הקצה (TargetEndpoint)

/targets/default.xml

ה-TargetEndpoint מגדיר את החיבור היוצא מ-Apigee Edge לשירות או למשאב אחר.

הנה דוגמה לתצורה של TargetEndpoint:

<TargetEndpoint name="default">
  <PreFlow/>
  <Flows/>
  <PostFlow/>
  <HTTPTargetConnection>
    <URL>http://mocktarget.apigee.net</URL>
    <SSLInfo/>
  </HTTPTargetConnection>
  <FaultRules/>
  <DefaultFaultRule/>
  <ScriptTarget/>
  <LocalTargetConnection/>
</TargetEndpoint>

רכיבי הגדרה של TargetEndpoint

TargetEndpoint יכול להפעיל יעד באחת מהדרכים הבאות:

  • HTTPTargetConnection עבור קריאות HTTP(S)
  • LocalTargetConnection לשרשור של שרת proxy מקומי לשרת proxy
  • ScriptTarget עבור קריאות לסקריפט Node.js שמתארח ב-Edge

צריך להגדיר רק אחד מהם ב-TargetEndpoint.

שם תיאור ברירת המחדל חובה?
TargetEndpoint
name השם של ה-TargetEndpoint, שחייב להיות ייחודי בהגדרת שרת ה-proxy ל-API. השם של TargetEndPoint משמש ב-ProxyEndpoint RouteRule כדי לשלוח בקשות ישירות לעיבוד יוצא. התווים שמותר לך להשתמש בהם בשם מוגבלים ל: A-Za-z0-9._\-$ %. לא רלוונטי כן
PreFlow הגדרת המדיניות בתהליך PreFlow של בקשה או תגובה. לא רלוונטי כן
Flows
הגדרת המדיניות בתהליכים המותנים של בקשה או תגובה.
לא רלוונטי כן
PostFlow
מגדיר את המדיניות בתהליך ה-PostFlow של בקשה או תגובה.
לא רלוונטי כן
HTTPTargetConnection

באמצעות רכיבי צאצא, מציין טווח הגעה של משאב בקצה עורפי דרך HTTP.

אם משתמשים ב-HTTPTargetConnection, אל תגדירו סוגים אחרים של חיבורי יעד (ScriptTarget או LocalTargetConnection).

URL המדיניות הזו מגדירה את כתובת הרשת של השירות לקצה העורפי שאליו TargetEndpoint מעביר הודעות בקשה. לא רלוונטי לא
LoadBalancer

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

אפשר גם להשתמש ב-TargetServers כדי להפריד בין הגדרות של שרתי proxy ל-API לבין כתובות URL של נקודות קצה של שירותים עורפיים ספציפיים.

למידע נוסף, ראו איזון עומסים בין שרתים עורפיים.

לא רלוונטי לא
Properties ניתן לקבוע קבוצה של הגדרות אופציונליות ב-HTTP כמאפיינים של <TargetEndpoint>. לא רלוונטי לא
SSLInfo אפשר גם להגדיר הגדרות TLS/SSL ב-TargetEndpoint כדי לשלוט בחיבור TLS/SSL בין שרת ה-API לבין שירות היעד. למידע נוסף, ראו הגדרת TLS/SSL TargetEndpoint. לא רלוונטי לא
LocalTargetConnection באמצעות האלמנטים הצאצאים שלו, הוא מציין משאב שצריך להגיע אליו באופן מקומי, תוך עקיפת מאפייני הרשת כמו איזון עומסים ומעבדי הודעות.

כדי לציין את משאב היעד, כוללים את רכיב הצאצא של APIProxy (עם הרכיב ProxyEndpoint) או את אלמנט הצאצא של נתיב.

מידע נוסף זמין במאמר שרשור של שרתי proxy של API ביחד.

אם משתמשים ב-LocalTargetConnection, אין להגדיר סוגים אחרים של חיבורי יעד (HTTPTargetConnection או ScriptTarget).

APIProxy מציין את השם של שרת proxy ל-API שישמש כיעד לבקשות. שרת ה-proxy ליעד חייב להיות באותו ארגון וסביבה שבהם שרת ה-proxy שולח את הבקשות. זוהי חלופה לשימוש ברכיב 'נתיב'. לא רלוונטי לא
ProxyEndpoint משמש יחד עם APIProxy לציון שם ה-ProxyEndpoint של שרת ה-proxy המיועד. לא רלוונטי לא
Path קובעת את נתיב נקודת הקצה של שרת proxy ל-API שישמש כיעד לבקשות. שרת ה-proxy ליעד חייב להיות באותו ארגון וסביבה כמו שרת ה-proxy ששולח את הבקשות. זוהי חלופה לשימוש ב-APIProxy. לא רלוונטי לא
FaultRules
מגדיר איך נקודת הקצה (TargetEndpoint) מגיבה לשגיאה. כלל כשל מציין שני פריטים:
  • תנאי שמציין את התקלה שיש לטפל בה על סמך הקטגוריה, קטגוריית המשנה או השם של התקלה שהוגדרו מראש
  • מדיניות אחת או יותר המגדירה את ההתנהגות של כלל התקלה עבור התנאי המתאים

למידע נוסף, ראו טיפול בפגמים.

לא רלוונטי לא
DefaultFaultRule

טיפול בשגיאות (מערכת, העברה, העברת הודעות או מדיניות) שלא מטופלות במפורש על ידי FaultRule אחר.

למידע נוסף, ראו טיפול בפגמים.

לא רלוונטי לא
ScriptTarget
ResourceURL

המדיניות הזו מגדירה את סוג המשאב (צומת) ואת שם הסקריפט הראשי של Node.js שמטמיע את הפונקציונליות של TargetEndpoint.

<ResourceURL>node://server.js</ResourceURL>

צריך לכלול את הסקריפט עם קובצי המשאבים של שרת ה-proxy של ה-API. ראו הוספת Node.js לשרת API קיים.

אם משתמשים ב-ScriptTarget, אין להגדיר סוגים אחרים של חיבורי יעד (HTTPTargetConnection או LocalTargetConnection).

לא רלוונטי כן
EnvironmentVariable

אפשר להעביר משתני סביבה לסקריפט הראשי של Node.js.

אפשר לקרוא את המאמר הסבר על התמיכה של Edge במודולים של Node.js.

לא רלוונטי לא
Arguments

אפשר להעביר ארגומנטים לסקריפט הראשי של Node.js.

אפשר לקרוא את המאמר הסבר על התמיכה של Edge במודולים של Node.js.

לא רלוונטי לא

הגדרת TargetEndpoint של TLS/SSL

לעיתים קרובות, TargetEndpoints צריך לנהל חיבורי HTTPS עם תשתית הטרוגנית של קצה עורפי. לכן יש תמיכה בכמה הגדרות תצורה של TLS/SSL.

רכיבי הגדרה של TLS/SSL

שם תיאור ברירת המחדל חובה?
SSLInfo
Enabled האפשרות מציינת אם TLS/SSL מופעל בנקודת הקצה. ערך ברירת המחדל הוא true אם <URL> מציין את פרוטוקול HTTPS, ו-false אם <URL> מציין HTTP. True אם <URL> מציין HTTPS לא
TrustStore מאגר מפתחות שמכיל אישורי שרת מהימנים. לא רלוונטי לא
ClientAuthEnabled הגדרה שמפעילה אימות לקוח יוצא (TLS/SSL דו-כיווני) false לא
KeyStore מאגר מפתחות שמכיל מפתחות פרטיים שמשמשים לאימות לקוחות מחוץ לארגון לא רלוונטי כן (אם הערך ClientAuthEnabled הוא True)
KeyAlias הכינוי של המפתח הפרטי שמשמש לאימות לקוח יוצא לא רלוונטי כן (אם הערך ClientAuthEnabled הוא True)
Ciphers

הצפנים נתמכים ל-TLS/SSL היוצא. אם לא צוינו צפנים, כל הצפנים שזמינים ל-JVM יהיו מורשים.

כדי להגביל את הצפנים, הוסף את הרכיבים הבאים המפרטים את הצפנים הנתמכים:

<Ciphers>
 <Cipher>TLS_RSA_WITH_3DES_EDE_CBC_SHA</Cipher>    
 <Cipher>TLS_RSA_WITH_DES_CBC_SHA</Cipher>
</Ciphers>
לא רלוונטי לא
Protocols

פרוטוקולים נתמכים להעברת TLS/SSL. אם לא צוינו פרוטוקולים, כל הפרוטוקולים הזמינים ל-JVM יהיו מותרים.

כדי להגביל פרוטוקולים, אפשר להוסיף את הרכיבים הבאים שמפרטים את הפרוטוקולים הנתמכים:

<Protocols>
 <Protocol>TLSv1.1</Protocol>
 <Protocol>TLSv1.2</Protocol>
</Protocols>
לא רלוונטי לא
CommonName

אם צוין ערך, יתבצע אימות של השם הנפוץ של אישור היעד. הערך הזה חוקי רק להגדרות של TargetEndpoint ו-TargetServer. הוא לא חוקי להגדרות של VirtualHost.

כברירת מחדל, הערך שצוין תואם בדיוק לשם הנפוץ של אישור היעד. לדוגמה, שימוש ב-*.myhost.com כערך של <CommonName> יתאים ותאמת את שם המארח של היעד רק אם הערך המדויק *.myhost.com צוין כשם הנפוץ באישור היעד.

לחלופין, Apigee יכולה לבצע את ההתאמה עם תווים כלליים באמצעות המאפיין wildcardMatch.

לדוגמה, שם נפוץ שמצוין כ-abc.myhost.com באישור היעד יותאם ויאומת אם הרכיב <CommonName> יצוין כך:

<CommonName wildcardMatch="true">*.myhost.com</CommonName>

לא רלוונטי לא

דוגמה ל-TargetEndpoint עם אימות לקוח יוצא

<TargetEndpoint name="default">
  <HttpTargetConnection>
        <URL>https://myservice.com</URL>
    <SSLInfo>
      <Enabled>true</Enabled>
      <ClientAuthEnabled>true</ClientAuthEnabled>
      <KeyStore>myKeystore</KeyStore>
      <KeyAlias>myKey</KeyAlias>
      <TrustStore>myTruststore</TrustStore>
    </SSLInfo>
  </HttpTargetConnection>
</TargetEndpoint>

להוראות מפורטות, ראה הגדרת TLS מ-Edge לקצה העורפי (ענן וענן פרטי).

שימוש במשתני זרימה כדי להגדיר ערכי TLS/SSL באופן דינמי

אפשר גם להגדיר פרטי TLS/SSL באופן דינמי לתמיכה בדרישות גמישות של סביבת זמן ריצה. לדוגמה, אם שרת ה-proxy מתחבר לשני יעדים שעשויים להיות שונים (יעד בדיקה ויעד בסביבת ייצור), אפשר להשתמש בשרת ה-proxy ל-API שיזהה באופן פרוגרמטי לאיזו סביבה הוא קורא, ולהגדיר באופן דינמי הפניות ל-Keystore ול-Truststore המתאימים. במאמר הבא בנושא קהילת Apigee מוסבר התרחיש הזה בפירוט ומספק דוגמאות לשרת API שניתן לפריסה: https://community.apigee.com/articles/21424/dynamic-sslinfo-for-targetendpoint-using-variable.html.

בדוגמה הבאה להגדרה של התג <SSLInfo> בהגדרות של TargetEndpoint, אפשר לקבל את הערכים בזמן ריצה. לדוגמה, נכס יתרונות מרכזיים של Java, מדיניות JavaScript או מדיניות של הקצאת הודעה. משתמשים במשתנים של ההודעות שמכילים את הערכים שרוצים להגדיר.

מותר להשתמש במשתנים רק ברכיבים הבאים.

<SSLInfo>
    <Enabled>{myvars.ssl.enabled}</Enabled>
    <ClientAuthEnabled>{myvars.ssl.client.auth.enabled}</ClientAuthEnabled>
    <KeyStore>{myvars.ssl.keystore}</KeyStore>
    <KeyAlias>{myvars.ssl.keyAlias}</KeyAlias>
    <TrustStore>{myvars.ssl.trustStore}</TrustStore>
</SSLInfo>

שימוש בהפניות כדי להגדיר ערכי TLS/SSL באופן דינמי

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

מידע נוסף זמין במאמר עדכון אישור TLS.

עם זאת, אפשר להגדיר את TargetEndpoint כך שישתמש במקום זאת בהפניה ל-Keystore או ל-Truststore. היתרון בשימוש בהפניה הוא שאפשר לעדכן את קובץ העזר כך שיפנה למאגר מפתחות אחר או ל-Truststore אחר כדי לעדכן את אישור ה-TLS/SSL בלי להפעיל מחדש את מעבדי ההודעות.

לדוגמה, זו דוגמה של TargetEndpoint שמשתמש בהפניה ל-Keystore:

<SSLInfo> 
    <Enabled>true</Enabled> 
    <ClientAuthEnabled>false</ClientAuthEnabled> 
    <KeyStore>ref://keystoreref</KeyStore> 
    <KeyAlias>myKeyAlias</KeyAlias> 
</SSLInfo>

משתמשים בקריאה הבאה ל-POST API כדי ליצור את קובץ העזר בשם keystoreref:

curl -X POST  -H "Content-Type:application/xml" https://api.enterprise.apigee.com/v1/o/{org_name}/e/{env_name}/references \
-d '<ResourceReference name="keystoreref">
    <Refers>myTestKeystore</Refers>
    <ResourceType>KeyStore</ResourceType>
</ResourceReference>' -u email:password

בהפניה מציינים את השם של מאגר המפתחות ואת הסוג שלו.

כדי להציג את קובץ העזר, משתמשים בקריאה הבאה ל-API של GET:

curl -X GET https://api.enterprise.apigee.com/v1/o/[org_name}/e/{env_name}/references/keystoreref -u uname:password

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

curl -X PUT -H "Content-Type:application/xml" https://api.enterprise.apigee.com/v1/o/{org_name}/e/{env_name}/references/keystoreref \
-d '<ResourceReference name="keystoreref">
    <Refers>myNewKeystore</Refers>
    <ResourceType>KeyStore</ResourceType>
</ResourceReference>' -u email:password

TargetEndpoint עם איזון עומסים ביעד

TargetEndpoints תומך באיזון עומסים במספר שרתי TargetServers בעלי שם, באמצעות שלושה אלגוריתמים של איזון עומסים.

להוראות מפורטות, ראו איזון עומסים בין שרתים עורפיים.

כללי המדיניות

הספרייה /policies בשרת proxy ל-API מכילה את כל כללי המדיניות שזמינים לצירוף אל 'זרימות' בשרת ה-API של ה-API.

רכיבי הגדרת המדיניות

שם תיאור ברירת המחדל חובה?
Policy
name

השם הפנימי של המדיניות. התווים שאפשר להשתמש בהם בשם מוגבלים ל-A-Za-z0-9._\-$ %. עם זאת, ממשק המשתמש לניהול Edge אוכף הגבלות נוספות, כמו הסרה אוטומטית של תווים שהם לא אלפאנומריים.

אפשר להשתמש באלמנט <DisplayName> כדי להוסיף תווית למדיניות בעורך ה-proxy לניהול ממשק המשתמש, עם שם אחר בשפה טבעית.

לא רלוונטי כן
enabled

צריך להגדיר את הערך true כדי לאכוף את המדיניות.

צריך להגדיר את הערך false כדי "להשבית" את המדיניות. המדיניות לא תיאכף גם אם היא תישאר מצורפת לתהליך.

true לא
continueOnError

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

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

false לא
async

הערה: המאפיין הזה לא מפעיל את המדיניות באופן אסינכרוני. ברוב המקרים, משאירים את האפשרות הזו עם ברירת המחדל false.

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

כדי להשתמש בהתנהגות אסינכרונית בשרתי proxy של API, קראו את המאמר מודל אובייקט של JavaScript.

false לא

קובץ מצורף למדיניות

התמונה הבאה מציגה את רצף הביצוע של תהליכי ה-proxy ל-API:

מראה לקוח שמתקשר לשירות HTTP. הבקשה מקבלת את
  ProxyEndpoint ו-TargetEndpoint, וכל אחד מהם מכיל שלבים שמפעילים את המדיניות. אחרי
  
  ששירות ה-HTTP מחזיר את התגובה, התגובה תעובד על ידי TargetEndpoint ולאחר מכן ה-ProxyEndpoing לפני שתוחזר ללקוח. בדומה לבקשה, התשובה מעובדת
  בהתאם לכללי המדיניות שמפורטים לפי השלבים.

כפי שמוצג למעלה:

כללי המדיניות מצורפת כשלבי עיבוד לדף זרימה. שם המדיניות משמש להפניה למדיניות לאכיפה כשלב בעיבוד. הפורמט של קובץ מדיניות מצורף הוא:

<Step><Name>MyPolicy</Name></Step>

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

<Step><Name>FirstPolicy</Name></Step>
<Step><Name>SecondPolicy</Name></Step>

רכיבי תצורה של קבצים מצורפים למדיניות

שם תיאור ברירת המחדל חובה?
Step
Name שם המדיניות שתבוצע לפי הגדרת השלב הזו. לא רלוונטי כן
Condition הצהרה מותנית שקובעת אם המדיניות נאכפת. אם למדיניות משויך תנאי, המדיניות תבוצע רק אם ההצהרה המותנית יקבלו את הערך True. לא רלוונטי לא

זרימות

ProxyEndpoint ו-TargetEndpoint מגדירים צינור עיבוד נתונים לעיבוד בקשות והודעות תשובה. צינור עיבוד נתונים כולל זרימת בקשות וזרימת תגובה. כל זרימת בקשה ותהליך תגובה מחולקים ל-PreFlow, לתהליך אופציונלי אחד או יותר מסוג 'מותנה' או 'עם שם', ו-PostFlow.

  • PreFlow: מבצעת תמיד. מופעל לפני זרימות מותנות.
  • PostFlow: מבצע תמיד. מופעלת אחרי זרימות מותנות.

בנוסף, אפשר להוסיף PostClientFlow ל-ProxyEndpoint, שיופעל לאחר שהתגובה מוחזרת לאפליקציית הלקוח המבקשת. לתהליך הזה ניתן לצרף רק את המדיניות MessageLogging ואת Google Stackdriver Logging Extension. PostClientFlow מפחית את זמן האחזור של שרת ה-proxy ל-API ומאפשר רישום ביומן. מידע שלא מחושב עד אחרי שהתגובה מוחזרת ללקוח, למשל client.sent.start.timestamp ו-client.sent.end.timestamp. התהליך משמש בעיקר למדידת מרווח הזמן בין חותמות הזמן של ההתחלה והסיום של הודעת התגובה.

לצפייה בסרטון הדרכה קצר

סרטון: אפשר לצפות בסרטון הקצר הזה על השימוש ברישום הודעות ב-PostClientFlow.

הנה דוגמה ל-PostClientFlow שמצורפת מדיניות לרישום הודעות.

    ...
    <PostFlow name="PostFlow">
        <Request/>
        <Response/>
    </PostFlow>
    <PostClientFlow>
        <Request/>
        <Response>
            <Step>
                <Name>Message-Logging-1</Name>
            </Step>
        </Response>
    </PostClientFlow>
    ...

צינור עיבוד הנתונים של proxy ל-API מפעיל את הזרימות ברצף הבא:

צינור עיבוד נתונים של בקשה:

  1. זרימה מראש של בקשת שרת proxy
  2. זרימות מותנות של בקשת שרת proxy (אופציונלי)
  3. בקשת Proxy לאחר זרימה
  4. זרימה מראש של בקשת יעד
  5. זרימות מותנות של בקשות יעד (אופציונלי)
  6. PostFlow של בקשת יעד

צינור עיבוד נתונים למענה:

  1. זרימה מראש של יעד התגובה
  2. זרימות מותנות של תגובת יעד (אופציונלי)
  3. PostFlow של יעד תגובת יעד
  4. זרימה מראש של תגובת שרת proxy
  5. זרימות מותנות לתגובת שרת proxy (אופציונלי)
  6. PostFlow של תגובת שרת proxy
  7. תגובת PostClientFlow (אופציונלי)

צריך להגדיר רק את הזרימות עם הקבצים המצורפים למדיניות בהגדרות ProxyEndpoint או TargetEndpoint. יש לציין את הפרמטרים PreFlow ו-PostFlow רק בהגדרות של ProxyEndpoint או TargetEndpoint, כאשר יש לאכוף מדיניות במהלך עיבוד PreFlow או PostFlow.

בניגוד לתהליכי עבודה מותנים, הסדר של רכיבי PreFlow ו-PostFlow אינו חשוב - שרת ה-proxy ל-API תמיד יבצע כל אחד מהם בנקודה המתאימה בצינור עיבוד הנתונים, ללא קשר למיקום שבו הם מופיעים בתצורת נקודת הקצה.

זרימות מותנות

ProxyEndpoints ו-TargetEndpoints תומכים במספר בלתי מוגבל של תהליכי עבודה מותנים (שנקראים גם 'זרימות בעלות שם').

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

כשמגדירים תהליכי עבודה מותנים, אפשר להחיל שלבי עיבוד בשרת proxy ל-API על סמך:

  • URI של בקשה
  • פועל HTTP (GET/PUT/POST/DELETE)
  • ערך של פרמטר, כותרת ופרמטר טופס של שאילתה
  • סוגים רבים אחרים של תנאים

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

<Flows>
  <Flow name="TokenEndpoint">
    <Condition>proxy.pathsuffix MatchesPath "/accesstoken"</Condition>
    <Request>
      <Step>
        <Name>GenerateAccessToken</Name>
      </Step>
    </Request> 
  </Flow>
</Flows>   

רכיבים להגדרת זרימה

שם תיאור ברירת המחדל חובה?
Flow צינור עיבוד בקשה או תגובה מוגדר על ידי ProxyEndpoint או TargetEndpoint
Name השם הייחודי של הזרימה. לא רלוונטי כן
Condition הצהרת תנאי שבודקת בה משתנים או יותר כדי שהערך שלהם יהיה TRUE או FALSE. בכל תהליכי העבודה, מלבד הסוגים PreFlow ו-PostFlow המוגדרים מראש, יש להגדיר תנאי לביצוע. לא רלוונטי כן
Request צינור עיבוד הנתונים המשויך לבקשות עיבוד הודעות לא רלוונטי לא
Response צינור עיבוד הנתונים המשויך לעיבוד הודעות התשובה לא רלוונטי לא

עיבוד השלבים

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

לדוגמה, בהגדרה הבאה של הזרימה, כל בקשה נכנסת שלא כוללת את סיומת הנתיב /first או /second תגרום להפעלה של ThirdFlow, והמדיניות הזו אוכפת את המדיניות Return404.

<Flows>
  <Flow name="FirstFlow">
    <Condition>proxy.pathsuffix MatchesPath "/first"</Condition>
    <Request>
      <Step><Name>FirstPolicy</Name></Step>
    </Request>
  </Flow>
  <Flow name="SecondFlow">
    <Condition>proxy.pathsuffix MatchesPath "/second"</Condition>
    <Request>
      <Step><Name>FirstPolicy</Name></Step>
      <Step><Name>SecondPolicy</Name></Step>
    </Request>
  </Flow>
  <Flow name="ThirdFlow">
    <Request>
      <Step><Name>Return404</Name></Step>
    </Request>
  </Flow>
</Flows>

משאבים

'משאבים' (קובצי משאבים לשימוש בשרתי proxy ל-API) הם סקריפטים, קוד וטרנספורמציות XSL שאפשר לצרף לזרימות באמצעות מדיניות. הם מופיעים בקטע 'סקריפטים' של עורך ה-proxy ל-API בממשק המשתמש של הניהול.

במאמר קובצי משאבים מפורטים סוגי המשאבים הנתמכים.

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

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