Службы

Эта страница — каталог фоновых служб портала. Службы делают работу «за кадром»: отправляют почту, синхронизируют AD, чистят корзину, строят поисковый индекс, делают бэкапы.

Откройте: Админка → Службы.

Читайте сверху вниз для общего понимания или перейдите к нужной службе по оглавлению в сводке ниже.
Для разработчиков расширений дополнительно: Service Framework, Hot deploy.

---

0. Простыми словами: что такое служба

Понятие	Простыми словами
Служба	Именованная фоновая функция портала (строка в таблице Службы)
Включена / выключена	Тумблер: выключенная служба не выполняет задания
Расписание (cron)	Автозапуск по времени (например, каждую ночь в 03:00)
Запустить	Ручной одноразовый запуск из меню ⋮
Задание (job)	Единица работы в очереди; её выполняет процесс Portal.Worker
backup-runner	Отдельный процесс только для резервных копий (не обычный Worker)

Схема:

Событие в портале → Event Receivers → очередь portal_jobs → Worker
Расписание (cron) → portal_jobs (или portal_backups) → Worker / backup-runner

Важно: если служба выключена, Worker не выполняет её задания: они завершаются без ошибки (пропуск) и не попадают в журнал ошибок. Новые задания по cron для неё тоже не ставятся. Если ключа службы в реестре нет — задание падает со статусом failed: «Служба не найдена».

---

1. Как пользоваться таблицей «Службы»

Шаг 1.1. Откройте список

1. Войдите как администратор.
2. Админка → Службы.
3. Увидите таблицу со всеми встроенными службами: название, статус, расписание, время последнего запуска.

Шаг 1.2. Меню действий (⋮)

У каждой строки справа — меню ⋮. В зависимости от службы там могут быть:

Пункт	Что делает
Включить / Выключить	Тумблер службы
Запустить / Полный обход	Ручной запуск (где есть)
Очистить индекс	Только у поискового индекса
⚙ Настройки	Отдельная страница настроек
Расписание	Модальное окно с временем автозапуска

Шаг 1.3. Расписание

1. ⋮ → Расписание — откроется модальное окно (строка таблицы не раскрывается).
2. Включите автозапуск и задайте время в понятном виде.
3. Сохраните — в системе сохранится cronExpression и флаг cronEnabled.

В колонке расписания текст виден и при выключенном cron: рядом будет пометка (выкл).

Пример в БД/API: 0 3 * * * — каждый день в 03:00.

Worker перечитывает расписание из БД примерно раз в минуту (CRON_RELOAD_INTERVAL_MS, по умолчанию 60000).

Шаг 1.4. Справка и статусы

Элемент	Что увидеть
? у названия	Краткая справка (popover) со ссылкой на этот каталог
Колонка Последний	Время последнего запуска из журнала или по cron
Runner online	Не в таблице Служб — только на странице бэкапа и в Обзор → Обслуживание

Состояние индекса и корзины: Админка → Обзор → Обслуживание.
Срок хранения журнала заданий: Админка → Задания.

---

2. Ночные задания по умолчанию

После установки (если расписание ещё не меняли):

Служба	Когда	Вкл. по умолчанию
Резервное копирование (portal-backup)	02:00	расписание выкл (нужны путь и runner)
Поисковый индекс (search-crawler)	03:00	да
Экспорт списков — очистка файлов (list-export)	03:00	да (в БД; в UI пункта «Расписание» нет)
Экспорт опросов — очистка файлов (survey-export)	03:00	да (в БД; в UI пункта «Расписание» нет)
Корзина (recycle-bin)	04:00	да
Журнал заданий (jobs-cleanup)	05:00	да
Очистка чата (chat-cleanup)	03:00	да
КЭДО (kedo)	09:00	да (напоминания о сроке подписания)
Отпуска (модуль)	Timer Job korport.vacations.maintenance	да (см. Планирование отпусков)

---

