Apex çağırışları VPN-inizdən deyil, Salesforce-dən çıxır

Noutbuk VPN-ə qoşulan kimi şəxsi API brauzerinizdə cavab verir, yəni inteqrasiya işləməlidir. İşləmir, çünki çağırışı edən kod tamamilə başqa yerdə işləyir. Apex Salesforce-un tətbiq serverlərində, Marketing Cloud-un server tərəfli fəaliyyəti isə həmin məhsulun icra mühitində icra olunur. Heç biri noutbukunuzun tunelini miras almır. Bunu qısa prosedur kimi aparın: çağıranı müəyyən edin, çağıranın çata biləcəyi girişi seçin, yolu başdan-başa qoşun, sonra icra mühitinin özündən yoxlayın.

Hər hansı şəbəkə dəyişikliyindən əvvəl çağıran kartını yazın

Beş sahəni doldurun və heç birini təxmin etməkdən imtina edin. İcra məhsulu və konteksti sonrakı hər şeyi müəyyən edir, ona görə serverin firewall-undan deyil, oradan başlayın.

Brauzer vərəqi və Apex çağırışı iki fərqli müştəridir və işləyən brauzer yalnız masanızdan yol olduğunu sübut edir. İcra mühiti sahəsi Apex deyirsə, əlaqəli sual Salesforce-un hansı ünvanlardan çıxdığıdır, noutbukunuzun hansı ünvanlara sahib olduğu deyil. Buna görə API-ni brauzerdə açan tunel inteqrasiyanı əvvəlki eyni timeout ilə uğursuz buraxa bilər. Çağıran kartı bu səhvi kiminsə firewall-u redaktə etməsindən əvvəl dayandırmaq üçün var.

Çağıranın həqiqətən istifadə edə biləcəyi girişi seçin

İki dizayn qanunidir və onlar fərqli problemləri həll edir. Birincisi qəsdən ictimai girişdir: çağıranı autentifikasiya edən, dar icazələr tətbiq edən və şəxsi backend-ə qorunan bağlantı saxlayan HTTPS API şlüzü və ya inteqrasiya xidməti. Bu, hər backend xidmətini açmaq və ya idarəetmə portunu internetə yönəltməklə eyni şey deyil.

İkincisi uyğun şəxsi bağlantıdır. Salesforce-un Private Connect xarici bağlantı sənədləri dəstəklənən çağırışların adlı etimadnaməyə bağlanmış Outbound Network Connection vasitəsilə, müəyyən edilmiş AWS PrivateLink quruluşu üzərindən yönləndirilməsini təsvir edir. Funksiyanın nəşr, lisenziya və məhsul məhdudiyyətləri var, ona görə onun ətrafında dizayn etməzdən əvvəl təşkilatın uyğun olduğunu təsdiqləyin.

Heç bir dizayn Salesforce-un içində quraşdırılmış OpenVPN müştərisi deyil və hər inteqrasiyanın ictimai backend-ə çatmalı olduğuna dair köhnə iddia, dəstəklənən şəxsi bağlantının uyğun olduğu yerlərdə çox genişdir. İcra mühitinin dəstəklədiyini seçin, sonra real API-yə qədər yolu tamamlayın: AWS son nöqtəsi sizin lokal resursunuzu bilmir və noutbukunuzun marşrutunu miras almır. DNS, backend marşrutlaşdırması, giriş siyasəti və cavab trafiki seçdiyiniz arxitekturaya uyğun olmalıdır. Yarımçıq şəxsi yol, tam olaraq autentifikasiya problemi kimi görünən şəkildə uğursuz olur.

Şəxsi yolu başdan-başa qoşun

API-dən xaricə doğru işləyin və ilk boşluqda dayanın. Backend-in lokal cavab verdiyini təsdiqləyin, sonra şəxsi son nöqtənin ona çatdığını, sonra adlı etimadnamənin və onun xarici bağlantısının həmin son nöqtəni hədəflədiyini təsdiqləyin.

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 integration

Birinci əmr backend-in şəxsi şəbəkənin içindən sağlam olduğunu sübut edir, ikincisi adın nəyə həll olunduğunu göstərir, üçüncüsü isə real Salesforce icra mühitindən çağırış icra edir. Birincidən 200 və üçüncüdən uğursuzluq boşluğu xidmətə deyil, yola və ya etimadnaməyə ayırır.

Qoşma zamanı kimlik əhatəsini dəqiq saxlayın. Adlı etimadnamə çatılmayan son nöqtəni təkbaşına düzəltmir, çünki etimadnamə və şəxsi bağlantı ayrı işləri olan əlaqəli parametrlərdir. IP icazə siyahısı şəbəkə qəbulunu daraldır və API etimadnaməsi deyil, ona görə normal TLS yoxlamasını və xidmətin öz autentifikasiya və rotasiya prosesini saxlayın. Əgər test yalnız sertifikat yoxlamasını söndürdükdən sonra keçirsə, yol deyil, hostname problemi tapdınız və sertifikat hələ də uyğun olmalıdır.

İcra mühitindən yoxlayın, sonra geri qaytarmanı qeyd edin

Zərərsiz, icazə verilmiş sorğunu maşınınızdan deyil, inteqrasiya icra mühitindən qəbul edin. Qəbul edən xidmətin müşahidə etdiyi mənbəni, autentifikasiya olunmuş subyekti, nəticəni və mütləq uğursuz olmalı olan bir qəsdən rədd edilmiş sorğunu qeyd edin.

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/ping

Eyni iki yoxlamanı backend-in öz şəbəkəsindən aparın ki, müşahidə edilən mənbə icra mühitinin yaratdığı ilə müqayisə olunsun. İstədiyiniz forma 200-dən sonra 401 və ya 403-dür; iki 200 rədd yolunun həqiqətən tətbiq olunmadığını göstərir.

Geri qaytarmanı ehtiyac duymadan əvvəl yazın: hansı icazə siyahısı qeydini, adlı etimadnaməni və ya xarici bağlantını dəyişdiyinizi, kimin sahib olduğunu və əvvəlki dəyəri necə bərpa edəcəyinizi. Sonra bulud çağıranını və tam xidmət yolunu biletdə adlandıraraq dövrəni bağlayın ki, heç kim eyni məsələni yenidən VPN problemi kimi açmasın.