Deteniendo transporte porque la capa requerida [DatastoreConnection][Layer Name] [LayerID] [Feature Server] no está accesible tras completar la sincronización

Mensaje de error

El siguiente error lo devuelve un conector de salida en GeoEvent Manager (https://server.domain.com:6143/geoevent/manager/index.html), si el servicio de entidades se detiene en el servidor (por ArcGIS Server):

Error: Deteniendo transporte porque la capa requerida [DatastoreConnection][Layer Name] [LayerID] [Feature Server] no está accesible tras completar la sincronización.

La salida de GeoEvent perdió la dirección URL que requiere para realizar solicitudes en el extremo REST de un servicio de entidades, la salida debería permanecer en su estado "Iniciado", y no pasar a un estado "Error".

Se espera que se produzca este comportamiento, y parece ser una limitación de cualquier arquitectura orientada a servicios (SOA) si un servicio externo se desconecta inesperadamente.
Dependiendo del tipo de conector entrante o saliente, es posible que el cliente HTTP utilizado por el conector reciba un error HTTP/500 "servidor general/servicio" al realizar una solicitud en un servicio web externo. Una entrada en este caso detiene la consulta o recepción de datos. Un conector de salida deja de hacer solicitudes en el servicio externo para distribuir datos desde registros de eventos procesados.

La clave aquí consiste en reconocer que un portal de Enterprise o un servicio de entidades alojado de ArcGIS Server no se benefician del tratamiento ni el manejo especiales porque se encuentran dentro del ecosistema de Esri.GeoEvent Server trata cualquier servicio web que consulta o al que envía solicitudes como un servicio web externo.

Durante el tiempo que el conector saliente permanece desconectado, en un estado de error, cualquier dato en tiempo real recibido no se distribuirá a través del conector saliente. Los registros de eventos recibidos seguirán estando "perdidos", ya que se dirigen al conector saliente que ya no está conectado ni en ejecución.

La solución para el error incluye algunos pasos básicos de solución de problemas junto con prácticas recomendadas para evitar que los conectores entren en un estado de error y eviten la pérdida de datos.

Causa

El conector Actualizar una salida de entidad pasa a un estado de error cuando el extremo REST del servicio de entidades de salida no está disponible. El servicio de entidades podría no estar disponible debido a:

• Una interrupción prevista, por ejemplo, para realizar revisiones del servidor
• Protección segura y mantenimiento de la fuente de datos a la que se hace referencia (geodatabase corporativa)
• Interrupciones no previstas, como daños en el servicio o si el sitio de ArcGIS Server está sin conexión
• Si el servicio de entidades de salida se detiene de alguna forma (el error se puede replicar simplemente deteniendo el servicio de entidades desde el correspondiente Server Manager/Admin).
• El servicio de entidades se está reciclando
• Pérdida de la comunicación entre GeoEvent Server y el ArcGIS Server que aloja el servicio de entidades

Se esperaría de un servicio que, de pronto, no está disponible porque el servicio se detuvo (o el ArcGIS Server se dejó sin conexión) y produciría un error HTTP/500 si un conector de GeoEvent en ejecución (entrada o salida) realizó una solicitud en el servicio no disponible.

Si un conector de GeoEvent Server (entrante o saliente) tuviera que realizar una solicitud en un servicio de entidades que se estaba reciclando actualmente, también se esperaría una respuesta de servidor HTTP/500. El servicio no está disponible.

Solución o solución alternativa

Para solucionar el mensaje de error, confirme el punto de fallo en función de las causas potenciales anteriores.

• ¿Es funcional ArcGIS Server en su conjunto?
• Compruebe si el extremo REST del servicio está disponible.
• Confirme el estado del servicio, Iniciado o Detenido, desde Server Manager o Admin.
• ¿Existen ArcSOC relacionados para el servicio de entidades?
• Valide la fuente de datos a la que se hace referencia.
• Acceda al extremo REST desde el equipo de GeoEvent. Confirme si está accesible.
• Examine los registros de ArcGIS Server para ir más allá con la resolución de problemas.

El conector de salida se puede recuperar o volver a conectar del siguiente modo:

• Reinicie el conector de salida específico desde el extremo de GeoEvent Manager.
• Detenga e inicie el conector de salida.
• Fuerce la sincronización de la conexión del data store desde GeoEvent Manager > Sitio > Data stores.Sincronice la conexión en la que se publica el servicio.
• Esperando a que se desencadene la siguiente detección de servicios.

Nota: En la mayoría de los casos, se debe evitar esperar a la siguiente detección de servicios.Si la detección de servicios coincide con que hay un servicio no disponible temporalmente y GeoEvent no pudo restaurar sus entradas o salidas, sería necesario esperar hasta la siguiente detección de servicios (varias horas después), momento en que los servicios de entidades están disponibles. Es fácil impacientarse en este caso y hacer clic para solicitar una nueva detección de servicios después de varios minutos, cuando puede tardar 20, 30, 45 o más minutos en completar una detección de servicios durante un par de cientos de servicios de mapas/entidades alojados por un servidor de alojamiento cuya infraestructura puede tener varias instancias de ArcGIS Server.

Para obtener más información sobre el seguimiento de una detección de servicios, consulte la entrada de blog de GeoNet sobre Cómo monitorizar la detección de servicios de un servidor web registrado.

Prácticas recomendadas

• Los administradores del sistema que saben que se van a reiniciar los servidores o que determinados servicios web no van a estar disponibles temporalmente comparten la responsabilidad de suspender o detener el procesamiento en tiempo real, que aprovecha esos servicios web. De lo contrario, se espera que tengan que detenerse y reiniciar conectores individuales, o que, en el peor de los casos, reinicie su GeoEvent Server para restablecer la conectividad del servicio. Detenga los conectores de entrada y salida y el servicio de GeoEvent durante la ventana de revisión/mantenimiento.
• Aumente la tasa de descubrimiento en sus conexiones registradas al servidor, del valor predeterminado (60 minutos) a un valor más cercano a 1440 minutos. También se puede establecer un valor mucho mayor.
• Limite el número de servicios de entidades que se pueden detectar cada vez que GeoEvent Server ejecuta la detección de servicios.
• Asimismo, plantéese no federar el ArcGIS Server debajo del cual se está ejecutando GeoEvent Server y configurar ese ArcGIS Server con su propia geodatabase relacional administrada, de modo que los servicios de entidades cuyos conjuntos de registros de entidades se estén consultando y/o actualizando de verdad en tiempo real no se mezclen con las capas de entidades alojadas del portal de Enterprise. A menos que haya un big data store espaciotemporal en la arquitectura del sistema, puede ser factible no federar ArcGIS Server de GeoEvent Server y ni siquiera registrar una conexión al servidor alojado del portal de Enterprise.

¿Cómo evita la pérdida de datos si sus servicios dejan de estar disponibles de forma inesperada?

Por la forma en que están implementados los conectores, quizá no sea posible.

• La salida de GeoEvent Server no está conectada de forma activa ni pasiva a un servicio de entidades. La salida solo puede enviar una serie de solicitudes discretas al servicio de entidades y detectar (mediante errores) que el servicio de entidades no está disponible en el momento actual.
• La salida puede volver a intentarlo en varias centenas de milisegundos, pero al seguir haciendo llamadas repetidas a un servicio no disponible, cada segundo o cada 100 milisegundos indefinidamente, se dificulta la capacidad de GeoEvent Server para realizar otras tareas de procesamiento de eventos y trabajar con otros servicios web entrantes/salientes que estén disponibles. La única opción es permitir que la salida suspenda las operaciones hasta que se detenga y se reinicie.