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 সমস্যা হিসেবে না খোলে।