Букварь Renga / Совместная работа над проектом

Renga Collaboration Server

Совместная работа пользователей, проектирующих в программе Renga, осуществляется посредством специальной службы Renga Collaboration Server (далее также RCS).

Установка Renga Collaboration Server должна производиться только на один компьютер, которым может быть:

Вариант 1 – Компьютер одного из пользователей Renga, участвующего в процессе совместной работы (возможен, но не рекомендуется).

Вариант 2 – Специально выделенный сервер (рекомендуется[1])

Основные требования к компьютеру или выделенному серверу, на котором установлена и запущена служба Renga Collaboration Server

1 – Включенное и бесперебойное состояние в постоянном режиме или в установленном режиме работы организации.

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

3 – Соответствие актуальным рекомендуемым системным требованиям:

• • Процессор: 64-разрядный, с тактовой частотой 3,1 ГГц или выше.
• • Оперативная память: 16 ГБ ОЗУ или выше.
• • Сетевой адаптер: Ethernet (100/1000baseT PHY/MAC).
• • Жесткий диск: его объем зависит от количества и размеров проектов (усредненно, один проект на сервере ≈ 100 МБ).
• • Операционная система: Microsoft Windows Server 2012 или новее.

Настройка при установке Renga Collaboration Server

Установка службы Renga Collaboration Server производится из специального файла, скачанного из центра загрузок (для коммерческих пользователей) или предоставленного по запросу на сайте (после заполнения формы «Пробная коммерческая лицензия» или «Renga для учебных целей»).

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

«Папка для установки» – указывается путь для установки самой службы Renga Collaboration Server.

«Папка для хранения проектов» – выбирается папка хранения специальных файлов, предназначенных для синхронизации проектов между всеми пользователями, а также файлов журналов этих проектов на сервере. По умолчанию на том компьютере, где устанавливается служба RCS, задан путь: C:\Program Files\Renga Collaboration Server\Projects. Рекомендуется указать собственный путь к папке для хранения проектов в надежном и установленном требованиями проектной организации месте, а также настроить резервное копирование данной папки.

«Ключ доступа» – задается при необходимости ограничить доступ к серверу в глобальной сети. Рекомендуется зафиксировать ключ доступа для последующей настройки подключения пользователей к серверу.

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

«Интервал опроса (секунды)» – задается интервал времени в секундах, через который служба RCS в постоянном автоматическом фоновом режиме производит проверку подключенных клиентов (приложений Renga, которые запущены на компьютерах пользователей и подключены к серверу совместной работы). В случае, если сервер определяет недействительное подключение (нет ответа от клиента, который подключился и не отключался самостоятельно от сервера) – сессия сбрасывается и клиент подключается повторно в автоматическом режиме. Это позволяет снизить вероятность возникновения ошибок при синхронизации после сбоя локального или интернет-соединения: так как если клиент фактически не подключен, а на сервере его подключение идентифицировано как действующее – при попытке синхронизации данных с сервером, данные от этого пользователя будут отклонены (по причине того, что пользователь с таким именем уже подключен к серверу). По умолчанию интервал опроса установлен длительностью в 30 секунд, что является оптимальным временем для проверки соединений. При нестабильном интернет-соединении рекомендуется оставить значение по умолчанию или уменьшить интервал.

При необходимости смены интервала опроса, номера порта и остальных параметров после установки необходимо заново запустить установку и изменить параметры, после чего запустить их исправление:

После установки служба RCS запускается автоматически. Проверить – запущена ли служба – можно в диспетчере задач (Ctrl+Alt+Delete -> Службы) или специальном системном приложении «Службы».

Подключение пользователя к совместной работе

Рекомендуется перед началом совместного проектирования установить программу Renga и настроить подключение к серверу на компьютерах всех участников совместной работы. При этом подключение нового участника проектирования к совместной работе может осуществляться в любой момент времени работы сервера и на любом этапе выполнения проекта.

