Thirrjet Apex dalin nga Salesforce, jo nga VPN-ja juaj
Një VPN në laptop i jep shfletuesit tuaj një rrugë, jo Apex ose Marketing Cloud. Përputhni thirrësin e vërtetë me një portë publike ose një lidhje private të kualifikuar.
API privat përgjigjet në shfletuesin tuaj në momentin që laptopi i bashkohet VPN-së, prandaj integrimi duhet të funksionojë. Nuk funksionon, sepse kodi që bën thirrjen ekzekutohet diku tjetër, krejt. Apex ekzekutohet në serverat e aplikacioneve të Salesforce, dhe një aktivitet nga ana e serverit në Marketing Cloud ekzekutohet në runtime-in e atij produkti. Asnjëra prej tyre nuk trashëgon tunelin e laptopit tuaj. Trajtojeni si një procedurë të shkurtër: identifikoni thirrësin, zgjidhni një hyrje që ai thirrës mund ta arrijë, lidhni rrugën nga fillimi në fund dhe më pas verifikoni nga vetë runtime-i.
Shkruani kartën e thirrësit përpara çdo ndryshimi në rrjet
Plotësoni pesë fusha dhe refuzoni të hamendësoni cilëndo prej tyre. Produkti i ekzekutimit dhe konteksti vendosin gjithçka më tej, prandaj filloni atje dhe jo nga firewall-i i serverit.
| 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? |
Një skedë shfletuesi dhe një thirrje Apex janë dy klientë të ndryshëm, dhe një shfletues që funksionon dëshmon vetëm se ekziston një rrugë nga tavolina juaj. Nëse fusha e runtime-it thotë Apex, pyetja përkatëse është nga cilat adresa del Salesforce, jo cilat adresa ka laptopi juaj. Prandaj një tunel që bën që API të ngarkohet në shfletues mund ta lërë integrimin të dështojë me të njëjtin afat kohor si më parë. Karta e thirrësit ekziston për ta ndaluar këtë gabim përpara se dikush të redaktojë një firewall.
Zgjidhni hyrjen që thirrësi mund ta përdorë vërtet
Të dyja modelet janë legitime dhe zgjidhin probleme të ndryshme. I pari është një hyrje publike e qëllimshme: një portë API me HTTPS ose një shërbim integrimi që vërteton thirrësin, zbaton leje të ngushta dhe mban një lidhje të mbrojtur me backend-in privat. Kjo nuk është e njëjtë me ekspozimin e çdo shërbimi backend ose kalimin e një porte administrimi në internet.
I dyti është një lidhje private e kualifikuar. Dokumentacioni i Salesforce për Private Connect dalës përshkruan rrugëtimin e thirrjeve të mbështetura përmes një Outbound Network Connection të lidhur me një kredenciale të emërtuar, sipas rregullimit të përcaktuar të AWS PrivateLink. Funksioni ka kufizime edicioni, licence dhe produkti, prandaj konfirmoni që organizata plotëson kushtet përpara se të dizajnoni rreth tij.
Asnjëri model nuk është një klient OpenVPN i instaluar brenda Salesforce, dhe pretendimi i vjetër se çdo integrim duhet të arrijë një backend publik është shumë i gjerë aty ku përshtatet një lidhje private e mbështetur. Zgjidhni atë që mbështet runtime-i, pastaj përfundoni rrugën deri te API i vërtetë: një pikë fundore AWS nuk e njeh burimin tuaj lokal dhe nuk trashëgon rrugën e laptopit tuaj. DNS, rrugëtimi i backend-it, politika e aksesit dhe trafiku i përgjigjeve duhet të ndjekin arkitekturën që zgjodhët. Një rrugë private gjysmë e ndërtuar dështon në një mënyrë që duket saktësisht si problem vërtetimi.
Lidhni rrugën private nga fillimi në fund
Punoni nga API-ja nga jashtë dhe ndaloni në boshllëkun e parë. Konfirmoni që backend-i përgjigjet lokalisht, pastaj që pika fundore private e arrin, dhe pastaj që kredencialja e emërtuar dhe lidhja e saj dalëse synojnë atë pikë.
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 integrationKomanda e parë dëshmon që backend-i është i shëndetshëm nga brenda rrjetit privat, e dyta tregon në çfarë zgjidhet emri, dhe e treta ekzekuton një thirrje nga runtime-i i vërtetë i Salesforce. 200 nga e para dhe dështim nga e treta e izolojnë boshllëkun te rruga ose kredencialja, jo te shërbimi.
Mbani shtrirjen e identitetit të saktë gjatë lidhjes. Një kredencial e emërtuar nuk e rregullon vetë një pikë fundore të paarritshme, sepse kredencialja dhe lidhja private janë cilësime të lidhura me detyra të ndara. Një listë e lejuar IP-ve ngushton pranimin në rrjet dhe nuk është kredencial API, prandaj ruani validimin normal TLS dhe procesin e vetë shërbimit të vërtetimit dhe rotacionit. Nëse një test kalon vetëm pasi çaktivizoni kontrollin e certifikatës, keni gjetur një problem emri hosti dhe jo rruge, dhe certifikata duhet ende të përputhet.
Verifikoni nga runtime-i, pastaj regjistroni kthimin
Pranoni një kërkesë të lejuar dhe të padëmshme nga runtime-i i integrimit, jo nga makina juaj. Regjistroni burimin e vëzhguar të shërbimit pritës, principalin e vërtetuar, rezultatin dhe një kërkesë të refuzuar qëllimisht që duhet të dështojë.
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/pingEkzekutoni të njëjtat dy prova nga rrjeti i vetë backend-it, që burimi i vëzhguar të mund të krahasohet me atë që prodhoi runtime-i. 200 i ndjekur nga 401 ose 403 është forma që dëshironi; dy 200 do të thonë se rruga e refuzimit nuk zbatohet vërtet.
Shkruani kthimin përpara se t'ju duhet: cila hyrje e listës së lejuar, kredencial i emërtuar ose lidhje dalëse ndryshuat, kush e zotëron dhe si të rikthehet vlera e mëparshme. Pastaj mbyllni ciklin duke emërtuar në tiketë thirrësin në re dhe rrugën e plotë të shërbimit, që askush të mos e rihapë të njëjtën çështje si problem VPN.