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

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

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

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

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

• שימוש בכלי לעריכת XML בממשק המשתמש של Edge
• מורידים את ההגדרה ועורכים אותה באופן מקומי, כמו שמתואר במאמר בנושא פיתוח מקומי של הגדרות שרת proxy.

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

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

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

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

1. מורידים את הגדרות ה-proxy הנוכחיות בממשק המשתמש של Edge. (בתצוגה API Proxies (שרתי proxy של API), בוחרים באפשרות 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 proxy, עורכים את קובץ ההגדרות של TargetEndpoint בספרייה /apiproxy/targets/. קובץ ברירת המחדל בספרייה הזו הוא default.xml, אבל יכול להיות שיש קבצים עם שמות שונים אם משתמשים ביעדים מותנים.

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

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

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

   cd myappdir

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

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

   zip my-new-proxy.zip -r .

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

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

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

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

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

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

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

8. פורסים את הגרסה החדשה.

מידע נוסף זמין במאמר Tutorial: How to download a proxy using the UI and the management API בקהילת Apigee.

המבנה של proxy ל-API

פרוקסי של API מורכב מההגדרות הבאות:

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

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

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

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

• הגדרת הבסיס
• ProxyEndpoint
• TargetEndpoint
  • הגדרה של TargetEndpoint ל-TLS/SSL
• המדיניות
• תהליכי עבודה
• מקורות מידע

הגדרה בסיסית

/apiproxy/weatherapi.xml

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

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

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

רכיבי הגדרה בסיסיים

ProxyEndpoint

בתמונה הבאה מוצג תהליך הבקשה והתגובה:

/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 Configuration Elements

איך מגדירים RouteRules

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

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

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

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

בנוסף, ProxyEndpoint יכול להפעיל ישירות שירות backend. הפעלה ישירה של כתובת 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>

מסלולים מותנים

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

כללי RouteRule מותנים פועלים כמו הצהרות מותנות אחרות ב-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>

מסלולי Null

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

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

<RouteRule name="GoNowhere"/>

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

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

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

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

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

TargetEndpoint

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

ל-API proxy לא חייבים להיות TargetEndpoints. אפשר להגדיר ProxyEndpoints כדי לקרוא לכתובות URL ישירות. שרת proxy של API ללא TargetEndpoints בדרך כלל מכיל ProxyEndpoint שקורא ישירות לשירות backend, או שמוגדר לקרוא לשירות באמצעות 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 רכיבים

נקודת קצה של יעד יכולה להתקשר ליעד באחת מהדרכים הבאות:

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

אפשר להגדיר רק אחד מהם ב-TargetEndpoint.

הגדרה של TargetEndpoint ל-TLS/SSL

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

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

<Ciphers>
 <Cipher>TLS_RSA_WITH_3DES_EDE_CBC_SHA</Cipher>
 <Cipher>TLS_RSA_WITH_DES_CBC_SHA</Cipher>
</Ciphers>

<Protocols>
 <Protocol>TLSv1.1</Protocol>
 <Protocol>TLSv1.2</Protocol>
</Protocols>

<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 מקצה העורף אל העורף (Cloud ו-Private Cloud).

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

אפשר גם להגדיר באופן דינמי פרטים של TLS/SSL כדי לתמוך בדרישות גמישות של זמן ריצה. לדוגמה, אם ה-proxy מתחבר לשני יעדים שונים פוטנציאלית (יעד בדיקה ויעד ייצור), אפשר להגדיר את ה-API proxy כך שיזהה באופן פרוגרמטי את הסביבה שהוא קורא לה ויגדיר באופן דינמי הפניות למאגר המפתחות ולמאגר האישורים המתאימים. במאמר הבא בקהילת Apigee מוסבר התרחיש הזה בפירוט, ומוצגות דוגמאות לפרוקסי של API שאפשר לפרוס: Dynamic SSLInfo for TargetEndpoint using variable reference (מידע דינמי על SSL עבור TargetEndpoint באמצעות הפניה למשתנה).

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

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

<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 באופן דינמי

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

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

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

לדוגמה, בהמשך מוצג TargetEndpoint שמשתמש בהפניה למאגר המפתחות:

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

משתמשים בקריאה הבאה ל-API מסוג POST כדי ליצור את ההפניה בשם 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 מכילה את כל כללי המדיניות שאפשר לצרף ל-Flows בשרת ה-proxy של API.

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

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

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

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

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

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

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

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

Policy Attachment Configuration Elements

Flows

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

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

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

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

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

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

צינור העיבוד של API Proxy מבצע את התהליכים ברצף הבא:

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

1. Proxy Request PreFlow
2. תהליכי עבודה מותנים של בקשות משרת proxy (אופציונלי)
3. Proxy Request PostFlow
4. Target Request PreFlow
5. תהליכי בקשה מותנים לטירגוט (אופציונלי)
6. Target Request PostFlow

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

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

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

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

Conditional Flows

רכיבי ProxyEndpoint ו-TargetEndpoint תומכים במספר בלתי מוגבל של זרימות מותנות (שנקראות גם 'זרימות עם שם').

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

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

• ‫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>

רכיבים של הגדרת תהליך

עיבוד שלבים

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

לדוגמה, בהגדרת ה-Flow הבאה, כל בקשה נכנסת שלא כוללת את סיומת הנתיב /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 שאפשר לצרף ל-Flows באמצעות מדיניות. הם מופיעים בקטע Scripts (סקריפטים) בכלי לעריכת proxy של API בממשק המשתמש לניהול.

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

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

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