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 مسئلہ بنا کر نہ کھولے۔