Le callout Apex partono da Salesforce, non dalla tua VPN

L'API privata risponde nel browser nel momento in cui il portatile entra nella VPN, quindi l'integrazione dovrebbe funzionare. Non funziona, perché il codice che esegue la callout gira altrove, del tutto. Apex viene eseguito sui server applicativi di Salesforce, e un'attività lato server di Marketing Cloud viene eseguita nel runtime di quel prodotto. Nessuno dei due eredita il tunnel del tuo portatile. Procedi come una breve procedura: identifica il chiamante, scegli un ingresso che quel chiamante può raggiungere, collega il percorso da un capo all'altro, poi verifica dal runtime stesso.

Scrivi la scheda del chiamante prima di qualsiasi modifica di rete

Compila cinque campi e rifiutati di indovinarne uno. Il prodotto di esecuzione e il contesto decidono tutto il resto, quindi parti da lì e non dal firewall del server.

Una scheda del browser e una callout Apex sono due client diversi, e un browser funzionante dimostra solo che esiste un percorso dalla tua scrivania. Se il campo del runtime dice Apex, la domanda pertinente è da quali indirizzi esce Salesforce, non quali indirizzi ha il tuo portatile. Per questo un tunnel che fa caricare l'API nel browser può lasciare l'integrazione in errore con lo stesso timeout di prima. La scheda del chiamante esiste per fermare quell'errore prima che qualcuno modifichi un firewall.

Scegli l'ingresso che il chiamante può davvero usare

Entrambi i progetti sono legittimi e risolvono problemi diversi. Il primo è un ingresso pubblico deliberato: un gateway API HTTPS o un servizio di integrazione che autentica il chiamante, applica autorizzazioni ristrette e mantiene una connessione protetta verso il backend privato. Non è lo stesso che esporre ogni servizio del backend o inoltrare una porta di gestione su internet.

Il secondo è una connessione privata qualificata. La documentazione Private Connect in uscita di Salesforce descrive l'instradamento delle callout supportate tramite una Outbound Network Connection legata a una credenziale con nome, secondo la sua disposizione AWS PrivateLink definita. La funzione ha vincoli di edizione, licenza e prodotto, quindi conferma che l'organizzazione ne abbia i requisiti prima di progettare su di essa.

Nessuno dei due progetti è un client OpenVPN installato dentro Salesforce, e la vecchia affermazione che ogni integrazione debba raggiungere un backend pubblico è troppo ampia dove serve una connessione privata supportata. Scegli quella che il runtime supporta, poi completa il percorso verso l'API reale: un endpoint AWS non conosce la tua risorsa locale e non eredita la route del tuo portatile. DNS, instradamento del backend, criteri di accesso e traffico di risposta devono tutti seguire l'architettura che hai scelto. Un percorso privato costruito a metà fallisce in un modo che sembra esattamente un problema di autenticazione.

Collega il percorso privato da un capo all'altro

Lavora dall'API verso l'esterno e fermati al primo vuoto. Conferma che il backend risponda in locale, poi che l'endpoint privato lo raggiunga, poi che la credenziale con nome e la sua connessione in uscita puntino a quell'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 integration

Il primo comando dimostra che il backend è sano dall'interno della rete privata, il secondo mostra a cosa risolve il nome, e il terzo esegue una callout dal runtime reale di Salesforce. Un 200 dal primo e un errore dal terzo isolano il vuoto nel percorso o nella credenziale, non nel servizio.

Mantieni preciso l'ambito dell'identità mentre colleghi. Una credenziale con nome non ripara da sola un endpoint irraggiungibile, perché la credenziale e la connessione privata sono impostazioni correlate con compiti separati. Un elenco di IP autorizzati restringe l'ammissione di rete e non è una credenziale API, quindi conserva la normale validazione TLS e il processo di autenticazione e rotazione proprio del servizio. Se un test passa solo dopo aver disattivato il controllo del certificato, hai trovato un problema di nome host e non di percorso, e il certificato deve comunque corrispondere.

Verifica dal runtime, poi registra il rollback

Accetta una richiesta permessa e innocua dal runtime dell'integrazione, non dalla tua macchina. Registra l'origine osservata dal servizio ricevente, il principal autenticato, il risultato e una richiesta deliberatamente negata che deve fallire.

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/ping

Esegui le stesse due sonde dalla rete del backend stesso, così l'origine osservata può essere confrontata con quella prodotta dal runtime. Un 200 seguito da un 401 o un 403 è la forma che vuoi; due 200 significano che il percorso di rifiuto non è davvero applicato.

Scrivi il rollback prima di averne bisogno: quale voce dell'elenco autorizzato, credenziale con nome o connessione in uscita hai cambiato, chi la possiede e come ripristinare il valore precedente. Poi chiudi il cerchio nominando nel ticket il chiamante cloud e il percorso di servizio completo, perché nessuno riapra lo stesso problema come problema di VPN.