Szenarien für Verzweigungsversionen

Mit der Standard- oder Advanced-Lizenz verfügbar.

Die Unternehmensanforderungen Ihrer Organisation bestimmen die Szenarien der Verzweigungsversionierung, die Sie verwenden.

Die Workflows unterscheiden sich, verlaufen jedoch häufig in getrennten Phasen, wobei jede Phase die Zuordnung unterschiedlicher Ressourcen und Geschäftsregeln erfordert. Meist stellen die einzelnen Phasen im Gesamtprozess einzelne Arbeitseinheiten dar, z. B. Arbeitsaufträge oder Aufträge. Zur besseren Verwaltung können Sie jeweils eine eigene, isolierte Version erstellen und diese bearbeiten. Wenn diese Arbeit abgeschlossen ist, können Sie die Änderungen in die Default-Version integrieren.

Grundkenntnisse der Organisations- und Geschäftsanforderungen sowie der wichtigsten Aspekte hinsichtlich der Szenarien für Verzweigungsversionen sind bei der Auswahl des optimalen Vorgehens in der Organisation unerlässlich.

Das Konzept der Versionierung ist bei Verzweigungsversionierung und traditioneller Versionierung gleich. Die Versionierung bietet Repräsentationen der Daten, ohne Daten zu kopieren, erlaubt die gleichzeitige Bearbeitung und ermöglicht es Benutzern, für längere Zeiträume eine Version zu nutzen. Weitere Details finden Sie im Überblick über die Versionierung.

Die Verzweigungsversionierung ist eine Form der Geodatabase-Versionierung, die mit dem ArcGIS Enterprise-Web-GIS-Modell arbeitet. Sie nutzt eine Service-basierte Architektur, um Bearbeitungs-Workflows für mehrere Benutzer und Szenarien mit langen Transaktionen über Web-Feature-Layer zu unterstützen. Web-Feature-Layer (werden auch als Feature-Services bezeichnet) sind Layer, die zum Anzeigen, Abfragen und Bearbeiten von Daten im Web freigegeben werden.

Die Abbildung zeigt einen allgemeinen Überblick über den Workflow der Verzweigungsversionierung.

Die Verzweigungsversionierung unterstützt einfache Feature-Classes und Tabellen sowie komplexe Geodatabase-Datasets wie Versorgungsnetze und Parcel-Fabrics in einer Enterprise-Geodatabase. Es ist wichtig, das Dataset gut vorzubereiten, damit die unterschiedlichen Workflows bewältigt werden, die durch Zugriff auf die Web-Feature-Layer durchgeführt werden können. Die Daten müssen als nach Verzweigung versioniert registriert werden und über eine Enterprise-Geodatabase veröffentlicht werden. Nachdem die Web-Feature-Layer veröffentlicht wurden, können Sie mithilfe der Verzweigungsversionierung Änderungen in Form von Einfüge-, Aktualisierungs- und Löschoperationen an Features in einer Version verfolgen.

Eine vollständige Liste der für die Verzweigungsversionierung unterstützten Datasets finden Sie in den Optionen für Bearbeitungs-Workflows.

Wenn die Daten als nach Verzweigung versioniert registriert sind und Sie die Funktion Versionsverwaltung nicht für den Web-Feature-Layer aktivieren, werden alle Operationen, z. B. Abfragen und Bearbeiten von Daten, mit der Default-Version durchgeführt. Sie können keine der Operationen der Versionsverwaltung nutzen, also benannte Versionen nicht erstellen oder löschen bzw. Versionen nicht ändern, und Sie können keine Abgleich- und Zurückschreibevorgänge ausführen.

Erfahren Sie mehr über Überlegungen zur Bearbeitung von Feature-Services.

In den folgenden Abschnitt finden Sie allgemeine Überlegungen zur Verzweigungsversionierung sowie Beschreibungen von mehreren Bearbeitungsszenarien für Verzweigungen und empfohlene Versionierungskonfigurationen.

Allgemeine Überlegungen

