پیغام کا لائف سائیکل بمقابلہ کم ڈیلیوری کا طریقہ کار

پیغام کا لائف سائیکل بمقابلہ کم ڈیلیوری کا طریقہ کار.

API قبولیت اور ابتدائی صف کی حالت

جب کوئی API کلائنٹ میسجنگ اینڈ پوائنٹ پر SMS کی درخواست بھیجتا ہے، تو پلیٹ فارم سنٹیکس کی توثیق اور پری پیڈ لیجر کی اجازت کو انجام دیتا ہے۔ منزل کا نمبر E.164 فارمیٹ کے مطابق ہونا ضروری ہے، چاہے وہ OTP الرٹس ہوں یا عمومی اطلاعات۔ پیغام کو اسٹیٹ مشین میں منتقل کرنے سے پہلے، انجن یہ تصدیق کرتا ہے کہ اکاؤنٹ میں کم از کم USD 20 کا بیلنس موجود ہے۔

اگر درخواست درست ہو تو پیغام کو ایک منفرد شناخت فراہم کی جاتی ہے اور اسے ابتدائی صف میں شامل کر دیا جاتا ہے۔ یہ مرحلہ نیٹ ورک پر زیادہ بوجھ کو روکتا ہے اور کیریئر کو پیغام منتقل کرنے سے پہلے تمام ریکارڈز کو محفوظ کرتا ہے۔

پروسیسنگ حالت اور کیریئر ہینڈ آف کے طریقے

صف میں شامل ہونے کے بعد، اندرونی ڈسپیچر ریکارڈ کو آؤٹ باؤنڈ پائپ لائن میں منتقل کرتا ہے۔ اس مرحلے کے دوران، انجن منزل کی روٹنگ کے قواعد، بھیجنے والے کی شناخت اور نیٹ ورک کی دستیابی کا جائزہ لیتا ہے۔ اگر آؤٹ باؤنڈ ٹریفک کے لیے مخصوص شناخت کی ضرورت ہو، تو سسٹم بغیر کسی تاخیر کے JIT کی تخصیص کرتا ہے۔

جب بہترین راستہ منتخب کر لیا جاتا ہے، تو پیغام پروسیسنگ کی حالت میں چلا جاتا ہے۔ اس نقطہ پر پلیٹ فارم تمام سرگرمیوں پر مکمل نظر رکھتے ہوئے موبائل کیریئر کو ڈیٹا منتقل کرتا ہے۔

غیر ہم آہنگ DLR منتقلی اور خرابی کے کوڈز

سینٹ سے آخری حالت میں منتقلی ڈیلیوری رپورٹس (DLR) کے ذریعے ہوتی ہے۔ موبائل کیریئر delivery status جیسے کہ delivered، undelivered یا failed واپس بھیجتا ہے۔ اگر ہینڈ سیٹ تک رسائی ممکن نہ ہو، تو کیریئر کے ٹائمرز ختم ہونے تک DLR زیر التوا رہتا ہے۔

اگر ڈیلیوری ناکام ہو جائے تو سسٹم خرابی کے کوڈز کا تفصیلی تجزیہ کرتا ہے۔ مثال کے طور پر، اگر نیٹ ورک غلط نمبر یا بلاک شدہ ٹریفک کا کوڈ واپس کرتا ہے، تو پلیٹ فارم فوری طور پر اسٹیٹس کو اپ ڈیٹ کر دیتا ہے۔

پری پیڈ لیجر ہولڈز اور پلیٹ فارم کے حدود

ہر اسٹیٹ کی تبدیلی براہ راست پری پیڈ لیجر کے مالیاتی ریکارڈ سے منسلک ہوتی ہے۔ ابتدائی سبمیشن منزل کے نرخوں اور پیغام کے حصوں کی بنیاد پر عارضی ہولڈ تیار کرتی ہے۔ جب اکاؤنٹس میں ٹریفک بڑھتی ہے اور USD 1,000 کی حد عبور ہوتی ہے، تو خودکار نظام کی جانچ کی جاتی ہے۔

پیغام کامیابی سے موصول ہونے پر، ہولڈ کی گئی رقم حتمی طور پر کاٹ لی جاتی ہے۔ اگر نیٹ ورک کی خرابی کی وجہ سے ڈیلیوری ناکام ہو جائے، تو سسٹم خودکار طور پر ہولڈ رقم واپس اکاؤنٹ میں شامل کر دیتا ہے۔

اسٹیٹ مشین کی مشاہدہ پذیری اور ویب ہوک انضمام

کلائنٹ کی درخواست میں اسٹیٹ ٹریکنگ کو مربوط کرنے کے لیے ریئل ٹائم HTTP ویب ہوکس کو ترتیب دینے کی ضرورت ہوتی ہے۔ جیسے ہی پیغامات صف سے سینٹ اور بالآخر DLR تک پہنچتے ہیں، پلیٹ فارم تصدیق شدہ کال بیکس بھیجتا ہے جن میں پیغام کی شناختی معلومات اور وقت شامل ہوتا ہے۔

یہ طریقہ کار تمام سرگرمیوں میں مکمل شفافیت فراہم کرتا ہے۔ ڈیوپلیپرز ڈیلیوری کے مسائل کی آسانی سے تشخیص کر سکتے ہیں اور ہر پیغام کی حالت میں تبدیلی پر خودکار اقدامات کر سکتے ہیں۔

متعلقہ: کیوڈ پیغام کے لیے فنڈز کو ہولڈ کرنا ضروری ہے، بھیجا گیا سمجھ کر وضع نہ کریں · کیوڈ بمقابلہ سینٹ: IOSOR میں ایک ہی پیغام کا راستہ · پہلی کٹوتی سے پہلے پری پیڈ رقم محفوظ کرنا.

IOSOR کے ساتھ شروع کریں

IOSOR کنسول کھولیں اور اپنے سسٹم کے پیغام کی درخواست کے ہینڈلرز کو براہ راست اسٹیট مشین کے کال بیک اینڈ پوائنٹس پر میپ کریں۔ اپنی ایپلیکیشن لاجک کو اس بات کی تصدیق کرنی چاہیے کہ داخلی پیغام کے ریکارڈ کی حالت کو قطار سے بھیجے گئے تک اپ ڈیٹ کرنے سے پہلے ویب ہک سگنیچر کی جانچ کی جائے۔ اپنے ایونٹ ہینڈلرز کو نقلی غیر مطابقت پذیر DLR پے لوڈز کے خلاف ٹیسٹ کریں تاکہ یہ تصدیق ہو سکے کہ لیجر ہولڈز بیک وقت کی درخواستوں کو روکے بغیر مطابقت پذیر ہوتے ہیں۔

IOSOR خلاصہ

پیغام کی پروسیسنگ ایک تعیناتی فنائٹ اسٹیStateException کے طور پر کام کرتی ہے جہاں ہر منتقلی ایک تجریدی ترسیل کے میٹرک کے بجائے ایک تصدیق شدہ تکنیکی واقعہ کی عکاسی کرتی ہے۔ ابتدائی API جمع کرانے اور قطار کی توثیق سے لے کر کیریئر ہینڈ آف اور فائنل اسنکرونس DLR کال بیکس تک، اسٹیٹ میکینکس کو الگ تھلگ کرنے سے ایونٹ پائپ لائنز اور ایرر میپنگ کی مکمل مرئیت ملتی ہے۔