Apex-kall går fra Salesforce, ikke fra VPN-en din
En VPN på laptopen gir nettleseren din en vei, ikke Apex eller Marketing Cloud. Koble den faktiske kalleparten til en offentlig gateway eller en kvalifisert privat tilkobling.
Den private API-en svarer i nettleseren din i det laptopen kobler seg på VPN-en, så integrasjonen burde virke. Den virker ikke, fordi koden som gjør kallet, kjører et helt annet sted. Apex kjører på Salesforces applikasjonsservere, og en serversideaktivitet i Marketing Cloud kjører i det produktets kjøretidsmiljø. Ingen av dem arver tunnelen til laptopen din. Kjør dette som en kort prosedyre: identifiser kalleparten, velg en inngang som den kalleparten kan nå, koble veien ende-til-ende, og verifiser deretter fra selve kjøretidsmiljøet.
Skriv kallepartkortet før noen nettverksendring
Fyll ut fem felt og nekt å gjette på noen av dem. Utførelsesproduktet og konteksten avgjør alt videre, så start der og ikke ved serverens brannmur.
| 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 nettleserfane og et Apex-kall er to ulike klienter, og en fungerende nettleser beviser bare at det finnes en vei fra skrivebordet ditt. Hvis kjøretidsfeltet sier Apex, er det relevante spørsmålet hvilke adresser Salesforce går ut fra, ikke hvilke adresser laptopen din har. Derfor kan en tunnel som får API-en til å laste i en nettleser, la integrasjonen feile med samme tidsavbrudd som før. Kallepartkortet finnes for å stoppe den feilen før noen redigerer en brannmur.
Velg inngangen kalleparten faktisk kan bruke
Begge designene er legitime, og de løser ulike problemer. Det første er en bevisst offentlig inngang: en HTTPS API-gateway eller en integrasjonstjeneste som autentiserer kalleparten, bruker snevre tillatelser og holder en beskyttet forbindelse til det private backendet. Det er ikke det samme som å eksponere hver backend-tjeneste eller videresende en administrasjonsport til internett.
Det andre er en kvalifisert privat tilkobling. Salesforces dokumentasjon for utgående Private Connect beskriver ruting av støttede kall gjennom en Outbound Network Connection bundet til en navngitt credential, over dens definerte AWS PrivateLink-oppsett. Funksjonen har begrensninger på utgave, lisens og produkt, så bekreft at organisasjonen kvalifiserer før du designer rundt den.
Ingen av designene er en OpenVPN-klient installert inne i Salesforce, og den eldre påstanden om at enhver integrasjon må nå et offentlig backend, er for bred der en støttet privat tilkobling passer. Velg den kjøretidsmiljøet støtter, og fullfør deretter veien til det virkelige API-et: et AWS-endepunkt kjenner ikke den lokale ressursen din og arver ikke ruten til laptopen din. DNS, backend-ruting, tilgangspolicy og svartrafikk må alle følge arkitekturen du valgte. En halvferdig privat vei feiler på en måte som ser nøyaktig ut som et autentiseringsproblem.
Koble den private veien ende-til-ende
Arbeid utover fra API-en og stopp ved første hull. Bekreft at backendet svarer lokalt, deretter at det private endepunktet når det, og så at den navngitte credentialen og dens utgående forbindelse peker på det endepunktet.
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 første kommandoen beviser at backendet er friskt innenfra det private nettverket, den andre viser hva navnet løses til, og den tredje utfører et kall fra det virkelige Salesforce-kjøretidsmiljøet. En 200 fra den første og en feil fra den tredje isolerer hullet til veien eller credentialen framfor tjenesten.
Hold identitetens omfang presist mens du kobler. En navngitt credential reparerer ikke et utilgjengelig endepunkt alene, fordi credentialen og den private tilkoblingen er beslektede innstillinger med hver sin oppgave. En IP-tillatelsesliste snevrer inn nettverkstilgang og er ikke en API-credential, så behold vanlig TLS-validering og tjenestens egen autentisering og rotasjon. Hvis en test bare lykkes etter at du slår av sertifikatkontrollen, har du funnet et vertsnavnproblem framfor et veiproblem, og sertifikatet må fortsatt stemme.
Verifiser fra kjøretidsmiljøet, og registrer deretter tilbakerullingen
Godta en ufarlig tillatt forespørsel fra integrasjonens kjøretidsmiljø, ikke fra maskinen din. Registrer den observerte kilden til tjenesten som mottar, den autentiserte principalen, resultatet og én bevisst avvist forespørsel som må feile.
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/pingKjør de samme to prøvene fra backendets eget nettverk slik at den observerte kilden kan sammenlignes med det kjøretidsmiljøet produserte. En 200 etterfulgt av 401 eller 403 er formen du vil ha; to 200 betyr at avvisningsveien ikke faktisk håndheves.
Skriv tilbakerullingen før du trenger den: hvilken tillatelseslistepost, navngitt credential eller utgående tilkobling du endret, hvem som eier den, og hvordan den forrige verdien gjenopprettes. Lukk deretter løkken ved å navngi skykalleparten og hele tjenesteveien i saken, slik at ingen åpner samme sak på nytt som et VPN-problem.