יצירת תהליכים משותפים לשימוש חוזר

הדף הזה רלוונטי ל-Apigee ול-Apigee Hybrid.

לעיון במסמכי התיעוד של Apigee Edge

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

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

בסרטון הבא אנחנו מדגימים איך ליצור ולנפות באגים בזרימת נתונים משותפת בממשק המשתמש של Apigee.

אפשר לקרוא לזרימה משותפת באמצעות מדיניות FlowCallout. בנוסף, אפשר לצרף זרימה משותפת לנקודת חיבור של זרימה כדי שהזרימה המשותפת תופעל לפני בקשת proxy או בקשת יעד, או אחרי תגובת proxy או תגובת יעד.

לעיון במדיניות FlowCallout, אפשר לעבור אל מדיניות FlowCallout. מידע נוסף על נקודות חיבור לזרימת נתונים זמין במאמר צירוף זרימת נתונים משותפת באמצעות נקודת חיבור לזרימת נתונים.

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

  • אבטחה, עם קוד הרשאה באמצעות OAuth ואימות מפתח API, וגם קוד להגנה מפני איומים.
  • רישום ביומן, ליצירת הודעות שגיאה סטנדרטיות.
  • גישור, להמרה בין פורמטים של הודעות XML ו-JSON.

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

תרשים זרימה שמראה את מדיניות POST /foodcarts למדיניות POST /menus ל-AuthSharedFlow. טקסט ההסבר: א) כמה פרוקסי של API צורכים זרימה משותפת באמצעות FlowCallouts. ב) מדיניות FlowCallout מבצעת קריאות מפרוקסי של API לזרימה משותפת. ג) חבילת הזרימה המשותפת מכילה לוגיקה לשימוש חוזר כמדיניות וכמשאבים.

פיתוח תהליך עבודה משותף

כשמפתחים זרימת נתונים משותפת, תמיד צריך לבדוק אותה באמצעות קריאות שנשלחות ל-proxy ל-API. In other words, you can't send requests directly to a shared flow as you would an API proxy. במקום זאת, שולחים בקשות ל-proxy ל-API, שבתורו קורא ל-shared flow.

אלה השלבים הכלליים לפיתוח של רכיב Shared Flow:

  1. מגדירים מה יהיה הסט המשותף של התכונות.

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

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

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

    לדוגמה, במסגרת התמיכה בניהול התנועה, אפשר להטמיע מדיניות של Spike Arrest כדי לאפשר רק 30 בקשות בשנייה, כמו בדוגמה הבאה:

    <SpikeArrest async="false" continueOnError="false" enabled="true" name="Spike-Arrest">
    <DisplayName>Spike Arrest</DisplayName>
    <Properties/>
    <Identifier ref="request.header.some-header-name"/>
    <MessageWeight ref="request.header.weight"/>
    <Rate>30ps</Rate>
</SpikeArrest>

    לאחר מכן, אפשר לצרף את מדיניות Spike Arrest כשלב לזרימה משותפת לניהול תעבורה. המדיניות תופעל עבור כל proxy ל-API שמבצע קריאה לזרימה המשותפת.

    <SharedFlow name="default">
    <Step>
        <Name>Spike-Arrest</Name>
    </Step>
</SharedFlow>

    מידע על הפעלת זרימה משותפת במסוף הניהול זמין במאמר בנושא יצירת זרימה משותפת בממשק המשתמש של Apigee.

    בדומה לשרתי proxy ל-API, אפשר לייבא קובץ zip שמכיל את מקור רכיבי התהליך המשותף באמצעות Create shared flow API. האיור הבא מראה איך לייבא תהליך משותף באמצעות Apigee API:

    curl "https://apigee.googleapis.com/v1/organizations/$ORG/sharedflows?action=import&name=mySharedFlow" \
  -X POST \
  -F "file=@sharedflow.zip" \
  -H "Authorization: Bearer $TOKEN"

    ‫$TOKEN מוגדר כאסימון הגישה מסוג OAuth 2.0, כפי שמתואר במאמר איך מקבלים אסימון גישה מסוג OAuth 2.0. מידע על האפשרויות curl שבהן נעשה שימוש בדוגמה הזו מופיע במאמר שימוש ב-curl. תיאור של משתני הסביבה שבהם אפשר להשתמש מופיע במאמר בנושא הגדרת משתני סביבה לבקשות API של Apigee.

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

    רכיב Shared Flow צריך להיות באותו ארגון ולהיפרס באותה סביבה כמו שרתי ה-proxy של ה-API ורכיבי Shared Flow אחרים שמשתמשים בו. פריסת הזרימה המשותפת לפני שרתי ה-proxy מאפשרת לפתור את התלות של ה-proxy בזרימה המשותפת בזמן הפריסה.

    אפשר לפרוס זרימה משותפת באמצעות קריאה ל-API של Apigee, כמו הקריאה הבאה:

    curl https://apigee.googleapis.com/v1/organizations/$ORG/environments/$ENV/sharedflows/$SHAREDFLOW/revisions/$REV/deployments \
  -X POST \
  -H "Authorization: Bearer $TOKEN"

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

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

    מ-proxy ל-API, קוראים ל-shared flow באמצעות מדיניות FlowCallout. (אפשר גם לצרף את ה-Flow המשותף ל-Proxy באמצעות flow hook).

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

    בדוגמת הקוד הבאה, מדיניות FlowCallout קוראת לזרימה משותפת בשם traffic-management-shared.

    <FlowCallout async="false" continueOnError="false" enabled="true" name="Traffic-Management-Flow-Callout">
    <DisplayName>Traffic Management FlowCallout</DisplayName>
    <Properties/>
    <SharedFlowBundle>traffic-management-shared</SharedFlowBundle>
