Using the OGC Web Feature Service (WFS) provides accessibility for your spatial data, meaning that any application which 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 Server and be able to serve you own spatial datasets.
The workspace was originally built and tested using FME 2015.1 and updated using FME 2018.1.
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.
Note: This workspace contains Python. FME 2019 will mark the beginning of the phase-out process for compatibility with Python 2.7. For more information, please read Python 2.7 deprecation.
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 (eg. PostGIS) to a simple shapefile.
The attached download package is ready to publish to FME Server 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.
Open the Transformers in the Navigator Window.
Click on the first transformer (_Data_Source) to navigate to the FeatureReader.
Open the transformer properties and modify the reader settings to read your desired source data.
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.
Open the Bookmarks in the Navigator Window.
Click on the second bookmark (_Set Layer Title and Abstract) to navigate to it.
Use the Bookmarks section of the Navigator to find a section of the workspace.
Open the Properties of the _Set_Titles transformer to set the Titles for each layer. Any layers not set will be set to default and get the layer name as the title.
Open the Properties of the _Set_Abstracts transformer to set the descriptions for each layer. Any layers not set will have a blank description.
Use an AttributeValueMapper to set the titles and abstracts to be displayed for each feature.
On the Register Services window, check the Data Streaming Service properties to ensure that Include Writers to Stream is set to the Textline writer and that the Send HTTP Message Body to Reader is useParameters[XML].
Publish the workspace to the Data Streaming Service on FME Server.
To allow guest access to run the workspace you can modify the Role Policies for the fmeguest account to allow Read/Run access to your repository. This will ensure that anyone can access your service without a username and password. See here for more information about using the Trusted User Account: Role-Based and User-Based Access Control.
Give the fmeguest role on FME Server access to the repository where your WFS is located.
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.
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.
Test the WFS service is running correctly using the GetCapabilities request.
It is much faster to test your workspace modifications before publishing up to FME Server. However, in this instance, the workspace requires some information that only FME Server 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.
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.
The easiest way to get these sample URLs is to publish the initial workspace to a sample repository and then using the Direct URL used to run this workspace within an WFS Reader in FME Workbench.
In the FME Server web interface, navigate to the GenericWFS workspace and click on it. From the Run Workspace page there is an Advanced section, this is where you will find the Direct URL.
Return to FME Workbench and open a blank workspace. Add a WFS reader and for the dataset copy this URL located above.
Open up the Parameters… and under Constraints > Feature Types check the Select all button. You can also define the WFS Version in this window.
Run the workspace, then examine the log window for lines starting with <WFS>. These specify the URLs for the three different GET requests used in a WFS. You can easily find these in the translation log by using the search button.
Return to the GenericWFS.fmw file. To test the workspace you can enter these URLs in the Navigator Window under User Parameters > FME Server Parameters >FME Server Request URI.
You can only test one request at a time. Additionally, within the URL, 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.
The output for each request will be written to the same folder as the workspace under the file name return.xml.
Generating POST requests for testing purposes is a little more complicated and first requires you to create an XML file based on information created in the job log files on FME Server. The contents of this file will then be used instead of the Direct URLs in the GET request example shown above.
Start with a blank canvas and adding a WFS reader as you did above. However, this time in Parameters… expose the Connection Properties and check the Prefer HTTP Post option.
Run the workspace and then return to the FME Server 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.
Click on the second job to open the job dialog, from here you can either search within the log on the web page (Ctrl+F) or download the log file. Search for xml_fragment and copy all the text within the angle brackets <>.
In the text editor select New and save the file as useParameters.xml in the same location as your workspace. Now select the XML text from the log file (this may span over several lines) and copy it into the useParameters.xml file.
Repeat this process for both the DescribeFeatureType and GetFeature job logs to test the POST requests - in the original workspace the job should run successfully producing output files for each request without the need to specify the FME_SERVER_REQUESR_URI as we did for the GET functions.
After your testing is complete, the useParameters.xml file should be deleted before the workspace is published to FME Server.
DescribeFeatureType: Details the requested Feature Type schema.
Location of filtering options in genericWFS.fmw workspace.