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

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

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

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. (בתצוגה שרת proxy, בוחרים באפשרות Project > Upload a New Edition).

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

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

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

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

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

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

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

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

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

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

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

• הגדרה בסיסית
• ProxyEndpoint
• TargetEndpoint
  • תצורת נקודת קצה (endpoint) של TLS/SSL
• כללי המדיניות
• פרחים
• מקורות מידע

הגדרה בסיסית

/apiproxy/weatherapi.xml

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

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

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

אלמנטים של הגדרה בסיסית

נקודת קצה של שרת 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

הגדרת RouteRules

נקודת קצה (endpoint) בשם היא קובץ תצורה תחת /apiproxy/targets שאליו ה-RouteRule מעביר בקשה לאחר עיבוד על ידי שרת ה-proxy.

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

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

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

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

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

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

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

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

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

לדוגמה, השילוב הבא של RouteRule מעריך את הבקשה הנכנסת כדי לאמת את הערך של כותרת HTTP. אם הערך של כותרת ה-HTTP routeTo הוא TargetEndpoint1, הבקשה תועבר לנקודת היעד (endpoint) ששמה 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

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

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

<RouteRule name="GoNowhere"/>

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

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

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

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

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

נקודת קצה (endpoint)

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

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

הגדרות אישיות של נקודת היעד

/targets/default.xml

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

הנה דוגמה להגדרה של יעד EndEnd:

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

רכיבים של תצורת נקודת קצה (endpoint)

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

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

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

תצורת נקודת יעד של TLS/SSL

לרוב, TargetEndpoints צריך לנהל חיבורי 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>

יעד סופי לדוגמה עם אימות של לקוח יוצא

<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 וענן פרטי).

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

ניתן גם להגדיר פרטי TLS/SSL באופן דינמי כדי לתמוך בדרישות זמן ריצה גמישות. לדוגמה, אם שרת ה-proxy מתחבר לשני יעדים שעשויים להיות שונים (יעד בדיקה ויעד ייצור), אפשר להגדיר את שרת ה-API של Google פרוגרמטי לזהות לאיזו סביבה הוא מתקשר ולהגדיר באופן דינמי הפניות למאגר המפתחות ולמאגר האמון המתאים. המאמר הבא של קהילת Apigee מסביר את התרחיש הזה בפירוט רב יותר ומספק דוגמאות של שרת proxy ל-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 באופן דינמי

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

למידע נוסף, קראו את המאמר עדכון אישור TLS.

עם זאת, אפשר להגדיר את נקודת הקצה (endpoint) לשימוש בהפניה למאגר המפתחות או ל-Truststore. היתרון בשימוש בקובץ עזר הוא שאתם יכולים לעדכן את קובץ העזר כך שיפנה למאגר מפתחות אחר או ל-Trust Store, כדי לעדכן את אישור ה-TLS/SSL בלי שתצטרכו להפעיל מחדש את מעבדי ההודעות.

לדוגמה, בהמשך מוצגת נקודת קצה (endpoint) שמשתמשת בהפניה למאגר המפתחות:

<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

קובץ העזר מציין את שם מאגר המפתחות ואת סוגו.

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

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 תומך באיזון עומסים בין שרתי שמות עם שמות מרובים, באמצעות שלושה אלגוריתמים לאיזון עומסים.

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

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

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

אלמנטים של הגדרת מדיניות

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

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

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

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

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

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

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

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

פרחים

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

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

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

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

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

צינור עיבוד תגובה:

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

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

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

זרימה מותנית

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

שרת ה-proxy של ה-API בודק את התנאי שצוין בתהליך המותנה, ואם התנאי מתקיים, שלבי העיבוד בזרימה המותנית מבוצעים על ידי שרת ה-API של ה-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>   

אלמנטים של הגדרת זרימה

עיבוד שלבים

הסדר הרגולרי של זרימה מותנית נאכף על ידי 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) הם סקריפטים, קוד וטרנספורמציות של XSL שאפשר לצרף לזרימות נתונים באמצעות מדיניות. הנכסים האלה מופיעים בקטע "Scripts" בעורך ה-API של ה-API בממשק המשתמש לניהול.

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

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

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