Apex-callouts geane fan Salesforce út, net fan jo VPN
In laptop-VPN jout jo browser in paad, net Apex of Marketing Cloud. Koppelje de echte oanropper oan in iepenbiere gateway of in kwalifisearre privee-ferbining.
De privee-API antwurdet yn jo browser op it stuit dat de laptop by de VPN komt, dus de yntegraasje soe wurkje moatte. Dat docht er net, want de koade dy't de oprop docht, rint hielendal earne oars. Apex rint op de applikaasjeservers fan Salesforce, en in serverside-aktiviteit yn Marketing Cloud rint yn de runtime fan dat produkt. Gjin fan beide erft de tunnel fan jo laptop. Doch dit as in koarte proseduere: identifisearje de oanropper, kies in yngong dy't dy oanropper berikke kin, ferbyn it paad fan begjin oant ein, en ferifiearje dan út de runtime sels.
Skriuw de oanropperkaart foardat jo wat oan it netwurk feroarje
Folje fiif fjilden yn en wegerje ien fan har te rieden. It útfierprodukt en de kontekst bepale alles wat folget, dus begjin dêr en net by de firewall fan de 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? |
In browser-tab en in Apex-callout binne twa ferskillende kliïnten, en in wurkjende browser bewiist allinnich dat der in paad fan jo buro is. As it runtime-fjild Apex seit, is de relevante fraach fan hokker adressen Salesforce útkomt, net hokker adressen jo laptop hat. Dêrom kin in tunnel dy't de API yn in browser lade lit, de yntegraasje mislearje litte mei deselde timeout as earder. De oanropperkaart bestiet om dy flater te stopjen foardat immen in firewall bewurket.
Kies de yngong dy't de oanropper echt brûke kin
Beide ûntwerpen binne legit, en se lossen ferskillende problemen op. It earste is in bewuste iepenbiere yngong: in HTTPS-API-gateway of in yntegraasjetsjinst dy't de oanropper autentisearret, smelle foech tapast en in beskerme ferbining mei it privee backend hâldt. Dat is net itselde as elke backend-tsjinst bleatstelle of in behearspoarte nei it internet trochstjoere.
It twadde is in kwalifisearre privee-ferbining. De dokumintaasje fan Salesforce oer útgeande Private Connect beskriuwt it rûtelearjen fan stipe callouts troch in Outbound Network Connection bûn oan in neamde credential, oer de fêststelde AWS PrivateLink-opstelling. De funksje hat beheiningen foar edysje, lisinsje en produkt, dus befêstigje dat de organisaasje foldocht foardat jo deromhinne ûntwerpe.
Gjin fan beide ûntwerpen is in OpenVPN-kliïnt ynstallearre yn Salesforce, en de âldere bewearing dat elke yntegraasje in iepenbier backend berikke moat, is te breed wêr't in stipe privee-ferbining past. Kies dejinge dy't de runtime stipet en meitsje dan it paad nei de echte API klear: in AWS-einpunt ken jo lokale boarne net en erft net de rûte fan jo laptop. DNS, backend-rûtelearring, tagongsbelied en antwurdferkear moatte allegear de arsjitektuer folgje dy't jo keazen hawwe. In healboude privee paad mislearret op in manier dy't der krekt as in autentikaasjeprobleem útsjocht.
Ferbyn it privee paad fan begjin oant ein
Wurkje fan de API nei bûten en stop by it earste gat. Befêstigje dat it backend lokaal antwurdet, dan dat it privee einpunt it berikt, en dan dat de neamde credential en syn útgeande ferbining dat einpunt as doel hawwe.
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 integrationIt earste kommando bewiist dat it backend sûn is fan binnen it privee netwurk, it twadde lit sjen wêr't de namme nei oplost, en it tredde fiert in callout út fan de echte Salesforce-runtime. In 200 fan it earste en in mislearring fan it tredde isolearje it gat nei it paad of de credential, net nei de tsjinst.
Hâld de omfang fan de identiteit presys wylst jo ferbine. In neamde credential reparearret net allinnich in ûnberikber einpunt, want de credential en de privee-ferbining binne besibbe ynstellings mei aparte taken. In IP-tolist ferlingt netwurkopname en is gjin API-credential, dus behâld normale TLS-falidaasje en it eigen autentikaasje- en rotaasjeproses fan de tsjinst. As in test allinnich slagget nei't jo de sertifikaatkontrôle útskeakele hawwe, hawwe jo in hostnamprobleem fûn ynstee fan in paadprobleem, en it sertifikaat moat noch altyd mate.
Ferifiearje út de runtime en skriuw dan de weromsetning op
Akseptearje in harmleas tastien fersyk fan de yntegraasje-runtime, net fan jo masine. Skriuw de waarnommen boarne fan de ûntfangende tsjinst op, de autentisearre prinsipaal, it resultaat en ien bewust wegere fersyk dat mislearje moat.
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/pingRun deselde twa probes fan it eigen netwurk fan it backend, sadat de waarnommen boarne fergelike wurde kin mei wat de runtime produsearre. In 200 folge troch in 401 of 403 is de foarm dy't jo wolle; twa 200's betsjutte dat it wegeringspaad net echt hanthavene wurdt.
Skriuw de weromsetning foardat jo dy nedich hawwe: hokker toelist-yngong, neamde credential of útgeande ferbining jo feroare hawwe, wa't dy besit en hoe't de foarige wearde werombrocht wurdt. Slút dan de sirkel troch de wolk-oanropper en it folsleine tsjinstpaad yn de ticket te neamen, sadat nimmen itselde kwestje wer as in VPN-probleem iepenet.