Hi, can you please have a look at this issue and see if it's a bug that needs fixing?
https://knowledge.safe.com/questions/42262/to-use-comma-in-variable-of-workspacerunner.html
My colleague stumbled into the exact same issue last week. We had to work around it by substituting the comma for something else, then using a StringReplacer in the child workspace to restore the value.
Hi @david_r and @takashi. Thank you for bringing this to my attention. Unfortunately, the WorkspaceRunner not being able to handle commas in parameters of type "Text" is a limitation of the WorkspaceRunner.
From Development:
"Text parameters don’t encode (make value mapping file safe) value where as Multiline Text parameter does. So if the value has characters like comma that needs to survive for the child workspace then the child workspace’s parameter should be configured as Multiline Text."
Please change the Type of the parameter in the child workspace from Text to Text (Multiline), then open the WorkspaceRunner in the parent workspace and re-choose the child workspace. This should fix the problem.
Setting the parameter to Text (Multiline) ensures that it is encoded when passed to the workspace being run, which is called using a command line. This prevents common delimiters from affecting the command line.
Hi @david_r and @takashi. Thank you for bringing this to my attention. Unfortunately, the WorkspaceRunner not being able to handle commas in parameters of type "Text" is a limitation of the WorkspaceRunner.
From Development:
"Text parameters don’t encode (make value mapping file safe) value where as Multiline Text parameter does. So if the value has characters like comma that needs to survive for the child workspace then the child workspace’s parameter should be configured as Multiline Text."
Please change the Type of the parameter in the child workspace from Text to Text (Multiline), then open the WorkspaceRunner in the parent workspace and re-choose the child workspace. This should fix the problem.
Setting the parameter to Text (Multiline) ensures that it is encoded when passed to the workspace being run, which is called using a command line. This prevents common delimiters from affecting the command line.
Hi @david_r and @takashi. Thank you for bringing this to my attention. Unfortunately, the WorkspaceRunner not being able to handle commas in parameters of type "Text" is a limitation of the WorkspaceRunner.
From Development:
"Text parameters don’t encode (make value mapping file safe) value where as Multiline Text parameter does. So if the value has characters like comma that needs to survive for the child workspace then the child workspace’s parameter should be configured as Multiline Text."
Please change the Type of the parameter in the child workspace from Text to Text (Multiline), then open the WorkspaceRunner in the parent workspace and re-choose the child workspace. This should fix the problem.
Setting the parameter to Text (Multiline) ensures that it is encoded when passed to the workspace being run, which is called using a command line. This prevents common delimiters from affecting the command line.
"Note: Any leading or trailing white space is automatically trimmed. To maintain white space, use Text (Multiline)." -- FME Workbench | Creating and Modifying User Parameters
How about adding a comment regarding the limitation about commas here?
Hi @NatalieAtSafe, using a Text (Multiline) type parameter would be a workaround in most cases, but the parameter value seems not to be decoded when it is referred from a reader (and writer?) parameter.
See this thread: How to pass comma separated values in work space runner
I think there still is a room to improve here.
Hi @NatalieAtSafe, using a Text (Multiline) type parameter would be a workaround in most cases, but the parameter value seems not to be decoded when it is referred from a reader (and writer?) parameter.
See this thread: How to pass comma separated values in work space runner
I think there still is a room to improve here.
Hi @takashi,
I have filed a PR on your behalf to look into and address this issue. My apologies for any inconvenience this may have caused (I have also replied with this comment to this related Q&A;)