Bedenken Sie im Hinblick auf die Verzweigungsversionierung Folgendes:

• Editoren müssen nach Verzweigung versionierte Daten über den Web-Feature-Layer bearbeiten. Sie können keine Verbindung mit der Geodatabase in ArcGIS Pro über eine Datenbankverbindung herstellen und die Daten bearbeiten. Dies bedeutet, dass Sie nach Verzweigung versionierte Daten als Web-Feature-Layer veröffentlichen und den Web-Feature-Layer für die entsprechende Zielgruppe (eine Gruppe, die Organisation oder die Öffentlichkeit) freigeben müssen. Wenn Sie den Web-Feature-Layer für eine Gruppe oder die Organisation freigeben, müssen Portalmitglieder, die den Feature-Layer bearbeiten müssen, einer Rolle angehören, die die Berechtigung zum Bearbeiten von Features umfasst.

  Hinweis:

  Der Besitzer der nach Verzweigung versionierten Daten kann über eine Datenbankverbindung eine Verbindung mit der Geodatabase in ArcGIS Pro herstellen und Geoverarbeitungswerkzeuge ausführen, die die nach Verzweigung versionierten Daten ändern. Dies sollte für Vorgänge vorbehalten bleiben, die das Massenladen von Daten erleichtern, wie Anhängen oder Features kopieren.

• Beim Bearbeiten von nach Verzweigung versionierten Daten werden die Aktualisierungen möglicherweise nicht sofort in der Attributtabelle angezeigt. Wenn die aktualisierten Daten in der Attributtabelle angezeigt werden sollen, müssen Sie die Datenquelle aktualisieren. Klicken Sie hierzu auf die Schaltfläche Aktualisieren auf der Registerkarte Versionierung auf dem Menüband oder im Bereich Inhalt, wählen Sie Nach Datenquelle auflisten aus, klicken Sie mit der rechten Maustaste auf die entsprechende Datenquelle für die nach Verzweigung versionierten Daten, und wählen Sie Aktualisieren aus.
• Sie müssen eine Verbindung mit dem Web-Feature-Layer herstellen, um benannte Versionen zu erstellen. Der Besitzer der benannten Version ist das Portalmitglied, mit dem die Verbindung mit dem aktiven Portal authentifiziert wurde, als Sie die benannte Version erstellt haben.
• Wenn Sie die Zugriffsberechtigung für Versionen festlegen, müssen Sie Ihre Workflows in Bezug auf die Versionen sowie die Anforderungen der verschiedenen Benutzer berücksichtigen, die in dieser Umgebung arbeiten.
• Die Berechtigungen des Portalmitglieds, das auf den Web-Feature-Layer zugreift, sowie die Zugriffsberechtigungen für Versionen und die Einstellungen des Web-Feature-Layers bestimmen, was das Portalmitglied mit Verzweigungsversionen und den darin enthaltenen Daten tun kann.
• Die Konfliktlösung für nach Verzweigung versionierte Daten kann über mehrere Bearbeitungssitzungen verwaltet werden. Sie können das ArcGIS Pro-Projekt auch schließen, neu öffnen und Konflikte bearbeiten.
• Workflows für die Verwaltung von Verzweigungsversionen sind mit einem vereinfachten Datenmodell optimierte Workflows. Abgleichen und Zurückschreiben werden weiterhin durchgeführt, um Änderungen zusammenzuführen und in die Default-Versionen zurückzuschreiben. Das Komprimieren ist jedoch für nach Verzweigung versionierte Datasets nicht erforderlich. Änderungen werden mit Archivierung verfolgt. Dabei werden alle Änderungen in der Basistabelle des Datasets gespeichert.

Bearbeiten von Daten in der Default-Version

Um anderen die Bearbeitung der Daten in der Default-Version zu erlauben, veröffentlichen sie die nach Verzweigung versionierten Daten. Der Web-Feature-Layer referenziert die Default-Version der Daten automatisch.

