Update: ArcGIS Pro 3.4/ArcGIS Enterprise 11.4 introduceerde Triggerende Velden wat de discussie beïnvloedt over het beperken van de impact van bewerkingen met events.
Het beheren van subnetwerken kan vaak het maken van honderden of duizenden bewerkingen aan objecten inhouden wanneer een subnetwork wordt gemaakt of opnieuw geconfigureerd. Daarom biedt het systeem verschillende bewerkingsmodi die kunnen worden gebruikt om deze updates uit te voeren. Meer informatie over dit onderwerp vindt u in de Subnetworks onderwerp in de online help.
Door dit artikel te lezen, begrijpt u de impact die deze instelling heeft op de prestaties van update subnetwork en waarom u voor bepaalde workflows eventing wilt inschakelen, ook al beïnvloedt dit de prestaties.
Wat is een bewerkingsmodus?
Wat is een bewerkingsmodus? In het ArcGIS Utility Network verwijst de bewerkingsmodus naar hoe de software systeemvelden op objecten beheert wanneer subnetwerken worden beheerd. Er zijn momenteel twee opties voor bewerkingsmodi, met eventing of zonder eventing.
Waar verwijzen we naar met “eventing” als we zeggen dat we data beheren met eventing of zonder eventing? Met eventing bedoelen we specifiek geodatabase-events die worden geactiveerd als reactie op bewerkingen. Geodatabase-events zijn een van de manieren waarop ArcGIS speciale gedragingen activeert wanneer objecten in een geodatabase worden bewerkt. Veelvoorkomende voorbeelden hiervan zijn gedragingen zoals het invullen van editor tracking-velden, het activeren van attribuutregels, het doorgeven van wijzigingen aan gerelateerde objecten en het bijwerken van feature-linked annotatie.
Wat heeft dit te maken met de subnetwerken? Een van de tools die gebruikers vaak gebruiken als onderdeel van hun bewerkingsworkflow is de update subnetwork tool. Deze tool beheert systeemvelden op utility network-objecten die het subnetwork beschrijven waaraan ze deelnemen. Elke keer dat een van deze objecten wordt bewerkt, activeert dit verschillende bewerkingsevents. Datamodellen met relaties of attribuutregels activeren meer events tijdens update subnetwork dan datamodellen met minder relaties en attribuutregels. Al deze events, regels en relaties voegen extra tijd toe aan het update subnetwork-proces.
Om hiermee om te gaan kunnen beheerders de tiers in hun netwerk configureren om een bewerkingsmodus te gebruiken die ofwel de normale geodatabase-events gebruikt (met eventing) of het normale geodatabase-eventmodel omzeilt (zonder eventing) bij het beheren van subnetwerken in die tier. Aan het einde van dit artikel is een korte bespreking opgenomen over hoe zakelijke vereisten geëvalueerd kunnen worden en best practices voor deze beslissing. Daarnaast kunt u ook triggerende velden gebruiken om precies te bepalen op welke bewerkingen attribuutregels reageren om zo de impact van bewerkingsevents tijdens update subnetwork te beperken.
Maar laten we nu eens kijken naar enkele voorbeelden van verschillende configuraties. In elk voorbeeld bekijken we hoe een set objecten reageert onder bepaalde omstandigheden. Elk object is gelabeld met 4 velden, en wanneer een waarde wordt gewijzigd, wordt het veld/de waarde vetgedrukt weergegeven:
- Asset ID – Dit is een unieke identificatie voor elk object. Het wordt ingevuld wanneer het object wordt gemaakt.
- Datum Gewijzigd – Dit is het editor tracking-veld dat door de geodatabase wordt onderhouden.
- Subnetwork Naam – Dit is het subnetwork naamveld dat door het utility network wordt onderhouden.
- Netwerk Regio – Dit veld wordt onderhouden door een attribuutregel die de subnetwork naam van het object gebruikt om een 'regio' waarde op te halen uit een opzoektafel.
Opmerking: Als geen van de attribuutregels informatie uit het subnetwork nodig heeft, kunnen alle attribuutregels zo worden geconfigureerd dat ze niet worden geactiveerd bij updates tijdens update subnetwork om zo prestatie-impact veroorzaakt door attribuutregels tijdens update subnetwork te beperken.
Update zonder eventing in default
Het eerste voorbeeld dat we bekijken is iets wat elk project minstens één keer doet. Het uitvoeren van update subnetwork op de default versie in een gloednieuwe database. In dit geval hebben alle subnetwork naamvelden in de database de waarde ‘Onbekend’ en hebben de overige velden hun initiële waarden uit de datalaadfase. Een voorbeeld hiervan ziet u in onderstaande afbeelding.
Figuur 1 Initiële database status
Na het uitvoeren van update subnetwork op Netwerk A zien we dat het subnetwork naamveld is bijgewerkt op alle objecten in het subnetwork, maar editor tracking en attribuutregels werden niet geactiveerd tijdens deze updates. Als een van onze klassen feature-linked annotatie had, zou deze annotatie ook niet zijn aangepast tijdens dit event.
Figuur 2 Update subnetwork in default zonder eventing
Laten we dit nu vergelijken met hoe het systeem zou reageren als we dezelfde actie uitvoeren maar met de bewerkingsmodus ingesteld op met eventing.
Update met eventing in default
Wanneer het utility network is geconfigureerd om een subnetwork bij te werken met eventing betekent dit dat alle geodatabase-gedragingen worden geactiveerd wanneer update subnetwork attributen op een object bijwerkt. Als het vorige voorbeeld was uitgevoerd met eventing, zouden de resultaten eruitzien zoals in onderstaande diagram.
Figuur 3 Update subnetwork in default met eventing
U ziet dat naast het invullen van het subnetwork naamveld ook het Laatst Gewijzigd veld werd bijgewerkt door editor tracking, en het Bedrijfsgebied veld werd bijgewerkt door onze attribuutregel. Daarnaast zouden feature-linked annotatie-objecten die naar één of meer van deze velden verwijzen ook worden bijgewerkt.
Echter, al deze extra triggers en updates gaan ten koste van de prestaties. Dus als u veel attribuutregels en/of feature-linked annotatieklassen heeft, moet u goed nadenken over de impact hiervan op uw systeem.
Update zonder eventing in een benoemde versie
De meest interessante situatie is om te kijken hoe update subnetwork zich gedraagt wanneer uitgevoerd in een benoemde versie zonder eventing. Dit is het standaardgedrag van het systeem omdat dit het meest performant is.Wanneer update subnetwork wordt uitgevoerd in een versie zonder eventing, heeft dit als nadeel dat niet alle subnetwork-informatie kan worden bijgewerkt op objecten die nog niet zijn bewerkt in die versie. Als u niet tevreden bent met dit gedrag zoals getoond in deze voorbeelden, onthoud dan dat we een nieuwe optie hebben geïntroduceerd om deze beperkingen te overwinnen, besproken in de volgende sectie (Update met eventing in een benoemde versie).
Om dit probleem volledig te bespreken behandelen we twee aparte voorbeelden waarbij uitvoeren van update subnetwork in een versie onverwachte resultaten kan opleveren. Het is belangrijk op te merken dat hoewel de tool mogelijk niet onder alle omstandigheden verwacht resultaat geeft binnen een versie, hij wel correct werkt zodra de versie is gepost naar default en update subnetwork daar wordt uitgevoerd.
Nieuw aangemaakte objecten
Ons eerste voorbeeld bouwt voort op ons vorige voorbeeld. Stel dat we een database hebben zonder ingevulde subnetwork-informatie, en voordat we update subnetwork in default uitvoeren besluiten we een nieuwe benoemde versie aan te maken en daarin een nieuwe dienst toe te voegen. Hier is een afbeelding van onze nieuw aangemaakte objecten in onze versie vóór uitvoering van update subnetwork:
Figuur 4 Nieuwe objecten aangemaakt in een benoemde versie
Na uitvoering van update subnetwork zonder eventing in de benoemde versie valt iets bijzonders op.Alleen de objecten die in deze versie zijn aangemaakt krijgen hun subnetwork naam ingevuld.
Figuur 5 Update nieuwe objecten in benoemde versie zonder eventing
Wanneer update subnetwork zonder eventing draait in een benoemde versie kan alleen informatie worden bijgewerkt voor objecten die zijn aangemaakt of bewerkt binnen die versie. Dit komt omdat als het object nog niet was aangepast binnen die versie, er een geodatabase-event getriggerd zou moeten worden om die wijziging toe te voegen aan de versie.
Bestaande Objecten
Voor ons volgende voorbeeld bekijken we nog een praktisch voorbeeld waarbij uitvoeren van update subnetwork zonder eventing in een benoemde versie onverwachte resultaten kan geven. We kijken hoe update subnetwork reageert op een wijziging waarbij objecten veranderen van het ene naar het andere subnetwork.
We beginnen met twee subnetwerken (Netwerk A en Netwerk 
) die gescheiden zijn door een verbindingsapparaat (open schakelaar, gesloten klep, etc.). Alle subnetwerken zijn bijgewerkt in default versie, dus alle attributen zijn correct ingevuld. Omdat een verbindingsapparaat tot meerdere subnetwerken behoort, wordt het subnetwork naamveld gescheiden door puntkomma's.
Figuur 6 Twee subnetwerken in default
In dit voorbeeld veranderen we het verbindingsapparaat tussen de subnetwerken van apparaat 3 naar apparaat 1. Dit gebeurt vaak in de praktijk wanneer circuits, drukzones etc. worden heringericht vanwege langdurige of zelfs seizoensgebonden veranderingen in klantvraag. We wijzigen hiervoor de status van deze twee apparaten om hun nieuwe open/gesloten status aan te geven zodat apparaat 1 nu verbindingsapparaat is en apparaat 3 niet langer als barrière fungeert.
Figuur 7 Bijgewerkt verbindingsapparaat
We zien deze wijzigingen terugkomen in bovenstaande diagram omdat de indicator voor verbindingsapparaat verplaatst is van apparaat 3 naar apparaat 1, de laatst gewijzigde datum is bijgewerkt en we hebben kleuren toegevoegd aan de objecten om visueel aan te geven tot welk subnetwork ze behoren als je elk netwerk zou traceren. De subnetwerknamen tonen nog steeds hun oude waarden omdat we update subnetwork nog niet hebben uitgevoerd. Hieronder ziet u een diagram dat alle attribuutwijzigingen toont die zullen plaatsvinden wanneer update subnetwork onder deze voorwaarden wordt uitgevoerd.
Figuur 8 Bijgewerkt subnetwork in benoemde versie
Zoals verwacht zien we dat het subnetwork naamveld op beide apparaten die we hebben aangepast binnen deze versie is bijgewerkt.Echter behouden objecten die verbonden waren met Netwerk A maar nu verbonden zijn met Netwerk B nog steeds hun oude waarden voor subnetwerknaam en bedrijfsgebied. Omdat deze objecten niet zijn aangepast binnen deze versie kan update subnetwork ze niet aanpassen zonder edit events te triggeren.
Beide voorbeelden benadrukken de beperkingen van het bijwerken van subnetwerken in named versions zonder eventing. Voor veel klanten zijn deze beperkingen acceptabel vanwege de prestatievoordelen van deze bewerkingsmodus, en omdat de gegevens correct zullen verschijnen zodra de data is gepost naar default en update subnetwork wordt uitgevoerd waar iedereen de resultaten kan zien. Andere klanten waren echter bereid te accepteren dat update subnetwork langer duurt om aan bepaalde zakelijke vereisten te voldoen. Daarom hebben we de mogelijkheid geïntroduceerd om update subnetwork te bewerken met eventing zoals we in de volgende sectie zullen bespreken.
Update met eventing in een named version
Laten we de twee bovenstaande scenario's opnieuw bekijken, maar nu hoe ze zich gedragen bij het bijwerken van het subnetwork in een named version wanneer de tier is geconfigureerd met een bewerkingsmodus met eventing.
Nieuw aangemaakte features
Hieronder zien we het eerste voorbeeld, waar een mix is van bestaande en nieuwe features die bijgewerkt moeten worden.
Figuur 9 Nieuwe features in een versie
En hieronder het resultaat na het uitvoeren van update subnetwork met eventing.
Figuur 10 Update subnetwork met eventing in named version
Zoals je kunt zien hebben alle features de juiste subnetwerknaam en bedieningsgebied. Het netwerk zal langer duren om te verwerken omdat er meer features worden bewerkt en omdat elke feature extra bewerkingen zal triggeren voor het afhandelen van editor tracking, attribuutregels, enzovoort.
Bestaande features
Vervolgens bekijken we het tweede voorbeeld waarin we verschillende subnetwerken hebben herconfigureerd. Hieronder staan de gegevens voordat update subnetwork is uitgevoerd.
Figuur 11 Features in een versie vóór het bijwerken van het subnetwork
En hieronder de status van de features na het uitvoeren van update subnetwork in een named version met eventing.
Figuur 12 Nieuwe features in een versie
Opnieuw kun je zien dat alle attributen op de feature de juiste waarden hebben. Het is belangrijk te vermelden dat dit langer zal duren dan dezelfde operatie uitvoeren zonder eventing. De tijd die het kost hangt direct samen met het aantal/complexiteit van attribuutregels die je hebt geconfigureerd op je features, evenals het aantal relaties met messaging ingeschakeld (inclusief feature-linked annotation). Het is verstandig deze prestatiekosten af te wegen tegen het belang van visuele inspectie/attribuutcontrole van netwerkinformatie tijdens je kwaliteitsborgingsproces.
Configuratie
Nu je hebt gezien hoe deze gedragingen werken, laten we kijken hoe ze zijn geconfigureerd in een utility network. Deze opties worden geconfigureerd met behulp van de Set Subnetwork Definition tool. Omdat deze tool je toestaat om de configuratie voor een specifieke tier in je netwerk aan te passen, betekent dit dat je verschillende gedragingen kunt definiëren voor elke tier (bijv. System en Pressure). Hoewel het fijn is om verschillende gedragingen per tier te kunnen instellen, geven de meeste klanten er de voorkeur aan dat al hun tiers hetzelfde gedrag vertonen om consistente bewerkingsworkflows voor editors te garanderen.
Bij het instellen van de bewerkingsmodus voor je subnetworkdefinitie zijn er twee verschillende velden, elk met twee opties. Dit betekent dat er vier combinaties mogelijk zijn voor je bewerkingsmodi:
- Zonder eventing in default, zonder eventing in named versions (standaard)
- Zonder eventing in default, met eventing in named versions
- Met eventing in default, met eventing in named versions
- Met eventing in default, zonder eventing in named versions
Voordat je teveel tijd besteedt aan welke van deze vier opties je moet kiezen, moet je weten dat de utility network foundation data modellen die door Esri worden geleverd al hun bewerkingsmodi geconfigureerd hebben. Elk van deze datamodellen heeft een aanbevolen set configuraties ontwikkeld door branche-experts samen met hun community, om een configuratie te bieden die aansluit bij de breedste reeks workflows voor die industrie.
Hoewel deze configuraties aan de meeste behoeften van klanten voldoen, is het altijd verstandig om deze configuraties te herzien binnen de context van jouw zakelijke vereisten en eventuele wijzigingen die je hebt aangebracht in configuratie/datamodel om te verzekeren dat de typische configuratie nog steeds het meest geschikt is.
Best Practices
De meest gestelde vraag die ik krijg is wat de beste praktijk is voor het configureren van je bewerkingsmodus in het utility network? Er is geen eenduidig antwoord dat voor alle klanten werkt. Er zijn echter verschillende criteria om te overwegen die je kunnen helpen beslissen welke optie het meest geschikt is voor jou. Deze overwegingen vallen meestal in drie categorieën: workflow, annotatie en attribuutregels.
De eerste overweging is je versioned editing workflow. Als jouw bewerkingsworkflow vereist dat je kwaliteitscontrole uitvoert in named versions, en dit proces omvat tools of lagen die afhankelijk zijn van attributen opgeslagen op features (subnetwerknaam, gepropageerde waarden, enz.), dan wil je je bewerkingsmodus voor named versions instellen op “Met Eventing”. Dit zorgt ervoor dat de subnetwerkvelden altijd correct gevuld zijn voor alle features in jouw versie zodat ze gebruikt kunnen worden voor kwaliteitscontrole. Als jouw QA-proces volledig kan worden uitgevoerd in default, of als jouw QA-proces tracing kan gebruiken in plaats van afhankelijk te zijn van feature-attributen, dan kun je je bewerkingsmodus voor named versions instellen op “Zonder Eventing”.
De tweede overweging is of je feature-linked annotation hebt. Als je geen feature-linked annotation hebt of annotatie-expressies die geen informatie bevatten uit het subnetwerk (subnetwerknaam, gepropageerde waarden, enz.), dan is elke bewerkingsmodus optie geschikt voor jou. Relatieklassen met messaging ingeschakeld, zoals feature-linked annotation klassen, brengen wel een prestatiekost mee bij bewerking die je goed moet monitoren. Maar belangrijker nog: als jouw feature-linked annotation informatie bevat over het subnetwerk, moet je keuzes maken. Het opslaan van subnetwerkinformatie in annotatieklassen wordt niet als best practice beschouwd vanwege de statische aard van annotatie, de dynamische aard van subnetwerken en de prestatiekosten om beide synchroon te houden. Je zou moeten overwegen deze feature-linked annotation features te vervangen door labels. Als dit echter een harde eis is, moet je jouw bewerkingsmodus instellen op “Met Eventing” voor zowel named versions als default om ervoor te zorgen dat tekst in jouw annotatie wordt bijgewerkt wanneer update subnetwork wordt uitgevoerd, maar wees ervan bewust dat dit invloed heeft op de prestaties van update subnetwork.
Het derde punt om te overwegen zijn de attribuutregels die je hebt gedefinieerd op jouw utility network features. Elke attribuutregel die zo is ingesteld dat hij afgaat bij update wordt geëvalueerd telkens wanneer die feature wordt bijgewerkt, ongeacht aan welk veld hij gekoppeld is. Dit betekent dat als je de bewerkingsmodus met eventing gebruikt, alle directe berekeningsregels zullen afgaan tijdens update subnetwork op alle bijgewerkte features. Als dit een harde eis is en je bent bereid de prestatiekosten te accepteren, moet je jouw attribuutregels herzien om ervoor te zorgen dat ze geschreven zijn met vroege exit-logica tijdens update subnetwork om deze prestatiekosten te minimaliseren. Als je attribuutregels hebt die reageren op veranderingen aan subnetwerkvelden, moet je weten dat dit niet als best practice wordt beschouwd. Maar als dit een harde eis is, moet je jouw bewerkingsmodus instellen op “Met Eventing” om ervoor te zorgen dat de attribuutregel wordt uitgevoerd tijdens update subnetwork.
Met deze overwegingen in gedachten laten we nu de vier opties zien en waar ze het meest geschikt zijn.
Zonder eventing in default en zonder eventing in named versions. Deze optie is het standaardgedrag van het systeem. Het geeft je de beste prestaties maar heeft beperkingen bij het bijwerken van features in versies en feature-linked annotation.
Zonder eventing in default en met eventing in named versions. Deze optie biedt een balans tussen prestaties en functionaliteit. Het geeft je de beste prestaties bij update subnetwork in default en de beste ervaring voor kwaliteitscontrole in een named version.
Met eventing in default en met eventing in named versions. Deze optie biedt de meeste functionaliteit maar heeft ook de hoogste prestatiekosten. Als je deze configuratie implementeert, moet je alle attribuutregels die draaien bij wijziging van features herzien om ervoor te zorgen dat ze zo zijn ingesteld dat ze vroegtijdig stoppen tijdens update subnetwork.
Met eventing in default en zonder eventing in named versions. Dit is de minst voorkomende configuratie. Het is bedoeld voor klanten die annotatie of attribuutregels moeten uitvoeren in default maar niet in versies.
Conclusie
Nu je dit artikel hebt gelezen zou je inzicht moeten hebben gekregen in de voor- en nadelen van verschillende bewerkingsmodi gebruikt voor subnetwerkbeheer, en zou je moeten kunnen bepalen welke modi geschikt zijn voor jouw datamodel, bewerkingsworkflows en zakelijke vereisten.
Als je wilt leren hoe je prestatie-impacten van bewerkingsevenementen op attribuutregels kunt beperken, lees dan het Attribute Rule Triggering Fields artikel.
Als je meer wilt weten over subnetwerkbeheer of hands-on tutorials wilt proberen, vind je branchespecifieke voorbeelden op de Getting Started with ArcGIS Utility Network leerserie.
Als je meer details en diepgaande informatie wilt over subnetwerkbeheer mogelijkheden van het utility network raad ik aan enkele andere technische artikelen op de ArcGIS Utility Network Esri community pagina te bekijken.
