Web editing with WFS services

When you publish a map or geodata service with the WFS capability enabled, the data can be accessed by OGC-compliant WFS clients. These WFS clients can also see the latest changes made to the data.

When a request comes in from a WFS client such as a viewer, the data is returned as it exists in the data source at that time. For example, suppose you have a map document containing a feature class. This feature class comes from a file geodatabase. Now you publish that map document as a map service and enable the WFS capability. A client with a WFS viewer can access the data in the feature class using the WFS URL provided by the map service.

Now suppose someone else accesses the source file geodatabase and adds, updates, and deletes features in the feature class. The next time the client with the WFS viewer refreshes, the data with the most recent edits is what's shown.

When the data source is an enterprise, workgroup, or desktop geodatabase geodatabase, geodata services and map services publish data from a specific version. If data is edited in that version, both WFS clients and non-WFS clients see these changes. However, if edits are made in other versions, clients do not see the changes until they are reconciled with the published version.

This gives you more control over the data exposed through your services. Suppose you publish some data with the WFS capability from a version named WFS. Clients with WFS viewers then start to access the data through your service. Meanwhile, editors in the office use ArcGIS to update the default version. The changes made by the editors are then checked and adjusted if necessary. Once the evaluation is complete, the WFS version is reconciled with the default version. At this point, the WFS clients see the latest updates from the editors.

Web editing with a WFS service using versioned data.

Transactional WFS services

A transactional WFS service (sometimes known as WFS-T) allows WFS editors to apply changes to the data in the source database through the WFS service. To apply changes through WFS-T, the data must be from an enterprise, workgroup, or desktop geodatabase geodatabase. Transactions can be enabled on services that have versioned data, nonversioned data, or a combination of both. If you choose to use versioned data, it is also recommended that you publish the service from a nondefault version.

For detailed instructions on how to create a transactional WFS service, see Tutorial: Publishing a WFS-T service.

Once transactions are enabled, WFS clients can apply changes to the geodatabase using transactional WFS methods. The following is an example of how changes can be applied:

• The WFS client connects to the WFS service that has been published with transactions enabled.
• The edited features and rows are locked on the server (this can be done using the GetFeatureWithLock WFS method).
• Edits are performed using a WFS editor on the WFS client.
• Edits are then applied on the server (this can be done using the Transaction WFS method).

When the edits are posted, the locks are released and the features can be edited by other WFS editors. Locks can also be released if they time out. By default, locks will time out after five minutes, but this can be adjusted by specifying a time-out in minutes using the GetFeatureWithLock method. An administrator can set the default time-out by manually editing a configuration and setting the element DefaultLockExpiration (time in minutes).

When a client requests a lock using GetFeatureWithLock, a feature collection with the locked features and a lock ID are returned. If any of the requested features cannot be locked, the request fails, and the client will need to call GetFeatureWithLock again. Other clients are prevented from acquiring locks on these features until the locks are released.

Insert-only transactions do not require features to be locked. Since existing features are not being modified (updated or deleted), there is no need to call GetFeatureWithLock. Any transaction requests with updates or deletions must have a lock ID.

When changes are posted through WFS-T, they are applied to the published version (with versioned data) or to the business tables (with nonversioned data). The following sections discuss important workflow differences to be aware of when working with either versioned or nonversioned data.

WFS-T services and versioned data

The power of versioning allows you to expose your geodatabase to both WFS and non-WFS editors and to effectively merge the edits made by the two groups with full conflict detection. To merge edits, you can reconcile and post the published WFS-T version with its parent. If there are outstanding locks, the system will not allow reconciliation and posting to succeed. This is to prevent conflicts between features locked by a WFS-T client and features changed because of the reconciling and posting process. In addition, reconciling and posting locks the published version, preventing GetFeatureWithLock and Transaction calls during that process. For more information about working with versioned data, see A quick tour of versioning.

Feature locks are kept on the server by means of a locks table. The locks table is created when transactions are enabled and appears as a regular table in the geodatabase. The table is named following the convention VERSION_<versionID>_ROW_LOCKS. To prevent reconciling and posting from being blocked, administrators may want to delete outstanding locks by directly deleting rows from the locks table before reconciling and posting.

The published WFS-T version shouldn't be edited using ArcGIS. An ArcGIS editor isn't aware of feature locks, and therefore, locked features may be edited. In such a case, the edits made in ArcGIS may cause conflicts that prevent the WFS-T client from uploading its changes. Creating and editing child versions of the published version may also cause similar problems if changes are reconciled and posted into the published version.

Multiple WFS-T services can reference the same published version, since all of them share the same locks table. There is a one-to-one association between the published version and its locks table.

If you disable transactions or remove the WFS service, the locks table is not automatically deleted. Once there are no longer any WFS-T services referencing the version, this table can be deleted manually.

WFS-T services and nonversioned data

If you publish nonversioned data in a WFS-T service, the edits are applied directly to the business tables in the geodatabase, so once the edits are committed, they cannot be undone. For more information about working with nonversioned data, see A quick tour of working with nonversioned data.

With WFS-T services based on nonversioned data, feature locks are also kept on the server in a locks table, which is created when transactions are enabled on the service. If you plan to have WFS-T clients only edit through the service, it will have the same behavior as a versioned data-based service. However, if you intend to edit the data published in the service with a non–WFS-T client, such as ArcMap, there are some important things to remember:

• ArcMap editors are not aware of the feature locks, and as a result, features locked through the WFS-T service can be edited.
• If an ArcMap editor edits features, they appear locked to the WFS-T clients. As a result, WFS-T clients cannot lock, update, or delete those features until the ArcMap editor saves the edits.

If you disable transactions or remove the WFS service, the locks table is not automatically deleted. Once there are no longer any WFS-T services referencing the version, the table can be deleted manually.

Additional notes

• When you enable editor tracking on a feature class, make sure that the edits are set to be recorded in UTC. WFS-T services do not support Database Time as the time zone for tracking edits.
• The DBMS user that ArcGIS Server uses to connect to the enterprise, workgroup, or desktop geodatabase geodatabase must be granted permissions to create tables in the DBMS to successfully use WFS-T.
• ArcGIS for Desktop does not have a mechanism for transactional WFS editing, meaning you must use a third-party client to edit features using WFS.
• Feature classes that are z aware cannot be edited using WFS-T.