Apex કૉલઆઉટ તમારા VPNમાંથી નહીં, Salesforceમાંથી નીકળે છે
લેપટોપ 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ને બ્રાઉઝરમાં લોડ કરાવે છે તે એકીકરણને પહેલાં જેવા જ ટાઇમઆઉટ સાથે નિષ્ફળ છોડી શકે છે. કોઈ ફાયરવૉલ સંપાદિત કરે તે પહેલાં એ ભૂલ રોકવા માટે જ કૉલર કાર્ડ છે.
કૉલર ખરેખર વાપરી શકે તેવું પ્રવેશદ્વાર પસંદ કરો
બંને ડિઝાઇન માન્ય છે, અને તે અલગ સમસ્યાઓ ઉકેલે છે. પ્રથમ એક જાણી જોઈને બનાવેલું જાહેર પ્રવેશદ્વાર છે: HTTPS API ગેટવે અથવા એકીકરણ સેવા જે કૉલરને પ્રમાણિત કરે છે, સાંકડી પરવાનગીઓ લાગુ કરે છે અને ખાનગી બેકએન્ડ સાથે સુરક્ષિત જોડાણ રાખે છે. આ દરેક બેકએન્ડ સેવાને ખુલ્લી કરવા અથવા વ્યવસ્થાપન પોર્ટને ઇન્ટરનેટ પર ફોરવર્ડ કરવા જેવું નથી.
બીજું લાયક ખાનગી જોડાણ છે. Salesforceનું આઉટબાઉન્ડ Private Connect દસ્તાવેજીકરણ સમર્થિત કૉલઆઉટને નામાંકિત ક્રેડેન્શિયલ સાથે બંધાયેલા Outbound Network Connection દ્વારા, તેની નિર્ધારિત AWS PrivateLink ગોઠવણી પર રૂટ કરવાનું વર્ણવે છે. આ સુવિધા પર આવૃત્તિ, લાઇસન્સ અને ઉત્પાદનની મર્યાદાઓ છે, તેથી તેની આસપાસ ડિઝાઇન કરતાં પહેલાં સંસ્થા લાયક છે તેની ખાતરી કરો.
બંનેમાંથી કોઈ ડિઝાઇન Salesforceની અંદર સ્થાપિત OpenVPN ક્લાયન્ટ નથી, અને દરેક એકીકરણે જાહેર બેકએન્ડ સુધી પહોંચવું જ જોઈએ એ જૂનું વિધાન ત્યાં ખૂબ વિશાળ છે જ્યાં સમર્થિત ખાનગી જોડાણ બંધ બેસે છે. રનટાઇમ જેને સમર્થન આપે છે તે પસંદ કરો, અને પછી વાસ્તવિક API સુધીનો માર્ગ પૂરો કરો: AWS એન્ડપોઇન્ટ તમારા સ્થાનિક સ્રોતને ઓળખતું નથી અને તમારા લેપટોપનો રૂટ વારસામાં લેતું નથી. DNS, બેકએન્ડ રૂટિંગ, ઍક્સેસ નીતિ અને જવાબ ટ્રાફિક—બધાએ તમે પસંદ કરેલી આર્કિટેક્ચરને અનુસરવું પડે. અડધું બનેલું ખાનગી માર્ગ એવી રીતે નિષ્ફળ જાય છે જે બરાબર પ્રમાણીકરણ સમસ્યા જેવું લાગે.
ખાનગી માર્ગને શરૂઆતથી અંત સુધી જોડો
APIથી બહારની તરફ કામ કરો અને પહેલા ખાલીપા પર ઊભા રહો. ખાતરી કરો કે બેકએન્ડ સ્થાનિક રીતે જવાબ આપે છે, પછી ખાનગી એન્ડપોઇન્ટ ત્યાં પહોંચે છે, અને પછી નામાંકિત ક્રેડેન્શિયલ અને તેનું આઉટબાઉન્ડ જોડાણ તે એન્ડપોઇન્ટને લક્ષ્ય બનાવે છે.
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પ્રથમ આદેશ સાબિત કરે છે કે બેકએન્ડ ખાનગી નેટવર્કની અંદરથી સ્વસ્થ છે, બીજો દર્શાવે છે કે નામ શેમાં ઉકલે છે, અને ત્રીજો વાસ્તવિક 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તે જ બે પ્રોબ બેકએન્ડના પોતાના નેટવર્કથી ચલાવો જેથી નિરીક્ષિત સ્રોતને રનટાઇમે ઉત્પન્ન કરેલા સ્રોત સાથે સરખાવી શકાય. 200 પછી 401 અથવા 403 એ ઇચ્છિત આકાર છે; બે 200 એટલે નકાર માર્ગ ખરેખર લાગુ થતો નથી.
રોલબૅક જરૂર પડે તે પહેલાં લખો: કઈ મંજૂરી-યાદી એન્ટ્રી, નામાંકિત ક્રેડેન્શિયલ કે આઉટબાઉન્ડ જોડાણ તમે બદલ્યું, તેનો માલિક કોણ છે અને પાછલું મૂલ્ય કેવી રીતે પુનઃસ્થાપિત કરવું. પછી ટિકિટમાં ક્લાઉડ કૉલર અને સેવાનો સંપૂર્ણ માર્ગ નામ આપીને ચક્ર બંધ કરો, જેથી કોઈ એ જ મુદ્દો ફરી VPN સમસ્યા તરીકે ન ખોલે.