Apex чакыруулары Salesforce тен чыгат, сиздин VPN ден эмес
Ноутбуктеги VPN браузериңизге жол берет, Apex же Marketing Cloud го эмес. Чыныгы чакыруучуну коомдук шлюз же квалификациялуу жеке туташуу менен дал келтириңиз.
Ноутбук VPN ге кошулган учурда жеке API браузериңизде жооп берет, ошондуктан интеграция иштеши керек. Бирок иштебейт, анткени чакырууну аткарган код таптакыр башка жерде жүрөт. 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 ни браузерде жүктөгөн туннель интеграцияны мурункудай эле күтүү убактысы менен ийгиликсиз калтырышы мүмкүн. Чакыруучу картасы бирөө брандмауэрди оңдобой туруп, ошол катаны токтотуу үчүн бар.
Чакыруучу чындыгында пайдалана алган кирүү жолун тандаңыз
Эки долбоор тең мыйзамдуу жана алар ар башка маселелерди чечет. Биринчиси атайын жасалган коомдук кирүү: чакыруучуну аутентификациялаган, кууш укуктарды колдонгон жана жеке backend менен корголгон байланышты кармаган HTTPS API шлюзу же интеграция кызматы. Бул ар бир 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 маселеси катары ачпайт.