Bei der Bearbeitung von Daten in der Default-Version werden Änderungen sofort in der zugrunde liegenden Datenquelle gespeichert. Das Bearbeiten von Daten in der Default-Verzweigungsversion entspricht regulären kurzen Datenbanktransaktionen. Wenn Sie die Default-Verzweigungsversion bearbeiten, startet Ihre erste Änderung die Transaktion. Die von Ihnen ausgeführten Bearbeitungsvorgänge werden jeweils automatisch als einzelne Transaktion in die Datenbank übernommen. Sie müssen die Änderungen nicht speichern. Die Änderungen, die Sie vornehmen, sind für alle anderen Benutzer und Anwendungen verfügbar, die auf den Web-Feature-Layer in der Default-Version zugreifen, wenn die Transaktion abgeschlossen ist.

Wenn der Versionszugriff auf die Default-Version (orange) auf "Öffentlich" festgelegt ist, können Editoren die Daten in der Default-Version, also die veröffentlichte Version, bearbeiten. Viewer, die auf diesen veröffentlichten Web-Feature-Layer (Feature-Service) mit aktivierter Versionsverwaltung zugreifen, können auch die an der Default-Version vorgenommenen Aktualisierungen anzeigen.

Der Versionszugriff basiert auf einer Kombination aus den Berechtigungen des aktiven Portal-Benutzers und der Zugriffsberechtigung, die für die Version konfiguriert ist. Die Berechtigungen des Portal-Benutzers und die Zugriffsberechtigungsebene für die Version (Öffentlich oder Geschützt) der Default-Version bestimmen, welche Arten von Bearbeitungs-Workflows zulässig sind.

• Öffentlich: Wenn die Zugriffsebene der Default-Version auf Öffentlich festgelegt ist, können alle Portal-Benutzer die Daten in der Default-Version bearbeiten, und Benutzer, die Daten in benannten Versionen bearbeiten, können ihre Änderungen in die Default-Version zurückschreiben. Dies ist die standardmäßige Zugriffseinstellung für die Default-Version.
• Geschützt: Wenn die Zugriffsebene der Default-Version auf Geschützt festgelegt ist, können nur Benutzer, die Versionsadministrator (Portal-Benutzer mit erweiterten Berechtigungen) sind, die Daten in der Default-Version bearbeiten oder Datenänderungen von benannten Versionen in die Default-Version zurückschreiben. Alle anderen Editoren müssen eine benannte Version erstellen, um mit der Bearbeitung zu beginnen.

Überlegungen

Bedenken Sie Folgendes, wenn Sie Daten in der Default-Version verwenden oder bearbeiten:

• Mehrere Benutzer können Daten in der Default-Version gleichzeitig bearbeiten.
• Wenn die Funktion Versionsverwaltung für den Web-Feature-Layer aktiviert ist, können Sie Ihre Änderungen an den Daten in der Default-Version nicht rückgängig machen und wiederholen.
• Beim Bearbeiten der Daten in der Default-Version erfolgt keine Konflikterkennung. Wenn ein Benutzer ein Feature aktualisiert und die Änderungen speichert und ein anderer Benutzer dasselbe Feature aktualisiert und die Änderungen speichert, wird die erste Aktualisierung von der zweiten überschrieben.

Bearbeiten einer benannten Version

Wenn Sie mehrere Projekte, Arbeitsaufträge oder Aufträge verwalten, müssen Sie bei der Verwaltung von Workflows strukturiert vorgehen. Eigenständige Arbeitseinheiten können sich über zahlreiche Editiersitzungen und mehrere Tage, Wochen oder Monate erstrecken, ohne dass die Default-Version geändert wird. Beispiele für solche eigenständigen Arbeitseinheiten sind Autobahnausbauten, die Einrichtung neuer Telefon-Services oder auch ein laufendes Wartungsprojekt für eine Gas-Pipeline. Bei Beginn eines Arbeitsauftrags oder Projekts können Sie eine benannte Version der Default-Version erstellen, um Änderungen zu isolieren.

