Mocking Service Callouts to another Apigee proxy

[Ian22]

I have this longstanding issue, which I raised in one of the mad_in_api Q&As in December 2024, about how to test API proxies that have Service Callouts in their flow. This is a common flow that we have:

1. Our Apigee instance receives a message and the corresponding proxy flow starts;
2. As part of that flow, we need to get data from an external system, which we do via a Service Callout (SC) to another proxy. Once we get the response from the SC, the data is used in our flow and the process continues until a target system is called.

As part of developing our proxies, we use Javascript testing libraries to call our proxy (most of the time running Apigee in the emulator, but also in the cloud after deployment) and validate the responses' status codes, payloads, etc. We usually have a flag that prevents Apigee from calling the target system, and instead return the message that would have been sent to the latter.

This works fine for proxies that do not use service callouts, but fails (or forces us to use test cases that actually exist in a target system) when a proxy has a SC, since we get 500s back from the SC.

In the mad_in_api Q&A, @tylerayers presented us his solution using a mock proxy. It seems this could work for my team, but we would like to get more details on how to implement this.

Hope this will be useful for others as well!

[AlexET]

Hello Ian, thanks for sharing this follow-up to your question. Due to the holiday season, there may be some delays in responses, but we truly appreciate your engagement. If anyone else would like to pitch in, we’d love to hear your thoughts to build an enriching conversation around this topic.

Registration for our upcoming office hours is now open! Register here. Also, check out the latest summary of all Apigee-related articles published in 2024 here.

Wishing you happy holidays and a wonderful new year ahead! 😊

[tyayers]

Hi @Ian22 , thanks for reaching out again on this. What I typically do is put callouts in a separate proxy, and then have a way of passing in if they should mock (test mode) or not, then in test scenarios I can set the test flag and call the proxy normally to get test data back. 

An easy way to do this is just have a RaiseFault in the PreFlow that checks for the test flag, and if it's true, returns a static response directly without any further processing. The nice thing is you can also embed variables in the response as well, so use any inputs to make the mock more realistic, without any coding or javascript needed.

Here's my preflow with the RF-TestMode policy on the condition that a url parameter "testmode" is set to true, in which case it then returns a static response and doesn't call the backend.

Here's the RaiseFault policy that sets the payload directly, even embedding the real prompt into the response to make it super realistic.

The source code is in this repository in case you want to take a look: https://github.com/api-integration-samples/apigee-envoy-aigateway.

There are many other ways of doing it - you could also easily use javascript to also set realistic responses with more logic.

I will show this example today in the Office Hours session, so happy to discuss more there, or you can watch the recording, and just reach out with any further ideas or questions on this really interesting topic!