How to Create a WFS Service Using FME Flow

Introduction

Using the OGC Web Feature Service (WFS) provides access to your spatial data, allowing any application that can work with web services to access geographic information. A WFS service can return features with geometry and attributes and also support filters, allowing users to perform spatial and attribute queries. After running through this guide, you will have a functional WFS Service on your FME Flow instance and be able to serve your own spatial datasets.

Technical Details

• The WFS services that are created are compliant with the WFS 1.0, 1.1, and 2.0 specifications.
• Support for both GET and POST.
• Limited to reading features only.
• Ability to utilize a simple attribute filter and/or spatial bounding box filter.

Step-by-step Instructions

Part 1:  Create a WFS Service with FME Flow

For this tutorial, all that is necessary to set up the WFS is the attached workspace and your choice of data. Your data can come from a variety of sources, from a complex database to a simple shapefile.

The attached download package is ready to publish to FME Flow and is configured to read and serve layers from the included sample SQLite database. You may wish to publish the sample and test it in your desired WFS client before modifying the workspace to serve your own data. This section describes where to make changes to use your own data; if you are testing, skip to Part 1 Step 5 to publish the workspace to FME Flow as is.

1. Open Workspace

Download, then open the generic-wfs.fmw workspace in FME Workbench. This workspace creates the WFS Service and can be customized to use with your data.

2. Load Data

In the Navigator window, expand Transformers and double-click on the first one (_Data_Source) to navigate to the FeatureReader transformer. 

Open the _Data_Source FeatureReader. In the parameters, update the Format and Dataset to your desired dataset.

For this example, leave the Format set to SpatiaLite and the Dataset set to Vancouver.sl3. 

3. Modify Workspace Private Parameters

In the Navigator window, expand the Private Parameters section under User Parameters. 

Modify the Private Parameters to fit your data. For this example, they can be left as the default.

• Target Namespace Prefix: The default 'mywfs' works, but you can specify your own namespace (note that 'fme' is reserved and will cause the workspace to fail).
• Target Namespace URI: Your namespace schema, if you change from the default.
• Data Layers to Serve: The layers you wish to serve, space-delimited. These must have the same name as the Layers/Feature Classes/Tables in your source data.
• Default Coordinate System to Serve: The default coordinate system to serve your data in if none is specified in the request. This must be only the EPSG four- or five-digit number (ie., 4326), and must be a coordinate system supported by FME.
• Additional Coordinate Systems: Additional coordinate systems the client can request the data in for WFS 1.1.0 and 2.0.0. This must be a space-separated list of EPSG numbers, from those supported by FME.
• Data Extents: The bounds of the source data. These do not need to be exact. You can use the entire world if you like, but proper bounds will often improve the initial zoom in the WFS client.
• Service Information: These parameters should be modified to provide the Service title, description, and provider contact information.

4. Modify Layer Descriptions

In the Navigator window, expand Bookmarks and double-click on the _Set Layer Title and Abstract bookmark to navigate to it. 

Open the _Set_Titles AttributeValueMapper transformer. Set the Titles for each layer. Any layers not set will be set to the default and get the same layer name as the title. Leave as the default for this example. 

Repeat with the _Set_Abstracts AttributeValueMapper transformer to set the descriptions for each layer. Any layers not set will have a blank description. Leave as the defaults for this example. 

5. Publish Workspace to FME Flow

Publish the workspace to FME Flow. On the Register Services dialog of the publishing wizard, select the Data Streaming Service. Next, click the Edit button to modify the Data Streaming properties. In the properties, set Send HTTP Message Body to Reader to useParameters[XML] and set Include Writers in Stream to return [TEXTLINE]. Click OK, then click Publish. 

6. Create a Webhook for the Workspace

A webhook allows users to run the workspace directly via a URL, with no intermediate forms to fill out.

Log in to FME Flow as an administrator. From the Run Workspace space, select the Repository where the generic-wfs.fmw workspace was published. From the Workspace Actions drop-down menu in the top corner, select Create Webhook. 

Click OK on the Webhook URL page to create the webhook:

On the final page, copy the URL from the Authorization with Header. This will be the URL to use when connecting to the WFS service.

Creating the webhook will also create a token that can be used to authenticate the connection. However, this token cannot always be used by WFS viewers, so we will also implement basic authentication as an alternative to the token.

7. Configure Authentication

To allow access to the WFS service, we will create a dedicated WFS user in FME Flow with access only to the WFS workspace.

Navigate to Users under the User Management section on the side menu. Click the Create button to create a new user.

On the New User page, set the Username, Full Name, and Password to the desired values. For this example, create a WFS user. 

Scroll down to the Permission section for Repositories. Click the drop-down arrow on the right to display all the available repositories, then check the Read and Run boxes for the WFS repository. Also, check the Run Workspace - Access box below the Repositories.