Die Verzweigungsversionierung lässt nur eine Ebene benannter Versionen zu, die aus der Default-Verzweigungsversion erstellt werden. Um in einer benannten Version mit nach Verzweigung versionierten Datasets zu arbeiten und diese in Versionierung-Workflows einzubinden, gehen Sie wie folgt vor:

• Aktivieren Sie die Funktion Versionsverwaltung, wenn Sie nach Verzweigung versionierte Daten veröffentlichen. Anschließend stellt der Versionsverwaltungsservice (VMS) Funktionen zum Erstellen, Ändern und Löschen von benannten Versionen sowie zum Abgleichen und Zurückschreiben von Änderungen aus benannten Versionen in die Default-Version bereit. Dies ist erforderlich, um Web-Feature-Layer zu unterstützen, die nach Verzweigung versionierte Datasets nutzen.
• Erstellen Sie eine benannte Version, um Editoren ihre eigene, isolierte Ansicht für die parallele Arbeit mit denselben Daten bereitzustellen und Konflikte erkennen und lösen zu können, bevor Änderungen in die Default-Version zurückgeschrieben werden.

Wenn der Versionszugriff auf die Default-Version (orange) auf "Öffentlich" festgelegt ist, können Editoren die Daten der Default-Version bearbeiten. Sie können aber auch eine benannte Version wie Version A (grün) oder Version B (violett) erstellen und bearbeiten. Dann können die Editoren ihre Änderungen abgleichen (R) und die Änderungen aus der benannten Version in die veröffentlichte Default-Version zurückschreiben (P). Viewer, die auf diesen veröffentlichten Web-Feature-Layer (Feature-Service) mit aktivierter Versionsverwaltung zugreifen, können die an der Default-Version vorgenommenen oder zurückgeschriebenen Aktualisierungen anzeigen.

Wenn Sie eine Strategie auswählen, bei der kein Benutzer die Default-Version direkt bearbeitet, kann der Geodatabase-Administrator die Eigenschaften der Default-Version ändern und die Versionszugriffsebene auf Geschützt festlegen. Dann können die Benutzer weiterhin die Daten in der der Default-Version anzeigen, der Zugriff kann aber auf Lesezugriff beschränkt werden. Editoren, die die Daten ändern möchten, müssen eine benannte Version erstellen und die Daten in dieser Version bearbeiten.

Wenn der Versionszugriff auf die Default-Version (orange) auf "Geschützt" festgelegt ist, können Editoren nur Daten in einer benannten Version wie Version A (grün) oder Version B (violett) bearbeiten. Editoren können ihre Änderungen mit der geschützten Default-Version abgleichen (R), und Versionsadministratoren können Änderungen in diese Version zurückschreiben (P). Viewer, die auf diesen veröffentlichten Web-Feature-Layer (Feature-Service) mit aktivierter Versionsverwaltung zugreifen, können die in die Default-Version zurückgeschriebenen Aktualisierungen anzeigen.

Wenn ein Web-Feature-Layer mit aktivierter Funktion Versionsverwaltung über eine Portal-Verbindung neu zur Karte hinzugefügt wird, greift er auf die Default-Version zu. Sie können jedoch mit dem Dialogfeld Version ändern zwischen Versionen wechseln. Wenn Sie einen Web-Feature-Layer mit aktivierter Versionsverwaltung bearbeiten, können Sie die Daten in der Default-Version oder in einer benannten Version bearbeiten, sofern eine vorhanden ist. Beim Bearbeiten von Daten in einer benannten Version können Sie einzelne Änderungen rückgängig machen und wiederholen sowie Gruppen von Änderungen speichern oder verwerfen. Um auf diese Bearbeitungsfunktionen in einer benannten Version zuzugreifen, muss die bearbeitete Version von anderen Editoren und Viewern isoliert werden. Um dies zu erreichen, bietet ArcGIS Pro Sperrmechanismen, die den Zugriff auf Versionen für die Anzeige oder Bearbeitung beschränken.

