RaiseFault policy works differently when we moved from free to edge start

Not applicable

Our test api contains just one RaiseFault policy:

<RaiseFault async="false" continueOnError="false" enabled="true" name="TestFault">
    <DisplayName>TestFault</DisplayName>
    <Properties/>
    <FaultResponse>
        <Set>
            <Headers/>
            <Payload contentType="application/json">{"fault":{"code":"UnsupportedOperation", "message":"Requested operation is not supported"}}</Payload>
            <StatusCode>400</StatusCode>
            <ReasonPhrase>Requested operation is not supported</ReasonPhrase>
        </Set>
    </FaultResponse>
    <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>
</RaiseFault>
on free org it works fine:

http://tn-prod.apigee.net/test

returns:

{"fault":{"code":"UnsupportedOperation", "message":"Requested operation is not supported"}}
on start org it removes the wrapper object:

http://tungsten-prod.apigee.net/test

returns:

 {"code":"UnsupportedOperation", "message":"Requested operation is not supported"}
questions:

1. why?

2. is it the only one diff?

the api package:

test-rev1-2016-08-18.zip

Solved Solved
0 5 108
1 ACCEPTED SOLUTION

@Dmitry Lukyanov I think I saw this behavior before but wasn't sure. I think it has to do with variable processing.

I reproduced in my orgs (free and paid) and have a solution, which works in both.

As a standard/best practice always set the variablePrefix and variableSuffix.

<Payload contentType="application/json" variablePrefix="@" variableSuffix="#">
{"fault":{"code":"UnsupportedOperation", "message":"Requested operation is not supported"}}
</Payload>

Don't know why it behaved differently though.

Thanks for providing the API bundle to test.

View solution in original post

5 REPLIES 5

@Dmitry Lukyanov I think I saw this behavior before but wasn't sure. I think it has to do with variable processing.

I reproduced in my orgs (free and paid) and have a solution, which works in both.

As a standard/best practice always set the variablePrefix and variableSuffix.

<Payload contentType="application/json" variablePrefix="@" variableSuffix="#">
{"fault":{"code":"UnsupportedOperation", "message":"Requested operation is not supported"}}
</Payload>

Don't know why it behaved differently though.

Thanks for providing the API bundle to test.

Thanks Kurt!

It works for me.

But the question why the behavior is different remains 🙂

@Dmitry Lukyanov, probably related to https://community.apigee.com/questions/18301/json-payload-not-returned-as-expected.html. An upcoming cloud release is supposed to fix this so that you don't need any variablePrefix or variableSuffix.

Also, are you looking at the response in Trace? If so, try it with cURL (without variablePrefix and variableSuffix) and see if your actual response is different there. Rewriting in Trace is a bug I filed earlier today.

It fails in trace and without trace.

Just click on links:

http://tn-prod.apigee.net/test

http://tungsten-prod.apigee.net/test

curl produces the same result

//

it's the same api deployed to different orgs.

Not applicable

Thanks for the solution.