Actualización: ArcGIS Pro 3.4/ArcGIS Enterprise 11.4 introdujo Campos de activación que afecta la discusión sobre cómo mitigar los impactos de la edición con eventos.
Bienvenido a la serie de comprensión de la gestión de subredes, donde profundizamos en algunos de los temas más avanzados de la gestión de subredes. Si no está familiarizado con qué son las subredes o cómo funcionan, le recomiendo leer los artículos y tutoriales en la Serie de aprendizaje Gestionando Subredes con ArcGIS Utility Network para comenzar.
Gestionar subredes a menudo puede implicar hacer cientos o miles de ediciones a entidades cuando se crea o reconfigura una subred. Debido a esto, el sistema proporciona varios modos de edición diferentes que se pueden usar para realizar estas actualizaciones.
Al leer este artículo entenderá el impacto que esta configuración tiene en el rendimiento de actualizar subred y por qué, para ciertos flujos de trabajo, puede querer habilitar eventing aunque impacte el rendimiento.
¿Qué es un modo de edición?
¿Qué es un modo de edición? En ArcGIS Utility Network, el modo de edición se refiere a cómo el software gestionará los campos del sistema en las entidades cuando se gestionan subredes. Actualmente hay dos opciones para modos de edición, con eventing o sin eventing.
¿A qué "eventing" nos referimos cuando decimos que estamos gestionando datos con eventing o sin eventing? Cuando decimos eventing, nos referimos específicamente a eventos de geodatabase que se activan en respuesta a ediciones. Los eventos de geodatabase son una de las formas en que ArcGIS activa comportamientos especiales cuando se editan objetos en una geodatabase. Ejemplos comunes son comportamientos como llenar campos de seguimiento del editor, disparar reglas de atributos, enviar mensajes sobre cambios a objetos relacionados y actualizar anotaciones vinculadas a entidades.
¿Qué tiene esto que ver con las subredes? Una de las herramientas que los usuarios comúnmente ejecutan como parte de su flujo de trabajo de edición es la herramienta actualizar subred. Esta herramienta es responsable de gestionar los campos del sistema en las entidades de la red eléctrica que describen la subred en la que participan. A medida que cada una de estas entidades es editada, dispara diferentes eventos de edición. Los modelos de datos que incluyen relaciones o reglas de atributos dispararán más eventos durante actualizar subred que los modelos con menos relaciones y reglas. Todos los eventos, reglas y relaciones añaden tiempo adicional al proceso actualizar subred.
Para manejar esta situación, los administradores pueden configurar los niveles en su red para usar un modo de edición que utilice ya sea los eventos normales de geodatabase (con eventing) o evite el modelo normal de eventos de geodatabase (sin eventing) al gestionar subredes en ese nivel. Hay una breve discusión sobre cómo evaluar requisitos comerciales y mejores prácticas para tomar esta decisión al final del artículo. Además, también puede usar campos desencadenantes para controlar exactamente a qué ediciones responden las reglas de atributos para mitigar los impactos de los eventos durante actualizar subred.
Pero por ahora, veamos algunos ejemplos de diferentes configuraciones. En cada ejemplo, veremos cómo un conjunto de entidades responde bajo ciertas condiciones. Cada entidad está etiquetada con 4 campos, y cuando un valor se modifica el campo/valor aparecerá en negrita:
- ID del activo – Este es un identificador único para cada entidad. Se llena cuando se crea la entidad.
- Fecha modificada – Este es el campo de seguimiento del editor mantenido por la geodatabase.
- Nombre de la subred – Este es el campo del nombre de la subred mantenido por la red eléctrica.
- Región de red – Este campo es mantenido por una regla de atributos que usa el nombre de la subred para obtener un valor 'región' desde una tabla auxiliar.
Nota: Si ninguna regla de atributos requiere usar información desde la subred, entonces todas las reglas pueden configurarse para no activarse en actualizaciones hechas durante actualizar subred para mitigar un impacto en el rendimiento causado por reglas durante actualizar subred.
Actualizar sin eventing en default
El primer ejemplo que veremos es algo que todo proyecto hace al menos una vez. Ejecutar actualizar subred en la versión default en una base nueva. En este caso, todos los campos del nombre de la subred tienen el valor 'Unknown' y el resto tienen sus valores iniciales desde la carga. Puede ver un ejemplo gráfico abajo.
Figura 1 Estado inicial base datos
Después de ejecutar actualizar subred en Red A, podemos ver que el campo nombre subred ha sido actualizado en todas las entidades dentro de esa subred, pero seguimiento del editor y reglas no fueron activadas durante estas actualizaciones. Si alguna clase tuviera anotación vinculada a entidad, esta tampoco sería modificada durante este evento.
Figura 2 Actualizar subred en default sin eventing
Ahora comparemos esto con cómo se comportaría el sistema si realizamos la misma acción pero con el modo establecido a con eventing.
Actualizar con eventing en default
Cuando la red eléctrica está configurada para actualizar una subred con eventing significa que todos los comportamientos del geodatabase serán activados cuando actualizar subred actualice atributos en una entidad. Si el ejemplo anterior se ejecutara con eventing, los resultados serían como el diagrama abajo.
Figura 3 Actualizar subred en default con eventing
Puede ver que además de llenar el campo nombre subred, también se actualizó el campo Última Modificación por seguimiento del editor y el campo Área Operativa fue actualizado por nuestra regla. Además, si hubiera anotaciones vinculadas a entidad referenciando estos campos serían actualizadas.
Sin embargo, todos estos disparadores y actualizaciones adicionales tienen un costo en rendimiento. Por lo tanto, si tiene muchas reglas y/o clases con anotación vinculada debe considerar cuidadosamente el impacto en su sistema.
Actualizar sin eventing en versión nombrada
La situación más interesante es ver cómo se comporta actualizar subred cuando se ejecuta sin eventing en una versión nombrada. Este es el comportamiento predeterminado porque es más eficiente.Cuando actualizar subred se ejecuta sin eventing en una versión tiene la desventaja que no puede actualizar información sobre la subred en entidades que no hayan sido editadas ya en esa versión. Si no le gusta este comportamiento mostrado aquí recuerde que introdujimos una nueva opción para superar estas limitaciones discutida en la siguiente sección (Actualizar con eventing en versión nombrada).
Para discutir completamente este tema consideraremos dos ejemplos donde ejecutar actualizar subred en versión puede producir resultados inesperados. Vale notar que aunque la herramienta pueda no producir resultados esperados bajo todas condiciones dentro una versión, producirá resultados correctos después que esa versión sea publicada a default y ejecutar actualizar subred ahí.
Entidades recién creadas
Nuestro primer ejemplo construye sobre el anterior. Supongamos tenemos una base sin información poblada sobre subnetworks y antes ejecutar actualizar subred en default decidimos crear una nueva versión nombrada y agregar un nuevo servicio ahí. Aquí hay un gráfico mostrando nuestras nuevas entidades creadas antes ejecutar actualizar subred:
Figura 4 Nuevas entidades creadas en versión nombrada
Después ejecutar actualizar subred sin eventing en versión nombrada notará algo curioso.Solo las entidades creadas dentro esta versión obtienen su nombre poblado para la subred.
Figura 5 Actualizar nuevas entidades en versión nombrada sin eventing
Cuando actualizar subred corre sin eventing dentro una versión nombrada solo puede actualizar entidades creadas o editadas dentro esa versión. Esto es porque si la entidad aún no ha sido modificada dentro esa versión requeriría activar un evento geodatabase para insertar esa edición dentro la versión.
Entidades existentes
Para nuestro siguiente ejemplo veremos otro caso práctico donde ejecutar actualizar subred sin eventing dentro una versión nombrada puede producir resultados inesperados. En este ejemplo veremos cómo responderá actualizar subred ante una edición donde entidades cambian entre subnetworks.
Comenzamos con dos subnetworks (Red A y Red 
) separadas por un dispositivo enlace (interruptor abierto, válvula cerrada, etc.). Todas las subnetworks han sido actualizadas dentro default así todos atributos están correctamente poblados. Note que porque un dispositivo enlace pertenece a múltiples subnetworks, el campo nombre está delimitado por punto y coma.
Figura 6 Dos subnetworks en default
En este ejemplo cambiaremos dispositivo enlace entre subnetworks desde dispositivo 3 a dispositivo 1. Esto ocurre frecuentemente cuando circuitos o zonas presión son reconfiguradas para cambios temporales o estacionales demanda clientes. Para esto cambiamos estado dispositivos indicando nuevo estado abierto/cerrado así dispositivo 1 ahora es enlace y dispositivo 3 ya no actúa como barrera.
Figura 7 Dispositivo enlace actualizado
Vemos estos cambios reflejados arriba porque indicador dispositivo enlace pasó del dispositivo 3 al 1; fecha última modificación fue actualizada; además coloreamos entidades visualmente indicando a qué subnetwork pertenecen si trazara cada red. Los nombres siguen mostrando valores antiguos porque no hemos corrido actualizar subred aún. Abajo verá diagrama mostrando todos cambios atributo ocurridos al correr actualizar bajo estas condiciones.
Figura 8 Subnetwork actualizada en versión nombrada
Como esperado vemos que campo nombre está actualizado solo para dispositivos editados dentro esta versión.Sin embargo, las entidades conectadas antes a Red A pero ahora conectadas a Red B aún muestran valores antiguos para nombre y área operativa. Debido a que estas características no fueron editadas en esta actualización de versión, subnetwork no puede editarlas sin activar eventos de edición.
Ambos ejemplos destacan las limitaciones de actualizar subnetworks en versiones nombradas sin eventos. Para muchos clientes, estas limitaciones son aceptables debido a los beneficios de rendimiento de este modo de edición, y porque los datos aparecerán correctamente una vez que se hayan publicado en default y se ejecute update subnetwork donde todos pueden ver los resultados. Sin embargo, otros clientes estaban dispuestos a aceptar que update subnetwork tardara más en ejecutarse para cumplir con ciertos requisitos comerciales. Por eso introdujimos la capacidad de update subnetwork para editar con eventos como discutiremos en la siguiente sección.
Actualizar con eventos en una versión nombrada
Volvamos a examinar los dos escenarios anteriores pero veamos cómo se comportan al actualizar el subnetwork en una versión nombrada cuando el nivel está configurado para tener un modo de edición con eventos.
Características recién creadas
A continuación podemos ver el primer ejemplo, donde hay una mezcla de características existentes y nuevas que necesitan ser actualizadas.
Figura 9 Nuevas características en una versión
Y el siguiente es el resultado después de ejecutar update subnetwork con eventos.
Figura 10 Update subnetwork con eventos en versión nombrada
Como puede ver, todas las características tienen el nombre correcto del subnetwork y el área operativa correcta. La red tardará más en procesarse porque está editando más características y porque cada característica activará ediciones adicionales para manejar el seguimiento del editor, reglas de atributos, etc.
Características existentes
A continuación, veamos el segundo ejemplo donde reconfiguramos varios subnetworks. A continuación están los datos antes de ejecutar update subnetwork.
Figura 11 Características en una versión antes de actualizar subnetwork
Y a continuación está el estado de las características después de ejecutar update subnetwork en una versión nombrada con eventos.
Figura 12 Nuevas características en una versión
Una vez más, puede ver que todos los atributos en la característica tienen los valores correctos. Vale la pena señalar que esto tomará más tiempo que realizar la misma operación sin eventos. Aún así, la cantidad de tiempo que toma estará directamente relacionada con el número/complejidad de reglas de atributos que haya configurado en sus características junto con el número de relaciones que tenga con mensajería habilitada (incluida la anotación vinculada a características). Vale la pena medir y considerar estos costos de rendimiento con la importancia de la inspección visual/revisión de atributos de la información de la red durante su proceso de aseguramiento de calidad.
Configuración
Ahora que ha visto cómo funcionan estos comportamientos, veamos cómo se configuran en una utility network. Estas opciones se configuran usando la herramienta Set Subnetwork Definition. Debido a que esta herramienta le permite modificar la configuración para un nivel específico en su red, esto significa que puede definir diferentes comportamientos para cada nivel (por ejemplo, System y Pressure). Aunque es bueno tener la opción de tener diferentes comportamientos para cada nivel, la mayoría de los clientes prefieren que todos sus niveles se comporten igual para garantizar flujos de trabajo consistentes para los editores.
Al establecer el modo de edición para su definición de subnetwork hay dos campos diferentes, cada uno con dos opciones diferentes. Esto significa que hay cuatro combinaciones de valores que puede configurar para sus modos de edición:
- Sin eventos en default, sin eventos en versiones nombradas (predeterminado)
- Sin eventos en default, con eventos en versiones nombradas
- Con eventos en default, con eventos en versiones nombradas
- Con eventos en default, sin eventos en versiones nombradas
Antes de que pase demasiado tiempo preocupándose por cuál de estas cuatro opciones debe seleccionar, debe saber que los modelos de datos base utility network proporcionados por Esri ya tienen sus modos de edición configurados. Cada uno de estos modelos tiene un conjunto recomendado de configuraciones desarrolladas por expertos del sector junto con su comunidad para tener una configuración que atraiga al conjunto más amplio posible de flujos de trabajo para esa industria.
Aunque estas configuraciones satisfacen las necesidades de la mayoría de los clientes, siempre es buena idea revisar estas configuraciones dentro del contexto de sus requisitos comerciales y cualquier cambio en configuración/modelo de datos que haya realizado para asegurarse de que la configuración típica sigue siendo la más apropiada.
Mejores prácticas
La pregunta más común que me hacen es cuál es la mejor práctica para configurar su modo de edición en utility network? No hay una única respuesta a esta pregunta que funcione para todos los clientes. Sin embargo, hay varios criterios a considerar que pueden ayudarle a decidir qué opción es más apropiada para usted. Estas consideraciones generalmente caen en tres categorías diferentes: flujo de trabajo, anotación y reglas de atributos.
La primera consideración es su flujo de trabajo con edición versionada. Si su flujo requiere realizar aseguramiento de calidad en versiones nombradas, y este proceso incluye usar herramientas o capas que dependen de los atributos almacenados en las características (nombre del subnetwork, valores propagados, etc.) entonces querrá configurar su modo edición para versiones nombradas como “Con Eventos”. Esto asegura que los campos del subnetwork siempre estén poblados correctamente para todas las características en su versión para que puedan usarse para aseguramiento de calidad. Si su proceso QA puede realizarse completamente en default, o su proceso QA puede usar trazado en lugar de depender atributos característicos, entonces puede configurar su modo edición para versiones nombradas como “Sin Eventos”.
La segunda consideración es si tiene anotación vinculada a características. Si no tiene anotación vinculada a características o expresiones anotativas que no incluyen información del subnetwork (nombre del subnetwork, valores propagados, etc.), entonces cualquiera opción del modo edición es apropiada para usted. Las clases relación con mensajería activada, como las clases anotativas vinculadas a características, sí tienen un costo asociado al rendimiento durante la edición que deberá monitorear cuidadosamente. Sin embargo, más importante aún es si su anotación vinculada a características incluye información sobre el subnetwork; tendrá algunas decisiones que tomar. Almacenar información del subnetwork en clases anotativas no se considera una mejor práctica debido a la naturaleza estática de la anotación, la naturaleza dinámica del subnetwork y el costo del rendimiento al mantener ambos sincronizados. Debería considerar reemplazar estas características anotativas vinculadas por etiquetas. Sin embargo, si esto es un requisito estricto entonces deberá configurar su modo edición como “Con Eventos” tanto para versiones nombradas como default para asegurar que el texto en su anotación se actualice cuando se ejecute update subnetwork pero tenga presente que esto impactará el rendimiento del update subnetwork.
La tercera cosa a considerar son las reglas de atributos que ha definido sobre sus características utility network. Cualquier regla atributo configurada para dispararse al actualizar será evaluada cada vez que esa característica sea actualizada, independientemente del campo al cual esté asignada. Esto significa que si usa el modo edición con eventos, todas las reglas cálculo inmediatas se dispararán durante update subnetwork sobre cualquier característica actualizada. Si esto es un requisito estricto y está dispuesto a aceptar el costo del rendimiento debe revisar sus reglas atributo para asegurarse estén escritas con lógica salida temprana durante update subnetwork para minimizar este costo. Si tiene reglas atributo que dependen responder cambios a campos del subnetwork debe saber que esto no se considera mejor práctica. Sin embargo si esto es un requisito estricto debe configurar su modo edición como “Con Eventos” para asegurar que la regla atributo se dispare durante update subnetwork.
Con estas consideraciones presentes revisemos las cuatro opciones y veamos dónde son más apropiadas.
Sin eventos en default y sin eventos en versiones nombradas. Esta opción es el comportamiento predeterminado del sistema. Le da mayor rendimiento pero tiene limitaciones alrededor actualizar características en versiones y anotación vinculada a características.
Sin eventos en default y con eventosa0en versiones nombradas. Esta opción equilibra rendimiento y funcionalidad. Le da mejor rendimiento mientras actualiza subnetwork en default y mejor experiencia aseguramiento calidad en versión nombrada.
Con eventos en default y con eventos en versiones nombradas. Esta opción provee mayor funcionalidad pero también tiene mayor costo rendimiento. Si implementa esta configuración debería revisar cualquier regla atributo configurada para ejecutarse cuando las características son modificadas para asegurar estén configuradas con salida temprana durante update subnetwork.
Con eventos en default y sin eventos en versiones nombradas. Esta es configuración menos común. Es para clientes quienes tienen anotación o reglas atributo necesitan ejecutar solo en default pero no versiones.
Conclusión
Ahora que ha leído este artículo debería entender pros/contras diferentes modos edición usados para gestión subnetwork y debería poder determinar qué modos son apropiados para su modelo datos, flujos edición y requisitos comerciales.
Si desea aprender cómo mitigar impactos rendimiento eventos edición sobre reglas atributo lea el artículo Campos Desencadenantes Regla Atributo.
Si desea aprender más sobre gestión subnetwork o probar algunos tutoriales prácticos puede encontrar ejemplos específicos industria sobre la serie aprendizaje Introducción a ArcGIS Utility Network.
Si desea más detalles e inmersiones profundas sobre capacidades gestión subnetwork utility network recomiendo revisar otros artículos técnicos sobre la página comunidad Esri ArcGIS Utility Network. Esri.
