Единый вход OAuth 2.0
Пользователь проходит авторизацию в ядре. Подключённый модуль получает его идентичность; доступ к функциям определяется назначенными правами.
Эдуполис /За 18 системами —
Платформа · для ИТ-службы
За 18 системами —
общее основание.
Отдельные рабочие приложения опираются на единые учётные записи, структуру организации и правила обмена. Так результат в одном процессе может стать началом другого.
Три уровня
Как устроена связность
01 / Общее ядро
Люди, структура и полномочия
Edupolis.ID хранит учётные записи, группы, подразделения и назначения. Роль назначается человеку или наследуется от подразделения.
02 / Прикладные системы
Свои рабочие данные и процессы
Расписание ведёт занятия; журнал — результаты; документооборот — основания изменений; биллинг — расчёты. Общие сведения связываются с ядром.
03 / Внешняя среда
Учёт, идентификация и оборудование
Подключение выполняется через предусмотренные механизмы и требует настройки организации. Наличие интерфейса не означает подключение любой внешней системы.
Условия каждой интеграции →От входа до события
Что происходит между модулями
Общие справочники
Люди, подразделения, группы и кураторы имеют согласованные связи. Это снижает потребность в отдельных несвязанных списках для каждого рабочего места.
События об изменениях
Ядро передаёт подписанным модулям события об изменении персон, учебных записей, групп и назначений. Настройка подписок входит в подготовку обмена.
Межсистемный API
Ключи и права определяют допустимые вызовы. Например, начисления поступают в биллинг по API, а приказ передаёт изменения учебных сведений в ядро.
Размещение и эксплуатация
Состав можно вводить поэтапно
Своё размещение или серверы правообладателя
Выбор закрепляется в предложении и договоре. При своём размещении заранее согласуются домены, HTTPS, сеть, сервисы и зона ответственности.
Лицензионные ключи
Лицензия проверяется локально. Для внешних интеграций отдельно планируется сетевой доступ к соответствующим провайдерам и оборудованию.
Обновления и сопровождение
Перед обновлением готовят резервную копию и согласуют порядок работ. После — проверяют вход, роли и критические процессы между системами.
Резервные копии и восстановление
В эксплуатационном плане определяют состав данных и файлов, периодичность копирования, хранение и ответственного. Восстановление проверяют на выбранном контуре.
Охват и ёмкость
Что подтверждает масштаб
18 систем в публичном каталоге, шесть разобранных процессов и девять рабочих ролей. Проверяются по страницам и демо.
Проверяется конкретным маршрутом: документ-основание, изменение данных, получение результата следующим модулем.
Предел одновременных пользователей и скорость на больших объёмах здесь не заявлены: для них нужен отдельный протокол испытаний.
Что зафиксировать в нагрузочных испытаниях
Версию ПО и конфигурацию серверов; объём данных; набор операций; число одновременных пользователей; время ответа и долю ошибок; длительность прогона; результаты проверки после восстановления. Показатели демо не заменяют такие испытания.
Следующий шаг
Подготовим технический разговор
Обсудим контур размещения, состав систем, интеграции и критерии приёмки до расчёта работ.