Dynamically calling several back-end endpoints from within Azure APIM policy

Question

I'm calling a back-end API from Azure API Management (APIM) and I need to provide the JSON schema for my custom connector in Logic Apps/Flow.

Depending on the content of the response I'm getting, I need to perform additional calls in order to provide an enumeration/drop down.

Consider a response from the back-end API, like this:

{
  "member1": {
    "prop": "content"
  },
  "member2": {
    "prop": "content",
    "datasource": "http://someurl.com/api/member2/content"
  },
  "member3": {
    "prop": "content"
  },
  "member4": {
    "prop": "content"
    "datasource": "http://someurl.com/api/memberfour/content"
  }
}

I need to perform additional calls to the URLs in the "datasource" members in order to provide additional data, but these are obviously dynamic, depending on the call I'm performing. I'm a bit stuck since I can't seem to perform a send-request policy for a dynamic number of calls and URLs. How would I best approach this?

Barty

If you are using logic apps then you need to get the response from api and then do a for each for the response and perform additional calls. Some thing like this. learn.microsoft.com/en-us/azure/logic-apps/… – Quinquennium

I'm sorry Baskar, my question is not fully clear I'm afraid. What I need to do is provide a JSON schema for my custom connector in logic apps/flow. I will update my question. – Barty

Answer 1

If I understand the scenario correctly, I don't think you want to use APIM to make the calls to the datasource URLs because then you wouldn't be able to get those results back to logic apps. I think what you are looking for is the x-ms-dynamic-values which is documented here

You can use this extension to describe both the primary operation which will provide your content and some secondary operations that will return the lists used to fill the drop downs for the Logic Apps UI. You will probably need to create additional APIM operations to surface those lists.

Drunk

If I understand correctly you may be using x-ms-dynamic-values, but the "values" returned will also be dynamic based on the initial response from API-M, and you want to resolve each of the "values" in the response to return a result to the Logic Apps designer with the correct and full set of values? If so the question may be "is there a way to write a 'make n requests based on the response' for the inbound policy? Is it recommended/ok to use HttpClient in a C# "set-body" policy? – Analyse

@Analyse No you can't use HttpClient from a set-body policy, but with very creative use of the retry policy you can make multiple requests. – Drunk

What if you call an Azure Function with a simple body like an array of URLs you're expecting to parse and get a JSON response back, would that do any good? – Management

@Analyse is exactly right: I already use the x-ms-dynamic-values in my Swagger, so I know how it works. However, for this particular scenario I select a dynamic type of record in my drop down, which in itself already retrieves the schema via x-ms-dynamic-schema in the background. However, in this schema, I would ideally have - again - the option to usex-ms-dynamic-values to fill in the drop downs for certain properties. These values would come from the URLs in the provided datasource for a property. Hope this makes more sense? – Barty

@DarrelMiller: Is there a reason why it is not allowed/possible to be able to call multiple back-end services in a dynamic way (e.g. loop)? I would think this may be a common scenario? – Barty

@Management This is indeed a valid point and definitely possible , but in my given case I would like to keep everything within my APIM policy. – Barty

@PieterVandenheede We haven't run into many cases where users want to do looping constructs in policies that can't be addressed by C# expressions. In this case because you want to make requests within the loop, it's more tricky. However, you can treat the retry policy like a while loop. learn.microsoft.com/en-us/azure/api-management/… – Drunk

@DarrelMiller Now that I think it through, I assume looping over different endpoints is something that is indeed not occurring very often. One would perhaps encapsulate two, perhaps 3 calls, but not much more due to latency. Thank you for elaborating on the retry policy. I think I will need to rethink things. Much appreciated. – Barty