חשיפת שירות SOAP כשרת proxy של API

אתם צופים במסמכי העזרה של Apigee Edge.
כניסה למסמכי העזרה של Apigee X. info

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

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

יצירת שרת proxy של API ל-REST לשירות מבוסס-SOAP

בקטע הזה נסביר איך ליצור שרת proxy של SOAP API מסוג RESTful באמצעות האפשרות מ-REST ל-SOAP ל-REST באשף יצירת שרת proxy.

סקירה כללית

האפשרות REST to SOAP to REST מעבדת את ה-WSDL כדי ליצור שרת proxy של API ל-REST. Edge קובע מה-WSDL את הפעולות הנתמכות של השירות, את פרמטרי הקלט וכו'. Edge "מנחש" באיזו שיטת HTTP להשתמש בכל פעולה. בדרך כלל, Edge מתרגם פעולות לבקשות GET, שיש להן יתרון של שמירה במטמון. ‏Edge גם מגדיר את נקודת הקצה של היעד לקצה העורפי, שעשויה להשתנות בהתאם לפעולה של SOAP.

בשביל סוג שרת ה-proxy הזה, Edge יוצר באופן אוטומטי מפרט OpenAPI, שאפשר להשתמש בו כדי ליצור מסמכי תיעוד של API.

שלבים בסיסיים

Edge

כדי ליצור שרת proxy של API ל-REST לשירות מבוסס-SOAP באמצעות ממשק המשתמש של Edge:

  1. נכנסים לחשבון בכתובת apigee.com/edge.
  2. בוחרים באפשרות פיתוח > שרתים proxy ל-API בסרגל הניווט הימני.
  3. לוחצים על +Proxy.
  4. לוחצים על שירות SOAP.
  5. בדף Proxy details (פרטי שרת proxy), מספקים את קובץ ה-WSDL.
    שדה תיאור
    איך מספקים קובץ WSDL

    בוחרים את המקור של קובץ ה-WSDL.

    • מכתובת אינטרנט (URL) – מזינים או מדביקים את כתובת ה-URL של ה-WSDL.
    • מהמחשב שלי – העלאת קובץ WSDL מהספרייה המקומית. אם יש יחסי תלות, אפשר להעלות כמה קבצים.
  6. לוחצים על Validate כדי לאמת את ה-WSDL.
  7. מזינים את פרטי שרת ה-proxy הבאים:
    שדה תיאור
    שם השם שמוצג ל-API. צריך לציין תווים אלפאנומריים, מקף (-) או קו תחתון (_).
    נתיב בסיס

    קטע URI שמופיע אחרי הכתובת http(s)://[host] של שרת ה-API המחובר. Edge משתמש ב-URI של נתיב הבסיס כדי להתאים את הודעות הבקשה הנכנסות ולנתב אותן לשרת ה-proxy המתאים של ה-API.

    הערה: ברירת המחדל של נתיב הבסיס של שרת ה-API הסוכני היא הערך שצוין בשדה Name, שמומר לכל אות קטנה.

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

    https://[host]/base_path/conditional_flow_path

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

    שימוש בתו הכללי (wildcard) בנתיבים בסיסיים

    שימוש בתו Wildcard אחד או יותר מסוג /*/ בנתיבי בסיס של שרת proxy ל-API כדי להתכונן לעתיד. לדוגמה, נתיב בסיס של /team/*/members מאפשר ללקוחות לבצע קריאה ל-https://[host]/team/blue/members ול-https://[host]/team/green/members בלי שתצטרכו ליצור שרתים proxy חדשים של API כדי לתמוך בצוותים חדשים. לתשומת ליבכם: אין תמיכה ב-/**/.
    תיאור (אופציונלי) תיאור של ה-API.
  8. לוחצים על הבא.
  9. בדף Common policies (מדיניות נפוצה) של האשף, מגדירים את הפרטים הבאים:
    • דרישות הרשאה באבטחה בקטע אבטחה: הרשאה. עיינו בקטע הוספת אבטחה.
    • תמיכה בשיתוף משאבים בין מקורות (CORS) בקטע אבטחה: דפדפן. ראו הוספת תמיכה ב-CORS.
    • מכסות להגנה על שירות הקצה העורפי מפני תנועה רבה בקטע מכסה. מכסות (האפשרות הזו לא זמינה אם בוחרים באפשרות 'הרשאה לצורך העברה').
  10. בדף WSDL operations, בוחרים את סוג שרת ה-proxy של ה-API REST to SOAP to REST.

    תוצג טבלה עם רשימת הפעולות ש-Edge "גילה" בקובץ ה-WSDL. אתם יכולים לבחור ולקבוע אילו פעולות תרצו לשלב בשרת ה-API. הטבלה מוצגת באיור הבא.

  11. בוחרים סוג יציאה מהתפריט הנפתח כדי לציין את קבוצת הפעולות שבה רוצים להשתמש. ב-WSDL, רכיבי סוג היציאה מגדירים את הפעולות שאפשר לבצע בשירות אינטרנט.
  12. אפשר לשנות את הנתיב של ה-API ל-REST לפעולה. הנתיב ישמש כשם המשאב בכתובת ה-URL של שרת ה-proxy של ה-API.
  13. אפשר לשנות את הפעולה (שיטת ה-HTTP) המשויכת לפעולה.
  14. לוחצים על הבא.
  15. בדף Virtual hosts (מארחים וירטואליים) באשף, בוחרים את המארחים הווירטואליים ששרת ה-proxy של ה-API יתחבר אליהם במהלך הפריסה. מידע נוסף זמין במאמר מידע על מארחים וירטואליים.
  16. לוחצים על הבא.
  17. בוחרים את סביבות הפריסה ולוחצים על Create and deploy
    .‏ Proxy ה-API החדש נוצר ופורס בסביבה שנבחרה.
  18. לוחצים על Edit proxy כדי להציג את דף הפרטים של שרת ה-API.

