Skip to main content

Интеграција со повеќекорисничка архитектура

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 обвивка за врски за управување преку домени:

$url = wu_with_sso($main_site_customer_url);

Генерираната URL-адреса останува филтрирачка преку wu_sso_url, кој ги прима SSO URL-адресата, тековниот корисник, ID-то на целниот сајт и контекстот за пренасочување. Додатоците можат да го користат тој филтер за да додадат контекст специфичен за давател или да ја заменат URL-адресата на посредникот, притоа зачувувајќи ја валидацијата на токени на Ultimate Multisite.

Не дуплирајте состојба за членство, фактура, адреса за наплата, шаблон или управување со домен во суверениот закупец. Третирајте ја контролната табла на закупецот како стартувач, а корисничкиот панел на главниот сајт како систем на евиденција за управувани дејства.

Проверка на миграција

Откако миграција или интеграција на животниот циклус ќе ги промени податоците на закупецот, извршете ги проверувачките порти:

  • wp tenant verify-no-legacy --site=<site-id> потврдува дека закупецот повеќе не зависи од застарени патеки од мрежната страна.
  • wp tenant verify-sovereign-push --site=<site-id> потврдува дека задачите за суверено испраќање можат да се обработат и испразнат.

Интеграциите треба да ја третираат неуспешната проверка како блокатор на распоредување и да избегнуваат означување на закупецот како активен додека неуспехот не се реши.

Бришење закупец

Тековите за бришење треба да ја повикаат патеката за растурање на додатокот за да се исчистат акредитивите за базата на податоци на закупецот. Надворешните интеграции може да отстранат ресурси на давателот откако растурањето ќе успее, но не треба да бришат хост бази на податоци или папки додека проверката или асинхроните задачи за испраќање сè уште се извршуваат.

Застарен рутер за база на податоци

Застарениот Database_Router е заменет со stub за застарување. Новите интеграции треба да ги разрешуваат закупците преку тековниот рутер на сајтот и API-ите на регистарот на закупци, наместо да зависат од старата класа на рутер.