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

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

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

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

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

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

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

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

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

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

1. מורידים את ההגדרה הנוכחית של שרת ה-proxy בממשק המשתמש של Edge. (בשרתי ה-proxy ל-API בתצוגה, בוחרים באפשרות Project > להורדת הגרסה)
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. (בשרתי proxy ל-API בתצוגה, בוחרים באפשרות Project > מעלים גרסה חדשה).

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

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

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

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

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

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

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

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

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

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

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

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

הגדרה בסיסית

/apiproxy/weatherapi.xml

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

הגדרות אישיות לדוגמה:

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

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

ProxyEndpoint

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

/apiproxy/proxies/default.xml

הגדרת ProxyEndpoint מגדירה את הממשק הנכנס (ללקוח) ל-API שרת proxy. כשמגדירים 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 בסיסית הם:

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

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

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

TargetEndpoint

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

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

הגדרה של נקודת קצה (endpoint) יעד

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

הגדרה של נקודת קצה (Target Endpoint) Elements

נקודת קצה (TargetEnd) יכולה להפעיל יעד באחת מהדרכים הבאות:

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

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

הגדרה של נקודת קצה (endpoint) של יעד TLS/SSL

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

TLS/SSL רכיבי ההגדרה של נקודת קצה (Target Endpoint)

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

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

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

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

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

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

תוכלו להשתמש בקריאה הבאה ל-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) תומכות באיזון עומסים במספר שרתי targetServer בעלי שם באמצעות שלושה עומסים אלגוריתמים של איזון.

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

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

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

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

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

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

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

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

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

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

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

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

זרימה

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

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

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

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

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

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

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

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

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

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

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

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

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

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

מידע נוסף זמין במאמר קובצי משאבים בסוגי המשאבים.

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

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