سو مراحل والا ایک فرضی براؤزر کام لیجیے۔ فرض کریں ہر مرحلہ دوسرے مراحل سے آزاد ہو کر 99% بار کامیاب ہوتا ہے۔ ہر مرحلے کے درست ہونے کا امکان 0.99^100، یعنی تقریباً 36.6% ہے۔
ننانوے فیصد بہت اچھا لگتا ہے۔ چھتیس فیصد نہیں۔
براؤزر میں لین دین کے کام پر ماخذ کی گفتگو اس حساب سے محدود نکتہ واضح کرتی ہے: صارف کو قدر کام مکمل ہونے پر ملتی ہے، جبکہ ہر مرحلے پر لاگت اور ناکامی کا خطرہ بڑھتا ہے۔ یہ ایک مفروضے کے تحت حساب ہے، کسی براؤزر ایجنٹ یا Tajo سنک کی شائع شدہ کامیابی کی شرح نہیں۔ حقیقی غلطیاں ایک دوسرے پر منحصر ہو سکتی ہیں۔ ایک ختم شدہ لاگ ان کئی بعد کے اعمال بگاڑ سکتا ہے۔
اس لیے مفید سوال یہ نہیں کہ “ماڈل کی آخری کلک کتنی درست تھی؟” بلکہ یہ ہے کہ “کیا صارف کی مطلوبہ حالت وجود میں آئی؟”
اہم اکائی پورا لین دین ہے
تصور کریں ایجنٹ بیمے کا پورٹل کھولتا ہے، دستاویز ڈھونڈتا ہے، ڈاؤن لوڈ کرتا ہے اور تصدیق کرتا ہے کہ وہ درست اکاؤنٹ کی ہے۔ وہ 99 اسکرینوں پر صحیح چل کر سوویں پر غلط فائل لے سکتا ہے۔ کامیاب کلکس کا بھرا لاگ نتیجہ نہیں سنوارتا۔
انٹیگریشن میں بھی یہی فرق ہے۔ ایجنٹ API ڈھونڈ سکتا ہے، فیلڈ میپ تجویز کر سکتا ہے اور مسودہ محفوظ کر سکتا ہے۔ ان میں سے کوئی قدم یہ ثابت نہیں کرتا کہ منزل کے رابطے میں مطلوبہ رضامندی کی حالت آ گئی ہے۔ کام تب مکمل ہے جب منظور شدہ عمل ہو جائے اور اس کے متعلقہ آخری نتیجے کی جانچ ہو۔
یہ سرگرمی اور تکمیل کا فرق ہے۔ سرگرمی گننا آسان ہے۔ تکمیل کی تعریف درکار ہے۔
فائل ڈاؤن لوڈ کے لیے تعریف ایسی فائل ہو سکتی ہے جس کا اکاؤنٹ نمبر درخواست سے ملے۔ رابطہ سنک کے لیے یہ منزل کا ریکارڈ ہو سکتا ہے جس کی شناخت، فیلڈز اور اجازت یافتہ پیغام رسانی کی حالت درست ہو۔ جانچ کو وہی شے دیکھنی چاہیے جس کی صارف کو فکر ہے۔ پچھلی کال کا سبز جواب صرف کال کے جواب کا ثبوت ہے، منزل کے مطلوبہ بدلنے کا لازمی ثبوت نہیں۔
Tajo کی کاروباری ٹولز کو جوڑنے کی رہنما تحریر ہر ڈیٹا شے کے ورک فلو اور مستند ماخذ سے شروع کرتی ہے۔ یہی فیصلے آخری جانچ کو معنی دیتے ہیں۔ اگر دو نظام ایک فیلڈ کی ملکیت کا دعویٰ کریں تو بالکل درست تحریر بھی طویل مدت میں غلط حالت بنا سکتی ہے۔
ایک اور فیصلے کی قیمت
اسی فرضی 99% کے تحت دس آزاد فیصلوں سے پوری زنجیر کی کامیابی تقریباً 90.4%، پچاس سے 60.5% اور سو سے 36.6% رہتی ہے۔
پوری زنجیر کی کامیابی کا امکان (%)
آزاد مراحل کی تعداد
- فرضی 99% کامیابی فی مرحلہ
حساب شدہ قدریں دیکھیں
| مراحل | پوری زنجیر کی کامیابی (%) |
|---|---|
| 0 | 100.0 |
| 10 | 90.4 |
| 25 | 77.8 |
| 50 | 60.5 |
| 75 | 47.1 |
| 100 | 36.6 |
منحنی تیزی سے گرتا ہے کیونکہ ضرب اچھی اوسط کا لحاظ نہیں کرتی۔ ہر اضافی فیصلے کو اپنی جگہ ثابت کرنی چاہیے۔
اس کا مطلب یہ نہیں کہ ہر API کال ایک بڑے عمل میں سمو دی جائے۔ بعض کالز قطعی ہیں: معلوم کرسر سے صفحہ لینا، شناختی قدر ملانا یا منظور شدہ میپ کے مطابق فیلڈ لکھنا۔ ماڈل کو ہر ریکارڈ پر یہ فیصلے دوبارہ نہیں کرنے چاہییں۔ دوسری کالز میں حقیقی ابہام ہے: فراہم کنندہ کی نئی فیلڈ، بدلا ہوا غلطی کا پیغام یا ایسی درخواست جس کا مالک واضح نہیں۔ وہاں فیصلے کی ضرورت ہو سکتی ہے۔
عملی تقسیم یہ ہے کہ فیصلہ ایک قاعدہ بنائے یا درست کرے، پھر عام کوڈ مستحکم قاعدہ چلائے۔ Reverse ETL بار بار ڈیٹا منتقل کرنے کی مثال ہے: معمول کی ہر قطار پائپ لائن چلائے، گفتگو نہیں۔ ایجنٹ پھر بھی طے کرنے میں مدد دے سکتا ہے کہ پائپ لائن کو کیا کرنا چاہیے۔
یہ حد ہے، نعرہ نہیں۔ اگر فراہم کنندہ فیلڈ کا مطلب بدل دے تو قطعی قاعدہ غلط کام بے عیب انداز میں دہرا سکتا ہے۔ نظام کو اپنے مفروضے بدلنے کی خبر پانے اور معاملہ جائزے کو لوٹانے کا راستہ چاہیے۔
ایک بڑا ٹول جواب کیوں نہیں
معقول اعتراض ہے: “طویل زنجیر ناکام ہو تو پورا کام ایک ٹول کال کے پیچھے رکھ دیں۔” یہ تب مدد دیتا ہے جب ٹول واضح لین دین ہو جس کا نتیجہ جانچا جا سکے۔ اگر وہ صرف طویل غیر یقینی عمل چھپائے تو ناکام ہے۔
فرض کریں syncCustomer() اپ ڈیٹ بھیج کر success: true لوٹاتا ہے۔ اگر منزل اپ ڈیٹس بعد میں لگاتی ہے تو کال ابھی رابطے کی آخری حالت ثابت نہیں کر سکتی۔ ٹول نے نظر آنے والے مراحل کم کیے، غیر یقینی صورتحال نہیں۔
بہتر انٹرفیس اہم حالتیں واضح کرے: درخواست قبول ہوئی، تبدیلی لاگو ہوئی، جانچ ہوئی یا ناکامی ہوئی۔ ہر لفظ کے پیچھے ثبوت ہو۔ کم اثر والے پیش نظارے کے لیے قبول شدہ تحریر کافی ہو سکتی ہے۔ مہم کی آڈیئنس یا رضامندی بدلنے سے پہلے منزل کی جانچ ضروری ہے۔
Tajo کے اس مجوزہ منظر میں درخواست کی قبولیت اور تبدیلی کا اطلاق منزل کی تصدیق سے الگ ہیں۔ آخری جانچ اب بھی باقی ہے۔ اگلا کام واضح ہے: دیکھیں منزل نے کیا محفوظ کیا۔ ایک اور کامیاب ٹول کال گننا اصل سوال کا جواب نہیں دیتا۔
ڈیٹا لکھنے کا کام مکمل ہو تب بھی ثبوت چاہیے
کیا گاہکوں کا سنک مکمل ہوا؟
ڈیٹا لکھا گیا۔ تصدیق باقی ہے۔
منزل کی حالت ابھی نہیں جانچی گئی۔
سنک کی سرگرمی
- درخواست قبول ہوئی
- تازہ کاری لاگو ہوئی
- منزل کی جانچ باقی ہے
نمونہ اجرا · 14:32 UTC
ہم کیا جانتے ہیں
- فراہم کنندہ کا جواب
- قبول شدہ
- ڈیٹا لکھنے کا نتیجہ
- لاگو شدہ
- منزل سے دوبارہ پڑھنا
- زیر التوا
کامیاب کال آخری حالت ثابت نہیں کرتی۔
یہ مجوزہ ترتیب Tajo کی سرگرمی فیڈ پر مبنی ہے۔ خاکے میں تصدیق کی حالت شامل ہے، لیکن یہ دعویٰ نہیں کہ منزل سے دوبارہ پڑھنا پہلے سے نافذ ہے۔
اس سے پیمائش بھی بدلتی ہے۔ کوششوں کی تعداد تشخیص میں مدد دے تو محفوظ کریں۔ درمیانی غلطیاں خراب مرحلہ دکھائیں تو انہیں درج کریں۔ مگر ورک فلو کو تصدیق شدہ مکمل لین دین سے جانچیں، ساتھ طریقۂ تصدیق بھی لکھیں۔ “99% کالز کامیاب رہیں” بتانے والی ٹیم نے ابھی یہ نہیں بتایا کہ صارفین کا کام ہوا یا نہیں۔
MCP سرور کی وضاحت دکھاتی ہے کہ ٹولز معاون کو دوسرے نظام سے کال کیسے کراتے ہیں۔ ٹول تک رسائی محض آغاز ہے۔ اصل وعدہ پیچھے رہ جانے والی حالت ہے۔
سو اچھی کلکس کے بعد بھی کچھ ہاتھ نہ آئے۔ نتیجہ گنیے۔
اکثر پوچھے گئے سوالات
ہر مرحلہ عموماً درست ہونے کے باوجود طویل ورک فلو کیوں ناکام ہوتا ہے؟
اگر ہر مرحلہ آزادانہ امکان p سے کامیاب ہو تو n مراحل کی زنجیر کا امکان p کی طاقت n ہے۔ فرضی 99% فی مرحلہ پر سو مراحل تقریباً 36.6% بار مکمل ہوتے ہیں۔ حقیقی ناکامیاں باہم متعلق بھی ہو سکتی ہیں، اس لیے یہ ایجنٹ کی ناپی گئی شرح نہیں بلکہ مثال ہے۔
کیا ٹول کالز کم کرنے سے اعتبار کی ضمانت ملتی ہے؟
نہیں۔ کم کالز تب مدد دیتی ہیں جب مشترکہ عمل درست جانچ اور بحالی کے مقامات دکھائے۔ ایک غیر شفاف کال ناکام تحریر کو اسی طرح چھپا سکتی ہے جیسے طویل زنجیر راستہ کھو سکتی ہے۔
ٹیم ایجنٹ ورک فلو میں کیا ناپے؟
صرف ماڈل کالز کی کامیابی نہیں بلکہ صارف کے لین دین کی تصدیق شدہ تکمیل ناپے۔ وہ فائل یا منزل کی حالت طے کرے جو کام مکمل ہونے کا ثبوت ہو، پھر دیکھے کہ پوری کارروائی کے بعد وہ کتنی بار ملتی ہے۔