Работа с конфигурацией Платформы 

Реализовано 3 способа проверки и применения конфигурации Платформы:

для проверки конфигурации (не)сохраненной функции (check функции);
для проверки сохраненной, но еще не примененной конфигурации (check кластера);
для проверки с применением конфигурации (apply кластера).

При запуске этих операций выполняется проверка успешности компиляции библиотек, необходимых для работы сервисов. При многократном запуске операций их выполнение помещается в независимые очереди.

Генерируются и компилируются следующие библиотеки:

Библиотека типов.
Типы данных.
Метаданные.
Перечисления.
Интерфейсы.
Группы.
Дополнительные служебные функции и расширения.
Пользовательские методы.
Определение функции.
Входящий/исходящий трансформаторы.
Библиотека функций.
Процессы.
Алгоритмы.
Библиотека маппинга для процессов.
Шаги Установка переменных.
Шаги Запуск БП.
Настройки маппинга в шагах процессов (вкладки Локальные переменные, После выполнения).
Библиотека маппинга для каждого сервиса UI.
Библиотеки обработчиков - для каждой активной системы (кроме 1С) создается своя библиотека с кодом обработчиков, привязанных к этой системе.

Проверка (Check)

При запуске проверки компилируется (но не применяется) вся модель указанного уровня. При компиляции считается и запоминается хеш от версий и идентификаторы всех объектов конфигурации.

Проверка процессов и алгоритмов 

Проверка запускается в редакторах процессов и алгоритмов. При этом компилируется библиотека и возвращается результат компиляции. Библиотека типов компилируется только если были изменения в ее объектах. Проверять можно как сохраненные, так и не сохраненные процессы.

При выполнении функции check:

В Центре настройки появляется запись о результате проверки в разделе Обслуживание → Управление конфигурацией.
В логах сервера Центра настройки в зависимости от успешности проверки:
- При успешной проверке: сообщение о сохранении временной dll с идентификатором.
- При неуспешной проверке: сообщение о допущенной в функции ошибке с указанием места ошибки.

При запуске проверки нескольких процессов или алгоритмов, все проверки выполняются в порядке очереди. По результатам каждой проверки в Управлении конфигурацией фиксируется отдельная запись.

Проверка конфигурации 

Проверка запускается в ЦН в разделе Обслуживание → Управление конфигурацией, либо посредством нажатия на значок в плашке нужного кластера в правом верхнем углу рабочей области ЦН.

При запуске проверки всегда запоминается контрольная сумма от всех объектов скомпилированной конфигурации. Если пользователь запустил проверку еще раз, эта проверка помещается в очередь. Если в момент подхода очереди текущая версия конфигурации идентична скомпилированной, возвращается готовый ответ без компиляции. При выполнении проверки конфигурации происходят следующие события:

В Центре настройки появляется всплывающее окно и запись в разделе Обслуживание → Управление конфигурацией с результатом проверки:
- При успешной проверке Проверка конфигурации прошла успешно!.
- При неуспешной проверке в тексте ошибки перечислены причины.
В логах сервера Центре настройки в зависимости от успешности проверки:
- При успешной проверке и совпадении контрольной суммы с текущей контрольной суммой выводится одно сообщение Проверка конфигурации кластера [идентификатор Кластера].
- При успешной проверке и несовпадении контрольной суммы в процессе проверки происходит сохранение dll конфигурации. Начало проверки - Проверка конфигурации кластера [идентификатор Кластера]. Окончание проверки - Выполнена проверка конфигурации кластера [идентификатор Кластера].
- при неуспешной проверке в логах сообщения выводится сообщение о допущенной в функции ошибке с указанием места ошибки.
При выполнении действия check из очереди учитываются сохраненные изменения, т.е. действие из очереди выполняется на той конфигурации, которая актуальна на момент начала выполнения, а не на момент вызова этой операции.

Применение конфигурации (Apply)

Для применения текущей конфигурации используется кнопка Применить конфигурацию:

При применении конфигурации производятся следующие действия:

