I am trying to use the WorkspaceRunner to start another workspace. Two parameters are sent along which are linked to published parameters in the latter. One of the published parameters include the "|" character (something like "|abc|def"), causing the workspace that includes the WorkspaceRunner transformer to fail. The Transaction Log has the following output:illegal use of | or |& in command' contains invalid characters and could not be converted into an integer (stfutil.cpp:738)If the published parameter requiring the "|" character is omitted from the latter workspace (ie, it is not required in the WorkspaceRunner anymore), all works fine and the latter workspace is executed as expected.Is there a way to escape the "|" character so that it is not interpreted as a special character when the workspace is run? I have tried |abc|def, "|abc|def", "\\|abc\\|def", ""|abc|def"", ""\\|abc\\|def"", ""|"abc"|"def" and "|"abc"|"def", but all gives the same issue.Any help would be appreciated.

How to use "|" in the parameters of WorkspaceRunner

How are the published parameters defined in the child workspace? Are they of type text or integer?

Try defining the published parameter of type "Text (Multiline)" and see if that makes a difference.

Hi david_r

Thanks for the suggestion, but that did not work. I have also tried setting the type to "Text (Multiline) or Number", but that also did not work. It is currently set as "Text". If I run the child workspace with its default value set to |abc|def, it runs as expected. I think the problem will be resolved if I can somehow pass |abc|def to the child workspace without it being checked for special characters.

This is more or less a known issue when passing parameters through the WorkspaceRunner containing "special" characters.

A workaround may be to use the TextEncoder set to Base64 on your calling workspace and send the encoded text value. In your child workspace, use the TextDecoder also set to Base64 to retrieve the original value.

I would recommend using Text (Multiline) as a parameter type for this.

This is more or less a known issue when passing parameters through the WorkspaceRunner containing "special" characters.

A workaround may be to use the TextEncoder set to Base64 on your calling workspace and send the encoded text value. In your child workspace, use the TextDecoder also set to Base64 to retrieve the original value.

I would recommend using Text (Multiline) as a parameter type for this.

Thanks for the advice. That did not work either. I have tried all possible encodings. Once I run the workspace, it still gives the following error.

Translation FAILED.

' contains invalid characters and could not be converted into an integer (stfutil.cpp:738)

The "illegal use of | or |& in command" part does not appear anymore.

Is there perhaps a way to build a published parameter from two or more received parameters from the calling workspace? Perhaps one can combine two received parameters ("abc" and "def") with two "|" characters in the child workspace side and use this as the value of a published parameter? I have tried this, but once I run the child workspace, it uses the default value for that published parameter instead of the combined string that I have generated to replace the default value.The only way that I found to set a value for a published parameter, was with the WorkspaceRunner.

Thanks for the advice. That did not work either. I have tried all possible encodings. Once I run the workspace, it still gives the following error.

Translation FAILED.

' contains invalid characters and could not be converted into an integer (stfutil.cpp:738)

The "illegal use of | or |& in command" part does not appear anymore.

Is there perhaps a way to build a published parameter from two or more received parameters from the calling workspace? Perhaps one can combine two received parameters ("abc" and "def") with two "|" characters in the child workspace side and use this as the value of a published parameter? I have tried this, but once I run the child workspace, it uses the default value for that published parameter instead of the combined string that I have generated to replace the default value.The only way that I found to set a value for a published parameter, was with the WorkspaceRunner.

Looking at that error message it seems like the published parameter on the child workspace is of the wrong type. You cannot pass text values into a published parameter defined e.g. as an integer type.

The type for the child workspace is set to Text (I also tried Text (Multiline) as you suggested). That is why the error message does not make sense to me either.

Sorry, I meant "the type of the published parameter in the child workspace"...

I was able to reproduce the same error "illegal use of | or |& in command", in a case where the first character of a parameter value was a pipe, regardless whether the parameter type was either Text or Text (MultiLine). |abc|xyz caused the error, but abc|xyz| didn't.

It seems that there is some restriction on the first character in a string to be set to parameter fields in the WorkspaceRunner. Hope someone from Safe would clarify this. @NatalieAtSafe

I was able to reproduce the same error "illegal use of | or |& in command", in a case where the first character of a parameter value was a pipe, regardless whether the parameter type was either Text or Text (MultiLine). |abc|xyz caused the error, but abc|xyz| didn't.

It seems that there is some restriction on the first character in a string to be set to parameter fields in the WorkspaceRunner. Hope someone from Safe would clarify this. @NatalieAtSafe

Thanks Takashi

If this is some limitation on what strings are used, hopefully Safe (or anyone else) could recommend a solution/workaround for this, since I need to pass a string to the published parameters of the child workspace that starts with a pipe symbol.

Here's a sample workaround using the TextEncoder and TextDecoder. Tested with the string "|abc|xyz" and FME 2017.1.2

Master workspace: textencoder.fmw

Child workspace: textdecoder.fmw

Here's a sample workaround using the TextEncoder and TextDecoder. Tested with the string "|abc|xyz" and FME 2017.1.2

Master workspace: textencoder.fmw

Child workspace: textdecoder.fmw

Thank you for the workspaces. This will work if you want to receive the decoded value for a new attribute in the child workspace. In my case, the published parameter itself needs to receive the value (|abc|def) from the parent workspace, not a new attribute. To clarify this a bit further: I am using the Smallworld writer to write to a specific alternative in the database (an alternative is like a specific version/position in the database - it is not important for the scope of this problem, however). The Smallworld writer has a parameter to specify the alternative, which can be linked to a published parameter. This alternative can only be set by changing the value of the published parameter, and it seems that the only way to change the value of a published parameter is with the WorkspaceRunner.

