Multi-Tenancy ინტეგრაცია

Ultimate Multisite: Multi-Tenancy 1.2.0 ცვლის რამდენიმე ინტეგრაციის შეხების წერტილს სუვერენული ტენანტებისთვის, მიგრაციის შემოწმებისთვის და ტენანტის სასიცოცხლო ციკლის ავტომატიზაციისთვის.

ტენანტის საწყისი გაშვების ნაკადი

ინტეგრაციებმა, რომლებიც ქმნიან ან ცვლიან ტენანტებს, უნდა დაიცვან ეს თანმიმდევრობა:

1. განსაზღვრეთ ტენანტის რეესტრის ჩანაწერი და იზოლაციის მოდელი.
2. შექმენით ან გადაამოწმეთ ტენანტის მონაცემთა ბაზის ჩამწერი.
3. საწყისად გაუშვით ტენანტის სქემა.
4. მოამარაგეთ ტენანტის მომხმარებლები.
5. დაარეგისტრირეთ ტენანტის მარშრუტიზაცია და ფაილური სისტემის ბილიკები.
6. გაუშვით მიგრაციის შემოწმება ტენანტის გამოჩენამდე.

ნუ ჩათვლით, რომ სუვერენულ ტენანტს შეუძლია ქსელის მონაცემთა ბაზის კავშირის ხელახლა გამოყენება. გამოიყენეთ ტენანტის რეესტრი და ჩამწერის აბსტრაქციები, რომლებსაც დამატება უზრუნველყოფს.

SSO და REST ჰუკები

უსახელმწიფო ტენანტის ავტოშესვლა იყენებს მოკლევადიან ტოკენებს დანიშნულების მოთხოვნით, JTI ხელახლა გამოყენებისგან დაცვით, ვადის ზედა ზღვარით და წყაროს მიბმით. ინტეგრაციებმა, რომლებიც ამატებენ შესვლის ღილაკებს ან დისტანციური მართვის ბმულებს, ტენანტის ვიზიტები უნდა შექმნან მხარდაჭერილი SSO ნაკადის მეშვეობით, ნაცვლად იმისა, რომ პირდაპირ ააგონ ტენანტის შესვლის URL-ები.

ქსელის მხარის API აუდიტის მოვლენები და ყოველდღიური შეჯამებები ხელმისაწვდომია სუვერენული ტენანტის კარიბჭეებისთვის. გამოიყენეთ ეს ჟურნალები გარე სისტემების გამართვისას, რომლებიც ტენანტის სასიცოცხლო ციკლის endpoint-ებს იძახებენ.

სუვერენული მომხმარებლის ქმედებების URL-ები

Ultimate Multisite v2.13.0 სუვერენული ტენანტის მომხმარებლის ქმედებებს აბრუნებს მთავარ საიტზე account-ის, checkout-ის, ბილინგის, ინვოისის, საიტის, შაბლონის გადართვისა და დომენის მიბმის ნაკადებისთვის. ინტეგრაციებმა, რომლებიც ტენანტის მხარეს მართვის ბმულებს აჩვენებენ, ეს ქმედებები უნდა მიმართონ მთავარი საიტის მომხმარებლის პანელზე და ჩართონ დადასტურებული დაბრუნების სამიზნე, როდესაც მომხმარებელს ქმედების დასრულების შემდეგ ტენანტზე დაბრუნების შესაძლებლობა უნდა ჰქონდეს.

გამოიყენეთ ძირითადი SSO შემომხვევი cross-domain მართვის ბმულებისთვის:

$url = wu_with_sso($main_site_customer_url);

გენერირებული URL კვლავ გაფილტვრადია wu_sso_url-ის მეშვეობით, რომელიც იღებს SSO URL-ს, მიმდინარე მომხმარებელს, სამიზნე საიტის ID-ს და გადამისამართების კონტექსტს. დამატებებს შეუძლიათ გამოიყენონ ეს ფილტრი პროვაიდერისთვის სპეციფიკური კონტექსტის დასამატებლად ან ბროკერის URL-ის შესაცვლელად, Ultimate Multisite-ის ტოკენის ვალიდაციის შენარჩუნებით.

ნუ დაადუბლირებთ membership-ის, ინვოისის, ბილინგის მისამართის, შაბლონის ან დომენის მართვის მდგომარეობას სუვერენული ტენანტის შიგნით. ტენანტის Dashboard განიხილეთ როგორც გამშვები, ხოლო მთავარი საიტის მომხმარებლის პანელი — როგორც მართვადი ქმედებებისთვის ჩანაწერის სისტემური წყარო.

მიგრაციის შემოწმება

მას შემდეგ, რაც მიგრაცია ან სასიცოცხლო ციკლის ინტეგრაცია შეცვლის ტენანტის მონაცემებს, გაუშვით შემოწმების კარიბჭეები:

• wp tenant verify-no-legacy --site=<site-id> ადასტურებს, რომ ტენანტი აღარ არის დამოკიდებული ძველ ქსელის მხარის ბილიკებზე.
• wp tenant verify-sovereign-push --site=<site-id> ადასტურებს, რომ სუვერენული push დავალებები დამუშავებასა და დაცლას შეძლებს.

ინტეგრაციებმა ჩავარდნილი შემოწმება უნდა განიხილონ როგორც განთავსების ბლოკერი და თავი აარიდონ ტენანტის live-ად მონიშვნას, სანამ პრობლემა არ მოგვარდება.

ტენანტის წაშლა

წაშლის ნაკადებმა უნდა გამოიძახონ დამატების teardown ბილიკი, რათა ტენანტის მონაცემთა ბაზის ავტორიზაციის მონაცემები გაიწმინდოს. გარე ინტეგრაციებმა შეიძლება წაშალონ პროვაიდერის რესურსები teardown-ის წარმატებით დასრულების შემდეგ, მაგრამ არ უნდა წაშალონ ჰოსტის მონაცემთა ბაზები ან საქაღალდეები, სანამ შემოწმება ან ასინქრონული push დავალებები ჯერ კიდევ მიმდინარეობს.

მოძველებული მონაცემთა ბაზის როუტერი

ძველი Database_Router ჩანაცვლებულია მოძველების stub-ით. ახალმა ინტეგრაციებმა ტენანტები უნდა განსაზღვრონ მიმდინარე საიტის როუტერისა და ტენანტის რეესტრის API-ების მეშვეობით, ძველ როუტერის კლასზე დამოკიდებულების ნაცვლად.