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

אתם צופים במסמכי התיעוד של Apigee Edge.
כדאי לעיין במסמכי התיעוד של Apigee X. מידע

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

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

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

בסרטון הבא (5 דקות) מוצגות הוראות ליצירה ולמעקב של תהליך משותף בממשק המשתמש החדש של Edge (Edge ל-Private Cloud בלבד).

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

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

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

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

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

פיתוח תהליך משותף

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

אלה השלבים הכלליים לפיתוח של זרימת נתונים משותפת:

  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>

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

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

    curl -X POST -F "file=@/path/to/zip/file.zip" \ 'https://api.enterprise.apigee.com/v1/o/{org_name}/sharedflows?action=import&name=shared-flow-name' \
-u email:password
  3. פורסים את התהליך המשותף בסביבה לפני שפורסים שרתי proxy או תהליכים משותפים שישתמשו בו. פריסת תהליך משותף מתבצעת באותו אופן שבו פורסים proxy ל-API. (מידע נוסף מופיע במאמר סקירה כללית על פריסה).

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

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

    curl -X POST --header "Content-Type: application/octet-stream" \
https://api.enterprise.apigee.com/v1/o/{org_name}/e/{env_name}/sharedflows/{shared_flow_name}/revisions/{revision_number}/deployments \
-u email:password

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

    curl -X POST --header "Content-Type:application/x-www-form-urlencoded" \
https://api.enterprise.apigee.com/v1/o/{org_name}/e/{env_name}/sharedflows/{shared_flow_name}/revisions/{revision_number}/deployments?"override=true" \
-u email:password
  4. מפתחים את ה-proxy ל-API שמשתמש בתהליך המשותף כדי שיוכל לקרוא לתהליך המשותף כחלק מהתהליך שלו.

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

    כדי להשתמש בתהליך משותף, מוסיפים מדיניות FlowCallout ל-proxy או לתהליך המשותף שבו רוצים להשתמש. בדומה למדיניות Service Callout שמאפשרת לקרוא לשירות אחר, מדיניות FlowCallout מאפשרת לקרוא ל-תהליך משותף. צריך לפרוס את ה-proxy ל-API שמשתמש בתהליך המשותף אחרי התהליך המשותף, ובאותה סביבה שבה פרוס התהליך המשותף. ה-Flow המשותף צריך להיות במקום כשרוצים לבדוק קריאה אליו באמצעות מדיניות 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 ולעקוב אחרי השרת.

    אלה השלבים:

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

      שימו לב שבמעקב, התהליך המשותף מיוצג כקבוצה של שלבים או כללי מדיניות שמוקפים בתיבה אפורה. סמלים שמייצגים מדיניות FlowCallout מופיעים לפני תהליכי עבודה משותפים. (מידע נוסף על מעקב זמין במאמר בנושא שימוש בכלי Trace).

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

כשמשתמשים בממשק המשתמש של Apigee Edge כדי ליצור זרימת נתונים משותפת, אפשר ליצור אותה מאפס או לייבא מקורות קיימים של זרימת נתונים כקובץ zip של חבילת זרימת נתונים.

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

    Edge

    כדי לגשת לדף 'רצפי פעולות משותפים' באמצעות ממשק המשתמש של Edge:

    1. נכנסים לכתובת apigee.com/edge.
    2. בוחרים את הארגון שמכיל את התהליך המשותף. איך עוברים בין הארגונים

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

    3. בסרגל הניווט הימני, בוחרים באפשרות פיתוח > תהליכים משותפים.

    ממשק משתמש חדש של Edge (ענן פרטי)

    כדי לגשת לדף 'תהליכים משותפים' באמצעות ממשק המשתמש החדש של Edge:

    1. נכנסים לממשק המשתמש החדש של Edge בכתובת http://host:3001/edge, כאשר host היא כתובת ה-IP או שם ה-DNS של המארח שבו פועל ממשק המשתמש החדש של Edge.
    2. בוחרים את הארגון שמכיל את התהליך המשותף. איך עוברים בין הארגונים

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

    3. בסרגל הניווט הימני, בוחרים באפשרות פיתוח > תהליכים משותפים.
  2. לוחצים על הלחצן + Shared Flow כדי להתחיל להוסיף זרימת נתונים משותפת חדשה.
  3. בדף Build a Shared Flow (יצירת רכיב Shared Flow), בוחרים איך ליצור את הרכיב החדש:
    • ליצור תהליך חדש מאפס. תוכלו להגדיר מדיניות ומשאבים כשלבים בתהליך.
      1. לוחצים על Empty Shared Flow (ריקון הזרימה המשותפת).
      2. מזינים ערך של שם. זה יהיה השם שבו משתמשים שרתי proxy של API ורכיבי Shared Flow אחרים כדי להפנות אל רכיב ה-Shared Flow הזה. השם צריך להיות תיאורי כדי שמפתחים יוכלו להבין את התהליך.
      3. מזינים תיאור כדי לספק מידע נוסף על הפעולות בתהליך.
      4. לוחצים על הבא.
      5. אפשר גם לבחור את הסביבות שבהן רוצים לפרוס את התהליך החדש.

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

      6. לוחצים על Build and Deploy(בנייה ופריסה) כדי ליצור את התהליך המשותף החדש ולפרוס אותו בסביבות שבחרתם. אם לא בחרתם סביבה, התהליך המשותף ייווצר אבל לא יופעל.

    • כדי ליצור תהליך משותף ממקורות קיימים, מעלים חבילת תהליך.
      1. בוחרים באפשרות Shared Flow Bundle (חבילת זרימת נתונים משותפת) כדי לציין קובץ ‎ .zip שמכיל את הארטיפקטים שרוצים לכלול בזרימת הנתונים החדשה.

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

      2. לוחצים על הבא.
      3. לוחצים על בחירת קובץ כדי לעיין בקובץ ה-ZIP שמכיל את מקורות הזרימה המשותפים שרוצים לייבא.
      4. בתיבה שם של זרימת נתונים משותפת, מזינים שם לזרימת הנתונים המיובאת. זה יהיה השם שבו משתמשים ב-API proxy ובזרימות משותפות אחרות כדי להתייחס לזרימה המשותפת הזו. השם צריך להיות תיאורי כדי שמפתחים יוכלו להבין את התהליך.
      5. לוחצים על הבא.
      6. לוחצים על יצירה כדי ליצור את התהליך החדש ממקורות הנתונים שמייבאים.

קריאה לתהליך משותף מ-proxy ל-API או מתהליך משותף

אפשר לקרוא לתהליך משותף משרת proxy או מתהליך משותף אחר באמצעות מדיניות FlowCallout.

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

ראה גם

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