Apelurile Apex pleacă din Salesforce, nu din VPN-ul tău
Un VPN pe laptop dă browserului o cale, nu lui Apex sau Marketing Cloud. Potrivește apelantul real cu o poartă publică sau cu o conexiune privată calificată.
API-ul privat răspunde în browser în momentul în care laptopul se alătură VPN-ului, deci integrarea ar trebui să funcționeze. Nu funcționează, pentru că codul care face apelul rulează cu totul altundeva. Apex rulează pe serverele de aplicații ale Salesforce, iar o activitate din partea serverului în Marketing Cloud rulează în runtime-ul acelui produs. Niciuna nu moștenește tunelul laptopului tău. Tratează asta ca o procedură scurtă: identifică apelantul, alege o intrare la care acel apelant poate ajunge, leagă calea de la un capăt la altul, apoi verifică din runtime-ul însuși.
Scrie fișa apelantului înainte de orice modificare de rețea
Completează cinci câmpuri și refuză să ghicești vreunul. Produsul de execuție și contextul decid tot restul, așa că începe de acolo, nu de la firewall-ul serverului.
| 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? |
Un tab de browser și un apel Apex sunt doi clienți diferiți, iar un browser funcțional dovedește doar că există o cale de la biroul tău. Dacă câmpul runtime spune Apex, întrebarea relevantă este din ce adrese iese Salesforce, nu ce adrese are laptopul tău. De aceea un tunel care face API-ul să se încarce în browser poate lăsa integrarea să eșueze cu același timeout ca înainte. Fișa apelantului există pentru a opri această greșeală înainte ca cineva să editeze un firewall.
Alege intrarea pe care apelantul o poate folosi cu adevărat
Ambele variante sunt legitime și rezolvă probleme diferite. Prima este o intrare publică deliberată: o poartă API prin HTTPS sau un serviciu de integrare care autentifică apelantul, aplică permisiuni înguste și menține o conexiune protejată către backendul privat. Asta nu este același lucru cu a expune fiecare serviciu din backend sau a redirecționa un port de administrare către internet.
A doua este o conexiune privată calificată. Documentația Private Connect pentru trafic ieșit a Salesforce descrie rutarea apelurilor acceptate printr-o Outbound Network Connection legată de o acreditare cu nume, conform aranjamentului AWS PrivateLink definit. Funcția are restricții de ediție, licență și produs, așa că verifică dacă organizația se califică înainte de a proiecta în jurul ei.
Niciuna dintre variante nu este un client OpenVPN instalat în interiorul Salesforce, iar afirmația mai veche că fiecare integrare trebuie să ajungă la un backend public este prea largă acolo unde se potrivește o conexiune privată acceptată. Alege-o pe cea pe care o acceptă runtime-ul și apoi finalizează calea până la API-ul real: un endpoint AWS nu cunoaște resursa ta locală și nu moștenește ruta laptopului. DNS-ul, rutarea backendului, politica de acces și traficul de răspuns trebuie toate să urmeze arhitectura pe care ai ales-o. O cale privată pe jumătate construită eșuează exact ca o problemă de autentificare.
Leagă calea privată de la un capăt la altul
Lucrează de la API spre exterior și oprește-te la prima lipsă. Confirmă că backendul răspunde local, apoi că endpointul privat ajunge la el, apoi că acreditarea cu nume și conexiunea ei ieșită țintesc acel 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 integrationPrima comandă dovedește că backendul este sănătos din interiorul rețelei private, a doua arată în ce se rezolvă numele, iar a treia execută un apel din runtime-ul real Salesforce. Un 200 de la prima și un eșec de la a treia izolează lipsa în cale sau în acreditare, nu în serviciu.
Păstrează precis domeniul identității în timp ce legi. O acreditare cu nume nu repară singură un endpoint inaccesibil, pentru că acreditarea și conexiunea privată sunt setări înrudite cu sarcini separate. O listă de IP-uri permise îngustează admiterea în rețea și nu este o acreditare API, așa că păstrează validarea TLS normală și procesul propriu de autentificare și rotație al serviciului. Dacă un test trece doar după ce dezactivezi verificarea certificatului, ai găsit o problemă de nume de gazdă, nu de cale, iar certificatul tot trebuie să corespundă.
Verifică din runtime, apoi înregistrează revenirea
Acceptă o cerere permisă și inofensivă din runtime-ul integrării, nu de pe mașina ta. Înregistrează sursa observată de serviciul care primește, principalul autentificat, rezultatul și o cerere refuzată intenționat care trebuie să eșueze.
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/pingRulează aceleași două sondări din rețeaua backendului însuși, ca sursa observată să poată fi comparată cu ce a produs runtime-ul. Un 200 urmat de 401 sau 403 este forma dorită; două 200 înseamnă că calea de refuz nu este chiar aplicată.
Scrie revenirea înainte de a avea nevoie de ea: ce intrare din lista de permise, acreditare cu nume sau conexiune ieșită ai modificat, cine o deține și cum se restaurează valoarea anterioară. Apoi închide bucla numind în tichet apelantul din cloud și calea completă a serviciului, ca nimeni să nu redeschidă aceeași problemă ca problemă de VPN.