Раз и готово! Обновления объектов в «Форсайт. Аналитической платформе»

Создавать новое, используя весь багаж накопленных знаний… Реорганизовать уже существующее, оптимизировав его наработками предшественников… Так хочется осуществить все операции быстро, без проблем и трудностей, чтобы раз – и готово! И с этой задачей как по мановению волшебной палочки справляется Менеджер обновлений «Форсайт. Аналитической платформы». Но чтобы волшебство произошло, нужно следовать определенным важным правилам. О них и пойдет речь.

Создание обновления

Каждый день перед нами возникают самые разные задачи. Одни мы решаем самостоятельно и за пару минут, другие относим к долгосрочным проектам, какие-то задачи помогают решить коллеги. Вот, скажем, появился у вас в коллективе новый сотрудник, перед которым поставили задачу создать демонстрационные отчеты для нового сквозного примера. А вас назначили его наставником, и вам нужно познакомить его с платформой, чтобы он по окончании испытательного срока эти отчеты, работоспособные и пригодные для дальнейшего использования, представил. Но вот какое дело: чтобы не плодить сущности, все примеры вы создаете в одной и той же схеме, которую создавали непосильным трудом в течение месяцев, а то и лет. И вся она такая замечательная и полезная, что испортить в ней что-то или сломать было бы непростительной ошибкой. Согласитесь, жаль отдавать свои труды на растерзание неопытному новичку. «А что нам мешает создать клон этой распрекрасной схемы и его отдать новичку?» – спросите вы. «Действительно, ничего не мешает!» – ответим мы. Но потом все равно придется эти отчеты новичка создавать заново на основной схеме (мы помним, что у нас все хранится в одном месте, да?). А создавать придется их уже вам: основную схему мы бережем (да-да, как зеницу ока). Вот и борются в вас волны сомнения: отдать схему новичку, рискуя потерять все наработанное, или же отдать ему ее клона, а потом самому пересоздать на основной схеме все источники данных, все отчеты… и, в конечном итоге, потратить свое драгоценное время, но зато, конечно, сохранить исходную схему в целости. Кто-то в такой момент может и отчаяться, кто-то будет создавать все с нуля. Ну а нам поможет инструмент, с помощью которого мы за пару минут легко и быстро перенесем отчеты нового сотрудника из дубликата в нашу прекрасную схему. Чтоб, как говорится, и волки сыты, и овцы целы остались.

Менеджер обновлений

Осуществлять процесс переноса данных мы будем в Менеджере обновлений, генерирующем так называемые pefx-файлы, с помощью которых затем и обновляется репозиторий. Если в новую схему требуется перенести таблицы с данными, представления или процедуры, то на вкладке Параметры обновления нужно установить флаги: Пересоздавать таблицы, Пересоздавать хранимые процедуры, Пересоздавать представления. На этой же вкладке мы можем задать параметры для действий после окончания процесса обновления и при возникновении ошибки. Далее, вернувшись в окно Обновление, следует выбрать объекты репозитория, которые необходимо обновить. Для выбора объектов нам в помощь кнопка: Не секрет, что только часть объектов в репозитории существует сама по себе и ни из каких других объектов не состоит, например, топооснова. Но большинство объектов все-таки содержат дочерние элементы. Так, кубы состоят, например, из справочников стран и показателей, а сами справочники базируются на таблицах с данными.

Волшебство обновления

