Apex-callouts vertrek vanaf Salesforce, nie vanaf jou VPN nie
'n VPN op die skootrekenaar gee jou blaaier 'n roete, nie vir Apex of Marketing Cloud nie. Pas die werklike oproeper by 'n openbare poort of 'n gekwalifiseerde private verbinding.
Die private API antwoord in jou blaaier sodra die skootrekenaar by die VPN aansluit, dus behoort die integrasie te werk. Dit werk nie, want die kode wat die callout maak, loop heeltemal êrens anders. Apex loop op Salesforce se toepassingbedieners, en 'n Marketing Cloud-bedienerkant-aktiwiteit loop in daardie produk se looptyd. Nie een van hulle erf jou skootrekenaar se tonnel nie. Voer dit as 'n kort prosedure uit: identifiseer die oproeper, kies 'n ingang wat die oproeper kan bereik, koppel die pad van punt tot punt, en verifieer dan vanuit die looptyd self.
Skryf die oproeperkaart voordat jy enigiets aan die netwerk verander
Vul vyf velde in en weier om enige een te raai. Die uitvoerproduk en -konteks bepaal alles stroomaf, so begin daar eerder as by die bediener se firewall.
| 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? |
'n Blaaier-oortjie en 'n Apex-callout is twee verskillende kliënte, en 'n werkende blaaier bewys net dat daar 'n pad vanaf jou lessenaar bestaan. As die looptydveld Apex sê, is die relevante vraag van watter adresse Salesforce uitgaan, nie watter adresse jou skootrekenaar het nie. Daarom kan 'n tonnel wat die API in 'n blaaier laat laai, die integrasie laat faal met dieselfde timeout as voorheen. Die oproeperkaart bestaan om daardie fout te stop voordat iemand 'n firewall redigeer.
Kies die ingang wat die oproeper werklik kan gebruik
Twee ontwerpe is geldig, en hulle los verskillende probleme op. Die eerste is 'n doelbewuste openbare ingang: 'n HTTPS-API-poort of integrasiediens wat die oproeper verifieer, noukeurige toestemmings toepas en 'n beskermde verbinding na die private backend hou. Dit is nie dieselfde as om elke backend-diens bloot te stel of 'n bestuursport na die internet deur te stuur nie.
Die tweede is 'n gekwalifiseerde private verbinding. Salesforce se dokumentasie oor uitgaande Private Connect beskryf hoe ondersteunde callouts deur 'n Outbound Network Connection gerouteer word wat aan 'n genoemde geloofsbrief gebind is, oor sy gedefinieerde AWS PrivateLink-reëling. Die funksie het uitgawe-, lisensie- en produkbeperkings, so bevestig dat die organisasie kwalifiseer voordat jy daarom ontwerp.
Nie een ontwerp is 'n OpenVPN-kliënt wat binne Salesforce geïnstalleer is nie, en die ou bewering dat elke integrasie 'n openbare backend moet bereik, is te breed waar 'n ondersteunde private verbinding pas. Kies die een wat die looptyd ondersteun en voltooi dan die pad na die werklike API: 'n AWS-eindpunt ken nie jou plaaslike hulpbron nie en erf nie jou skootrekenaar se roete nie. DNS, backend-roetering, toegangsbeleid en antwoordverkeer moet almal die argitektuur volg wat jy gekies het. 'n Halfgeboude private pad faal op 'n manier wat presies soos 'n verifikasieprobleem lyk.
Koppel die private pad van punt tot punt
Werk van die API uitwaarts en stop by die eerste gaping. Bevestig dat die backend plaaslik antwoord, bevestig dan dat die private eindpunt dit bereik, en bevestig dan dat die genoemde geloofsbrief en sy uitgaande verbinding daardie eindpunt teiken.
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 integrationDie eerste opdrag bewys dat die backend gesond is van binne die private netwerk, die tweede wys waarheen die naam oplos, en die derde voer 'n callout vanuit die werklike Salesforce-looptyd uit. 'n 200 van die eerste en 'n mislukking van die derde isoleer die gaping na die pad of die geloofsbrief eerder as die diens.
Hou die identiteitsomvang presies terwyl jy koppel. 'n Genoemde geloofsbrief herstel nie op sy eie 'n onbereikbare eindpunt nie, want die geloofsbrief en die private verbinding is verwante instellings met aparte take. 'n IP-toelaatlys vernou netwerktoelating en is nie 'n API-geloofsbrief nie, so behou normale TLS-validasie en die diens se eie verifikasie- en rotasieproses. As 'n toets eers slaag nadat jy sertifikaatkontrole afgeskakel het, het jy 'n gasheernaamprobleem eerder as 'n padprobleem gevind, en die sertifikaat moet steeds pas.
Verifieer vanuit die looptyd en teken dan die terugrol aan
Aanvaar 'n skadelose toegelate versoek van die integrasie-looptyd, nie van jou masjien nie. Teken die ontvangende diens se waargenome bron, die geverifieerde hoof, die resultaat en een doelbewus geweierde versoek wat moet faal aan.
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/pingVoer dieselfde twee ondersoeke vanaf die backend se eie netwerk uit, sodat die waargenome bron met wat die looptyd gelewer het, vergelyk kan word. 'n 200 gevolg deur 'n 401 of 403 is die vorm wat jy wil hê; twee 200's beteken die weieringspad word nie werklik afgedwing nie.
Skryf die terugrol voordat jy dit nodig het: watter toelaatlys-inskrywing, genoemde geloofsbrief of uitgaande verbinding jy verander het, wie dit besit, en hoe om die vorige waarde te herstel. Sluit dan die kring deur die oproeper in die wolk en die volledige dienspad in die kaartjie te noem, sodat niemand dieselfde kwessie weer as 'n VPN-probleem oopmaak nie.