Classic Edge (ענן פרטי)

כדי ליצור שרת proxy של API ל-REST לשירות מבוסס-SOAP באמצעות ממשק המשתמש הקלאסי של Edge:

  1. מתחברים אל http://ms-ip:9000, כאשר ms-ip היא כתובת ה-IP או שם ה-DNS של צומת שרת הניהול.
  2. בסרגל הניווט העליון, בוחרים באפשרות APIs‏ > API Proxies.
  3. לוחצים על + proxy ל-API.
  4. בשלב 'יצירת שרת proxy', בוחרים באפשרות 'שירות SOAP'.
  5. לוחצים על הבא.
  6. בדף הפרטים, בוחרים באפשרויות הבאות. אחרי שבוחרים קובץ WSDL, צריך ללחוץ על Validate.
    בשדה הזה מבצעים את הפעולה הזו
    WSDL

    בוחרים את המקור של קובץ ה-WSDL.

    • כתובת URL – מזינים את כתובת ה-URL של קובץ ה-WSDL שבו רוצים להשתמש.
    • קובץ – בוחרים קובץ WSDL במערכת הקבצים. במקרים שבהם יש קבצים תלויים נוספים, אפשר לבחור את כולם.
    • Example URL – בוחרים מתוך רשימה של קובצי WSDL לשירותי אינטרנט שזמינים לכולם. הם שימושיים לניסיון התכונות של שרת proxy ל-SOAP או ל-API ב-Edge.
    שם שרת ה-proxy

    זהו השם של שרת ה-proxy שיצרתם.
    Proxy Base Path

    קטע URI שמופיע אחרי הכתובת http(s)://[host] של שרת ה-API המחובר. Edge משתמש ב-URI של נתיב הבסיס כדי להתאים את הודעות הבקשה הנכנסות ולנתב אותן לשרת ה-proxy המתאים של ה-API.

    הערה: ברירת המחדל של נתיב הבסיס של שרת ה-proxy של ה-API היא הערך שצוין בשדה Name, שמומר לכל אות קטנה.

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

    https://[host]/base_path/conditional_flow_path

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

    שימוש בתו הכללי (wildcard) בנתיבים בסיסיים

    שימוש בתו Wildcard אחד או יותר מסוג /*/ בנתיבי בסיס של שרת proxy ל-API כדי להתכונן לעתיד. לדוגמה, נתיב בסיס של /team/*/members מאפשר ללקוחות לבצע קריאה ל-https://[host]/team/blue/members ול-https://[host]/team/green/members בלי שתצטרכו ליצור שרתים proxy חדשים של API כדי לתמוך בצוותים חדשים. לתשומת ליבכם: אין תמיכה ב-/**/.
    תיאור תיאור קצר של שרת ה-proxy.
  7. לוחצים על הבא.
  8. בדף WSDL, בוחרים את סוג שרת ה-proxy של ה-API REST to SOAP to REST.

    תוצג טבלה עם רשימת הפעולות ש-Edge "גילה" בקובץ ה-WSDL. אתם יכולים לבחור ולקבוע אילו פעולות תרצו לשלב בשרת ה-API. הטבלה מוצגת באיור הבא.

    בדף הפעולות של WSDL, סוג שרת ה-proxy של ה-API מוגדר כ-REST ל-SOAP ל-REST, וטבלה מציגה שורה אחת של תוצאות עם פעולת ההוספה.

  9. בעמודה Port Type (סוג היציאה), בוחרים את קבוצת הפעולות שבה רוצים להשתמש. ב-WSDL, רכיבי סוג היציאה מגדירים את הפעולות שאפשר לבצע בשירות אינטרנט.
  10. אפשר גם לשנות את שיטת ה-HTTP המשויכת לפעולה.

    הערה: Edge מבצע "ניחוי הטוב ביותר" כדי לקבוע את שיטת ה-HTTP שבה יש להשתמש בכל פעולה. בדרך כלל, עדיף להשתמש ב-GET כי אפשר לשמור בקשות GET במטמון.
  11. אפשר לשנות את הנתיב של ה-API ל-REST של פעולה. הנתיב ישמש כשם המשאב בכתובת ה-URL של שרת ה-proxy של ה-API.
  12. לוחצים על שאר השלבים באשף כדי להוסיף אבטחה, לבחור מארחים וירטואליים וסביבת פריסה.
  13. בדף Build, לוחצים על Build and Deploy. Edge יוצר ומפרס את שרת ה-proxy החדש של ה-API על סמך ה-WSDL.
  14. עוברים לדף הסיכום של שרת ה-API החדש. שימו לב שנוצרה קבוצה של משאבים על סמך הפעולות שהתגלו בקובץ ה-WSDL.

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

