The following error is returned by an output connector in GeoEvent Manager (https://server.domain.com:6143/geoevent/manager/index.html), if the feature service is stopped on the server side (by ArcGIS Server):
Error: Stopping transport because the required layer [DatastoreConnection][Layer Name] [LayerID] [Feature Server] is not accessible after sync'ing has completed.
GeoEvent’s output lost the URL it requires to make requests on a feature service’s REST endpoint, the output should remain in its ‘Started’ state and not transition to an ‘Error’ state.The error state is only supposed to indicate that a request to a service assumed to exist failed because an HTTP return code indicates the service does not exist.
This behavior is expected and seems to be a limitation of any service‑oriented architecture (SOA) if an external service unexpectedly goes offline.
Depending on the type of inbound or outbound connector, it is possible that the HTTP client used by the connector may receive an HTTP/500 “general server/service” error when making a request on an external web service. An input in this case stops querying for or receiving data. An output connector stops making requests on the external service to disseminate data from processed event records.
The key here is to recognize that an Enterprise portal or ArcGIS Server hosted feature service does not benefit from special treatment or handling because it is inside the Esri ecosystem. GeoEvent Server treats any web service being polled or to which it sends requests as an external web service.
For the period of time the outbound connector remains disconnected, in an error state, any real-time data received will not be disseminated through the outbound connector. Event records received will continue to be “lost” as they are routed to the outbound connector which is no longer connected and running.
The solution for the error includes some basic troubleshooting steps along with best practices to prevent connectors from entering an error state and avoiding data loss.
The Update a Feature output connector transitions into an error state when the REST endpoint of the output feature service is unavailable. The feature service could be unavailable due to :
This would be expected of a service which is suddenly unavailable, because the service had been stopped (or the ArcGIS Server taken offline) and would produce an HTTP/500 error if a running GeoEvent connector (input or output) made a request on the unavailable service.
If a GeoEvent Server connector (inbound or outbound) were to make a request on a feature service which was currently being recycled, an HTTP/500 server response would also be expected. The service is not available.
To troubleshoot the error message, confirm the point of failure based on the above potential causes.
The output connector can be recovered or brought back online by:
Note: In most cases waiting for the next service discovery should be avoided. If the service discovery coincided with a service being temporarily unavailable and GeoEvent were unable to restore its input(s) and/or output(s), it would be necessary to wait until the next service discovery (several hours later), at which time the feature service(s) are available. It is easy to get impatient in this case, and click to request a new service discovery after several minutes, when it may take 20, 30, 45 or more minutes to complete a service discovery for a couple of hundred map/feature services being hosted by a hosting server whose infrastructure may have multiple ArcGIS Server instances.
For more information on tracking a service discovery, follow the Geonet blog on Monitoring a registered web server's service discovery.
Recommended best practices
How do we prevent the loss of data if their services unexpectedly become unavailable?
The way the connectors are implemented, it may not be possible.