ArcGIS Server - Service Design/Architecture

[BrianCollins]

Looking for input on laying out a brand new ArcGIS Server environment. We're a state government agency that serves data both internally to our program staff and externally to the public. Our dilemma is this: do we lump services or split services? In other words, do we publish specific endpoints (map service and feature service) for each of our production-level feature classes so that we have completely granular control over each specific dataset...or do we try to group feature classes together based on assumed end-user needs? The concern is that we'll have unanticipated changes in the future that may goof up the indexing of web services that serve more than one dataset and then have to do our best to fix everything that touches a layer that might have changed position. On the flip side, I don't know if there is a performance hit, either on ArcGIS Server or applications that are consuming the data, by splitting every feature class out to its own endpoint.

I've scoured the web looking for best-practices documentation and examples, but I can't find much. Any input would be greatly appreciated. We have an ideal situation in that we've got a clean environment to configure from the ground up...we just don't want to look back and wish we'd done things differently.

[JakeSkinner · Accepted solution]

Hi Brian,

A new feature that is available that may help your decision is the ability to preserve layer and table IDs:

Map authoring considerations—Documentation (10.3 and 10.3.1) | ArcGIS for Server

I usually find it's best to create services based on the end user's needs.  However, you can monitor the performance of the server using System Monitor tools, and monitor services/applications using the System Test tools.

[JoshuaBixby]

It would be nice if Esri released System Monitor 2.0 to the masses instead of relying on Professional Services contracts as the release mechanism.  I am not opposed to Professional Services, I just don't like the idea of using it to get the latest version of tools that we need to monitor all of the other Esri software we have paid for already.

[BrianCollins]

Thanks Jake...great information! I have to admit I was totally unaware of the ability to preserve layer/table IDs in 10.3. We're leaning toward publishing discrete service endpoints for specific feature classes. While there are projects and applications that are predictable for us in their layout and design, we can't really anticipate how our end users will ultimately consume our data on an ad hoc basis. Even though we can preserve the indexing with 10.3, I still like the granular approach. It may be cumbersome to set up the first time, but I'm thinking it's the right move for us long term.

I'll check out System Monitor and System Test. Thanks again...

[MichaelVolz]

Are you laying out this brand new environment with the current 10.3.x release?  If not, then the ability to preserve layer and table IDs will not be available to you as per the previous post.  If this is the case, I would push to get the latest ArcGIS release to make sure you have this ability when you setup your ArcGIS Server environment.

Also, will you have an SDE database registered with ArcGIS Server?  If so, what type of database is it (e.g. SQL Server, Oracle, other)?

[BrianCollins]

Thanks Michael...yes, we're running the latest release (10.3.1). The majority of our web services (map services) will be running from file geodatabase sources hosted on the server. Those data sources are updated from the authoritive parent SQL/SDE databases via python script using Windows Task Scheduler. In the instance where we need editing capabilities we'll spin up services directly from the enterprise data source which is primarily SQL...with one production Oracle instance. Those data sources are registered in ArcGIS Server as well.

[MichaelVolz]

Brian:

Have you thought about removing the file geodatabases from the equation (thus the python based Windows Task Scheduler), by using SDE as the source for your ArcGIS Server services?  In this way, you have single-sourced your data.

Also, the more services you spin up, the more instances that will be needed (more CPU and RAM), as opposed to grouping data together into mapservices that target a specific application(s) if the data requirements are similar.

[BrianCollins]

Michael...we have considered single-sourcing the data, which is what we've done in the past; however, abstracting the SDE data into file geodatabase provides us a couple advantages:

1. Administration - Our SDE environments are relatively complex multi-user/versioned environments. Removing the majority of direct web services connections allows us to perform management tasks more efficiently without impacting web service availability.
2. Performance- not having to deal with any network latency for web services to call SDE data across the network.

Of course we do use the single-source method when we need to provide feature service access for end users to make direct modifications via web services, but otherwise our approach works very well.