Apex iškvietimai išeina iš Salesforce, o ne iš jūsų VPN
Nešiojamojo kompiuterio VPN suteikia jūsų naršyklei kelią, o ne Apex ar Marketing Cloud. Suderinkite tikrąjį iškvietėją su viešaisiais vartais arba kvalifikuotu privačiu ryšiu.
Privatusis API atsako jūsų naršyklėje tą akimirką, kai nešiojamasis kompiuteris prisijungia prie VPN, tad integracija turėtų veikti. Ji neveikia, nes kodas, atliekantis iškvietimą, vykdomas visai kitoje vietoje. Apex vykdomas Salesforce programų serveriuose, o Marketing Cloud serverio pusės veikla – to produkto vykdymo aplinkoje. Nė vienas iš jų nepaveldi jūsų nešiojamojo kompiuterio tunelio. Atlikite tai kaip trumpą procedūrą: nustatykite iškvietėją, pasirinkite įėjimą, kurį tas iškvietėjas gali pasiekti, sujunkite kelią nuo pradžios iki galo ir tada patikrinkite iš pačios vykdymo aplinkos.
Parašykite iškvietėjo kortelę prieš bet kokį tinklo pakeitimą
Užpildykite penkis laukus ir atsisakykite nors vieną jų spėlioti. Vykdymo produktas ir kontekstas lemia visa kita, todėl pradėkite nuo jų, o ne nuo serverio užkardos.
| 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? |
Naršyklės skirtukas ir Apex iškvietimas yra du skirtingi klientai, o veikianti naršyklė įrodo tik tai, kad kelias egzistuoja nuo jūsų darbo stalo. Jei vykdymo aplinkos laukas sako Apex, aktualus klausimas yra iš kurių adresų Salesforce išeina, o ne kokius adresus turi jūsų nešiojamasis kompiuteris. Todėl tunelis, leidžiantis API įsikelti naršyklėje, gali palikti integraciją nepavykusią su ta pačia laukimo trukme kaip anksčiau. Iškvietėjo kortelė egzistuoja tam, kad sustabdytų šią klaidą prieš kam nors keičiant užkardą.
Pasirinkite įėjimą, kurį iškvietėjas tikrai gali naudoti
Abu sprendimai yra teisėti ir sprendžia skirtingas problemas. Pirmasis yra sąmoningas viešas įėjimas: HTTPS API vartai arba integracijos paslauga, kuri autentifikuoja iškvietėją, taiko siaurus leidimus ir palaiko apsaugotą ryšį su privačiu backend. Tai nėra tas pats, kas atverti kiekvieną backend paslaugą arba persiųsti valdymo prievadą į internetą.
Antrasis yra kvalifikuotas privatus ryšys. Salesforce išeinančio Private Connect dokumentacija aprašo palaikomų iškvietimų maršrutizavimą per Outbound Network Connection, susietą su įvardytu prisijungimo duomeniu, pagal apibrėžtą AWS PrivateLink išdėstymą. Funkcija turi leidimo, licencijos ir produkto apribojimų, todėl prieš projektuodami aplink ją patvirtinkite, kad organizacija atitinka sąlygas.
Nė vienas sprendimas nėra Salesforce viduje įdiegtas OpenVPN klientas, o senesnis teiginys, kad kiekviena integracija turi pasiekti viešą backend, yra per platus ten, kur tinka palaikomas privatus ryšys. Pasirinkite tą, kurį palaiko vykdymo aplinka, tada užbaikite kelią iki tikrojo API: AWS galinis taškas nepažįsta jūsų vietinio ištekliaus ir nepaveldi jūsų nešiojamojo kompiuterio maršruto. DNS, backend maršrutizavimas, prieigos politika ir atsakymo srautas turi sekti jūsų pasirinktą architektūrą. Pusiau pastatytas privatus kelias nepavyksta taip, kad atrodo lygiai kaip autentifikavimo problema.
Sujunkite privatų kelią nuo pradžios iki galo
Dirbkite nuo API į išorę ir sustokite prie pirmos spragos. Patvirtinkite, kad backend atsako vietoje, tada kad privatusis galinis taškas jį pasiekia, o paskui kad įvardytas prisijungimo duomuo ir jo išeinantis ryšys nukreipti į tą galinį tašką.
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 integrationPirmoji komanda įrodo, kad backend sveikas iš privačiojo tinklo vidaus, antroji parodo, į ką rezoliuojamas vardas, o trečioji atlieka iškvietimą iš tikrosios Salesforce vykdymo aplinkos. 200 iš pirmosios ir nesėkmė iš trečiosios izoliuoja spragą į kelią arba prisijungimo duomenį, o ne į paslaugą.
Išlaikykite tikslią tapatybės apimtį jungdami. Įvardytas prisijungimo duomuo pats nepataiso nepasiekiamo galinio taško, nes prisijungimo duomuo ir privatus ryšys yra susiję nustatymai su atskiromis užduotimis. IP leidžiamųjų sąrašas susiaurina tinklo priėmimą ir nėra API prisijungimo duomuo, todėl išlaikykite įprastą TLS validaciją ir paslaugos pačios autentifikavimo bei rotacijos procesą. Jei testas praeina tik išjungus sertifikato tikrinimą, radote prieglobsčio vardo problemą, o ne kelio problemą, ir sertifikatas vis tiek turi atitikti.
Patikrinkite iš vykdymo aplinkos, tada užfiksuokite atšaukimą
Priimkite nekenksmingą leistiną užklausą iš integracijos vykdymo aplinkos, o ne iš savo mašinos. Užfiksuokite priimančios paslaugos pastebėtą šaltinį, autentifikuotą subjektą, rezultatą ir vieną sąmoningai atmestą užklausą, kuri turi nepavykti.
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/pingPaleiskite tuos pačius du patikrinimus iš backend savo tinklo, kad pastebėtą šaltinį būtų galima palyginti su tuo, ką pagamino vykdymo aplinka. 200, po kurio seka 401 arba 403, yra norima forma; du 200 reiškia, kad atmetimo kelias faktiškai nevykdomas.
Parašykite atšaukimą prieš jam prireikus: kurią leidžiamųjų sąrašo eilutę, įvardytą prisijungimo duomenį ar išeinantį ryšį pakeitėte, kam jis priklauso ir kaip atkurti ankstesnę reikšmę. Tada uždarykite ratą biliete įvardydami debesies iškvietėją ir visą paslaugos kelią, kad niekas nebeatidarytų tos pačios problemos kaip VPN problemos.