Работа с разными версиями моделей

Вопрос:

Как организовать работу с разными версиями одной модели организации?

Ответ:

При построении модели организации может появиться необходимость в создании нескольких версий модели. Например, когда существует актуальная утвержденная модель, опубликованная на портале или в HTML-публикации (далее – опубликованная версия модели), и необходимо подготовить ее изменения, для чего создается рабочая версия модели. Для решения этой задачи существует 3 способа:

1. Использование механизма веток.¹⁾
2. Хранение рабочей и опубликованной версий модели в разных базах данных.
3. Хранение рабочей и опубликованной версий модели в одной базе данных.

Внимание! Перед использованием любого способа рекомендуется делать резервную копию базы данных.

Способ 1. Использование механизма веток

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

Способ 2. Хранение версий модели в разных базах данных

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

Пусть в базе данных «База данных 1» (далее по тексту – опубликованная база данных) содержится опубликованная модель деятельности, которая утверждена, и на ее основе формируется HTML-публикация и портал. Процессы модели имеют статус «Опубликован».

Предположим, что в опубликованную версию модели нужно внести изменения. Для этого необходимо создать рабочую копию опубликованной базы данных – базу «База данных 2» (далее по тексту – рабочая база данных). Подробнее о копировании базы данных описано в статье Резервное копирование и восстановление информационной базы данных. Далее все изменения необходимо выполнять в рабочей базе данных. При внесении изменений в модель процесса у процесса и всех его нижележащих необходимо сменить статус, например, на статус «В работе», а также поменять версию, например, на 2 (подробнее см. Изменения статуса процесса).

Возможно 2 сценария использования рабочей базы данных:

1. Несколько изменений модели проводятся одновременно и завершаются в один момент времени.
2. Каждое изменение модели производится в свой период времени.

В сценарии 1 после внесения необходимых изменений и их утверждения создается копия рабочей базы данных и производится замена опубликованной базы данных на рабочую. Перед заменой баз данных для предотвращения потери данных в опубликованной базе необходимо предварительно выполнить ее резервное копирование.

В сценарии 2 отдельная рабочая база данных создается под каждое изменение. После внесения изменений, например, в выбранный процесс и их утверждения этот процесс переносится из рабочей базы данных в опубликованную базу. Перенос части модели из одной базы данных в другую базу необходимо выполнять при помощи экспорта/импорта XML-файлов (подробнее см. Перенос данных между базами данных Business Studio). Для этого нужно создать объект, например, «Группа 1» в справочнике «Группы». В свойствах этого объекта на вкладку Состав необходимо перетянуть из Навигатора измененный процесс, а также все измененные или созданные объекты, связанные с процессом. Например, если на диаграмме процесса есть стрелки, с которыми в рамках изменения модели процесса были присоединены новые объекты деятельности, то эти объекты деятельности нужно найти и перетянуть на вкладку Состав в свойствах группы. Если и в рабочей, и в опубликованной базах данных есть объекты, связанные с измененным процессом, и они не менялись, то их не нужно включать в группу. При экспорте в XML-файл попадет информация о процессе и связях с ним. Если при импорте в конечной базе не будут найдены объекты, с которыми есть связь импортируемого процесса, то система выдаст сообщение, что в пакет не были включены объекты определенного справочника. Импорт при необходимости можно будет отменить и добавить в пакет дополнительные объекты в исходной базе данных.

Достоинством рассмотренного способа является возможность формирования портала или HTML-публикации без необходимости настраивать исключение объектов рабочей версии модели.

Однако стоит заметить, что данный способ весьма трудоемок, например, из-за необходимости выполнения поиска измененных объектов, связанных с процессом, который нужно экспортировать в опубликованную базу данных.

Способ 3. Хранение версий модели в одной базе данных

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

Объекты опубликованной версии модели рекомендуется размещать в папке, например, «Опубликованная», которую следует создавать в каждом справочнике (например, в справочниках «Процессы», «Субъекты», «Объекты деятельности»). Также в каждом справочнике для размещения всех изменяемых объектов рекомендуется создавать папку, например, «Рабочая».

Пусть в базе данных содержится опубликованная версия модели, которая утверждена, и на ее основе формируется портал и HTML-публикация. Процессы модели имеют статус «Опубликован». Предположим, что в процесс «Планирование проектов» опубликованной модели нужно внести изменения. Для этого необходимо создать копию этого процесса в папке «Рабочая».

