To Swizzle or Not to Swizzle?

What is Swizzling?

Well it definitely sounds like fun, and for some people it really is! But what is it – other than a bit confusing, when you see that your swizzling has failed?

Put simply, in the context of ArcGIS Enterprise, “swizzling” is an automated process within ArcGIS Server that replaces references to datasets you are publishing as a service. Often this will be because the server cannot ‘see’ the same data that you can see, or you want to improve the response times (latency) of the service you’re publishing.

Swizzling your data allows for a separation between the source desktop map document data and the ArcGIS Server data sources.

In an ArcGIS Server configuration, layers within a service can be sourced either from Registered Data Stores, or Unregistered Data Stores. When a service is ready to be published, depending on the Data Stores registered on the server, and the specific connection the layer is using, they will fall into one of the following three categories:

1. Referenced [Registered]
   • Publisher and Server use the same data connection.
2. Replaced [Registered]
   • Publisher and Server use different data connections.
3. Copied [Unregistered*]
   • You can publish Registered data that is copied to the server in certain circumstances, e.g. to support a particular workflow such as reducing latency between server and data source.

* Data can be copied to the server even if it is referenced, but you have to select this. If the layer’s data is unregistered, it must be copied to the server.

It is possible to publish a service that has layers of each category within the service. For data management, maintenance and trust, it is important to establish publishing guidelines so you know which of these options your services layers are using.

How Does Swizzling Work?

The swizzling process relates to layers that are Replaced, meaning that the folder or database connection to the layer gets replaced automatically during the publishing process.  For this to work, a Data Store is registered with your ArcGIS Server site, and the publisher and server data connections are different.

During the process of publishing a service each layer will be analysed to identify whether it uses a registered or an unregistered data store. If a layer is identified that has a data source within a registered data store, and if that data store connection is swizzled, the layers data source will be replaced to reflect this.

Let’s look at an example:

• You are publishing a map service that contains a Wells layer that you are accessing, such as :
  • Wells (publisher): \\office-file-share\GIS\corporate.fgdb\wells_102100
• There is a data connection registered against your ArcGIS Server, such as:
  • Data Store Name: CorporateData
  • Publisher Folder Path: \\office-file-share\GIS\
  • Server Folder Path: \\cloud-file-share\GIS\
• When the Wells layer is published the location ‘\\office-file-share\GIS\’ will be replaced with ‘\\cloud-file-share\GIS\’, leading to the following full path:
  • Wells (server): \\cloud-file-share\GIS\corporate.fgdb\wells_102100

The result is that some or all of the layers in the service you have published will be ‘swizzled’ (replaced) with the servers’ data connection, assuming they reference the same path.

This Server Folder Path is likely to be remote to ‘you’ (i.e. ArcGIS Pro, where the map is authored), and ‘close’ to ArcGIS Server. So, while the map you are authoring in ArcGIS Pro is created with data ‘close’ to you, ArcGIS Server accesses a version of that data that is ’close’ to it. This will (if architected and implemented correctly) improve the performance of data drawing times for both environments.

Where is Swizzling Configured?

Swizzling capabilities are configured against Registered Data Stores. They can be managed in three places:

It is worth noting that using ArcGIS Server Registered Data Stores does not by default create a Portal Data Store item, but the other 2 options above will.

Why Should I Swizzle?

There are several scenarios where you might consider using swizzling to publish your data, for example:

1. ArcGIS Server cannot access the data you are visualising in ArcGIS Pro directly
   • g. you have Enterprise Geodatabase replicated between head office and remote offices.
2. You want to reduce data connection latency
   • g. you have an ArcGIS Enterprise environment hosted in Azure, but the File Geodatabase data you will be publishing is stored on an on-premise file share. Duplicating or synchronising this data nearer the Azure data centre would likely reduce service latency.
3. Development/Testing/Production (DTAP) promotion workflows
   • g. you use a single centralised set of map documents to publish to multiple servers, rather than updating data sources in each map ahead of publishing.
4. Environment / infrastructure changes
   • g. a shared folder structure changes to a DFS path, or a folder path changes from one drive letter to another.
5. To avoid having ArcGIS Pro installed on your ArcGIS Server machine to publish
   • g. you can publish using data stored on a drive attached locally to the ArcGIS Server, without publishing from that server.

This is not an exhaustive list and there are potentially many more reasons why swizzling your data may make sense.

When Not to Swizzle?

1. If you are copying data directly to the server, it will be automatically swizzled to the local ArcGIS Server directory where it copies the data**, so there is no need to pre-configure this (though you can enable/disable this capability).
2. If the source map document has the same connection to data as the ArcGIS Server you are publishing to.
3. If you do not wish to, or cannot maintain, synchronised copies of the same data.

As with the previous section, there are many more reasons why swizzling would not be appropriate, though this is a good starting point.

** It will copy data for each service you publish, so any duplicate data between other published layers will be duplicated on the server.

That Sounds Easy. What’s the Catch?

As with so many things, the devil is in the detail. Here are a few to be aware of before you start:

1. You can’t swizzle from one data source type of connection to another type of connection. For example, you cannot change data from a Database reference to a Folder reference.
2. There can often be several ways to connect to the same data, e.g. using a local path (E:\data\content.fgdb) rather than a UNC path (\\dataserver\data\content.fgdb), or using a slightly different connection string or alias to connect to an Enterprise Geodatabase. This can lead to data being copied to your server that should rather be referencing ‘live’ data.
3. There is no data copying involved in the swizzling process – it only changes the data source. If you are swizzling from a separate instance of the data on the Enterprise server (e.g. from a network drive to a local drive on the ArcGIS Server machine), the data will not be copied to the ArcGIS Server machine. In this case, you will need to ensure you synchronise your data from one to the other, e.g. via automated Python scripts or replica database(s).
4. You will need to set a hostname variable if you are using a locally mounted folder path as the publisher path (rather than a UNC path) so you may need to register multiple data stores if publishing from multiple machines not using a UNC folder source.
5. You may end up with quite a few registered data stores. This can be a bit unwieldy to manage and to standardise, so choosing appropriate names for your data stores is key.

Honourable Swizzling Mentions

The automated method discussed in this blog relates to ArcGIS Server side swizzling process, but there are other similar processes that allow for automatic updating of data sources.

1. ArcGIS Pro
   

In ArcGIS Pro you are able to update data sources in bulk using the Update Data Sources tool. This tool allows you to update either the workspaces used within a map or a linked web map, or the individual layer references, and has some useful ‘find and replace’ capabilities.

2. ArcGIS Python API
   

Using the ArcGIS Python API you can perform more advanced data updating tasks, from bulk desktop data connections to more advanced ArcGIS Enterprise migration tasks (e.g. migrating content from one domain to another), though it requires a bit more hands-on work.

That’s It!

Hopefully this has provided a summary of workflows that could help with planning your enterprise GIS deployment, whether cloud, on-premise or both. If you’re after any guidance please drop us a line.

Posted by Dean Moiler, Solution Architect.