Szenarien für Verzweigungsversionen

Im Folgenden wird die Anwendung der Versionierung beschrieben, d. h., wie diese Technologie in einer Organisation verwendet werden kann. Außerdem werden einige der verfügbaren Versionierungskonfigurationen erläutert.

Workflows unterscheiden sich von Organisation zu Organisation. Häufig verlaufen sie 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 Szenarien mit Verzweigungsversionen oder Szenarien mit traditionellen Versionen 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.

Ein allgemeiner Überblick über den Workflow der Verzweigungsversionierung ist dargestellt.

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 richtig vorzubereiten. Nur so kann eine Vielzahl von Workflows berücksichtigt werden, die durch den Zugriff auf die Web-Feature-Layer durchgeführt werden können, die die Daten enthalten, die als nach Verzweigung versioniert registriert und über eine Enterprise-Geodatabase veröffentlicht wurden. 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 Datentypen finden Sie in den Optionen für Bearbeitungs-Workflows .

Wenn Ihre Daten als nach Verzweigung versioniert registriert sind und die Funktion Versionsverwaltung nicht aktiviert ist, werden alle Operationen, z. B. Abfragen und Bearbeiten, mit der veröffentlichten Default-Version durchgeführt. Sie können keine der Operationen der Versionsverwaltung nutzen, also Versionen auch nicht erstellen, ändern, löschen oder abgleichen und zurückschreiben.

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

Allgemeine Überlegungen

Bedenken Sie im Hinblick auf die Verzweigungsversionierung Folgendes:

• Für die Bearbeitung von Verzweigungsversionen muss der Zugriff über einen Web-Feature-Layer erfolgen. Zudem muss dem Portal-Benutzer eine Rolle zugewiesen sein, die die Berechtigung "Bearbeiten" umfasst. Beim Zugriff auf Datasets mit Verzweigungsversionierung direkt über eine Datenbankverbindung sind keine Bearbeitungsfunktionen verfügbar.
• Verzweigungsversionen sind nur in dem Web-Feature-Layer verfügbar, in dem sie erstellt wurden.
• 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.
• Der Versionsbesitz basiert auf dem aktiven Portal-Benutzer. Die Berechtigungen des Portal-Benutzers bestimmten auch, welche Versionen der Benutzer anzeigen, bearbeiten und verwalten kann.
• Die Konfliktlösung für nach Verzweigung versionierte Daten kann über mehrere Sitzungen verwaltet werden.
• Versionsverwaltungs-Workflows 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 mehr erforderlich. Änderungen werden mit Archivierung verfolgt. Dabei werden alle Änderungen in der Basistabelle des Datasets gespeichert.

Bearbeiten der Default-Version

Die Default-Version ist die veröffentlichte Version, auf die Benutzer zugreifen, wenn sie mit nach Verzweigung versionierten Daten arbeiten. Dies ist die erste Version, die den meisten Benutzern angezeigt wird, wenn Sie Web-Feature-Layer über Services nutzen.

Um nach Verzweigung versionierte Daten zu bearbeiten, müssen Sie über einen Web-Feature-Layer darauf zugreifen. Wenn Sie Layer mit aktivierter Funktion Versionsverwaltung bearbeiten, werden die Änderungen sofort in der zugrunde liegenden Datenquelle gespeichert. Die Default-Version kann immer mehrere Editoren haben (z. B. mehrere Administratoren). Jedoch bestimmt die Einstellung für die Versionszugriffsebene, wer die jeweilige Version abrufen und bearbeiten darf. Wenn der Versionszugriff auf Öffentlich festgelegt ist, können alle Portal-Benutzer die Default-Version direkt bearbeiten, und Editoren können Änderungen in die Version zurückschreiben. Das Bearbeiten der Default-Verzweigungsversion entspricht regulären kurzen Datenbanktransaktionen. Wenn Sie die Default-Verzweigungsversion bearbeiten, startet Ihre erste Änderung in der Editiersitzung 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 Default-Version, also die veröffentlichte Version, direkt bearbeiten. Viewer, die auf diesen veröffentlichten Web-Feature-Layer (Feature-Service) mit aktiviertem VMS zugreifen, können auch die an der Default-Version vorgenommenen Aktualisierungen anzeigen.

