Achieving full compatibility with CDF - based services

Question

Is it useful to capture the fields list (and other parameters like return geometry only) when implementing the data provider functionality?

I could see that the published service (based on a full-fetch custom data provider) does already filter the response and returns the desired fields. Even though I have not explicitly captured the parameter value and implemented the filtering on the GeoJSON response.

How do I know what do we need to capture and handle at request level to produce a proper full compatible Feature Service, that behaves completely like a read-only FeatureService?

The where clause, returnCount, returnExtent and the pagination parameters are definitelly a must. But... what else? F.e. How to "build" a proper response when we query directly a feature by OBJECTID. We can query and get a list of IDs only, but the resulting hyperlink is broken. So the user cannot follow it.

John_Hash · Answer

@MarcBateEA Thank you for the comment. I'd like to learn more about the issue you are running into with the filter widget. The problem you are describing seems like it might be a little too complicated to fully work through in this forum. I sent you a direct message, so we can get into more details if you'd like.

MarcBateEA · Answer

We were sold CDFs to behave just like feature services and they just aren't.  Our biggest problem is the performance when using something like the filter widget.  It is extremely chatty to get all the dependent dropdown values when you change your selection, making it unusable for more than 5k records in the dataset.  Our data doesn't update often so I do a daily cache so it doesn't have to hit the source data server multiple times during the day, yet still too slow to use.

Francisco_R · Answer

Thanks for a very good explanation. I see I might not have formulated my question properly, apologies for that. I meant I have identified broken links when consuming the published service directly by feature ID, so this address: rest/services//FeatureServer// returns Not Found error. { "error": { "code": 500, "message": "Feature (ID: 2) not found", "details": [] } } Instead for a JSON Definition of the feature with ObjectID = 2 like this example from a Hosted Service: { "feature": { "attributes": { "globalid": "{4D9FC17A-661C-44F7-B688-E1AA94245F29}", "objectid": 2 }, "geometry": { "x": 1196029.2908000015, "y": 8378724.482199997 } } } I would assume that I would need to define a route, and somehow parametrize the OID, so I can process the getData accordingly based on the OID (which will be basically filtering by ObjectID as you explained in your answer). If that's the case. The route should probably look like (assumed 1 layer only): { path: `//rest/services/FeatureServer/0/:objectid`, methods: ['GET','POST'], handler: 'getDataByObjectId' } And where I define a separate handler function in the Model to return single feature results. I guess the request parameters will expose that objectid for preparing the answer. I wondered if there are more situations like these we have to handle. So we can achieve an equivalent service than a Pro-published regular FeatureService. So far I have found (but I have just begun): * Capture Where clause (fundamental query) * Capture ObjectIDs (almost everything might leverage this) * Capture count and extent (metadata queries) * Capture spatial filter (Pro seems to leverage them by default) * Build a route and handler for direct OID queries Other query parameters (returnIDs only, display fields, etc) seem to be handled at AGS level already. I Understand that I can still capture them if I need to customize the query against the datasource in advanced scenarios. But that would be more related to a query-optimization stage more than "achieving client-side compatibility".