Atualização: ArcGIS Pro 3.4/ArcGIS Enterprise 11.4 introduziu Campos de Disparo que afeta a discussão sobre mitigar os impactos da edição com eventos.
Gerenciar subredes muitas vezes envolve fazer centenas ou milhares de edições em feições quando uma subrede é 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. Você pode encontrar mais informações sobre este tópico no tópico Subnetworks na ajuda online.
Ao ler este artigo, você entenderá o impacto que essa configuração tem no desempenho da atualização da subrede 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 subredes 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 falamos em 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 incluem comportamentos como preencher campos de rastreamento do editor, disparar regras de atributo, enviar mensagens sobre alterações para objetos relacionados e atualizar anotações vinculadas a feições.
O que isso tem a ver com as subredes? Uma das ferramentas que os usuários costumam executar como parte do seu fluxo de trabalho de edição é a ferramenta update subnetwork. Essa ferramenta é responsável por gerenciar campos do sistema nas feições da utility network que descrevem a subrede na qual elas participam. À medida que cada uma dessas feições é editada, diferentes eventos de edição são acionados. Modelos de dados que incluem relacionamentos ou regras de atributo disparam mais eventos durante update subnetwork do que modelos com menos relacionamentos e regras. Todos esses eventos, regras e relacionamentos adicionam tempo extra 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 subredes 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 campos de disparo 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 está 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. É 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 subrede mantido pela utility network.
- Network Region – Este campo é mantido por uma regra de atributo que usa o nome da subrede da feição para recuperar um valor 'região' de uma tabela de consulta.
Nota: Se nenhuma das regras de atributo exigir usar informações da subrede, então todas as regras podem ser configuradas para não disparar em atualizações feitas durante update subnetwork para mitigar o impacto no desempenho causado pelas regras durante update subnetwork.
Atualizar 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. Neste caso, todos os campos do nome da subrede no banco têm o valor ‘Unknown’ e os demais campos têm seus valores iniciais do carregamento 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 Rede A, podemos ver que o campo do nome da subrede foi atualizado em todas as feições da subrede, mas rastreamento do editor e regras de atributo não foram acionados durante essas atualizações. Se alguma das nossas classes tivesse anotações vinculadas a feições, elas também não seriam modificadas durante esse 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 configurado para com eventing.
Atualizar com eventing no default
Quando a utility network está configurada para atualizar uma subrede com eventing, isso significa que todos os comportamentos da geodatabase serão acionados 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 subrede, 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 no 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 disso no seu sistema.
Atualizar 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. Esse é 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 subrede em 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 numa versão sob todas as condições, ela produzirá o resultado correto assim que a versão for postada na versão default e update subnetwork for executado no default.
Feições recém-criadas
Nosso primeiro exemplo baseia-se no exemplo anterior. Suponha que temos um banco sem informações populadas da subrede 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 subrede populado.
Figura 5 Atualizar novas feições em uma versão nomeada sem eventing
Quando update subnetwork roda sem eventing numa versão nomeada só pode atualizar feições 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
No próximo exemplo veremos outro caso prático sobre como executar update subnetwork sem eventing numa versão nomeada pode gerar resultados inesperados. Neste exemplo veremos como update subnetwork responde a uma edição que resulta na mudança das feições de uma subrede para outra.
Começamos com duas subnetworks (Rede A e Rede 
) separadas por um dispositivo tie (chave aberta, 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 subrede está 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 sazonais ou permanentes na demanda dos clientes. Para isso mudamos o status desses dois dispositivos indicando seu novo estado aberto/fechado para que Dispositivo 1 seja agora um dispositivo tie e Dispositivo 3 deixe de atuar 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 Dispositivo 1; a data da última modificação foi atualizada; e atualizamos as cores das feições para indicar visualmente a qual subrede pertencem caso você faça um traçado em cada uma delas. Os nomes das subnetworks ainda mostram seus valores antigos porque ainda não executamos update subnetwork. 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 Subnetworks atualizadas em versão nomeada
Como esperado vemos que o campo do nome da subrede nos dois dispositivos editados nesta versão foi atualizado.No entanto as feições conectadas à Rede A mas agora conectadas à Rede B ainda possuem os valores antigos dos campos nome da subrede e área operacional. Porque essas feições não foram editadas nesta versão update subnetwork não pode editá-las sem disparar eventos de edição.
Ambos os exemplos destacam as limitações de atualizar sub-redes em versões nomeadas sem eventing. 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 a atualização da sub-rede seja executada onde todos possam ver os resultados. No entanto, outros clientes estavam dispostos a aceitar que a atualização da sub-rede demorasse mais para ser executada a fim de atender a certos requisitos comerciais. Por isso, introduzimos a capacidade de atualizar sub-rede para editar com eventing como discutiremos na próxima seção.
Atualizar com eventing em uma versão nomeada
Vamos reexaminar os dois cenários acima, mas observar como eles se comportam ao atualizar a sub-rede em uma versão nomeada quando o nível está configurado para ter um modo de edição com eventing.
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 a atualização da sub-rede com eventing.
Figura 10 Atualizar sub-rede com eventing em versão nomeada
Como você pode ver, todos os recursos têm o nome correto da sub-rede e área operacional. A rede levará mais tempo para processar porque está editando mais recursos e porque cada recurso acionará edições adicionais para lidar com rastreamento do editor, regras de atributo, etc.
Recursos existentes
Em seguida, vamos olhar o segundo exemplo onde reconfiguramos várias sub-redes. Abaixo estão os dados antes de executar a atualização da sub-rede.
Figura 11 Recursos em uma versão antes de atualizar a sub-rede
E abaixo está o status dos recursos após executar a atualização da sub-rede em uma versão nomeada com eventing.
Figura 12 Novos recursos em uma versão
Mais uma vez, você pode ver que todos os atributos do recurso têm os valores corretos. Vale ressaltar que isso levará mais tempo do que realizar a mesma operação sem eventing. 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 anotação vinculada ao recurso). 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 rede utilitária. Essas opções são configuradas usando a ferramenta Definir Definição de Sub-rede. Como essa ferramenta permite modificar a configuração para um nível específico na sua rede, isso significa que você pode definir comportamentos diferentes para cada nível (por exemplo, Sistema e Pressão). Embora seja bom ter a opção de ter comportamentos diferentes para cada nível, a maioria dos clientes prefere que todos os seus níveis se comportem da mesma forma para garantir fluxos de trabalho consistentes para os editores.
Ao definir o modo de edição para sua definição de sub-rede, 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 eventing no padrão, sem eventing em versões nomeadas (padrão)
- Sem eventing no padrão, com eventing em versões nomeadas
- Com eventing no padrão, com eventing em versões nomeadas
- Com eventing no padrão, sem eventing 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 rede utilitária 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 às necessidades da maioria 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 rede utilitária? 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, anotação e regras de atributo.
A primeira consideração é seu fluxo de trabalho de edição versionada. 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 da sub-rede, valores propagados etc.), então você desejará definir seu modo de edição para versões nomeadas como “Com Eventing”. Isso garante que os campos da sub-rede 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 se seu processo QA puder usar rastreamento em vez de depender dos atributos do recurso, então você pode definir seu modo de edição para versões nomeadas como “Sem Eventing”.
A segunda consideração é se você tem anotação vinculada ao recurso. Se você não tem anotação vinculada ao recurso ou expressões de anotação que não incluem informações da sub-rede (nome da sub-rede, valores propagados etc.), então qualquer opção do modo de edição é apropriada para você. Classes de relacionamento com mensagens ativadas, como classes de anotação vinculadas ao recurso, têm um custo de desempenho associado à edição que você precisará monitorar cuidadosamente. No entanto, mais importante do que isso é se sua anotação vinculada ao recurso inclui informações sobre a sub-rede; você terá algumas decisões a tomar. Armazenar informações da sub-rede em classes de anotação não é considerado uma melhor prática devido à natureza estática da anotação, à natureza dinâmica das sub-redes e ao custo de desempenho para manter os dois sincronizados. Você deve considerar substituir esses recursos anotados vinculados por rótulos. No entanto, se isso for um requisito rígido, então você precisará definir seu modo de edição como “Com Eventing” tanto para versões nomeadas quanto para padrão para garantir que o texto na sua anotação seja atualizado quando a atualização da sub-rede for executada; mas esteja ciente que isso impactará o desempenho da atualização da sub-rede.
A terceira coisa a considerar são as regras de atributo que você definiu nos recursos da sua rede utilitária. 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 eventing, todas as regras imediatas serão disparadas durante a atualização da sub-rede 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 a atualização da sub-rede para minimizar esse custo. Se você tiver regras de atributo que dependem das mudanças nos campos da sub-rede, deve saber que isso não é considerado uma melhor prática. No entanto, se isso for um requisito rígido, então você precisa definir seu modo de edição como “Com Eventing” para garantir que a regra seja disparada durante a atualização da sub-rede.
Com essas considerações em mente, vamos revisar as quatro opções e ver onde elas são mais apropriadas.
Sem eventing no padrão e sem eventing em versões nomeadas. Esta opção é o comportamento padrão do sistema. Ela oferece o melhor desempenho mas tem limitações na atualização dos recursos nas versões e na anotação vinculada ao recurso.
Sem eventing no padrão e com eventing em versões nomeadas. Esta opção equilibra desempenho e funcionalidade. Ela oferece o melhor desempenho ao atualizar a sub-rede no padrão e a melhor experiência na garantia da qualidade em uma versão nomeada.
Com eventing no padrão e com eventing em versões nomeadas. Esta opção oferece mais funcionalidade mas também tem o maior custo em desempenho. Se implementar esta configuração, deve revisar quaisquer regras atribuídas configuradas para serem executadas quando os recursos forem modificados para garantir que estejam configuradas para fornecer saída antecipada durante a atualização da sub-rede.
Com eventing no padrão e sem eventing em versões nomeadas. Esta é a configuração menos comum. É destinada aos clientes que têm anotações ou regras atribuídas que precisam ser executadas no padrão mas não nas versões.
Conclusão
Agora que você leu este artigo deve entender os prós/contras dos diferentes modos usados para gerenciamento da sub-rede e deve ser capaz de determinar quais modos são apropriados para seu modelo de dados, fluxos de trabalho e requisitos comerciais.
Se quiser aprender como mitigar os impactos no desempenho dos eventos na edição das regras atribuídas leia o artigo Campos Disparadores das Regras Atribuídas.
Se quiser aprender mais sobre gerenciamento da sub-rede ou experimentar alguns tutoriais práticos pode encontrar exemplos específicos do setor na série Introdução à Rede Utilitária ArcGIS.
Se quiser mais detalhes e análises aprofundadas sobre as capacidades do gerenciamento da sub-rede na rede utilitária recomendo conferir alguns dos outros artigos técnicos na página comunitária ArcGIS Utility Network. Esri
