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 ब्राउझरमध्ये लोड करणारी टनेल इंटिग्रेशनला पूर्वीप्रमाणेच त्याच टाइमआउटसह अपयशी ठेवू शकते. कोणी फायरवॉल संपादित करण्यापूर्वी ती चूक थांबवण्यासाठी कॉलर कार्ड आहे.
कॉलर प्रत्यक्षात वापरू शकतो ते प्रवेशद्वार निवडा
दोन्ही रचना वैध आहेत, आणि त्या वेगवेगळ्या समस्या सोडवतात. पहिली म्हणजे हेतुपुरस्सर सार्वजनिक प्रवेश: कॉलरचे प्रमाणीकरण करणारे, अरुंद परवानग्या लागू करणारे आणि खाजगी बॅकएंडशी संरक्षित कनेक्शन ठेवणारे 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 समस्या म्हणून उघडणार नाही.