JSON payload not returned as expected.

Hi,

I am facing an issue while setting JSON error payload in Raise Fault policy.

If I am setting the error response as below:

<Payload contentType="application/json">{ "faultresponse": { "status": "failure", "detail": { "code": "xxx202", "text": "not able to perform this operation", "severity": "error" } } } </Payload>

and testing using postman, I am getting the below result:

{ "status": "failure", "detail": { "code": "xxx202", "text": "not able to perform this operation", "severity": "error" } }....here it is skipping the first element faultresponse in the response in postman.

In another scenario , where I am setting the payload as below in raise Fault policy:

(added '\' in front the the JSON payload.)

<Payload contentType="application/json">\{ "faultresponse": { "status": "failure", "detail": { "code": "xxx202", "text": "not able to perform this operation", "severity": "error" } } } </Payload>

I am getting the response as

{ "faultresponse": "failure", "detail": { "code": "xxx202", "text": "not able to perform this operation", "severity": "error" } }.. where the element status is missing and failure is getting mapped to faultresponse.

Kindly suggest why this is happening and how it can be handled.

Solved Solved
0 14 2,803
1 ACCEPTED SOLUTION

Hi @GargiTalukdar,

Please use variable prefix & suffix while defining payload like below -

<Payload variablePrefix="%" variableSuffix="#">

Thanks,

Abhishek

View solution in original post

14 REPLIES 14

Hi @GargiTalukdar,

Please use variable prefix & suffix while defining payload like below -

<Payload variablePrefix="%" variableSuffix="#">

Thanks,

Abhishek

Hi @Abhishek Subramanya

Thanks for the solution. It works with variablePrefix and variableSuffix . But my concern is since I am not using any variable in the payload why is it required to use variablePrefix and variableSuffix.

I had a similar issue and this worked for me. Just like @GargiTalukdar, I want to understand why are these attributes necessary as the Apigee documentation does only quotes them as needed when variables are included, see documentation link below.

http://docs.apigee.com/api-services/reference/raise-fault-policy#faultresponseelement-faultresponses...

Throughout the Apigee platform, the {variable.name} notation is use in XML files to inject variables. As braces are required for JSON objects, these attributes are used to differentiate between variables and JSON objects.

This allows you to create a JSON object with dynamic fields. For example:

{

"developerName":"$developer.name%"

}

...if $ and % are used for the prefix and suffix. Hope this helps!

Thanks @Sean Davis. However, the challenge is about needing the attributes despite not using dynamic fields. The documentation does not state these attributes are mandatory for payloads with no variables but it should.

Hit the "Send Docs Feedback" button in the bottom corner, and the docs team will resolve it quickly 🙂

Thanks, I have sent my comment. First time I do this so let's see how quickly it gets addressed. Thanks @Sean Davis

Hi,

The document on raise-fault-policy mentions to set json payload as below:

\{"name":"foo", "type":"bar"} with a '\'

and to use variablePrefix and variableSuffix while referencing a variable in a JSON payload.

Since in the above scenation I am trying to set the payload without using any variable is it required to use variablePrefix and suffix? I guess I am seeing this issue only in on-premise.

Kindly suggest.

Hi @GargiTalukdar, @gonzalo.silva.cruz, @Sean Davis -

I'm on the doc team, and I've just played with this as well.

The current behavior is in an in-between state right now. We're expecting an update to this in the next major cloud release that may fix the issue (APIRT-1160), currently scheduled for mid-August.

In my testing just now on my free cloud account, I saw similar weird reordering of JSON properties in the response, both in an Assign Message policy and a Raise Fault policy. The only two things worked for me:

  • Escaping the payload like this: \{ "faultresponse": ...
  • Doing a slight tweak to the payload, adding "fault" as the value to the opening property, like this:
    { "faultresponse" : "fault", { "status": "failure", ..

The mere presence of variablePrefix and variableSuffix did not work for me, and those shouldn't be a requirement unless you're going to use those symbols to indicate variables. (The fix will even make those unnecessary, as the product logic will be able to handle {variable} in JSON payloads.)

If variablePrefix and variableSuffix are needed, it's a bug--either because they shouldn't be required, or if they are required, the policy validation doesn't catch it. But if it works for you, great, and please just consider that a temporary workaround. Otherwise, one of my two tweaks above may work for now.

Note that your Private Cloud version may behave slightly differently than the current cloud version.

I've filed a product bug on this (APIRT-3246), just in case it's not covered by the planned fix. Since we tend not to document around bugs in the official documentation, this community thread is the ideal place for folks to find an answer if others are running into this as well.

Thanks!

Thanks @Floyd Jones 🙂

Thanks @Floyd Jones, the additional information is quite interesting. My use case is on public cloud so looking forward to the fix. Hopefully the fix won't break current work arounds. I wonder if you can comment on that as we do depend on this for fault handling.

Hey @gonzalo.silva.cruz - The "official" documented workaround was to escape the opening curly with a backslash. The fix is also supposed to make sure folks who used that workaround don't break. So if the fix is what I understand it to be, it will 1) Allow {variable} in JSON payloads without being required the use variablePrefix/Suffix, 2) render the JSON payload as expected, and 3) not break folks who used the backslash-escape workaround.

After the release, please keep in touch about your experience. You can use this thread, start a new one, drop us a note on the doc site, or/and ping us directly at docs@apigee.com.

Thanks a TON for using the community!

Thanks @Floyd Jones, do you know exactly when the mid August major release is going live? Is there an online calendar I should be following?

@gonzalo.silva.cruz - No exact date. Sorry we can't be more specific.