מידע על שרת ה-proxy הסופי

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

לדוגמה, בצד הבקשה, מדיניות AssignMessage משמשת להגדרת כתובת ה-URL של היעד. בצד התגובה, המדיניות פועלת כדי להמיר את התגובה מ-XML ל-JSON, לחלץ את החלק של גוף ה-SOAP בתגובה למשתנה ולהגדיר את הודעת התגובה. כללי המדיניות האלה (ואחרים) מתווספים באופן אוטומטי כשיוצרים את שרת ה-proxy.

מפרט OpenAPI: כדי להציג את מפרט OpenAPI שנוצר באופן אוטומטי לשרת ה-proxy הזה, אפשר להיכנס לכתובת http(s)://[proxy_domain]/[proxy_base_path]/openapi.json. עם זאת, ההמרה לא תמיד מדויקת, כי לא כל הכללים של סכימה של XML יכולים להיות מיוצגים במפרט OpenAPI.

יצירת שרת proxy להעברה (pass-through) לשירות שמבוסס על SOAP

בקטע הזה מוסבר איך יוצרים שרת proxy מסוג pass-through באמצעות האפשרות Pass-Through Proxy בתיבת הדו-שיח Create New Proxy (יצירת שרת proxy חדש).

סקירה כללית

האפשרות Pass-Through Proxy מאפשרת ליצור שרת proxy שמעביר את הודעת ה-SOAP בבקשה לשירות לקצה העורפי "ללא שינוי", וכך קל מאוד ליצור שרת proxy לשירות אינטרנט שמבוסס על SOAP. מאחורי הקלעים, Edge מטפל באופן אוטומטי בכל הטרנספורמציות ובפעילויות אחרות בתהליך. לדוגמה, אם הבקשה בפורמט JSON, Edge ממיר אותה להודעת XML SOAP תקינה עם מרחבי שמות נכונים לפני שליחת הבקשה לשירות באמצעות POST. באופן דומה, כשהשירות מחזיר תשובה של SOAP שמבוססת על XML, Edge מתרגם אותה בחזרה ל-JSON לפני שהוא מחזיר אותה ללקוח. בנוסף, Edge מגדיר את נקודת הקצה של היעד לקצה העורפי, שעשויה להשתנות בהתאם לפעולה של SOAP.

