Hi @philippeb,
One suggestion would be to use the @ReplaceString function - set the string to the published parameter and then replace the space with a 'comma-space':
@ReplaceString($(ChoiceTest)," ",", ")
Which would give me the result:
N2, N4
FME Server is intelligent enough to use quotation marks around parameters if they contain spaces or other special characters. Here are two examples made by publishing a multi-choice parameter and retrieving the value with a ParameterFetcher.
Example without spaces in the choice values:
ROADS = `N1 N2'
Example with spaces in the choice values:
ROADS = `"Way Beta" "Highway Theta"'
So in principle this should be a non-issue, althouth you have to make sure to account for any potential quotation marks, depending on how you process the string value later on.
Hi @philippeb,
One suggestion would be to use the @ReplaceString function - set the string to the published parameter and then replace the space with a 'comma-space':
@ReplaceString($(ChoiceTest)," ",", ")
Which would give me the result:
N2, N4
For the roads name, I'm using this string though :
@ReplaceString($(ChoiceTest),"" "",", ")
Very useful thanks!
For the roads name, I'm using this string though :
@ReplaceString($(ChoiceTest),"" "",", ")
Very useful thanks!
Well, I though it would work but it does only localy. FME Server seems not to place quotes between multi choice values. Explanations above.
FME Server is intelligent enough to use quotation marks around parameters if they contain spaces or other special characters. Here are two examples made by publishing a multi-choice parameter and retrieving the value with a ParameterFetcher.
Example without spaces in the choice values:
ROADS = `N1 N2'
Example with spaces in the choice values:
ROADS = `"Way Beta" "Highway Theta"'
So in principle this should be a non-issue, althouth you have to make sure to account for any potential quotation marks, depending on how you process the string value later on.
Ok so I tried your solution (first time using by myself this transformer, very happy to know this one now!).
I added a ParameterFetcher to my script and localy it works great. I get the quotes for my values.

With FME Server, I get a different result though.
If I choose values from my web page

I just can't get the quotes in FME Server... Into the logs, I see this result.

Are you sure "FME Server is intelligent enough to use quotation marks around parameters if they contain spaces or other special characters"?
I have FME Server 2017.1.1.1.
Well, I though it would work but it does only localy. FME Server seems not to place quotes between multi choice values. Explanations above.
Hi @philippeb,
Unfortunately I can't replicate what you are seeing. If I use an AttributeManager or ParameterFetcher to first view the original ChoiceTest parameter and then use the replace string I get the expected results:

As you can see FME Server places quotation marks around each choice feature as in Desktop. So I would expect using the @ReplaceString function to work in the text editor for you?
Hi @philippeb,
Unfortunately I can't replicate what you are seeing. If I use an AttributeManager or ParameterFetcher to first view the original ChoiceTest parameter and then use the replace string I get the expected results:

