No, if you wanted to evaluate the literal string you'd need to use
${literal("REST_URL")}
When you use ${REST_URL:endsWith("...")} you are testing whether or not the
value of the REST_URL
variable ends with ...
Think of it the same as just using the expression ${REST_URL} -- you expect
that to
"resolve the value of the REST_URL variable, then use that as the name of
a variable."
Doesn't seem to make much sense: the plan is to run "endsWith" on value of
REST_URL, doesn't your expression set to tun it on literal string
"REST_URL" within {...} ?
Thank you,
On Fri, Feb 1, 2019 at 8:58 AM
No
On Thu, Jan 31, 2019 at 4:48 PM James Srinivasan
wrote:
> Out of interest, does the URL containing the double slash work?
>
> On Thu, 31 Jan 2019, 21:42 l vic
>> I am using processor group variable as base part of my URL:
>> REST_URL=http://localhost:8080/nifi-api
>>
>> I am trying to
Hello,
The issue appears to be that you're using `${${REST_URL}:endsWith`
at the beginning, which is saying "resolve the value of the REST_URL variable,
then use that as the name of a variable."
So it's looking for a variable named "http://localhost:8080/nifi-api; and never
finds it. So
Out of interest, does the URL containing the double slash work?
On Thu, 31 Jan 2019, 21:42 l vic I am using processor group variable as base part of my URL:
> REST_URL=http://localhost:8080/nifi-api
>
> I am trying to append second part of URL in InvokeHTTP regardless if
> REST_URL ends with
I am using processor group variable as base part of my URL:
REST_URL=http://localhost:8080/nifi-api
I am trying to append second part of URL in InvokeHTTP regardless if
REST_URL ends with '/', or not so that concatenation of "
http://localhost:8080/nifi-api/;, or "http://localhost:8080/nifi-api;
