Atualização: ArcGIS Pro 3.4/ArcGIS Enterprise 11.4 introduziu Campos de Disparo que afeta a discussão sobre como mitigar os impactos da edição com eventos.
Bem-vindo à série de entendimento da gestão de subnetwork, onde mergulhamos em alguns dos tópicos mais avançados da gestão de subnetwork. Se você não está familiarizado com o que são subnetworks ou como elas funcionam, recomendo que leia os artigos e tutoriais na Gerenciando Subnetworks com ArcGIS Utility Network learn series para começar.
Gerenciar subnetworks muitas vezes envolve fazer centenas ou milhares de edições em feições quando uma subnetwork é criada ou reconfigurada. Por causa disso, o sistema oferece vários modos de edição diferentes que podem ser usados para fazer essas atualizações.
Ao ler este artigo, você entenderá o impacto que essa configuração tem no desempenho da atualização da subnetwork e por que, para certos fluxos de trabalho, você pode querer habilitar eventing mesmo que isso impacte o desempenho.
O que é um modo de edição?
O que é um modo de edição? No ArcGIS Utility Network, o modo de edição refere-se a como o software gerenciará os campos do sistema nas feições quando as subnetworks são gerenciadas. Atualmente existem duas opções para modos de edição, com eventing ou sem eventing.
A que "eventing" nos referimos quando dizemos que estamos gerenciando dados com eventing ou sem eventing? Quando dizemos eventing, estamos nos referindo especificamente a eventos da geodatabase que são acionados em resposta a edições. Eventos da geodatabase são uma das formas pelas quais o ArcGIS dispara comportamentos especiais quando objetos em uma geodatabase são editados. Exemplos comuns disso são comportamentos como preencher campos de rastreamento do editor, disparar regras de atributo, enviar mensagens sobre mudanças para objetos relacionados e atualizar anotações vinculadas a feições.
O que isso tem a ver com as subnetworks? Uma das ferramentas que os usuários costumam executar como parte do seu fluxo de trabalho de edição é a ferramenta update subnetwork. Esta ferramenta é responsável por gerenciar campos do sistema nas feições da utility network que descrevem a subnetwork na qual elas participam. À medida que cada uma dessas feições é editada, ela dispara diferentes eventos de edição. Modelos de dados que incluem relacionamentos ou regras de atributo dispararão mais eventos durante update subnetwork do que modelos de dados com menos relacionamentos e regras de atributo. Todos esses eventos, regras e relacionamentos adicionam tempo adicional ao processo update subnetwork.
Para lidar com essa situação, os administradores podem configurar os tiers em sua rede para usar um modo de edição que utilize os eventos normais da geodatabase (com eventing) ou ignore o modelo normal de eventos da geodatabase (sem eventing) ao gerenciar subnetworks nesse tier. Há uma breve discussão sobre como avaliar requisitos comerciais e melhores práticas para tomar essa decisão no final deste artigo. Além disso, você também pode usar triggering fields para controlar exatamente a quais edições as regras de atributo respondem para mitigar os impactos dos eventos de edição durante update subnetwork.
Mas por enquanto, vamos olhar alguns exemplos de diferentes configurações. Em cada exemplo, veremos como um conjunto de feições responde sob certas condições. Cada feição é rotulada com 4 campos, e quando um valor é modificado o campo/valor aparecerá em negrito:
- Asset ID – Este é um identificador único para cada feição. Ele é preenchido quando a feição é criada.
- Date Modified – Este é o campo de rastreamento do editor mantido pela geodatabase.
- Subnetwork Name – Este é o campo do nome da subnetwork mantido pela utility network.
- Network Region – Este campo é mantido por uma regra de atributo que usa o nome da subnetwork da feição para recuperar um valor 'região' a partir de uma tabela de consulta.
Nota: Se nenhuma das regras de atributo exigir usar informações da subnetwork, então todas as regras de atributo podem ser configuradas para não disparar em atualizações feitas durante update subnetwork para mitigar um impacto no desempenho durante update subnetwork causado por regras de atributo.
Atualização sem eventing no default
O primeiro exemplo que veremos é algo que todo projeto faz pelo menos uma vez. Executar update subnetwork na versão default em um banco de dados novo em folha. Neste caso, todos os campos do nome da subnetwork no banco têm o valor 'Unknown' e o resto dos campos têm seus valores iniciais da carga dos dados. Você pode ver um exemplo disso no gráfico abaixo.
Figura 1 Estado inicial do banco de dados
Após executar update subnetwork na Network A, podemos ver que o campo do nome da subnetwork foi atualizado em todas as feições na subnetwork, mas o rastreamento do editor e as regras de atributo não foram disparados durante essas atualizações. Se alguma das nossas classes tivesse anotações vinculadas a feições, as anotações também não seriam modificadas durante este evento.
Figura 2 Update subnetwork no default sem eventing
Agora, vamos comparar isso com como o sistema se comportaria se realizássemos a mesma ação mas com o modo de edição definido para com eventing.
Atualização com eventing no default
Quando a utility network está configurada para atualizar uma subnetwork com eventing isso significa que todos os comportamentos da geodatabase serão disparados quando update subnetwork atualizar os atributos em uma feição. Se o exemplo anterior fosse executado com eventing, os resultados seriam como no diagrama abaixo.
Figura 3 Update subnetwork no default com eventing
Você pode ver que além de preencher o campo do nome da subnetwork, o campo Last Modified também foi atualizado pelo rastreamento do editor, e o campo Operating Area foi atualizado pela nossa regra de atributo. Além disso, se houvesse anotações vinculadas a feições que referenciam um ou mais desses campos, elas seriam atualizadas.
No entanto, todos esses gatilhos e atualizações adicionais têm um custo em desempenho. Portanto, se você tiver muitas regras de atributo e/ou classes de anotações vinculadas a feições deve pensar cuidadosamente sobre o impacto que isso terá no seu sistema.
Atualização sem eventing em uma versão nomeada
A situação mais interessante é observar como update subnetwork se comporta quando executado em uma versão nomeada sem eventing. Este é o comportamento padrão do sistema porque é o mais performático.Quando update subnetwork é executado em uma versão sem eventing, isso tem a desvantagem de não poder atualizar as informações da subnetwork nas feições que ainda não foram editadas na versão. Se você não gostar do comportamento visto nesses exemplos, lembre-se que introduzimos uma nova opção para superar essas limitações discutidas na próxima seção (Update with eventing in a named version).
Para garantir que discutamos completamente essa questão consideraremos dois exemplos separados onde executar update subnetwork em uma versão pode produzir resultados inesperados. Vale notar que mesmo que a ferramenta possa não produzir os resultados esperados em uma versão sob todas as condições, ela produzirá o resultado correto assim que a versão for postada na versão default e executar update subnetwork no default.
Feições recém-criadas
Nosso primeiro exemplo baseia-se no nosso exemplo anterior. Vamos supor que temos um banco de dados sem informações populadas da subnetwork e antes de executar update subnetwork no default decidimos criar uma nova versão nomeada e adicionar um novo serviço nessa versão. Aqui está um gráfico das nossas feições recém-criadas na nossa versão antes de executar update subnetwork:
Figura 4 Novas feições criadas em uma versão nomeada
Após executar update subnetwork sem eventing na versão nomeada, você notará algo curioso.Apenas as feições criadas nesta versão têm seu nome da subnetwork populado.
Figura 5 Atualizar novas feições em uma versão nomeada sem eventing
Quando update subnetwork roda sem eventing em uma versão nomeada ele só pode atualizar feições que foram criadas ou editadas na versão. Isso porque se a feição ainda não foi modificada na versão seria necessário disparar um evento da geodatabase para inserir a edição na versão.
Feições existentes
Para nosso próximo exemplo, veremos outro exemplo prático sobre como executar update subnetwork sem eventing em uma versão nomeada pode produzir resultados inesperados. Para este exemplo veremos como update subnetwork responde a uma edição que resulta na mudança das feições de uma subnetwork para outra.
Começamos com duas subnetworks (Network A e Network 
) separadas por um dispositivo tie (interruptor aberto, válvula fechada etc.). Todas as subnetworks foram atualizadas na versão default, então todos os atributos estão devidamente populados. Note que porque um dispositivo tie pertence a múltiplas subnetworks, o campo do nome da subnetwork é delimitado por ponto e vírgula.
Figura 6 Duas subnetworks no default
Neste exemplo mudaremos o dispositivo tie entre as subnetworks do dispositivo 3 para o dispositivo 1. Isso acontece frequentemente no mundo real conforme circuitos, zonas de pressão etc., são reconfigurados para considerar mudanças longas ou até sazonais na demanda dos clientes. Para fazer isso mudamos o status desses dois dispositivos para indicar seu novo status aberto/fechado para que Dispositivo 1 seja agora um dispositivo tie e Dispositivo 3 não atue mais como barreira.
Figura 7 Dispositivo tie atualizado
Vemos essas mudanças refletidas no diagrama acima porque o indicador do dispositivo tie mudou do Dispositivo 3 para o Dispositivo 1, a data da última modificação foi atualizada e atualizamos a coloração nas feições para indicar visualmente a qual subnetwork pertencem se você fosse traçar cada subnetwork. Os nomes das subnetworks ainda mostram seus valores antigos porque não executamos update subnetwork ainda. Abaixo você verá um diagrama mostrando todas as mudanças nos atributos que ocorrerão quando update subnetwork for executado nessas condições.
Figura 8 Subnetwork atualizada em versão nomeada
Como esperado vemos que o campo do nome da subnetwork nos dois dispositivos editados nesta versão foi atualizado.No entanto as feições conectadas à Network A mas agora conectadas à Network B ainda possuem os valores antigos dos campos nome da subnetwork e operating area. Porque esses recursos não foram editados nesta atualização de versão, o subnetwork não pode editá-los sem acionar eventos de edição.
Ambos os exemplos destacam as limitações de atualizar subnetworks em versões nomeadas sem eventos. Para muitos clientes, essas limitações são aceitáveis devido aos benefícios de desempenho desse modo de edição e porque os dados aparecerão corretamente uma vez que os dados tenham sido postados para o padrão e o update subnetwork seja executado onde todos podem ver os resultados. No entanto, outros clientes estavam dispostos a aceitar que o update subnetwork demorasse mais para ser executado a fim de atender a certos requisitos comerciais. Por isso, introduzimos a capacidade de update subnetwork para editar com eventoscomo discutiremos na próxima seção.
Atualizar com eventos em uma versão nomeada
Vamos reexaminar os dois cenários acima, mas observar como eles se comportam ao atualizar o subnetwork em uma versão nomeada quando o tier está configurado para ter um modo de edição com eventos.
Recursos recém-criados
Abaixo podemos ver o primeiro exemplo, onde há uma mistura de recursos existentes e novos que precisam ser atualizados.
Figura 9 Novos recursos em uma versão
E o seguinte é o resultado após executar update subnetwork com eventos.
Figura 10 Atualizar subnetwork com eventos em versão nomeada
Como você pode ver, todos os recursos têm o nome correto do subnetwork e a área operacional correta. A rede levará mais tempo para processar porque está editando mais recursos e porque cada recurso acionará edições adicionais para lidar com editor tracking, regras de atributo, etc.
Recursos existentes
Em seguida, vamos olhar o segundo exemplo onde reconfiguramos vários subnetworks. Abaixo estão os dados antes de executar update subnetwork.
Figura 11 Recursos em uma versão antes de atualizar o subnetwork
E abaixo está o status dos recursos após executar update subnetwork em uma versão nomeada com eventos.
Figura 12 Novos recursos em uma versão
Mais uma vez, você pode ver que todos os atributos no recurso têm os valores corretos. Vale ressaltar que isso levará mais tempo do que realizar a mesma operação sem eventos. Ainda assim, o tempo que leva estará diretamente relacionado ao número/complexidade das regras de atributo que você configurou em seus recursos junto com o número de relacionamentos que você tem com mensagens ativadas (incluindo feature-linked annotation). Vale a pena medir e considerar esses custos de desempenho com a importância da inspeção visual/revisão de atributos das informações da rede durante seu processo de garantia de qualidade.
Configuração
Agora que você viu como esses comportamentos funcionam, vamos ver como eles são configurados em uma utility network. Essas opções são configuradas usando a ferramenta Set Subnetwork Definition. Como essa ferramenta permite modificar a configuração para um tier específico na sua rede, isso significa que você pode definir comportamentos diferentes para cada tier (por exemplo, System e Pressure). Embora seja bom ter a opção de ter comportamentos diferentes para cada tier, a maioria dos clientes prefere que todos os seus tiers se comportem da mesma maneira para garantir fluxos de trabalho consistentes para editores.
Ao definir o modo de edição para sua definição de subnetwork, existem dois campos diferentes, cada um com duas opções diferentes. Isso significa que existem quatro combinações de valores que você pode configurar para seus modos de edição:
- Sem eventos no padrão, sem eventos em versões nomeadas (padrão)
- Sem eventos no padrão, com eventos em versões nomeadas
- Com eventos no padrão, com eventos em versões nomeadas
- Com eventos no padrão, sem eventos em versões nomeadas
Antes de gastar muito tempo se preocupando sobre qual dessas quatro opções você precisa selecionar, saiba que os modelos básicos de dados da utility network fornecidos pela Esri já têm seus modos de edição configurados. Cada um desses modelos de dados tem um conjunto recomendado de configurações desenvolvido por especialistas do setor, junto com sua comunidade, para ter uma configuração que atraia o maior conjunto possível de fluxos de trabalho para esse setor.
Embora essas configurações atendam à maioria das necessidades dos clientes, é sempre uma boa ideia revisar essas configurações dentro do contexto dos seus requisitos comerciais e quaisquer alterações na configuração/modelo de dados que você tenha feito para garantir que a configuração típica ainda seja a mais apropriada.
Melhores Práticas
A pergunta mais comum que recebo é qual é a melhor prática para configurar seu modo de edição na utility network? Não há uma única resposta para essa pergunta que funcione para todos os clientes. No entanto, existem vários critérios a considerar que podem ajudá-lo a decidir qual opção é mais apropriada para você. Essas considerações geralmente se enquadram em três categorias diferentes: fluxo de trabalho, annotation e regras de atributo.
A primeira consideração é seu fluxo de trabalho versioned editing. Se seu fluxo de trabalho exige que você realize garantia de qualidade em versões nomeadas e esse processo inclui usar ferramentas ou camadas que dependem dos atributos armazenados nos recursos (nome do subnetwork, valores propagados etc.), então você desejará definir seu modo de edição para versões nomeadas como "Com Eventos". Isso garante que os campos do subnetwork estejam sempre preenchidos corretamente para todos os recursos na sua versão para que possam ser usados na garantia de qualidade. Se seu processo QA puder ser realizado inteiramente no padrão ou seu processo QA puder usar tracing em vez de depender dos atributos do recurso, então você pode definir seu modo de edição para versões nomeadas como "Sem Eventos".
A segunda consideração é se você tem feature-linked annotation. Se você não tem feature-linked annotation ou expressões annotation que não incluem informações do subnetwork (nome do subnetwork, valores propagados etc.), então qualquer opção do modo de edição é apropriada para você. Classes de relacionamento com mensagens ativadas, como classes feature-linked annotation, têm um custo de desempenho associado à edição que você precisará monitorar cuidadosamente. No entanto, mais importante do que isso é se sua feature-linked annotation inclui informações sobre o subnetwork; você tem algumas decisões a tomar. Armazenar informações do subnetwork em classes annotation não é considerado uma melhor prática devido à natureza estática da annotation, à natureza dinâmica dos subnetworks e ao custo de desempenho para manter os dois sincronizados. Você deve considerar substituir esses recursos feature-linked annotation por labels. No entanto, se isso for um requisito rígido, então você precisará definir seu modo de edição como "Com Eventos" tanto para versões nomeadas quanto para padrão para garantir que o texto na sua annotation seja atualizado quando update subnetwork for executado, mas esteja ciente de que isso impactará o desempenho do update subnetwork.
A terceira coisa a considerar são as regras de atributo que você definiu nos seus recursos da utility network. Qualquer regra de atributo configurada para disparar na atualização será avaliada sempre que esse recurso for atualizado, independentemente do campo ao qual está atribuída. Isso significa que se você usar o modo de edição com eventos, todas as regras imediatas serão disparadas durante update subnetwork em quaisquer recursos atualizados. Se isso for um requisito rígido e você estiver disposto a aceitar o custo do desempenho, deve revisar suas regras de atributo para garantir que elas sejam escritas com lógica de saída antecipada durante update subnetwork para minimizar esse custo. Se você tiver regras de atributo que dependem da resposta às mudanças nos campos do subnetwork, deve saber que isso não é considerado uma melhor prática. No entanto, se isso for um requisito rígido, então precisa definir seu modo de edição como "Com Eventos" para garantir que a regra seja disparada durante update subnetwork.
Com essas considerações em mente, vamos revisar as quatro opções e ver onde elas são mais apropriadas.
Sem eventos no padrão e sem eventos em versões nomeadas. Esta opção é o comportamento padrão do sistema. Oferece melhor desempenho mas tem limitações ao atualizar recursos em versões e feature-linked annotation.
Sem eventos no padrão e com eventosem versões nomeadas. Esta opção equilibra desempenho e funcionalidade. Oferece melhor desempenho ao atualizar subnetwork no padrão e melhor experiência na garantia da qualidade em uma versão nomeada.
Com eventos no padrão e com eventos em versões nomeadas. Esta opção oferece mais funcionalidade mas também tem maior custo no desempenho. Se implementar esta configuração deve revisar quaisquer regras atribuídas configuradas para rodar quando recursos forem modificados para garantir saída antecipada durante update subnetwork.
Com eventos no padrão e sem eventos em versões nomeadas. Esta é a configuração menos comum. É destinada a clientes com annotation ou regras atribuídas necessárias apenas no padrão mas não nas versões.
Conclusão
Agora que leu este artigo deve entender os prós/contras dos diferentes modos usados na gestão do subnetwork e ser capaz determinar quais modos são adequados ao seu modelo dados fluxos trabalho requisitos comerciais.
Se quiser aprender como mitigar impactos no desempenho dos eventos nas regras atribuídas leia o artigo Campos Disparadores das Regras Atribuídas.
Se quiser aprender mais sobre gestão do subnetwork ou experimentar tutoriais práticos pode encontrar exemplos específicos da indústria na série Introdução à ArcGIS Utility Network.
Se quiser detalhes aprofundados sobre capacidades da gestão do subnetwork da utility network recomendo conferir outros artigos técnicos na página comunitária ArcGIS Utility Network. Esri
