Введение
Думаю, многие из вас хотя бы слышали о технологии Фреш, а кто-то даже использовал на своих проектах. На данный момент, кроме «1С:Облачная подсистема Фреш. Руководство разработчика» (далее Руководство) от 1С, в интернете по ней довольно мало материала, нужного программисту. Доработки, вводящие какой-то новый функционал именно с учетом Фреша, приходится делать, ориентируясь только на вышеупомянутое Руководство. В этой статье я хочу рассказать о такой доработке, которую мы сделали на одном из своих проектов. Буду рад вопросам, конструктивной критике, идеям для развития и прочей обратной связи.
Итак, начальные условия:
Есть одна большая распределенная информационная база (РИБ) ЗКГУ, в которой некоторые данные (Должности, Начисления и т.п.). редактируются только централизованно из центральной ИБ (Рут). Нужно перевести ее во фреш, сохранив возможность централизованного редактирования и добавить возможность так же из одного места редактировать права пользователей во всех областях данных (ОД).
О разделении
Прежде, чем продолжать, нужно внести ясность, что такое область данных, разделенные и неразделенные данные. Позволю себе прямой копипаст из Руководства:
При работе в модели сервиса используется механизм разделения данных, который позволяет разделить все хранимые данные на отдельные части. При использовании механизма разделения данных все данные, хранящиеся в информационной базе, и объекты метаданных, соответствующие этим данным, могут быть разделены на следующие виды:
- Общие (неразделенные) данные — данные, которые являются общими для всех областей данных и не разделяются общими реквизитами-разделителями. Из сеансов, в которых установлены значения разделителей, общие данные доступны только для чтения;
- Разделенные данные — данные, относящиеся к области данных, разделяются общими реквизитами-разделителями.
При использовании механизма разделения данных:
- изменяется поведение объектов конфигурации, входящих в состав общего реквизита (далее — разделителя);
- для каждого разделителя в информационной базе определяется текущее значение разделителя и признак использования данного разделителя;
- данные информационной базы, доступные для выбранных значений разделителей, и данные неразделенных объектов конфигурации называются областью данных.
Во всех операциях чтения записей базы данных «1С:Предприятие» автоматически отбирает только те записи, в которых значения используемых разделителей совпадают с текущими значениями разделителей.
Например, справочник «Виды доходов НДФЛ» неразделенный, потому что они для всех общие, а справочник «Должности» разделенный, т.к. в каждом учреждении они могут быть свои.
Переход во Фреш заключается в выгрузке дампа из базы «на земле» и загрузке его в качестве области данных в базу «в облаке». Здесь тоже есть несколько подводных камней (в основном, связанных с дублями в неразделенных данных), но в этой статье не о них. Дальше будем исходить из того, что все базы «с земли» уже загружены во Фреш как ОД и находятся в разных базах «в облаке» (в одной базе 15-20 ОД) и даже физически на разных серверах.
Какие были варианты
COM-соединение – отметается сразу, т.к. не работает на серверах под управлением Linux-систем
Веб-сервисы – уже лучше, но при добавлении каждой новой ИБ необходимы дополнительные работы по настройке и публикации, и я уже не говорю, что при «переезде» баз нужно будет практически заново заниматься всем этим.
Поставляемые данные (ПД) – наверное, лучший вариант, т.к. для работы нужно только чтобы ОД были подключены к Менеджеру сервиса (МС) и сам файл ПД как-то в МС загружался.
Несколько слов о Менеджере сервиса
Снова процитирую 1С, но на этот раз не Руководство разработчика, а «1С: Облачная подсистема Фреш»:
Центральным компонентом облачной подсистемы Фреш является менеджер сервиса. Менеджер сервиса — это специальное прикладное решение на платформе «1С:Предприятие». Менеджер сервиса:
- хранит в себе всю информацию о том, какие прикладные решения зарегистрированы в сервисе, какие области данных используются и какими абонентами, какие пользователи существуют в системе и с какими правами, и т. д.;
- позволяет просматривать и редактировать эту информацию (если пользователь имеет соответствующие права);
- хранит и предоставляет приложениям единую нормативно-справочную информацию, которая может централизованно обновляться (классификаторы, курсы валют и т. д.);
- координирует взаимодействие всех компонентов сервиса.
Менеджер сервиса — это единственный обязательный компонент сервиса. Сервис может функционировать и позволять работать с приложениями на платформе «1С:Предприятие» через Интернет при наличии только менеджера сервиса. Но возможности сервиса при этом будут, разумеется, сильно ограничены.
Если кратко, то Менеджер сервиса это информационная база, которая управляет всеми развернутыми в сервисе ОД, частично их пользователями (тонкая настройка прав по-прежнему в самой ОД), и частично некоторыми данными в базах, а так же предоставляет инструмент без изменения самого МСа расширить состав этих данных с помощью обработок поставляемых данных.
Поставляемые данные
Подробно о них можно прочитать все в том же Руководстве, я же остановлюсь только на тех аспектах механизма, которые потребовались для выполнения конкретно нашей задачи.
Поставляемые данные нужны как раз для того, чтобы централизованно загружать в базы некоторые данные из МС. В МС же они загружаются Обработками поставляемых данных и после загрузки автоматически отправляются в базы с помощью подсистемы «Обмен сообщениями». Данные могут быть как неразделенными, так и разделенными, что нам как раз и было нужно.
Частичное повторение функционала РИБ
Полная картина выглядит следующим образом:
- В базе Рут (ее тоже перенесли во фреш, но в своей ИБ она единственная) создан отдельный план обмена, который регистрирует изменения только в тех объектах, которые нужно отправлять в остальные ОД.
- Когда необходимые объекты зарегистрированы к отправке, они по нажатию кнопки по определенным правилам (в общем случае сериализация объекта в xml целиком, но для некоторых объектов потребовалось немного дописать выгрузку и загрузку) сериализуются в xml и выгружаются в каталог на сервере.
- В МСе стоит обработка поставляемых данных, которая запускается по расписанию и при запуске проверяет этот каталог и если в нем что-то есть, загружает это что-то в качестве поставляемых данных вида ПД_НСИ (существующими видами ПД мы пользоваться не можем, поэтому потребовалось создать свой).
- В рабочих ИБ при приеме поставляемых данных этого вида из МС обработка по определенным правилам записывает полученные объекты во всех ОД.
- В рабочих ОД пользователи не имеют возможности изменять данные, редактируемые централизованно.
Что в планах
- Обработка по подготовке ОД ко включению в систему
Поскольку в данном случае у заказчика изначально была РИБ, в которой у объектов, раздаваемых из Рута, в разных базах одинаковые ГУИДы, наша задача упрощалась. Не нужно было придумывать, как именно при приеме ПД сопоставлять объекты, пришедшие из Рута, и объекты, уже существующие в ОД. Но в общем случае для централизации уже существующих данных такая схема не подойдет, поэтому при внедрении системы на других проектах придется прорабатывать этот момент.
Наиболее логичным для этого выглядит своеобразная «замена» ГУИДа. Например, из Рута нужно централизованно изменять должность «Инженер-программист». В базе до подключения к централизованному управлению такая должность уже была, но, само собой, с другим ГУИДом. Перед подключением к централизации необходимо будет создавать в базе-приемнике новую должность с заданным ГУИДом (таким же, как в Руте), переносить все ссылки со старой на новую, а старую затем удалять.
- Очередь поставляемых данных
В типовом механизме при загрузке поставляемых данных в тот момент, когда не успели загрузиться во все ОД предыдущие, более ранние не доходят и раздаются только более поздние. Этого можно избежать, если ввести в МСе своеобразную очередь поставляемых данных, а в обработке поставляемых данных смотреть, везде ли успели загрузиться предыдущие перед тем, как заменять файл поставляемых данных на более новый.
- Отслеживание получения поставляемых данных в Руте
Типовой механизм позволяет лишь отслеживать в МСе завершение обработки поставляемых данных в целом по информационной базе. Видится логичным и более удобным для пользователя добавить возможность отслеживания с детализацией по ОД и прямо в Руте. Поскольку решение хочется оставить максимально не требующим каких-то дополнительных действий, кроме развертки инфраструктуры Фреш, напрашивается реализация с помощью подсистемы «Обмен сообщениями»
