Les crides d'Apex surten de Salesforce, no del vostre VPN
Una VPN al portàtil dona un camí al navegador, no a Apex ni a Marketing Cloud. Feu coincidir el cridador real amb una passarel·la pública o una connexió privada qualificada.
L'API privada respon al navegador en el moment que el portàtil s'uneix a la VPN, així que la integració hauria de funcionar. No funciona, perquè el codi que fa la crida s'executa en un altre lloc ben diferent. Apex s'executa als servidors d'aplicacions de Salesforce, i una activitat del costat del servidor de Marketing Cloud s'executa al runtime d'aquell producte. Cap de les dues no hereta el túnel del vostre portàtil. Feu-ho com un procediment curt: identifiqueu el cridador, trieu una entrada que aquest cridador pugui assolir, connecteu el camí d'un extrem a l'altre i després verifiqueu-ho des del mateix runtime.
Escriviu la fitxa del cridador abans de qualsevol canvi de xarxa
Ompliu cinc camps i refuseu d'endevinar-ne cap. El producte d'execució i el context decideixen tot el que ve després, així que comenceu per aquí i no pel tallafoc del servidor.
| 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? |
Una pestanya del navegador i una crida d'Apex són dos clients diferents, i un navegador que funciona només demostra que hi ha un camí des del vostre escriptori. Si el camp del runtime diu Apex, la pregunta rellevant és de quines adreces surt Salesforce, no quines adreces té el vostre portàtil. Per això un túnel que fa carregar l'API al navegador pot deixar la integració fallant amb el mateix temps d'espera que abans. La fitxa del cridador existeix per aturar aquest error abans que algú editi un tallafoc.
Trieu l'entrada que el cridador pot fer servir de debò
Els dos dissenys són legítims i resolen problemes diferents. El primer és una entrada pública deliberada: una passarel·la d'API HTTPS o un servei d'integració que autentica el cridador, aplica permisos estrets i manté una connexió protegida amb el backend privat. Això no és el mateix que exposar tots els serveis del backend o reenviar un port de gestió a internet.
El segon és una connexió privada qualificada. La documentació de Private Connect sortint de Salesforce descriu com s'encaminen les crides admeses per una Outbound Network Connection lligada a una credencial amb nom, segons la seva disposició definida d'AWS PrivateLink. La funcionalitat té restriccions d'edició, llicència i producte, així que confirmeu que l'organització compleix els requisits abans de dissenyar-hi al voltant.
Cap dels dos dissenys no és un client OpenVPN instal·lat dins de Salesforce, i l'afirmació antiga que tota integració ha d'arribar a un backend públic és massa àmplia allà on encaixa una connexió privada admesa. Trieu la que el runtime admeti i després completeu el camí fins a l'API real: un punt de connexió d'AWS no coneix el vostre recurs local ni hereta la ruta del portàtil. El DNS, l'encaminament del backend, la política d'accés i el trànsit de resposta han de seguir l'arquitectura que heu triat. Un camí privat mig construït falla d'una manera que sembla exactament un problema d'autenticació.
Connecteu el camí privat d'un extrem a l'altre
Treballeu des de l'API cap enfora i atureu-vos al primer buit. Confirmeu que el backend respon en local, després que el punt de connexió privat hi arriba i, finalment, que la credencial amb nom i la seva connexió sortint apunten a aquest punt.
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 integrationLa primera ordre demostra que el backend és sa des de dins de la xarxa privada, la segona mostra a què resol el nom i la tercera executa una crida des del runtime real de Salesforce. Un 200 de la primera i un error de la tercera aïllen el buit al camí o a la credencial, no al servei.
Manteniu l'abast de la identitat precís mentre connecteu. Una credencial amb nom no arregla per si sola un punt de connexió inassolible, perquè la credencial i la connexió privada són paràmetres relacionats amb feines separades. Una llista d'adreces IP permeses estreny l'admissió de xarxa i no és una credencial d'API, així que conserveu la validació TLS normal i el procés propi d'autenticació i rotació del servei. Si una prova només passa després de desactivar la comprovació del certificat, heu trobat un problema de nom d'amfitrió i no de camí, i el certificat encara ha de coincidir.
Verifiqueu des del runtime i després enregistreu la reversió
Accepteu una petició permesa i innòcua des del runtime d'integració, no des de la vostra màquina. Enregistreu l'origen observat pel servei receptor, el principal autenticat, el resultat i una petició denegada expressament que ha de fallar.
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/pingExecuteu les mateixes dues proves des de la xarxa del propi backend perquè l'origen observat es pugui comparar amb el que va produir el runtime. Un 200 seguit d'un 401 o un 403 és la forma que voleu; dos 200 volen dir que el camí de denegació no s'aplica de veritat.
Escriviu la reversió abans de necessitar-la: quina entrada de la llista permesa, credencial amb nom o connexió sortint heu canviat, qui en és el propietari i com restaurar el valor anterior. Després tanqueu el cercle anomenant el cridador al núvol i el camí complet del servei al tiquet, perquè ningú no reobri el mateix assumpte com un problema de VPN.