Apex-anrop utgår från Salesforce, inte från ditt VPN
Ett VPN på laptopen ger webbläsaren en väg, inte Apex eller Marketing Cloud. Matcha den verkliga anroparen mot en offentlig gateway eller en kvalificerad privat anslutning.
Det privata API:et svarar i webbläsaren i samma stund som laptopen ansluter till VPN:et, så integrationen borde fungera. Den fungerar inte, eftersom koden som gör anropet körs någon helt annanstans. Apex körs på Salesforces applikationsservrar, och en serversidig aktivitet i Marketing Cloud körs i den produktens körmiljö. Ingen av dem ärver din laptops tunnel. Gör detta som en kort procedur: identifiera anroparen, välj en ingång som den anroparen kan nå, koppla vägen hela vägen och verifiera sedan från själva körmiljön.
Skriv anroparkortet innan någon nätverksändring
Fyll i fem fält och vägra gissa något av dem. Körningsprodukten och kontexten avgör allt därefter, så börja där och inte vid serverns brandvägg.
| 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 webbläsarflik och ett Apex-anrop är två olika klienter, och en fungerande webbläsare bevisar bara att det finns en väg från ditt skrivbord. Om körmiljöfältet säger Apex är den relevanta frågan vilka adresser Salesforce går ut från, inte vilka adresser din laptop har. Därför kan en tunnel som får API:et att laddas i en webbläsare lämna integrationen felande med samma tidsgräns som tidigare. Anroparkortet finns för att stoppa det misstaget innan någon redigerar en brandvägg.
Välj den ingång som anroparen faktiskt kan använda
Båda designerna är legitima och löser olika problem. Den första är en avsiktlig offentlig ingång: en HTTPS API-gateway eller integrationstjänst som autentiserar anroparen, tillämpar snäva behörigheter och håller en skyddad anslutning till det privata backendet. Det är inte samma sak som att exponera varje backend-tjänst eller vidarebefordra en administrationsport till internet.
Den andra är en kvalificerad privat anslutning. Salesforces dokumentation för utgående Private Connect beskriver routning av stödda anrop genom en Outbound Network Connection bunden till en namngiven credential, över dess definierade AWS PrivateLink-upplägg. Funktionen har begränsningar i utgåva, licens och produkt, så bekräfta att organisationen kvalificerar innan du designar kring den.
Ingen av designerna är en OpenVPN-klient installerad inne i Salesforce, och det äldre påståendet att varje integration måste nå ett offentligt backend är för brett där en stödd privat anslutning passar. Välj den som körmiljön stöder och slutför sedan vägen till det riktiga API:et: en AWS-endpunkt känner inte till din lokala resurs och ärver inte din laptops rutt. DNS, backend-routning, åtkomstpolicy och svarstrafik måste alla följa den arkitektur du valde. En halvfärdig privat väg misslyckas på ett sätt som ser precis ut som ett autentiseringsproblem.
Koppla den privata vägen hela vägen
Arbeta utåt från API:et och stanna vid första gapet. Bekräfta att backendet svarar lokalt, sedan att den privata slutpunkten når det, och sedan att den namngivna credentialen och dess utgående anslutning riktar sig mot den slutpunkten.
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 integrationDet första kommandot bevisar att backendet är friskt inifrån det privata nätet, det andra visar vad namnet löses till, och det tredje utför ett anrop från den riktiga Salesforce-körmiljön. En 200 från det första och ett fel från det tredje isolerar gapet till vägen eller credentialen snarare än tjänsten.
Håll identitetens omfattning exakt när du kopplar. En namngiven credential reparerar inte en onåbar slutpunkt på egen hand, eftersom credentialen och den privata anslutningen är besläktade inställningar med separata uppgifter. En IP-tillåtelselista minskar nätverksintaget och är inte en API-credential, så behåll normal TLS-validering och tjänstens egen autentisering och rotation. Om ett test bara lyckas efter att du stängt av certifikatkontrollen har du hittat ett värdnamnsproblem snarare än ett vägproblem, och certifikatet måste fortfarande stämma.
Verifiera från körmiljön och registrera sedan återställningen
Acceptera en ofarlig tillåten förfrågan från integrationens körmiljö, inte från din maskin. Registrera den observerade källan hos tjänsten som tar emot, den autentiserade principalen, resultatet och en medvetet nekad förfrågan som måste misslyckas.
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/pingKör samma två prober från backendets eget nätverk så att den observerade källan kan jämföras med det körmiljön producerade. En 200 följd av 401 eller 403 är formen du vill ha; två 200 betyder att nekandevägen inte faktiskt upprätthålls.
Skriv återställningen innan du behöver den: vilken tillåtelselistepost, namngiven credential eller utgående anslutning du ändrade, vem som äger den och hur det tidigare värdet återställs. Stäng sedan loopen genom att namnge molnanroparen och hela tjänstevägen i ärendet, så att ingen öppnar samma sak igen som ett VPN-problem.