Beim Veröffentlichen von nach Verzweigung versionierten Daten kann der Publisher die Funktion Versionsverwaltung aktivieren. Der Versionsverwaltungsservice (VMS) stellt die Operationen der Versionsverwaltung bereit, die zur Unterstützung von Web-Feature-Layern erforderlich sind, die mit nach Verzweigung versionierten Datasets arbeiten.

Der Versionszugriff basiert auf einer Kombination aus den Berechtigungen des aktiven Portal-Benutzers und der Zugriffsberechtigung der Version. 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: Alle Portal-Benutzer können die Default-Version direkt bearbeiten, und Editoren können Änderungen in die Version zurückschreiben.
• Geschützt: Nur Benutzer, die der Versionsadministrator (Portal-Benutzer mit erweiterten Berechtigungen) sind, können die Default-Version direkt bearbeiten oder Änderungen in sie zurückschreiben. Editoren müssen eine benannte Version erstellen, um mit der Bearbeitung zu beginnen.

Weitere Überlegungen

Bedenken Sie Folgendes, wenn Sie die Default-Version verwenden oder bearbeiten:

• Mehrere Benutzer können die Default-Version gleichzeitig bearbeiten.
• Beim Bearbeiten der Default-Version mit aktivierter Funktion Versionsverwaltung können Sie Änderungen nicht rückgängig machen oder wiederholen.
• Beim Bearbeiten 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 arbeitet mit einer vereinfachten Versionshierarchie, die das Erstellen von lediglich einer Ebene benannter Versionen aus der Default-Verzweigungsversion ermöglicht. Die Versionszugriffsebene für die Default-Verzweigungsversion ist standardmäßig auf Öffentlich festgelegt. Um in einer benannten Version mit nach Verzweigung versionierten Datasets zu arbeiten und diese an versionierten Workflows zu beteiligen, aktivieren Sie die Funktion Versionsmanagement beim Veröffentlichen des Service. Anschließend stellt der Versionsverwaltungsservice (VMS) Funktionen zum Erstellen, Ändern und Löschen von Versionen sowie zum Abgleichen und Zurückschreiben von Änderungen für Versionen bereit. Sie sind erforderlich, um Web-Feature-Layer zu unterstützen, die mit nach Verzweigung versionierten Datasets arbeiten. Sie können eine benannte Version erstellen, um den Editoren eine eigene, isolierte Ansicht für die parallele Arbeit mit denselben Daten bereitzustellen.

Wenn der Versionszugriff auf die Default-Version (orange) auf "Öffentlich" festgelegt ist, können Editoren die Default-Version direkt 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 in die veröffentlichte Default-Version zurückschreiben (P). Viewer, die auf diesen veröffentlichten Web-Feature-Layer (Feature-Service) mit aktiviertem VMS zugreifen, können die an der Default-Version vorgenommenen oder zurückgeschriebenen Aktualisierungen anzeigen.

Wenn Sie eine Strategie ausgewählt haben, bei der kein Benutzer die Default-Version direkt bearbeitet, kann der Geodatabase-Administrator die Versionseigenschaften ändern und die Versionszugriffsebene auf Geschützt festlegen. Dann können die Benutzer weiterhin die Default-Version anzeigen, der Zugriff kann aber auf Lesezugriff beschränkt. Bearbeiter, die die Daten ändern möchten, müssen eine benannten Version erstellen.

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

Wenn ein Web-Feature-Layer mit aktivierter Funktion Versionsverwaltung über eine Portal-Verbindung neu zur Karte hinzugefügt wird, wird die Default-Version verwendet. 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 Default-Version oder eine benannte Version bearbeiten, sofern eine vorhanden ist. Beim Bearbeiten 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 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 eine benannte Version bearbeiten kann, dürfen zu diesem Zeitpunkt keine anderen Benutzer mit dieser Version verbunden sein.

