הפניית תצורה של שרת 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 בבקרת המקור, בניהול הגרסאות ובתהליכי עבודה משותפים אחרים. בנוסף, כשעובדים על הגדרת שרת proxy באופן מקומי, אפשר להשתמש בכלי אימות ובכלי עריכה של XML משלכם.

בקטע הזה מוסבר איך להשתמש בממשק המשתמש כדי להוריד הגדרת proxy קיימת, לערוך אותה ואז להעלות אותה בחזרה ל-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.

   לדוגמה, כדי להפעיל מעקב אחר תקינות ב-proxy ל-API, עורכים את קובץ התצורה של 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

proxy ל-API מורכב מההגדרות הבאות:

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

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

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

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

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

הגדרה בסיסית

/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. הפעלה ישירה של כתובת 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 מותנה יכול להיות לתמיכה בשמירה במטמון. באמצעות הערך של המשתנה שמוגדר על ידי מדיניות המטמון, אפשר להגדיר proxy ל-API שיבצע את המסלול null כשערך מוגש מהמטמון.

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

TargetEndpoint

‫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 רכיבים

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

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

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

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

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

TLS/SSL TargetEndpoint Configuration Elements

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

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

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

בדוגמה הבאה להגדרת התג <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.

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

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

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

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

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

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

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

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

הגדרת מדיניות לצירוף רכיבים

Flows

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

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

בנוסף, אפשר להוסיף PostClientFlow ל-ProxyEndpoint, שמופעל אחרי שהתשובה מוחזרת לאפליקציית הלקוח ששלחה את הבקשה. אפשר לצרף ל-PostClientFlow רק את המדיניות MessageLogging ואת התוסף Google Stackdriver Logging. השימוש ב-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>
    ...

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

צינור בקשות:

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 רק את רכיבי Flow שיש להם קבצים מצורפים של מדיניות. צריך לציין 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>

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

עיבוד שלבים

הסדר הרציף של 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 בממשק המשתמש לניהול.

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

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

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