As you can see FME Server places quotation marks around each choice feature as in Desktop. So I would expect using the @ReplaceString function to work in the text editor for you?
Hi again @philippeb,
I have been able to reproduce what you see when running the workspace through checking boxes in a web app - I will get back to you on this if I find out anymore.
My first thought is that you need to look at the javascript code of your web page to see how it handles the check box values and how they're transferred to FME Server (I suppose using the REST API).
You can e.g. use the browser developer tools to intercept the json document that's sent to FME Server and that contains the published parameter values. If you could post an example showing how these values are transmitted in the "publishedParameters" json block, that would be helpful.
It should typically look something like this, notice that each value is a separate list item:
{
"name": "BEST_HOCKEY_TEAM",
"value": [
"Vancouver Canucks",
"New York Rangers"
]
}
It should e.g. NOT look like this where the selected items have been concatenated into a single string::
{
"name": "BEST_HOCKEY_TEAM",
"value": [
"Vancouver Canucks New York Rangers"
]
}
Here's an example from the job log in FME Server 2018.1 where I sent the values from the first example above to the published parameter BEST_HOCKEY_TEAM using the REST API:
`--BEST_HOCKEY_TEAM' `"Vancouver Canucks" "New York Rangers"'
As you can see the item containing spaces has been properly quoted.
Just note that values without spaces may not be quoted, so you would need to support a mix of quoted and non-quoted values, e.g.:
`--BEST_HOCKEY_TEAM' `"Vancouver Canucks" HCGotteron'
My first thought is that you need to look at the javascript code of your web page to see how it handles the check box values and how they're transferred to FME Server (I suppose using the REST API).
You can e.g. use the browser developer tools to intercept the json document that's sent to FME Server and that contains the published parameter values. If you could post an example showing how these values are transmitted in the "publishedParameters" json block, that would be helpful.
It should typically look something like this, notice that each value is a separate list item:
{
"name": "BEST_HOCKEY_TEAM",
"value": [
"Vancouver Canucks",
"New York Rangers"
]
}
It should e.g. NOT look like this where the selected items have been concatenated into a single string::
{
"name": "BEST_HOCKEY_TEAM",
"value": [
"Vancouver Canucks New York Rangers"
]
}
Here's an example from the job log in FME Server 2018.1 where I sent the values from the first example above to the published parameter BEST_HOCKEY_TEAM using the REST API:
`--BEST_HOCKEY_TEAM' `"Vancouver Canucks" "New York Rangers"'
As you can see the item containing spaces has been properly quoted.
Just note that values without spaces may not be quoted, so you would need to support a mix of quoted and non-quoted values, e.g.:
`--BEST_HOCKEY_TEAM' `"Vancouver Canucks" HCGotteron'
As you suggest I looked deeper and the check boxes seems to be the problem like @hollyatsafe said. If I run my workspace manually and look at the FME Server topic monitoring, everything looks fine. I get that string :
{"subscriber_content":"{\"DATE\":\"30-10-2018\",\n\"HOCKEYTEAM\":\"\"Montréal Canadiens\"\"Vancouver Canucks\"\"}","ws_topic":"NHLteams"}
But when I choose the values from my web page and check the boxes, I get that string in the monitoring :
{"DATE":"30-10-2018","HOCKEYTEAM":"Montréal Canadiens Vancouver Canucks","ws_topic":"NHLteams"}
When I look into the console in the serviceResponse.fmeTransformationResult.fmeServerResponse.request I get the exact samething as the monitoring.
I'm using Chrome 70.
I based my script with this Safe template, without doing any major changes :
Populate Forms Dynamically
Maybe the problem is in
FMEServer.js and not FME Server itself?
BTW, do you know why my code here isn't in color while yours is? I'm jealous :P
As you suggest I looked deeper and the check boxes seems to be the problem like @hollyatsafe said. If I run my workspace manually and look at the FME Server topic monitoring, everything looks fine. I get that string :
{"subscriber_content":"{\"DATE\":\"30-10-2018\",\n\"HOCKEYTEAM\":\"\"Montréal Canadiens\"\"Vancouver Canucks\"\"}","ws_topic":"NHLteams"}
But when I choose the values from my web page and check the boxes, I get that string in the monitoring :
{"DATE":"30-10-2018","HOCKEYTEAM":"Montréal Canadiens Vancouver Canucks","ws_topic":"NHLteams"}
When I look into the console in the serviceResponse.fmeTransformationResult.fmeServerResponse.request I get the exact samething as the monitoring.
I'm using Chrome 70.
I based my script with this Safe template, without doing any major changes :
Populate Forms Dynamically
Maybe the problem is in
FMEServer.js and not FME Server itself?
BTW, do you know why my code here isn't in color while yours is? I'm jealous :P
Do you use the REST API or something like the jobsubmitter or datadownload service? I ask because there's often some confusion because they don't behave the same way.
Also, if you could post the javascript snippet that generates your json here, that might be helpful.
I wonder if the code window behaves differently if you're on a top-level answer or on a reply?
{
"a_key": "a value"
}
Yup, no highlighting for me either ;-)
Do you use the REST API or something like the jobsubmitter or datadownload service? I ask because there's often some confusion because they don't behave the same way.
Also, if you could post the javascript snippet that generates your json here, that might be helpful.
I wonder if the code window behaves differently if you're on a top-level answer or on a reply?
{
"a_key": "a value"
}
Yup, no highlighting for me either ;-)
Yeah I'm using the REST API, only to send information to FME Server, so he can call my workspace to run and send an email. No data download. I'm calling the REST API from the web page.
There is the code that generates the JSON.
{"DATE": "@Value(DATE)","HOCKEYTEAM": "$(HOCKEYTEAM)"}
Hi again @philippeb,
I have been able to reproduce what you see when running the workspace through checking boxes in a web app - I will get back to you on this if I find out anymore.
Hi @philippeb,
I was able to reproduce your findings using this example here: https://playground.fmeserver.com/javascript/job-submission/populate-forms-dynamically/. My colleague @LauraAtSafe was able to modify the function to include quotes around each of the selected values and then you will be able to implement my suggestion above. Perhaps you can do the same in your case?
I have included a copy of the edited script and we are also going to look into updating the javascript API to handle this better going forward. I hope this helps.
function_runDataDownload.txt
Hi @philippeb,
I was able to reproduce your findings using this example here: https://playground.fmeserver.com/javascript/job-submission/populate-forms-dynamically/. My colleague @LauraAtSafe was able to modify the function to include quotes around each of the selected values and then you will be able to implement my suggestion above. Perhaps you can do the same in your case?
I have included a copy of the edited script and we are also going to look into updating the javascript API to handle this better going forward. I hope this helps.
function_runDataDownload.txt
Hi @hollyatsafe !
Thanks a lot for your reply and your help! I confirm that the changes made by @LauraAtSafe are great and everything works normally now.
When I check the boxes, I get that string now into the monitoring :
{"DATE": "01-11-2018","HOCKEYTEAM": "'Toronto Maple Leafs' 'Montréal Canadiens' 'New York Rangers'","ws_topic": "NHLteams"}
Is there a way to be warned when there is changes into the API ? Do you log the changes? That way, in the future it would be easier for us to know why some of our web pages interacts differently for no reason. (We never experimented this in the past though, we're just starting to use FME Server.)
Now let's hope the best hockey team will be the Montréal Canadiens this year! :P
Hi @hollyatsafe !
Thanks a lot for your reply and your help! I confirm that the changes made by @LauraAtSafe are great and everything works normally now.
When I check the boxes, I get that string now into the monitoring :
{"DATE": "01-11-2018","HOCKEYTEAM": "'Toronto Maple Leafs' 'Montréal Canadiens' 'New York Rangers'","ws_topic": "NHLteams"}
Is there a way to be warned when there is changes into the API ? Do you log the changes? That way, in the future it would be easier for us to know why some of our web pages interacts differently for no reason. (We never experimented this in the past though, we're just starting to use FME Server.)
Now let's hope the best hockey team will be the Montréal Canadiens this year! :P
Hi @philippeb,
I'm pleased that you've managed to get that working now.
That's a good question but it's not something we have currently. Thank you for the feedback, we will try and look into the best way to make changes to the API more easily known.