اس صفحہ پر
آرڈر کی اپ ڈیٹ آرڈر بنانے کے واقعے سے پہلے آ جاتی ہے۔ دوسری جگہ ادائیگی کا واقعہ اس سے پہلے والے اشتراک کے واقعے سے پہلے آتا ہے۔ یہ مختلف مصنوعات اور پی لوڈز استعمال کرنے والی مثالی ٹیمیں ہیں۔ دونوں ترسیل کو آمد کے وقت سے ترتیب دینے کی طرف مائل ہیں۔
یہ دونوں ٹیموں کے حادثے کی رپورٹ نہیں۔ سوال ہے کہ فراہم کنندہ کی تفصیل مختلف ہونے کے باوجود ناکامی کی شکل مشترک ہے یا نہیں۔
ریاضی کے ربط پر حاصل شدہ گفتگو دیکھتی ہے کہ بظاہر مختلف مسائل کی مفید ساخت ایک ہو سکتی ہے۔ اس خیال کو سافٹ ویئر انٹیگریشن پر لگانا استنباط ہے۔ یہ تبھی مفید بنتا ہے جب مشترک ساخت ایسی آزمائش دے جس کی دونوں نظاموں کی دستاویزی صورت تائید کرے۔
نام ہٹائیں، پھر معاہدے واپس لائیں
پہلی صورت کو پروڈکٹ نام کے بغیر بیان کریں: کسی وسیلے کا واقعہ اسی وسیلے کی بعد کی تبدیلی کے بعد پہنچ سکتا ہے۔ وصول کنندہ آمد کی ترتیب کو حالت کی ترتیب سمجھے تو نئی معلومات پرانی سے مٹا سکتا ہے۔
اب دونوں حقیقی معاہدے دیکھیں۔ Shopify کی ویب ہک دستاویز کہتی ہے موضوع کے اندر بھی ترتیب یقینی نہیں، اور مثال دیتی ہے کہ پروڈکٹ اپ ڈیٹ پروڈکٹ بنانے کی ترسیل سے پہلے پہنچ سکتی ہے۔ Stripe کی ویب ہک دستاویز بھی کہتی ہے واقعات بننے کی ترتیب میں پہنچنا یقینی نہیں اور متوقع پرانا واقعہ نہ آئے تو غائب آبجیکٹ حاصل کرنے کی تجویز دیتی ہے۔
Shopify اور Stripe دونوں خبردار کرتے ہیں کہ ترسیل کی ترتیب یقینی نہیں۔ مشترک سوال آخری حالت کی درستی کا ہے؛ ہر فراہم کنندہ کی شناخت اور بحالی الگ آزمائش مانگتی ہے۔
منتقل ہونے والا سوال یہ ہے: “یہ واقعہ متعلقہ واقعے سے پہلے آئے تو کیا ہم اب بھی درست موجودہ حالت بنا سکتے ہیں؟” نفاذ کا جواب مفروضے سے منتقل نہیں ہوتا۔ Shopify X-Shopify-Webhook-Id جیسے ہیڈرز اور وقت درج کرتی ہے۔ Stripe اپنی واقعہ شناخت اور آبجیکٹ حاصل کرنے کے قواعد رکھتی ہے۔ ایک نظام میں “ترسیل” کی شناخت دوسرے میں وہی معنی نہیں رکھتی۔
ہماری Brevo کنیکٹر رہنما تحریر فیلڈ اور میپنگ کی الگ تفصیل دیکھتی ہے۔ کام کرتی انٹیگریشن کے لیے یہ اہم ہے، مگر اسے عالمگیر API رویہ نہ سمجھیں۔
مشترک شکل برقرار رہنے والا اصول ہے
گاہک سنک میں اصول ہو سکتا ہے: عمل کے بعد منزل کا گاہک ریکارڈ مجاز ماخذ کی موجودہ حالت دکھائے۔ بلنگ میں ہو سکتا ہے: ادائیگی پر منحصر عمل صرف مستند ادائیگی حالت اجازت دے تو ہو۔ اصول بتاتا ہے کیا درست رہنا چاہیے، چاہے واقعات دیر سے، دوبارہ یا نامکمل آئیں۔
اصلاح چننے سے پہلے چار چیزیں لکھیں:
| سوال | اہمیت |
|---|---|
| کون سی شناخت کاروباری آبجیکٹ کو نام دیتی ہے؟ | واقعہ شناخت پیغام کی ہو سکتی ہے، گاہک یا آرڈر کی نہیں۔ |
| موجودہ حالت کس نظام کی ملکیت ہے؟ | پی لوڈ پوری حالت، تبدیلی یا محض اشارہ ہو سکتا ہے۔ |
| ماخذ وقت کے بارے میں کیا ضمانت دیتا ہے؟ | ترسیل کی ترتیب حالت کی ترتیب نہیں ہو سکتی۔ |
| کون سی اختتامی شرط کامیابی ثابت کرتی ہے؟ | واقعہ وصول ہونا منزل کی درستی ثابت نہیں کرتا۔ |
جدول سوچنے کا ذریعہ ہے، پروٹوکول نہیں۔ مستند ماخذ ورک فلو پر منحصر ہے۔ ایک نظام میں براہ راست تلاش لازم اور دوسرے میں غلط ہو سکتی ہے۔ کچھ واقعات نئی حالت میں سمٹنے کے بجائے تاریخی حقائق کے طور پر محفوظ ہونے چاہییں۔
آزمائش دہرائیں، علاج موافق بنائیں
چھوٹی معاہدہ جاتی آزمائش متعلقہ واقعات الٹی ترتیب میں بھیج کر پوچھ سکتی ہے کہ منزل کی آخری حالت درست ہے یا نہیں۔ دوسری ایک ہی ترسیل دو بار بھیجے۔ یہ خطرے کی ساخت دکھاتی ہیں۔ پھر فراہم کنندہ کی دستاویز طے کرتی ہے کہ واقعے کی شناخت، تصدیق اور بحالی کیسے ہوگی۔
یہ فرق ٹیم کو نقل شدہ تعمیر سے بچاتا ہے۔ ایک API کی نقل روکنے والی کلید دوسری میں ناکام ہو سکتی ہے۔ کم دقت کا وقت ترتیب ثابت نہیں کرتا۔ موجودہ آبجیکٹ لانا حالت کی سنک کے لیے ضروری ہو سکتا ہے، مگر ہر درمیانی تاریخی واقعہ دوبارہ نہیں بنا سکتا۔ متعدد کاروباری ٹولز جوڑنے کی رہنما تحریر پہلے ہر فیلڈ کا مالک طے کرتی ہے؛ اس کے بغیر “تازہ ترین” کا مطلب واضح نہیں۔
نمونہ منتقل کرنے کی حد ہے۔ ملتے اثرات مختلف اسباب سے آ سکتے ہیں: غائب ریکارڈ غیر مجاز تلاش، دیر سے ویب ہک، غلط میپنگ یا مسترد تحریر کا نتیجہ ہو سکتا ہے۔ دو صورتیں برابر کہنے سے پہلے ماخذ معاہدہ، منزل معاہدہ اور دیکھی ہوئی اختتامی شرط ملائیں۔ ایک بھی مختلف ہو تو مشترک سوال رکھیں، آزمائش بدلیں۔
یہ طریقہ واقعہ ترسیل سے آگے بھی مفید ہے۔ API نے فیلڈ قبول کی مگر صارف کے ریکارڈ میں نہ آئی تو ہر کنیکٹر میں عام سوال اٹھتا ہے: منظوری کا جواب کیا ثابت کرتا ہے، اور مطلوبہ حالت کس ثبوت سے ثابت ہوگی؟ جواب میں منزل سے پڑھنا، اسکیما تلاش یا اجازت جانچ ہو سکتی ہے۔ نمونہ ٹیم کو منتقلی اور معنی الگ رکھنا بتاتا ہے۔ یہ نہیں بتاتا کون سی فیلڈ یا عمل کال کرنا ہے۔ عالمگیر انٹیگریشن نسخے سے یہ سبق کم دلچسپ لگتا ہے، مگر مقامی حقائق دکھانے کی وجہ سے زیادہ دور جاتا ہے۔
بہترین دہرایا جانے والا سبق سنبھالنے والے کوڈ کا ٹکڑا نہیں۔ وہ سوال ہے جو دوسرے نظام تک جائے اور مقامی معاہدہ دیکھنا آسان کرے۔
اکثر پوچھے گئے سوالات
کیا ایک انٹیگریشن آزمائش مختلف فراہم کنندگان میں دہرائی جا سکتی ہے؟
سوال اکثر منتقل ہوتا ہے، مثلاً اپ ڈیٹس بے ترتیب آ سکتی ہیں یا نہیں۔ مگر واقعات کی شناخت، پی لوڈ کا معنی، دستخط اور بحالی ہر فراہم کنندہ کے معاہدے سے لینے ہوں گے۔
نمونے اور نقل کی ہوئی اصلاح میں کیا فرق ہے؟
نمونہ ناکامی کی شرط اور برقرار رہنے والا اصول بتاتا ہے۔ نقل شدہ اصلاح بنا جانچے فرض کرتی ہے کہ دوسرے نظام کی شناخت، ترتیب اور حالت کے معنی یکساں ہیں۔
واقعہ لگانے کے بعد کیا جانچیں؟
ورک فلو کی مطلوبہ منزل حالت، نہ کہ صرف واقعے کی وصولی یا HTTP جواب۔ اختتامی شرط کاروباری آبجیکٹ اور مستند ماخذ کے قاعدے پر منحصر ہے۔