Aktualizace: ArcGIS Pro 3.4/ArcGIS Enterprise 11.4 zavedly Spouštěcí pole což ovlivňuje diskusi o zmírnění dopadů úprav pomocí událostí.
Vítejte v sérii porozumění správě podsítí, kde se podrobně zabýváme některými pokročilejšími tématy správy podsítí. Pokud neznáte, co jsou podsítě nebo jak fungují, doporučuji přečíst si články a návody v Řízení podsítí pomocí ArcGIS Utility Network učební sérii pro začátek.
Správa podsítí často zahrnuje stovky nebo tisíce úprav prvků při vytváření nebo přeconfigurování podsítě. Proto systém poskytuje několik různých režimů úprav, které lze použít k provedení těchto aktualizací.
Přečtením tohoto článku pochopíte dopad tohoto nastavení na výkon aktualizace podsítě a proč byste pro určité pracovní postupy mohli chtít povolit eventing, i když to ovlivní výkon.
Co je režim úprav?
Co je režim úprav? V ArcGIS Utility Network režim úprav označuje způsob, jakým software spravuje systémová pole u prvků při správě podsítí. V současnosti jsou k dispozici dvě možnosti režimů úprav, s eventingem nebo bez eventingu.Co znamená „eventing“, když říkáme, že spravujeme data s eventingem
nebo bez eventingu? Když mluvíme o eventingu, máme na mysli konkrétně geodatabázové události, které jsou vyvolány v reakci na úpravy. Geodatabázové události jsou jedním ze způsobů, jak ArcGIS spouští speciální chování při úpravách objektů v geodatabázi. Běžné příklady zahrnují chování jako vyplňování polí sledování editorů, spouštění pravidel atributů, zasílání zpráv o změnách souvisejících objektů a aktualizaci anotací propojených s prvky.Co to má společného s podsítěmi? Jedním z nástrojů, které uživatelé běžně používají jako součást svého pracovního postupu úprav, je nástroj aktualizace podsítě
. Tento nástroj je zodpovědný za správu systémových polí u prvků utility network, která popisují podsíť, ve které se účastní. Při každé úpravě těchto prvků se spustí různé editační události. Datové modely obsahující vztahy nebo pravidla atributů vyvolají během aktualizace podsítě více událostí než datové modely s méně vztahy a pravidly atributů. Všechny tyto události, pravidla a vztahy přidávají další čas k procesu aktualizace podsítě.Aby tuto situaci řešili, mohou administrátoři nakonfigurovat vrstvy ve své síti tak, aby používaly režim úprav buď s běžnými geodatabázovými událostmi (s eventingem
), nebo obcházely běžný model geodatabázových událostí (bez eventingu) při správě podsítí v dané vrstvě. Na konci tohoto článku je krátká diskuse o tom, jak vyhodnotit obchodní požadavky a nejlepší postupy pro rozhodnutí. Kromě toho můžete také použít spouštěcí pole k přesné kontrole toho, na které úpravy pravidla atributů reagují, abyste zmírnili dopady editačních událostí během aktualizace podsítě.Ale nyní se podíváme na několik příkladů různých konfigurací. V každém příkladu budeme sledovat, jak sada prvků reaguje za určitých podmínek. Každý prvek je označen 4 poli a když je hodnota upravena, pole/hodnota se zobrazí tučně:ID aktiva – Jedinečný identifikátor každého prvku. Je vyplněn při vytvoření prvku.
Datum změny – Toto je pole sledování editoru spravované geodatabází.
- Název podsítě – Toto je pole názvu podsítě spravované utility network.
- Region sítě – Toto pole spravuje pravidlo atributu, které používá název podsítě prvku k získání hodnoty 'region' z tabulky vyhledávání.
- Poznámka: Pokud žádná z pravidel atributů nevyžadovala použití informací z podsítě, pak lze všechna pravidla atributů nakonfigurovat tak, aby se nespouštěla při aktualizacích provedených během aktualizace podsítě za účelem zmírnění dopadu na výkon způsobeného pravidly atributů.
- Aktualizace bez eventingu ve výchozím nastavení
První příklad se týká něčeho, co každý projekt dělá alespoň jednou. Spuštění aktualizace podsítě ve výchozí verzi v zcela nové databázi. V tomto případě mají všechna pole názvu podsítě v databázi hodnotu „Neznámý“ a ostatní pole mají své počáteční hodnoty z načtení dat. Příklad tohoto stavu vidíte na obrázku níže.
Obrázek 1 Počáteční stav databáze
Po spuštění aktualizace podsítě na Síti A vidíme, že pole názvu podsítě bylo aktualizováno u všech prvků v podsíti, ale sledování editoru a pravidla atributů nebyla během těchto aktualizací spuštěna. Pokud by některé naše třídy měly anotace propojené s prvky, anotace by také nebyla během této události upravena.
Obrázek 2 Aktualizace podsítě ve výchozím nastavení bez eventingu
Nyní porovnejme toto s tím, jak by systém fungoval, kdybychom provedli stejnou akci s režimem úprav nastaveným na
s eventingem
.Aktualizace s eventingem ve výchozím nastaveníKdyž je utility network nakonfigurována tak, aby aktualizovala podsíť s eventingem, znamená to, že všechny chování geodatabáze budou spuštěny při aktualizaci atributů prvku nástrojem update subnetwork. Kdyby byl předchozí příklad spuštěn
s eventingem
, výsledky by vypadaly jako na diagramu níže.Obrázek 3 Aktualizace podsítě ve výchozím nastavení s eventingemVidíte, že kromě vyplnění pole názvu podsítě bylo také aktualizováno pole Poslední změna sledováním editoru a pole Provozní oblast bylo aktualizováno naším pravidlem atributu. Kromě toho by byly aktualizovány i anotace propojené s prvky odkazujícími na jedno nebo více těchto polí.
Nicméně všechny tyto další spouštěče a aktualizace mají vliv na výkon. Pokud tedy máte mnoho pravidel atributů a/nebo tříd anotací propojených s prvky, měli byste pečlivě zvážit dopad na váš systém.
Aktualizace bez eventingu v pojmenované verzi
Nejzajímavější situací je podívat se na to, jak update subnetwork funguje při spuštění v pojmenované verzi bez eventingu. To je výchozí chování systému protože je nejvýkonnější.
Když je update subnetwork spuštěn v verzi bez eventingu, má to nevýhodu v tom, že nemůže aktualizovat informace o podsíti u prvků, které ještě nebyly upraveny v této verzi
. Pokud se vám nelíbí chování viděné v těchto příkladech, pamatujte že jsme představili novou možnost k překonání těchto omezení diskutovanou v následující části (Aktualizace s eventingem v pojmenované verzi).Abychom tuto problematiku plně probrali, zvážíme dva samostatné příklady situací, kdy může spuštění update subnetwork ve verzi přinést neočekávané výsledky. Stojí za zmínku, že i když nástroj nemusí za všech okolností ve verzi produkovat očekávané výsledky, po zveřejnění verze do výchozí verze a spuštění update subnetwork ve výchozím nastavení bude výsledek správný.Nově vytvořené prvky
Náš první příklad navazuje na předchozí příklad. Předpokládejme databázi bez vyplněných informací o podsítích a před spuštěním update subnetwork ve výchozím nastavení vytvoříme novou pojmenovanou verzi a přidáme novou službu do této verze. Zde je obrázek nově vytvořených prvků v naší verzi před spuštěním update subnetwork:
Obrázek 4 Nové prvky vytvořené v pojmenované verzi
Po spuštění update subnetwork bez eventingu v pojmenované verzi si všimnete něčeho zajímavého.
Pouze prvky vytvořené v této verzi mají vyplněný název své podsítě
.Obrázek 5 Aktualizace nových prvků v pojmenované verzi bez eventinguKdyž update subnetwork běží bez eventingu v pojmenované verzi může aktualizovat pouze prvky vytvořené nebo upravené v této verzi
. Je to proto, že pokud prvek ještě nebyl upraven ve verzi, vyžadovalo by to spuštění geodatabázové události k vložení úpravy do verze.
Existující prvkyV dalším příkladu se podíváme na praktický případ toho, jak může update subnetwork bez eventingu v pojmenované verzi přinést neočekávané výsledky. Budeme sledovat reakci update subnetwork na úpravu vedoucí ke změně prvků z jedné podsítě do druhé.
Začínáme se dvěma podsítěmi (Síť A a Síť
), které jsou odděleny spojovacím zařízením (otevřený vypínač, uzavřený ventil atd.). Všechny podsítě byly aktualizovány ve výchozí verzi takže všechny atributy jsou správně vyplněny. Všimněte si že protože spojovací zařízení patří do více sítí je pole názvu podsítě odděleno středníky.
Obrázek 6 Dvě podsítě ve výchozím nastavení
V tomto příkladu změníme spojovací zařízení mezi sítěmi ze zařízení 3 na zařízení 1. To se často děje v reálném světě při přeconfiguraci okruhů tlakových zón atd., aby odpovídaly dlouhodobým či sezónním změnám poptávky zákazníků. Provedeme to změnou stavu těchto dvou zařízení tak aby zařízení 1 bylo nyní spojovacím zařízením a zařízení 3 již nefungovalo jako bariéra.
Obrázek 7 Aktualizované spojovací zařízení
Tyto změny vidíme reflektované na diagramu výše protože indikátor spojovacího zařízení se přesunul ze Zařízení 3 na Zařízení 1 datum poslední změny bylo aktualizováno a barvy prvků byly upraveny tak aby vizuálně ukazovaly ke které síti patří pokud byste trasovali každou síť zvlášť. Názvy sítí stále ukazují staré hodnoty protože jsme ještě nespustili update subnetwork. Níže vidíte diagram všech změn atributů které nastanou po spuštění update subnetwork za těchto podmínek.
Obrázek 8 Aktualizovaná podsíť v pojmenované verzi
Jak očekáváme vidíme že pole názvu podsítě u obou zařízení upravených v této verzi bylo aktualizováno.
. Protože tyto prvky nebyly upraveny v této aktualizaci verze, subnetwork je nemůže upravovat bez vyvolání editačních událostí.
Oba tyto příklady zdůrazňují omezení aktualizace subnetworks v pojmenovaných verzích bez eventingu. Pro mnoho zákazníků jsou tato omezení přijatelná kvůli výhodám výkonu tohoto režimu úprav a protože data se zobrazí správně, jakmile jsou data zveřejněna do default a spustí se update subnetwork, kde všichni mohou vidět výsledky. Nicméně jiní zákazníci byli ochotni akceptovat delší dobu běhu update subnetwork, aby splnili určité obchodní požadavky. Proto jsme zavedli možnost update subnetwork upravovat s eventingemjak si vysvětlíme v následující sekci.
Aktualizace s eventingem v pojmenované verzi
Pojďme znovu prozkoumat dva scénáře výše, ale podívejme se, jak se chovají při aktualizaci subnetwork v pojmenované verzi, když je vrstva nakonfigurována tak, aby měla režim úprav s eventingem.
Nově vytvořené prvky
Níže vidíme první příklad, kde je směs existujících a nových prvků, které je třeba aktualizovat.
Obrázek 9 Nové prvky ve verzi
A následuje výsledek po spuštění update subnetwork s eventingem.
Obrázek 10 Aktualizace subnetwork s eventingem v pojmenované verzi
Jak vidíte, všechny prvky mají správný název subnetwork a provozní oblast. Síť bude trvat déle na zpracování, protože upravuje více prvků a protože každý prvek vyvolá další úpravy pro zpracování editor tracking, pravidel atributů atd.
Existující prvky
Dále se podívejme na druhý příklad, kde jsme pře-konfigurovali několik subnetworks. Níže jsou data před spuštěním update subnetwork.
Obrázek 11 Prvky ve verzi před aktualizací subnetwork
A níže je stav prvků po spuštění update subnetwork v pojmenované verzi s eventingem.
Obrázek 12 Nové prvky ve verzi
Opět můžete vidět, že všechny atributy na prvcích mají správné hodnoty. Stojí za zmínku, že to bude trvat déle než provedení stejné operace bez eventingu. Přesto doba trvání bude přímo souviset s počtem/komplexitou pravidel atributů, která máte nakonfigurována na svých prvcích spolu s počtem vztahů s povoleným messagingem (včetně feature-linked annotation). Stojí za to měřit a zvážit tyto náklady na výkon vzhledem k důležitosti vizuální kontroly/review atributů síťových informací během vašeho procesu zajištění kvality.
Konfigurace
Nyní když jste viděli, jak tyto chování fungují, podívejme se, jak jsou nakonfigurovány v utility network. Tyto možnosti jsou konfigurovány pomocí nástroje Set Subnetwork Definition. Protože tento nástroj umožňuje upravit konfiguraci pro konkrétní vrstvu ve vaší síti, znamená to, že můžete definovat různá chování pro každou vrstvu (např. System a Pressure). I když je hezké mít možnost mít různá chování pro každou vrstvu, většina zákazníků preferuje mít všechny své vrstvy nastavené stejně, aby zajistili konzistentní pracovní postupy úprav pro editory.
Při nastavování režimu úprav pro vaši definici subnetwork existují dvě různá pole, každé se dvěma různými možnostmi. To znamená, že existují čtyři kombinace hodnot, které můžete nakonfigurovat pro své režimy úprav:
- Bez eventingu v defaultu, bez eventingu v pojmenovaných verzích (výchozí)
- Bez eventingu v defaultu, s eventingem v pojmenovaných verzích
- S eventingem v defaultu, s eventingem v pojmenovaných verzích
- S eventingem v defaultu, bez eventingu v pojmenovaných verzích
Než strávíte příliš mnoho času obavami o to, kterou ze čtyř možností potřebujete vybrat, měli byste vědět, že základní datové modely utility network poskytované Esri již mají své režimy úprav nakonfigurovány. Každý z těchto datových modelů má doporučenou sadu konfigurací vyvinutých odborníky z průmyslu spolu s jejich komunitou tak, aby konfigurace vyhovovala co nejširšímu spektru pracovních postupů pro daný průmysl.
I když tyto konfigurace splňují potřeby většiny zákazníků, je vždy dobré tyto konfigurace přezkoumat v kontextu vašich obchodních požadavků a jakýchkoli změn konfigurace/datového modelu, které jste provedli, abyste zajistili, že typická konfigurace je stále nejvhodnější.
Nejlepší postupy
Nejčastější otázka, kterou dostávám je: jaký je nejlepší postup pro konfiguraci vašeho režimu úprav v utility network? Neexistuje jediná odpověď na tuto otázku platná pro všechny zákazníky. Nicméně existuje několik kritérií k zvážení, která vám mohou pomoci rozhodnout se, která možnost je pro vás nejvhodnější. Tyto úvahy obvykle spadají do tří kategorií: pracovní postupy (workflow), anotace a pravidla atributů.
První úvaha je váš verzionovaný pracovní postup úprav. Pokud váš pracovní postup úprav vyžaduje provádění kontroly kvality v pojmenovaných verzích a tento proces zahrnuje používání nástrojů nebo vrstev spoléhajících na atributy uložené na prvcích (název subnetwork, propagované hodnoty atd.), pak budete chtít nastavit svůj režim úprav pro pojmenované verze na „S Eventingem“. To zajistí správné naplnění polí subnetwork pro všechny prvky ve vaší verzi tak, aby mohly být použity pro kontrolu kvality. Pokud lze váš QA proces provést zcela v defaultu nebo může používat trasování místo spoléhání se na atributy prvků, pak můžete nastavit svůj režim úprav pro pojmenované verze na „Bez Eventingu“.
Druhá úvaha je zda máte feature-linked annotation. Pokud nemáte feature-linked annotation nebo anotace výrazy nezahrnující informace ze subnetwork (název subnetwork, propagované hodnoty atd.), pak je vhodná kterákoliv možnost režimu úprav. Vztahové třídy s povoleným messagingem jako feature-linked annotation třídy mají výkonový dopad při úpravách, který budete muset pečlivě sledovat. Nicméně důležitější je pokud vaše feature-linked annotation obsahuje informace o subnetwork; máte několik rozhodnutí k učinění. Ukládání informací o subnetwork do anotací není považováno za nejlepší praxi kvůli statické povaze anotací a dynamické povaze subnetworks a výkonovým nákladům udržování synchronizace obou. Měli byste zvážit nahrazení těchto feature-linked annotation funkcemi štítků (labels). Pokud je to však tvrdý požadavek, musíte nastavit svůj režim úprav na „S Eventingem“ jak pro pojmenované verze tak i default k zajištění aktualizace textu v anotacích při spuštění update subnetwork; buďte však si vědomi dopadu na výkon update subnetwork.
Třetí věc k zvážení jsou pravidla atributů která jste definovali na svých prvcích utility network. Jakékoli pravidlo atributů nakonfigurované k aktivaci při aktualizaci bude vyhodnoceno kdykoli bude daný prvek aktualizován bez ohledu na pole kterému je přiřazeno. To znamená že pokud používáte režim úprav s eventingem, všechna pravidla okamžitého výpočtu budou spuštěna během update subnetwork u všech aktualizovaných prvků. Pokud je to tvrdý požadavek a jste ochotni akceptovat výkonové náklady, měli byste přezkoumat svá pravidla atributů tak aby obsahovala logiku raného ukončení během update subnetwork ke snížení těchto nákladů na výkon. Pokud máte pravidla atributů reagující na změny polí subnetwork vězte že to není považováno za nejlepší praxi. Nicméně pokud je to tvrdý požadavek musíte nastavit svůj režim úprav na „S Eventingem“ k zajištění spuštění pravidla atributů během update subnetwork.
S těmito úvahami si projděme čtyři možnosti a uvidíme kde jsou nejvhodnější.
Bez eventingu v defaultu a bez eventingu v pojmenovaných verzích. Tato možnost je výchozí chování systému. Poskytuje nejlepší výkon ale má omezení kolem aktualizace prvků ve verzích a feature-linked annotation.
Bez eventingu v defaultu a s eventingemv pojmenovaných verzích. Tato možnost představuje rovnováhu mezi výkonem a funkčností. Poskytuje nejlepší výkon při aktualizaci subnetwork v defaultu a nejlepší zážitek z kontroly kvality v pojmenované verzi.
S eventingem v defaultu a s eventingem v pojmenovaných verzích. Tato možnost poskytuje nejvíce funkčnosti ale také nejvyšší náklady na výkon. Pokud implementujete tuto konfiguraci měli byste přezkoumat jakákoli pravidla atributů nakonfigurovaná ke spuštění při modifikaci prvků aby byla nastavena tak aby poskytovala logiku raného ukončení během update subnetwork.
S eventingem v defaultu a bez eventingu v pojmenovaných verzích. Toto je nejméně běžná konfigurace. Je určena zákazníkům kteří potřebují spouštět anotace nebo pravidla atributů v default ale ne ve verzích.
Závěr
Nyní když jste si přečetli tento článek byste měli rozumět výhodám/nevýhodám různých režimů úprav používaných pro správu subnetworks a měli byste být schopni určit které režimy jsou vhodné pro váš datový model, pracovní postupy úprav a obchodní požadavky.
Pokud chcete zjistit jak zmírnit dopady výkonu editačních událostí na pravidla atributů přečtěte si článek Attribute Rule Triggering Fields.
Pokud chcete vědět více o správě subnetworks nebo vyzkoušet praktické návody najdete příklady specifické pro průmysl v sérii vzdělávacích lekcí Getting Started with ArcGIS Utility Network.
Pokud chcete více detailů a hlubší pohledy na schopnosti správy subnetworks utility network doporučuji podívat se na další technické články na stránce komunity Esri ArcGIS Utility Network. Esri community page.
