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

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

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

בסרטון הזה מוצגת הדגמה מלאה של הפיכת שירות SOAP לשירות REST באמצעות אשף ה-API Proxy ב-Apigee Edge. עם זאת, אם אתם רוצים יותר שליטה בהמרה מ-SOAP ל-REST, אתם יכולים ליצור שרת proxy באמצעות כללי מדיניות. מידע נוסף מופיע במאמר Tutorial: Manual construction of a SOAP-to-REST proxy ל-API in Apigee Edge.

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

בקטע הזה מוסבר איך ליצור proxy ל-API של SOAP עם RESTful באמצעות האפשרות REST to SOAP to REST באשף Build a Proxy (יצירת שרת proxy).

סקירה כללית

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

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

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

Edge

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

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

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

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

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

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

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

    https://[host]/base_path/conditional_flow_path

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

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

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

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

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

‫Classic Edge (ענן פרטי)

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

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

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

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

    זהו השם של ה-proxy שאתם יוצרים.
    נתיב בסיסי של שרת proxy

    מקטע URI שמופיע אחרי הכתובת http(s)://[host] של proxy ל-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, צריך לערוך את נתיב הבסיס כך שיהיה ייחודי.

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

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

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

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

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

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

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

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

כש-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 למעבר נתונים לשירות מבוסס SOAP

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

סקירה כללית

האפשרות Pass-Through Proxy מאפשרת ליצור proxy שמעביר את הודעת ה-SOAP בבקשה לשירות הקצה העורפי ללא שינוי, וכך קל מאוד ליצור proxy לשירות אינטרנט מבוסס-SOAP. מאחורי הקלעים, Edge מטפל בכל השינויים ופעילויות אחרות בתהליך באופן אוטומטי. לדוגמה, אם הבקשה היא בפורמט JSON, ‏ Edge מבצע המרה להודעת SOAP בפורמט XML תקין עם מרחבי שמות נכונים לפני שהוא שולח אותה לשירות באמצעות POST. באופן דומה, כשהשירות מחזיר תגובת SOAP מבוססת-XML, ‏ Edge מתרגם אותה בחזרה ל-JSON לפני שהוא מחזיר אותה ללקוח. בנוסף, Edge מגדיר את נקודת הקצה של יעד ה-Backend, שיכולה להיות שונה לכל פעולת 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 (שרת proxy).
  4. לוחצים על שירות SOAP.
  5. בדף הפרטים של ה-Proxy, מזינים את פרטי ה-WSDL.
    שדה תיאור
    WSDL

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

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

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

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

    הערה: המלצות של Apigee לגבי ניהול גרסאות של API זמינות ב Web API Design: The Missing Link.

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

    https://[host]/base_path/conditional_flow_path

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

    שימוש בתו כללי בנתיבי בסיס

    אתם יכולים להשתמש בתו כללי אחד או יותר של /*/ בנתיבי הבסיס של proxy ל-API כדי להכין את השרתים לשימוש עתידי. לדוגמה, נתיב בסיסי של /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. בתפריט הנפתח Port Type, בוחרים את סדרת הפעולות שרוצים להשתמש בה. ב-WSDL, רכיבי port type מגדירים את הפעולות שאפשר להפעיל בשירות אינטרנט.
  10. לוחצים על הבא.
  11. בדף Virtual hosts של האשף, בוחרים את המארחים הווירטואליים שאליהם proxy ל-API יקשר כשהוא יופעל. מידע נוסף זמין במאמר מידע על מארחים וירטואליים.
  12. בוחרים את סביבות הפריסה ולוחצים על יצירה ופריסה
    נוצר פרוקסי חדש של API ונפרס בסביבה שנבחרה.
  13. לוחצים על עריכת ה-proxy ל-API כדי להציג את דף הפרטים של ה-proxy ל-API.

‫Classic Edge (ענן פרטי)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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