Работа с разными версиями моделей
Вопрос:
Как организовать работу с разными версиями одной модели организации?
Ответ:
При построении модели организации может появиться необходимость в создании нескольких версий модели. Например, когда существует актуальная утвержденная модель, опубликованная на портале или в HTML-публикации (далее – опубликованная версия модели), и необходимо подготовить ее изменения, для чего создается рабочая версия модели. Для решения этой задачи существует 2 способа:
- Хранение рабочей и опубликованной версий модели в разных базах данных.
- Хранение рабочей и опубликованной версий модели в одной базе данных.
Внимание! Перед использованием любого способа рекомендуется делать резервную копию базы данных.
Способ 1. Хранение версий модели в разных базах данных
Рассмотрим способ, в котором работа с рабочей и опубликованной версией модели осуществляется в разных базах.
Пусть в базе данных "База данных 1" (далее по тексту – опубликованная база данных) содержится опубликованная модель деятельности, которая утверждена, и на ее основе формируется HTML-публикация и портал. Процессы модели имеют статус "Опубликован".
Предположим, что в опубликованную версию модели нужно внести изменения. Для этого необходимо создать рабочую копию опубликованной базы данных – базу "База данных 2" (далее по тексту – рабочая база данных). Подробнее о копировании базы данных описано в статье Резервное копирование и восстановление информационной базы данных. Далее все изменения необходимо выполнять в рабочей базе данных. При внесении изменений в модель процесса у процесса и всех его нижележащих необходимо сменить статус, например, на статус "В работе", а также поменять версию, например, на 2 (подробнее см. Изменения статуса процесса).
Возможно 2 сценария использования рабочей базы данных:
- Несколько изменений модели проводятся одновременно и завершаются в один момент времени.
- Каждое изменение модели производится в свой период времени.
В сценарии 1 после внесения необходимых изменений и их утверждения создается копия рабочей базы данных и производится замена опубликованной базы данных на рабочую. Перед заменой баз данных для предотвращения потери данных в опубликованной базе необходимо предварительно выполнить ее резервное копирование.
В сценарии 2 отдельная рабочая база данных создается под каждое изменение. После внесения изменений, например, в выбранный процесс и их утверждения этот процесс переносится из рабочей базы данных в опубликованную базу. Перенос части модели из одной базы данных в другую базу необходимо выполнять при помощи экспорта/импорта XML-файлов (подробнее см. Перенос данных между базами данных Business Studio). Для этого нужно создать объект, например, "Группа 1" в справочнике "Группы". В свойствах этого объекта на вкладку Состав необходимо перетянуть из Навигатора измененный процесс, а также все измененные или созданные объекты, связанные с процессом. Например, если на диаграмме процесса есть стрелки, с которыми в рамках изменения модели процесса были присоединены новые объекты деятельности, то эти объекты деятельности нужно найти и перетянуть на вкладку Состав в свойствах группы. Если и в рабочей, и в опубликованной базах данных есть объекты, связанные с измененным процессом, и они не менялись, то их не нужно включать в группу. При экспорте в XML-файл попадет информация о процессе и связях с ним. Если при импорте в конечной базе не будут найдены объекты, с которыми есть связь импортируемого процесса, то система выдаст сообщение, что в пакет не были включены объекты определенного справочника. Импорт при необходимости можно будет отменить и добавить в пакет дополнительные объекты в исходной базе данных.
Достоинством рассмотренного способа является возможность формирования портала или HTML-публикации без необходимости настраивать исключение объектов рабочей версии модели.
Однако стоит заметить, что данный способ весьма трудоемок, например, из-за необходимости выполнения поиска измененных объектов, связанных с процессом, который нужно экспортировать в опубликованную базу данных.
Способ 2. Хранение версий модели в одной базе данных
Рассмотрим способ, в котором работа с рабочей и опубликованной версиями модели осуществляется в одной базе данных.
Объекты опубликованной версии модели рекомендуется размещать в папке, например, "Опубликованная", которую следует создавать в каждом справочнике (например, в справочниках "Процессы", "Субъекты", "Объекты деятельности"). Также в каждом справочнике для размещения всех изменяемых объектов рекомендуется создавать папку, например, "Рабочая".
Пусть в базе данных содержится опубликованная версия модели, которая утверждена, и на ее основе формируется портал и HTML-публикация. Процессы модели имеют статус "Опубликован". Предположим, что в процесс "Планирование проектов" опубликованной модели нужно внести изменения. Для этого необходимо создать копию этого процесса в папке "Рабочая".
У копии процесса и всех его нижележащих необходимо сменить статус, например, на статус "В работе", а также поменять версию, например, на 2. В созданной копии процесса следует вносить изменения и согласовывать их.
На диаграмме копии процесса внешние концы граничных стрелок будут автоматически затуннелированы. Для обеспечения полноты информации во время работы с копией процесса рекомендуется восстановить внешние источники и потребители стрелок с помощью внешних ссылок. Например, если стрелка выходила из процесса "А2.3 Формирование и заключение договора с клиентом", то нужно будет на диаграмме копии создать внешнюю ссылку с названием процесса "А2.3 Формирование и заключение договора с клиентом". Если есть необходимость еще более детально восстановить окружение процесса, то в Окне свойств этой внешней ссылки нужно указать субъектов, связанных с процессом "А2.3 Формирование и заключение договора с клиентом".
После утверждения рабочей копии процесса, эту копию нужно вернуть в опубликованную версию модели. Для этого необходимо в опубликованной версии модели сменить статус процесса, являющегося родительским по отношению к процессу "Планирование проектов", со статуса "Опубликован", например, на статус "В работе", чтобы появилась возможность вносить изменения в диаграмму родительского процесса. Далее необходимо перетянуть измененный процесс из папки "Рабочая" в опубликованную модель под соответствующий родительский процесс и открыть диаграмму родительского процесса для переприсоединения стрелок. Если нужно сохранить для истории действующий процесс, то можно будет после переприсоединения стрелок не удалять этот процесс, а перенести его в отдельную папку, например, "Архив". Статус этого процесса и всех его потомков можно будет сменить на статус "Архивирован". На диаграмме родительского процесса нужно отсоединить стрелки от архивного процесса, и присоединить к новому процессу. Далее нужно перейти на диаграмму нового процесса и присоединить стрелки с родительской диаграммы рядом с теми стрелками, которые уже есть в новом процессе и присоединены к внешней ссылке. Только после полного восстановления стрелок с родительской диаграммы те стрелки, которые присоединены к внешней ссылке, можно удалить. Затем при закрытом Окне диаграммы нужно переместить архивный процесс в папку "Архив".
Настройка портала и HTML-публикации
1. Создание портала только с опубликованной версией модели
Для того чтобы в структуре портала содержались только те объекты, которые имеют отношение к опубликованной версии модели организации, структуру портала нужно настроить при помощи параметра "Группа фильтра". Объекты, имеющие отношение к опубликованной версии модели, рекомендуется размещать в отдельной папке, например, в папке "Опубликованная". В Навигаторе (Навигатор -> Группы) необходимо создать группу, и в ее Окне свойств на вкладке Состав нужно указать те папки "Опубликованная", все содержимое которых должно попадать в структуру на портале. Далее необходимо выбрать эту группу в Окне свойств портала в параметре "Группа фильтра" (по умолчанию не выводится на показ, подробнее о параметре "Группа фильтра" см. в статье Параметры портала) и сформировать портал.
2. Создание портала с опубликованной и рабочей версиями модели
Для того чтобы в структуре портала помимо объектов опубликованной версии модели содержались объекты рабочей версии, но с правом просмотра ограниченным кругом пользователей, необходимо в Business Studio настроить права доступа к объектам рабочей версии модели при помощи настройки горизонтальных прав доступа (подробнее см. Горизонтальные права). Например, права можно дать бизнес-аналитикам, вносящим изменения в объекты рабочей версии, и пользователям, участвующим в согласовании изменений в этих объектах.
Настраивать горизонтальные права доступа можно как к объекту, так и к целой папке. Например, к папке "Рабочая" можно дать доступ только бизнес-аналитикам. В окне настройки прав доступа объекта (контекстное меню объекта -> Дополнительно -> Права доступа) необходимо добавить пользователя (или группу пользователей), которому разрешен доступ к этому объекту и в Business Studio, и на портале. Например, пользователь Сидоркин Василий Викторович будет иметь доступ к папке "Рабочая" и к ее содержимому. После переформирования портала пользователь Сидоркин В.В. будет видеть в дереве портала процесс в папке "Рабочая".
Остальные пользователи, у которых нет доступа к папке "Рабочая", не увидят ее в дереве портала.
3. Создание HTML-публикации только с опубликованной версией модели
При формировании HTML-публикации задача отбора объектов, относящихся к опубликованной версии решается путем проставления пометок. Пометку или флажок необходимо установить для тех объектов, которые должны попасть в HTML-публикацию (подробнее см. Формирование HTML-публикации).