На компьютерах участников совместного проектирования должна быть установлена версия программы Renga, соответствующая версии службы Renga Collaboration Server, установленной на компьютере-сервере.

В приложении Renga на компьютере каждого из участников должны быть установлены необходимые настройки совместной работы:

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

«Имя сервера» – имя или статичный IP-адрес в локальной или глобальной сети компьютера, являющегося сервером (при необходимости настройки совместной работы посредством глобальной интернет-сети, можно обратиться к примеру настройки одного из пользователей Renga – «Совместный доступ Renga»). В случае, если служба RCS установлена на компьютере одного из участников совместного проектирования, для этого участника имя сервера должно быть задано также по имени или статичному IP-адресу его компьютера в сети или в значении «localhost» (что означает обращение к своему же компьютеру в качестве сервера); для остальных участников имя сервера задается по стандартным правилам, указанным выше.

«Ключ доступа к серверу» – ключ доступа, заданный в параметрах настройки службы Renga Collaboration Server на сервере.

«Порт» – номер порта компьютера-сервера. Должен совпадать с номером порта, указанного при установке службы Renga Collaboration Server (см. настройки установки RCS). После настройки и применения всех указанных параметров, потребуется перезапуск приложения Renga. При повторном запуске приложения, в строке заголовка отобразится один из статусов наличия подключения к серверу совместной работы:

После настройки и применения всех указанных параметров, потребуется перезапуск приложения Renga. При повторном запуске приложения, в строке заголовка отобразится один из статусов наличия подключения к серверу совместной работы: «Автономная работа» или «Подключено к серверу».

«Автономная работа» – пользователь не подключен к Renga Collaboration Server. Возможные причины: отсутствует подключение компьютера пользователя к сети; в настройках приложения Renga указано неверное имя сервера или порт; сервер не подключен к сети; закрыт порт, указанный в настройках при установке сервера.

При успешном подключении к серверу совместной работы в строке заголовка отобразится надпись «Подключено к серверу [Имя сервера или IP адрес]»

Каждое подключение и отключение от сервера совместной работы пользователей по всем проектам фиксируется в едином журнале на компьютере-сервере. Данный журнал под названием «RengaServer.log» хранится в папке установки службы RCS: C:\Program Files\Renga Collaboration Server\RengaServer.log. Подробнее о чтении и анализе информации в пункте "Рекомендации по организации и ведению совместного проектирования в Renga".

Обновление Renga и Renga Collaboration Server

Обновление службы Renga Collaboration Server выпускается одновременно с обновлением программы Renga. При обновлении программы Renga требуется одновременное обновление Renga Collaboration Server – версии программы и службы совместной работы должны совпадать. Файлы установки обновления Renga Collaboration Server для коммерческих пользователей предоставляются по специальной ссылке из сервиса загрузок; для учебных целей – запрашиваются через форму на сайте.

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

В случае обновления Renga и службы RCS с версии 3.3 до версии 4.0 или более поздней версии, потребуется заново опубликовать каждый проект, находящийся в совместной работе после обновления.

Порядок осуществления совместной работы и основные команды

Рекомендуется перед началом совместного проектирования убедиться, что программа Renga и служба RCS установлены, при этом произведены все настройки (см. пункт "Настройка работы посредством Renga Collaboration Server"), и необходимые участники подключены к серверу каждый под своим уникальным идентифицирующим именем пользователя (в дальнейшем подключить нового участника проектирования к совместной работе над проектом также возможно на любом этапе его выполнения). 

✎ Для того чтобы инициировать совместную работу над проектом, одному из пользователей, подключенных к серверу совместной работы, необходимо произвести следующие действия:

Шаг 1 – Создать новый проект.

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

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

Шаг 2 – Сохранить проект локально на своем компьютере в формате *.RNP

Шаг 3 – Опубликовать проект.

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

В момент публикации происходит присвоение уникального идентификатора проекту и публикация проекта (создается специальный файл, предназначенный для синхронизации проекта между всеми подключенными пользователями, а также файл журнала транзакций по этому проекту, получающих наименование по номеру уникального идентификатора проекта) на сервере (в папке, указанной для сохранения при установке службы Renga Collaboration Server).

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

