Disable proxy endpoint according to environment

Google Cloud Apigee
1

Hi,

I have a proxy which is containing multiple proxy endpoints.

Let’s suppose proxy1 and proxy2

now, I want to deploy the same code in both servers dev-int-live, dev-ext-live.

How can I configure that my proxy1 should display only in dev-int-live and not in dev-ext-live?

Is it even possible?

1 Like
2

What do you mean by “display”?

How can I configure that my proxy1 should display only in dev-int-live and not in dev-ext-live?

Do you mean you don’t want proxyendpoint2 to … appear in the Management UI?

3

Sorry… i mean enable the proxy endpoint or disable it

4

There isn’t a way to administratively “enable” or disable a proxyendpoint in different environments.

It is however, possible to include conditional logic in a proxyendpoint that checks the environment name, and sends back a fault if the environment name is not as expected.

For example

<PreFlow> 
  <Request>
    <Step>
      <Condition>NOT (environment.name = "dev-int-live")</Condition>
      <Name>RF-Unsupported</Name>
    </Step>

      ...
  </Request>
   ...

Of course there are elaborations of this idea. For example you could externalize the rules for which proxyendpoints should be “enabled” on which environments, and store it in a KVM. Then at runtime, retrieve that table from KVM (or from some other store), and then evaluate the rules. It might be like this:

<PreFlow> 
  <Request>
    <Step>
      <Name>KVM-Get-EndpointEnablementRules</Name>
    </Step>
    <Step>
      <!-- javascript to evaluate proxy.name against the environment.name -->
      <Name>JS-EvaluateRules</Name>
    </Step>
    <Step>
      <Condition>proxyendpoint_disabled = true</Condition>
      <Name>RF-Unsupported</Name>
    </Step>

      ...
  </Request>
   ...

Depending on how you serialize the rules, the Javascript could be pretty simple. For example in the KVM you could have an entry called proxyendpoint_enable_rules and the value might be a JSON hash with the names of the api proxy bundle, the proxyendpoints, and the environments for each. like this:

{
  "proxybundle1" : {
    "proxyendpoint1" : *,
    "proxyendpoint2" : [ "dev-int-live"],
    "*" : [ "dev-int-live", "dev-iat", "stg", "whatever"] 
  },
  "proxybundle2" : { ... }
}

And then the JS would just check apiproxy.name, proxy.name, and environment.name. maybe like this:

var rules = JSON.parse(context.getVariable('proxyendpoint_enable_rules'));
var bundle = context.getVariable('apiproxy.name');
var isDisabled = true;
if (rules[bundle]) {
  // there's a rule for this proxy bundle
  var endpoint = context.getVariable('proxy.name');
  if (rules[bundle][endpoint]) { 
    // there is a rule for this endpoint
    var env = context.getVariable('environment.name');
    if (rules[bundle][endpoint] == '*') {
      isDisabled = false;
    }
    else if (rules[bundle][endpoint].indexOf(env) >= 0) {
      isDisabled = false;
    }
  }
  else if (rules[bundle]['*']) {
    isDisabled = false;
  }
}
else if (rules['*']) { 
  // enable by default
  isDisabled = false;
}
context.setVariable('proxyendpoint_disabled', isDisabled);

Another elaboration is to factor all that logic out to a sharedflow, and include that sharedflow on the pre-proxy flowhook. Which would mean no changes to any existing proxy.

I’ll leave that part up to you!