Callout Apex keluar dari Salesforce, bukan dari VPN anda
VPN pada komputer riba memberi laluan kepada pelayar anda, bukan kepada Apex atau Marketing Cloud. Padankan pemanggil sebenar dengan gateway awam atau sambungan peribadi yang layak.
API peribadi menjawab dalam pelayar anda sebaik sahaja komputer riba menyertai VPN, jadi integrasi sepatutnya berfungsi. Ia tidak berfungsi, kerana kod yang membuat callout berjalan di tempat lain sepenuhnya. Apex berjalan pada pelayan aplikasi Salesforce, dan aktiviti sebelah pelayan Marketing Cloud berjalan dalam runtime produk itu. Kedua-duanya tidak mewarisi terowong komputer riba anda. Lakukan ini sebagai prosedur ringkas: kenal pasti pemanggil, pilih pintu masuk yang boleh dicapai pemanggil itu, sambungkan laluan dari hujung ke hujung, kemudian sahkan dari runtime itu sendiri.
Tulis kad pemanggil sebelum sebarang perubahan rangkaian
Isi lima medan dan enggan meneka mana-mana daripadanya. Produk pelaksanaan dan konteks menentukan segala-galanya selepas itu, jadi mulakan di situ dan bukan di tembok api pelayan.
| 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? |
Tab pelayar dan callout Apex ialah dua klien berbeza, dan pelayar yang berfungsi hanya membuktikan bahawa ada laluan dari meja anda. Jika medan runtime menyebut Apex, soalan yang relevan ialah dari alamat mana Salesforce keluar, bukan alamat mana yang ada pada komputer riba anda. Itulah sebabnya terowong yang membuat API dimuatkan dalam pelayar boleh membiarkan integrasi gagal dengan tamat masa yang sama seperti sebelum ini. Kad pemanggil wujud untuk menghentikan kesilapan itu sebelum sesiapa menyunting tembok api.
Pilih pintu masuk yang benar-benar boleh digunakan pemanggil
Kedua-dua reka bentuk sah, dan kedua-duanya menyelesaikan masalah yang berbeza. Yang pertama ialah pintu masuk awam yang disengajakan: gateway API HTTPS atau perkhidmatan integrasi yang mengesahkan pemanggil, menggunakan kebenaran yang sempit dan mengekalkan sambungan terlindung ke backend peribadi. Itu tidak sama dengan mendedahkan setiap perkhidmatan backend atau memajukan port pengurusan ke internet.
Yang kedua ialah sambungan peribadi yang layak. Dokumentasi Private Connect keluar Salesforce menerangkan penghalaan callout yang disokong melalui Outbound Network Connection yang terikat pada kelayakan bernama, mengikut susunan AWS PrivateLink yang ditetapkan. Ciri ini mempunyai kekangan edisi, lesen dan produk, jadi sahkan organisasi layak sebelum mereka bentuk berdasarkannya.
Tiada satu pun reka bentuk itu ialah klien OpenVPN yang dipasang di dalam Salesforce, dan dakwaan lama bahawa setiap integrasi mesti mencapai backend awam terlalu luas di mana sambungan peribadi yang disokong sesuai. Pilih yang disokong runtime, kemudian lengkapkan laluan ke API sebenar: titik akhir AWS tidak mengenali sumber tempatan anda dan tidak mewarisi laluan komputer riba anda. DNS, penghalaan backend, dasar akses dan trafik balasan semuanya mesti mengikut seni bina yang anda pilih. Laluan peribadi yang separuh dibina gagal dengan cara yang kelihatan tepat seperti masalah pengesahan.
Sambungkan laluan peribadi dari hujung ke hujung
Bekerja keluar dari API dan berhenti pada jurang pertama. Sahkan bahawa backend menjawab secara tempatan, kemudian bahawa titik akhir peribadi mencapainya, kemudian bahawa kelayakan bernama dan sambungan keluarnya menyasarkan titik akhir itu.
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 integrationPerintah pertama membuktikan backend sihat dari dalam rangkaian peribadi, yang kedua menunjukkan apa nama itu diselesaikan, dan yang ketiga melaksanakan callout dari runtime Salesforce sebenar. 200 daripada yang pertama dan kegagalan daripada yang ketiga mengasingkan jurang kepada laluan atau kelayakan, bukan perkhidmatan.
Kekalkan skop identiti dengan tepat semasa menyambung. Kelayakan bernama tidak membaiki titik akhir yang tidak dapat dicapai dengan sendirinya, kerana kelayakan dan sambungan peribadi ialah tetapan berkaitan dengan tugas berasingan. Senarai IP yang dibenarkan menyempitkan kemasukan rangkaian dan bukan kelayakan API, jadi kekalkan pengesahan TLS biasa serta proses pengesahan dan putaran perkhidmatan itu sendiri. Jika ujian hanya lulus selepas anda mematikan pemeriksaan sijil, anda telah menemui masalah nama hos dan bukan masalah laluan, dan sijil masih perlu sepadan.
Sahkan dari runtime, kemudian rekod pengunduran
Terima permintaan dibenarkan yang tidak berbahaya dari runtime integrasi, bukan dari mesin anda. Rekodkan sumber yang diperhatikan oleh perkhidmatan penerima, prinsipal yang disahkan, hasilnya, dan satu permintaan yang sengaja ditolak yang mesti gagal.
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/pingJalankan dua probe yang sama dari rangkaian backend itu sendiri supaya sumber yang diperhatikan boleh dibandingkan dengan apa yang dihasilkan runtime. 200 diikuti 401 atau 403 ialah bentuk yang anda mahu; dua 200 bermakna laluan penolakan tidak benar-benar dikuatkuasakan.
Tulis pengunduran sebelum anda memerlukannya: entri senarai dibenarkan, kelayakan bernama atau sambungan keluar mana yang anda ubah, siapa pemiliknya dan cara memulihkan nilai sebelumnya. Kemudian tutup gelung dengan menamakan pemanggil awan dan laluan perkhidmatan lengkap dalam tiket, supaya tiada siapa membuka semula isu yang sama sebagai masalah VPN.