Aktualisierung: ArcGIS Pro 3.4/ArcGIS Enterprise 11.4 hat eingeführt Auslösende Felder was die Diskussion über die Minderung der Auswirkungen von Bearbeitungen mit Events beeinflusst.
Die Verwaltung von Subnetzen kann oft Hunderte oder Tausende von Bearbeitungen an Features erfordern, wenn ein Subnetz erstellt oder neu konfiguriert wird. Aus diesem Grund bietet das System verschiedene Bearbeitungsmodi, die für diese Aktualisierungen verwendet werden können. Weitere Informationen zu diesem Thema finden Sie im Subnetworks Thema in der Online-Hilfe.
Wenn Sie diesen Artikel lesen, verstehen Sie die Auswirkungen dieser Einstellung auf die Leistung von Update Subnetwork und warum Sie bei bestimmten Arbeitsabläufen Eventing aktivieren möchten, obwohl dies die Leistung beeinträchtigen kann.
Was ist ein Bearbeitungsmodus?
Was ist ein Bearbeitungsmodus? Im ArcGIS Utility Network bezeichnet der Bearbeitungsmodus die Art und Weise, wie die Software Systemfelder bei Features verwaltet, wenn Subnetze verwaltet werden. Derzeit gibt es zwei Optionen für Bearbeitungsmodi, mit Eventing oder ohne Eventing.
Worauf beziehen wir uns mit „Eventing“, wenn wir sagen, dass wir Daten mit Eventing oder ohne Eventing verwalten? Mit Eventing meinen wir speziell 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 sind das Ausfüllen von Editor-Tracking-Feldern, das Auslösen von Attributregeln, das Übermitteln von Änderungen an verwandte Objekte und das Aktualisieren von feature-gebundener Beschriftung.
Was hat das mit den Subnetzen zu tun? Eines der Werkzeuge, das Benutzer häufig im Rahmen ihres Bearbeitungs-Workflows ausführen, ist das Update Subnetwork-Werkzeug. Dieses Werkzeug ist verantwortlich für die Verwaltung der Systemfelder bei Utility Network-Features, die das Subnetz beschreiben, an dem sie teilnehmen. Wenn jedes dieser Features bearbeitet wird, löst es verschiedene 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 verlängern den Update Subnetwork-Prozess.
Um diese Situation zu bewältigen, 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 Subnetzen 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 mildern.
Schauen wir uns nun einige Beispiele für verschiedene Konfigurationen an. In jedem Beispiel betrachten wir, wie eine Gruppe von Features unter bestimmten Bedingungen reagiert. Jedes Feature ist mit 4 Feldern beschriftet; wenn ein Wert geändert wird, erscheint das Feld/Wert fett gedruckt:
- Asset ID – Dies ist eine eindeutige Kennung für jedes Feature. Sie wird beim Erstellen des Features ausgefüllt.
- Datum der Änderung – Dies ist das Editor-Tracking-Feld, das von der Geodatabase gepflegt wird.
- Subnetzname – Dies ist das vom Utility Network gepflegte Feld für den Subnetz-Namen.
- Netzwerkregion – Dieses Feld wird durch eine Attributregel gepflegt, die den Subnetz-Namen des Features verwendet, um einen 'Region'-Wert aus einer Nachschlagetabelle abzurufen.
Hinweis: Wenn keine der Attributregeln Informationen aus dem Subnetz benötigt haben, können alle Attributregeln so konfiguriert werden, dass sie bei Aktualisierungen während des Update Subnetwork nicht ausgelöst werden, um Leistungseinbußen durch Attributregeln während des Update Subnetwork zu vermeiden.
Aktualisierung ohne Eventing im Standardmodus
Das erste Beispiel zeigt 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 Subnetzname-Felder in der Datenbank den Wert ‚Unbekannt‘ und die übrigen Felder 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 Subnetz-Namen bei allen Features im Subnetz aktualisiert wurde; Editor Tracking und Attributregeln wurden jedoch bei diesen Aktualisierungen nicht ausgelöst. Wenn eine unserer Klassen feature-gebundene Beschriftungen hätte, würden diese ebenfalls nicht während dieses Ereignisses geändert werden.
Abbildung 2 Update Subnetwork im Standard ohne Eventing
Vergleichen wir dies nun damit, wie sich das System verhalten würde, wenn wir dieselbe Aktion mit dem Bearbeitungsmodus mit Eventing durchführen würden.
Aktualisierung mit Eventing im Standardmodus
Wenn das Utility Network so konfiguriert ist, dass ein Subnetz mit Eventing aktualisiert wird, bedeutet dies, dass alle Geodatabase-Verhaltensweisen ausgelöst werden, wenn Update Subnetwork Attribute eines Features aktualisiert. Wenn das vorherige Beispiel mit Eventing ausgeführt worden wäre, sähen die Ergebnisse wie in der folgenden Abbildung aus.
Abbildung 3 Update Subnetwork im Standard mit Eventing
Sie sehen also neben dem Ausfüllen des Feldes für den Subnetz-Namen auch eine Aktualisierung des Feldes „Zuletzt geändert“ durch Editor Tracking sowie eine Aktualisierung des Feldes „Betriebsbereich“ durch unsere Attributregel. Außerdem würden feature-gebundene Beschriftungen aktualisiert werden, falls sie eines oder mehrere dieser Felder referenzieren.
All diese zusätzlichen Auslöser und Aktualisierungen gehen jedoch zulasten der Leistung. Wenn Sie viele Attributregeln und/oder feature-gebundene Beschriftungsklassen 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 ohne Eventing in einer benannten Version ausgeführt wird. Dies ist das Standardverhalten des Systems, da es am leistungsfähigsten ist.Wenn Update Subnetwork ohne Eventing in einer Version ausgeführt wird, hat dies den Nachteil, dass es keine Informationen zum Subnetz auf 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 behandeln, betrachten wir zwei separate Beispiele dafür, wann das Ausführen von Update Subnetwork in einer Version unerwartete Ergebnisse liefern kann. Es sei darauf hingewiesen, dass auch wenn das Werkzeug unter allen Bedingungen in einer Version möglicherweise nicht erwartungsgemäß funktioniert – sobald die Version jedoch zur Standardversion gepostet wurde und Update Subnetwork im Standard ausgeführt wird – korrekte Ergebnisse erzielt werden.
Neu erstellte Features
Unser erstes Beispiel baut auf dem vorherigen auf. Angenommen wir haben eine Datenbank ohne gefüllte Subnetzinformationen und bevor wir Update Subnetwork im Standard 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 Subnetz-Namen gefü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. Das liegt daran, dass wenn ein Feature noch nicht in der Version geändert wurde ein Geodatabase-Ereignis ausgelöst werden müsste um die Bearbeitung einzufügen.
Bestehende Features
Im nächsten Beispiel betrachten wir ein weiteres praktisches Beispiel dafür wie Update Subnetwork ohne Eventing in einer benannten Version unerwartete Ergebnisse liefern kann. Hier schauen wir uns an wie Update Subnetwork auf eine Änderung reagiert bei der Features von einem zu einem anderen Subnetz wechseln.
Wir beginnen mit zwei Subnetzen (Netzwerk A und Netzwerk 
, getrennt durch ein Verbindungselement (offener Schalter, geschlossene Armatur usw.). Alle Subnetze wurden bereits in der Standardversion aktualisiert sodass alle Attribute korrekt gefüllt sind. Beachten Sie: Da ein Verbindungselement mehreren Subnetzen angehört ist das Feld für den Subnetz-Namen durch Semikolons getrennt.
Abbildung 6 Zwei Subnetze im Standard
In diesem Beispiel ändern wir das Verbindungselement zwischen den beiden Subnetzen von Gerät 3 zu Gerät 1. Dies passiert häufig im realen Leben wenn Schaltkreise oder Druckzonen neu konfiguriert werden um langfristige oder saisonale Änderungen bei der Kundennachfrage zu berücksichtigen. Dazu ändern wir den Status dieser beiden Geräte um ihren neuen offen/geschlossen Zustand anzuzeigen sodass Gerät 1 jetzt ein Verbindungselement ist und Gerät 3 nicht mehr als Barriere fungiert.
Abbildung 7 Aktualisiertes Verbindungselement
Diese Änderungen sehen Sie auch im obigen Diagramm reflektiert: Der Indikator für das Verbindungselement hat sich von Gerät 3 zu Gerät 1 verschoben; das Datum der letzten Änderung wurde aktualisiert; außerdem haben wir die Farbgebung der Features angepasst um visuell anzuzeigen welchem Subnetz sie angehören falls man jedes einzelne nachverfolgt. Die Namen der Subnetze zeigen noch ihre alten Werte weil wir noch kein Update Subnetwork ausgeführt haben. Unten sehen Sie ein Diagramm aller Attributänderungen die auftreten wenn unter diesen Bedingungen Update Subnetwork ausgeführt wird.
Abbildung 8 Aktualisiertes Subnetz in benannter Version
Wie erwartet sehen wir dass das Feld für den Namen des Subnetzes bei beiden Geräten aktualisiert wurde welche wir in dieser Version bearbeitet haben.Die Features welche zuvor mit Netzwerk A verbunden waren aber jetzt mit Netzwerk B verbunden sind zeigen jedoch weiterhin alte Werte für den Namen des Subnetzes und den Betriebsbereich an. Da diese Features nicht in dieser Version bearbeitet wurden kann Update Subnetwork sie nicht bearbeiten ohne Bearbeitungsevents auszulösen.
Beide Beispiele verdeutlichen die Einschränkungen beim Aktualisieren von Subnetzen in benannten Versionen ohne Eventing. Für viele Kunden sind diese Einschränkungen akzeptabel, da dieser Bearbeitungsmodus Leistungsverbesserungen bietet und die Daten korrekt angezeigt werden, sobald die Daten in default gepostet und das Update Subnetwork ausgeführt wurde, sodass jeder die Ergebnisse sehen kann. Andere Kunden waren jedoch bereit, eine längere Laufzeit des Update Subnetwork in Kauf zu nehmen, um bestimmte Geschäftsanforderungen zu erfüllen. Aus diesem Grund haben wir die Möglichkeit eingeführt, das Update Subnetwork mit Eventing durchzuführen.mit Eventing wie wir im nächsten Abschnitt besprechen werden.
Update mit Eventing in einer benannten Version
Lassen Sie uns die beiden oben genannten Szenarien erneut betrachten und sehen, wie sie sich verhalten, wenn das Subnetz in einer benannten Version aktualisiert wird, bei der 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 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 Subnetz-Namen und Betriebsbereich. Die Verarbeitung des Netzwerks dauert länger, da mehr Features bearbeitet werden und jedes Feature zusätzliche Bearbeitungen auslöst, um Editor-Tracking, Attributregeln usw. zu handhaben.
Bestehende Features
Als Nächstes betrachten wir das zweite Beispiel, bei dem wir mehrere Subnetze neu konfiguriert haben. Unten sind die Daten vor der Ausführung von Update Subnetwork dargestellt.
Abbildung 11 Features in einer Version vor dem Aktualisieren des Subnetzes
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 sehen Sie, 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 für Ihre Features konfiguriert haben, sowie von der Anzahl der Beziehungen mit aktiviertem Messaging (einschließlich feature-linked annotation). Es lohnt sich, diese Leistungskosten im Verhältnis zur Bedeutung der visuellen Inspektion/Attributüberprüfung der Netzwerkinformationen während Ihres Qualitätssicherungsprozesses abzuwägen.
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, können Sie unterschiedliche Verhaltensweisen für jeden Tier definieren (z.B. System und Pressure). Obwohl es schön ist, verschiedene Verhaltensweisen für jeden Tier zu haben, bevorzugen die meisten Kunden einheitliche Verhaltensweisen für alle ihre Tiers, um konsistente Bearbeitungsabläufe für Editoren sicherzustellen.
Beim Festlegen des Bearbeitungsmodus für Ihre Subnetzdefinition gibt es zwei verschiedene Felder mit jeweils zwei Optionen. Das bedeutet, dass Sie vier Kombinationen von Werten 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 wählen sollten: Die von Esri bereitgestellten Utility Network Foundation-Datenmodelle haben ihre Bearbeitungsmodi bereits konfiguriert. Jedes dieser Datenmodelle enthält eine empfohlene Konfiguration, die von Branchenexperten zusammen mit ihrer Community entwickelt wurde und auf die breiteste Palette von Workflows dieser Branche zugeschnitten ist.
Obwohl diese Konfigurationen den Bedürfnissen der meisten Kunden entsprechen, ist es immer ratsam, diese Konfigurationen im Kontext Ihrer Geschäftsanforderungen und aller Änderungen an Konfiguration oder 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 allgemeingültige Antwort für alle Kunden. Allerdings gibt es mehrere Kriterien zur Überlegung, 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 versionierter Bearbeitungsworkflow. Wenn Ihr Bearbeitungsworkflow erfordert, dass Sie Qualitätssicherung in benannten Versionen durchführen und dieser Prozess Werkzeuge oder Layer umfasst, die auf den Attributen der Features basieren (Subnetzname, propagierte Werte usw.), dann sollten Sie den Bearbeitungsmodus für benannte Versionen auf „Mit Eventing“ setzen. Dies stellt sicher, dass die Subnetzfelder für alle Features in Ihrer Version immer korrekt gefüllt sind und für die 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 „Ohne Eventing“ setzen.
Die zweite Überlegung ist, ob Sie feature-linked annotation verwenden. Wenn Sie keine feature-linked annotation oder Annotationsausdrücke haben, die keine Informationen aus dem Subnetz enthalten (Subnetzname, propagierte Werte usw.), dann ist jede Bearbeitungsmodus-Option für Sie geeignet. Beziehungsklassen mit aktiviertem Messaging wie feature-linked annotation Klassen verursachen Leistungseinbußen bei der Bearbeitung, die sorgfältig überwacht werden müssen. Noch wichtiger ist jedoch: Wenn Ihre feature-linked annotation Informationen über das Subnetz enthält, müssen Sie Entscheidungen treffen. Das Speichern von Subnetzinformationen in Annotationsklassen gilt nicht als Best Practice wegen der statischen Natur von Annotationen und der dynamischen Natur von Subnetzen sowie wegen der Leistungskosten zur Synchronisierung beider. Sie sollten erwägen, diese feature-linked annotation durch Labels zu ersetzen. Wenn dies jedoch eine zwingende Anforderung ist, müssen Sie den Bearbeitungsmodus sowohl für benannte Versionen als auch default auf „Mit Eventing“ setzen, um sicherzustellen, dass Text in Ihrer Annotation aktualisiert wird beim Ausführen von Update Subnetwork – seien Sie sich aber bewusst, dass dies die Leistung beeinträchtigt.
Die dritte Überlegung betrifft die Attributregeln , die Sie auf Ihren Utility Network-Features definiert haben. Jede Attributregel mit Trigger 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, werden alle sofortigen Berechnungsregeln während Update Subnetwork auf allen aktualisierten Features ausgelöst. Wenn dies eine zwingende Anforderung ist und Sie bereit sind den Leistungseinbruch zu akzeptieren, sollten Sie Ihre Attributregeln überprüfen und sicherstellen, dass sie eine frühzeitige Beendigung während Update Subnetwork unterstützen um diesen Leistungseinbruch zu minimieren. Wenn Ihre Attributregeln darauf angewiesen sind auf Änderungen an Subnetzfeldern zu reagieren – was nicht als Best Practice gilt – müssen Sie dennoch den Bearbeitungsmodus auf „Mit Eventing“ setzen um sicherzustellen dass die Attributregel während Update Subnetwork ausgelöst wird.
Mit diesen Überlegungen im Hinterkopf betrachten wir nun die vier Optionen und wo sie am besten geeignet sind.
Ohne Eventing in default und ohne Eventing in benannten Versionen. Diese Option ist das Standardverhalten des Systems. Sie bietet die beste Leistung hat aber Einschränkungen beim Aktualisieren von Features in Versionen und bei feature-linked annotation.
Ohne Eventing in default und mit Eventing in benannten Versionen. Diese Option bietet einen Kompromiss zwischen Leistung und Funktionalität. Sie liefert beste Leistung beim Aktualisieren des Subnetzes in default und das beste Qualitätssicherungserlebnis in einer benannten Version.
Mit Eventing in default und mit Eventing in benannten Versionen. Diese Option bietet den größten Funktionsumfang hat aber auch die höchsten Leistungskosten. Wenn Sie diese Konfiguration implementieren sollten Sie alle Attributregeln überprüfen die beim Ändern von Features ausgeführt werden um sicherzustellen dass sie eine frühzeitige Beendigung während Update Subnetwork unterstützen.
Mit Eventing in default und ohne Eventing in benannten Versionen. Dies ist die am wenigsten verbreitete Konfiguration. Sie richtet sich an Kunden mit Annotation oder Attributregeln die sie nur im default ausführen müssen aber nicht in Versionen.
Fazit
Nachdem Sie diesen Artikel gelesen haben sollten Sie die Vor- und Nachteile der verschiedenen Bearbeitungsmodi für das Management von Subnetzen verstehen und bestimmen können welche Modi für Ihr Datenmodell Ihre Workflows und Geschäftsanforderungen geeignet sind.
Wenn Sie lernen möchten wie man Leistungseinbußen durch Editing Events auf Attributregeln mindert lesen Sie den Artikel Attribute Rule Triggering Fields.
Wenn Sie mehr über das Management von Subnetzen erfahren oder praktische Tutorials ausprobieren möchten finden Sie branchenspezifische Beispiele in der Lernreihe Getting Started with ArcGIS Utility Network.
Für detailliertere Informationen und tiefere Einblicke zu den Fähigkeiten des Managements von Subnetzen im Utility Network empfehle ich Ihnen weitere technische Artikel auf der Esri Community-Seite ArcGIS Utility Network.
