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 समस्या के रूप में न खोले।