Apex-kall går ut fra Salesforce, ikke fra VPN-en din
En VPN på laptopen gir nettleseren en vei, ikke Apex eller Marketing Cloud. Match den faktiske kalleparten mot en offentlig gateway eller en kvalifisert privat forbindelse.
Den private API-en svarer i nettleseren din i det laptopen kobler seg til VPN-en, så integrasjonen burde fungere. Den fungerer 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 kjøremiljøet til det produktet. Ingen av dem arver tunnelen til laptopen din. Gjør dette som en kort prosedyre: identifiser innringeren, velg en inngang som den innringeren kan nå, koble veien ende-til-ende, og verifiser deretter fra selve kjøremiljøet.
Skriv innringerkortet før noen nettverksendring
Fyll ut fem felt og nekt å gjette på noen av dem. Utførelsesproduktet og konteksten bestemmer 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 forskjellige klienter, og en fungerende nettleser beviser bare at det finnes en vei fra skrivebordet ditt. Hvis kjøremiljøfeltet 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-et til å laste i en nettleser, la integrasjonen feile med samme tidsavbrudd som før. Innringerkortet finnes for å stoppe den feilen før noen redigerer en brannmur.
Velg inngangen innringeren faktisk kan bruke
Begge designene er legitime, og de løser forskjellige problemer. Det første er en bevisst offentlig inngang: en HTTPS API-gateway eller en integrasjonstjeneste som autentiserer innringeren, bruker trange 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 forbindelse. Salesforces dokumentasjon for utgående Private Connect beskriver ruting av støttede kall gjennom en Outbound Network Connection knyttet til en navngitt credential, over den definerte AWS PrivateLink-ordningen. 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 vid der en støttet privat forbindelse passer. Velg den kjøremiljø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-et 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øremiljøet. En 200 fra den første og en feil fra den tredje isolerer hullet til veien eller credentialen fremfor tjenesten.
Hold identitetens omfang presist mens du kobler. En navngitt credential reparerer ikke et utilgjengelig endepunkt alene, fordi credentialen og den private forbindelsen 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 fremfor et veiproblem, og sertifikatet må fortsatt stemme.
Verifiser fra kjøremiljøet, og registrer deretter tilbakerullingen
Godta en ufarlig tillatt forespørsel fra integrasjonens kjøremiljø, 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øremiljø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 forbindelse du endret, hvem som eier den, og hvordan den forrige verdien gjenopprettes. Lukk deretter løkken ved å navngi skyllekalleparten og hele tjenesteveien i saken, slik at ingen åpner samme sak på nytt som et VPN-problem.