Apex chaqiruvlari VPN'ingizdan emas, Salesforce'dan chiqadi
Noutbukdagi VPN brauzeringizga yo'l beradi, Apex yoki Marketing Cloud'ga emas. Haqiqiy chaqiruvchini ommaviy shlyuz yoki malakali xususiy ulanish bilan moslang.
Noutbuk VPN'ga ulanashi bilanoq xususiy API brauzeringizda javob beradi, shuning uchun integratsiya ishlashi kerak. Ammo ishlamaydi, chunki chaqiruvni amalga oshiruvchi kod butunlay boshqa joyda ishlaydi. Apex Salesforce'ning amaliy serverlarida, Marketing Cloud'dagi server tomonidagi faoliyat esa o'sha mahsulotning ishlash muhitida ishlaydi. Ikkalasi ham noutbukingiz tunnelini meros olmaydi. Buni qisqa tartib sifatida bajaring: chaqiruvchini aniqlang, o'sha chaqiruvchi yetib bora oladigan kirishni tanlang, yo'lni boshidan oxirigacha ulang, so'ngra ishlash muhitining o'zidan tekshiring.
Har qanday tarmoq o'zgarishidan oldin chaqiruvchi kartasini yozing
Beshta maydonni to'ldiring va ularning birortasini taxmin qilishdan voz keching. Bajarish mahsuloti va kontekst keyingi hamma narsani belgilaydi, shuning uchun serverning xavfsizlik devoridan emas, o'sha yerdan boshlang.
| 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? |
Brauzer yorlig'i va Apex chaqiruvi ikki xil mijoz, ishlayotgan brauzer esa stolingizdan yo'l borligini faqatgina isbotlaydi. Agar ishlash muhiti maydoni Apex desa, tegishli savol Salesforce qaysi manzillardan chiqadi, noutbukingizda qaysi manzillar bor emas. Shuning uchun API'ning brauzerda yuklanishini ta'minlaydigan tunnel integratsiyani avvalgi bilan bir xil kutish vaqtida muvaffaqiyatsiz qoldirishi mumkin. Chaqiruvchi kartasi kimdir xavfsizlik devorini tahrirlashdan oldin bu xatoni to'xtatish uchun bor.
Chaqiruvchi haqiqatan ham foydalana oladigan kirishni tanlang
Ikkala loyiha ham qonuniy va ular turli muammolarni hal qiladi. Birinchisi ataylab yaratilgan ommaviy kirish: chaqiruvchini autentifikatsiya qiladigan, tor ruxsatlarni qo'llaydigan va xususiy backend bilan himoyalangan ulanishni saqlaydigan HTTPS API shlyuzi yoki integratsiya xizmati. Bu har bir backend xizmatini ochish yoki boshqaruv portini internetga yo'naltirish bilan bir xil emas.
Ikkinchisi malakali xususiy ulanish. Salesforce'ning chiquvchi Private Connect hujjatlari qo'llab-quvvatlanadigan chaqiruvlarni nomlangan hisob ma'lumotlariga bog'langan Outbound Network Connection orqali, belgilangan AWS PrivateLink tartibida qanday yo'naltirishni tavsiflaydi. Bu xususiyat nashr, litsenziya va mahsulot cheklovlariga ega, shuning uchun uning atrofida loyihalashdan oldin tashkilot talablarga javob berishini tasdiqlang.
Ikkala loyihaning hech biri Salesforce ichida o'rnatilgan OpenVPN mijozi emas, va har bir integratsiya ommaviy backend'ga yetishi shart degan eski da'vo qo'llab-quvvatlanadigan xususiy ulanish mos keladigan joyda juda keng. Ishlash muhiti qo'llab-quvvatlaydiganini tanlang, so'ngra haqiqiy API'gacha yo'lni tugating: AWS so'nggi nuqtasi sizning mahalliy resursingizni bilmaydi va noutbukingiz marshrutini meros olmaydi. DNS, backend yo'naltirishi, kirish siyosati va javob trafigi — barchasi siz tanlagan arxitekturaga rioya qilishi kerak. Yarim qurilgan xususiy yo'l xuddi autentifikatsiya muammosiga o'xshab muvaffaqiyatsizlikka uchraydi.
Xususiy yo'lni boshidan oxirigacha ulang
API'dan tashqariga qarab ishlang va birinchi bo'shliqda to'xtang. Backend mahalliy javob berishini, so'ngra xususiy so'nggi nuqta unga yetib borishini, so'ngra nomlangan hisob ma'lumotlari va ularning chiquvchi ulanishi o'sha nuqtani nishonga olishini tasdiqlang.
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 integrationBirinchi buyruq backend xususiy tarmoq ichidan sog'lom ekanini isbotlaydi, ikkinchisi nom nimaga hal bo'lishini ko'rsatadi, uchinchisi esa haqiqiy Salesforce ishlash muhitidan chaqiruv bajaradi. Birinchisidan 200 va uchinchisidan muvaffaqiyatsizlik bo'shliqni xizmatga emas, yo'l yoki hisob ma'lumotlariga ajratadi.
Ulashda identifikatsiya doirasini aniq saqlang. Nomlangan hisob ma'lumotlari yetib bo'lmaydigan so'nggi nuqtani o'zi tuzatmaydi, chunki hisob ma'lumotlari va xususiy ulanish alohida vazifalarga ega bog'liq sozlamalardir. IP ruxsat ro'yxati tarmoqqa qabulni toraytiradi va API hisob ma'lumoti emas, shuning uchun odatdagi TLS tekshiruvi va xizmatning o'z autentifikatsiya va rotatsiya jarayonini saqlang. Agar test sertifikat tekshiruvini o'chirgandan keyingina o'tsa, siz yo'l emas, xost nomi muammosini topdingiz, va sertifikat baribir mos kelishi kerak.
Ishlash muhitidan tekshiring, so'ngra qaytarishni yozib qo'ying
O'z mashinangizdan emas, integratsiya ishlash muhitidan zararsiz ruxsat etilgan so'rovni qabul qiling. Qabul qiluvchi xizmatning kuzatilgan manbasini, autentifikatsiya qilingan subyektni, natijani va albatta muvaffaqiyatsiz bo'lishi kerak bo'lgan ataylab rad etilgan bitta so'rovni yozib oling.
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/pingXuddi o'sha ikki tekshiruvni backend'ning o'z tarmog'idan o'tkazing, shunda kuzatilgan manbani ishlash muhiti ishlab chiqqan manba bilan solishtirish mumkin. 200, undan keyin 401 yoki 403 — kerakli shakl; ikkita 200 rad etish yo'li aslida qo'llanilmasligini bildiradi.
Qaytarishni kerak bo'lishidan oldin yozing: qaysi ruxsat ro'yxati yozuvini, nomlangan hisob ma'lumotlarini yoki chiquvchi ulanishni o'zgartirdingiz, u kimga tegishli va oldingi qiymatni qanday tiklash kerak. So'ngra chiptada bulutli chaqiruvchini va xizmatning to'liq yo'lini nomlab, halqani yoping, shunda hech kim o'sha masalani yana VPN muammosi sifatida ochmaydi.