Если выдано сообщение о том, что публикация проекта не может быть выполнена, то требуется проверить и при необходимости настроить соединение с сервером, затем повторить попытку (эта информация будет содержаться и в сообщении в качестве подсказки).

Также в строке заголовка проекта должна появиться надпись «(В совместном доступе)».

Если проект не опубликован, то рядом с названием проекта не будет такой надписи, а также при дальнейшей попытке синхронизации будет выдано сообщение о невозможности синхронизации без публикации.

Шаг 4 – Передать копию файла проекта в формате *.RNP остальным участникам совместной работы.

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

✎ На данном этапе к совместной работе над проектом присоединяются остальные участники проектирования, которые должны придерживаться следующего порядка действий:

Шаг 5 – Разместить полученный файл проекта в удобном каждому участнику совместной работы месте расположения и открыть проект.

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

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

Рекомендуется настроить резервное копирование файла проекта для каждого пользователя.

Шаг 6 – Первоначально синхронизировать проект.

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

Специального сообщения о том, что синхронизация проекта с сервером завершена не предусмотрено (в связи с рекомендуемой высокой частотой синхронизации). Далее будет рассмотрена работа с журналами проекта, которые фиксируют все изменения и являются достоверным источником информации. Дополнительно убедиться в том, что синхронизация завершена и работа ведется с актуальным проектом, можно увидев изменения в модели на 3D-сцене или в Обозревателе проекта. А также простой подсказкой о том, что в локальный проект внесены изменения от других пользователей с сервера может служить такой способ: если пользователь еще не начал вносить собственные изменения (или внес изменения и произвел рекомендуемое сохранение проекта) перед синхронизацией, то в строке заголовка его проекта не будет символа «*». После синхронизации в названии проекта появится символ «*», сигнализирующий о том, что в проект внесены изменения (в данном случае, изменения внесены с сервера). 

✎ Рекомендуемая последовательность следующих шагов может повторяться неограниченное число раз для каждого участника совместной работы. Она определяет порядок внесения собственных изменений в проект, с периодической синхронизацией данных со всеми участниками через сервер совместной работы.

Шаг 7 – Внести собственные изменения в проект.

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

Одно из основных правил, которые должен знать проектировщик на этапе внесения изменений в проект до проведения синхронизации: минимальный блок передачи данных (см. правило 5 пункта "Правила, действующие при совместной работе в Renga"). Учитывая это правило наравне с естественным порядком разграничения обязанностей в проектировании, специалисты не должны одновременно изменять тот блок передачи данных, который является минимальным и цельным для передачи при синхронизации. В случае, если специалистам необходимо поработать с разными составляющими одного и того же минимального блока передачи данных (при наличии не одного, а нескольких составляющих), следует делать это последовательно, заранее договариваясь.

Шаг 8 – Сохранить внесенные изменения в своей копии проекта.

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

Шаг 9 – Синхронизировать проект.

В процессе собственной работы над проектом требуется периодически синхронизировать проект для поддержания актуальности данных у всех участников совместного проектирования. Периодичность синхронизации рекомендуется сохранять максимально частой. Это позволит принимать и передавать в момент синхронизации минимальные объемы изменений, снижая вероятность возникновения пересечения изменений от разных пользователей, а также обеспечивая актуальность данных для принятия специалистами корректных проектных решений. При этом следует знать правило: при работе над одним минимальным блоком передачи информации (см. шаг 7 пункта "Правила, действующие при совместной работе в Renga") для сведе́ния изменений будут приняты изменения от первого отправившего пользователя.

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

Шаг 10 – В случае необходимости открыть журнал проекта.

Журнал проекта на компьютере пользователя – показывает все изменения, совершенные пользователем в локальной копии проекта с момента его первой публикации или синхронизации; а также данные о пришедших в локальную копию изменениях проекта с сервера (от других пользователей под общим именем «Other»).

