Hello everyone,
I am developing a custom Server Object Extension (SOE) using C# and the ArcGIS Enterprise SDK. My extension needs to run heavy, long-running queries and traces against a Utility Network dataset.
Because these operations can exceed standard HTTP and Web Adaptor timeouts, a synchronous REST request isn't viable. I want to implement an asynchronous job pattern native to my SOE - very similar to how asynchronous Geoprocessing (GP) services work (/submitJob, /jobs/{jobID}, and /jobs/{jobID}/results).I want to avoid GP services because my core logic requires the use of Enterprise SDK to query the network index. I understand that IServerObject and IMapServerDataAccess live on the main ArcSOC thread (STA) and cannot be passed across threads without throwing AccessViolationException or crashing the ArcSOC process.
I'm thinking for an SOE with following operations:
- Submit Job Operation (/submitJob)
- registers a new job and starts a new thread where the query tasks are run
- when the job is done, the results are stored and the job is marked as complete
- Check Status Operation (/checkJob)
- Get Results Operation (/getJobResults)
- if the job is complete the stored results are returned
Before diving in code I'm looking for best practices and architecture advice on a few specific points:
- Thread-Safe UN Data Access: To run the trace/query on a background thread pool (Task.Run), is the recommended approach to extract the IPropertySet connection string from the main thread, open a clean IWorkspaceFactory / IFeatureWorkspace inside the background thread, and re-open the Utility Network dataset there?
- COM Context Handling: Are there any specific Enterprise SDK threading pitfalls I need to look out for when initializing a new thread pool thread to interact with IBaseNetwork or IUtilityNetworkQuery ? Do I need to explicitly handle thread marshaling, or does opening a separate workspace instance on the background thread completely isolate the COM context safely?
If anyone has implemented a custom async task wrapper or job queue inside a .NET SOE, I would love to hear your architectural recommendations or see snippet examples of how you handled the background workspace bootstrap.
Thank you in advance!
