Skip to main content
  • EN

I encountered something peculiar and I was wondering how/why this is the case.

 

When I build a JSON document, I am able to fetch a number parameter, and parse that to a string.

When I however try to do the same with a text parameter, and try to parse that to a string, I get an error. See below:

image Also seems related to this old community thread. In some sense I get the error 'undeclared variable' (since in XQuery the '$' is used for variables), but it seems odd that this error does occur for a text parameter and not for a number parameter, and I was wondering how that is possible.

 

Of course there are easy solutions. I generally try to enclose user parameters in double quotes in these situations, like e.g. 

{
    "key": "$(IN_Text)"
}

In that case, (data type parsing) functions also can be used, like e.g. 

{
    "key": xs:string("$(IN_Text)")
}

But in this case that's a bit of a redundant example, as without that data type parsing function, the parameter is already inserted as a string.

 

Just as a caution to other users, similar to the XQuery function 'get-attribute("")' (that's automatically used when you double click on an attribute from the menu), there is also the XQuery function 'fme:parameter-value("")'. but this one has an active issue that it is not aware of the context in which it is used. More particulary, when used in a custom transformer, the 'fme:parameter-value("")' function doesn't work correctly (C662869, FMEENGINE-70950).

 

Then of course there is also the easy option of converting the parameters to attributes with e.g. a ParameterFetcher, but although effective, I think it's not such a clean solution (as you already have the information as a parameter). Also, in case you have one execution of a Custom Transformer, and within it you end up with many more features/records, it always seems a bit inefficient to me to spread out this constant parameter value over all of your features/records.

 

So long story short, I would advise to use the double quotes workaround in the meantime ;)

 

 

 

$(IN_Text) written in a template expression will be replaced with the parameter value as-is when running the workspace.

 

If the parameter value was abc for example,

{ "key" : $(IN_Text) }

will be interpreted as

{ "key" : abc }

and it's apparently incorrect as a JSON document. It's the reason for the error.

 

{ "key" : "abc" }

is intended, you therefore need to write this expression if the parameter value could be a non-numeric representation.

{ "key" : "$(IN_Text)" }

$(IN_Text) written in a template expression will be replaced with the parameter value as-is when running the workspace.

 

If the parameter value was abc for example,

{ "key" : $(IN_Text) }

will be interpreted as

{ "key" : abc }

and it's apparently incorrect as a JSON document. It's the reason for the error.

 

{ "key" : "abc" }

is intended, you therefore need to write this expression if the parameter value could be a non-numeric representation.

{ "key" : "$(IN_Text)" }

Hi @Takashi Iijima​ 

 

Tnx again for sharing your insight.

I know that { "key" : abc } is invalid JSON, which is why in my JSONTemplator I used the xs:string() xQuery function to attemt to parse the value to a string, i.e. I had { "key": xs:string($(IN_Text)) }

 

I guess I was confused by the error "context item": undeclared variable. Because of the term 'variable' I thought it had something to do that the user parameter $(IN_Text) would be misinterpreted for an xQuery variable $VARIABLE.

 

But I just ran some additional checks.

'$(IN_Text)' = 'abc'

{ "key": xs:string($(IN_Text)) } --> ERROR: "context item": undeclared variable

 

'$(IN_Text)' = '1'

{ "key": xs:string($(IN_Text)) } --> { "key": "1" } (thus this works, and the issue was indeed in the text value)

 

And also without a reference to the parameter I get this error:

{ "key": xs:string(abc) } --> ERROR: "context item": undeclared variable

{ "key": abc } --> ERROR: "context item": undeclared variable

 

Thus I think the main thing here was my own misinterpretation of the error message. Thanks for your insight which led me in this direction

 

 

Reply


Community Stats

30,171
Posts
114,532
Replies
37,828
Members
Terms & ConditionsCookie settings
A product of
Safe Software respectfully acknowledges that we live, learn and work on the traditional and unceded territories of the Kwantlen, Katzie, and Semiahmoo First Nations.