</FlowCallout>

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

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

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

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

    1. בכרטיסייה Debug (ניפוי באגים) של ה-proxy ל-API, מתחילים בניפוי הבאגים של ה-proxy ל-API.
    2. שליחת בקשה לנקודת קצה של שרת proxy ב-API proxy. התהליך מנקודת הקצה צריך לכלול את מדיניות FlowCallout שקוראת לתהליך המשותף.
    3. בכרטיסייה Debug, בודקים את התהליך מ-proxy ל-API לזרימה משותפת. (מידע נוסף על ניפוי באגים זמין במאמר בנושא כלי לניפוי באגים).

יצירת תהליך משותף בממשק המשתמש של Apigee

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

ניגשים לדף Shared Flows (תזרימי נתונים משותפים), כמו שמתואר בהמשך. בדף Shared Flows, תוכלו לראות רשימה של זרימות משותפות בארגון, ולערוך או למחוק זרימות מהרשימה.

כדי ליצור תהליך משותף בממשק המשתמש של Apigee:

  1. במסוף Google Cloud , נכנסים לדף Apigee > Proxy development > Shared flows.

    מעבר לתהליכי עבודה משותפים

  2. בוחרים את הארגון שמכיל את התהליך המשותף. מידע נוסף זמין במאמר בנושא מעבר בין הארגונים שלכם.

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

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

      מוצגת תיבת הדו-שיח Create a Shared Flow (יצירת רכיב Shared Flow).

      1. מזינים את השם של התהליך המשותף.

        זה יהיה השם ששרתי proxy ל-API ורכיבים משותפים אחרים ישתמשו בו כדי להפנות לרכיב המשותף הזה. השם צריך להיות תיאורי כדי שמפתחים יוכלו להשתמש ברכיב.

      2. מזינים תיאור כדי לספק מידע נוסף על הפעולות שמתבצעות בתהליך.
      3. אם הפעלתם את Apigee Spaces בארגון, תוכלו לשייך את הרכיב המשותף למרחב שנבחר מתוך רשימת האפשרויות הזמינות. מידע נוסף זמין במאמר סקירה כללית של Apigee Spaces.
      4. לוחצים על יצירה.

        הזרימה המשותפת נוצרת.

      5. לאחר מכן, אפשר לפתח את התכונות של התהליך המשותף ולפרוס אותו בסביבה הרצויה.
    • לוחצים על העלאת חבילה כדי ליצור זרימה משותפת ממקורות קיימים על ידי העלאת חבילת זרימה.

      חבילה של תהליך עבודה משותף מכילה את פריטי המקור של תהליך עבודה משותף. לדוגמה, אם תורידו זרימת נתונים משותפת ממסוף Apigee, תקבלו קובץ zip עם חבילת זרימת הנתונים.

      מוצגת תיבת הדו-שיח Create a Shared Flow (יצירת רכיב Shared Flow).

      1. בוחרים את קובץ ה-ZIP שמכיל את הארטיפקטים שרוצים להוסיף לזרימה החדשה.
      2. לוחצים על פתיחה.
      3. מזינים שם לזרימת הנתונים המשותפת שיובאה.

        זה יהיה השם ששרתי proxy ל-API וזרימות משותפות אחרות ישתמשו בו כדי להפנות לזרימה המשותפת הזו. השם צריך להיות תיאורי כדי שמפתחים יוכלו להשתמש בזרימה.

      4. לוחצים על יצירה.

        הזרימה המשותפת נוצרת מהחבילה.

      5. לאחר מכן, אפשר לפתח את התכונות של התהליך המשותף ולפרוס אותו בסביבה הרצויה.

קריאה ל-Shared Flow מ-proxy ל-API או מ-Shared Flow

אפשר לקרוא לרכיב Flow משותף מ-Proxy או מרכיב Flow משותף אחר באמצעות מדיניות FlowCallout.

  1. מבצעים אחת מהפעולות הבאות:
  2. לוחצים על השם של ה-proxy או של התהליך המשותף שרוצים לשנות.
  3. לוחצים על הכרטיסייה פיתוח.
  4. בחלונית הניווט, לצד Policies (מדיניות), לוחצים על .
  5. ברשימת כללי המדיניות, בקטע Extension, בוחרים באפשרות FlowCallout.
  6. מזינים את השם המוצג ואת השם (מזהה ייחודי), ואז בוחרים את התהליך המשותף שהמדיניות הזו תקרא לו.
  7. לוחצים על יצירה.
  8. לוחצים על לצד שמירה ואז על שמירת הגרסה החדשה.

מידע נוסף

שרשור של שרתי proxy ל-API