Wenn Sie beim Erstellen einer benannten Version den Versionszugriff auf Privat festlegen, können Sie das Sperren der Version für die Bearbeitung vermeiden. Mit einer als Privat festgelegten benannten 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 Änderungen an einer benannten Version wie Version A (grün) oder Version B (violett) vornehmen. Damit keine anderen Benutzer eine Verbindung mit der benannten Version herstellen, können Editoren den Versionszugriff für ihre benannte Version auf "Privat" festlegen. Sobald Editoren ihre Änderungen mit der geschützten Default-Version abgleichen (R) und sie in sie zurückschreiben (P), sehen Viewer, die auf diesen veröffentlichten Web-Feature-Layer (Feature-Service) mit aktiviertem VMS zugreifen, die in die Default-Version zurückgeschriebenen Änderungen.

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 gefundene 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 in die geschützte Default-Version zurückschreiben und integrieren. Dann kann die benannte Version gelöscht werden.

Weitere Überlegungen

Bedenken Sie Folgendes, wenn Sie eine benannte Version verwenden oder bearbeiten:

• Die Verzweigungsversionierung arbeitet mit einer vereinfachten Versionshierarchie, die das Erstellen von lediglich einer Ebene benannter Versionen aus der Default-Version ermöglicht.
• Lässt nur einen Editor pro Verzweigungsversion oder mehrere Leser zu. Sobald ein Editor mit der Bearbeitung einer Verzweigungsversion beginnt, wird eine exklusive Sperre eingerichtet, sodass sich keine anderen Benutzer mit der Version verbinden können.
• Die Funktionen zum Rückgängigmachen und Wiederholen sind beim Arbeiten in einer benannten Version verfügbar.
• 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 Benutzergruppen unterstützen muss, die jeweils unterschiedliche Operationen benötigen, ist es empfehlenswert, für jede Benutzerebene einen Service zu erstellen. Es könnte z. B. eine Gruppe von Editoren oder Viewern geben, die Lesezugriff auf das System benötigen. 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.

• Der erste Web-Feature-Layer wird als editierbarer Web-Feature-Layer mit aktivierter Funktion Versionsverwaltung veröffentlicht. Er wird erstellt, damit er nur für die Editoren in der Organisation zur Bearbeitung freigegeben werden kann.
• Ein zweiter Web-Feature-Layer wird mit aktivierter Abfragefunktion erstellt. Die Operationen zum Erstellen, Aktualisieren, Löschen, Exportieren und Synchronisieren sind deaktiviert. Dieser Web-Feature-Layer, für den die Bearbeitung nicht aktiviert ist, wird veröffentlicht, um einen nicht editierbaren Service bereitzustellen, der für die Viewer freigegeben wird, die eine schreibgeschützte Ansicht der veröffentlichten Daten benötigen.

  Hinweis:

  Beim Vorbereiten von Daten für die Veröffentlichung eines Feature-Service muss der verbundene Geodatabase-Benutzer der Besitzer der Daten sein, und die Geodatabase muss als Data Store registriert sein. Bei der Verzweigungsversionierung basiert der Versionsbesitz auf dem aktiven Portal-Benutzer. Wenn Sie den Web-Feature-Layer nur zur Bearbeitung oder Anzeige verwenden möchten, muss dem Portal-Benutzer eine Rolle mit der Berechtigung "Bearbeiten" oder "Viewer" zugewiesen sein.

Sobald der erste Web-Feature-Layer veröffentlicht wurde, können die Editoren entweder die Default-Verzweigungsversion bearbeiten oder eine benannte Version bearbeiten und mithilfe der Default-Version in diesem editierbaren Web-Feature-Layer abgleichen und zurückschreiben. Wenn die Änderungen abgeschlossen sind und in die Default-Version zurückgeschrieben wurden, sind sie sofort verfügbar. Sie können für einen anderen Web-Feature-Layer verwendet werden und mit aktivierter Abfragefunktion und deaktivierten Operationen zum Erstellen, Aktualisieren, Löschen, Exportieren und Synchronisieren veröffentlicht werden. Beim Veröffentlichen dieses Web-Feature-Layers, für den die Bearbeitung nicht aktiviert ist, müssen Sie die Funktion Versionsverwaltung nicht aktivieren.

