Custom Attributes for API Proxy Alternative

[nickolsen]

I have found in some other posts that its not possible to add custom attributes to a proxy like you can an App but I'm looking for a way to tag a specific proxy with an attribute of some sort that can be consumed via a custom javascript policy. The specific use case is for logging. Depending on the proxy we'd like to be able to turn on and off more verbose logging based on some flag that is set somewhere that can be read by javascript.

If this isn't possible, we could have a minimal logging and verbose logging policy that could be added or removed from the API Proxy flow but we were looking for something a bit more dynamic.

[dchiesa1]

I would do this via a KeyValueMap.

The KVM is just a table of keys and values associated to those keys. One could imagine a set of keys representing the proxy name, and a set of values representing "desired log verbosity".

key	value
proxy__proxy1	0
proxy__proxy2	2
proxy__proxy3	9

Use a KVM GET policy to retrieve the KVM. You might embed that KVM policy within a SharedFlow which is attached as a FlowHook in the Pre-Proxy hook. That means the sharedflow will run for every proxy.

The KVM policy might look like this:

<KeyValueMapOperations name='KVM-1' mapIdentifier='nameOfMap'>
  <Scope>environment</Scope>
  <ExpiryTimeInSecs>60</ExpiryTimeInSecs>
  <Get assignTo='desired_logging'>
    <Key>
      <Parameter>proxy</Parameter>
      <Parameter ref='apiproxy.name'/>
    </Key>
  </Get>
</KeyValueMapOperations>

When that runs, the value of the "desired_logging" variable will contain 0, 2, 9, or null, depending on the name of the proxy which is currently executing. You can then test that variable within your JS by doing something like this:

try {
  var desiredLoggingLevel = Number(context.getVariable('desired_logging')); 
  if (desiredLoggingLevel && !Number.isNaN(desiredLoggingLevel)) {
   ... do something with the log here...
  }
}
catch(e) {
  ..handle exceptions
}

You might want some different logic there to handle "default" logging levels.

Also be careful to add tests for the NaN condition, in case the KVM table is updated with invalid data.

You can update the KVM via the Admin API**. According to the KVM policy config I showed here, the cache TTL on the KVM entry within the proxy is 60 seconds, so any update to the KVM table may take that long to be "operational." You can adjust your caching as you see fit.

**In Apigee Hybrid, you cannot update the KVM via the Admin API, but you can build a proxy to update the KVM the way you like.