Das Sperrmodell ermöglicht wie folgt mehrere gleichzeitige Viewer oder einen einzelnen Editor:

• Sobald ein Editor mit der Bearbeitung von Daten in einer benannten Version beginnt, wird eine exklusive Sperre eingerichtet, sodass sich während der Editiersitzung keine anderen Benutzer mit der Version verbinden können.
• Damit ein Editor Daten in einer benannten Version bearbeiten kann, dürfen zu diesem Zeitpunkt keine anderen Benutzer mit dieser Version verbunden sein.

Um einige dieser Sperren zu vermeiden, legen Sie die Zugriffsberechtigung für die benannte Version auf Privat fest. Mit einer als Privat festgelegten Zugriffsberechtigung für eine benannte Version können nur Benutzer mit erweiterten Berechtigungen (beispielsweise der Portal-Administrator und der Versionsadministrator) eine Verbindung herstellen.

Wenn der Versionszugriff auf die Default-Version (orange) auf "Geschützt" festgelegt ist, können Editoren nur Daten in einer benannten Version wie Version A (grün) oder Version B (violett) bearbeiten. Damit keine anderen Benutzer eine Verbindung mit der benannten Version herstellen, können Editoren den Versionszugriff für ihre benannte Version auf "Privat" festlegen. Editoren können ihre Änderungen mit der geschützten Default-Version abgleichen (R), und Versionsadministratoren können Änderungen in diese Version zurückschreiben (P). Viewer, die auf diesen veröffentlichten Web-Feature-Layer (Feature-Service) mit aktivierter Versionsverwaltung zugreifen, können die in die Default-Version zurückgeschriebenen Aktualisierungen anzeigen.

Sobald alle Änderungen am Arbeitsauftrag, Auftrag oder Projekt abgeschlossen sind, können Sie einen Abgleich durchführen, um Änderungen aus der Default-Version abzurufen und die gefundenen Konflikte zu lösen. Durch Verzweigungsversionierung können Sie Konflikte über mehrere Editiersitzungen hinweg verwalten, sie überprüfen und lösen und die Arbeit unterbrechen und später wieder aufnehmen. Sie können Konflikte einzeln überprüfen und bei Bedarf Änderungen vornehmen. Anschließend kann der Versionsadministrator die Änderungen von der benannten Verzweigungsversion in die geschützte Default-Version zurückschreiben und sie auf diese Weise integrieren. Dann kann die benannte Version gelöscht werden.

Überlegungen

Bedenken Sie Folgendes, wenn Sie die Daten in einer benannten Version bearbeiten:

• Die Verzweigungsversionierung lässt nur eine Ebene benannter Versionen zu, die aus der Default-Version erstellt werden. Anders ausgedrückt: Sie können keine benannte Version aus einer benannten Version erstellen.
• Nur ein Editor pro benannter Verzweigungsversion ist zulässig, oder mehrere Benutzer können die benannte Version lesen. Sobald ein Editor mit der Bearbeitung von Daten in einer benannten Version beginnt, wird eine exklusive Sperre eingerichtet, sodass sich kein anderer Benutzer mit dieser Version verbinden kann.
• Sie können Änderungen, die beim Bearbeiten von Daten in einer benannten Version vorgenommen werden, rückgängig machen und wiederholen.
• Abgleichen und Zurückschreiben erfolgen mit der Default-Version als Zielversion. Sie können diese Operationen nicht mit einer anderen benannten Version durchführen.
• Da das Modell der Verzweigungsversionierung ein zeitliches Modell ist, bei dem alle Datensätze und Änderungen in derselben Basistabelle verfolgt werden, ist kein Komprimieren erforderlich.

Unterstützen von Editoren und Viewern

