Update: ArcGIS Pro 3.4/ArcGIS Enterprise 11.4 geïntroduceerd Triggerende Velden wat de discussie beïnvloedt over het beperken van de impact van bewerkingen met events.
Welkom bij de serie begrip van subnetworkbeheer, waar we dieper ingaan op enkele van de meer geavanceerde onderwerpen van subnetworkbeheer. Als je niet bekend bent met wat subnetwerken zijn of hoe ze werken, raad ik je aan de artikelen en tutorials in de Managing Subnetworks with ArcGIS Utility Network leerreeks te lezen om te beginnen.
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.
Door dit artikel te lezen begrijp je de impact die deze instelling heeft op de prestaties van update subnetwork en waarom je voor bepaalde workflows eventing wilt inschakelen, ook al beïnvloedt dit de prestaties.
Wat is een bewerkingsmodus?
Wat is een bewerkingsmodus? In de 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 die relaties of attribuutregels bevatten, 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 er een korte bespreking over hoe zakelijke vereisten geëvalueerd kunnen worden en best practices voor het maken van deze beslissing. Daarnaast kun je 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/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 wordt onderhouden door de geodatabase.
- Subnetwork Naam – Dit is het subnetwork naamveld dat wordt onderhouden door het utility network.
- Netwerk Regio – Dit veld wordt onderhouden door een attribuutregel die de subnetwork naam van het object gebruikt om een 'regio' waarde uit een opzoektafel op te halen.
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 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 ‘Unknown’ en hebben de overige velden hun initiële waarden uit de datalaadfase. Je kunt een voorbeeld hiervan zien 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
Je ziet dat naast het invullen van het subnetwork naamveld ook het Laatst Gewijzigd veld werd bijgewerkt door editor tracking, en het Operating Area 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 komen al deze extra triggers en updates ten koste van prestaties. Dus als je veel attribuutregels en/of feature-linked annotatieklassen hebt, moet je goed nadenken over de impact hiervan op je 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 objecten waarvan nog geen bewerking heeft plaatsgevonden in die versie kunnen worden bijgewerkt met betrekking tot hun subnetwork-informatie.Als je niet tevreden bent met het gedrag dat je ziet in deze voorbeelden, onthoud dan dat we een nieuwe optie hebben geïntroduceerd om deze beperkingen te overwinnen zoals besproken in de volgende sectie (Update met eventing in een benoemde versie).
Om dit probleem volledig te bespreken zullen we twee aparte voorbeelden bekijken waarbij uitvoeren van update subnetwork in een versie onverwachte resultaten kan opleveren. Het is vermeldenswaard dat hoewel de tool mogelijk niet onder alle omstandigheden verwacht resultaat geeft binnen een versie, deze 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 service toe te voegen. Hier is een afbeelding van onze nieuw aangemaakte objecten in onze versie voordat update subnetwork wordt uitgevoerd:
Figuur 4 Nieuwe objecten aangemaakt in een benoemde versie
Na uitvoeren van update subnetwork zonder eventing in de benoemde versie valt iets op.Alleen de objecten die in deze versie zijn aangemaakt krijgen hun subnetwork naam ingevuld.
Figuur 5 Update nieuwe objecten in een benoemde versie zonder eventing
Wanneer update subnetwork zonder eventing wordt uitgevoerd in een benoemde versie kan alleen worden bijgewerkt wat is aangemaakt of bewerkt binnen die versie.. Dit komt omdat als het object nog niet is gewijzigd binnen die versie, er een geodatabase-event getriggerd zou moeten worden om die wijziging toe te voegen aan die versie.
Bestaande objecten
Voor ons volgende voorbeeld bekijken we nog een praktisch voorbeeld hoe 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. Let op dat omdat een verbindingsapparaat tot meerdere subnetwerken behoort, het subnetwork naamveld gescheiden wordt door puntkomma's.
Figuur 6 Twee subnetwerken in default
In dit voorbeeld veranderen we het verbindingsapparaat tussen subnetwerken van apparaat 3 naar apparaat 1. Dit gebeurt vaak in de praktijk wanneer circuits, drukzones etc. worden herconfigureerd vanwege langdurige of zelfs seizoensgebonden veranderingen in klantvraag. We veranderen 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 veranderingen terugkomen in bovenstaande diagram omdat indicator voor verbindingsapparaat verplaatst is van apparaat 3 naar apparaat 1, datum laatst gewijzigd is bijgewerkt en we hebben kleuren aangepast op objecten om visueel aan te geven tot welk subnetwork ze behoren als je elk netwerk zou traceren. De subnetwerknamen tonen nog steeds oude waarden omdat we nog geen update subnetwork hebben uitgevoerd. Hieronder zie je een diagram dat alle attribuutwijzigingen toont die optreden 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 bewerkt binnen deze versie is bijgewerkt.Echter hebben objecten die verbonden waren met Netwerk A maar nu verbonden zijn met Netwerk B nog steeds oude waarden voor subnetwerknaam en operating area. Omdat deze features niet zijn bewerkt in deze versie-update, kan subnetwork ze niet bewerken zonder bewerkgebeurtenissen te activeren.
Beide voorbeelden benadrukken de beperkingen van het bijwerken van subnetworks in benoemde versies 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 om te accepteren dat update subnetwork langer duurt om te voldoen aan bepaalde zakelijke vereisten. 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 benoemde versie
Laten we de twee scenario's van hierboven opnieuw bekijken, maar nu hoe ze zich gedragen bij het bijwerken van het subnetwork in een benoemde versie 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 het volgende is het resultaat na het uitvoeren van update subnetwork met eventing.
Figuur 10 Update subnetwork met eventing in benoemde versie
Zoals je kunt zien hebben alle features de juiste subnetworknaam en operationeel gebied. Het netwerk zal langer duren om te verwerken omdat er meer features worden bewerkt en omdat elke feature extra bewerkingen activeert voor het afhandelen van editor tracking, attribuutregels, enzovoort.
Bestaande features
Laten we nu het tweede voorbeeld bekijken waarin we verschillende subnetworks hebben geherconfigureerd. Hieronder staan de gegevens voordat update subnetwork werd uitgevoerd.
Figuur 11 Features in een versie vóór het bijwerken van subnetwork
En hieronder is de status van de features na het uitvoeren van update subnetwork in een benoemde versie 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 vermeldenswaard dat dit langer zal duren dan dezelfde operatie uitvoeren zonder eventing. Toch is de tijd die het kost direct gerelateerd aan het aantal/complexiteit van attribuutregels die je hebt geconfigureerd op je features samen met het aantal relaties met messaging ingeschakeld (inclusief feature-linked annotation). Het is verstandig om deze prestatiekosten te meten en te overwegen 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 de optie te hebben om verschillende gedragingen per tier te hebben, 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 verschillende opties. Dit betekent dat er vier combinaties van waarden zijn die je kunt configureren voor je bewerkingsmodi:
- Zonder eventing in default, zonder eventing in benoemde versies (standaard)
- Zonder eventing in default, met eventing in benoemde versies
- Met eventing in default, met eventing in benoemde versies
- Met eventing in default, zonder eventing in benoemde versies
Voordat je teveel tijd besteedt aan welke van deze vier opties je moet selecteren, 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 aantrekkelijk is voor het breedste scala aan workflows binnen die industrie.
Hoewel deze configuraties aan de meeste behoeften van klanten voldoen, is het altijd een goed idee om deze configuraties te herzien binnen de context van jouw zakelijke vereisten en eventuele configuratie-/datamodelwijzigingen die je hebt aangebracht om ervoor te zorgen 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 kunnen helpen bepalen 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 benoemde versies, en dit proces omvat het gebruik van tools of lagen die afhankelijk zijn van attributen opgeslagen op features (subnetworknaam, gepropageerde waarden, enz.), dan wil je je bewerkingsmodus voor benoemde versies instellen op 1 Met Eventing7. Dit zorgt ervoor dat de subnetworkvelden altijd correct worden ingevuld voor alle features in jouw versie zodat ze kunnen worden gebruikt 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 benoemde versies instellen op 1 Zonder Eventing7.
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 subnetwork (subnetworknaam, gepropageerde waarden, enz.), dan is elke bewerkingsmodusoptie geschikt voor jou. Relatieklassen met messaging ingeschakeld, zoals feature-linked annotation klassen, brengen wel een prestatiekost mee bij bewerken die je zorgvuldig moet monitoren. Maar belangrijker nog: als jouw feature-linked annotation informatie bevat over het subnetwork, moet je keuzes maken. Het opslaan van subnetworkinformatie in annotatieklassen wordt niet beschouwd als best practice vanwege de statische aard van annotatie, de dynamische aard van subnetworks en de prestatiekost om beide synchroon te houden. Je zou moeten overwegen deze feature-linked annotation features te vervangen door labels. Maar als dit een harde eis is, moet je jouw bewerkingsmodus instellen op 1 Met Eventing7 voor zowel benoemde versies 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 geconfigureerd dat hij afgaat bij update wordt geëvalueerd telkens wanneer die feature wordt bijgewerkt, ongeacht welk veld wordt aangepast. 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 om de prestatiekost te accepteren, moet je jouw attribuutregels herzien om ervoor te zorgen dat ze geschreven zijn met vroege exit-logica tijdens update subnetwork om deze prestatiekost te minimaliseren. Als je attribuutregels hebt die reageren op veranderingen aan subnetworkvelden, moet je weten dat dit niet als best practice wordt beschouwd. Maar als dit een harde eis is, moet je jouw bewerkingsmodus instellen op 1 Met Eventing7 om ervoor te zorgen dat de attribuutregel wordt afgevuurd 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 benoemde versies. Deze optie is het standaardgedrag van het systeem. Het geeft je de beste prestaties maar heeft beperkingen rond het bijwerken van features in versies en feature-linked annotation.
Zonder eventing in default en met eventinga0in benoemde versies. 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 benoemde versie.
Met eventing in default en met eventing in benoemde versies. Deze optie biedt de meeste functionaliteit maar heeft ook de hoogste prestatiekost. Als je deze configuratie implementeert, moet je alle attribuutregels herzien die zijn geconfigureerd om uit te voeren wanneer features worden gewijzigd om ervoor te zorgen dat ze zo zijn ingesteld dat ze vroegtijdig stoppen tijdens update subnetwork.
Met eventing in default en zonder eventing in benoemde versies. 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 bewerkgebeurtenissen 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, kun je branchespecifieke voorbeelden vinden 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.