Открыть журнал проекта возможно при работе над совместным проектом в Renga с помощью одноименной команды. По умолчанию локальный журнал каждого проекта, находящегося в совместной работе, хранится в папке под именем учетной записи пользователя в операционной системе %LocalAppData%\Renga Software\Renga.

В названии журнала проекта отображен уникальный идентификатор, по которому можно идентифицировать проект на сервере среди других проектов, находящихся в совместной работе. Зная идентификатор проекта, можно открыть и проанализировать журнал проекта на сервере (который отображает изменения, пришедшие ото всех пользователей – от каждого под своим именем – в синхронизируемый проект) и проанализировать время публикации проекта и подключения пользователей к серверу и конкретному проекту в журнале подключений.

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

Правила, действующие при совместной работе в Renga

1 – Для организации совместной работы пользователей, проектирующих с помощью программы Renga, определена стратегия оптимистичного контроля параллелизма, при которой происходит объединение изменений, полученных от каждого участника.

Основные характеристики выбранной стратегии:

• Во время работы данные синхронизируемого проекта не блокируются. Это позволяет неограниченному числу пользователей одновременно работать над одним проектом; и предоставляет возможность работать автономно, потому что для редактирования элементов не нужно уведомлять сервер о необходимости блокировки.

• Можно передавать минимальный набор данных для синхронизации с сервером.

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

• Дополнительные сведения о стратегии оптимистичного контроля параллелизма в сравнении с другими существующими стратегиями см. в статье.

2 – Данные проекта между всеми участниками совместной работы в Renga синхронизируются по уникальному идентификатору проекта (присваивается при публикации проекта) через единый файл на сервере. Таким образом в локальной копии проекта каждого пользователя содержатся данные по всему проекту, переданные от всех пользователей при синхронизации.

3 – У всех специалистов, работающих над проектом в Renga, одинаковые права. В любой момент совместного проектирования специалист может внести необходимое изменение в модель, чертеж, спецификацию и т.д.

4 – При синхронизации одновременно отправляются и принимаются изменения с сервера[1]

Информация о проведенных транзакциях фиксируется в локальном журнале проекта на компьютере каждого пользователя и в общем журнале проекта на компьютере-сервере.

[1] Технически изменения сначала принимаются с сервера, затем отправляются на сервер, но происходит это по единой команде.

5 – Минимальный блок передачи данных при синхронизации[2]

В актуальной версии Renga минимальным блоком передачи данных является: стиль (передается единым блоком параметров и свойств, кроме стилей материалов и многослойных материалов: для этих стилей передается отдельный параметр или значение свойства стиля), пользовательское свойство (как позиция), цельный объект модели (единым блоком передаются все параметры и геометрические данные сразу), набор значений свойств объекта модели, спецификация целиком, компонент чертежа, компонент сборки, параметр или данные ячейки таблицы. Это значит, что даже если изменено значение, например, только одного параметра объекта модели, то в синхронизируемом проекте объект изменится целиком (то есть все параметры и геометрические данные), при этом возможно одновременно разным пользователям изменять одному – параметры, другому – значения свойств одного и того же объекта.

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

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

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

Для того чтобы опубликовать проект, создаваемый на основе находящегося или ранее бывшего в совместной работе проекта, потребуется:

Шаг 1 – Сохранить проект-аналог как шаблон в формате *.RNT.

Шаг 2 – Открыть сохраненный шаблон двойным щелчком из сохраненного файла шаблона проекта. В этот момент создается новый проект по открываемому шаблону, который уже не содержит в себе уникальный идентификатор того проекта, на основе которого был создан шаблон.

Шаг 3 – Сохранить локально проект в формате *.RNP.

Шаг 4 – Опубликовать проект. В этот момент проекту будет присвоен собственный уникальный идентификатор и проект будет опубликован на сервере для последующей синхронизации данных.