Wenn Ihre Organisation mehrere Ebenen von Benutzern unterstützen muss, die jeweils unterschiedliche Operationen benötigen, ist es empfehlenswert, für jede Benutzerebene einen Web-Feature-Layer zu erstellen. Es könnte z. B. Editoren oder Viewer geben, die auf die versionierten Daten zugreifen müssen. In diesem Szenario können Sie diese Editoren und Viewer unterstützen, indem Sie zwei Web-Feature-Layer (Feature-Services) aus einer zugrunde liegenden Feature-Class veröffentlichen, die als nach Verzweigung versioniert registriert ist.

Sobald Editoren Änderungen im editierbaren Web-Feature-Layer (Feature-Service) in die Default-Version (orange) zurückschreiben, werden diese Änderungen in die zugrunde liegende Feature-Class aufgenommen, die als nach Verzweigung versioniert registriert ist. Sie sind für Viewer sichtbar, die auf den nicht editierbaren Web-Feature-Layer (grün) zugreifen, da dieser Web-Feature-Layer über die gleiche zugrunde liegende Feature-Class veröffentlicht wird.

• Veröffentlichen Sie den ersten Web-Feature-Layer als editierbaren Web-Feature-Layer mit aktivierter Funktion Versionsverwaltung. Geben Sie diesen Web-Feature-Layer für eine Gruppe frei, deren Mitglieder die Daten bearbeiten dürfen.

  Sobald der erste Web-Feature-Layer veröffentlicht wurde, können die Editoren entweder die Daten in der Default-Verzweigungsversion bearbeiten oder die Daten in einer benannten Version bearbeiten und ihre Änderungen abgleichen und zurückschreiben. Sobald die Änderungen abgeschlossen sind und ggf. in die Default-Version zurückgeschrieben wurden, sind sie unmittelbar in der Default-Version verfügbar. Diese Änderungen sind für den Web-Feature-Layer verfügbar, den Sie unten für Benutzer nur mit Leseberechtigung veröffentlichen.

• Veröffentlichen Sie einen zweiten Web-Feature-Layer mit aktivierter Abfragefunktion. Deaktivieren Sie dabei die Operationen zum Erstellen, Aktualisieren, Löschen, Exportieren und Synchronisieren. Beim Veröffentlichen dieses Web-Feature-Layers, für den die Bearbeitung nicht aktiviert ist, müssen Sie die Funktion Versionsverwaltung nicht aktivieren. Geben Sie diesen Web-Feature-Layer, für den die Bearbeitung nicht aktiviert ist, für eine Gruppe frei, deren Mitglieder nur eine schreibgeschützte Ansicht der Daten in der Default-Version benötigen. Geben Sie ihn alternativ für Ihre Organisation frei, um allen Mitgliedern der Organisation eine schreibgeschützte Ansicht der Daten in der Default-Version bereitzustellen.

Überlegungen

Bedenken Sie beim Unterstützen von Editoren und Viewern Folgendes:

• Da für den editierbaren Web-Feature-Layer die Funktion Versionsverwaltung aktiviert ist und er für die Editoren in der Organisation freigegeben wurde, können die Editoren benannte Versionen erstellen und löschen sowie die Eigenschaften von benannten Versionen ändern, Daten bearbeiten und abgleichen. Wenn die Zugriffsberechtigung der Default-Version auf Öffentlich festgelegt ist, können Editoren Änderungen von benannten Versionen in die Default-Version zurückschreiben.
• Um in einer benannten Version mit nach Verzweigung versionierten Datasets zu arbeiten und diese in versionierte Workflows einzubinden, müssen Sie die Funktion Versionsverwaltung beim Veröffentlichen des Web-Feature-Layers aktivieren. Der Portal-Benutzer, der den Web-Feature-Layer veröffentlicht hat, wird zum Versionsadministrator für diesen Layer. Der Besitzer eines Web-Feature-Layers kann ihn für die Gruppe oder Gruppen freigeben, welche die Mitglieder enthalten, die den Web-Feature-Layer bearbeiten müssen. Nach der Freigabe können Editoren Versionen erstellen, ändern und löschen. Zudem können sie Versionen bearbeiten, abgleichen und zurückschreiben.
• Da nur die Funktion Abfrage für den zweiten Web-Feature-Layer aktiviert ist und die Versionsverwaltung nicht aktiviert ist, können die Mitglieder, für die Sie den zweiten Web-Feature-Layer freigeben, nur auf die Default-Version zugreifen.
• Die Operation Abfrage ist für Viewer erforderlich, um die Daten im Web-Feature-Layer anzuzeigen. Aus diesem Grund ist die Abfrage-Operation beim Veröffentlichen von ArcGIS Pro aktiviert und kann nicht deaktiviert werden.

