Is it needed on all backend proxies, or just the logic apps ones? If a customer has two logic app flows (in different logic apps), is the backend proxy the same?

@adrianhall, as I undestood from the discussion, clients wanted to have a proxy parametirization, because they are having only logic apps under the hood of the APIM.

As I see from the documentation of APIM API, we can not identify type of backend resource (view https://docs.microsoft.com/en-us/rest/api/apimanagement/current-ga/backend/get#backendcontract). So I can not determine, if backend resource is a logic app, and set proxy parametrization for it and in the other case just ignore proxy section.

So that is why I decided to put parametrization of proxy section for each backend resource, if proper console flag is set.

What do you think? (sorry if I misunderstood the question)

I'm not disagreeing with the approach just yet. Just asking the question about our API. Can the customer set a different proxy on each backend, or do they set a single proxy for all APIs. Your proposed solution is good for the latter and will cause issues in the former.

I think they can set different proxy on each backend, because we can create 2 or more backend entities from Azure Resources -> Logic Apps, which can have different proxy settings. So by default from the possibilities of user, I think it could be possible.

If that is the case, then I don't like this solution. Customers will use multiple logic apps so will have multiple proxies.

It is hard to control the settings just using some console-boolean flags. So this complex scenario could be supported in this way.

User has to create a configuration for extractor, specifying proxy-parameterization section

{
    ... ,
    "backend-proxy-settings": [
         {
             "proxy-settings-section-name": "my-backend-group-1-name", // unique name of group of backend resources, that need to have the same proxy settings section linked
             "backend-resources-names": [ "my-backend-resource-1", "my-backend-resource-2" ]
         },
         {
             "proxy-settings-section-name": "my-backend-group-2-name", // unique name of group of backend resources, that need to have the same proxy settings section linked
             "backend-resources-names": [ "my-backend-resource-3", "my-backend-resource-4" ]
         }
    ],
    ...
}

This allows to specify anything you want really. Also I like that we will be declining exposing a lot of boolean flag console app arguments, which are very hard to maintain because of their amount. Configurations are always better in my opinion (more code to handle the flow, but much more maintainable and understandable).

What do you think?

Per discussion, we will extract the backend proxy without additional configuration (including no additional boolean command line arg - if backend parameterization is requested, then proxies will be parameterized too). We will determine which proxies are unique and provide a separate parameter for each unique proxy. Care to be taken around "what happens if we add a new proxy" to ensure that existing proxies continue to work with a parameter file. Perhaps by using the URL as part of the parameter name?

I believe we can close this PR, to not take time in resolving conflicts, and change the approach here, PR: #787 introduced which includes agreed changes and ready for review

Closing a PR due to another implementation in #787. Thanks, @f-alizada