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