Apex-kald udgår fra Salesforce, ikke fra din VPN
En VPN på laptop giver din browser en vej, ikke Apex eller Marketing Cloud. Match den rigtige kalder med en offentlig gateway eller en kvalificeret privat forbindelse.
Den private API svarer i din browser i det øjeblik, laptoppen kobler på VPN'en, så integrationen burde virke. Den virker ikke, fordi koden, der laver kaldet, kører et helt andet sted. Apex kører på Salesforces applikationsservere, og en serversideaktivitet i Marketing Cloud kører i det produkts runtime. Ingen af dem arver din laptops tunnel. Kør det som en kort procedure: identificér kalderen, vælg en indgang, som den kalder kan nå, kobl stien end-to-end, og verificér derefter fra selve runtime.
Skriv kalderkortet, før du ændrer noget i netværket
Udfyld fem felter, og nægt at gætte på nogen af dem. Eksekveringsproduktet og konteksten afgør alt nedstrøms, så start der i stedet for ved serverens firewall.
| 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 browservinduesfane og et Apex-kald er to forskellige klienter, og en browser, der virker, beviser kun, at der findes en vej fra dit skrivebord. Hvis runtime-feltet siger Apex, er det relevante spørgsmål, hvilke adresser Salesforce udgår fra, ikke hvilke adresser din laptop har. Derfor kan en tunnel, der får API'en til at loade i en browser, efterlade integrationen fejlende med samme timeout som før. Kalderkortet findes for at standse den fejl, før nogen redigerer en firewall.
Vælg den indgang, kalderen faktisk kan bruge
To designs er legitime, og de løser forskellige problemer. Det første er en bevidst offentlig indgang: en HTTPS API-gateway eller integrationstjeneste, der autentificerer kalderen, anvender snævre tilladelser og holder en beskyttet forbindelse til det private backend. Det er ikke det samme som at eksponere hver backend-tjeneste eller videresende en administrationsport til internettet.
Det andet er en kvalificeret privat forbindelse. Salesforces dokumentation for udgående Private Connect beskriver routing af understøttede kald gennem en Outbound Network Connection bundet til en navngivet credential, over dens definerede AWS PrivateLink-arrangement. Funktionen har begrænsninger i edition, licens og produkt, så bekræft, at organisationen er kvalificeret, før du designer ud fra den.
Ingen af designene er en OpenVPN-klient installeret inde i Salesforce, og den ældre påstand om, at enhver integration skal nå et offentligt backend, er for bred, hvor en understøttet privat forbindelse passer. Vælg den, som runtime understøtter, og færdiggør derefter stien til den rigtige API: et AWS-endpoint kender ikke din lokale ressource og arver ikke din laptops rute. DNS, backend-routing, adgangspolitik og svartrafik skal alle følge den arkitektur, du valgte. En halvfærdig privat sti fejler på en måde, der ser præcis ud som et autentificeringsproblem.
Kobl den private sti end-to-end
Arbejd udad fra API'en, og stop ved det første hul. Bekræft, at backend svarer lokalt, bekræft derefter, at det private endpoint når det, og bekræft så, at den navngivne credential og dens udgående forbindelse peger på det endpoint.
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 kommando beviser, at backend er sundt indefra det private netværk, den anden viser, hvad navnet opløses til, og den tredje udfører et kald fra den faktiske Salesforce-runtime. Et 200 fra den første og en fejl fra den tredje isolerer hullet til stien eller credentialen frem for tjenesten.
Hold identitetens omfang præcist, mens du kobler. En navngivet credential reparerer ikke et utilgængeligt endpoint alene, fordi credentialen og den private forbindelse er beslægtede indstillinger med hver sin opgave. En IP-allowliste indsnævrer netværksadgang og er ikke en API-credential, så behold normal TLS-validering og tjenestens egen autentificering og rotation. Hvis en test kun lykkes, efter du har slået certifikatkontrol fra, har du fundet et hostname-problem frem for et sti-problem, og certifikatet skal stadig matche.
Verificér fra runtime, og registrér derefter tilbagerulningen
Accepter en uskadelig tilladt anmodning fra integrationens runtime, ikke fra din maskine. Registrér den modtagende tjenestes observerede kilde, den autentificerede principal, resultatet og én bevidst afvist anmodning, som skal fejle.
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 de samme to prober fra backendens eget netværk, så den observerede kilde kan sammenlignes med det, runtime producerede. Et 200 efterfulgt af et 401 eller 403 er den form, du vil have; to 200 betyder, at afvisningsstien ikke reelt håndhæves.
Skriv tilbagerulningen, før du får brug for den: hvilken allowliste-post, navngivet credential eller udgående forbindelse du ændrede, hvem der ejer den, og hvordan den tidligere værdi gendannes. Luk derefter cirklen ved at navngive cloud-kalderen og den fulde tjenestesti i billetten, så ingen genåbner samme sag som et VPN-problem.