Callout Apex keluar dari Salesforce, bukan dari VPN Anda
VPN di laptop memberi jalur bagi browser Anda, bukan bagi Apex atau Marketing Cloud. Cocokkan pemanggil sebenarnya dengan gateway publik atau koneksi privat yang memenuhi syarat.
API privat menjawab di browser Anda begitu laptop bergabung ke VPN, jadi integrasinya semestinya berhasil. Kenyataannya tidak, karena kode yang membuat callout berjalan di tempat yang sama sekali lain. Apex berjalan di server aplikasi Salesforce, dan aktivitas sisi server Marketing Cloud berjalan di runtime produk tersebut. Keduanya tidak mewarisi tunnel laptop Anda. Jalankan ini sebagai prosedur singkat: identifikasi pemanggil, pilih pintu masuk yang dapat dijangkau pemanggil itu, sambungkan jalur dari ujung ke ujung, lalu verifikasi dari runtime itu sendiri.
Tulis kartu pemanggil sebelum ada perubahan jaringan apa pun
Isi lima kolom dan jangan menebak satu pun. Produk eksekusi dan konteksnya menentukan semua hal berikutnya, jadi mulailah dari sana, bukan dari firewall server.
| 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 browser dan callout Apex adalah dua klien berbeda, dan browser yang berfungsi hanya membuktikan bahwa ada jalur dari meja Anda. Jika kolom runtime menyebut Apex, pertanyaan yang relevan adalah dari alamat mana Salesforce keluar, bukan alamat mana yang dimiliki laptop Anda. Itu sebabnya tunnel yang membuat API termuat di browser bisa meninggalkan integrasi gagal dengan timeout yang sama seperti sebelumnya. Kartu pemanggil ada untuk menghentikan kesalahan itu sebelum siapa pun menyunting firewall.
Pilih pintu masuk yang benar-benar bisa dipakai pemanggil
Kedua desain sah, dan keduanya menyelesaikan masalah yang berbeda. Yang pertama adalah pintu masuk publik yang disengaja: gateway API HTTPS atau layanan integrasi yang mengautentikasi pemanggil, menerapkan izin yang sempit, dan memegang koneksi terlindungi ke backend privat. Itu tidak sama dengan mengekspos setiap layanan backend atau meneruskan port manajemen ke internet.
Yang kedua adalah koneksi privat yang memenuhi syarat. Dokumentasi Private Connect keluar dari Salesforce menjelaskan perutean callout yang didukung melalui Outbound Network Connection yang terikat ke kredensial bernama, di atas tata letak AWS PrivateLink yang telah ditentukan. Fitur ini punya batasan edisi, lisensi, dan produk, jadi pastikan organisasi memenuhi syarat sebelum merancang di sekitarnya.
Tidak ada dari kedua desain itu yang merupakan klien OpenVPN yang terpasang di dalam Salesforce, dan klaim lama bahwa setiap integrasi harus mencapai backend publik terlalu luas di mana pun koneksi privat yang didukung cocok. Pilih yang didukung runtime, lalu selesaikan jalur sampai ke API sebenarnya: endpoint AWS tidak mengenal sumber daya lokal Anda dan tidak mewarisi rute laptop Anda. DNS, perutean backend, kebijakan akses, dan lalu lintas balasan semuanya harus mengikuti arsitektur yang Anda pilih. Jalur privat yang setengah jadi gagal dengan cara yang persis tampak seperti masalah autentikasi.
Sambungkan jalur privat dari ujung ke ujung
Bekerjalah keluar dari API dan berhenti pada celah pertama. Pastikan backend menjawab secara lokal, lalu bahwa endpoint privat mencapainya, lalu bahwa kredensial bernama dan koneksi keluarnya menyasar endpoint 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 sehat dari dalam jaringan privat, yang kedua menunjukkan ke apa nama itu resolve, dan yang ketiga menjalankan callout dari runtime Salesforce yang sebenarnya. 200 dari yang pertama dan kegagalan dari yang ketiga mengisolasi celah ke jalur atau kredensial, bukan ke layanan.
Jaga cakupan identitas tetap tepat saat menyambungkan. Kredensial bernama tidak memperbaiki endpoint yang tak terjangkau dengan sendirinya, karena kredensial dan koneksi privat adalah pengaturan terkait dengan tugas yang terpisah. Daftar IP yang diizinkan mempersempit penerimaan jaringan dan bukan kredensial API, jadi pertahankan validasi TLS normal serta proses autentikasi dan rotasi milik layanan itu sendiri. Jika sebuah uji hanya lolos setelah Anda mematikan pemeriksaan sertifikat, Anda menemukan masalah nama host, bukan masalah jalur, dan sertifikat tetap harus cocok.
Verifikasi dari runtime, lalu catat rollback
Terima permintaan tidak berbahaya yang diizinkan dari runtime integrasi, bukan dari mesin Anda. Catat sumber yang diamati layanan penerima, principal yang terautentikasi, hasilnya, dan satu permintaan yang sengaja ditolak yang harus 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 jaringan backend itu sendiri agar sumber yang diamati dapat dibandingkan dengan yang dihasilkan runtime. 200 yang diikuti 401 atau 403 adalah bentuk yang Anda inginkan; dua 200 berarti jalur penolakan tidak benar-benar ditegakkan.
Tulis rollback sebelum Anda membutuhkannya: entri daftar izin, kredensial bernama, atau koneksi keluar mana yang Anda ubah, siapa pemiliknya, dan bagaimana memulihkan nilai sebelumnya. Lalu tutup lingkaran dengan menyebut pemanggil cloud dan jalur layanan lengkap di tiket, supaya tidak ada yang membuka kembali masalah yang sama sebagai masalah VPN.