И вот сейчас самое время для Волшебства №1. При добавлении сложносоставных объектов репозитория (куб, база данных временных рядов и др.), в процесс обновления необходимо также включить дочерние для них элементы. Добавляем зависимые объекты мы с помощью пункта Состоит из контекстного меню главного объекта. Удостоверимся, что ВСЕ зависимые объекты добавлены в файл обновления, поскольку некоторые из них напрямую не зависят от главных объектов, но тем не менее без их наличия в репозитории – никуда (например, при обновлении справочников НСИ нужно вручную добавить репозиторий НСИ, в котором они находятся). Альтернативным вариантом добавлению «неявных» объектов может быть наличие в репозитории-приемнике аналогичного объекта с тем же идентификатором/ключом, что и в репозитории-источнике. Следует иметь в виду, что когда мы обновляем объекты, в состав которых входят справочники, или когда мы обновляем отдельно сами справочники, следует исключить из создаваемого *.pefx-файла базу данных, от которой они зависят, т.к. при обновлении справочники, ясное дело, попытаются создаться в той же базе данных, где они уже есть. Тут мы с большой долей вероятности получим сообщение об ошибке, что таблица или процедура уже существует. Однако такое волшебство с базой данных (как и последующее волшебство №2) справедливо, только если мы обновляем объекты в той же сети, где находятся объекты-исходники. Теперь самое место для резонного Волшебства №2. В репозитории-приемнике должна быть заранее создана база данных, т.к. при установке обновления будет выдан запрос на ее замену из текущего репозитория. Следующим шагом создания файла для обновления идет упорядочивание объектов в порядке зависимости. И как раз здесь нет ничего волшебного, нужно просто нажать на кнопку: И выбрать одноименную команду подменю. Далее определим тип обновления. По умолчанию устанавливается тип обновления По ключам, который используется в случае, если перед пользователем не стоит задача создания новых объектов, а нужно только скопировать существующие объекты в репозиторий-приемник. Иначе следует установить тип обновления По идентификаторам. А сейчас – внимание! Подволшебство процесса обновления для данного типа: объекты, не включенные в *.pefx-файл, но от которых зависят объекты *.pefx-файла, при обновлении будут искать соответствие по ключам. Затем мы сохраняем созданное обновление как *.pefx-файл через команду главного меню Обновление – Сохранить в файл.

Применение обновлений

После того как файл был создан, применим созданное обновление к репозиторию. Для этого нам нужно открыть обновляемый репозиторий и из окна навигатора объектов выполнить команду главного меню Навигатор – Обновить объекты репозитория. Далее мы выбираем только что созданный файл обновления, и появляется мастер, который поможет нам произвести обновление. Иногда, однако, мы можем столкнуться с конфликтными ситуациями, препятствующими дальнейшему обновлению. Эти конфликты можно посмотреть на одноименной вкладке. Возможны следующие конфликты: 1. Объект с таким идентификатором/ключом уже существует. Совпадение ключа или идентификатора зависит от выбранного типа обновления. Для разрешения конфликта следует нажать на гиперссылку в поле «Конфликт» и создать новый объект репозитория, изменив наименование и идентификатор. 2. Найденный соответствующий объект имеет другой класс. Объект обновления и соответствующий ему объект репозитория по ключу или идентификатору относятся к разным типам объектов (например, таблица и модуль). Для разрешения конфликта будет предложено создать новый объект. 3. Не найден объект для обновления. Для разрешения данного конфликта рекомендуется открыть файл в менеджере обновления и проверить параметры обновления объекта. Возможно, для объекта был выбран способ обновления «Только обновлять объекты», а соответствующий объект в репозитории не найден. 4. Отсутствуют метаданные объекта. Для разрешения данного конфликта рекомендуется открыть файл в менеджере обновления и проверить параметры обновления объекта. Возможно, в параметрах обновления определено пересоздание объекта, а файл обновления не содержит метаданных для осуществления этой операции. 5. База данных <наименование> не найдена. Конфликт возникает, если в репозитории отсутствует БД, указанная в соединении SQL-оператора. Для разрешения конфликта следует нажать на гиперссылку в поле «Конфликт» и выбрать базу данных. После разрешения возможных конфликтов мастер за считанные секунды произведет обновление. Вот так, владея всего лишь несколькими секретами, мы можем быстро перенести объекты из одного репозитория в другой, сохраняя весь накопленный опыт.