فراخوانی‌های 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 یا یک سرویس یکپارچه‌سازی که فراخوان را احراز هویت می‌کند، مجوزهای محدود اعمال می‌کند و اتصال محافظت‌شده‌ای به بک‌اند خصوصی نگه می‌دارد. این با آشکار کردن همه سرویس‌های بک‌اند یا هدایت یک درگاه مدیریت به اینترنت یکسان نیست.
دومی یک اتصال خصوصی واجد شرایط است. مستندات Private Connect برای اتصال‌های خروجی از Salesforce مسیریابی فراخوان‌های پشتیبانی‌شده را از طریق یک Outbound Network Connection متصل به یک اعتبارنامه نام‌دار و روی چیدمان تعریف‌شده AWS PrivateLink توصیف می‌کند. این ویژگی محدودیت‌های نسخه، مجوز و محصول دارد، پس پیش از طراحی بر پایه آن تأیید کنید که سازمان واجد شرایط است.
هیچ‌یک از دو طرح، کلاینت OpenVPN نصب‌شده درون Salesforce نیست و این ادعای قدیمی که هر یکپارچه‌سازی باید به یک بک‌اند عمومی برسد، هرجا اتصال خصوصی پشتیبانی‌شده جا بیفتد بیش از حد گسترده است. آنچه محیط اجرا پشتیبانی می‌کند را انتخاب کنید و سپس مسیر را تا API واقعی کامل کنید: نقطه پایانی AWS منبع محلی شما را نمی‌شناسد و مسیر لپ‌تاپ شما را به ارث نمی‌برد. DNS، مسیریابی بک‌اند، سیاست دسترسی و ترافیک پاسخ همه باید از معماری انتخابی شما پیروی کنند. مسیر خصوصی نیمه‌ساخته دقیقاً مانند یک مشکل احراز هویت شکست می‌خورد.
مسیر خصوصی را سرتاسر متصل کنید
از API به سمت بیرون کار کنید و در نخستین شکاف بایستید. تأیید کنید بک‌اند به‌صورت محلی پاسخ می‌دهد، سپس نقطه پایانی خصوصی به آن می‌رسد و بعد اعتبارنامه نام‌دار و اتصال خروجی آن همان نقطه پایانی را هدف می‌گیرند.
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فرمان نخست ثابت می‌کند بک‌اند از داخل شبکه خصوصی سالم است، دومی نشان می‌دهد نام به چه چیزی تجزیه می‌شود و سومی فراخوانی‌ای را از محیط اجرای واقعی 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همان دو کاوش را از شبکه خود بک‌اند اجرا کنید تا منبع مشاهده‌شده با آنچه محیط اجرا تولید کرده مقایسه شود. شکل مطلوب یک 200 است که پس از آن 401 یا 403 بیاید؛ دو 200 یعنی مسیر رد واقعاً اعمال نمی‌شود.
بازگشت را پیش از نیاز بنویسید: کدام ورودی فهرست مجاز، اعتبارنامه نام‌دار یا اتصال خروجی را تغییر دادید، مالک آن کیست و چگونه مقدار قبلی بازگردانده می‌شود. سپس حلقه را با نام بردن فراخوان ابری و مسیر کامل سرویس در تیکت ببندید تا کسی همان مسئله را دوباره به‌عنوان مشکل VPN باز نکند.