XSL Transformation in Raise Fault

Not applicable

Is there anyway possible to use a XSL Transformation step within a RaiseFault policy. If so is there any documentation on how this can be handled.

Solved Solved
1 1 122
1 ACCEPTED SOLUTION

Nope.

In Apigee Edge, XSL and RaiseFault are two distinct policies.

If you want to Raise a fault, then ... (surprise!) use the RaiseFault policy.

If you want to transform some XML, then use the XSL policy.

In the case that you want to Raise a Fault and transmit some XML there, and that XML needs to be the result of a transform of some OTHER XML. . . . . then what I would do is use the same condition to wrap the XSL, and then the Raise Fault.

Let's look at an example. Suppose your design calls for raising a fault explicitly, if the value of a specific query parameter does not match a specific regular expression pattern. Suppose the pattern is AMG-XXXXX , where the XXXXX is replaced with decimal digits. Not everyone speaks Regular Expressions, so I'll just say: the regex for that pattern is

^AMG-[0-9]{5}$

A condition checking for a match of that is:

request.queryparam.id ~~ "^AMG-[0-9]{5}$"

But we want to raise a fault when that match is NOT found. So we need to negate that condition. Therefore the steps and conditions might look like this:

  <Step>
    <Condition>NOT (request.queryparam.id ~~ "^AMG-[0-9]{5}$")</Condition>
    <Name>XSL-TransformMyXml</Name> 
  </Step>
  <Step> 
    <Condition>NOT (request.queryparam.id ~~ "^AMG-[0-9]{5}$")</Condition>
    <Name>RaiseFault-InvalidValue</Name> 
  </Step>

And presumably the RaiseFault-InvalidValue will reference the output of the XSL step.

Maybe like this:

<RaiseFault name='RaiseFault-InvalidValue'>
  <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>
  <FaultResponse>
    <Set>
      <Payload contentType='application/xml'>{xml_document}</Payload>
      <StatusCode>400</StatusCode>
      <ReasonPhrase>Bad Request</ReasonPhrase>
    </Set>
  </FaultResponse>
</RaiseFault><br>

Does this make sense?

You could also insert a FaultRules element, and insert the XSL transform there. In that case it would execute AFTER the RaiseFault triggers the fault. You would need the appropriate conditions to make sure that XSL step runs only in the cases you want it to run.

View solution in original post

1 REPLY 1

Nope.

In Apigee Edge, XSL and RaiseFault are two distinct policies.

If you want to Raise a fault, then ... (surprise!) use the RaiseFault policy.

If you want to transform some XML, then use the XSL policy.

In the case that you want to Raise a Fault and transmit some XML there, and that XML needs to be the result of a transform of some OTHER XML. . . . . then what I would do is use the same condition to wrap the XSL, and then the Raise Fault.

Let's look at an example. Suppose your design calls for raising a fault explicitly, if the value of a specific query parameter does not match a specific regular expression pattern. Suppose the pattern is AMG-XXXXX , where the XXXXX is replaced with decimal digits. Not everyone speaks Regular Expressions, so I'll just say: the regex for that pattern is

^AMG-[0-9]{5}$

A condition checking for a match of that is:

request.queryparam.id ~~ "^AMG-[0-9]{5}$"

But we want to raise a fault when that match is NOT found. So we need to negate that condition. Therefore the steps and conditions might look like this:

  <Step>
    <Condition>NOT (request.queryparam.id ~~ "^AMG-[0-9]{5}$")</Condition>
    <Name>XSL-TransformMyXml</Name> 
  </Step>
  <Step> 
    <Condition>NOT (request.queryparam.id ~~ "^AMG-[0-9]{5}$")</Condition>
    <Name>RaiseFault-InvalidValue</Name> 
  </Step>

And presumably the RaiseFault-InvalidValue will reference the output of the XSL step.

Maybe like this:

<RaiseFault name='RaiseFault-InvalidValue'>
  <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>
  <FaultResponse>
    <Set>
      <Payload contentType='application/xml'>{xml_document}</Payload>
      <StatusCode>400</StatusCode>
      <ReasonPhrase>Bad Request</ReasonPhrase>
    </Set>
  </FaultResponse>
</RaiseFault><br>

Does this make sense?

You could also insert a FaultRules element, and insert the XSL transform there. In that case it would execute AFTER the RaiseFault triggers the fault. You would need the appropriate conditions to make sure that XSL step runs only in the cases you want it to run.