صرف batch چلانے والے پرانے ERP کو SaaS سے کیسے جوڑیں گے؟

Question

IT Interview Practice · Accepted Answer

ایسا **غیر ہم وقت، بحال کیا جا سکنے والا تبادلہ** ڈیزائن کریں جو ERP کی batch حدود کا احترام کرے۔ پہلے قابلِ قبول کاروباری تاخیر اور ہر data entity کے مالک سسٹم پر اتفاق کریں؛ فی گھنٹہ import کے اوپر حقیقی وقت میں تکمیل کا وعدہ نہ کریں۔

## آرکیٹیکچر اور ملکیت

```text
[SaaS API/events] --> [Durable staging] --> [Mapping adapter]
                                               |
                                         [Batch files]
                                               |
                                         [ERP importer]
                                               |
[Status + reconciliation] <------------- [Result files]
```

فروخت کے ایک فرضی انضمام میں جمع شدہ آرڈر درخواست SaaS کی اور باقاعدہ درج شدہ مالیاتی دستاویز ERP کی ملکیت ہے۔ ان کی شناختوں کا واضح ملاپ کریں۔ Adapter حالات، اکائیوں اور فیلڈز کے مفہوم کو تبدیل کرتا ہے تاکہ ERP کے مخصوص طریقے SaaS سے متعلق workflow میں نہ پھیلیں۔

## ہر قدم کو بحال ہونے کے قابل بنائیں

جہاں ماخذ کا protocol اجازت دے وہاں وصولی کی تصدیق سے پہلے آنے والا کام مستقل محفوظ کریں۔ اگر polling ضروری ہو تو پائیدار checkpoint اور overlap یا replay کے اصول استعمال کریں تاکہ حدوں پر موجود ریکارڈ ضائع نہ ہوں۔ Batch شناختیں، ریکارڈ شناختیں، schema ورژن، تعداد اور checksums رکھیں۔ جہاں سہولت ہو مکمل فائلیں atomically شائع کریں، ورنہ تکمیل کا الگ marker استعمال کریں۔

ہر ریکارڈ کو pending، submitted، accepted یا rejected حالات میں ٹریک کریں۔ کامیاب فائل منتقلی کا مطلب کاروباری ریکارڈ کا درج ہو جانا نہیں۔ ERP کے نتائج پڑھیں اور صرف فائلوں کی تعداد کے بجائے کاروباری شناختوں اور رقوم کا ملاپ کریں۔ غلط ریکارڈ وجوہات اور جواب دہ آپریٹر کے ساتھ الگ رکھیں۔

## غیر واضح ناکامی سے نمٹیں

اگر ERP batch درج کر دے مگر اس کی تصدیق کھو جائے تو بغیر تحقیق دوبارہ بھیجنا کاروباری دستاویزات دہرا سکتا ہے۔ Retry سے پہلے ERP کی معاونت یافتہ duplicate key یا query اور reconciliation کی صلاحیت استعمال کریں۔ اگر دونوں موجود نہ ہوں تو غیر واضح ریکارڈ کو کنٹرول شدہ ملاپ کے لیے روکیں؛ صرف adapter کی ledger ERP میں exactly-once اثرات کی ضمانت نہیں دے سکتی۔

## گنجائش اور آپریشنز

تخمینہ کریں کہ کیا ایک import window جمع شدہ کام ختم کر سکتی ہے، بشمول زیادہ سے زیادہ حجم اور بندش کے بعد بحالی۔ Backpressure لگائیں اور صارفین کو حقیقت پسندانہ وقت کے ساتھ pending حالت دکھائیں۔ سب سے پرانے pending ریکارڈ کی عمر، مسترد ہونے کی شرح اور ملاپ کے فرق پر alerts دیں۔ Staging میں رکھی فائلیں محفوظ کریں اور رسائی اور retention کی ذمہ داریاں طے کریں۔

## انٹرویو میں اہم بات

Consistency کی حد اور بحالی کا عمل بیان کریں۔ “Queue شامل کر دیں” مفہومی mapping، جزوی قبولیت یا ایسے ERP کا مسئلہ حل نہیں کرتا جو retries میں دہراؤ نہیں روک سکتا۔ ڈیزائن compatibility کے بدلے فوری تکمیل چھوڑتا ہے اور اسے یہ تاخیر کاروبار کے سامنے واضح کرنی چاہیے۔

حوالہ: [Microsoft: anti-corruption layer](https://learn.microsoft.com/en-us/azure/architecture/patterns/anti-corruption-layer).

آرکیٹیکچر اور ملکیت

ہر قدم کو بحال ہونے کے قابل بنائیں

غیر واضح ناکامی سے نمٹیں

گنجائش اور آپریشنز

انٹرویو میں اہم بات

متعلقہ سوالات