Migration from 10.0 to 10.2.2: Overwiting a Service

[JoeBorgione]

I have been running ArcGIS server on the 10.0 for a few years: due to a dependance on a third party application, I now have the opportunity to modernize to 10.2.2.

The primary function of ArcGIS Server within the organization I work for is to provide a geocoding service as well as a map service used in 9-1-1 dispatching.  The third party software mentioned is Computer Assisted Dispatch (CAD); a 9-1-1 call is received, and to verify the address of the caller, that information is passed via ArcGIS Engine where the address is validated (geocoded) and the appropriate responding zones (polygons in the map service) assigned.  That information is then passed back to the dispatcher.

Currently, I have two  "systems" available, and I use the slogan "when one is hot, the other is not" where Hot refers to it's connectivity to CAD and where the geocoding and zone assignments are made.  (See workflow image below)  Having two parallel systems allows me to shut one published composite geocoder down so I can rebuild it as new data is made available.  Both composites point to a single file geodatabse that is a child replica of an SDE (SQL Server) geodatabse.

Once I rebuild one service and restart it, I toggle CAD over to it with no loss in service to dispatch.  I then shutdown the 'cold' service and rebuild the locators for it and restart it as well, leaving me with two refreshed services.

In ArcGIS 10.2.2 there is now the ability to Overwrite a service (see ArcGIS Help (10.2, 10.2.1, and 10.2.2) ) .  From the online help:

At 10.1 and later versions, edits made to the source data (such as feature classes displayed in a map) should be immediately visible in the service as long as a copy of the data was not placed on the server when publishing

I'm not exactly sure what this means.  Can someone please explain this passage?  I would also like to know what change(s) in the current workflow I should make in order to keep the services always available as I do now.

[TanuHoque · Accepted solution]

Joe Borgione wrote:

At 10.1 and later versions, edits made to the source data (such as feature classes displayed in a map) should be immediately visible in the service as long as a copy of the data was not placed on the server when publishing

Joe, lets see whether I can explain it clearly.

Unlike pre-10.1 server, starting at 10.1 (put that in very simple way), you can publish a service (a) by referencing the original data and (b) by copying data on the server along.

As you may have noticed that the publishing process is different at 10.1 and depending on your workflow (which seems like the case for you) you may want to 'register' the FileGDB / SDE/ folders etc. (that layers in your mxd pointing to) to the 'data store'.

If you don't do that you will see an analyzer warning and if you accept, your data get copied to the server; and the service starts to use that version of data (off a server's managed location) instead of the workspace layers in your source mxd referring to.

Option (a): this is like pre-10.1 server. you create a map document in ArcMap, you add bunch of layers e.g. from a FileGDB, you register the workspace and you publish...

in this scenario, as you update you data in the workspace, every map refresh or query operation call will give you the updated data. No service restart, no overwrite needed.

Option (b): this is when you do not register the workspace to the data-store and right before publishing process starts, you accept to copy data on the server. In this case, layers in that map/feature service will *no* longer refer to the workspace that the layers in the source mxd refer to... instead they refer to a managed workspace on the server...

In this particular scenario, if you data get updated, yes, you need to overwrite the map/feature service so that the data on server get updated as well.

Hope this help. Sorry about the lengthy reply.

[JoeBorgione]

Tanu-  thanks for your reply, and no it's not lengthy at all.  Rather it's right to the point!

As I understand your explanation, Option A is the better choice for me, as it emulates what I'm used to doing, but actually cuts down on the work flow.  I assume that this approach will work for a published composite locator in addition to a published map service.  It seems to me I don't need need to two parallel services: they are only in place to maintain service while rebuilding the off-line locators.