The reason for this requirement is to have a workspace that writes to a Smallworld database, where the alternative to write to can be set dynamically (ie. as an input parameter to the workspace).

I was able to reproduce the same error "illegal use of | or |& in command", in a case where the first character of a parameter value was a pipe, regardless whether the parameter type was either Text or Text (MultiLine). |abc|xyz caused the error, but abc|xyz| didn't.

It seems that there is some restriction on the first character in a string to be set to parameter fields in the WorkspaceRunner. Hope someone from Safe would clarify this. @NatalieAtSafe

If the parameter value should always start with a pipe, creating a scripted parameter which returns a string concatenating a pipe and the published parameter value (without the first pipe), could be a workaround in the interim.

Thank you Takashi, that did it! I did not know anything about TCL scripting, but googled it and got to a blog of yours (http://fme-memorandum-takashi.blogspot.com/2013/10/getting-started-with-tcl-in-fme_21.html) which explained the basics on how to use it.

I was now able to amend the published parameter with the pipes in the child workspace before it ran. Here are the steps that I took to resolve this for completeness.

1. In the child workspace, define a published parameter to take as input from the parent workspace the last part of the string excluding the first pipe (something like "abc|def" instead of "|abc|def"). In my case, this published parameter is called "GIS_ALTERNATIVE".

2. Create another private parameter in the child workspace of type "Scripted (Tcl)". In the Value section, type the following:

set gis_alt $FME_MacroValues(GIS_ALTERNATIVE)

return "|abc|$gis_alt"

The set gis_alt $FME_MacroValues(GIS_ALTERNATIVE) probably creates a local variable for the Tcl script to use and stores whatever was sent to the published parameter GIS_ALTERNATIVE (that is the "def"-part in my initial example).

I have then returned a string that concatenates "|abc|" and what was stored in $gis_alt, the result being "|abc|def".

Thank you Takashi, that did it! I did not know anything about TCL scripting, but googled it and got to a blog of yours (http://fme-memorandum-takashi.blogspot.com/2013/10/getting-started-with-tcl-in-fme_21.html) which explained the basics on how to use it.

I was now able to amend the published parameter with the pipes in the child workspace before it ran. Here are the steps that I took to resolve this for completeness.

1. In the child workspace, define a published parameter to take as input from the parent workspace the last part of the string excluding the first pipe (something like "abc|def" instead of "|abc|def"). In my case, this published parameter is called "GIS_ALTERNATIVE".

2. Create another private parameter in the child workspace of type "Scripted (Tcl)". In the Value section, type the following:

set gis_alt $FME_MacroValues(GIS_ALTERNATIVE)

return "|abc|$gis_alt"

The set gis_alt $FME_MacroValues(GIS_ALTERNATIVE) probably creates a local variable for the Tcl script to use and stores whatever was sent to the published parameter GIS_ALTERNATIVE (that is the "def"-part in my initial example).

I have then returned a string that concatenates "|abc|" and what was stored in $gis_alt, the result being "|abc|def".

It would be nice if Safe could expand the functionality of the WorkspaceRunner so that this workaround is not required in the future.

I would suggest the following:

Test with the lastest FME 2018. Has this been fixed? If so, that's fantastic.
If the problem is still present in FME 2018, it might be a good idea to also push this issue to support@safe.com to try and get a higher priority for a fix.

I would suggest the following:

Test with the lastest FME 2018. Has this been fixed? If so, that's fantastic.
If the problem is still present in FME 2018, it might be a good idea to also push this issue to support@safe.com to try and get a higher priority for a fix.

Thanks David_r

I have contacted support@save.com in this regard, so hopefully they will also let us know if it has been fixed in FME 2018. I will revert if that is the case.

It would be nice if Safe could expand the functionality of the WorkspaceRunner so that this workaround is not required in the future.

Definitely is something we need to address in the WorkspaceRunner. Change request PR82849

This problem has been addressed in FME2018. You have to use Upgrade Transformer to upgrade the FME WorkspaceRunner to Version 3. The new version of WorkspaceRunner creates an FME Command batch file and hence avoids the problems of special characters on the command line. You can also use this to your advantage to batch multiple small tasks using the new parameter: Number of Workspaces per FME Process. See this blog article. So WorkbenchRunner is now doing the same thing as using an FME Command file

Thanks for this Mark. Sorry for this question as it seems straight forward, but how do I upgrade a transformer? I have seen other posts with pictures showing an "Upgradeable Transformers"-heading in the Navigator, but I do not see such a heading in the Navigator. I am using the 32-bit version of FME Workbench 2017.1.2.1, build 17725.

First, you'll have to download and install FME 2018, then open your existing workspace in FME 2018. You should then have the option to upgrade the transformer when you right-click the transformer.

More info here: Working with Transformer Versions

First, you'll have to download and install FME 2018, then open your existing workspace in FME 2018. You should then have the option to upgrade the transformer when you right-click the transformer.

More info here: Working with Transformer Versions

Thanks David_r, that worked! Regards Francois

Reply

Community Stats

Reply

Community Stats

Sign up

An FME Account is required to contribute

Login to the community

An FME Account is required to contribute

Scanning file for viruses.

This file cannot be downloaded