בשרת proxy מהסוג הזה, Edge מארח את ה-WSDL ויוצר תהליך בשרת ה-proxy כדי לאפשר לכם לגשת אליו. הכתובת של ה-WSDL שמתארח ב-Edge,‏ http(s)://[proxy_domain]/[proxy_base_path]?wsdl, הופכת לכתובת ה-URL החדשה של נקודת הקצה של השירות ללקוחות שמפעילים את שירות ה-SOAP דרך שרת ה-proxy.

שלבים בסיסיים

Edge

כדי ליצור שרת proxy להעברה דרך שירות שמבוסס על SOAP באמצעות ממשק המשתמש של Edge:

  1. נכנסים לחשבון בכתובת apigee.com/edge.
  2. בוחרים באפשרות פיתוח > שרתים proxy ל-API בסרגל הניווט הימני.
  3. לוחצים על +Proxy.
  4. לוחצים על שירות SOAP.
  5. בדף Proxy details, מציינים את פרטי ה-WSDL.
    שדה תיאור
    WSDL

    בוחרים את המקור של קובץ ה-WSDL.

    • מכתובת אינטרנט (URL) – מזינים או מדביקים את כתובת ה-URL של ה-WSDL.
    • מהמחשב שלי – העלאת קובץ WSDL מהספרייה המקומית. אם יש יחסי תלות, אפשר להעלות כמה קבצים.
    שם

    השם של שרת ה-proxy של ה-API.
    נתיב בסיס

    קטע URI אחרי הכתובת http(s)://[host] של שרת ה-proxy של ה-API. Edge משתמש ב-URI של נתיב הבסיס כדי להתאים את הודעות הבקשה הנכנסות ולנתב אותן לשרת ה-proxy המתאים של ה-API.

    הערה: ההמלצות של Apigee לגבי ניהול גרסאות של API מפורטות בקטע ניהול גרסאות בספר האלקטרוני עיצוב Web API: החוליה החסרה.

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

    https://[host]/base_path/conditional_flow_path

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

    שימוש בתווים כלליים לחיפוש בנתיבים בסיסיים

    כדי להבטיח את עמידות השרתים הווירטואליים ל-API בעתיד, אפשר להשתמש בתו Wildcard אחד או יותר מסוג /*/ בנתיבי הבסיס של השרתים הווירטואליים. לדוגמה, נתיב בסיס של /team/*/members מאפשר ללקוחות לבצע קריאה ל-https://[host]/team/blue/members ול-https://[host]/team/green/members בלי שתצטרכו ליצור שרתים proxy חדשים של API כדי לתמוך בצוותים חדשים. לתשומת ליבכם: אין תמיכה ב-/**/.

    הערה: ברירת המחדל של נתיב הבסיס של שרת ה-proxy של ה-API היא הערך שצוין בשדה Name (שם), שמומר לכל אותיות קטנות, אלא אם עורכים את התוכן בשדה Base Path (נתיב בסיס) באופן מפורש.
    תיאור (אופציונלי) תיאור של ה-API.
  6. לוחצים על הבא.
  7. בדף Common policies (מדיניות נפוצה) של האשף, מגדירים את הפרטים הבאים:
  8. בדף WSDL, בוחרים את סוג שרת ה-proxy של ה-API Pass-Through SOAP.

  9. בוחרים סוג יציאה מהתפריט הנפתח כדי לציין את קבוצת הפעולות שבה רוצים להשתמש. ב-WSDL, רכיבי סוג היציאה מגדירים את הפעולות שאפשר לבצע בשירות אינטרנט.
  10. לוחצים על הבא.
  11. בדף Virtual hosts (מארחים וירטואליים) באשף, בוחרים את המארחים הווירטואליים ששרת ה-proxy של ה-API יתחבר אליהם במהלך הפריסה. מידע נוסף זמין במאמר מידע על מארחים וירטואליים.
  12. בוחרים את סביבות הפריסה ולוחצים על Create and deploy
    .‏ Proxy ה-API החדש נוצר ופורס בסביבה שנבחרה.
  13. לוחצים על Edit proxy כדי להציג את דף הפרטים של שרת ה-API.

