Когда вы используете в автономном режиме ранее загруженную карту, которая содержит редактируемый сервис объектов, в котором используются данные, зарегистрированные для использования в традиционных версиях, из версии, используемой публикуемыми данными, создается новая версия реплики, а также создается реплика сервиса объектов со связанной версии реплики. Когда клиент синхронизирует правки с репликой сервисом объектов, правки применяются к версии реплики. В результате требуется выполнить дополнительные процессы согласования и закрепления, чтобы внести изменения в опубликованную версию и поделиться ими с другими пользователями.
Если карта содержит сервис объектов, предназначенный только для чтения (для сервиса объектов активированы только функции запроса и синхронизации), и сервис объектов содержит версионные данные, при загрузке карты не будет создана версия реплики. Схожим образом, версия реплики не создается при копировании данных в течение рабочего процесса распределенного сотрудничества. Когда клиенты синхронизируются с сервисом объектов в этих случаях, у них есть доступ ко всем правкам, внесенным в исходные данные.
Примечание:
Даже если сервис объектов находится в режиме только для чтения (разрешены только запросы и синхронизация), пользователь базы данных, подключающийся к базе геоданных при публикации, должен обладать правами на редактирование данных.
Две опции, описанные ниже, позволяют владельцу сервиса объектов или администратору ArcGIS Server выбирать способ создания традиционных версий для конкретного редактируемого сервиса объектов. Издатель задает эти опции при публикации сервиса объектов.
Создать версию для каждой автономной карты
Это является опцией по умолчанию. В этом случае версия реплики создается из опубликованной каждый раз, когда карта с редактируемым сервисом объектов используется в автономном режиме. Имя версии реплики содержит следующую информацию:
- Имя пользователя, загрузившего карту
- Имя сервиса объектов
- Уникальный идентификатор (ID)
Эти три компонента обеспечивают уникальность имени версии реплики. К примеру, если пользователь Bob загружает карту, содержащую сервис объектов NetFS, имя созданной версии реплики будет Bob_NetFS_1404578882000. Если один и тот же пользователь загружает карту несколько раз (например, на разные устройства), при синхронизации с каждым устройством будут использоваться разные версии реплики. Ни одно устройство не будет иметь доступа к редактированию с других устройств. Однако вновь загруженные карты будут согласованы с опубликованной версией. Если загружено много карт, может быть большое число версий реплики. Как только загруженные карты перемещаются из приложения для автономного редактирования, их версии реплики могут быть согласованы, закреплены и удалены.
Примечание:
Если вы опубликовали сервис объектов с поддержкой синхронизации на автономном сайте ArcGIS Server, на котором нет индивидуальных учетных записей пользователей, имя версии реплики будет Esri_Anonymous_<имя сервиса объектов>_<ID>.
Длина имени версии реплики не должна превышать 30 символов. Часть имени сервиса объектов будет усечена, чтобы соответствовать этому ограничению.
Создание версии для каждого пользователя
В данном случае версия реплики создается для каждого пользователя, загрузившего карту с редактируемым сервисом объектов. Например, если карту загрузили 10 пользователей – будет создано 10 версий реплики. Для каждого пользователя своя версия реплики, и имя версии реплик составляется из имени пользователя и имени сервиса (например, Joe_InspectionFS). Если пользователь загружает карту несколько раз (например, с нескольких устройств), при выполнении пользователем синхронизации с любого устройства будет использоваться одна и так же версия. Любое устройство имеет доступ к редактированию с других устройств. Однако вновь загруженные карты будут актуальны на дату последнего согласования пользовательской версии реплики. Пользовательская версия реплики существует до тех пор, пока существует загруженная карта.
Примечание:
При использовании этой опции следует либо интегрировать сайт ArcGIS Server с порталом, либо настроить пользовательские учетные записи в ArcGIS Server. Если вы этого не сделаете, имя созданной версии карты будет выглядеть так: Esri_Anonymous_<feature service name>, а все подключенные к порталу пользователи будут работать с одной и той же версией.
Примеры рабочих процессов
В следующих примерах рабочих процессов используются опции версии, описанные в двух предыдущих разделах:
- Загрузка карт для поддержки данных
- Загрузка карт для краткосрочного проекта
- Загрузка карты для постоянного проекта
Компоненты каждого рабочего процесса сравниваются в следующей таблице:
| Загрузка для поддержки данных | Загрузка для краткосрочного проекта | Загрузка для постоянного проекта | |
|---|---|---|---|
Версия базы геоданных, из которой публикуется сервис объектов | |||
Версия реплики создается для каждой из них | Загруженная карта | Пользователь | Пользователь |
Число созданных версий реплики | Много | Мало | Мало |
Задержка между автономными правками и обновлением версии по умолчанию | Low | Длительная (1 неделя) | Длительная (ежедневно) |
Карты, участвующие в проверке качества | Одна карта | Все карты | Все карты |
Частота удаления версий реплики | Ежедневно | По завершении проекта | Никогда (Never) |
Загрузка карт для поддержки данных
В этом рабочем процессе участник организации использует ArcGIS Pro или пользовательское мобильное приложение при осуществлении полевых работ для подтверждения изменений в отмеченных картах. В этом случае данные регистрируются для участия в традиционном управлении версиями, и рабочие требуют, чтобы карта, которую они загружают, содержала последние данные из версии по умолчанию в базе геоданных. Вернувшись в офис и подключившись к сети, сотрудники синхронизируют изменения, сделанные в поле, удаляют карту, согласовывают и публикуют версию реплики карты с версией базы геоданных по умолчанию. Процесс можно повторить несколько раз за день. По окончании процесса сотрудники удаляют версию реплики.
Для этого веб-карта становится доступной для учетной записи организации – работникам офисной группы. Сотрудник, являющийся членом этой группы, может работать с веб-картой через приложение, работающее на мобильном устройстве, находящееся в офисной сети. Перед тем как покинуть офис, сотрудник загружает карту в приложение. Затем он идет в поле и проверяет наличие изменений, находясь вне сети. Затем, возвратившись в офис, внесенные в поле изменения синхронизируются с сервисом объектов, а затем согласовываются и закрепляются в версии по умолчанию.
В следующих разделах описан данный рабочий процесс:
Публикация сервиса объектов
Для создания веб-карты сначала необходимо опубликовать сервис объектов.
Издатель запускает ArcGIS Pro и добавляет на карту данные из версии по умолчанию. В этом примере данные содержат новые сенсоры в классе объектов многопользовательской базы геоданных компании. Класс объектов регистрируется как версионный.
Издатель публикует векторный слой с именем NetFS, который ссылается на зарегистрированные данные из ArcGIS Pro.
В процессе публикации издатель редактирует следующие настройки на вкладке Конфигурация векторного слоя, чтобы позволить перевести слой в автономный режим и редактировать:
- В разделе Включить редактирование и разрешить редакторам пункт Добавлять, обновлять и удалять объекты позволяет редактировать данные в полном объеме.
- Включить синхронизацию - позволяет перевести слой в автономный режим.
- В разделе Синхронизация пункт Создать версию для каждой скачанной карты позволяет создавать версию реплики с уникальным именем для автономной карты, когда мобильный сотрудник загружает карту. Эта версия реплики затем используется при синхронизации правок данных сотрудником.
Издатель также открывает для работы офисных сотрудников сервис, чтобы данные были доступны другим пользователям организации.
Создание веб-карты
Следующим шагом после создания сервиса объектов является создание веб-карты. Издатель добивается этого путем входа в организацию (ArcGIS Enterprise или ArcGIS Online), создания веб-карты, добавления векторного слоя на карту и публикации карты для участников группы офисных работников. Свойство автономного режима веб-карты включено, что делает ее доступной для автономного использования. Члены группы офисных работников теперь могут загружать карту.
Загрузка веб-карты
Имея доступ к веб-карте, сотрудники могут загрузить ее в приложение на своем мобильном устройстве и отправиться на место для проверки запрошенных обновлений. Чтобы сделать это, сотрудник по имени Боб запускает приложение на своем мобильном устройстве, подключенном к сети, входит в организацию и загружает веб-карту на свое устройство.
После начала процесса загрузки из опубликованной версии (По умолчанию) базы геоданных создается версия реплики Bob_NetFS_1404578882000. Поскольку сервис был настроен на создание версии каждой загружаемой карты, создается уникальное имя версии. Имя составляется из учетной записи мобильного работника (Bob), имени сервиса объектов (NetFS) и уникального идентификатора (ID). Эта версия реплики будет использоваться при синхронизации загруженной карты.
Затем данные загружаются на устройство, и приложение переключает карту на использование локальных данных. На этом этапе карту можно редактировать, не находясь в сети.
Синхронизация изменений
Находясь в поле, Боб видит, что один из сенсоров отмечен не на той стороне улицы. Боб вносит исправления на мобильном устройстве.
В дневное время Боб может посетить другие места и внести соответствующие коррективы. Если есть соединение, Боб так же может синхронизировать изменения прямо в поле. Вернувшись в офис, Боб подключается к внутренней сети на полевом устройстве и выполняет окончательную синхронизацию. Это гарантирует, что все внесенные в поле изменения применяются к версии реплики Bob_NetFS_1404578882000.
Теперь, когда изменения, сделанные в поле, синхронизированы с источником, Боб удаляет локальную карту с мобильного устройства и возвращает его. Процесс удаления локальной карты помечает версию реплики Bob_NetFS_1404578882000, как более не связанную с автономной картой. Боб подключается к версии реплики Bob_NetFS_1404578882000 в ArcGIS Pro и согласовывает и закрепляет ее в версии по умолчанию. Боб использует основанное на атрибутах обнаружение конфликтов и вручную их разрешает.
После сохранения изменений Боб переключается на версию по умолчанию и удаляет версию реплики Bob_NetFS_1404578882000.
Боб обнаруживает, что для правильного обновления данных необходимо больше поездок в поле. Каждый поход в поле требует новой загрузки карты и новой версии реплики Bob_NetFS_<ID>. Каждая новая версия реплики включает последние изменения версии по умолчанию. Эти версии реплики будут сохранены в базе геоданных, пока не будут отключены от карты, согласованы и закреплены.
Помимо Боба, и другие офисные работники могут выполнять подобные задачи одновременно с Бобом.
После согласования и закрепления внесенных Бобом изменений в версии по умолчанию, он удаляет версии реплики Bob_NetFS_<ID>.
Загрузка карт для краткосрочного проекта
В данном примере мобильные работники используют для правки версионные данные. Версионные данные в исходной базе геоданных ссылается на версию проекта, являющуюся дочерней по отношению к версии по умолчанию.
Мобильные сотрудники синхронизируют изменения утром и в конце дня с версией проекта. Запускается ночной процесс согласования и закрепления для поддержания версий реплики мобильных сотрудников в актуальном состоянии, с учетом внесения изменений другими мобильными сотрудниками. Каждый мобильный работник синхронизирует данные следующим утром и видит внесенные другими мобильными работниками изменения. По завершении проекта все изменения, внесенные в поле, синхронизированы и применены к версии проекта. Версия проекта проверяется, согласовывается и закрепляется в версию базы геоданных по умолчанию. По завершении проекта сотрудник удаляет сервис объектов и версии реплики мобильных работников.
В этом рабочем процессе задержка данных мобильных работников не превышает недели.
Ниже описаны действия, которые необходимо выполнить для завершения рабочего процесса.
- Публикация сервиса объектов
- Создание веб-карты
- Загрузка веб-карты
- Синхронизация изменений
- Запуск ночной обработки базы геоданных
- Удалите автономные карты и выполните итоговое согласование и закрепление данных
Публикация сервиса объектов
В данном примере менеджер проекта должен подготовить полевых работников для осуществления проверок сенсоров. Проверки сенсоров проводятся периодически в течение года. Во время этих проверок мобильные работники проверяют сенсоры и фиксируют их повреждения и работоспособность. Эта информация используется для планирования ремонта и определения наиболее легко доступных сенсоров. Проект выполняется еженедельно. Для сбора данных каждый мобильный сотрудник получает планшет с установленным мобильным приложением.
Для данного проекта менеджер хочет создать и опубликовать веб-карту для проверок сенсоров в учетной записи организации. Веб-карта будет ссылаться на сервис объектов, работающий в локальной сети компании на сайте ArcGIS Server.
Чтобы создать сервис объектов, менеджер проекта добавляет класс объектов сенсора из версии по умолчанию исходной многопользовательской базы геоданных на карту в ArcGIS Pro. Класс пространственных объектов зарегистрирован для традиционного управления версиями. Сенсоры, включенные в инспекцию, показываются желтым.
Для организации работы менеджер проекта создает версию из версии по умолчанию базы геоданных. Менеджер называет дочернюю версию Inspection и изменяет карту, чтобы она ссылалась на эту версию.
После этого менеджер проекта публикует сервис объектов InspectionFS из ArcGIS Pro.
В процессе публикации менеджер проекта редактирует следующие настройки на вкладке Конфигурация векторного слоя, чтобы позволить перевести слой в автономный режим и редактировать:
- В разделе Включить редактирование и разрешить редакторам пункт Добавлять, обновлять и удалять объекты позволяет редактировать данные в полном объеме.
- Включить синхронизацию - позволяет перевести слой в автономный режим.
- В разделе Синхронизация пункт Создать версию для каждого пользователя позволяет создавать версию реплики для сотрудника при первой загрузке карты. Эта версия реплики используется при синхронизации правок данных сотрудником.
Создание веб-карты
После публикации сервиса объектов менеджер проекта создает веб-карту на портале ArcGIS Enterprise и предоставляет возможность ее использования другим мобильным работникам – участникам группы.
Менеджер проекта выполняет следующие действия:
- Войдите в организацию.
- Создает веб-карту.
- Добавляет недавно опубликованный сервис объектов на веб-карту.
- Сохраните веб-карту.
- Открывает доступ к веб-картам и сервису объектов для группы мобильных работников.
- Включает автономный режим веб-карты для ее автономного использования.
Загрузка веб-карты
Каждый мобильный сотрудник получает доступ к веб-карте, входя в свои учетные записи в организации из мобильного приложения, пока он все еще находится в сети, и загружает карту и данные на свои устройства.
На следующей схеме показано, что один из мобильных сотрудников (Джо) начинает процесс загрузки.
Джо выбирает экстент и разрешение базовой карты для своей карты.
После начала процесса загрузки из опубликованной версии базы геоданных создается версия реплики в исходной базе геоданных, с именем Joe_InspectionFS. Поскольку сервис объектов создает версию для каждого пользователя, имя версии реплики состоит из имени мобильного работника (Joe) и имени сервиса, из которого она был создана (InspectionFS). Эта версия реплики будет использоваться при синхронизации загруженной карты.
Примечание:
Когда Джо загружает карту из сервиса InspectionFS, она начинает ссылаться на версию реплики Joe_InspectionFS. Например, ему может понадобиться удалить локальную карту и создать ее заново – уже с большим экстентом. Когда Джо снова загружает карту, все изменения, которые Джо ранее синхронизировал из версии реплики Joe_InspectionFS, будут видны на карте.
После загрузки карты и данных, мобильное приложение переключает карту на локальные данные. На этом этапе Джо может редактировать карту, не находясь в сети.
Второй мобильный работник (Мэри) выполняет те же действия, что и Джо. Это приводит к созданию в исходной базе геоданных версии реплики Mary_InspectionFS.
Синхронизация изменений
Находясь в поле, Джо работает в восточной части карты. Джо обновляет статусы объектов сенсора во время проверки. Если сенсор проходит проверку, он показывается зеленым. Если он поврежден и требует ремонта, он показывается красным.
В конце дня Джо подключается к сети с полевого устройства и синхронизирует данные с сервисом объектов. Это приводит к сохранению изменений из версии реплики Joe_InspectionFS в исходной базе геоданных.
В конце дня Мэри также синхронизирует данные своей проверки сенсоров, выполненной в западной части карты.
Запуск ночной обработки базы геоданных
Вечером запускается автоматический процесс согласования и закрепления изменений, внесенных мобильными работниками. Процесс сначала согласовывает и закрепляет каждую версию реплики в версии Inspection. Процесс применяет политику разрешения конфликтов, при которой сохраняется последняя правка, а обнаружение конфликтов основано на атрибутах.
После применения всех полевых изменений в версии Inspection, для данных запускается скрипт проверки. Эти скрипты идентифицируют и корректируют правки (некорректные значения либо объекты, находящиеся вне границ). К примеру, поле статуса должно быть заполнено корректным значением статуса. Если значение некорректно, статус объекта меняется на требующий проверки, а объект показывается желтым. После завершения проверки, процесс согласовывает версии реплики мобильного сотрудника с версией Inspection, чтобы в каждой версии были самые последние изменения.
Во время утренней синхронизации данных Джо и Мэри видят обновления друг друга.
Примечание:
Ночной процесс также можно было согласовать с версией по умолчанию, чтобы включить изменения, которые были внесены в версию по умолчанию с момента начала проекта. Вместо этого менеджер проекта решил согласовать только с версией по умолчанию в конце проекта. Это позволит выявить и вручную просмотреть конфликты перед закреплением данных в версии по умолчанию. Если этот процесс выполнен в конце работы над проектом, работники могут осуществлять дополнительные правки объектов, которые не отобразятся в качестве конфликтов во время процесса итогового согласования.
Также помните, что в этом примере процесс согласования и закрепления внесенных мобильными работниками изменений запускается ночью. То есть мобильный работник увидит последние правки, сделанные другими, только на следующий день. Для уменьшения этого временного промежутка процесс можно запускать чаще. К примеру, если запускать его каждый час, мобильный работник сможет запускать синхронизацию каждый час, чтобы увидеть внесенные другими пользователями изменения.
Удалите загруженные карты и выполните итоговое согласование и закрепление данных
Процесс, описанный выше, продолжается в течение недели – времени выполнения проекта. Проект завершается, когда проверены все датчики. В конце проекта мобильных сотрудников просят синхронизировать последние внесенные ими правки и удалить локальную карту из мобильного приложения. После удаления локальных карт из мобильного приложения реплики версий мобильных сотрудников больше не связаны с загруженной картой. Затем менеджер проекта останавливает и удаляет сервис объектов.
Менеджер проекта выполняет итоговое согласование и закрепление версий реплики всех мобильных работников, затем удаляет их. После этого менеджер проекта согласовывает и закрепляет версию Inspection с версией по умолчанию. Во время этого процесса менеджер проекта вручную просматривает и разрешает конфликты. После этого актуальная информация о состоянии сенсоров становится доступной для всех работников в версии по умолчанию. Последним действием менеджера проектов является удаление версии Inspection.
Загрузка карты для постоянного проекта
Данный рабочий процесс похож на предыдущий (Загрузка карт для краткосрочного проекта), в котором мобильные работники синхронизируют правки, выполненные ими в автономном режиме. Они подключаются к сети и синхронизируют изменения утром и в конце рабочего дня. Так же как в предыдущем, в этом рабочем процессе сервис объектов публикуется из версии с гарантированным качеством, а не напрямую из версии по умолчанию. Это приводит к необходимости выполнения дополнительной проверки, согласования и закрепления. Однако в отличие от предыдущего рабочего процесса версия с гарантированным качеством остается в базе геоданных, и ее существование не ограничивается сроком жизни проекта.
Ниже приведены шаги, необходимые для завершения этого рабочего процесса:
- Публикация сервиса объектов
- Создание веб-карты
- Загрузка веб-карты
- Синхронизация изменений
- Запуск ночной обработки базы геоданных
Публикация сервиса объектов
Для данного проекта менеджер создает и публикует веб-карту для проверок сенсоров в учетной записи организации. Веб-карта ссылается на сервис объектов, работающий на локальном сайте ArcGIS Server компании.
Чтобы создать сервис объектов, менеджер проекта добавляет класс объектов сенсора из версии по умолчанию исходной многопользовательской базы геоданных на карту в ArcGIS Pro. Класс пространственных объектов зарегистрирован для традиционного управления версиями. Сенсоры, включенные в инспекцию, показываются желтым.
С целью организации работы менеджер проекта создает дочернюю версию из версии по умолчанию и называет ее Inspection. Менеджер изменяет карту, чтобы она ссылалась на версию Inspection.
После этого менеджер проекта публикует сервис объектов InspectionFS из карты ArcGIS Pro.
Менеджер проекта проверяет возможность Синхронизации в Редакторе сервиса в ArcGIS Server Manager, поскольку сервис будет использоваться в автономной карте. Менеджер проекта также щелкает Расширенные опции для отображения Расширенных опций сервисов объектов.
В Расширенных опциях сервиса объектов менеджер проекта выбирает опцию Создать версию для каждого пользователя. С использованием этой опции во время первой загрузки мобильным сотрудником карты для него создается версия. Эта версия реплики затем используется при синхронизации правок данных сотрудником.
В процессе публикации менеджер проекта редактирует следующие настройки на вкладке Конфигурация векторного слоя, чтобы позволить перевести слой в автономный режим и редактировать:
- В разделе Включить редактирование и разрешить редакторам пункт Добавлять, обновлять и удалять объекты позволяет редактировать данные в полном объеме.
- Включить синхронизацию - позволяет перевести слой в автономный режим.
- В разделе Синхронизация пункт Создать версию для каждого пользователя позволяет создавать версию реплики для сотрудника при первой загрузке карты. Эта версия реплики используется при синхронизации правок данных сотрудником.
Создание веб-карты
После публикации сервиса объектов менеджер проекта создает веб-карту на портале ArcGIS Enterprise и предоставляет возможность ее использования другим мобильным работникам – участникам группы.
Менеджер проекта выполняет следующие действия:
- Войдите в организацию.
- Создает веб-карту.
- Добавляет недавно опубликованный сервис объектов на карту.
- Сохраните веб-карту.
- Открывает доступ к веб-картам и сервису объектов для группы мобильных работников.
- Включает автономный режим веб-карты для ее автономного использования.
Загрузка веб-карты
Каждый мобильный сотрудник получает доступ к веб-карте, входя в свои учетные записи из мобильного приложения, пока он все еще находится в сети, и загружает карту и данные на свои устройства.
На следующей схеме показано, что один из мобильных сотрудников (Джо) начинает процесс загрузки.
Джо выбирает экстент и разрешение для карты.
После начала процесса загрузки ArcGIS создает версию реплики (Joe_InspectionFS) из опубликованной версии (Inspection) в исходной базе геоданных. Поскольку сервис объектов создает версию для каждого пользователя, имя версии реплики состоит из имени мобильного работника (Joe) и имени сервиса, из которого она был создана (InspectionFS). Эта версия реплики будет использоваться при синхронизации карты.
Примечание:
Когда Джо загружает карту из сервиса InspectionFS, она начинает ссылаться на версию реплики Joe_InspectionFS. Например, ему может понадобиться удалить локальную карту и создать ее заново – уже с большим экстентом. Когда Джо снова загрузит карту, все изменения, которые были синхронизированы из версии реплики Joe_InspectionFS, появятся на карте.
После загрузки карты и данных, мобильное приложение переключает карту на локальные данные. На этом этапе Джо может редактировать карту, не находясь в сети.
Второй мобильный работник (Мэри) выполняет те же действия, что и Джо. Это приводит к созданию в исходной базе геоданных версии реплики Mary_InspectionFS.
Пока Мэри и Джо редактируют данные в поле, офисный сотрудник добавил в версию базы геоданных по умолчанию новый сенсор. Новый сенсор – результат нового проекта для той же территории. Всякий раз после установки новых сенсоров требуется проверка – и они показываются желтым.
Синхронизация изменений
Находясь в поле, Джо работает в восточной части карты. Джо обновляет состояние каждого объекта сенсора во время его проверки. Если сенсор проходит проверку, он показывается зеленым. Если он поврежден и требует ремонта, он показывается красным.
Когда мобильное устройство подключается к сети в конце дня, Джо синхронизирует данные с сервисом объектов. Это приводит к сохранению изменений из версии реплики Joe_InspectionFS в исходной базе геоданных.
В конце дня Мэри также синхронизирует данные своей проверки сенсоров, выполненной в западной части карты.
Запуск ночной обработки базы геоданных
Вечером запускается автоматический процесс согласования и закрепления изменений, внесенных мобильными работниками. Процесс сначала согласовывает и закрепляет версию реплики каждого сотрудника в версии Inspection. Процесс применяет политику разрешения конфликтов, при которой сохраняется последняя правка, а обнаружение конфликтов основано на атрибутах.
После применения всех полевых изменений в версии Inspection, в версии Inspection запускаются скрипты проверки данных. Эти скрипты идентифицируют и корректируют правки (некорректные значения либо объекты, находящиеся вне границ).
Примечание:
В этой части процесса версия реплики Mary_InspectionFS содержит правки, выполненные Джо, а версия Joe_InspectionFS не содержит правки, внесенные Мэри. Это объясняется тем, что версия реплики Joe_InspectionFS была согласована и закреплена ранее версии реплики Mary_InspectionFS.
Следующий шаг автоматического процесса включает согласование и закрепление версии Inspection в версии по умолчанию. Этот процесс обнаруживает конфликты на основе атрибутов и разрешает их автоматически. Согласование передает изменения из версии по умолчанию (новый сенсор) в версию Inspection, а процесс закрепления вносит изменения из версии Inspection (изменения, внесенные Джо и Мэри) в версию по умолчанию.
Для завершения процесса версия реплики каждого мобильного сотрудника согласовывается второй раз с версией Inspection. Версия реплики каждого мобильного сотрудника теперь является актуальной.
Подсказка:
Для применения последних изменений в версии мобильных работников требуется процесс согласования, а процесс закрепления – нет. Некоторые организации могут запускать отдельный процесс закрепления правок в версии по умолчанию, поскольку это делает изменения доступными другим пользователям, не относящимся к проекту.
Следующим утром, во время синхронизации данных Джо и Мэри, они увидят обновленные другими сотрудниками сенсоры, а также появившийся сенсор из версии по умолчанию. Новый сенсор находится в восточной части карты, поэтому Джо проверит новый сенсор и синхронизирует результаты своей работы. На следующий день, после запуска ночных процессов, информация о проверке Джо нового сенсора будет в версии по умолчанию.
Этот процесс повторяется ежедневно. Версии реплики Joe_InspectionFS и Mary_InspectionFS существуют до тех пор, пока Джо и Мэри выполняют проверки сенсоров. Если в какой-то момент они перестают работать над проектом, версии реплики могут быть удалены, как только Джо и Мэри выполнят окончательную синхронизацию, отменят регистрацию своих локальных карт, и будут осуществлены последние процессы согласования и закрепления в версиях реплики Joe_InspectionFS и Mary_InspectionFS.