3. Сводка встроенных служб

Порядок как в таблице Службы.

#	Ключ	Название	Вкл.*	Расписание в UI	Ручной запуск	Настройки
1	audit	Аудит	да	нет	нет	—
2	notifications	Уведомления	нет	нет	да (тест e-mail)	SMTP в Настройки
3	ad-sync	Синхронизация AD	нет	да	да	/services/ad-sync
4	search-crawler	Поисковый индекс	да + cron	да	да (полный обход)	—
5	recycle-bin	Корзина	да + cron	да	да	—
6	event-extensions	Event Receivers	да	нет	нет	вкладка Event Receivers
7	timer-extensions	Timer Jobs	да	нет**	нет	вкладка Timer Jobs
8	list-export	Экспорт списков	да	нет***	нет	—
9	survey-export	Экспорт опросов	да	нет***	нет	—
10	portal-backup	Резервное копирование	да	да	нет****	/services/portal-backup
11	jobs-cleanup	Журнал заданий	да + cron	да	да	retention на Задания
12	chat-cleanup	Очистка чата	да + cron	да	да	/services/chat-cleanup
13	kedo	КЭДО	да + cron	да	да	/kedo/settings

* Ориентир для новой установки; фактические флаги смотрите в таблице Службы.
** Расписание задаётся у экземпляров Timer Job, не у строки службы.
*** Cron purge в БД есть; пункта «Расписание» в меню ⋮ нет.
**** Копия / проверка / восстановление — со страницы настроек, не через «Запустить».

---

