@pvaziri It looks like @Value(fme_feature_type_poly) is being passed across from the parent workspace (WorkspaceRunner) to the child workspace as a literal string rather than as a value.

Can you attach the two workspaces?

Runnee.log.txtI can only give you an abridged version of the child workspace but since the Readers are failing, that should suffice. Let me know if you need anything else... Thanks for your help and let me know if you need anything else...runner.fmwrunnee.fmw

@pvaziri Thanks for including the workspace and the FME log file. I couldn't reproduce your error - might be a problem with the MFE 2020.1 beta you are using. But there is a problem passing a value directly to the Feature Types to Read parameter. To pass the value to feature types to read, create a new text parameter, then link the feature types to read to that new text parameter See the example workspaces I've attached.

Example WorkspaceRunner & Feature Types to Read (FME 2020): workspacerunner_child.fmwt

I'll try that. Meanwhile, I put together a more compact testing environment for testing if you want to check it out. Hopefully, your solution will work! Runner_Problem_Mtrls.zip

@markatsafe Still didn't work using a created attribute and not fme_feature_type. (although using it is fine in FME 2019. I also tried 2020.0.1 and I'm still experiencing the issue. Here is the updated parent (runner) fmw, and the child (runnee) log. runner.fmw Runnee.log.txt

@markatsafe I'm not sure what this is showing me pertaining to my issue. Maybe I'm thick due to all my social distancing... Please explain further...

@markatsafe I believe my case is proof that 2020 is passing the literal entire string '@value(fme_feature_type_poly)' rather than running in 2019 which is passing just the string 'fme_feature_type_poly'...

One more thing, the Parent/Child fmws need to be saved in FME 2020.0.1 before they fail.

I'd be happy to show you more of what is happening in a brief Zoom session. Then maybe you might better be able to replicate the issue.

I hope to use 2020 and beyond but I needs me WorkspaceRunner to work and I can't upgrade with this issue remaining.

Hi @markatsafe and @daleatsafe,

I'm including this with Dale since he has helped me solve a worspacerunner issue in the past.  Basically, to recap the FME 2020 parent workspacerunner isn't playing nice with the FME2020 child workspace.  Everything seems to work OK when running the same workspace pair in FME2019.

From FME 2020.0.1 parent workspacerunner fmw run log:d 

--FEATURE_TYPES_3 {${=<at>Value<openparen>point_feature<closeparen>=}} 

Again, here's what I'm seeing - 2020 child fmw run log:

--FEATURE_TYPES_3' `<at>Value<openparen>point_feature<closeparen>'

In the FME 2019 parent workspacerunner fmw run log:

 --FEATURE_TYPES_3 point_feature

In the FME 2019 child fmw.run log:

`--FEATURE_TYPES_3' `point_feature'

Obviously, the FME 2019 log snippets are clean of various punctuations (perhaps unnecessary punctuations) that are applied in the 2020 version.  I'm not sure why you aren't able to replicate this...

Again, I'd be happy to Zoom conference / share my screen with you.  I think we need to engage in synchronous communication.

Thanks and stay safe (pardon the pun),

Pete

P.S. My upcoming deadline dictates that this either gets fixed soon or I will have to fall back to running FME 2019, which we would rather avoid...

@pvaziri in the child workspace I have created a User parameter (Text) . Then linked the Feature Class to Read to that Text parameter:

In your case you'd do this twice - once for each Geodb reader

@markatsafe The "dumbing down" of the Child FMW worked. However, this is suboptimal compared to what can be accomplished in FME2019. For instance, if you want to run the Child FMW with Feature Types to Read as a text user parameter, then choosing from a list of possible feature types is not possible. The user also is forced to remember the exact spelling of feature class name(s). This is provided by this more robust type of user parameter:

Basically this should work:

So unlike other 2020 features, I think you took a step backwards here. If you would like to pursue this future, I'm at your service..

@pvaziri it is a problem in workspacerunner. Hopefully it's something we can fix. Just trying to give you a workaround. If the table names are consitent, then you could create a parameter that is a choice list

@markatsafe First of all, thanks for the time you spent providing the workaround. I didn't mean to appear ungrateful for that. I just was pushing for what the fix should look like. So this will be submitted as a bug? If so, that's all I ask.

Thanks again and happy weekend,

Pete

We have addressed this issue for FME 2021. So in future projects you should be able to pass an attribute through WorkspaceRunner