Projektphasen

Verwaltungssysteme für Arbeitsaufträge und die Zuweisung von Arbeitsaufträgen durchlaufen in einer Organisation mehrere Phasen. Viele Projekte werden in einer vorgeschriebenen und aufeinander abgestimmten Abfolge von Phasen durchgeführt, die vor dem Wechsel zur nächsten Phase baulich, behördlich oder rechtlich genehmigt werden müssen. Zu diesen Phasen können der erste Design-Vorschlag, die Bauerstellung, die Vermessung im Außeneinsatz, die Baukonstruktion und der Projektabschluss gehören. In jeder Phase eines Projekts können Teilmengen der Daten mehrfach aktualisiert werden. Dieser Prozess verläuft im Wesentlichen zyklisch: Ein Arbeitsauftrag wird anfänglich einem Ingenieur zugewiesen und in der Zeit, in der das Projekt verschiedene Phasen durchläuft, nach und nach geändert, bevor er vollständig in die Produktionsdatenbank integriert wird. Im letzten Schritt jeder Phase kann es erforderlich sein, dass ein Administrator den Besitz übernimmt, um vor dem Zurückschreiben eine Qualitätssicherung (QA) und Qualitätskontrolle (QC) oder eine Validierung durchzuführen.

Im folgenden Szenario wird eine benannte Version namens Proposed aus der Default-Version erstellt und stellt die Vorschlagsphase dieses Prozesses dar. Sobald die Änderungen in der Vorschlagsphase abgeschlossen sind, überträgt der Benutzer den Besitz der Version an den Versionsadministrator. Der Versionsadministrator prüft und führt den QA/QC-Validierungsprozess durch. Zudem übernimmt er das Abgleichen und Zurückschreiben der Änderungen in die geschützte Default-Version. Nach dem Zurückschreiben kann die Version "Proposed" gelöscht werden.

Ein Editor kann die benannte Version "Proposed" (grün) erstellen und über die geschützte Default-Version einen Abgleich (R) mit der benannten Version "Proposed" durchführen. Während der Editor (grün) die benannte Version "Proposed" bearbeitet, sieht der Viewer, was aus der Default-Version (orange) veröffentlicht wurde. Sobald der Editor die Bearbeitung abschließt und den Versionsbesitz auf den Administratorbenutzer (blau) überträgt, damit der den QA/QC-Prozess durchführen kann, gleicht dieser die Aktualisierungen mit der Default-Version ab (R) und schreibt sie zurück (P). Nach dem Zurückschreiben der Aktualisierungen in die Default-Version sind sie für Viewer sichtbar, wenn sie auf diesen veröffentlichten Web-Feature-Layer zugreifen.

Als Nächstes wird eine benannte Version namens "Constructed" aus der Default-Version erstellt und stellt die Bauphase dieses Prozesses dar. Sobald die Änderungen in der Bauphase abgeschlossen sind, überträgt der Besitzer der benannten Version den Besitz der Version an den Versionsadministrator. Der Versionsadministrator prüft und führt den QA/QC-Prozess durch. Zudem übernimmt er das Abgleichen und Zurückschreiben der Änderungen in die geschützte Default-Version. Sobald die Änderungen in die Default-Version zurückgeschrieben wurden, kann die Version "Constructed" gelöscht werden.

