ملٹی ٹیننٹ آرکیٹیکچر کیا ہے؟

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

کانٹیکٹ سینٹر پلیٹ فارم کے لیے داؤ غیر معمولی طور پر بلند ہیں، کیونکہ متعلقہ ڈیٹا کال ریکارڈنگز، کسٹمر کانٹیکٹ لسٹیں، رضامندی کے ریکارڈز اور سپریشن لسٹیں ہیں۔ ایک پلیٹ فارم پر مسابقتی کلائنٹس چلانے والے BPO پر انہیں الگ رکھنے کی معاہداتی اور اکثر ریگولیٹری ذمہ داری ہوتی ہے، اور لیک کوئی معمولی تکلیف نہیں بلکہ ایک واقعہ (incident) ہے۔

علیحدگی کہاں نافذ ہونی چاہیے

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

ہر ٹیننٹ کے لیے کیا مختلف ہونا چاہیے

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

DialerBee ملٹی ٹیننسی کو کیسے نافذ کرتا ہے

DialerBee کا ملٹی ٹیننٹ آرکیٹیکچر ہر ٹیننٹ کو ڈیٹا بیس کی سطح پر PostgreSQL row-level security سے نافذ شدہ الگ ڈیٹا دیتا ہے، نیز ڈو-ناٹ-کال لسٹوں، کالنگ اوقات اور رضامندی کی ٹریکنگ پر مشتمل آزاد تعمیل قواعد، ہر ٹیننٹ کی الگ اسٹوریج کے ساتھ الگ کال ریکارڈنگز، آزاد ریٹینشن اور لیگل ہولڈ، استعمال، منٹس اور سیٹس کو الگ الگ ٹریک کرنے والی فی ٹیننٹ بلنگ، ایجنٹس اور سپروائزرز کو ان کے ٹیننٹ تک محدود کرنے والا رول بیسڈ ایکسیس کنٹرول، فی ٹیننٹ AI ٹیوننگ، اور ایڈمن پورٹل یا API کے ذریعے منٹوں میں ٹیننٹ پروویژننگ۔ یہ 11 زبانوں میں دستیاب ہے، ہر ٹیننٹ کی ڈیفالٹ زبان کے ساتھ۔

یہ حد ڈیٹا بیس پر رکنے کے بجائے باقی پلیٹ فارم میں بھی جاری رہتی ہے۔ اینالیٹکس میں ہر ڈیش بورڈ اور رپورٹ موجودہ ٹیننٹ تک محدود ہے، تاکہ BPO کلائنٹس صرف اپنا ڈیٹا دیکھیں جبکہ پلیٹ فارم مالکان کراس ٹیننٹ اینالیٹکس تک رسائی رکھیں، اور ٹیننٹ کی حدیں ڈیٹا بیس کی سطح پر نافذ ہیں۔ کالر ID کی ملکیت صرف ایک ٹیننٹ کے لیے مخصوص ہے، جو اس نمبر کو جس کے آپ ذمہ دار ہیں کسی اور کی کالز پر ظاہر ہونے سے روکتی ہے، اور ہر ٹیننٹ کو الگ روٹیشن قواعد اور رپورٹنگ کے ساتھ اپنے کالر ID پولز ملتے ہیں۔ ٹرانسکرپٹ ڈیٹا row-level security کے ذریعے فی ٹیننٹ علیحدگی کے ساتھ محفوظ ہوتا ہے، اور ریٹینشن ہر ٹیننٹ کے لیے قابلِ ترتیب ہے۔ وائٹ لیبل ڈیپلائمنٹس میں پارٹنر ایڈمن اپنے بنائے ہوئے ٹیننٹس کا مالک ہوتا ہے، اور آن بورڈنگ وزرڈ ہر ٹیننٹ کی اپنی ایکسٹینشن رینج اور اپنی کالر IDs مقرر کرتا ہے، کیونکہ ڈیفالٹس آپس میں ٹکراتے ہیں اور مشترکہ ٹرنک کالر ID نہیں ہوتا۔

اکثر پوچھے جانے والے سوالات

ملٹی ٹیننٹ اور سنگل ٹیننٹ میں کیا فرق ہے؟

سنگل ٹیننٹ ڈیپلائمنٹ میں ہر کسٹمر کو سافٹ ویئر کا اپنا انسٹینس اور اکثر اپنا انفراسٹرکچر ملتا ہے۔ ملٹی ٹیننٹ ڈیپلائمنٹ میں کسٹمرز انفراسٹرکچر اور کوڈ شیئر کرتے ہیں، اور الگ کاپیوں کے بجائے ایپلیکیشن اور ڈیٹا بیس کے ذریعے الگ کیے جاتے ہیں۔ ملٹی ٹیننسی چلانا اور اپ گریڈ کرنا سستا ہے؛ سنگل ٹیننسی فی کسٹمر کہیں زیادہ لاگت پر جسمانی علیحدگی دیتی ہے۔

row-level security کیا ہے؟

ڈیٹا بیس کا ایک فیچر جو کسی ٹیبل سے پالیسی منسلک کرتا ہے تاکہ کوئری صرف وہی قطاریں واپس کرے جنہیں دیکھنے کا موجودہ ٹیننٹ حقدار ہو۔ یہ اس لیے اہم ہے کہ متبادل، یعنی ایپلیکیشن کی ہر کوئری میں ٹیننٹ کے لحاظ سے فلٹر کرنا، اس پر منحصر ہے کہ ہر ڈویلپر ہر بار یاد رکھے۔ اسے ڈیٹا بیس کی سطح پر نافذ کرنے کا مطلب ہے کہ فلٹر بھولنے والی کوئری سب کچھ کے بجائے کچھ بھی واپس نہیں کرتی۔

کیا ملٹی ٹیننسی کا مطلب ہے کہ میرا ڈیٹا دوسرے کسٹمرز کے ساتھ ملا ہوا ہے؟

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

ہر ٹیننٹ کو اپنی ایکسٹینشن رینج اور کالر IDs کیوں درکار ہیں؟

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

ہر ٹیننٹ کے لیے کیا قابلِ ترتیب ہونا چاہیے؟

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

متعلقہ اصطلاحات: وائٹ لیبل کانٹیکٹ سینٹر پلیٹ فارم, BPO کانٹیکٹ سینٹر, کنسنٹ مینجمنٹ, کالر ID اور لوکل پریزنس اور DID.