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 խնդիր։