הפניה להגדרת 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 משלכם.

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

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

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

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

לפרוקסי של 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 לשרת proxy
• ‫ScriptTarget לקריאות לסקריפט Node.js שמתארח ב-Edge

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

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

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

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

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

צירוף מדיניות

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

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

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

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

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

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

Policy Attachment Configuration Elements

תהליכים

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

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

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

צינור העיבוד של 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 רק את רכיבי Flows עם קבצים מצורפים של מדיניות. צריך לציין את PreFlow ו-PostFlow רק בתצורת ProxyEndpoint או TargetEndpoint כשצריך לאכוף מדיניות במהלך העיבוד של PreFlow או PostFlow.

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

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

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

בבדיקות של שרת 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 (סקריפטים) בכלי לעריכת פרוקסי של API בממשק המשתמש לניהול.

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

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

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