Tutorial: Publishing a WFS-T service

Complexity: Beginner Data Requirement: Use your own data

This tutorial will show you how to publish a WFS service with read-write access by enabling transactions (WFS-T) using ArcGIS Server Manager. A WFS service with transactions (WFS-T) allows WFS clients to apply edits (inserts, deletes, and updates) to the data in the source database through the WFS service. To apply changes through WFS-T, the data must be from an ArcSDE geodatabase. This tutorial demonstrates the workflow that should be used when working specifically with versioned data.

When a map service or geodata service is published with WFS capabilities, the data can be accessed by OGC-compliant WFS clients, including the Data Interoperability extension in ArcCatalog and ArcMap. These WFS clients can also see the latest changes made to the data. If you're new to WFS services and want to learn more about it before attempting this tutorial, see WFS services.

If you've just installed ArcGIS Server, you need to complete some preparatory steps before you can log in to Manager or publish services. You can find these steps in the Getting started after install section of this help system.

Setup requirements for publishing a service

To create a map service or geodata service, you need to place the map document (.mxd), geodatabase (File or Personal), or SDE connection file in a shared location visible to all server object container (SOC) machines in your GIS server. The SOC Account you created during the postinstallation must also have permissions to read the map document and all the data it references (map service), or all the data in the geodatabase that you wish to publish (geodata service).

WFS services support simple features from ESRI sources, such as shapefiles and geodatabases. However, if you are going to enable transactions on the service (WFS-T), all data that you wish to edit must be stored within an ArcSDE geodatabase.

Deciding between a geodata service or a map service

With WFS services, you have the option of publishing a geodata service or a map service. There are a few differences to be aware of when selecting the type of service you are going to create. The following sections summarize the functionality available with geodata and map services to help you identify which type of service best suits your requirements.

Geodata services

A WFS geodata service allows you to access a geodatabase through the Internet or any OGC-compliant WFS client. A geodata service may be created for any type of geodatabase including ArcSDE geodatabases, personal geodatabases, and file geodatabases. When creating a WFS service from a geodata service, it is important to keep in mind that all the feature classes in the geodatabase will be exposed in the service.

Geodata services are useful in situations where you need to access geodatabases in remote locations. For example, a company may want to set up ArcSDE geodatabases to manage data in its Los Angeles and New York offices. Once created, each office can publish its ArcSDE geodatabase on the Internet using a geodata service.

Map services

A WFS map service represents a map document (.mxd) that you've made available to others through the Internet or any OGC-compliant WFS client. Map services with WFS functionality give you a lot of control over the data that is published through the service. Here are some common reasons why you might set up a map service:

• Unlike a geodata service, a single map service may include data from a variety of sources including data from multiple geodatabases (personal, file, and ArcSDE) as well as shapefiles.
• You can select which feature classes are exposed through a map service.
• You can rename the feature classes in the map document so that the service does not expose the actual names in the data source.

There are also some limitations associated with WFS map services. Consider the following things when publishing a WFS service from a map document:

• The map document is just a specification of the layers that will be available in your WFS service. Symbology, query definitions, and field aliases defined at the layer level will not transfer to the WFS service because the purpose of the service is to expose the features in the data. To expose the visual properties of your map through OGC specifications, use a WMS service.
• Two or more layers in the map cannot reference the same feature class.
• Two or more layers in the map cannot have the same name.
• Since WFS only works with features, any raster layers in the map will be excluded from the service.
• Nonspatial tables are not exposed.
• If you want the WFS service to support transactions for editing (WFS-T), the source data for all the layers in the map must come from the same workspace, for example, the same ArcSDE geodatabase.

Preparing data for a WFS-T service

Before creating a WFS service with read and write access, there are some initial requirements to set up your data:

• It must be loaded into an ArcSDE geodatabase.
• If you want to work with versioned data, it must be registered as versioned.
• A version must be dedicated specifically for WFS editors to work with. If one does not already exist, it must be created.
• Specific WFS editors must be granted permissions on the SDE connection file to edit.

Follow these steps to prepare your data for a WFS-T service with versioned data:

Steps:

1. Load the data you want to publish into an ArcSDE Geodatabase. For more information on loading data, see Loading Data in ArcCatalog.
2. Register the data as versioned by right-clicking the dataset and choosing Register data as versioned from the context menu. For more information on this, see Registering data as versioned.
3. Now that the data is versioned, you must dedicate a version specifically for WFS users to edit. If no such version exists, follow these steps to create a new version for WFS editors to work with. Right-click the connection file and select Versions.

   This opens the Version Manager dialog box.

4. In the Version Manager dialog box, right-click the version you wish to create a child version of and click New. This creates a new version that can be used by WFS editors.
5. Type a Name for the new version. If users other than the creator will be editing the data, the Permission option must be set to Public.
   If you are creating a Geodata service, continue to step 6. If you are creating a map service, skip to step 9.

