I want to know what is expected when I use this policy to set those variables as follows
I added this policy as the last step in my postFlow
I have an issue with viewing them in the debugging session and even if I download the debugging session file
<?xml version="1.0" encoding="UTF-8"?>
<TraceCapture continueOnError="true" enabled="true" name="TraceCapture-RequestResponse">
<DisplayName>Trace Request and Response</DisplayName>
<Variables>
<!-- Capturing the request path -->
<Variable name="trace-request-path" ref="request.url">/default-path</Variable>
<!-- Capturing a unique request ID -->
<Variable name="trace-request-id" ref="request.header.X-Request-ID">unknown-request-id</Variable>
<!-- Capturing the response status -->
<Variable name="trace-response-status" ref="response.status.code">unknown-status</Variable>
</Variables>
<IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>
<ThrowExceptionOnLimit>false</ThrowExceptionOnLimit>
</TraceCapture>
> I have an issue with viewing them in the debugging session and even if I download the debugging session file
Just to clarify: Trace is not the same as DebugSession, though in the past, we (the Apigee community, both inside Google and outside) have used "Trace" to refer to DebugSession. The TraceCapture policy affects the data that is supplied to a distributed trace session. See the docs for more.
What, specifically, are you expecting to see in the DebugSession that you did not see? I presume you can see the request.url variable if you access it in a policy other than TraceCapture, yes?
yes after enabling Cloud trace I could see those variables printed in the request.
but I have a problem with response.content
somehow it is not captured (set to the default value as shown in pic 1 ).
the response.status.code ( triggers an error in the policy as shown in pic 2 )
even though I put the trace policy in the response post flow. I am sure these variables have values because I have a cloud logging policy and it captures them just fine.
this is the policy code :
Hello,
Is there any specific reason why you put brackets around your reference variable? The syntax should be something as follows:
<Variable name="trace-response-content" ref="response.content">unknown-status</Variable>
please let us know if this works to expectation - it did on my side, thanks!
hartmann, good catch.
yes I don't know of a single place within Apigee where the following syntax is accepted.
<Something... ref="{variable-name}">...</Something> <!-- NO -->
If there is a ref= , the variable name should not be in curlies. I think apigeelint checks for this. If it does not, it should.
There is a case where you wrap variable names in curlies. That is within a message template. a ref= attribute is never going to be a message template.
Tried that without the curly braces first. For some reason that didn’t capture the value
it only worked when i used an assing message policy and used set variable inside it and the passed that variable to the trace policy
what about response.status.code it’s without curly braces. And it returned that error in pic2
also worked when i assigned this value to a variable inside assign message then passed this variable to the trace policy
@dareenhamdy wrote:
what about response.status.code it’s without curly braces. And it returned that error in pic2
Seems like the issue there is, the TraceCapture is expecting a string value, and response.status.code is an integer. (Judging from the error message). I don't know a way around that, beyond using AssignMessage. When you use SetVariable within AssignMessage, you are creating a string. It's a way to convert the type of the variable.
Maybe someone else can offer a suggestion on how to include an integer into the TraceCapture. The behavior you're seeing may just be a limitation or deficiency in the TraceCapture policy. You may want to raise a support ticket to request to have that changed / enhanced. ("Enhance TraceCapture so that it can capture an integer values"). It is surprising to me; it seems like capturing the response code would be a common use of TraceCapture.