Setting StatusCode in Assign Message not working

[#1]

I have a couple of Assign Message policies used to create a response for a targetless proxy. The first Assign Message creates the response payload as follows:

    <DisplayName>Create Response with Expiration</DisplayName>
    <Properties/>
    <Remove>
        <Headers/>
        <QueryParams/>
        <FormParams/>
    </Remove>
    <Set>
        <StatusCode>201</StatusCode>
        <ReasonPhrase>Created</ReasonPhrase>
        <Payload contentType="application/json" variablePrefix="@" variableSuffix="#">
          {
[....]
          }
      </Payload>
    </Set>
    <IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables>
    <AssignTo createNew="false" transport="http" type="response"/>

The next fills in the Location header for the response:

    <DisplayName>Add Location Header</DisplayName>
    <Properties/>
    <Add>
        <Headers>
            <Header name="Location">{request.path}/{profileId}</Header>
        </Headers>
    </Add>
    <Set>
        <StatusCode>201</StatusCode>
        <ReasonPhrase>Created</ReasonPhrase>
    </Set>
    <IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables>
    <AssignTo createNew="false" transport="http" type="response"/>

I need to set the status code for the response to 201, to indicate that the requested data has been created on the server, but the proxy continues to return 200 instead of the specified 201.

If I try createNew=true in the first Assign Message, the second Assign Message will fail as the request.path variable will be empty.

I have set StatusCode in the past without issue, but cannot see why this particular case fails even though I am setting it twice (originally, I set it only in the first Assign Message).

[#2]

Coulld you please try below things:

1) move IgnoreUnresolvedVariables tag up and keep it just below properties tag.

2) Remove AssignTo tag completely since you are assigning payload to current response variable only.

[#3]

@Manish SinghI have tried moving the IgnoreUnresolvedVariables tag to just below the Properties tag with no effect. I cannot remove the AssignTo tag as these policies are by necessity on the Request flow and need access to the request values as indicated above. Note that I have other similar proxies that can set the status code without issue with AssignTo in the request flow.

[#4]

Hi, @Eric Hildum. Have you used Trace to examine the status code at each step? And are these steps on the Request or the Response side?

You might also try putting the Set > StatusCode XML into a separate AssignMessage step that does nothing else.

[#5]

The steps are on the request side as this is a no target server for this flow. Unfortunately, it appears the trace tool will not show the contents of the response while tracing the request flow, and there is no way to ask the trace tool the value of a flow variable that it does not chose to show.

I tried adding a separate Assign Message with not other content, the proxy still returns 200 instead of the correct 201. @Lee Grey

[#6]

I think the problem could be the fact that you are trying to manipulate the response on the request side. Even though there is no target server, is there any reason why you can't move these policies to the response segments? The fact that trace doesn't show the response on the request flow indicates to me that you are trying to use an object that is out-of-scope.

[#7]

This might help: http://apigee.com/docs/api-services/content/introduction-flow-variables#understandingflowvariablesco...

And this page shows that response.* is not in scope until Target response: http://apigee.com/docs/api-services/api/variables-reference

[#8]

By the way, why does setting createNew to true for a response cause the request variables to be deleted?

[#9]

Follow up. I resolved the issue using @Lee Grey's suggestion of a separate assign message; however, this had to be placed in the response flow, not the request flow where I previously tried it.

What I have found: If you create a new response in the request flow, you can set the entire response content, including status code, with assign message. However, that will apparently clear the request flow variables (in other examples I have used one assign message as the last step of the request flow).

If you edit the existing response with assign messages in the request flow, it is not possible to set the status code in the request flow, instead, an additional assign message policy must be added to the response flow to set the status code (obviously, do not set create new in this policy).