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-то во прелистувач може да ја остави интеграцијата да паѓа со истиот тајмаут како порано. Картичката на повикувачот постои за да ја запре таа грешка пред некој да уреди огнен ѕид.
Изберете влез што повикувачот навистина може да го користи
Двата дизајна се легитимни и решаваат различни проблеми. Првиот е намерен јавен влез: HTTPS API порта или интеграциска услуга што го автентификува повикувачот, применува тесни дозволи и држи заштитена врска со приватниот backend. Тоа не е исто како да се изложи секоја backend услуга или да се пренасочи управувачка порта на интернет.
Вториот е квалификувана приватна врска. Документацијата на Salesforce за излезен Private Connect опишува насочување на поддржаните повици преку 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 проблем.