Private Data in XML Request

[ezninnovation]

I am trying to pass private job data into the XML Post request. However, Switch is not interpreting it as a variable and instead passing it as a string to the post request. I have verified that the private job data exists as it is being use to create the filename after this.

Here is the line I am passing in the "multi line text with variables: Content"

<ProjectName>[Job.PrivateData:Key="orderDetailId"]</ProjectName>

From my understanding, the square brackets tell Switch to interpret this as a variable. Is there another escape character needed?

[magnussandstrom]

Are you using the app 'HTTP Request' and trying to POST a request using SOAP?

[ezninnovation]

Yes I am using the 'HTTP Request' to POST a request using SOAP.

I use a "create text file" to generate a xml file. The xml file that it generates is leaving the [Job.PrivateData:Key="orderDetailId"] as a string instead of inserting the value of the variable.

[freddyp]

I am confused here. You are suggesting that you use "Multi-line text with variables" with "HTTP request", but in the next post you also mention the app "Create text file". Which is it?

If the created text file does not contain the resolved variable, that points to a problem with the app and you should report that to the app creator.

Which version of "HTTP request" are you using?

[ezninnovation]

I did an awful job of explaining what I was doing, and to be honest it was because I did not completely understand. Let me try again.

I am storing job info as private data. Then I am using the app "Create text file" to generate the XML file that is being sent in the HTTP request. Within the HTTP request, I have select request type POST and attached the XML file that was created from the "Create text file" app.

The issue I was running into was actually in the "Create text file" app. The XML file I was creating was not resolving the variable. After digging deeper, the XML code I told it to generate was wrapped with a "!{CDATA[". The reason it could not resolve the variable is because the variable was inside the CDATA section. If I remove the CDATA wrapper then the variable resolves correctly.

My issue now is the HTTP request fails with a 400 error when the CDATA is removed. The HTTP request works when it is wrapped with the CDATA, but the variables don't get resolved. I am working now to figure out how to submit the HTTP request without the CDATA wrapper.

I am on HTTP request version 20.

I hope that makes more sense now. Sorry for the confusion.

[magnussandstrom]

The reason why the variables doesn't resolve is probably because <![CDATA[ contains square brackets that Switch fail to parse those as variables.

A work-a-round could be to add something else then <![CDATA[ and then use the app String Replace to replace those "placeholder values" with <![CDATA[, then send the request.

Example:

1. Create this with Create text file:

<example>
STARTCDATA
Your data and variables
ENDCDATA
</example>

2. Use String Replace like this:

STARTCDATA=<![CDATA[
ENDCDATA=]]>

3. You will get the result:

<example>
<![CDATA[
Your data and variables
]]>
</example>

4. Send it with HTTP request


Maybe there is a better way, but this is ONE way

[freddyp]

Good approach, Magnus! The explanation is indeed the presence of the square brackets that inhibits the correct resolution of the Switch variables.

A few things about CDATA. XML has 5 reserved characters that must be escaped when being used in a value: less than, greater than, ampersand, double quote, single quote. If you have to include in an XML a value that is a (long) string that is likely to contain those characters the result can be very annoying for a human to look at. That would be, for example, the case when putting a JSON as a value in an XML, because a JSON is full of double quotes. An XML inside an XML is another example because that XML will obviously contain lots of those reserved characters. By placing that JSON or XML inside a CDATA construct it can be placed unchanged, so no escaping necessary. It is nicer on the eyes, but software does not have eyes so you could also not use CDATA and escape everything.

In this case the private data looks like it is just an ID. I would be surprised if that ID contained any of the reserved characters, but you never know of course. And even if it did, how long is that ID, so what is wrong with escaping the reserved characters? Theoretically, it does not matter because if you place characters that do not require escaping inside a CDATA they come out the same anyway.

When retrieving a value from an XPath you should get the correct value whether it was embedded in a CDATA construct (the value is unchanged) or not (the value is unescaped). In other words, the problem lies with the HTTP server that does not seem to be doing this correctly.

[tdeschampsBluewest]

A work-a-round could be to add something else then <![CDATA[ and then use the app String Replace to replace those "placeholder values" with <![CDATA[, then send the request.

This is the way!
I had the same problem with some XML control file with bracket a tag value, and it was the only workaround.
A special symbol to escape character within Switch evaluation could be a great addition though @freddy @laurent

[Padawan]

If I'm not mistaken you can escape Switch variables by duplicating the opening bracket.

By example

Code: Select all

[[test]

is seen as

Code: Select all

[test]

in a single line text with variables