Parsing issue while using Common error Raise Fault

[asharma377]

Hi

i am trying to hit a webserviceand parse the respone to json before return.

In case of success i am able to return the jsonresponsesuccesfully. However, there are situations where i need to do the parsing for exceptions as well.

To handle this i am following steps below

1.

 <Step><Name>XML-to-JSON-1</Name>-</Step>
 <Step><Name>AM-Set-Apigee-Error-Response</Name></Step>
 <Step><Name>FC-Error-Handling-Logging-Shared-Flow</Name></Step>

2. create an assign message policy as below to assign

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<AssignMessage async="false" continueOnError="false" enabled="true" name="AM-Set-Apigee-Error-Response">  
  <DisplayName>AM-Set Apigee Error Response</DisplayName>  
  <AssignVariable>  
    <Name>custom.response.service.status</Name>  
    <Value>ERROR</Value>  
  </AssignVariable>  
  <AssignVariable>  
    <Name>custom.response.status.code</Name>  
    <!--<Value>{response.status.code}</Value>-->  
    <Ref>response.status.code</Ref>  
  </AssignVariable>  
  <AssignVariable>  
    <Name>custom.response.status.string</Name>  
    <Value>Bad Request</Value>  
  </AssignVariable>  
  <AssignVariable>  
    <Name>custom.error.code</Name>  
    <Value>ECB00001</Value>  
  </AssignVariable>  
  <AssignVariable>  
    <Name>custom.error.message</Name>  
    <!--<Value>{response.content}</Value>-->  
    <!--<Ref>test</Ref>-->  
    <Value>test</Value>  
  </AssignVariable>  
  <AssignVariable>  
    <Name>custom.response.content</Name>  
    <!--<Value>{response.content}</Value>-->  
    <Ref>response.content</Ref>  
  </AssignVariable>  
  <AssignVariable>  
    <Name>custom.error.handled.flag</Name>  
    <Value>true</Value>  
  </AssignVariable>  
  <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>  
  <AssignTo createNew="false" transport="http" type="request"/>
</AssignMessage>

3. If i do not execute the step -

<Step><Name>FC-Error-Handling-Logging-Shared-Flow</Name>

I a able to see the error response in JSON format correctly.

4. However, for our project we are using the logging shared flow that first logs the error to SUmologic and then uses Raise Fault policy as below to generate new error and send the response back. It falters at this stage.

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<RaiseFault async="false" continueOnError="false" enabled="true" name="RF-Fault-Error-Template">
    <DisplayName>RF-Fault Error Template</DisplayName>
    <FaultResponse>
        <Set>
            <Payload contentType="application/json; charset=UTF-8" variablePrefix="@" variableSuffix="#">
{
    "serviceStatus" : "@custom.response.service.status#",
    "errorMessages" : [{
            "code": "@custom.error.code#",
            "message": "@custom.response.content#"
        }
    ],
    "data" : null,
    "traceId" : "xxx",
    "spanId" : "xxxx"
}
            </Payload>
            <StatusCode>{custom.response.status.code}</StatusCode>
            <ReasonPhrase>{custom.response.status.string}</ReasonPhrase>
        </Set>
    </FaultResponse>
    <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>
</RaiseFault>

5.

@custom.response.content#

seems non-parse able for some reason though i can see the variable holds the json in correct format. i get error below

Expected ',' instead of 'E'

"Envelope":{"Body":{"Fault":{"faultcode":"AuthenticationFailed","faultstring":"Authentication
 failed. 
(286c1fdc-8404-4e6f-b68b-2cb3165d3c3e)","faultactor":"http:\/\/www.ast.com\/OnDemandIntermediary\/","detail":{"ExceptionCode":"AuthenticationFailed","Message":"Authentication
 failed. 
(286c1fdc-8404-4e6f-b68b-2cb3165d3c3e)","ErrorId":-1000,"RequestId":"286c1fdc-8404-4e6f-b68b-2cb3165d3c3e"}}}}}

[dknezic]

Hi there

Are you able to provide an example of your response.content ?

[asharma377]

thanks i was using both json and string which was the issue.

[DChiesa · Accepted solution]

yes, please tell us what is contained in custom.response.content.

The reason this matters:

You have that variable embedded into a string, in the RaiseFault. If the variable custom.response.content is a simple string, everything is fine. But if the variable contains a double-quote, then the RaiseFault will generate invalid JSON. Any double-quotes in that variable will not be "escaped".

To illustrate, let's look at your template, the template you have in RaiseFault, which is:

{
    "serviceStatus" : "@custom.response.service.status#",
    "errorMessages" : [{
            "code": "@custom.error.code#",
            "message": "@custom.response.content#"
        }
    ],
    "data" : null,
    "traceId" : "xxx",
    "spanId" : "xxxx"
}

First, suppose the custom.response.content contains the following:

error: 17

That's just a simple string. When the template is evaluated, the result will be:

{
    "serviceStatus" : "ERROR",
    "errorMessages" : [{
            "code": "ECB00001",
            "message": "error: 17"
        }
    ],
    "data" : null,
    "traceId" : "xxx",
    "spanId" : "xxxx"
}

That is valid JSON. One of the strings contains a colon, but that's not a problem, because the string is safely wrapped inside double quotes.

Now, suppose the custom.response.content contains the following:

{ "error" : 17 }

That is valid JSON. When the template is evaluated with THAT value in the variable, the result will be:

{
    "serviceStatus" : "ERROR",
    "errorMessages" : [{
            "code": "ECB00001",
            "message": "{ "error" : 17 }"
        }
    ],
    "data" : null,
    "traceId" : "xxx",
    "spanId" : "xxxx"
}

It might be hard to see, but that is not valid JSON. In a JSON payload, The value to the right of each colon needs to be one of:

• a boolean, like true or false
• a number
• a quoted string
• a hash wrapped in curly braces
• an array wrapped in square brackets

But instead what we have is ...

• a string containing an open curly and a space "{ "
• followed by the word "error", which is outside of double-quotes
• a new opening double-quote
• etc.

That's not legal JSON. It looks JSON-ish, but it's not JSON.

PS: If my theory is correct, the problem you are reporting has nothing to do with the FC-* policy.

[asharma377]

Yes you are correct. The response.content is actually situational it could be a json as well as string and thats what was causing the problem. I am putting json in a separate field now and using this only for string. thanks for your help.