Apex deiek Salesforce-tik irteten dute, ez zure VPN-tik
Ordenagailuko VPN batek zure arakatzaileari bidea ematen dio, ez Apex edo Marketing Cloud-i. Lotu benetako deitzailea atebide publikoei edo konexio pribatu egoki bati.
API pribatuak zure arakatzailean erantzuten du ordenagailua VPN-ra konektatzen den unean, beraz integrazioak funtzionatu beharko luke. Ez du funtzionatzen, deiak egiten dituen kodea erabat beste leku batean exekutatzen delako. Apex Salesforce-en aplikazio zerbitzarietan exekutatzen da, eta Marketing Cloud-eko zerbitzari-alboko jarduerak produktu horren exekuzio ingurunean exekutatzen dira. Biak ere ez dira zure ordenagailuaren tunelaz jabetzen. Egin ezazu prozedura labur gisa: identifikatu deitzailea, aukeratu deitzaile horrek irits dezakeen sarbide bat, konektatu bidea muturretik muturrera, eta gero egiaztatu exekuzio ingurunetik bertatik.
Idatzi deitzailearen fitxa sareko edozein aldaketaren aurretik
Bete bost eremu eta ukatu horietako edozein asmatzea. Exekuzio produktuak eta testuinguruak erabakitzen dute gainerako guztia, beraz hasi horretatik, ez zerbitzariaren suebakitik.
| 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? |
Arakatzailearen fitxa bat eta Apex dei bat bi bezero ezberdin dira, eta funtzionatzen duen arakatzaile batek zure mahaitik bide bat dagoela baino ez du frogatzen. Exekuzio ingurunearen eremuak Apex esaten badu, galdera garrantzitsua da Salesforce zein helbidetatik irteten den, ez zure ordenagailuak zein helbide dituen. Horregatik APIa arakatzailean kargatzea lortzen duen tunel batek integrazioa lehengo itxaron-denbora berarekin huts egiten utz dezake. Deitzailearen fitxa errore hori gelditzeko dago, norbaitek suebakia editatu aurretik.
Aukeratu deitzaileak benetan erabil dezakeen sarbidea
Bi diseinuak zilegiak dira, eta arazo desberdinak konpontzen dituzte. Lehenengoa sarbide publiko nahita egina da: HTTPS API atebide bat edo integrazio zerbitzu bat, deitzailea autentifikatzen duena, baimen estuak aplikatzen dituena eta backend pribatuarekiko konexio babestua mantentzen duena. Hori ez da backend zerbitzu guztiak agerian jartzearen edo kudeaketa ataka bat interneten birbidaltzearen berdina.
Bigarrena konexio pribatu egoki bat da. Salesforce-eko Private Connect irteerako dokumentazioak deiak onartutako Outbound Network Connection baten bidez bideratzen direla deskribatzen du, izendatutako kredentzial bati lotuta, zehaztutako AWS PrivateLink antolamenduaren gainean. Eginbideak edizio, lizentzia eta produktu murrizketak ditu, beraz berretsi erakundeak baldintzak betetzen dituela horren inguruan diseinatu aurretik.
Bi diseinuetako bat ere ez da Salesforce-ren barruan instalatutako OpenVPN bezero bat, eta integrazio guztiek backend publiko bat iritsi behar dutelako baieztapen zaharra zabalegia da konexio pribatu onartu bat egokia den lekuetan. Aukeratu exekuzio inguruneak onartzen duena, eta gero osatu bidea benetako APIraino: AWS endpoint batek ez daki zure tokiko baliabidea eta ez du zure ordenagailuaren ibilbidea heredatzen. DNSak, backend bideratzeak, sarbide politikek eta erantzun trafikoak zuk aukeratutako arkitektura jarraitu behar dute. Erdi eraikitako bide pribatu batek autentifikazio arazo baten itxura zehatza duen moduan huts egiten du.
Konektatu bide pribatua muturretik muturrera
Lan egin APItik kanpora eta gelditu lehen hutsunean. Berretsi backendak tokian erantzuten duela, gero endpoint pribatuak hura iristen duela, eta gero izendatutako kredentzialak eta bere irteerako konexioak endpoint hori helburutzat dutela.
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 integrationLehen komandoak frogatzen du backenda osasuntsu dagoela sare pribatuaren barrutik, bigarrenak erakusten du zertara ebazten den izena, eta hirugarrenak benetako Salesforce exekuzio ingurunetik dei bat exekutatzen du. Lehenengotik 200 bat eta hirugarrenetik huts egite bat hutsunea bidera edo kredentzialera isolatzen dute, ez zerbitzura.
Eduki identitatearen irismena zehatz konektatzen duzun bitartean. Izendatutako kredentzial batek ez du berak bakarrik iristezin den endpoint bat konpontzen, kredentziala eta konexio pribatua zeregin ezberdineko ezarpen erlazionatuak direlako. IP baimenduen zerrenda batek sareko onarpena estutzen du eta ez da API kredentziala, beraz mantendu ohiko TLS baliozkotzea eta zerbitzuaren autentifikazio eta errotazio prozesua. Proba bat ziurtagiriaren egiaztapena desaktibatu ondoren bakarrik pasatzen bada, ostalari-izen arazo bat aurkitu duzu, ez bide arazo bat, eta ziurtagiriak oraindik bat etorri behar du.
Egiaztatu exekuzio ingurunetik, eta gero erregistratu atzerakada
Onartu eskaera kaltegabe eta baimendu bat integrazioaren exekuzio ingurunetik, ez zure makinatik. Erregistratu jasotzen duen zerbitzuaren behatutako iturria, autentifikatutako nagusia, emaitza eta nahita ukatutako eskaera bat, huts egin behar duena.
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/pingExekutatu bi proba berak backendaren saretik bertatik, behatutako iturria exekuzio inguruneak sortutakoarekin aldera dadin. Nahi duzun forma 200 bat da, ondoren 401 edo 403 duena; bi 200ek ukatze bidea benetan betetzen ez dela esan nahi dute.
Idatzi atzerakada behar baino lehen: zein baimenduen zerrendako sarrera, izendatutako kredentzial edo irteerako konexio aldatu zenuen, norena den eta nola leheneratu aurreko balioa. Gero itxi zirkulua tiketeko hodeiko deitzailea eta zerbitzuaren bide osoa izendatuz, inork arazo bera berriro VPN arazo gisa ireki ez dezan.