Apex-Callouts ginn vu Salesforce aus, net vun Ärem VPN
E Laptop-VPN gëtt Ärem Browser e Wee, net Apex oder Marketing Cloud. Maacht de richtegen Uruffer mat engem ëffentleche Gateway oder enger qualifizéierter privater Verbindung zesummen.
Déi privat API äntwert an Ärem Browser dee Moment wou de Laptop bei de VPN geheit, also sollt d'Integratioun funktionéieren. Se funktionéiert net, well de Code deen den Callout mécht, komplett anescht laf. Apex laf op den Applikatiounsservere vu Salesforce, an eng Serversäit-Aktivitéit a Marketing Cloud laf an der Runtime vun deem Produkt. Keng vun deenen zwee ierft den Tunnel vun Ärem Laptop. Maacht dat als kuerz Prozedur: identifizéiert den Uruffer, wielt en Agang deen deen Uruffer erreeche kann, verbannt de Wee vun Ufank bis Enn, a verifizéiert dann aus der Runtime selwer.
Schreift d'Urufferkaart ier Dir eppes um Netz ännert
Fëllt fënnef Felder aus a refuséiert ee vun hinnen ze roden. D'Produkt vun der Ausféierung an de Kontext entscheede alles wat duerno kënnt, also fänkt do un an net bei der Firewall vum Server.
| 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? |
En Browser-Tab an en Apex-Callout sinn zwee verschidde Clienten, an e funktionéierende Browser beweise just datt et e Wee vun Ärem Schreifdësch aus gëtt. Wa säi Runtime-Feld Apex seet, ass déi relevant Fro vun deene Adressen aus Salesforce erausgeet, net déi Adressen déi Ären Laptop huet. Dofir kann en Tunnel deen d'API am Browser lued d'Integratioun nach ëmmer mat deem selwechten Timeout wéi virdrun feelen. D'Urufferkaart ass do fir dee Feeler ze stoppen ier een eng Firewall ännert.
Wielt den Agang deen den Uruffer wierklech ka benotzen
Déi zwou Konzepter si legitim, a si léise verschidde Problemer. Déi éischt ass en bewossten ëffentlechen Agang: en HTTPS-API-Gateway oder en Integratiounsservice deen den Uruffer authentifizéiert, enk Rechter uwendt an eng geschützt Verbindung zum private Backend hält. Dat ass net datselwecht wéi all Backend-Service ze weisen oder e Managementport an den Internet weiderzeleeden.
Déi zweet ass eng qualifizéiert privat Verbindung. Dem Salesforce seng Dokumentatioun zu Private Connect fir erausginn beschreift wéi ënnerstëtzt Callouts iwwer eng Outbound Network Connection déi un eng benannt Kredential gebonne ass, iwwer seng definéiert AWS-PrivateLink-Uerdnung gerout ginn. D'Funktioun huet Aschränkungen an Editioun, Lizenz a Produkt, also confirméiert datt d'Organisatioun den Ufuerderunge entsprécht ier Dir ronderëm se plangt.
Keen vun deenen zwee Konzepter ass en OpenVPN-Client deen an Salesforce installéiert ass, an déi méi al Behauptung datt all Integratioun en ëffentlecht Backend muss erreechen ass ze wäit iwwerall wou eng ënnerstëtzt privat Verbindung passt. Wielt deen deen d'Runtime ënnerstëtzt, a maacht dann de Wee bis zur richtege API fäerdeg: en AWS-Endpunkt weess net vun Ärem lokale Ressource a ierft net de Wee vun Ärem Laptop. DNS, Backend-Routing, Accesspolitik an Äntwerttrafic mussen alleguer der Architektur folgen déi Dir gewielt hutt. En hallef gebaute private Wee feelt op eng Manéier déi genee wéi en Authentifizéierungsproblem ausgesäit.
Verbannt de private Wee vun Ufank bis Enn
Schafft vun der API no baussen a stoppt bei der éischter Lück. Confirméiert datt d'Backend lokal äntwert, dann datt den private Endpunkt et erreecht, dann datt déi benannt Kredential an hir erausgäng Verbindung deen Endpunkt viséieren.
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 integrationDen éischte Kommando beweist datt d'Backend gesond ass vun bannen aus dem private Netz, deen zweeten weist op wat den Numm sech opléist, an den drëtten erfëllt en Callout aus der richteger Salesforce-Runtime. En 200 aus dem éischten an en Feeler aus dem drëtten isoléieren d'Lück op de Wee oder d'Kredential an net op de Service.
Halt den Ëmfang vun der Identitéit präzis wärend Dir verbannt. Eng benannt Kredential reparéiert net eleng en onerrechbaren Endpunkt, well d'Kredential an d'privat Verbindung verbonne Parameter mat getrennten Aufgabe sinn. Eng IP-Erlaabneslëscht mécht de Netzzougang méi enk an ass keng API-Kredential, also behält déi normal TLS-Validéierung an de Service säin eegene Prozess vun Authentifizéierung a Rotatioun. Wa en Test just nom Ausschalte vun der Zertifikatskontroll geet, hutt Dir e Hostnummproblem fonnt an net e Weeproblem, an d'Zertifikat muss nach ëmmer passen.
Verifizéiert aus der Runtime an notéiert dann de Rollback
Akzeptéiert eng harmlos erlaabte Fuerderung aus der Runtime vun der Integratioun, net vun Ärer Maschinn. Notéiert déi observéiert Quell vum Service dee se kritt, de authentifizéierte Principal, d'Resultat an eng bewosst refuséiert Fuerderung déi muss feelen.
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/pingFuert déi selwecht zwou Prüfungen aus dem eegene Netz vum Backend aus, sou datt déi observéiert Quell mat deem verglach ka ginn wat d'Runtime produzéiert huet. En 200 gefollegt vun engem 401 oder 403 ass d'Form déi Dir wëllt; zwee 200 heescht datt de Refuswee net wierklech duerchgesat gëtt.
Schreift de Rollback ier Dir en braucht: wéi en Erlaabneslëscht-Agang, benannt Kredential oder erausgäng Verbindung Dir geännert hutt, wien se besëtzt a wéi den virege Wäert restauréiert gëtt. Da schléisst de Krees andeems Dir am Ticket den Cloud-Uruffer an de komplette Serviceweg nennt, sou datt keen datselwecht Thema nach eng Kéier als VPN-Problem opmécht.