For Geodata services
6. To ensure that the geodata service publishes the appropriate data when it is created, the connection properties of the geodatabase must be updated so that they reference the new WFS version that has been created.

   To do this, right-click the geodatabase connection file and choose Connection Properties.
7. Under the section Connection Details, click the Change button.
8. Select the version dedicated to WFS users and click OK.
For map services
9. To ensure that the map service publishes the appropriate data when it is created, your map document must be updated so that it references the newly created WFS version. To do this, click the Source tab in the table of contents.
10. Right-click the geodatabase and select Change Version. This opens the Version Manager dialog box.
11. In the Version Manager dialog box, select the version dedicated to WFS users and click OK.
12. Save changes to the map document.

Publishing a WFS service

Follow these steps to create your geodata or map service:

Steps:

Start ArcGIS Server Manager and log in. For additional help with this step, see Logging in to Manager.
1. Click Publish a GIS Resource under the Services tab.
2. To select the Resource, use the drop-down box to browse to the map document (.mxd) or geodatabase (personal, file, or SDE connection file [.sde]) that you want to publish.
3. In the Name box, type a name for the service. The name cannot be more than 120 characters long and may contain only alphanumeric characters and underscores.
4. There are three options for the folder to publish the service to:
   • Use the drop-down menu to choose an existing folder.
   • Create a new folder.
   • Accept the default folder; this will publish to the root folder.

   After choosing where to publish the service, click Next to continue.

5. Select WFS to enable the capability for the service and click Next.
6. Review the information about the service you are about to create, then click Finish to create the service.

If you have an existing service that does not have WFS capabilities enabled, follow these steps to enable it:

1. Your service may be listed with its status as Started. To change settings on your service, the service must be stopped. If the status is shown as Started, check the check box beside your service and click the Stop button.
2. Click the Edit option for the service. This will allow you to edit the properties of the service including the capabilities.
3. Click the Capabilities folder.
4. Check the WFS check box.
5. Click OK to enable the capability.

Enabling transactions on the WFS service

After a WFS service has been published, there is an option called Transactions (WFS-T), which must be enabled to allow WFS users to edit and apply changes to the data in the source database.

Follow these steps to enable transactions on a WFS service:

Steps:

1. On the Services tab in ArcGIS Server Manager, click Manage Services.
2. Click the Services in drop-down arrow and navigate to the service folder containing your published service.
3. Your service may be listed with its status as Started. To change settings on your service, the service must be stopped. If the status is shown as Started, check the check box beside your service and click the Stop button.
4. Click the Edit icon to open the properties dialog box.
5. In the properties dialog box, select the Capabilities tab.
6. Click the WFS option (the name, not the check box) under the Select and configure capabilities window. This will display the WFS service properties.
7. Check the Enable Transactions check box.

How to acquire the URL for your WFS service

Steps:

1. Under the Services tab in ArcGIS Server Manager, click Manage Services.
2. Click the Services in drop-down arrow and navigate to the service folder containing your published service.
3. Your service should be listed with its status as Started. If the status is shown as Stopped, check the check box beside your service and click the Start button.
4. To acquire the URL for your WFS service, click the Edit icon to open the properties dialog box.
5. Click the Capabilities tab.
6. Highlight the WFS option under the Select and configure capabilities window. This will display the WFS service properties.
7. The URL for your WFS service is located in the Web Access window. This is the URL that you and other users will use to connect to the WFS service you have published.

Once you have published a WFS service, it can be used in any client that supports WFS 1.1 and the Simple Features profile of GML including Web browsers. You can also use the Data Interoperability extension in ArcCatalog and ArcMap to work with WFS services. The following sections will show you how to access WFS services through a Web browser and the Data Interoperability extension in ArcCatalog.

Connecting to your WFS service through a Web browser

A Web browser is one of the simplest clients of a WFS service. You can request information through HTTP, and the responses or exceptions are returned through the browser.

To connect to your service, you need to know the WFS URL, which can be located in the Service Properties under the Capabilities tab in ArcGIS Server Manager or ArcCatalog. Once you have the URL, you can use OGC standard operations to request information about the service through HTTP. Some examples of operations that you can use to request information include the following:

GetCapabilities

This request will return all feature types and functionality available through the service in GML format. To use the GetCapabilities operation in a Web browser, copy and paste the WFS URL into the address bar and add ?request=getCapabilities to the end, as shown in the example and screen shot below.

URL example: http://bobmk/arcgis/services/wfs_services/ArcSDE_wfs/GeoDataServer/WFSServer?request=getcapabilities

The following graphic is an example of functionality returned by the GetCapabilities operation:

GetCapabilities also returns a list of all available feature classes and tables:

DescribeFeatureType

This request describes the field information about one or more features in the WFS service. This includes the field names, field types, allowed minimum and maximum field values, and any other constraints set on a field of the feature classes or tables.