Ein Editor kann die benannte Version "Constructed" (violett) erstellen und über die geschützte Default-Version einen Abgleich (R) mit der benannten Version "Constructed" durchführen. Während der Editor (violett) die benannte Version "Constructed" bearbeitet, sieht der Viewer, was aus der Default-Version (orange) veröffentlicht wurde. Sobald der Editor die Bearbeitung abschließt und den Versionsbesitz auf den Administratorbenutzer (blau) überträgt, damit der den QA/QC-Prozess durchführen kann, gleicht der Versionsadministrator (Admin) die Aktualisierungen mit der Default-Version ab (R) und schreibt sie zurück (P). Nach dem Zurückschreiben der Aktualisierungen in die Default-Version sind sie für Viewer sichtbar, wenn sie auf diesen veröffentlichten Web-Feature-Layer zugreifen.

Dieser Lebenszyklusprozess, bei dem benannte Versionen erstellt werden, Änderungen vorgenommen werden und der Besitz der Version auf den Versionsadministrator übertragen wird, der dann den QA/QC-Prozess durchführt und das Abgleichen und Zurückschreiben in die Default-Version vornimmt, wird wiederholt, bis Sie den Abschluss oder die letzte Phase erreichen.

Überlegungen

Sie können Folgendes in allen oben beschriebenen Szenarien verwenden, aber es ist besonders in diesem QA/QC-Workflow hilfreich:

• Attributregeln: Attributregeln verbessern die Bearbeitung und die Datenintegrität für Geodatabase-Datasets. Sie sind benutzerdefinierte Regeln, die Attribute automatisch füllen, ungültige Änderungen bei Bearbeitungsvorgängen einschränken und Qualitätssicherungsprüfungen für vorhandene Features durchführen können.
• ArcGIS Data Reviewer: Data Reviewer ermöglicht das Verwalten von Daten für die Datenerzeugung und -analyse. Dazu wird ein System für die Automatisierung und Vereinfachung der Datenqualitätskontrolle bereitgestellt, das die Datenintegrität verbessern kann. Zu Data Reviewer gehört eine Reihe von QC-Werkzeugen, die eine effiziente und konsistente Datenprüfung ermöglichen, beispielsweise die Analyse der Attributwerte von Tabellen und der räumlichen Beziehungen zwischen Features.
• ArcGIS Workflow Manager: ArcGIS Workflow Manager ermöglicht das Optimieren und Standardisieren von Geschäftsprozessen, die mithilfe einer Reihe von Schritten, die durch Pfade verbunden sind, in ArcGIS Workflow Manager als Workflow dargestellt werden können. Mithilfe von Workflows können Tasks organisiert und erläutert werden, sodass kein Schritt vergessen wird. Informationen werden für jede Aktivität automatisch aufgezeichnet. Zudem gibt es Werkzeuge, mit denen Informationen über Tasks in Berichte aufgenommen werden. Zu ArcGIS Workflow Manager gehören Werkzeuge zum Zuweisen von Ressourcen und zum Verfolgen des Status und des Fortschritts von Aufträgen. Verschiedene E-Mail-Benachrichtigungen werden bereitgestellt, um Benutzer über Tasks, die ihnen zugewiesen wurden, abgeschlossene Tasks, bearbeitete räumliche Daten und weitere Aktivitäten zu informieren.

Verteiltes Datenmanagement

Sie können Workflows für mobile Editoren unterstützen, indem Sie Apps zur mobilen Datenerfassung oder in ArcGIS Pro die Schaltfläche Karte herunterladen verwenden.

Unter Offline-Karten und nach Verzweigung versionierte Daten erfahren Sie, wie Szenarien mit Verzweigungsversion für mobile Editoren implementiert werden.

Web-Feature-Layer, die auf nach Verzweigung versionierte Daten zugreifen, werden auch in Workflows zur verteilten Kollaboration unterstützt. Über eine Kollaboration können Sie Web-Feature-Layer mit aktivierter Synchronisierung als Kopien freigeben, um auf unterschiedliche Versionen der Daten zuzugreifen. Weitere Informationen über Kollaborationsprozesse und -konzepte finden Sie unter Funktionsweise von Kollaborationen.