Multi-Tenancy ইন্টিগ্রেশন
Ultimate Multisite: Multi-Tenancy 1.2.0 সার্বভৌম টেন্যান্ট, মাইগ্রেশন যাচাই এবং টেন্যান্ট লাইফসাইকেল অটোমেশনের জন্য কয়েকটি ইন্টিগ্রেশন টাচপয়েন্ট পরিবর্তন করে।
টেন্যান্ট বুটস্ট্র্যাপ প্রবাহ
যে ইন্টিগ্রেশনগুলো টেন্যান্ট তৈরি বা পরিবর্তন করে, সেগুলোর এই ক্রম অনুসরণ করা উচিত:
- টেন্যান্ট রেজিস্ট্রি রেকর্ড এবং আইসোলেশন মডেল নির্ধারণ করুন।
- টেন্যান্ট ডাটাবেস writer তৈরি বা যাচাই করুন।
- টেন্যান্ট স্কিমা বুটস্ট্র্যাপ করুন।
- টেন্যান্ট ব্যবহারকারী প্রভিশন করুন।
- টেন্যান্ট রাউটিং এবং ফাইলসিস্টেম পাথ নিবন্ধন করুন।
- টেন্যান্ট প্রকাশ করার আগে মাইগ্রেশন যাচাই চালান।
ধরে নেবেন না যে একটি সার্বভৌম টেন্যান্ট নেটওয়ার্ক ডাটাবেস সংযোগ পুনরায় ব্যবহার করতে পারে। addon-প্রদত্ত টেন্যান্ট রেজিস্ট্রি এবং writer abstraction ব্যবহার করুন।
SSO এবং REST hook
স্টেটলেস টেন্যান্ট autologin স্বল্পমেয়াদি token ব্যবহার করে, যার মধ্যে purpose claim, JTI replay protection, expiry cap এবং origin pinning থাকে। যে ইন্টিগ্রেশনগুলো লগইন বাটন বা রিমোট ম্যানেজমেন্ট লিংক যোগ করে, তাদের সরাসরি টেন্যান্ট লগইন URL বানানোর বদলে সমর্থিত SSO প্রবাহের মাধ্যমে টেন্যান্ট ভিজিট তৈরি করা উচিত।
সার্বভৌম টেন্যান্ট gateway-এর জন্য নেটওয়ার্ক-পক্ষের API audit event এবং দৈনিক সারাংশ উপলভ্য। টেন্যান্ট লাইফসাইকেল endpoint-এ কল করা বাহ্যিক সিস্টেম ডিবাগ করার সময় এই লগগুলো ব্যবহার করুন।
সার্বভৌম গ্রাহক অ্যাকশন URL
Ultimate Multisite v2.13.0 সার্বভৌম-টেন্যান্ট গ্রাহক অ্যাকশনগুলোকে Account, checkout, billing, invoice, site, template-switching এবং domain-mapping প্রবাহের জন্য মূল সাইটে ফিরিয়ে রাউট করে। যে ইন্টিগ্রেশনগুলো টেন্যান্ট-পক্ষের ম্যানেজমেন্ট লিংক রেন্ডার করে, তাদের সেই অ্যাকশনগুলো মূল-সাইট গ্রাহক প্যানেলের দিকে নির্দেশ করা উচিত এবং অ্যাকশন শেষ করার পর ব্যবহারকারী যেন টেন্যান্টে ফিরে যেতে পারে, সে ক্ষেত্রে একটি যাচাইকৃত return target অন্তর্ভুক্ত করা উচিত।
ক্রস-ডোমেইন ম্যানেজমেন্ট লিংকের জন্য core SSO wrapper ব্যবহার করুন:
$url = wu_with_sso($main_site_customer_url);
তৈরি হওয়া URL wu_sso_url-এর মাধ্যমে filterable থাকে, যা SSO URL, বর্তমান ব্যবহারকারী, লক্ষ্য সাইট ID এবং redirect context পায়। Add-on গুলো ওই filter ব্যবহার করে provider-নির্দিষ্ট context যোগ করতে পারে বা Ultimate Multisite-এর token validation বজায় রেখে broker URL বদলাতে পারে।
সার্বভৌম টেন্যান্টের ভেতরে membership, invoice, billing-address, template বা domain-management state নকল করবেন না। টেন্যান্ট Dashboard-কে launcher হিসেবে এবং মূল-সাইট গ্রাহক প্যানেলকে পরিচালিত অ্যাকশনের system of record হিসেবে বিবেচনা করুন।
মাইগ্রেশন যাচাই
কোনো মাইগ্রেশন বা লাইফসাইকেল ইন্টিগ্রেশন টেন্যান্ট ডাটা পরিবর্তন করার পর verification gate চালান:
wp tenant verify-no-legacy --site=<site-id>নিশ্চিত করে যে টেন্যান্ট আর legacy network-side path-এর ওপর নির্ভরশীল নয়।wp tenant verify-sovereign-push --site=<site-id>নিশ্চিত করে যে sovereign push job প্রক্রিয়া করতে এবং drain করতে পারে।
ইন্টিগ্রেশনগুলোর উচিত ব্যর্থ যাচাইকে deployment blocker হিসেবে বিবেচনা করা এবং ব্যর্থতা সমাধান না হওয়া পর্যন্ত টেন্যান্টকে live হিসেবে চিহ্নিত না করা।
টেন্যান্ট মুছে ফেলা
Deletion flow-গুলোতে addon teardown path কল করা উচিত, যাতে টেন্যান্ট ডাটাবেস credential পরিষ্কার করা হয়। Teardown সফল হওয়ার পর বাহ্যিক ইন্টিগ্রেশন provider resource সরাতে পারে, কিন্তু verification বা async push job এখনও চলতে থাকলে host database বা folder মুছে ফেলা উচিত নয়।
অবচয়িত ডাটাবেস router
পুরনো Database_Router একটি deprecation stub দিয়ে প্রতিস্থাপিত হয়েছে। নতুন ইন্টিগ্রেশনগুলোর উচিত পুরনো router class-এর ওপর নির্ভর না করে বর্তমান সাইট router এবং টেন্যান্ট registry API-এর মাধ্যমে টেন্যান্ট নির্ধারণ করা।