How to Create a WFS Service Using FME Flow

Introduction

Using the OGC Web Feature Service (WFS) provides accessibility for your spatial data, meaning that any application that can work with web services can now 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.1and 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 set up to read and serve layers from the included sample SpatiaLite 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: Default of 'mywfs' will work, 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 Include Writers in Stream to return [TEXTLINE]. Click OK then click Publish. 


6. Create a Webhook for the Workspace
A webhook allows users to directly run the workspace using a URL, with no intermediate forms to manually fill in.

Log into 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:


In the final page, copy the URL from the Authorization with Header. This will be the URL to connect to when reading from 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 easily used by WFS viewers, so we will also create a basic authentication to use instead of 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 to 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 a number of ways to ensure that 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 have methods to connect to a WFS Service, and there is also a WFS reader within FME Workbench.

Browser:
To verify your WFS service, use a GetCapabilites request. The resulting XML stream will serve information about the available functionality of the service, 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 up 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 respond to and the layers and WFS version to return. In order to run this workspace successfully in FME Workbench, we will need to supply 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 in the entire URI from the Translation Log into the [FME_SERVER_REQUEST_URI] and 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. In order to test this process in FME Form, we need to supply the workspace with  XML files containing the same parameters that are supplied with 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 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. 


If when running the workspace in the next step, you receive a 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
In order 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 are going to look only 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 XML files that were just created and then run the workspace to test the POST request. Repeat with the other two created XML files. The workspace should run successfully, producing an output file for each request without the need to specify the FME_SERVER_REQUEST_URI 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 perform a query on 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.