В логах сервера управления в зависимости от успешности проверки.
- При успешной проверке и совпадении контрольной суммы происходит проверка, применена ли конфигурация, и выводится сообщение с актуальной версией. Если не применена - применяется.
- Начало применения: Применение нового состояния метаданных для кластера [идентификатор Кластера].
- Регистрация конфигурации на применение: Обновление актуальной конфигурации в хранилище.
- Завершение проверки конфигурации на применение и ее сохранение: Обновление актуальной конфигурации в хранилище завершено успешно.
- Окончание действия apply: Настройки репликации Центра настройки успешно применены. Версия ххх.
- При успешной проверке и несовпадении контрольной суммы происходит сохранение dll конфигурации и применение конфигурации. Начальное и конечное сообщение в логах как в прошлом пункте.
- При неуспешной проверке выводится сообщение начала действия apply, сообщения о сохранении dll конфигурации и об ошибке.
В логах узла присутствуют записи только об успешных конфигурациях.
- При совпадении версии с предыдущей. действия apply: Поступило ping сообщение от ControlServer.
- Окончание действия apply: Применение конфигурации сети, версия ххх.
- При несовпадении версии с предыдущей происходит запуск необходимых компонентов.
В Центре настройки запись об успешном применении появляется в момент передачи стабильной конфигурации на применение в Node. Это значит, что конфигурация скомпилирована, но еще не применена на узлах. В Центре настройки появляется всплывающее окно и запись в разделе Обслуживание с результатом проверки:
- При успешной проверке: Применение конфигурации прошло успешно!.
- При неуспешной проверке в тексте ошибки перечислены причины.
В Журнале действий пользователя (при использовании Guard - в журнале Guard) сохраняется применение стабильной конфигурации для кластера и центров настройки (настройки репликации).

Если предыдущая компиляция еще не завершена, при многократном запуске apply конфигурация нового применения отличается от выполняемой в данный момент. При этом происходит отмена предыдущей компиляции и начинается компиляция по последнему запуску проверки.

Проверка компиляции маппинга и обработчиков происходит после успешной компиляции библиотеки основных объектов. Т.е. если есть ошибка в маппинге, и при этом допущены более серьезные ошибки (для переменной используется несуществующий тип данных или удалена вложенная функция), то при проверке сначала отобразятся эти более серьезные ошибки (так как для компиляции всех прочих библиотек библиотека функций должна скомпилироваться успешно). И только после их устранения будет выдано сообщение об ошибке маппинга, обработчиков или процессов. После успешной компиляции Центр настройки передает обновленную конфигурацию на координатор для рассылки и применения на узлах. Узлы при получении команды на обновление конфигурации сначала сравнивают номера версий (полученной и фактической) и запускают процесс обновления только в случае их отличия. Кроче того, если узел получает новую версию конфигурации в момент перезапуска, обновление останавливается и снова запускается процесс обновления уже по последней версии.

Устранение ошибок обновления 

Откат на предыдущую версию конфигурации 

В Центре настройки возможен отказ на примененную ранее конфигурацию с помощью метода post/api/{clusterId}/metadata/restoreStable. При этом все сохраненные и непримененные изменения будут удалены.

Внимание

Откат выполняется на версию, которая была применена в последний раз, а не фактическую конфигурацию кластера.

Рассинхронизация версий 

Кластер при получении команды на обновления от Центра настройки выполняет сравнение версий конфигурации. Если текущая конфигурация более новая, координатор отклоняет обновление и сообщает Центру настройки номер его версии. Для установки более старой версии на кластер предусмотрен параметр versionBefore, в котором устанавливается номер версий кластера, которую необходимо заместить.

Обновление от неизвестного Центра настроек 

При получении команды обновления от Центра настройки кластер проверяет получена ли команда от текущего хоста, где находится сам координатор. Если команда получена с другого сервера, то выполняется проверка вхождения этого хоста в список известных серверов. Если команда получена от сервера, который не входит в кластер и там не зарегистрирован Центр настройки для данного кластера, то координатор отклоняет обновление. Для регистрации нового Центра настройки необходимо выполнить команду на хосте координатора с указанием адреса Центра настройки:

Для Windows:

DatareonPlatformService.exe SetCS <ip adress>

Для Linux:

sudo /usr/bin/datareon/platform/DatareonPlatformService setCS <ip adress>

После выполнения команды требуется отправить обновление повторно.