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.

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.

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

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

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).

 

 

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".

 

 

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:

 

1. Test with the lastest FME 2018. Has this been fixed? If so, that's fantastic.
2. 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.

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

Thanks David_r, that worked! Regards Francois