Шаг 5 – Поделиться копией сохраненного локально файла проекта с коллегами, которые будут участвовать в совместной работе над ним.

Рекомендации по организации и ведению совместной работы

1 – Обеспечивать бесперебойность работы сервера и сети. Компьютеры должны быть всегда включены, защищены от перепадов напряжения и подключены к сети.

2 – Соблюдать порядок настроек и действий для организации и осуществления совместной работы, приведенный в разделах "Настройка работы посредством Renga Collaboration Server" и "Команды и правила совместной работы над проектом".

3 – Настроить и производить резервное копирование файлов синхронизации проектов на сервере и файлов проектов на компьютерах пользователей, участвующих в совместной работе.

4 – Всем участникам совместного проектирования быть осведомленными о правилах совместной работы (см. пункт "Правила, действующие при совместной работе в Renga") в текущей версии Renga и службы RCS. Как следствие: не изменять одновременно разным пользователям один и тот же блок передачи данных, являющийся минимальным при синхронизации. При необходимости работы над теми компонентами модели и проекта, над которыми могут работать несколько специалистов, уведомлять остальных участников проектирования о намерении их изменить, о внесенных изменениях.

5 – На любом этапе начинания и ведения совместной работы над проектом (проектами), договариваться о разделении ответственности по разделам и компонентам объекта проектирования для каждого специалиста, соблюдая должностные обязанности. Применять для этого принятые и утвержденные на предприятии методы и средства коммуникации, выдачи заданий, согласования порядка действий и принимаемых решений и т.д.

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

7 – Публиковать проект только один раз и только одному пользователю перед началом совместной работы над ним.

8 – Каждому участнику совместной работы вести проектирование в своей копии файла проекта в формате *.RNP. Эта рекомендация особенно актуальна при наличии и функционировании в проектной организации настроенной среды общих данных.

9 – Вносить изменения в проект и синхронизировать их под своим уникальным и неизменным именем пользователя. Именно по имени пользователя происходит идентификация клиента на сервере – то есть, при необходимости, существует возможность настроить подключение и передачу данных от одного определенного пользователя с разных компьютеров. Строго не рекомендуется изменять имя пользователя в процессе совместной работы, так как изменения в общий синхронизируемый проект будут приняты сервером только под тем именем пользователя, который их локально вносил в свою копию проекта.

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

11 – Чаще синхронизировать изменения с сервером. Это позволит передавать и принимать минимальные объемы изменений, снижая вероятность возникновения пересечения изменений от разных пользователей в момент синхронизации, а также обеспечивая актуальность данных для принятия специалистами корректных проектных решений.

12 – Синхронизировать все проекты перед обновлением программы Renga и Renga Collaboration Server для сохранности актуальных данных у каждого пользователя и на сервере.

Чтение журнала подключений и журналов проекта. Выявление отсутствия подключений и конфликтных ситуаций при совместной работе

Фиксация процессов и транзакций совместной работы посредством Renga Collaboration Server осуществляется в трех видах журналов (файлов расширения .log): журнал проекта на компьютере каждого из участников совместной работы; единый для всех пользователей журнал проекта на компьютере-сервере; единый для всех пользователей и проектов журнал подключений к серверу на компьютере-сервере.

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

Приведенные далее примеры каждого из журналов рассмотрены на едином случае совместной работы двух специалистов – архитектора и конструктора.

1 – Журнал проекта на компьютере каждого из участников совместной работы (локальный журнал проекта) – содержит записи обо всех изменениях, совершенных пользователем в локальной копии проекта с момента его первой публикации или синхронизации (все действия пользователя фиксируются автоматически в режиме реального времени); а также данные о ранее принятых сервером в общем проекте и пришедших в локальную копию изменениях проекта с сервера (от других пользователей под общим именем «Other»; в момент синхронизации проекта с сервером по команде пользователя).

Открыть журнал проекта с компьютера пользователя возможно при работе над совместным проектом в приложении Renga с помощью одноименной команды. По умолчанию журнал каждого проекта, находящегося в совместной работе, хранится в папке под именем учетной записи пользователя в операционной системе %LocalAppData%\Renga Software\Renga.

