Get TargetServer info at runtime

Not applicable

Is there a way to get the info associated with a TargetServer configuration at runtime. For instance if I have configured "cnn" as the key to "http://www.cnn.com" in the Target Servers, I want to use the key cnn to get the host, port, enabled entries associated with it.

The only way I know right now is to call the REST API but I don't want to do that within my proxy for performance reasons. Is this info somehow exposed?

We already have a KVM with various clients that could use different servers, but multiple clients can use the same server, so instead of repeating the info in our KVM we want to just use the target server definition. We could have yet another KVM for this but this functionality already exists in Apigee so we want to leverage that.

Example:

Client1 -> server1

Client2 -> server2

Client3 -> server1

Client4 -> server3

etc.

server1, 2, 3 all defined in Target servers. I read the key from my KVM and lookup the Target server definition, then construct and set the appropriate target.

0 4 709
4 REPLIES 4

Hi @Kevin A,

The basic idea behind target servers is to provide load balancing and failover support.

As of today, we don't have any policy or direct way to fetch target server configurations, apart from the Management API calls.

Now coming to your scenario, you can create an another KVM with key as target server name say server1 and value being the JSON string representation of target server like:

{ 
   "server1" : "{ \"host\" :\"cnn.com\", \"port\": \"9000\", \"enabled\": \"true\"}",
}

Now using your first KVM you can get the client to server mapping.

And with the other KVM which only has the target endpoints configuration in the form of the target server, build the target URL using a Javascript callout or any other policy.

Hope this helps!

Hi @Kevin A

I am not sure how you are defining your Dev apps and products. If you do not want to do another KVM as suggested by @Mohammed Zuber, can you set a custom attribute either on the Product or on the Dev app that defines the server name to which it needs to hit as target server ?

When you use VerifyAPIKey or Oauth VerifyAccessToken policies, these custom attributes are populated as flow variables. Using that as a condition you can set the Route Rules, so for any number of new clients, if the custom attribute to a server is set, the same Route rules conditions will work, so you dont have to change the proxy code. You can have a default target server for ones that do not have that custom attribute set

Again - this is assuming that you are using VerifyAPIKey or OAuth policies and also can consider the custom attributes which is out of the box and can be changed at run time

In the future if you want Client 1 to use Server 3, you just change the custom attribute, the changes reflect immediately and there is no change to the proxy code

Let me know if you have any questions.

adas
Participant V

@Kevin A I think the kvm approach is the best for your use-case. Unfortunately we do not have a policy that exposes the targetserver configuration at runtime. Our runtime engine internally has access to the targetserver entity and its attributes. While I like the custom attribute approach by setting these as attributes of the developer app or the api product, but then it becomes hard to manage. Even the KVM approach is a duplication of information, but there at least you can do a GET of /targetservers/mytarget and directly insert the json or xml as the kvm entry.

Not applicable

thanks for the responses! We went with using a KVM for the lookup for now and that works fine 🙂