4. audit — Аудит {#audit}

Ключ: audit
В UI: «Журналирование событий портала».

Простыми словами

Служба пишет важные действия пользователей в журнал аудита. Сама по себе она «не бегает по ночам» — записи появляются, когда срабатывают подписчики Event Receivers.

Журнал смотрите на Админка → Обзор.

По умолчанию

• Служба включена.
• Расписания нет, кнопки «Запустить» в UI нет.

Что делает

Тип задания	Когда
audit.logEvent	Event Receiver среагировал на событие (чаще всего создание / изменение / удаление элемента списка)

Подписчики: Админка → Event Receivers.

Если выключить

Новые записи аудита через этот канал перестанут появляться. Старый журнал и экран обзора останутся.

Связанные материалы

• Event Receivers

---

5. notifications — Уведомления {#notifications}

Ключ: notifications
В UI: «Отправка почты через SMTP».

Простыми словами

Это шлюз исходящей почты портала. Пока служба выключена, портал не шлёт письма (ни по событиям, ни по API, ни тестовой кнопкой из Служб).

По умолчанию

• Служба выключена.
• Расписания нет — письма уходят по событиям и запросам.

Подготовка — по шагам

1. Откройте Админка → Настройки → SMTP / Почта.
2. Укажите host, порт, From, при необходимости логин и пароль.
3. Сохраните. При наличии кнопки теста SMTP — проверьте сервер (тест не требует включённой службы).
4. Откройте Админка → Службы.
5. У строки Уведомления → ⋮ → Включить.
6. Проверка реальной отправки: ⋮ → Запустить → введите e-mail → должно прийти тестовое письмо.

Настройки SMTP хранятся в конфиге службы notifications. Если в UI пусто — могут подставляться переменные SMTP_* из окружения сервера.

Откуда уходят письма

Источник	Что происходит
Event Receiver notifications.sendEventEmail	На событие ставится задание → Worker шлёт письмо по шаблону
API POST /api/v1/mail/send	В очередь или сразу (сразу — только admin)
⋮ → Запустить	Prompt e-mail → тестовое письмо

Если выключить

• Тест из ⋮ и /mail/send — ошибка.
• Задания уведомлений падают.
• Настройки SMTP и тест SMTP в Настройках остаются.

Не путать с пакетными обработчиками модулей (у них свой serviceKey) и со службой event-extensions.

Связанные материалы

• API: Почта
• SMTP в API админки
• Сценарии Event Receivers — уведомления

---

6. ad-sync — Синхронизация AD {#ad-sync}

Ключ: ad-sync
В UI: «Импорт и обновление доменных пользователей и групп из LDAP/AD».

Простыми словами

Служба забирает пользователей (и при желании группы) из Active Directory / LDAP в Portal: создаёт и обновляет учётки auth_source=domain, поля профиля, состав групп.

Без настроенного LDAP строка в таблице недоступна — нельзя включить, запустить или задать расписание.

По умолчанию

• Служба выключена, cron выкл.

Подготовка — по шагам

1. Службы → Синхронизация AD → ⚙ Настройки (адрес /services/ad-sync).
2. Откройте аккордеон Подключение:
   • URL каталога, Base DN, Bind DN и пароль;
   • фильтры входа/поиска, атрибут логина;
   • дождитесь badge статуса подключения.
3. Откройте Настройка синхронизации:
   • фильтры и лимиты пользователей / групп;
   • поля профиля — чекбоксы (givenName, sn, department, …) или «Выбрать все»;
   • дополнительные поля — ручной маппинг (например отчество → middleName);
   • флаги групп и деактивации (у каждого значок ⓘ с подсказкой).
4. Сохраните.
5. На вкладке Службы → ⋮ → Включить.
6. При необходимости ⋮ → Расписание или ⋮ → Запустить (без лишнего confirm; результат — тост / вкладка Задания).

Карточка пользователя с импортированными полями: Админка → Пользователи → /users/{id}.

Флаги синхронизации

Разделы UI Группы и Пользователи — разные настройки.

Флаг в UI	Config	Смысл
Синхронизировать группы AD	syncGroups	Импорт групп и участников. Выкл — только пользователи
Удалять участников, которых нет в AD-группе	removeMissingGroupMembers	Убрать из группы Portal; учётки не трогает
Удалять группы Portal, пропавшие из AD	removeMissingGroups	Удалить ранее импортированные группы вне фильтра; локальные группы не трогает
Деактивировать пользователей, отсутствующих в AD	cronDeactivateMissing	is_active=false для domain-пользователей вне выборки; работает и при ручном запуске, и по cron. Не про состав групп

Отчества в стандартном каталоге AD/Portal часто нет — добавьте в «Дополнительные поля».

Вложенные AD-группы не разворачиваются — только прямые member.

Тип задания: adSync.run. В ответе — счётчики users / groups (synced, created, updated, …).

Если выключить

Cron и ручной запуск недоступны. Уже импортированные пользователи и группы остаются. Вход через AD (если настроен отдельно) от этой службы не обязательно зависит.

Связанные материалы

• API: каталог / AD
• Группы доступа

---

7. search-crawler — Поисковый индекс {#search-crawler}

Ключ: search-crawler
В UI: «Полная переиндексация (сверка). Повседневные изменения индексируются сразу при сохранении».

Простыми словами

• Обычные правки (страницы, списки, документы) попадают в поиск сразу при сохранении — без этой службы.
• Служба нужна для полного ночного обхода или после кнопки «Очистить индекс».

По умолчанию

• Включена, cron ежедневно в 03:00 (0 3 * * *).

Что делать в админке

Действие	Как
Вкл/выкл	⋮
Расписание	⋮ → Расписание
Полный обход	⋮ → Запустить («Полный обход»)
Очистить индекс	кнопка у службы или POST /admin/search/clear (без постановки crawl)
Статус	Обзор → Обслуживание

Тип задания: searchCrawler.run.

Списки и библиотеки с выключенным «Участвует в поиске» в индекс не попадают.

Если выключить

Полный обход и его cron падают. Инкрементальная индексация при сохранении обычно продолжает работать.

Связанные материалы

• API: Поиск

---

8. recycle-bin — Корзина {#recycle-bin}

Ключ: recycle-bin
В UI: «Автоочистка корзины удалённых элементов узлов (старше 30 дней)».

Простыми словами

Служба окончательно удаляет из корзины объекты старше 30 дней. Срок зашит в код (RetentionDays) и не редактируется в настройках службы.

Мягкое удаление и экран корзины узла работают независимо от тумблера — служба отвечает только за автоочистку.

Типы объектов: элемент списка, страница, файл библиотеки, список, библиотека и др.

По умолчанию

• Включена, cron ежедневно в 04:00.

Что делать в админке

Действие	Как
Вкл/выкл	⋮
Расписание	⋮ → Расписание
Немедленная очистка	⋮ → Запустить
Счётчик	Обзор → Обслуживание

Тип задания: recycleBin.purgeExpired.

Если выключить

Автоочистка и ручной purge через службу останавливаются; объекты могут лежать в корзине дольше 30 дней.

Связанные материалы

• Корзина (пользователь)

---

9. event-extensions — Event Receivers {#event-extensions}

Ключ: event-extensions
В UI: «Пользовательские обработчики событий из пакетов .portalevent».

Простыми словами

Это рубильник для пакетных обработчиков событий. Сама служба не ходит по cron: при событии ставится задание, Worker загружает DLL пакета и вызывает обработчик.

Рекомендуемый serviceKey в манифесте пакета: "event-extensions". Если указать другой ключ — в реестре служб должна быть включённая строка с этим ключом, иначе задания упадут. Платформа сама не создаёт произвольные ключи (кроме upsert event-extensions при install).

По умолчанию

• Включена.
• Расписания и ручного запуска у строки нет.

Где управлять

Админка → Event Receivers — пакеты и привязки к спискам/событиям.

Если выключить

Пакетные ER с service_key=event-extensions не выполняются. Встроенные audit и notifications живут на своих ключах и этим тумблером не гасятся.

Связанные материалы

• Event Receivers
• Манифест
• Hot deploy

---

10. timer-extensions — Timer Jobs {#timer-extensions}

Ключ: timer-extensions
В UI: «Пользовательские задания по расписанию из пакетов .portaltimer».

Простыми словами

Рубильник для пакетных заданий по расписанию. Время запуска задаётся у каждого экземпляра на вкладке Timer Jobs, а не у строки службы в списке Служб.

Рекомендуемый serviceKey в манифесте: "timer-extensions".

По умолчанию

• Включена.
• У строки службы cron/run в UI нет.

Где управлять

Админка → Timer Jobs — экземпляры, расписание, ручной запуск экземпляра.

Если выключить

Пакетные timer-jobs с этим ключом не ставятся и не выполняются.

Связанные материалы

• Timer Jobs
• Манифест

---

11. list-export — Экспорт списков {#list-export}

Ключ: list-export
В UI: «Фоновый экспорт элементов списка в XLSX через worker».

Простыми словами

1. Пользователь в списке нажимает экспорт → Worker собирает файл XLSX (живёт 24 часа).
2. Ночью служба удаляет просроченные файлы экспорта.

По умолчанию

• Включена.
• В БД cron 0 3 * * * для purge; в UI меню ⋮ пунктов «Расписание» и «Запустить» нет.

Типы заданий

job_type	Назначение
listExport.run	Собрать XLSX
listExport.purgeExpired	Удалить файлы старше 24 часов

Что делать

Действие	Где
Заказать экспорт	UI списка (не строка службы)
Вкл/выкл	Службы → ⋮ — при выкл. и export, и purge падают
Расписание purge	только через API/БД (PATCH /services/list-export)

---

11.1. survey-export — Экспорт опросов {#survey-export}

Ключ: survey-export
В UI: «Фоновый экспорт результатов опросов в XLSX через worker».

Простыми словами

1. Автор опроса на странице Результаты нажимает Выгрузить в Excel → Worker собирает XLSX (листы Сводка и Ответы, живёт 24 часа).
2. Ночью служба удаляет просроченные файлы экспорта.
3. Для анонимного опроса в файле нет ФИО респондентов.

По умолчанию

• Включена.
• В БД cron 0 3 * * * для purge; в UI меню ⋮ пунктов «Расписание» и «Запустить» нет.

Типы заданий

job_type	Назначение
surveyExport.run	Собрать XLSX
surveyExport.purgeExpired	Удалить файлы старше 24 часов

Что делать

Действие	Где
Заказать экспорт	Страница Результаты опроса на узле (не строка службы)
Вкл/выкл	Службы → ⋮ — при выкл. и export, и purge падают
Расписание purge	только через API/БД (PATCH /services/survey-export)

См. также Опросы.

---

12. portal-backup — Резервное копирование {#portal-backup}

Ключ: portal-backup
В UI: «Архивы PostgreSQL + S3 + portal_data в каталог на хосте».

Простыми словами

Строка службы разрешает очередь и расписание в портале. Сама архив не пишет — это делает отдельный backup-runner.

В архиве обычно: PostgreSQL, файлы (S3), данные установки (portal_data). Подробная инструкция: Резервное копирование и восстановление.

Очередь — portal_backups (не portal_jobs): виды validate, backup, restore.

По умолчанию

• Служба включена.
• Предложен cron 0 2 * * *, но автозапуск выкл, пока не настроены путь и проверка.

Подготовка — по шагам

1. Поднимите backup-runner и смонтируйте каталог (PORTAL_BACKUP_HOST_DIR / PORTAL_BACKUP_MOUNT_PATH для Docker).
2. Откройте Службы → Резервное копирование → ⚙ Настройки (/services/portal-backup).
3. Аккордеон Резервное копирование: путь (в Docker — ровно mount path), retention, Проверить запись, создание копии, журнал, бейдж Runner online.
4. Аккордеон Восстановление: выбор копии из restorable, подтверждение, очередь restore.
5. Расписание: на вкладке Службы → ⋮ → Расписание (после успешного validate и online runner).

Включение cron требует: служба вкл, путь проверен (lastValidatedOk), runner online.

У строки службы кнопки Запустить нет (POST …/run отвергается).

Если выключить

Новые задания бэкапа из портала не ставятся. Архивы на диске не удаляются. CLI portal-cli backup может работать отдельно от UI-очереди.

Связанные материалы

• Резервное копирование и восстановление
• API админки — backups

---

13. jobs-cleanup — Журнал заданий {#jobs-cleanup}

Ключ: jobs-cleanup
В UI: «Автоудаление записей журнала заданий старше срока хранения».

Простыми словами

Чистит таблицу portal_jobs (историю заданий), а не бизнес-данные портала. Удаляет завершённые записи (completed / failed / dismissed) старше срока. Строки pending и running не трогает.

По умолчанию

• Включена, cron в 05:00.
• Срок хранения: 30 дней (допустимо 1…3650).

Что делать в админке

Действие	Как
Вкл/выкл, расписание, ручной purge	Службы → ⋮
Срок хранения	Админка → Задания → retention

Тип задания: jobs.purgeOlder.

Если выключить

Журнал перестанет автоматически сокращаться; ручной purge через службу тоже недоступен.

---

14. chat-cleanup — Очистка чата {#chat-cleanup}

Ключ: chat-cleanup
В UI: «Ночное удаление старых сообщений и вложений корпоративного чата».

Простыми словами

По расписанию (или вручную) удаляет старые сообщения и файлы в Portal.Chat. Имеет смысл только если установлен модуль чата и PORTAL_CHAT_ENABLED=true.

Установка runtime и модуля: Корпоративный чат.

По умолчанию

• Включена, cron в 03:00.
• Сообщения: 365 дней, вложения: 180 дней (0 = не удалять).

Владельцы групповых чатов могут задавать свои сроки в UI чата; глобальные — в настройках службы.

Что делать в админке

1. Службы → Очистка чата → ⚙ Настройки (/services/chat-cleanup) — задайте сроки.
2. ⋮ → Включить (если выкл).
3. ⋮ → Расписание и/или ⋮ → Запустить.

Тип задания: chat.purgeOlder (через PORTAL_CHAT_INTERNAL_URL).

Если выключить

Автоочистка и ручной purge останавливаются; данные чата накапливаются.

---

14.1. kedo — КЭДО (устарело как builtin)

С версии korport.kedo 2.0 напоминания — Timer Job korport.kedo.reminders внутри модуля (списки Portal). Встроенная служба kedo / job kedo.remindPending отключена миграцией и не регистрируется в BuiltinServices.

UI: /kedo/pages/home. Platform SDK: KedoCryptoService + KedoPackageAdapter, job kedo.createIntegrationPackage (отпуска и др.). Доменные SQL-таблицы КЭДО сняты миграцией 083; в SQL остаются только crypto (kedo_ca, kedo_certificates, kedo_key_blobs).

См. КЭДО.

---

14.2. Отпуска (модуль, не встроенная служба)

С версии korport.vacations 2.0 обслуживание отпусков — Timer Job korport.vacations.maintenance и Event Receiver korport.vacations.workflow внутри модуля (списки Portal). Встроенной службы vacations / job vacations.maintenance больше нет.

См. Планирование отпусков.

---

15. Пакетные службы модулей

Встроенные службы из таблицы выше — фиксированный набор платформы.

Пакеты .portalevent / .portaltimer и модули обычно используют serviceKey: "event-extensions" или "timer-extensions".

Если в манифесте указан свой ключ (например korport.helpdesk.ticket-notifications):

• подписчик/job ссылается на этот ключ;
• при установке пакета, подписчика и модуля в portal_services появляется включённая строка с тем же ключом (её можно выключить в Админка → Службы);
• повторная установка той же версии модуля тоже проверяет, что строка есть.

Управление пакетами: вкладки Event Receivers и Timer Jobs.

---

16. Компоненты и API (справочник)

Компоненты

Компонент	Назначение
portal_services	Реестр служб
portal_jobs	Очередь большинства служб
portal_backups	Очередь validate / backup / restore
event_receivers	Подписчики на события
Worker	Опрос очереди, cron, hot-load пакетов
backup-runner	Отдельный процесс для бэкапов

API (только portal_admin)

Метод	Путь	Описание
GET	/admin/dashboard	Обзор
POST	/admin/search/clear	Очистить поисковый индекс
GET	/services	Список служб
PATCH	/services/{key}	Вкл/выкл, cron, config
POST	/services/{key}/run	Ручной запуск (где есть)
GET	/jobs	Журнал заданий
POST	/jobs/{id}/retry	Повторить задание
GET/PUT	/jobs/settings/retention	Срок журнала
GET/POST/PATCH/DELETE	/event-receivers	Подписчики

Поля расписания

Поле	Описание
cron_enabled	Включить автозапуск
cron_expression	Cron (5 полей)
cron_job_type	Тип задания (в UI не редактируется)
cron_last_run_at	Последний запуск по расписанию

Переменные Worker

• WORKER_POLL_INTERVAL_MS — опрос очереди (по умолчанию 5000)
• WORKER_BATCH_SIZE — размер пакета (по умолчанию 10)
• CRON_RELOAD_INTERVAL_MS — перезагрузка расписания (по умолчанию 60000)

Для почты и бэкапа см. также SMTP_*, PORTAL_BACKUP_* в установке и backup-restore.

Добавление обработчика (разработка)

1. Реализуйте обработчик в Worker (IJobHandler) или пакет .portalevent / .portaltimer.
2. Для платформы — регистрация в BuiltinServices / JobProcessor.
3. Для пакета — манифест + install; подписчик или Timer Job через админку / API / module.json.

См. Job-модули, SDK Event Receiver, SDK Timer Job.