Wenn weitere Änderungen an der Default-Version im editierbaren Web-Feature-Layer vorgenommen werden, sind sie direkt in der Default-Version des schreibgeschützten Web-Feature-Layers sichtbar, der für die Gruppe von Benutzern mit der Rolle "Viewer" verfügbar ist.

Weitere Überlegungen

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

• Editierbarer Web-Feature-Layer
  • Für den editierbaren Web-Feature-Layer ist die Funktion Versionsverwaltung aktiviert, und er wird nur für die Editoren in der Organisation freigegeben. Sie können Versionen erstellen, ändern und löschen. Zudem können sie Versionen bearbeiten, abgleichen und zurückschreiben.
• Nicht editierbare Web-Feature-Layer, bei denen nur die Abfragefunktion aktiviert ist
  • Der nicht editierbare Web-Feature-Layer, bei dem nur die Funktion Abfrage aktiviert ist, kann nur für Viewer mit Lesezugriff auf die Daten freigegeben werden. Viewer können nur auf die Default-Version dieses reinen Abfrage-Service zugreifen, da der Server für die Versionsverwaltung nicht aktiviert ist.
  • 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 besondere 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 einzelne benannte Version namens "Proposed" aus der Default-Version erstellt und stellt die Vorschlagsphase dieses Prozesses dar. Sobald die Änderungen in der Vorschlagsphase abgeschlossen sind, ändert der Benutzer den Besitz der Version und weist sie dem Administratorbenutzer zu. Der Administrator 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 einzelne benannte Version namens "Constructed" aus der Default-Version erstellt und stellt die Bauphase dieses Prozesses dar. Sobald die Änderungen in der Bauphase abgeschlossen sind, ändert der Benutzer den Besitz der Version und weist sie dem Administratorbenutzer zu. Der Administrator 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. Nach dem Zurückschreiben 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 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.

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

Weitere Überlegungen

Beachten Sie beim Arbeiten mit Projektphasen die folgenden Punkte:

• Dieser QA/QC-Workflow-Prozess kann Folgendes beinhalten:
  • Attributregeln: Attributregeln verbessern die Bearbeitung und die Datenintegrität für Geodatabase-Datasets. Sie sind benutzerdefinierte Regeln, die verwendet werden können, um Attribute automatisch zu füllen, ungültige Änderungen bei Bearbeitungsvorgängen einzuschränken und Qualitätssicherungsprüfungen für vorhandene Features durchzuführen.
  • 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.
  • Workflow Manager: Workflow Manager ermöglicht das Optimieren und Standardisieren Ihrer Geschäftsprozesse, die mithilfe einer Reihe von Schritten, die durch Pfade verbunden sind, in 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 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

Mit ArcGIS Collector oder in ArcGIS Pro über die Schaltfläche Karte herunterladen können Sie Workflows für mobile Benutzer unterstützen.

Erfahren Sie, wie Sie nach Verzweigung versionierte Daten in offline genommenen Feature-Services verwenden, wenn Sie mit nach Verzweigung versionierten Daten und mobilen Editoren arbeiten.

Die verteilte Kollaboration unterstützt auch Web-Feature-Layer. Dazu gehören solche, die mit nach Verzweigung versionierten Daten ausgeführt werden. Dadurch ist es möglich, Web-Feature-Layer mit aktivierter Synchronisierung als Kopie freizugeben, wenn die für die Kollaboration freigegebenen Web-Feature-Layer mit separaten Kopien der Daten ausgeführt werden. Weitere Informationen über Kollaborationsprozesse und -konzepte finden Sie unter Funktionsweise von Kollaborationen.