The GeoEvent extension includes an inbound connector which is able to poll an existing Esri feature service, for example, to retrieve data from a feature layer. The feature service in this case acts as a data broker which the GeoEvent extension can work through to access the underlying feature data in the database. The product team has no plans to provide ODBC / JDBC connectors to retrieve data directly from RDBMS tables. Connectors such as these would be database specific and we are working to keep GeoEvent database agnostic.
You do have a few options available, however, without relying on an ODBC / JDBC connector:
- Since ArcMap will not allow you to publish a map document as a feature service if the MXD has no feature layers, you cannot create an MXD with *only* a non-spatial table and publish a feature service. ArcMap will require that you include at least one feature layer whose "features" come from a "feature class" … a spatial table containing geometry.
However, if you add your non-spatial table to a map document and then add any feature layer, even one pointing to an empty (dummy) feature class which has no features, you should be able to publish a feature service. An out-of-the-box GeoEvent input can then poll the non-spatial table for "features" through the feature service. When configuring the Poll an ArcGIS Server for Featuresinbound connector, you simply select the non-spatial table as the "layer" rather than the actual (dummy) feature layer which will be forever empty (no features).
- Another option is to create a script which would periodically retrieve the non-spatial event data from the database's table, and then HTTP/POST the data directly to an endpoint associated with a GeoEvent Extension input. The out-of-the-box inbound connectors expect either Generic JSON or Esri Feature JSON. Later releases of GeoEvent also support XML and geoJSON.
- You might also look into creating a wrapper around the RDBMS using an open API such as the OData protocol (http://www.odata.org/). The OData protocol provides rapid solution development incorporating database access through web services as a front facet to the backend database.
We are only interested in retrieving row data as "events" … and the OData protocol provides an REST endpoint through which the database records can be retrieved as generic JSON. This approach fits well with the GeoEvent extension which provides a generic JSON adapter out-of-the-box. You can then configure a Poll an external website for JSON inbound connector to poll the OData endpoint for data – or configure a Receive JSON on a REST endpoint inbound connector to receive JSON data from an OData HTTP POST (though I'm not sure if OData is capable of retrieving the database records and POSTing them to an external client).
An architecture for the OData approach might look something like the following:
Hope this information is helpful -
RJ