Формат записи данных в журнале проекта:

Дата и время транзакции | Имя текущего пользователя или изменения пришли с сервера от других пользователей (Other) | Наименование объекта, стиля, свойства, чертежа и т.д. | Уникальный идентификатор объекта, над которым произведено действие в проекте | Действие создания (Creation), редактирования (Editing) или удаления (Removal) объекта | Успешное выполнение действия (Success) или возникновение конфликта (Conflict) | Поясняющее суть конфликта сообщение (Failure message) |

Пример чтения журнала проекта под уникальным идентификатором «2786632915423444940» на компьютере пользователя под именем «StrEngineer_Kolmogorova»:

В названии журнала проекта отображен уникальный идентификатор, по которому можно идентифицировать проект на сервере среди других проектов, находящихся в совместной работе. Зная идентификатор проекта, можно открыть и проанализировать журнал проекта на сервере и проанализировать время подключения (или отключения) пользователей к серверу и конкретному проекту в журнале подключений.

2 – Журнал проекта на сервере – содержит записи обо всех принятых после публикации изменениях по проекту от всех пользователей, каждый из которых обозначен тем именем, какое задано в настройках совместной работы его приложения.

Формат записи данных в журнале проекта:

Дата и время транзакции | Имя пользователя | Наименование объекта, стиля, свойства, чертежа и т.д. | Уникальный идентификатор объекта, над которым произведено действие в проекте | Действие создания (Creation), редактирования (Editing) или удаления (Removal) объекта | Успешное выполнение действия (Success) или возникновение конфликта (Conflict) | Поясняющее суть конфликта сообщение (Failure message) |

Пример чтения журнала проекта под уникальным идентификатором «2786632915423444940» на компьютере-сервере:

3 – Каждое подключение (и отключение) к серверу совместной работы пользователей по всем проектам, а также публикация проектов фиксируется в едином журнале подключений на сервере.

Данный журнал под названием «RengaServer.log» хранится в папке установки службы RCS: C:\Program Files\Renga Collaboration Server\RengaServer.log.

Пример журнала на изображении выше позволяет проанализировать следующие данные:

Дополнительный одновременный анализ всех трех журналов показывает:

16 ноября служба RCS запущена с 16:33, проект «2786632915423444940» опубликован единственным подключенным до публикации пользователем «StrEngineer_Kolmogorova»; к совместной работе над данным проектом в 16:35 подключился пользователь «Architect_Kiryan» (по данным из журнала подключений).

В 17:53 пользователь «Architect_Kiryan» успешно опубликовал внесенные изменения в проект на сервере, затем до 18:31 в проекте синхронизировали изменения пользователи «Architect_Kiryan» и «StrEngineer_Kolmogorova» (по данным из журнала проекта на сервере).

Пользователь «StrEngineer_Kolmogorova» синхронизировал (в данном случае только принял изменения) локальную копию проекта в 18:33 (по данным из локального журнала проекта).

В 18:35 и 18:38 пользователи «StrEngineer_Kolmogorova» и «Architect_Kiryan» соответственно закрыли проект и программу Renga, после чего служба RCS была остановлена и компьютер-сервер выключен (по данным из журнала подключений).

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

Для того чтобы при необходимости уточнить состояние или наличие определенного объекта, информация по которому отображена в журналах проекта, можно применить выбор фильтром, настроенным по ID этого объекта. Например, настроив фильтр для колонны из рассмотренного примера с ID=1665da88-51cf-47a2-aa8a-488329813306:

Важно отметить, что при соблюдении порядка и правил организации и ведения совместной работы, изложенных в разделах "Настройка работы посредством Renga Collaboration Server" и "Команды и правила совместной работы над проектом", не потребуется обращение к перечисленным журналам.

 Дополнительный показ изложенных базовых положений раздела см. видео «Совместная работа в Renga».