Apex-ის გამოძახებები Salesforce-იდან მიდის, არა თქვენი VPN-იდან
ლეპტოპის VPN ბრაუზერს გზას აძლევს, არა Apex-ს ან Marketing Cloud-ს. შეუსაბამეთ ნამდვილი გამომძახებელი საჯარო კარიბჭეს ან კვალიფიციურ კერძო კავშირს.
კერძო API ბრაუზერში პასუხობს იმ მომენტში, როცა ლეპტოპი VPN-ს უერთდება, ამიტომ ინტეგრაცია უნდა მუშაობდეს. არ მუშაობს, რადგან გამოძახების შემსრულებელი კოდი სულ სხვაგან ეშვება. Apex Salesforce-ის აპლიკაციის სერვერებზე ეშვება, ხოლო Marketing Cloud-ის სერვერის მხარის აქტივობა ამ პროდუქტის გაშვების გარემოში. არც ერთი მათგანი არ მემკვიდრეობით იღებს თქვენი ლეპტოპის გვირაბს. შეასრულეთ ეს როგორც მოკლე პროცედურა: დაადგინეთ გამომძახებელი, აირჩიეთ შესასვლელი, რომელზეც ეს გამომძახებელი მიაღწევს, დააკავშირეთ გზა თავიდან ბოლომდე და შემდეგ გადაამოწმეთ თავად გაშვების გარემოდან.
დაწერეთ გამომძახებლის ბარათი ქსელის ნებისმიერ ცვლილებამდე
შეავსეთ ხუთი ველი და უარი თქვით რომელიმეს გამოცნობაზე. შესრულების პროდუქტი და კონტექსტი წყვეტს ყველაფერს შემდგომს, ამიტომ დაიწყეთ იქიდან და არა სერვერის ფაირვოლიდან.
| 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? |
ბრაუზერის ჩანართი და Apex-ის გამოძახება ორი განსხვავებული კლიენტია, და მომუშავე ბრაუზერი მხოლოდ იმას ამტკიცებს, რომ თქვენი მაგიდიდან გზა არსებობს. თუ გაშვების გარემოს ველი ამბობს Apex-ს, შესაბამისი კითხვაა, რომელი მისამართებიდან გადის Salesforce, და არა რომელი მისამართები აქვს თქვენს ლეპტოპს. ამიტომ გვირაბი, რომელიც API-ს ბრაუზერში ტვირთავს, ინტეგრაციას იმავე ვადის გასვლით ამარცხებს, როგორც ადრე. გამომძახებლის ბარათი სწორედ იმისთვისაა, რომ ეს შეცდომა შეჩერდეს მანამ, სანამ ვინმე ფაირვოლს შეცვლის.
აირჩიეთ შესასვლელი, რომელსაც გამომძახებელი ნამდვილად გამოიყენებს
ორივე დიზაინი ლეგიტიმურია და სხვადასხვა პრობლემას წყვეტს. პირველი განზრახ საჯარო შესასვლელია: HTTPS API კარიბჭე ან ინტეგრაციის სერვისი, რომელიც ამოწმებს გამომძახებელს, იყენებს ვიწრო ნებართვებს და ინახავს დაცულ კავშირს კერძო backend-თან. ეს არ არის იგივე, რაც ყოველი backend სერვისის გამოჩენა ან მართვის პორტის ინტერნეტში გადატანა.
მეორე კვალიფიციური კერძო კავშირია. Salesforce-ის Private Connect-ის გამავალი დოკუმენტაცია აღწერს მხარდაჭერილი გამოძახებების მარშრუტიზაციას Outbound Network Connection-ის მეშვეობით, რომელიც დაკავშირებულია სახელდებულ რწმუნებასთან, მისი განსაზღვრული AWS PrivateLink განლაგებით. ფუნქციას აქვს გამოცემის, ლიცენზიისა და პროდუქტის შეზღუდვები, ამიტომ დაადასტურეთ, რომ ორგანიზაცია აკმაყოფილებს პირობებს, სანამ მის გარშემო დიზაინს შექმნით.
არც ერთი დიზაინი არ არის Salesforce-ის შიგნით დაყენებული OpenVPN კლიენტი, და ძველი მტკიცება, რომ ყოველი ინტეგრაცია საჯარო backend-ს უნდა მიაღწიოს, ძალიან ფართოა იქ, სადაც მხარდაჭერილი კერძო კავშირი ჯდება. აირჩიეთ ის, რასაც გაშვების გარემო მხარს უჭერს, შემდეგ დაასრულეთ გზა ნამდვილ API-მდე: AWS-ის საბოლოო წერტილი არ იცნობს თქვენს ლოკალურ რესურსს და არ მემკვიდრეობით იღებს თქვენი ლეპტოპის მარშრუტს. DNS, backend-ის მარშრუტიზაცია, წვდომის პოლიტიკა და პასუხის ტრაფიკი ყველამ უნდა დაიცვას თქვენ მიერ არჩეული არქიტექტურა. ნახევრად აშენებული კერძო გზა ისე ცდება, რომ ზუსტად ავთენტიფიკაციის პრობლემას ჰგავს.
დააკავშირეთ კერძო გზა თავიდან ბოლომდე
იმუშავეთ API-დან გარეთ და გაჩერდით პირველ ხარვეზზე. დაადასტურეთ, რომ backend ადგილობრივად პასუხობს, შემდეგ რომ კერძო საბოლოო წერტილი აღწევს მას, და შემდეგ რომ სახელდებული რწმუნება და მისი გამავალი კავშირი ამ წერტილს მიემართება.
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პირველი ბრძანება ამტკიცებს, რომ backend ჯანსაღია კერძო ქსელის შიგნიდან, მეორე აჩვენებს, რაში იხსნება სახელი, ხოლო მესამე გამოძახებას ასრულებს Salesforce-ის ნამდვილი გაშვების გარემოდან. 200 პირველიდან და მარცხი მესამიდან ხარვეზს გზას ან რწმუნებას უკავშირებს და არა სერვისს.
დაკავშირებისას იდენტობის არე ზუსტად შეინარჩუნეთ. სახელდებული რწმუნება დამოუკიდებლად არ არემონტებს მიუწვდომელ საბოლოო წერტილს, რადგან რწმუნება და კერძო კავშირი დაკავშირებული პარამეტრებია ცალკეული ამოცანებით. IP ნებადართული სია ავიწროებს ქსელურ მიღებას და არ არის API რწმუნება, ამიტომ შეინარჩუნეთ ჩვეულებრივი TLS ვალიდაცია და სერვისის საკუთარი ავთენტიფიკაციისა და როტაციის პროცესი. თუ ტესტი მხოლოდ სერტიფიკატის შემოწმების გამორთვის შემდეგ გადის, თქვენ იპოვეთ ჰოსტის სახელის პრობლემა და არა გზის პრობლემა, და სერტიფიკატი მაინც უნდა შეესაბამებოდეს.
გადაამოწმეთ გაშვების გარემოდან, შემდეგ ჩაწერეთ დაბრუნება
მიიღეთ უვნებელი ნებადართული მოთხოვნა ინტეგრაციის გაშვების გარემოდან და არა თქვენი მანქანიდან. ჩაწერეთ მიმღები სერვისის დაკვირვებული წყარო, ავთენტიფიცირებული სუბიექტი, შედეგი და ერთი განზრახ უარყოფილი მოთხოვნა, რომელიც უნდა ჩავარდეს.
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გაუშვით იგივე ორი შემოწმება backend-ის საკუთარი ქსელიდან, რათა დაკვირვებული წყარო შევადაროთ იმას, რაც გაშვების გარემომ წარმოქმნა. სასურველი ფორმაა 200, რომელსაც მოჰყვება 401 ან 403; ორი 200 ნიშნავს, რომ უარყოფის გზა რეალურად არ სრულდება.
დაწერეთ დაბრუნება სანამ დაგჭირდებათ: რომელი ნებადართული სიის ჩანაწერი, სახელდებული რწმუნება ან გამავალი კავშირი შეცვალეთ, ვის ეკუთვნის და როგორ აღვადგინოთ წინა მნიშვნელობა. შემდეგ დახურეთ ციკლი ბილეთში ღრუბლოვანი გამომძახებლისა და სერვისის სრული გზის დასახელებით, რათა არავინ გახსნას იგივე საკითხი ისევ VPN პრობლემად.