update features in mapservice

Question

I am using a SOE on top of a MapService in order to enable complex editing of the features in my File-Geodatabase. We use a SOE as we have much ArcObjects-code in our code-base that wraps rows from within a table to actual features. So in fact a feature consists of several rows in different tables, thus updates to a single row should be notified by the others. We´re also using topological edits which I suppose a feature-service can´t handle. When I try to edit a feature I get the following error: Workspace or data source is read only. If I understand things right, a map-service is just for presenting a map, not for modifying the data. This is where a feature-service would come into play, which however does not have support for a Server-object-extension and thus won´t handle our business-logic very well. I´ve already tried to read the connection-properties of the underlying map-service and re-open it: public void Init(IServerObjectHelper pSOH) { serverObjectHelper = pSOH; if (serverObjectHelper.ServerObject.TypeName == "MapServer") { m_mapServer = serverObjectHelper.ServerObject as IMapServer; m_mapServerDataAccess = (IMapServerDataAccess)serverObjectHelper.ServerObject; } IMapServerInfo mapServerInfo = m_mapServer.GetServerInfo(m_mapServer.MapName[0]); IMapLayerInfos mapLayerInfos = mapServerInfo.MapLayerInfos; for (int layerId = 0; layerId < mapLayerInfos.Count; layerId++) { IFeatureClass fc = (IFeatureClass)m_mapServerDataAccess.GetDataSource(m_mapServer.MapName[0], layerId); if (fc != null) { IDataset fsDataset = (IDataset)fc; m_workspace = fsDataset.Workspace; } if (m_workspace != null) break; } if(this.m_workspace == null) throw new ArcGISAccessException("Workspace could not be opened"); var props = this.m_workspace.ConnectionProperties; var factory = new FileGDBWorkspaceFactory(); var editWorkspace = factory.Open(props, 0); }‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ However this yields to the examt same error. I can´t see what I´m doing different than the code from the samples. I also noticed that I am able to edit the data in the geodatabase in ArcMap without any problems, even when it is used by the map-service. EDIT: To limit the cause of error I set up a completely new service that references a newly created File-Geodatabase containing only a single feature within a featureclass ("FC"). Now I update that feature within my request-handler: private byte[] ModifyFeature(NameValueCollection boundVariables, JsonObject operationInput, string outputFormat, string requestProperties, out string responseProperties) { responseProperties = null; var featureWorkspace = (IFeatureWorkspace) this.m_workspace; var editWorksopace = (IWorkspaceEdit) this.m_workspace; var featureClass = featureWorkspace.OpenFeatureClass("FC"); var feature = featureClass.Search(null, false).NextFeature(); var index = featureClass.FindField("MyAttribute"); if (featureClass.Fields.Field[index].Editable) { editWorksopace.StartEditing(false); editWorksopace.StartEditOperation(); feature.set_Value(index, "Hallo"); feature.Store(); editWorksopace.StopEditOperation(); editWorksopace.StopEditing(true); } var result = new JsonObject(); result.AddString("Status", "OK"); return Encoding.UTF8.GetBytes(result.ToJson()); }‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ I still get the same error, although I even check if the field of that feature is editable.

CarstenSchumann · Answer

Hi James,

thanks for your reply. We already considered those opportunities mentioned by you, however it feels they all have their own drawbacks. In particular - as our logic includes some millions of existing code - I doubt a geo-processing-service is the right thing as it´s hard to debug.

Thinking about the SOI I doubt we can manage the amount of different operations that exist in our application by a SOI, as it does only modify the operations given by the map-service itself. However I assume we have to extend the mapserver by some functionality, which was why we thought about using the SOE in the first point.

JamesMacKay3 · Answer

Hi Carsten, perhaps you could use a geoprocessing tool written in ArcObjects and then published as a service to perform the complex edits needed.  I did something similar several years ago (no sample code on hand now, unfortunately) with the connection properties stored in a configuration file.  A standard map service could still be used for read access.

Another option that may or may not work depending on the complexity of these features and edits is to use a Server Object Interceptor with a map service that has feature access enabled (SOIs can intercept edits in this way, then perform custom editing inline).  In my opinion the big advantage of SOIs is that you don't need any client-side customization like you do for SOEs or GP services, but it also sounds like what I've used them for is less complex than what you're looking for.