Skip to main content
  • EN

This has me stumped. I have a Workflow that has a Parameter --SourceDataset_FFS, which has got 3 Filename Path strings in it corresponding to 3 input FFS files.

 

The Parameter itself is of a Type: "Filename (Multiple)" with a Default value: "C:\\ArcGIS\\Water Script Working\\DEMFFS\\ELEV_DEM_1.ffs","C:\\ArcGIS\\Water Script Working\\DEMFFS\\ELEV_DEM_2.ffs","C:\\ArcGIS\\Water Script Working\\DEMFFS\\ELEV_DEM_3.ffs"

 

Now, running the FMW in WorkBench runs fine, and it passes to FME.exe the Parameter properly formatted by splitting the file names up at the comma delimiter by adding enclosing "" and adding spaces as such:

--SourceDataset_FFS """"""C:\\ArcGIS\\Water Script Working\\DEMFFS\\ELEV_DEM_1.ffs"" ""C:\\ArcGIS\\Water Script Working\\DEMFFS\\ELEV_DEM_2.ffs"" ""C:\\ArcGIS\\Water Script Working\\DEMFFS\\ELEV_DEM_3.ffs""""""

 

However, when I Batch this in another Workflow using WorkspaceRunner, it fails to run the same FMW because it complains that the file paths in --SourceDataset_FFS don't exist.

 

Inspecting the Log, it is because it is parsing the parameter instead as --SourceDataset_FFS "C:\\ArcGIS\\Water Script Working\\DEMFFS\\ELEV_DEM_1.ffsC:\\ArcGIS\\Water Script Working\\DEMFFS\\ELEV_DEM_2.ffsC:\\ArcGIS\\Water Script Working\\DEMFFS\\ELEV_DEM_3.ffs"

 

ie. Instead of recognising that it is Filename(Multiple) Parameter, it doesn't parse it properly across the commas and just joins all the file paths together in one long, non-separated string, which of course creates a malformed Path and why get the error of the path being non-existent.

 

Scratching my head on how to work around this? Setting the Parameter to Private didn't help and even though this meant that it didn't explicitly pass this as an FME shell argument, it still "read" the Private Parameter without the separators and get the same error, so it seems that WorkspaceRunner can't handle FMWs that use a Filename(Multiple) parameter type.

 

FME 2018.1

Workaround I used was a SystemCaller instead of WorkspaceRunner to make sure the Filename(Multiple) parameter is parsed correctly, but that is a little bit "hacky"! Otherwise I'm thinking this is a bug I'm hoping resolves once migrate to FME2020.1

It sounds like this could be the issue where the workspace runner doesn't process a parameter correctly. If you fetch the parameter into an attribute and reference the attribute in the workspace runner that should fix the issue (if it is the issue I'm thinking of).

It sounds like this could be the issue where the workspace runner doesn't process a parameter correctly. If you fetch the parameter into an attribute and reference the attribute in the workspace runner that should fix the issue (if it is the issue I'm thinking of).

@ebygomm​  I'm not sure that is any less of a "hack", but I'll accept it as an Answer! 🙂

So that leads to one stupidly long Workspace, but it seems to work:

  1. Read the FMW itself with a Workspace Reader
  2. Set the "Features to Read" as "Published Parameters" (Noting, that is not listed as an available Feature Type in the Help for the Workspace Reader!)
  3. Use an AttributePivoter/AttributeTransposer to move all the Published Parameter row values to a Single Feature with each Published Parameter value as its own Attribute
  4. Use an AttributeExposer to expose the transposed Published Parameter Attribute
  5. In WorkspaceRunner, override the default Text value for the FileName(Multiple) Parameter with @Value(Parameter Name)

WorkspaceRunner taking in the mutliple filename string as an Attribute, rather than using the same text as hard-coded within the Transformer, for whatever reason causes WorkspaceRunner to parse the text differently. Now it gets parsed out to the FME shell as:

--SourceDataset_FFS {"\\"\\"C:\\ArcGIS\\Water Script Working\\DEMFFS\\ELEV_DEM_1.ffs\\" \\"C:\\ArcGIS\\Water Script Working\\DEMFFS\\ELEV_DEM_2.ffs\\" \\"C:\\ArcGIS\\Water Script Working\\DEMFFS\\ELEV_DEM_3.ffs\\"\\""}

Reply


Community Stats

30,092
Posts
114,244
Replies
37,717
Members
Terms & ConditionsCookie settings
A product of
Safe Software respectfully acknowledges that we live, learn and work on the traditional and unceded territories of the Kwantlen, Katzie, and Semiahmoo First Nations.