קריאות Apex יוצאות מ-Salesforce, לא מה-VPN שלך
VPN במחשב הנייד נותן לדפדפן שלך נתיב, לא ל-Apex או ל-Marketing Cloud. התאם את הקורא האמיתי לשער ציבורי או לחיבור פרטי מוסמך.
ה-API הפרטי עונה בדפדפן שלך ברגע שהמחשב הנייד מצטרף ל-VPN, ולכן האינטגרציה אמורה לעבוד. היא לא עובדת, כי הקוד שמבצע את הקריאה רץ במקום אחר לגמרי. Apex רץ בשרתי האפליקציה של Salesforce, ופעילות בצד השרת ב-Marketing Cloud רצה בסביבת ההרצה של אותו מוצר. אף אחד מהם לא יורש את המנהרה של המחשב הנייד שלך. בצע זאת כנוהל קצר: זהה את הקורא, בחר כניסה שהקורא הזה יכול להגיע אליה, חבר את הנתיב מקצה לקצה, ואז אמת מסביבת ההרצה עצמה.
כתוב את כרטיס הקורא לפני כל שינוי ברשת
מלא חמישה שדות וסרב לנחש אף אחד מהם. מוצר ההרצה וההקשר קובעים כל מה שממשיך מכאן, אז התחל שם ולא בחומת האש של השרת.
| Field | What it must answer |
|---|---|
| Runtime | Which product and execution context issues the request? |
| Endpoint | Which hostname must that runtime resolve, and to what? |
| Path | Which supported public entry or private connection carries it? |
| Identity | Which credential and which operation is the API asked to authorize? |
| Failure | How do responses return, and what happens when the path is down? |
לשונית דפדפן וקריאת Apex הן שני לקוחות שונים, ודפדפן שעובד רק מוכיח שקיים נתיב מהשולחן שלך. אם שדה סביבת ההרצה אומר Apex, השאלה הרלוונטית היא מאילו כתובות Salesforce יוצאת, ולא אילו כתובות יש למחשב הנייד שלך. לכן מנהרה שמאפשרת ל-API להיטען בדפדפן יכולה להשאיר את האינטגרציה נכשלת עם אותו זמן המתנה שהיה קודם. כרטיס הקורא קיים כדי לעצור את הטעות הזאת לפני שמישהו עורך חומת אש.
בחר את הכניסה שהקורא יכול באמת להשתמש בה
שני העיצובים לגיטימיים, והם פותרים בעיות שונות. הראשון הוא כניסה ציבורית מכוונת: שער API ב-HTTPS או שירות אינטגרציה שמאמת את הקורא, מחיל הרשאות צרות ושומר על חיבור מוגן ל-backend הפרטי. זה לא אותו דבר כמו לחשוף כל שירות backend או להעביר פורט ניהול לאינטרנט.
השני הוא חיבור פרטי מוסמך. התיעוד של Private Connect ליוצא של Salesforce מתאר ניתוב של קריאות נתמכות דרך Outbound Network Connection הקשור לאישור מזוהה, לפי פריסת AWS PrivateLink המוגדרת שלו. לתכונה יש מגבלות מהדורה, רישיון ומוצר, אז אשר שהארגון עומד בתנאים לפני שתעצב סביבה.
אף אחד מהעיצובים אינו לקוח OpenVPN המותקן בתוך Salesforce, והטענה הוותיקה שכל אינטגרציה חייבת להגיע ל-backend ציבורי רחבה מדי בכל מקום שבו חיבור פרטי נתמך מתאים. בחר את זה שסביבת ההרצה תומכת בו, ואז השלם את הנתיב ל-API האמיתי: נקודת קצה ב-AWS לא מכירה את המשאב המקומי שלך ולא יורשת את הנתיב של המחשב הנייד. DNS, ניתוב ה-backend, מדיניות הגישה ותעבורת התגובות חייבים כולם ללכת לפי הארכיטקטורה שבחרת. נתיב פרטי שנבנה חצי נכשל באופן שנראה בדיוק כמו בעיית אימות.
חבר את הנתיב הפרטי מקצה לקצה
עבוד מה-API החוצה ועצור בפער הראשון. אשר שה-backend עונה מקומית, ואז שנקודת הקצה הפרטית מגיעה אליו, ואז שהאישור המזוהה והחיבור היוצא שלו מכוונים לאותה נקודת קצה.
curl -sS -m 5 -o /dev/null -w '%{http_code}\n' http://10.40.8.20:8080/health
dig +short api.partner.example
sf apex run --file scripts/apex/callout-check.apex --target-org integrationהפקודה הראשונה מוכיחה שה-backend בריא מתוך הרשת הפרטית, השנייה מראה למה השם מתפענח, והשלישית מבצעת קריאה מסביבת ההרצה האמיתית של Salesforce. 200 מהראשונה וכשל מהשלישית מבודדים את הפער לנתיב או לאישור ולא לשירות.
שמור על היקף זהות מדויק בזמן החיווט. אישור מזוהה לא מתקן לבדו נקודת קצה שאינה נגישה, כי האישור והחיבור הפרטי הם הגדרות קשורות עם תפקידים נפרדים. רשימת IP מורשים מצמצמת קבלת רשת ואינה אישור API, אז שמור על אימות TLS רגיל ועל תהליך האימות והסבב של השירות עצמו. אם בדיקה עוברת רק אחרי שהשבתת את בדיקת התעודה, מצאת בעיית שם מארח ולא בעיית נתיב, והתעודה עדיין צריכה להתאים.
אמת מסביבת ההרצה, ואז תעד את הנסיגה
קבל בקשה מורשית ובלתי מזיקה מסביבת ההרצה של האינטגרציה, לא מהמכונה שלך. תעד את המקור הנצפה של השירות המקבל, את הזהות המאומתת, את התוצאה ואת בקשה אחת שנדחתה במכוון ושחייבת להיכשל.
curl -sS -o /dev/null -w '%{http_code} %{remote_ip}\n' https://api.partner.example/v1/ping
curl -sS -o /dev/null -w '%{http_code}\n' -H 'Authorization: Bearer invalid' https://api.partner.example/v1/pingהרץ את שתי הבדיקות זהות מרשת ה-backend עצמו כדי שאפשר יהיה להשוות את המקור הנצפה למה שסביבת ההרצה הפיקה. 200 ואחריו 401 או 403 הוא הצורה הרצויה; שני 200 פירושם שנתיב הדחייה לא נאכף באמת.
כתוב את הנסיגה לפני שתזדקק לה: איזו רשומת הרשאה, אישור מזוהה או חיבור יוצא שינית, מי הבעלים שלו ואיך לשחזר את הערך הקודם. ואז סגור את הלולאה בכך שתנקוב בכרטיס בקורא הענן ובנתיב השירות המלא, כדי שאף אחד לא יפתח מחדש את אותה סוגיה כבעיית VPN.