Simulate VerifyAPIKey analytics

Hi all,

I am wondering if it is possible to simulate the analytics behavior that happens when you use the VerifyAPIKey policy.

The situation is that our Apigee does not know the clients, therefore we cannot perform the VerifyAPIKey and populate the default analytics dashboards on the UI. However what we would like to do is populate our analytics dashboards anyway with those values, except they are not coming from the VerifyAPIKey policy. We want to populate those analytics with data retrieved from an LDAP lookup.

So instead by using the StatisticsCollector policy, the idea is to populate the same analytics variables that the VerifyAPIKey populates (this is based on this article https://www.googlecloudcommunity.com/gc/Apigee/StatisticCollector-or-VerifyAPIKey-not-setting-flow-v...)

 

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<StatisticsCollector async="false" continueOnError="false" enabled="true" name="SC-Record-Analytics">
    <DisplayName>SC-Record-Analytics</DisplayName>
    <Properties/>
    <Statistics>
        <Statistic name="apiproduct.name" ref="in.SF-Lib-Record-Analytics.API-Product" type="STRING">defaultValue</Statistic>
        <Statistic name="developer.app.name" ref="in.SF-Lib-Record-Analytics.Developer-App" type="STRING">defaultValue</Statistic>
        <Statistic name="client_id" ref="in.SF-Lib-Record-Analytics.Client-ID" type="STRING">defaultValue</Statistic>
        <Statistic name="developer.email" ref="in.SF-Lib-Record-Analytics.Developer" type="STRING">defaultValue</Statistic>
        <Statistic name="developer.id" ref="in.SF-Lib-Record-Analytics.Developer" type="STRING">defaultValue</Statistic>
    </Statistics>
</StatisticsCollector>

 

However this does not seem to be fully working, as e.g. the Traffic Composition dashboard just shows this:

pietjacobs_0-1658306512677.png

It appears the default value has been set properly in the past, when I pass it as a variable it seems to fail (the variables are correct though...).

Anyone else have any experience with this?

Thanks!
Kind regards, Piet

Solved Solved
1 4 198
1 ACCEPTED SOLUTION

It turns out that there are 2 main requirements before this can work (only tested in OPDK 4.51):

  1. You must have configured at least 1 (mock) developer + api product + app
  2. The Statistics Collector Policy was unhappy with the syntax of my variables (this is a naming convention that we employ), never had any issue with this before. But changing the variables to something like this and it worked:

 

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<StatisticsCollector async="false" continueOnError="false" enabled="true" name="SC-Record-Analytics">
    <DisplayName>SC-Record-Analytics</DisplayName>
    <Properties/>
    <Statistics>
        <Statistic name="api_product" type="string" ref="AnalyticsProduct">defaultValue</Statistic>
        <Statistic name="developer_app" type="string" ref="AnalyticsDeveloperApp">defaultValue</Statistic>
        <Statistic name="client_id" type="string" ref="AnalyticsClientID">defaultValue</Statistic>
        <Statistic name="developer" type="string" ref="AnalyticsDeveloper">defaultValue</Statistic>
        <Statistic name="developer_email" type="string" ref="AnalyticsDeveloper">defaultValue</Statistic>
    </Statistics>
</StatisticsCollector>​

 

The following documentation states however that this is something you "cannot do".
So we are still uncertain if this approach is safe for long-term...

View solution in original post

4 REPLIES 4

I don't have any good ideas here. My inclination is to change this fact:


The situation is that our Apigee does not know the clients,

If you can register the clients in Apigee, even dynamically, then you could use VerifyAPIKey.  

 

 

@dchiesa1 To come back on your reply, thanks for your input btw.
I have noticed that simply registering the clients in Apigee is something that customers not always want to do. It can bring a lot of overhead of managing client id's in 2 places. There then needs to be a mechanism in place to keep the clients in sync (delete/update), so simply registering them once is not enough...

Sure I suppose we could develop something outside of Apigee so that we can dynamically register/update/delete the clients), but this just adds complexity and risk to the implementation. Although it would be interesting to see something like this (in or outside of Apigee), any example implementations that you might know of?

Maybe you disagree with me on all this, but this is just something that happens more and more with customers.


@pietjacobs wrote:

Although it would be interesting to see something like this (in or outside of Apigee), any example implementations that you might know of?


Yes, I agree with you, that it would be very interesting to see something like this, supported in Apigee. The product team has talked about implementing something like this previously. Though I don't believe we've developed a concrete plan on what to implement. 

@gsjurseth FYI

It turns out that there are 2 main requirements before this can work (only tested in OPDK 4.51):

  1. You must have configured at least 1 (mock) developer + api product + app
  2. The Statistics Collector Policy was unhappy with the syntax of my variables (this is a naming convention that we employ), never had any issue with this before. But changing the variables to something like this and it worked:

 

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<StatisticsCollector async="false" continueOnError="false" enabled="true" name="SC-Record-Analytics">
    <DisplayName>SC-Record-Analytics</DisplayName>
    <Properties/>
    <Statistics>
        <Statistic name="api_product" type="string" ref="AnalyticsProduct">defaultValue</Statistic>
        <Statistic name="developer_app" type="string" ref="AnalyticsDeveloperApp">defaultValue</Statistic>
        <Statistic name="client_id" type="string" ref="AnalyticsClientID">defaultValue</Statistic>
        <Statistic name="developer" type="string" ref="AnalyticsDeveloper">defaultValue</Statistic>
        <Statistic name="developer_email" type="string" ref="AnalyticsDeveloper">defaultValue</Statistic>
    </Statistics>
</StatisticsCollector>​

 

The following documentation states however that this is something you "cannot do".
So we are still uncertain if this approach is safe for long-term...