The ArcGIS Enterprise SDK includes several additional technologies for customization of GIS services that can support integration workflows or patterns. With each of these patterns, Java or .NET software developers can write code using the ArcGIS Enterprise SDK to extend existing services, create new patterns, or affect existing service behavior.
Server object extensions (SOEs) are used to add new methods or capabilities (REST endpoints) to existing services. These extensions do not affect the existing endpoints and methods for the services, so they can generally only be consumed by custom applications or workflows that are aware of the endpoint and can call it directly. For more information on SOEs see What is a REST SOE.
Server object interceptors (SOIs) are used to affect, control or adjust existing endpoint functionality of a specific supported service. This means that the SOI code is invoked on each request to the service, and the developer can selectively choose to override an existing logical path, such as a /query or /identify request. The SOI code can then act either on the incoming request, adjusting parameters or inputs, or on the response from the existing server backend, removing attributes, adding information, or performing some other operations. For more information on SOIs, including samples and coding guidance, see What is an SOI.
Service interceptors are a new pattern of development that allows global control of certain service patterns or types, operating at the site-level REST tier rather than on an individual service. Interceptors can be used to control the behavior of a set of services, rather than applying an SOI to each service independently. For more information about service interceptors, and comparisons to existing SOI concepts, see Overview of service interceptors.
For integration purposes, these extensibility patterns provide a method to deploy an integration into an existing application server (ArcGIS Server) in a way that can be integrated into other ArcGIS workflows or patterns.
SOEs are built on top of existing services, so they inherit the authentication model of federated services in an ArcGIS Enterprise deployment. .NET or Java development patterns may have established libraries or tools for working with a remote dataset or system, so creating a new web service endpoint using an SOE may be an easier path to integration than hosting and building a stand-alone service.
SOIs work with existing endpoints such as a /query request. This allows interception of a query and then any desired action can be taken on the query input or result set, such as joining data from an existing system or filtering results based on a query to a different endpoint. These steps introduce latency on each request and should be carefully designed to avoid significant performance degradation.
ArcGIS Online apps or services that interact with ArcGIS Enterprise services can become users of SOIs and service interceptors, by consuming those layers into a web mapping experience. The same applies to ArcGIS Pro, which is a supported client for these service types can use them for visualization and cartographic purposes, as sources for geoprocessing tools, or for printing, with all SOI or service interceptor logic preserved. SOEs are generally consumed by custom applications that are designed to work with these new, use case-specific endpoints.
| Capability | ArcGIS Online | ArcGIS Enterprise | ArcGIS Location Platform | ArcGIS Pro |
|---|---|---|---|---|
| SOEs and SOIs | N/A |
Full support
Partial support
Prior to undertaking development of an SOE, SOI or service interceptor, refer to the ArcGIS Enterprise SDK documentation, specifically the Design philosophy for the ArcGIS Enterprise SDK, which provides helpful guidance and background on these development patterns. See the documentation topic Strategies for building REST SOEs for best practices and recommendations for SOE development.