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 или интеграционна услуга, която удостоверява извикващия, прилага тесни разрешения и поддържа защитена връзка към частния бекенд. Това не е същото като да изложите всяка бекенд услуга или да пренасочите административен порт към интернет.
Вторият е квалифицирана частна връзка. Документацията на Salesforce за изходящ Private Connect описва маршрутизиране на поддържани извиквания през 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 проблем.