Aktualisierung: ArcGIS Pro 3.4/ArcGIS Enterprise 11.4 eingeführtAuslösende Felder was die Diskussion über die Minderung der Auswirkungen von Bearbeitungen mit Events beeinflusst.
Willkommen zur Serie zum Verständnis der Subnetzwerkverwaltung, in der wir einige der fortgeschritteneren Themen der Subnetzwerkverwaltung vertiefen. Wenn Sie nicht vertraut sind mit dem, was Subnetzwerke sind oder wie sie funktionieren, empfehle ich Ihnen, die Artikel und Tutorials in derVerwaltung von Subnetzwerken mit ArcGIS Utility Network-Lernserie zu lesen, um zu beginnen.
Die Verwaltung von Subnetzwerken kann oft das Durchführen von Hunderten oder Tausenden von Bearbeitungen an Features erfordern, wenn ein Subnetzwerk erstellt oder neu konfiguriert wird. Aus diesem Grund bietet das System verschiedene Bearbeitungsmodi, die verwendet werden können, um diese Aktualisierungen vorzunehmen.
Durch das Lesen dieses Artikels werden Sie die Auswirkungen dieser Einstellung auf die Leistung von Update Subnetwork verstehen und warum Sie für bestimmte Arbeitsabläufe Eventing aktivieren möchten, obwohl dies die Leistung beeinträchtigen kann.
Was ist ein Bearbeitungsmodus?
Was ist einBearbeitungsmodus? Im ArcGIS Utility Network bezieht sich derBearbeitungsmodus darauf, wie die Software Systemfelder bei Features verwaltet, wenn Subnetzwerke verwaltet werden. Derzeit gibt es zwei Optionen für Bearbeitungsmodi,mit Eventing oderohne Eventing.
Auf welches „Eventing“ beziehen wir uns, wenn wir sagen, dass wir Datenmit Eventing oderohne Eventing verwalten? Wenn wir von Eventing sprechen, beziehen wir uns speziell auf Geodatabase-Ereignisse, die als Reaktion auf Bearbeitungen ausgelöst werden. Geodatabase-Ereignisse sind eine der Methoden, mit denen ArcGIS spezielle Verhaltensweisen auslöst, wenn Objekte in einer Geodatabase bearbeitet werden. Häufige Beispiele hierfür sind Verhaltensweisen wie das Ausfüllen von Editor-Tracking-Feldern, das Auslösen von Attributregeln, das Übermitteln von Nachrichten an verwandte Objekte und das Aktualisieren von Feature-verknüpfter Annotation.
Was hat das mit den Subnetzwerken zu tun? Eines der Werkzeuge, das Benutzer häufig im Rahmen ihres Bearbeitungs-Workflows ausführen, ist dasUpdate Subnetwork-Werkzeug. Dieses Werkzeug ist verantwortlich für die Verwaltung der Systemfelder bei Utility Network-Features, die das Subnetzwerk beschreiben, an dem sie teilnehmen. Jedes dieser Features löst beim Bearbeiten unterschiedliche Bearbeitungsereignisse aus. Datenmodelle mit Beziehungen oder Attributregeln lösen während des Update Subnetwork mehr Ereignisse aus als Datenmodelle mit weniger Beziehungen und Attributregeln. Alle Ereignisse, Regeln und Beziehungen fügen dem Update Subnetwork-Prozess zusätzliche Zeit hinzu.
Um diese Situation zu handhaben, können Administratoren die Tiers in ihrem Netzwerk so konfigurieren, dass sie einen Bearbeitungsmodus verwenden, der entweder die normalen Geodatabase-Ereignisse (mit Eventing) nutzt oder das normale Geodatabase-Ereignismodell umgeht (ohne Eventing) beim Verwalten von Subnetzwerken in diesem Tier. Am Ende dieses Artikels gibt es eine kurze Diskussion darüber, wie Geschäftsanforderungen bewertet werden können und bewährte Verfahren für diese Entscheidung. Zusätzlich können Sie auch auslösende Felder verwenden, um genau zu steuern, auf welche Bearbeitungen Attributregeln reagieren sollen, um die Auswirkungen von Bearbeitungsevents während des Update Subnetwork zu mindern.
Aber schauen wir uns zunächst einige Beispiele verschiedener Konfigurationen an. In jedem Beispiel betrachten wir, wie eine Gruppe von Features unter bestimmten Bedingungen reagiert. Jedes Feature ist mit 4 Feldern beschriftet und wenn ein Wert geändert wird, erscheint das Feld/Wert fettgedruckt:
- Asset-ID – Dies ist ein eindeutiger Bezeichner für jedes Feature. Er wird beim Erstellen des Features ausgefüllt.
- Datum der Änderung – Dies ist das Editor-Tracking-Feld, das von der Geodatabase gepflegt wird.
- Subnetzwerkname – Dies ist das vom Utility Network gepflegte Feld für den Namen des Subnetzwerks.
- Netzwerkregion – Dieses Feld wird durch eine Attributregel gepflegt, die den Subnetzwerknamen des Features verwendet, um einen 'Region'-Wert aus einer Nachschlagetabelle abzurufen.
Hinweis: Wenn keine der Attributregeln Informationen aus dem Subnetzwerk benötigt hat, können alle Attributregeln so konfiguriert werden, dass sie bei Aktualisierungen während des Update Subnetwork nicht ausgelöst werden, um eine Leistungsbeeinträchtigung durch Attributregeln während des Update Subnetwork zu mindern.
Aktualisierung ohne Eventing im Standardmodus
Das erste Beispiel betrachten wir etwas, das jedes Projekt mindestens einmal durchführt: Das Ausführen von Update Subnetwork in der Standardversion in einer brandneuen Datenbank. In diesem Fall haben alle Subnetzwerknamenfelder in der Datenbank den Wert „Unbekannt“ und die restlichen Felder haben ihre Anfangswerte aus dem Datenimport. Ein Beispiel dafür sehen Sie in der Grafik unten.
Abbildung 1 Anfangszustand der Datenbank
Nach dem Ausführen von Update Subnetwork auf Netzwerk A sehen wir, dass das Feld für den Subnetzwerknamen bei allen Features im Subnetzwerk aktualisiert wurde, aber Editor Tracking und Attributregeln wurden während dieser Aktualisierungen nicht ausgelöst. Wenn eine unserer Klassen Feature-verknüpfte Annotation hätte, würde diese Annotation ebenfalls während dieses Ereignisses nicht geändert werden.
Abbildung 2 Update Subnetwork im Standardmodus ohne Eventing
Vergleichen wir dies nun damit, wie sich das System verhalten würde, wenn wir dieselbe Aktion ausführen würden, aber mit dem Bearbeitungsmodus aufmit Eventing.
Aktualisierung mit Eventing im Standardmodus
Wenn das Utility Network so konfiguriert ist, dass es ein Subnetzwerk mit Eventing aktualisiert, bedeutet dies, dass alle Geodatabase-Verhaltensweisen ausgelöst werden, wenn Update Subnetwork die Attribute eines Features aktualisiert. Wenn das vorherige Beispiel mit Eventing ausgeführt worden wäre, sähen die Ergebnisse wie im folgenden Diagramm aus.
Abbildung 3 Update Subnetwork im Standardmodus mit Eventing
Sie sehen also neben dem Ausfüllen des Feldes für den Subnetzwerknamen auch eine Aktualisierung des Feldes „Zuletzt geändert“ durch Editor Tracking sowie eine Aktualisierung des Feldes „Betriebsbereich“ durch unsere Attributregel. Zusätzlich würden Feature-verknüpfte Annotationen aktualisiert werden, falls sie eines oder mehrere dieser Felder referenzieren würden.
Allerdings gehen all diese zusätzlichen Auslöser und Aktualisierungen auf Kosten der Leistung. Wenn Sie viele Attributregeln und/oder Feature-verknüpfte Annotationsklassen haben, sollten Sie sorgfältig über die Auswirkungen auf Ihr System nachdenken.
Aktualisierung ohne Eventing in einer benannten Version
Die interessanteste Situation ist zu betrachten, wie sich Update Subnetwork verhält, wenn es in einer benannten Version ohne Eventing ausgeführt wird. Dies ist das Standardverhalten des Systems, da es am leistungsfähigsten ist.Wenn Update Subnetwork in einer Version ohne Eventing ausgeführt wird, hat dies den Nachteil, dass es keine Informationen zum Subnetzwerk bei Features aktualisieren kann, die in dieser Version noch nicht bearbeitet wurden.Wenn Ihnen dieses Verhalten in diesen Beispielen nicht gefällt, denken Sie daran: Wir haben eine neue Option eingeführt, um diese Einschränkungen zu überwinden (siehe nächsten Abschnitt: Aktualisierung mit Eventing in einer benannten Version).
Um dieses Thema vollständig zu diskutieren betrachten wir zwei separate Beispiele dafür, wann das Ausführen von Update Subnetwork in einer Version unerwartete Ergebnisse liefern kann. Es ist erwähnenswert, dass auch wenn das Werkzeug unter allen Bedingungen in einer Version möglicherweise nicht erwartungsgemäße Ergebnisse liefert – es liefert korrekte Ergebnisse sobald die Version zur Standardversion gepostet wurde und Update Subnetwork im Standardmodus ausgeführt wird.
Neu erstellte Features
Unser erstes Beispiel baut auf unserem vorherigen Beispiel auf. Angenommen wir haben eine Datenbank ohne ausgefüllte Informationen zum Subnetzwerk und bevor wir Update Subnetwork im Standardmodus ausführen entscheiden wir uns dazu eine neue benannte Version zu erstellen und einen neuen Dienst in dieser Version hinzuzufügen. Hier sehen Sie eine Grafik unserer neu erstellten Features in unserer Version vor dem Ausführen von Update Subnetwork:
Abbildung 4 Neue Features erstellt in einer benannten Version
Nach dem Ausführen von Update Subnetwork ohne Eventing in der benannten Version fällt etwas Merkwürdiges auf.Nur die Features, die in dieser Version erstellt wurden erhalten ihren Subnetzwerknamen ausgefüllt.
Abbildung 5 Aktualisierung neuer Features in einer benannten Version ohne Eventing
Wenn Update Subnetwork ohne Eventing in einer benannten Version ausgeführt wird kann es nur Features aktualisieren die in dieser Version erstellt oder bearbeitet wurden.
. Da diese Features in diesem Versions-Update nicht bearbeitet wurden, kann das Subnetzwerk sie nicht bearbeiten, ohne Bearbeitungsereignisse auszulösen.
Beide Beispiele verdeutlichen die Einschränkungen beim Aktualisieren von Subnetzwerken in benannten Versionen ohne Ereignisverarbeitung. Für viele Kunden sind diese Einschränkungen akzeptabel aufgrund der Leistungsverbesserungen dieses Bearbeitungsmodus und weil die Daten korrekt angezeigt werden, sobald die Daten in default gepostet wurden und update subnetwork ausgeführt wird, wo jeder die Ergebnisse sehen kann. Andere Kunden waren jedoch bereit, in Kauf zu nehmen, dass update subnetwork länger läuft, um bestimmte Geschäftsanforderungen zu erfüllen. Deshalb haben wir die Möglichkeit eingeführt, update subnetwork mit eventing durchzuführen, wie wir im nächsten Abschnitt besprechen werden.
Aktualisierung mit eventing in einer benannten Version
Lassen Sie uns die beiden oben genannten Szenarien erneut betrachten und sehen, wie sie sich verhalten, wenn das Subnetzwerk in einer benannten Version aktualisiert wird, wenn der Tier so konfiguriert ist, dass ein Bearbeitungsmodus mit eventing verwendet wird.
Neu erstellte Features
Unten sehen wir das erste Beispiel, bei dem eine Mischung aus bestehenden und neuen Features aktualisiert werden muss.
Abbildung 9 Neue Features in einer Version
Und das Folgende ist das Ergebnis nach Ausführung von update subnetwork mit eventing.
Abbildung 10 Update subnetwork mit eventing in benannter Version
Wie Sie sehen können, haben alle Features den korrekten Subnetzwerknamen und Betriebsbereich. Das Netzwerk benötigt länger zur Verarbeitung, da mehr Features bearbeitet werden und jedes Feature zusätzliche Bearbeitungen für Editor-Tracking, Attributregeln usw. auslöst.
Bestehende Features
Als nächstes betrachten wir das zweite Beispiel, bei dem wir mehrere Subnetzwerke neu konfiguriert haben. Unten sind die Daten vor Ausführung von update subnetwork dargestellt.
Abbildung 11 Features in einer Version vor der Aktualisierung des Subnetzwerks
Und unten ist der Status der Features nach Ausführung von update subnetwork in einer benannten Version mit eventing.
Abbildung 12 Neue Features in einer Version
Erneut können Sie sehen, dass alle Attribute des Features die korrekten Werte haben. Es sei erwähnt, dass dies länger dauert als dieselbe Operation ohne eventing durchzuführen. Die benötigte Zeit hängt direkt von der Anzahl/Komplexität der Attributregeln ab, die Sie auf Ihren Features konfiguriert haben, sowie von der Anzahl der Beziehungen mit aktivierter Nachrichtenübermittlung (einschließlich feature-linked annotation). Es ist ratsam, diese Leistungskosten im Verhältnis zur Bedeutung der visuellen Inspektion/Attributüberprüfung von Netzwerkinformationen während Ihres Qualitätssicherungsprozesses zu messen und zu berücksichtigen.
Konfiguration
Nachdem Sie nun gesehen haben, wie diese Verhaltensweisen funktionieren, schauen wir uns an, wie sie in einem utility network konfiguriert werden. Diese Optionen werden mit dem Werkzeug Set Subnetwork Definition konfiguriert. Da dieses Werkzeug Ihnen erlaubt, die Konfiguration für einen bestimmten Tier in Ihrem Netzwerk zu ändern, bedeutet dies, dass Sie unterschiedliche Verhaltensweisen für jeden Tier definieren können (z.B. System und Pressure). Obwohl es schön ist, die Option zu haben, unterschiedliche Verhaltensweisen für jeden Tier zu definieren, bevorzugen die meisten Kunden, dass alle ihre Tiers gleich funktionieren, um konsistente Bearbeitungsabläufe für Editoren sicherzustellen.
Beim Festlegen des Bearbeitungsmodus für Ihre Subnetwerkdefinition gibt es zwei verschiedene Felder mit jeweils zwei Optionen. Das bedeutet, dass es vier Kombinationen von Werten gibt, die Sie für Ihre Bearbeitungsmodi konfigurieren können:
- Ohne eventing in default, ohne eventing in benannten Versionen (Standard)
- Ohne eventing in default, mit eventing in benannten Versionen
- Mit eventing in default, mit eventing in benannten Versionen
- Mit eventing in default, ohne eventing in benannten Versionen
Bevor Sie zu viel Zeit damit verbringen herauszufinden, welche dieser vier Optionen Sie auswählen sollten: Die utility network Foundation-Datenmodelle von Esri haben ihre Bearbeitungsmodi bereits konfiguriert. Jedes dieser Datenmodelle hat eine empfohlene Konfiguration entwickelt von Branchenexperten zusammen mit ihrer Community, um eine Konfiguration bereitzustellen, die für den breitesten Satz von Workflows dieser Branche geeignet ist.
Obwohl diese Konfigurationen den Bedürfnissen der meisten Kunden entsprechen, ist es immer eine gute Idee, diese Konfigurationen im Kontext Ihrer Geschäftsanforderungen und aller Änderungen an Konfiguration/Datenmodell zu überprüfen, um sicherzustellen, dass die typische Konfiguration weiterhin am besten geeignet ist.
Best Practices
Die häufigste Frage lautet: Was ist die beste Praxis zur Konfiguration Ihres Bearbeitungsmodus im utility network? Es gibt keine einzige Antwort darauf, die für alle Kunden gilt. Es gibt jedoch mehrere Kriterien zu berücksichtigen, die Ihnen helfen können zu entscheiden, welche Option am besten geeignet ist. Diese Überlegungen fallen typischerweise in drei Kategorien: Workflow, Annotation und Attributregeln.
Die erste Überlegung ist Ihr versioned editing workflow. Wenn Ihr Bearbeitungsworkflow erfordert, dass Sie Qualitätssicherung in benannten Versionen durchführen und dieser Prozess Werkzeuge oder Layer umfasst, die auf den Attributen basieren (Subnetzwerkname, propagierte Werte usw.), dann sollten Sie Ihren Bearbeitungsmodus für benannte Versionen auf „With Eventing“ setzen. Dies stellt sicher, dass die Subnetzwerkfelder immer korrekt für alle Features in Ihrer Version gefüllt sind und für Qualitätssicherung verwendet werden können. Wenn Ihr QA-Prozess vollständig in default durchgeführt werden kann oder Tracing anstelle von Feature-Attributen verwendet wird, können Sie den Bearbeitungsmodus für benannte Versionen auf „Without Eventing“ setzen.
Die zweite Überlegung ist ob Sie feature-linked annotation haben. Wenn Sie keine feature-linked annotation oder Annotationsausdrücke haben, die keine Informationen aus dem Subnetzwerk enthalten (Subnetzwerkname, propagierte Werte usw.), dann ist jede Bearbeitungsmodusoption für Sie geeignet. Beziehungsklassen mit aktivierter Nachrichtenübermittlung wie feature-linked annotation Klassen verursachen Leistungskosten bei der Bearbeitung und müssen sorgfältig überwacht werden. Noch wichtiger ist jedoch: Wenn Ihre feature-linked annotation Informationen über das Subnetzwerk enthält, müssen Sie Entscheidungen treffen. Das Speichern von Subnetzwerkinformationen in Annotationsklassen gilt nicht als Best Practice wegen der statischen Natur von Annotationen und der dynamischen Natur von Subnetzwerken sowie der Leistungskosten zur Synchronisation beider. Sie sollten erwägen diese feature-linked annotation Features durch Labels zu ersetzen. Wenn dies jedoch eine harte Anforderung ist, müssen Sie Ihren Bearbeitungsmodus sowohl für benannte Versionen als auch default auf „With Eventing“ setzen um sicherzustellen, dass Text in Ihrer Annotation aktualisiert wird wenn update subnetwork ausgeführt wird; seien Sie sich jedoch bewusst dass dies die Leistung von update subnetwork beeinträchtigt.
Die dritte Überlegung sind die Attributregeln , die Sie auf Ihren utility network Features definiert haben. Jede Attributregel konfiguriert zum Auslösen bei Aktualisierung wird ausgewertet wann immer dieses Feature aktualisiert wird – unabhängig davon welches Feld betroffen ist. Das bedeutet: Wenn Sie den Bearbeitungsmodus mit eventing verwenden wird jede sofortige Berechnungsregel während update subnetwork auf allen aktualisierten Features ausgelöst. Wenn dies eine harte Anforderung ist und Sie bereit sind den Leistungseinbruch hinzunehmen sollten Sie Ihre Attributregeln überprüfen um sicherzustellen dass sie eine frühzeitige Beendigung während update subnetwork implementieren um diesen Leistungseinbruch zu minimieren. Wenn Ihre Attributregeln darauf angewiesen sind auf Änderungen an Subnetzwerkfeldern zu reagieren sollten Sie wissen dass dies nicht als Best Practice gilt. Wenn dies jedoch eine harte Anforderung ist müssen Sie Ihren Bearbeitungsmodus auf „With Eventing“ setzen um sicherzustellen dass die Attributregel während update subnetwork ausgelöst wird.
Mit diesen Überlegungen wollen wir nun die vier Optionen überprüfen und sehen wo sie am besten geeignet sind.
Ohne eventing in default und ohne eventing in benannten Versionen. Diese Option ist das Standardverhalten des Systems. Es bietet Ihnen die beste Leistung hat aber Einschränkungen beim Aktualisieren von Features in Versionen und feature-linked annotation.
Ohne eventing in default und mit eventinga0in benannten Versionen. Diese Option bietet einen Kompromiss zwischen Leistung und Funktionalität. Es bietet Ihnen beste Leistung beim Aktualisieren des Subnetzwerks in default und das beste Qualitätssicherungserlebnis in einer benannten Version.
Mit eventing in default und mit eventing in benannten Versionen. Diese Option bietet die meiste Funktionalität hat aber auch den höchsten Leistungsverlust. Wenn Sie diese Konfiguration implementieren sollten Sie alle Attributregeln überprüfen die beim Ändern von Features ausgeführt werden um sicherzustellen dass sie so konfiguriert sind dass sie während update subnetwork frühzeitig beendet werden können.
Mit eventing in default und ohne eventing in benannten Versionen. Dies ist die am wenigsten verbreitete Konfiguration. Für Kunden gedacht die Annotation oder Attributregeln benötigen welche im default ausgeführt werden müssen aber nicht in Versionen.
Fazit
Nachdem Sie diesen Artikel gelesen haben sollten Sie nun Vor- und Nachteile der verschiedenen Bearbeitungsmodi für das Subnetzwerkmanagement verstehen und bestimmen können welche Modi für Ihr Datenmodell Ihre Bearbeitungsworkflows und Geschäftsanforderungen geeignet sind.
Wenn Sie lernen möchten wie man Leistungseinbußen durch Bearbeitungsereignisse bei Attributregeln mindert lesen Sie den Artikel Attribute Rule Triggering Fields.
Wenn Sie mehr über Subnetzwerkmanagement erfahren oder praktische Tutorials ausprobieren möchten finden Sie branchenspezifische Beispiele in der Lernreihe Getting Started with ArcGIS Utility Network.
Wenn Sie detailliertere Informationen und tiefere Einblicke zu den Fähigkeiten des Subnetzwerkmanagements im utility network wünschen empfehle ich Ihnen einige weitere technische Artikel auf der ArcGIS Utility Network Esri Community-Seite anzusehen.
