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.
Gestionar subredes a menudo implica realizar cientos o miles de ediciones en entidades cuando se crea o reconfigura una subred. Debido a esto, el sistema ofrece varios modos de edición diferentes que se pueden usar para hacer estas actualizaciones. Puedes encontrar más información sobre este tema en el tema de Subredes en la ayuda en línea.
Al leer este artículo entenderás el impacto que esta configuración tiene en el rendimiento de actualizar subred y por qué, para ciertos flujos de trabajo, podrías querer habilitar eventing aunque afecte 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 administran 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, activar reglas de atributos, enviar mensajes sobre cambios a objetos relacionados y actualizar anotaciones vinculadas a entidades.
¿Qué tiene que ver esto 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 se edita, 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 estos eventos, reglas y relaciones añaden tiempo adicional al proceso actualizar subred.
Para manejar esta situación, los administradores pueden configurar los niveles (tiers) en su red para usar un modo de edición que utilice los eventos normales de geodatabase (con eventing) o que omita el modelo normal de eventos de geodatabase (sin eventing) al gestionar subredes en ese nivel. Al final de este artículo hay una breve discusión sobre cómo evaluar requisitos comerciales y mejores prácticas para tomar esta decisión. Además, también puedes 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, observaremos cómo responde un conjunto de entidades 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 la 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 de datos. Puedes ver un ejemplo gráfico abajo.
Figura 1 Estado inicial de la base
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 no se activaron seguimiento del editor ni reglas durante estas actualizaciones. Si alguna clase tuviera anotación vinculada a entidades, 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 realizáramos 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 modifique 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
Puedes 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 entidades que referencian uno o más campos serían actualizadas.
Sin embargo, todos estos disparadores y actualizaciones adicionales tienen un costo en rendimiento. Por lo tanto, si tienes muchas reglas y/o clases con anotación vinculada deberías considerar cuidadosamente su impacto en tu sistema.
Actualizar sin eventing en una versión nombrada
La situación más interesante es observar cómo se comporta actualizar subred cuando se ejecuta sin eventing en una versión nombrada. Este es el comportamiento predeterminado porque es el más eficiente.Cuando actualizar subred se ejecuta sin eventing en una versión tiene la desventaja de no poder actualizar información sobre la subred en entidades que no fueron editadas previamente en esa versión. Si no te gusta este comportamiento mostrado aquí recuerda que introdujimos una nueva opción para superar estas limitaciones discutida en la siguiente sección (Actualizar con eventing en una versión nombrada).
Para discutir completamente este tema consideraremos dos ejemplos donde ejecutar actualizar subred en una versión puede producir resultados inesperados. Vale aclarar que aunque la herramienta pueda no producir resultados esperados bajo todas las condiciones dentro de una versión, producirá resultados correctos una vez publicada esa versión a default y ejecutado actualizar subred allí.
Entidades recién creadas
Nuestro primer ejemplo amplía el anterior. Supongamos tenemos una base sin información poblada sobre subredes y antes ejecutar actualizar subred en default decidimos crear una nueva versión nombrada y agregar un nuevo servicio allí. Aquí hay un gráfico con 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 esa versión notarás algo curioso.Solo las entidades creadas dentro de esta versión tienen su nombre poblado con la subred.
Figura 5 Actualizar nuevas entidades sin eventing en versión nombrada
Cuando actualizar subred corre sin eventing dentro de una versión nombrada solo puede modificar entidades creadas o editadas dentro esa versión. Esto ocurre porque si la entidad aún no fue modificada dentro esa versión requeriría activar un evento geodatabase para insertar esa edición dentro dela versión.
Entidades existentes
En nuestro siguiente ejemplo veremos otro caso práctico donde ejecutar actualizar subred sin eventing dentro una versión nombrada puede producir resultados inesperados. Observaremos cómo responde actualizar subred ante una edición donde entidades cambian entre dos subnetworks distintas.
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 la versión default así que todos los atributos están correctamente poblados. Nota 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 el dispositivo enlace entre las subnetworks desde dispositivo 3 a dispositivo 1. Esto ocurre frecuentemente cuando circuitos o zonas presurizadas son reconfiguradas para cambios estacionales o permanentes en demanda del cliente. Para hacer esto cambiamos estado estos dos dispositivos indicando su nuevo estado abierto/cerrado para que Dispositivo 1 sea ahora enlace y Dispositivo 3 ya no actúe como barrera.
Figura 7 Dispositivo enlace actualizado
Vemos estos cambios reflejados porque indicador enlace pasó del Dispositivo 3 al Dispositivo 1; fecha última modificación fue actualizada; y coloreamos las entidades para indicar visualmente a qué red pertenecen si trazas cada red individualmente. Los nombres siguen mostrando valores antiguos porque aún no hemos corrido actualizar subred. Abajo verás diagrama mostrando todos cambios atributivos 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 mantienen valores antiguos tanto nombre como área operativa. Porque estas entidades no fueron editadas dentro esta versión actualizar no puede modificarlas sin activar eventos.
Ambos ejemplos destacan las limitaciones de actualizar subredes en versiones nombradas sin eventing. 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 ello, introdujimos la capacidad de actualizar subredes para editar con eventing como discutiremos en la siguiente sección.
Actualizar con eventing en una versión nombrada
Volvamos a examinar los dos escenarios anteriores pero veamos cómo se comportan al actualizar la subred en una versión nombrada cuando el nivel está configurado para tener un modo de edición con eventing.
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 eventing.
Figura 10 Actualizar subred con eventing en versión nombrada
Como puede ver, todas las características tienen el nombre correcto de la subred 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 varias subredes. A continuación están los datos antes de ejecutar update subnetwork.
Figura 11 Características en una versión antes de actualizar la subred
Y a continuación está el estado de las características después de ejecutar update subnetwork en una versión nombrada con eventing.
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 mencionar que esto tomará más tiempo que realizar la misma operación sin eventing. Aún así, el tiempo que toma estará directamente relacionado 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 red 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 asegurar flujos de trabajo consistentes para los editores.
Al establecer el modo de edición para su definición de subred 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 eventing en default, sin eventing en versiones nombradas (predeterminado)
- Sin eventing en default, con eventing en versiones nombradas
- Con eventing en default, con eventing en versiones nombradas
- Con eventing en default, sin eventing en versiones nombradas
Antes de que dedique 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 realizado en configuración/modelo de datos para asegurar que la configuración típica sigue siendo la más adecuada.
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 típicamente caen en tres categorías diferentes: flujo de trabajo, anotación y reglas de atributos.
La primera consideración es su flujo de trabajo versioned editing workflow. 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 subred, valores propagados, etc.) entonces querrá configurar su modo edición para versiones nombradas como “With Eventing”. Esto asegura que los campos subnetwork siempre estén correctamente poblados para todas las características en su versión para poder usarlos durante aseguramiento de calidad. Si su proceso QA puede realizarse completamente en default o puede usar trazado en lugar de depender atributos feature, entonces puede configurar su modo edición para versiones nombradas como “Without Eventing”.
La segunda consideración es si tiene feature-linked annotation. Si no tiene feature-linked annotation o expresiones anotación que no incluyan información sobre la subred (nombre subred, valores propagados, etc.), entonces cualquiera opción modo edición es apropiada para usted. Las clases relación con mensajería activada, como las clases feature-linked annotation, sí tienen un costo rendimiento asociado a editar que deberá monitorear cuidadosamente. Sin embargo, más importante aún es si su feature-linked annotation incluye información sobre la subred; tendrá decisiones que tomar. Almacenar información subred en clases anotación no se considera una mejor práctica debido a la naturaleza estática anotación y naturaleza dinámica subredes y costo rendimiento mantener ambos sincronizados. Debe considerar reemplazar estas características feature-linked annotation por etiquetas. Sin embargo, si esto es un requisito estricto deberá configurar su modo edición como “With Eventing” tanto para versiones nombradas como default para asegurar que el texto anotación se actualice cuando se ejecute update subnetwork pero tenga presente que esto impactará el rendimiento update subnetwork.
La tercera cosa a considerar son las reglas atributo attribute rules que haya 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 asignado. Esto significa que si usa modo edición with eventing, todas las reglas cálculo inmediato se dispararán durante update subnetwork sobre cualquier característica actualizada. Si esto es un requisito estricto y está dispuesto a aceptar costo rendimiento debe revisar sus reglas atributo para asegurar estén escritas con lógica salida temprana durante update subnetwork para minimizar este costo rendimiento. Si tiene reglas atributo basadas responder cambios campos subnetwork debe saber que esto no se considera mejor práctica. Sin embargo si esto es requisito estricto debe configurar modo edición “With Eventing” para asegurar regla atributo se dispare durante update subnetwork.
Con estas consideraciones presentes revisemos las cuatro opciones y veamos dónde son más apropiadas.
Sin eventing en default y sin eventing en versiones nombradas. Esta opción es comportamiento predeterminado sistema. Le da mayor rendimiento pero tiene limitaciones al actualizar características en versiones y feature-linked annotation.
Sin eventing en default y con eventing en versiones nombradas. Esta opción equilibra rendimiento y funcionalidad. Le da mejor rendimiento al actualizar subred en default y mejor experiencia aseguramiento calidad versión nombrada.
Con eventing en default y con eventing en versiones nombradas. Esta opción ofrece mayor funcionalidad pero también mayor costo rendimiento. Si implementa esta configuración debe revisar reglas atributo configuradas para ejecutarse cuando características modificadas asegurando lógica salida temprana durante update subnetwork.
Con eventing en default y sin eventing en versiones nombradas. Esta es configuración menos común. Es para clientes con anotación o reglas atributo necesarias 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 gestión subredes y debería poder determinar qué modos son apropiados para su modelo datos flujos trabajo edición y requisitos comerciales.
Si desea aprender cómo mitigar impactos rendimiento eventos edición sobre reglas atributo lea el artículo Attribute Rule Triggering Fields.
Si desea aprender más sobre gestión subred o probar tutoriales prácticos puede encontrar ejemplos específicos industria en la serie aprendizaje Getting Started with ArcGIS Utility Network.
Si desea más detalles e inmersiones profundas sobre capacidades gestión subred utility network recomiendo revisar otros artículos técnicos página comunidad ArcGIS Utility Network. Esri
