Ang mga callout ng Apex ay lumalabas mula sa Salesforce, hindi sa iyong VPN

Sumasagot ang pribadong API sa browser mo sa sandaling kumonekta ang laptop sa VPN, kaya dapat gumana ang integrasyon. Hindi ito gumagana, dahil ang code na gumagawa ng callout ay tumatakbo sa ibang lugar, ganap. Tumatakbo ang Apex sa mga application server ng Salesforce, at ang server-side na aktibidad sa Marketing Cloud ay tumatakbo sa runtime ng produktong iyon. Wala sa kanila ang nagmamana ng tunnel ng laptop mo. Gawin ito bilang maikling pamamaraan: tukuyin ang tumatawag, pumili ng pasukan na kayang maabot ng tumatawag na iyon, ikonekta ang landas mula simula hanggang dulo, at pagkatapos ay i-verify mula sa runtime mismo.

Isulat ang card ng tumatawag bago ang anumang pagbabago sa network

Punan ang limang field at tumangging hulaan ang alinman sa mga ito. Ang produktong nagpapatupad at ang konteksto ang nagtatakda ng lahat ng susunod, kaya magsimula doon at hindi sa firewall ng server.

Ang tab ng browser at ang callout ng Apex ay dalawang magkaibang kliyente, at ang gumaganang browser ay nagpapatunay lamang na may landas mula sa iyong mesa. Kung sinasabi ng field ng runtime na Apex, ang kaugnay na tanong ay kung saang mga address lumalabas ang Salesforce, hindi kung anong mga address ang mayroon ang laptop mo. Iyon ang dahilan kung bakit ang tunnel na nagpapaload ng API sa browser ay maaaring mag-iwan sa integrasyon na nabigo sa parehong timeout tulad ng dati. Ang card ng tumatawag ay naroroon upang pigilan ang pagkakamaling iyon bago pa may mag-edit ng firewall.

Piliin ang pasukan na talagang magagamit ng tumatawag

Ang dalawang disenyo ay lehitimo, at iba ang nilulutas nila. Ang una ay sinadyang pampublikong pasukan: isang HTTPS API gateway o serbisyo ng integrasyon na nagpapatotoo sa tumatawag, naglalapat ng makitid na pahintulot, at nagpapanatili ng protektadong koneksyon sa pribadong backend. Hindi iyon katulad ng paglalantad sa bawat serbisyo ng backend o pagpapasa ng management port sa internet.

Ang pangalawa ay isang kwalipikadong pribadong koneksyon. Inilalarawan ng dokumentasyon ng Private Connect palabas ng Salesforce ang pag-route ng mga sinusuportahang callout sa pamamagitan ng Outbound Network Connection na nakatali sa pinangalanang kredensyal, ayon sa tinukoy nitong AWS PrivateLink arrangement. May mga limitasyon ang feature sa edisyon, lisensya at produkto, kaya tiyakin na kwalipikado ang organisasyon bago magdisenyo sa paligid nito.

Wala sa mga disenyo ang isang OpenVPN client na naka-install sa loob ng Salesforce, at ang lumang pahayag na dapat maabot ng bawat integrasyon ang pampublikong backend ay masyadong malawak kung saan nababagay ang sinusuportahang pribadong koneksyon. Piliin ang sinusuportahan ng runtime, pagkatapos ay kumpletuhin ang landas hanggang sa tunay na API: ang AWS endpoint ay hindi kilala ang iyong lokal na resource at hindi nagmamana ng ruta ng laptop mo. Ang DNS, routing ng backend, patakaran sa access at trapiko ng tugon ay dapat lahat sumunod sa arkitekturang pinili mo. Ang kalahating itinayong pribadong landas ay nabibigo sa paraang mukhang eksaktong problema sa pagpapatotoo.

Ikonekta ang pribadong landas mula simula hanggang dulo

Magtrabaho papalabas mula sa API at huminto sa unang puwang. Tiyakin na sumasagot ang backend nang lokal, pagkatapos na naaabot ito ng pribadong endpoint, at pagkatapos na ang pinangalanang kredensyal at ang palabas na koneksyon nito ay naglalayon sa endpoint na iyon.

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

Pinatutunayan ng unang utos na malusog ang backend mula sa loob ng pribadong network, ipinapakita ng pangalawa kung ano ang nireresolba ng pangalan, at ang pangatlo ay nagsasagawa ng callout mula sa tunay na runtime ng Salesforce. Ang 200 mula sa una at pagkabigo mula sa pangatlo ay naghihiwalay ng puwang sa landas o kredensyal, hindi sa serbisyo.

Panatilihing tumpak ang saklaw ng pagkakakilanlan habang nagkokonekta. Ang pinangalanang kredensyal ay hindi nag-aayos ng hindi maabot na endpoint nang mag-isa, dahil ang kredensyal at ang pribadong koneksyon ay magkaugnay na setting na may magkahiwalay na gawain. Ang listahan ng pinapayagang IP ay nagpapaliit ng pagtanggap sa network at hindi kredensyal ng API, kaya panatilihin ang normal na TLS validation at ang sariling proseso ng pagpapatotoo at pag-ikot ng serbisyo. Kung pumasa lamang ang isang pagsubok matapos mong patayin ang pagsusuri ng sertipiko, natagpuan mo ang problema sa hostname at hindi sa landas, at kailangan pa ring tumugma ang sertipiko.

I-verify mula sa runtime, pagkatapos ay itala ang rollback

Tanggapin ang isang hindi mapanganib at pinapayagang kahilingan mula sa runtime ng integrasyon, hindi mula sa iyong makina. Itala ang naobserbahang pinagmulan ng tumatanggap na serbisyo, ang napatotohanang principal, ang resulta, at isang sinadyang tinanggihang kahilingan na dapat mabigo.

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

Patakbuhin ang parehong dalawang pagsusuri mula sa sariling network ng backend upang maihambing ang naobserbahang pinagmulan sa ginawa ng runtime. Ang 200 na sinusundan ng 401 o 403 ang hugis na gusto mo; dalawang 200 ang ibig sabihin ay hindi talaga ipinatutupad ang landas ng pagtanggi.

Isulat ang rollback bago mo ito kailanganin: aling entry ng listahan ng pinapayagan, pinangalanang kredensyal o palabas na koneksyon ang binago mo, sino ang may-ari nito, at paano ibabalik ang dating halaga. Pagkatapos ay isara ang loop sa pamamagitan ng pagbanggit sa ticket ng cloud caller at ng buong landas ng serbisyo, upang walang magbukas muli ng parehong isyu bilang problema sa VPN.