Classic Edge (ענן פרטי)

כדי ליצור שרת proxy להעברה דרך שירות שמבוסס על SOAP באמצעות ממשק המשתמש הקלאסי של Edge:

  1. מתחברים אל http://ms-ip:9000, כאשר ms-ip היא כתובת ה-IP או שם ה-DNS של צומת שרת הניהול.
  2. בסרגל הניווט העליון, בוחרים באפשרות APIs‏ > API Proxies.
  3. לוחצים על + proxy ל-API.
  4. בשלב 'יצירת שרת proxy', בוחרים באפשרות 'שירות SOAP'.
  5. לוחצים על הבא.
  6. בדף הפרטים, בוחרים באפשרויות הבאות. אחרי שבוחרים קובץ WSDL, צריך ללחוץ על Validate.
    בשדה הזה מבצעים את הפעולה הזו
    WSDL

    בוחרים את המקור של קובץ ה-WSDL.

    • כתובת URL – מזינים את כתובת ה-URL של קובץ ה-WSDL שבו רוצים להשתמש.
    • קובץ – בוחרים קובץ WSDL במערכת הקבצים. במקרים שבהם יש קבצים תלויים נוספים, אפשר לבחור את כולם.
    • כתובת URL לדוגמה – בוחרים מתוך רשימה של קובצי WSDL לשירותי אינטרנט שזמינים לכולם. הם שימושיים לניסיון התכונות של שרת proxy ל-SOAP או ל-API ב-Edge.
    שם שרת ה-proxy

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

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

  8. לוחצים על הבא.
  9. בדף WSDL, בוחרים את סוג שרת ה-proxy של ה-API Pass-Through SOAP.

    הערה: מוצגת טבלה עם כל פעולת WSDL ועומס הנתונים (payload) התואם שלה ב-SOAP. זהו עומס העבודה ש "עובר דרך" שירות ה-SOAP בקצה העורפי.

    בדף WSDL, סוג שרת ה-proxy של ה-API מוגדר ל-Pass-Through SOAP, ורשימת הפעולות כמו GetQuote מאורגנת לפי סוג היציאה.
  10. בעמודה Port Type (סוג היציאה), בוחרים את קבוצת הפעולות שבה רוצים להשתמש. ב-WSDL, רכיבי סוג היציאה מגדירים את הפעולות שאפשר לבצע בשירות אינטרנט.
  11. לוחצים על שאר השלבים באשף כדי להוסיף אבטחה, לבחור מארחים וירטואליים וסביבת פריסה.
  12. בדף Build, לוחצים על Build and Deploy. Edge יוצר ומפרס את שרת ה-proxy החדש של ה-API על סמך ה-WSDL.

מידע על שרת ה-proxy הסופי

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

לדוגמה, באיור הבא מוצג החלק של תהליך הטרום בנקודת הקצה של היעד בשרת proxy של העברה דרך. בצד הבקשה, המדיניות AssignMessage משמשת להגדרת כתובת ה-URL של היעד. בצד התגובה, המדיניות פועלת כדי להמיר את התגובה מ-XML ל-JSON, לחלץ את החלק של גוף ה-SOAP בתגובה למשתנה ולהגדיר את הודעת התגובה. כללי המדיניות האלה (ואחרים) מתווספים באופן אוטומטי כשיוצרים את שרת ה-proxy.

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

WSDL שמתארח ב-Edge: כדי לראות את ה-WSDL שמתארח ב-Edge שנוצר עבור סוג שרת ה-proxy הזה, עוברים אל http(s)://[proxy_domain]/[proxy_base_path]?wsdl.

פיתוח מתקדם של שרת proxy מסוג SOAP ל-REST

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