Interrompendo o transporte porque a camada necessária [DatastoreConnection][Layer Name] [LayerID] [Feature Server] não está acessível após a conclusão da sincronização

Mensagem de Erro

O seguinte erro é retornado por um conector de saída em GeoEvent Manager (https://server.domain.com:6143/geoevent/manager/index.html), se o serviço da feição for interrompido no lado do servidor (pelo ArcGIS Server):

Erro: Interrompendo o transporte porque a camada necessária [DatastoreConnection][Layer Name] [LayerID] [Feature Server] não está acessível após a conclusão da sincronização.

A saída do GeoEvent perdeu a URL necessária para fazer solicitações no ponto final REST de um serviço de feições, a saída deve permanecer em seu estado ‘Iniciado’ e não passar para um estado de ‘Erro’.

Este comportamento é esperado e parece ser uma limitação de qualquer arquitetura orientada a serviços (SOA) se um serviço externo ficar offline inesperadamente.
Dependendo do tipo de conector de entrada ou saída, é possível que o cliente HTTP usado pelo conector receba um erro HTTP/500 “servidor/serviço geral” ao fazer uma solicitação em um serviço da web externo. Uma entrada, neste caso, interrompe a consulta ou o recebimento de dados. Um conector de saída para de fazer solicitações no serviço externo para disseminar dados de registros de eventos processados.

A chave aqui é reconhecer que um portal corporativo ou serviço de feições hospedado no ArcGIS Server não se beneficia de tratamento ou manipulação especial porque está dentro do ecossistema da Esri. O GeoEvent Server trata qualquer serviço da web que está sendo pesquisado ou para o qual envia solicitações como um serviço da web externo.

Durante o período de tempo em que o conector de saída permanecer desconectado, em um estado de erro, quaisquer dados em tempo real recebidos não serão disseminados por meio do conector de saída. Os registros de eventos recebidos continuarão a ser “perdidos” à medida que são roteados para o conector de saída que não está mais conectado e em execução.

A solução para o erro inclui algumas etapas básicas de solução de problemas junto com as melhores práticas para evitar que os conectores entrem em um estado de erro e evitem a perda de dados.

Causa

O conector de saída Atualizar uma Feição muda para um estado de erro quando o ponto final REST do serviço de feição de saída está indisponível. O serviço de feição pode estar indisponível devido a:

• Uma interrupção planejada, como patch de servidor
• Proteção e manutenção da fonte de dados referenciada (Geodatabase Enterprise)
• Interrupções não planejadas, como serviço corrompido ou quando o site do ArcGIS Server está offline
• Se o serviço de feição de saída for interrompido de alguma forma (O erro pode ser replicado simplesmente interrompendo o serviço de feição do respectivo Gerenciador de Servidor/Admin.)
• O serviço de feição está sendo reciclado
• Perda de comunicação entre o servidor GeoEvent e ArcGIS Server que hospeda o serviço de feição

Isso seria esperado de um serviço que está repentinamente indisponível, porque o serviço foi interrompido (ou o ArcGIS Server foi colocado offline) e produziria um erro HTTP/500 se um conector GeoEvent em execução (entrada ou saída) fizesse uma solicitação no indisponível serviço.

Se um conector do GeoEvent Server (de entrada ou saída) fizesse uma solicitação em um serviço de feição que estava sendo reciclado, uma resposta do servidor HTTP/500 também seria esperada. O serviço não está disponível.

Solução ou Solução Provisória

Para solucionar a mensagem de erro, confirme o ponto de falha com base nas possíveis causas acima.

• O ArcGIS Server como um todo é funcional?
• Verifique se o ponto final REST do serviço está disponível.
• Confirme o status do serviço, Iniciado ou Interrompido no Gerenciador de Servidor ou Admin.
• Há ArcSOCs relacionados para o serviço de feição?
• Valide a fonte de dados referenciada.
• Acesse o ponto de extremidade REST da máquina GeoEvent. Confirme se está acessível.
• Examine os logs do ArcGIS Server para solucionar mais problemas.

O conector de saída pode ser recuperado ou colocado online novamente por:

• Reiniciando o conector de saída específico do ponto final do GeoEvent Manager.
• Parando e iniciando o conector de saída.
• Força a sincronização da conexão do GeoEvent Datastore em GeoEvent Manager> Site> Data Stores. Sincronize a conexão com a qual o serviço é publicado. 
• Esperando que a próxima descoberta de serviço seja acionada.

Nota: Na maioria dos casos, a espera pela próxima descoberta de serviço deve ser evitada. Se a descoberta de serviço coincidiu com a indisponibilidade temporária de um serviço e GeoEvent não conseguiu restaurar suas entradas e/ou saídas, seria necessário esperar até a próxima descoberta de serviço (várias horas depois), momento em que os serviços de feições estão disponíveis. É fácil ficar impaciente neste caso e clicar para solicitar uma nova descoberta de serviço após vários minutos, quando pode levar 20, 30, 45 ou mais minutos para concluir uma descoberta de serviço para algumas centenas de serviços de mapa/feições sendo hospedados por um servidor de hospedagem cuja infraestrutura pode ter várias instâncias do ArcGIS Server.

Para obter mais informações sobre como rastrear uma descoberta de serviço, siga o blog Geonet em Monitorando a descoberta de serviço de um servidor web registrado.

Práticas recomendadas recomendadas

• Os administradores de sistema que estão cientes de que os servidores serão reinicializados ou que serviços da web específicos ficarão temporariamente indisponíveis compartilham a responsabilidade de suspender ou interromper o processamento em tempo real, o que potencializa esses serviços da web. Caso contrário, pode-se esperar que eles tenham que parar e reiniciar os conectores individuais - ou na pior das hipóteses, reiniciar seu GeoEvent Server para restabelecer a conectividade do serviço. Pare os conectores de entrada, saída e serviço GeoEvent durante a janela de correção/manutenção.
• Aumente a taxa de descoberta em suas conexões de servidor registradas do padrão – que é 60 minutos – para algo mais como 1440 minutos. Também pode ser definido com um valor muito maior.
• Limite o número de serviços de feições que podem ser descobertas cada vez que o GeoEvent Server executa sua descoberta de serviço.
• Considere também não associar o ArcGIS Server sob o qual o GeoEvent Server está sendo executado, e configurar esse ArcGIS Server com seu próprio geodatabase relacional gerenciado, de modo que os serviços de feições cujos conjuntos de registros de feições estão realmente sendo consultados e/ou atualizados em tempo real não sejam associados as camadas de feições hospedadas do portal Enterprise. A menos que haja um grande armazenamento de dados espaço-temporal na arquitetura do sistema, pode ser viável não federar o ArcGIS Server do GeoEvent Server e nem mesmo registrar uma conexão com o servidor hospedado do portal Enterprise.

Como evitamos a perda de dados se seus serviços ficarem indisponíveis inesperadamente?

Da maneira como os conectores são implementados, pode não ser possível.

• A saída do GeoEvent Server não está ativa ou passivamente conectada a um serviço de feição. A saída só pode enviar uma série de solicitações discretas para o serviço de feição e descobrir – por meio de falha – que o serviço de feição está indisponível no momento.
• A saída pode tentar novamente em algumas centenas de milissegundos, mas se continuar a fazer chamadas repetidas em um serviço indisponível a cada segundo, ou a cada 100 milissegundos indefinidamente, ele prejudica a capacidade do GeoEvent Server de executar outras tarefas de processamento de eventos e trabalhar com outras entradas/saídas de serviços da web que estão disponíveis. A única opção é permitir que a saída suspenda as operações até que seja interrompida e reiniciada.