У копии процесса и всех его нижележащих необходимо сменить статус, например, на статус «В работе», а также поменять версию, например, на 2. В созданной копии процесса следует вносить изменения и согласовывать их.

На диаграмме копии процесса внешние концы граничных стрелок будут автоматически затуннелированы. Для обеспечения полноты информации во время работы с копией процесса рекомендуется восстановить внешние источники и потребители стрелок с помощью внешних ссылок. Например, если стрелка выходила из процесса «А2.3 Формирование и заключение договора с клиентом», то нужно будет на диаграмме копии создать внешнюю ссылку с названием процесса «А2.3 Формирование и заключение договора с клиентом». Если есть необходимость еще более детально восстановить окружение процесса, то в Окне свойств этой внешней ссылки нужно указать субъектов, связанных с процессом «А2.3 Формирование и заключение договора с клиентом».

После утверждения рабочей копии процесса, эту копию нужно вернуть в опубликованную версию модели. Для этого необходимо в опубликованной версии модели сменить статус процесса, являющегося родительским по отношению к процессу «Планирование проектов», со статуса «Опубликован», например, на статус «В работе», чтобы появилась возможность вносить изменения в диаграмму родительского процесса. Далее необходимо перетянуть измененный процесс из папки «Рабочая» в опубликованную модель под соответствующий родительский процесс и открыть диаграмму родительского процесса для переприсоединения стрелок. Если нужно сохранить для истории действующий процесс, то можно будет после переприсоединения стрелок не удалять этот процесс, а перенести его в отдельную папку, например, «Архив». Статус этого процесса и всех его потомков можно будет сменить на статус «Архивирован». На диаграмме родительского процесса нужно отсоединить стрелки от архивного процесса, и присоединить к новому процессу. Далее нужно перейти на диаграмму нового процесса и присоединить стрелки с родительской диаграммы рядом с теми стрелками, которые уже есть в новом процессе и присоединены к внешней ссылке. Только после полного восстановления стрелок с родительской диаграммы те стрелки, которые присоединены к внешней ссылке, можно удалить. Затем при закрытом Окне диаграммы нужно переместить архивный процесс в папку «Архив».

Настройка портала и HTML-публикации

1. Создание портала только с опубликованной версией модели

Для того чтобы в структуре портала содержались только те объекты, которые имеют отношение к опубликованной версии модели организации, структуру портала нужно настроить при помощи параметра «Группа фильтра». Объекты, имеющие отношение к опубликованной версии модели, рекомендуется размещать в отдельной папке, например, в папке «Опубликованная». В Навигаторе (Навигатор → Группы) необходимо создать группу, и в ее Окне свойств на вкладке Состав нужно указать те папки «Опубликованная», все содержимое которых должно попадать в структуру на портале. Далее необходимо выбрать эту группу в Окне свойств портала в параметре «Группа фильтра» (по умолчанию не выводится на показ, подробнее о параметре «Группа фильтра» см. в статье Параметры портала) и сформировать портал.

2. Создание портала с опубликованной и рабочей версиями модели

Для того чтобы в структуре портала помимо объектов опубликованной версии модели содержались объекты рабочей версии, но с правом просмотра ограниченным кругом пользователей, необходимо в Business Studio настроить права доступа к объектам рабочей версии модели при помощи настройки горизонтальных прав доступа (подробнее см. Горизонтальные права). Например, права можно дать бизнес-аналитикам, вносящим изменения в объекты рабочей версии, и пользователям, участвующим в согласовании изменений в этих объектах.

Настраивать горизонтальные права доступа можно как к объекту, так и к целой папке. Например, к папке «Рабочая» можно дать доступ только бизнес-аналитикам. В окне настройки прав доступа объекта (контекстное меню объекта → Дополнительно → Права доступа) необходимо добавить пользователя (или группу пользователей), которому разрешен доступ к этому объекту и в Business Studio, и на портале. Например, пользователь Сидоркин Василий Викторович будет иметь доступ к папке «Рабочая» и к ее содержимому. После переформирования портала пользователь Сидоркин В.В. будет видеть в дереве портала процесс в папке «Рабочая».

Остальные пользователи, у которых нет доступа к папке «Рабочая», не увидят ее в дереве портала.

3. Создание HTML-публикации только с опубликованной версией модели

При формировании HTML-публикации задача отбора объектов, относящихся к опубликованной версии решается путем проставления пометок. Пометку или флажок необходимо установить для тех объектов, которые должны попасть в HTML-публикацию (подробнее см. Формирование HTML-публикации).