Scroll down to Services, then click the drop-down arrow to display all the available services. Check the Full Access box for the Data Streaming Service:

Finally, scroll all the way to the bottom, then click OK to save the new user.

You can now use the Webhook URL with the new username and password to connect to the WFS service.

Part 2: Verify your WFS Service

There are several ways to ensure your WFS Service is functioning correctly. Listed below is a simple web browser-based method. However, as WFS is a standard, you can use multiple tools. For example, software packages such as ArcGIS, Autodesk IMS, and QGIS provide methods to connect to a WFS Service, and FME Workbench also includes a WFS reader.

Browser:

To verify your WFS service, use a GetCapabilities request. The resulting XML stream will provide information about the service's available functionality, including which Feature Types are available.

Enter the following in the address bar of your browser, editing the string where necessary:

http://<serverhostname>:<port>/fmedatastreaming/<Repository>/generic-wfs.fmw?service=wfs&version=1.1.0&request=GetCapabilities

If you have set up your services correctly, you will receive a string of XML:

Part 3: Testing the Workspaces

It is much faster to test your workspace modifications before publishing to FME Flow. However, in this instance, the workspace requires some information that only FME Flow will provide. Therefore, in order to properly test the workspace, we can manually provide FME Workbench with this information. The next section will go through how to test both GET and POST requests.

GET Requests

When responding to a GET request, the workspace uses the URL that called it to determine which type of request to handle and which layers and WFS version to return. To run this workspace successfully in FME Workbench, we will need to provide sample URLs.

The workspace responds to three different types of requests (GetCapabilities, DescribeFeatureType, and GetFeature), so we will need a sample of each to fully test it.

1. Create a Workspace with a WFS Reader

Return to FME Workbench and open a blank workspace. Add an OGC WFS (Web Feature Service) reader to the canvas, with the webhook URL generated in Part 1 Step 6 above used for the Dataset. Then open the Parameters. 

In the Parameters, click the checkbox next to Use Network Authentication, then enter the Username and Password created with the new WFS user on FME Flow. 

Next, click on the ellipsis next to Feature Types, and then in the Select Feature Types dialog, click Select All. Click OK three times to add the reader to the canvas. 

3. Find the GET Requests

Run the workspace, then examine the Translation Log for lines starting with <WFS>. These specify the URIs for the three different GET requests used in a WFS. You can easily find these in the translation log by using the search button.

4. Test the GET Requests

Return to the generic-wfs.fmw workspace. To test the workspace, you can enter these URIs in the Navigator Window under User Parameters > FME Flow Parameters > [FME_SERVER_REQUEST_URI]

You can only test one request at a time. Additionally, within the URI, you may need to modify the TYPENAME=<> parameter to only include those available in your source data. This parameter is equivalent to exposing feature types in the constraints of the WFS Reader.

Paste the entire URI from the Translation Log into [FME_SERVER_REQUEST_URI], then run the workspace. Open return.xml in a text editor or a web browser to view the results. 

http://<serverhostname>:<port>/fmedatastreaming/<Repository>/generic-wfs.fmw?service=wfs&version=1.1.0&request=GetCapabilities

Repeat with the other two URIs, rerunning the workspace each time. 

http://<serverhostname>:<port>/fmedatastreaming/<respository>?SERVICE=WFS&VERSION=1.1.0&REQUEST=DescribeFeatureType&TYPENAME=mywfs%3Aaccessibleparking%2Cmywfs%3Afire_halls%2Cmywfs%3Aparks%2Cmywfs%3Astreets%2Cmywfs%3Atransitstations%2Cmywfs%3Abikepaths%2Cmywfs%3Adrinkingfountains%2Cmywfs%3Alibraries%2Cmywfs%3Afoodvendors%2Cmywfs%3Acommunitycentres%2Cmywfs%3Aparcels&NAMESPACE=xmlns%28mywfs%3Dhttp%3A%2F%2Fwww.safe.com%2Fgml%2Ffme%29 

http://<serverhostname>:<port>/fmedatastreaming/<respository>?SERVICE=WFS&VERSION=1.1.0&REQUEST=GetFeature&TYPENAME=mywfs%3Aaccessibleparking%2Cmywfs%3Afire_halls%2Cmywfs%3Aparks%2Cmywfs%3Astreets%2Cmywfs%3Atransitstations%2Cmywfs%3Abikepaths%2Cmywfs%3Adrinkingfountains%2Cmywfs%3Alibraries%2Cmywfs%3Afoodvendors%2Cmywfs%3Acommunitycentres%2Cmywfs%3Aparcels&NAMESPACE=xmlns%28mywfs%3Dhttp%3A%2F%2Fwww.safe.com%2Fgml%2Ffme%29&MAXFEATURES=30000

POST Requests

