When running a workspace using a WorkspaceRunner transformer in FME some non-standard query string parameters in the WFS url are discarded and/or seemingly randomly replaced by equals signs.

Setup is like this:

Workspace "control":
  creator -> workspace runner (this runs the workspace "wfsread", parameter WFS URL reads https://[serverpath]?SERVICE=WFS&REQUEST=GetCapabilities&NodeId=287

Workspace "wfsread":
  wfs reader -> shapefile writer
  reader URL is "https://[serverpath]?SERVICE=WFS&REQUEST=GetCapabilities&NodeId=287"

Now, when running the control workspace, the log of workspace "wfsread" starts with

2019-01-15 10:12:42| 0.0| 0.0|INFORM|FME Configuration: Command line arguments are 'C:\FME\fme.exe' 'D:/wfsread.fmw' '--SourceDataset_WFS' 'https://[serverpath]?SERVICE=WFS=GetCapabilities=287' '--FEATURE_TYPES' 'L525 L50 L48 L383 L382 L381 L377 L34' '--DestDataset_ESRISHAPE' 'D:\'

...so FME is somehow throwing away the characters "NodeId" and replacing ampersands with equal signs in the call to the wfsread workspace.

Is this a known issue, and/or are there workarounds/settings that can mitigate this?


As the problem starts at the "&" it might be caused by the url not being URL encoded.

Not tested but you might solve this by encode the string with a TextEncoder before feeding it in the FeatureReader.

& --> %26

  • 1
    Thanks for the tip - unfortunately it does not solve the issue, but brought me on the right track - see my answer – til_b Jan 15 at 10:17

Omitting all the OGC parameters from the query string (service, request) and setting the query string inside the control workspace to just https://[serverpath]?NodeId=287 solves the issue. FME appends the OGC parameters automatically and apparently fails sometimes when they are present.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.