Tokens in uri not processed

asked on February 28, 2016 • Show version history

I have a HTTP Web Request activity that is calling a REST API web service. I want to use a token in the URI to pass in a parameters into the request. The token substitution does not seem to work. When I remove the token and hard-code a valid value in its place everything works correctly. When I run the workflow with the token the web service request returns a 404. I am pretty sure the token contains a valid value because I use that same token earlier in the workflow to rename the document and that is working as expected.

I tried identifying the URL being called through Fiddler but it does not show the requests executed from Workflow.

2016-02-28_10-59-43.jpg (41.95 KB)

| Download

0 0

SELECTED ANSWER

replied on February 29, 2016 • Show version history

I figured it out. I had to put http://mywebsite/api/app/ as my Host name and then put "%(RetrieveFieldValues_Policy Number)/state" as my URI. Why it would not work with the "api/app" in the URI I am not sure but the only way it seemed to work was to have the token be the first value in the URI.

1 0

View 2 previous replies

replied on April 13, 2018

I was having the same problem and found your post. This saved me a lot of time and trouble (and my sanity). This is still an issue in the latest version of workflow (10.2). The token must be at the beginning of the URI in the web service request section or it does not process correctly.

Thank you.

0 0

replied on April 13, 2018

As Gene said, the URI does resolve tokens. The reason why it didn't in the first case is because prefixing tokens with a slash ("/" in Workflow turns them into their literal text string). So Workflow was specifically (though, unexpected by the user) to not resilve tokens.

Gene's workaround sidesteps the problem by removing the slash in front of the token. The other way to do this would be to use 2 slashes in the URI in front of the token to escape the first one: http://mywebsite/api/app//%(RetrieveFieldValues_Policy Number)/state

1 0

replied on April 16, 2018

That's different, usually it is the backslash that is the "escape" character (turning them into their literal) for strings, not the forward slash.

1 0

replied on April 16, 2018

That does seem different and is definitely unexpected (at least by this user). Is this behavior documented anywhere in the workflow help guide? I spent a considerable amount of time with this issue and was fortunate to find this post to help resolve it. It would be most helpful if Laserfiche could document this in the Workflow HTTP Web Request help text where it is most likely that a token will be used in a URI which normally includes forward slashes in the address. Thanks.

0 0

replied on April 16, 2018

It is documented, though we can maybe add something directly in the HTTP Web Request's documentation. Backslash is only used as an escape character in regular expressions. The backslash is not a suitable escape character for tokens in this context given that one of the most common places where tokens are used is in folder paths.

0 0

Question

Question

Answer

Replies

Sign in to reply to this post.