I’ve written an article that seeks to build on Ozan’s pattern. While there are elements of this approach I like, and I fully agree with Ozan’s summary “main point”, I recommend some modifications to the approach to fit better with Apigee’s native fault handling, which will reduce code duplication and improve maintenance.
@Ozan Seymen, few years ago I used the same approach on Axway API Gateway and I cannot see any better way to handle errors in a centralized way as you describe here.
Now I’m working on Apigee and this post is exactly want I need.
Thanks for that…
1 Like
Can’t believe I didn’t see this before now, @ozanseymen. Great article – I’m linking to this in the API Platform Learning Guide.
1 Like
Item 2 - if you remove the Response element from the ServiceCallout, it will be a fire-and-forget call. See: https://community.apigee.com/questions/53829/service-callout-policy-for-logging.html
1 Like
Hi @ozanseymen/ @Dino,
Could you please help me with the below scenario:
I have a proxy where there are many service call-outs (6-8 sequential) And so there are many possibilities for custom errors like invalid payload field That does mean that there are many RF/AM/JS should be present.
AM - cannot be used as it wont switch the normal flow to error flow (I assume, help me if there are other)
JS - As call outs are sequential and are many, creating JS for callout can cause additional delay (Correct me if wrong)
(I have seen use of single JS suggested in default rule which also might be having this issue I guess)
RF - I choose this. But on choosing RF for raising custom errors ,there is an issue - on error occurrence , flow will be switched to error flow and reaches to “true” and so gives out error response as :
“{ “fault”: { “faultstring”: “Raising fault. Fault name : Raise-Fault-1”, “detail”: { “errorcode”: “steps.raisefault.RaiseFault” } } }”
So I have added one condition in DefaultFaultRule
RaiseFault.Jsoncustom.error_message != null and (fault.name != “RaiseFault”)
Is this method okay? are there any better way of implementation? Will this affect the logging as the error content sent for logging will be that of RF’s->“steps.raisefault.RaiseFault”?
Great article. Just one comment, using RFs in error flow is marked as antipattern in https://docs.apigee.com/api-platform/antipatterns/raise-fault-conditions . Is this still valid recommendation?