When responding to a POST request, FME Flow supplies the XML reader in the workspace with an XML file containing the request parameters. To test this process in FME Form, we need to supply the workspace with XML files containing the same parameters as the request.  The workspace contains a Logger transformer to aid in this process by logging the POST request XML from a WFS reader. We can extract this XML from the FME Flow log file and use it to create the test XML file.

1. Create a New Workspace

Start a blank workspace. Add an OGC WFS (Web Feature Service) reader to the canvas and, for the Dataset, paste in the same URL used in the GET example.

In the Parameters, check the box next to Use Network Authentication and enter the Username and Password for the WFS user created in FME Flow. Next,  expand Connection Properties and check the Prefer HTTP Post option. Finally, click the ellipsis next to Feature Types, then in the Select Feature Types dialog, click Select All. Click OK three times to add the reader to the canvas. 

If, when running the workspace in the next step, you receive an HTTP Timeout error, change the Connection Timeout Length and Transfer Timeout Length to 400 seconds. 

2. Run the Workspace and Find the Job Logs

Run the workspace and then return to the FME Flow Web Interface, select Jobs > Completed and here you should see that running the WFS Reader in FME Workbench has triggered the last three jobs to run - one job for each of the three requests made: GetCapabilities, DescribeFeatureType and GetFeature, in that order.

3. Create an XML File

To fulfill the WFS POST requests, we will need to extract XML fragments from the log files and copy them into new files. FME always submits GetCapabilities as a GET request, so we will only look at the last two jobs. You can use the following XML to create your own POST GetCapabilities request as the file testGetCapabilities.xml (change the version as desired):

<?xml version="1.0"?>
<GetCapabilities service="WFS" xmlns="http://www.opengis.net/wfs" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.opengis.net/wfs http://schemas.opengis.net/wfs/1.1.0/wfs.xsd"/>

Click on the second-to-last job to open the job dialog, then download the log file. Open the downloaded file in any text editor, then search for xml_fragment. Copy all the XML text within the angle brackets <> (this may span over several lines).

In the text editor, select New and paste the XML text from the log file into the new window. Save the file as testDescribeFeatureType.xml in the same location as your workspace. 

Save xml_fragment as testDescribeFeatureType.xml

Download the last log file from FME Flow and save the xml_fragment to testGetFeature.xml

Save xml_fragment as testGetFeature.xml 

4. Test the POST requests

Back in the generic-wfs.fmw workspace: update the reader to point to one of the newly created XML files, then run the workspace to test the POST request. Repeat with the other two XML files created. The workspace should run successfully, producing an output file for each request without requiring the FME_SERVER_REQUEST_URI to be specified, as we did for the GET functions.

Note: If you are receiving an encoding error, remove encoding="UTF-16 from the created XML files. 

Note: When publishing the workspace to FME Flow, do not include the XML files in the upload.

WFS Service Capabilities

The WFS Service created by this tutorial contains the following operations:

• GetCapabilities: Retrieve metadata about the service, including available Feature Types.
• DescribeFeatureType: Details the requested Feature Type schema.
• GetFeature: Retrieve data.

Filtering Capabilities

Filtering can be used to query the WFS Service data using the GetFeature operation. This workspace supports the following filters:

Attribute Filters:

• PropertyIsEqualTo
• PropertyIsNotEqualTo
• PropertyIsLessThan
• PropertyIsLessThanOrEqualTo
• PropertyIsGreaterThan
• PropertyIsGreaterThanOrEqualTo
• PropertyIsLike
• PropertyIsNull
• PropertyIsBetween

Spatial Filters:

• BBOX

Example Attribute Filtering Syntax:

<Filter><PropertyIsLike><PropertyName>BikePathName</PropertyName><Literal>Seaside</Literal></PropertyIsLike></Filter>

Filter used in a GET Request:

http://<host>:<port>/fmedatastreaming/<RepositoryName>/GenericWFS.fmw?service=wfs&version=2.0.0&request=GetFeature&typeName=mywfs:bikepaths&Filter=<Filter><PropertyIsLike><PropertyName>bikepathname</PropertyName><Literal>Seaside</Literal></PropertyIsLike></Filter>

Example Spatial Filter Syntax:

BBOX=-71.4,42.3,-71.1,42.6

Full Request:

http://<host>:<port>/fmedatastreaming/<RepositoryName>/GenericWFS.fmw?service=wfs&version=2.0.0&request=GetFeature&typeName=mywfs:parks&BBOX=-71.4,42.3,-71.1,42.6

Additional Resources

• OGC Website: WFS Standard
• FME Formats: WFS Reader
• WFS Tutorials: INSPIRE WFS Tutorial
• Troubleshooting: Troubleshooting WFS Errors

Data Attribution

The data used here originates from open data made available by the City of Vancouver, British Columbia. It contains information licensed under the Open Government License - Vancouver.