To use the DescribeFeatureType operation in a Web browser, copy and paste the WFS URL into the address bar and add ?SERVICE=WFS&VERSION=1.1.0&REQUEST=DescribeFeatureType&VERSION=1.1.0 to the end of the URL. This will return all the field information about each of the feature types and tables available in the feature service, as seen in the screen shot below.

URL Example: http://bobmk/arcgis/services/wfs_services/ArcSDE_wfs/GeoDataServer/WFSServer?SERVICE=WFS&VERSION=1.1.0&REQUEST=DescribeFeatureType&VERSION=1.1.0

Adding filters

You can also specify a single feature class or table that you want the field information for by appending the following request to the end of the URL with the name of the feature type or table: ?SERVICE=WFS&VERSION=1.1.0&REQUEST=DescribeFeatureType&TypeName=[enter feature type here]&VERSION=1.1.0

In the example below, the DescribeFeatureType request is used to identify the field information for the feature type called cities.

URL example: http://bobmk/arcgis/services/wfs_services/ArcSDE_wfs/GeoDataServer/WFSServer?SERVICE=WFS&VERSION=1.1.0&REQUEST=DescribeFeatureType&TypeName=cities&VERSION=1.1.0

GetFeature

This request returns information about specific feature types available through the WFS service. Additionally, filters can be used to refine the information that is returned. For more information about the different filters available with WFS services, see WFS Services.

To use the GetFeature operation in a Web browser, copy and paste the WFS URL into the address bar and add ?request=getFeature&typename=[enter feature type here] to the end of the URL. This will return all the attribute and geometry information about each feature or row in the feature type.

URL example: http://bobmk/arcgis/services/wfs_services/ArcSDE_wfs/GeoDataServer/WFSServer?request=getfeature&typename=cities

Adding filters

You can also add filters in the request to refine the results that are returned. For example, you can request all the cities that are within a specified coordinate range. In the example below, two cities are located within a specified coordinate range.

URL Example: http://bobmk/arcgis/services/wfs_services/ArcSDE_wfs/GeoDataServer/WFSServer?request=getfeature&typename=cities&BBOX=46.90,-76.21,42.12,-72.88

Using the Data Interoperability extension to connect to a WFS service

The Data Interoperability extension allows you to read and write data in formats not native to ArcGIS. You can use the Interoperability Connection tool located in ArcCatalog to connect directly to external ESRI data formats, including WFS services. Once the connection is made, the data source will appear underneath the Interoperability Connection entry in the Catalog Tree. A connection is just like any other dataset in that you can add it to ArcMap or use it in geoprocessing tools. For more information about how to use the Data Interoperability Extension with WFS services in ArcMap, see How to work with WFS using ArcGIS Desktop.

Managing edits made through a WFS-T service with versioned data

It is important to create an efficient workflow for managing edits made through a WFS-T service. Assuming you have followed the recommended method of creating a separate WFS version for WFS-T editors to work with, the system that you have set up should look similar to the diagram below:

In this example, WFS-T editors and ArcMap editors use versions so that each group can have their own isolated view of the geodatabase to work with. ArcMap editors are directly editing the Default version through ArcMap. WFS-T editors are accessing the WFS service over the Internet. This allows WFS-T editors to make edits on the WFS version that was created as a child of the Default. To learn more about versions, see A quick tour of versioning in the desktop help system.

To keep the two versions in sync, a process can be run regularly to update the WFS version with edits from the Default version and to update the Default version with the edits from the WFS version. This is a two-step process in the editing workflow of any versioned system called reconcile and post. This process can be automated, or it can be administered by an editor (depending on his or her permissions) or database administrator. To learn more about the reconcile and post process, see A quick tour of the version editing process.

When run, the reconcile operation will pull updates from the Default version into the current editing session on the WFS version. Conflicts may occur if edits have been made to the same features in both versions. You can either set up conflict resolution to be automatic or choose to resolve each conflict manually through the conflict resolution dialog box.

After handling any conflicts the post operation can be run. This process merges changes from the WFS version into the Default version.

The whole reconcile and post process is summarized in the diagram below. Here, the WFS version pulls updates from the Default version during reconcile. After incorporating the changes, the WFS version posts its updates to the Default version using the post operation. At this point, the Default and WFS versions both have the same content.

Once the reconcile and post process is complete, both versions are up-to-date with the most current representation of the features, and WFS editors can continue making edits again.

It is important to note that if there are outstanding locks when reconcile and post is run, the system will not allow the process to succeed. This is a safeguard to prevent conflicts between features locked by WFS-T clients and features changed through the reconcile and post process. Also, running reconcile and post will lock the WFS-T version to prevent any lock and transaction calls from being made by WFS-T editors during the reconcile and post process.

To accommodate this safeguard, it is recommended that the reconcile and post process be run at well-established times that all WFS-T editors have prior knowledge of. This will allow the editors to get their changes posted to the database. Administrators may also need to manually remove locks from the locks table before the reconcile and post.

To learn more about the WFS-T locking scheme, see WFS services.