Hi all , Currently the *application name * , through which the user calls an api , is not saved in APIMGTSTATS_DB . Plan was to link the WSO2AM_DB and APIMGTSTATS_DB to collect the application based information with out changing hive sripts in BAM.
Could figure out it is only possible with these scenarios. *Per App / Per API / Count* - Using *CONSUMERKEY* in the *API_REQUEST_SUMMARY* table in *APIMGTSTATS_DB* to link with *AM_APPLICATION_KEY_MAPPING* table in * WSO2AM_DB* *Per App / registered users* - DB:* WSO2AM_DB*, Tables: *AM_APPLICATION*, *AM_SUBSCRIBER* *Per App / Top users* - Using *CONSUMERKEY* in the *API_REQUEST_SUMMARY* table in *APIMGTSTATS_DB* to link with *AM_APPLICATION_KEY_MAPPING* table in * WSO2AM_DB* But with other two occasions according to the APIMGTSTATS_DB table structure , it's not possible to get application data linking to WSO2AM_DB. *Per App / Per API / call type* - DB: APIMGTSTATS_DB, Tables: API_RESOURCE_USAGE_SUMMARY - Same API invoked by different applications are counted all together in the TOTAL_REQUEST_COLUMN. *Per App / Per API / faulty count* - DB: APIMGTSTATS_DB, Tables: API_FAULT_SUMMARY - Same problem as *Per App / Per API / call type* * Change suggested:* Adding a new column "app_name" to each required table changing the hive scripts in BAM. This allows to use only APIMGTSTATS_DB for all the stats except *Per App / registered users *stat. On Mon, Mar 17, 2014 at 10:46 AM, Sumedha Rubasinghe <[email protected]>wrote: > Uvindra, > Refactor the current methods to externalise provider, subscriber > dependency. > That way we get to re-use the same data access logic. > > > On Mon, Mar 17, 2014 at 10:10 AM, Uvindra Dias Jayasinha <[email protected] > > wrote: > >> Adding dev list >> >> >> On Sat, Mar 15, 2014 at 6:46 AM, Sumedha Rubasinghe <[email protected]>wrote: >> >>> Folks, >>> Move these into dev list.. :) .. >>> You get a far better visibility of the work being done. >>> >>> As a general rule of thumb, don't do private mails on technical stuff >>> unless you want to clarify something before discussing publicly (even this >>> can be done publicly. But sometime a simple clarification can save lot of >>> lengthy discussions on a public thread). >>> >>> >>> >>> >>> On Fri, Mar 14, 2014 at 12:34 PM, Uvindra Dias Jayasinha < >>> [email protected]> wrote: >>> >>>> Hi Asiri, >>>> >>>> As discussed here are the implementation details for you to get started >>>> >>>> *Intro:* >>>> >>>> Before you get started, note that you will encounter *DTO* classes in >>>> the APIM code base. DTO stands for *D*ata *T*ransport *O*bject. These >>>> classes are simply data structures used to pass data to and from functions. >>>> >>>> All the main changes will be done to the *APIUsageStatisticsClient*class. >>>> >>>> APIMGTSTATS_DB refers to the h2 stats DB in BAM. >>>> WSO2AM_DB refers to the API Manager DB. >>>> >>>> >>>> >>>> >>>> *Implementation details:Per App / Per API / Count* >>>> >>>> - As you already discovered we can use >>>> APIUsageStatisticsClient.getUsageByAPIs() function for this, but we will >>>> need to add the Application name to APIUsageDTO. >>>> - When we do this existing stat in the API publisher will not be >>>> affected, the new stat we are adding can access the Application name >>>> that >>>> was added to the APIUsageDTO. >>>> - The existing functionality of the >>>> APIUsageStatisticsClient.getUsageByAPIs() should not break in any way >>>> due >>>> to the changes that are done! The whole purpose is to reuse existing >>>> code >>>> without duplicating logic. >>>> >>>> >>>> *Per App / registered users* >>>> >>>> - DB: WSO2AM_DB, Tables: AM_APPLICATION, AM_SUBSCRIBER(Get the >>>> Application that the user has registered for from here) >>>> - Currently only the stats DB is being accessed in the >>>> APIUsageStatisticsClient via the dataSource member variable but this >>>> data >>>> is located in the AM_DB. Access the AM_DB connection by using the >>>> APIMgtDBUtil.getConnection() static function. >>>> >>>> *Per App / Per API / faulty count* >>>> >>>> - Reuse APIUsageStatisticsClient.getAPIResponseFaultCount(), but >>>> will need to add the Application name to APIResponseFaultCountDTO. >>>> - Again, make sure that existing functionality does not break. >>>> >>>> *Per App / Per API / call type* >>>> >>>> - DB: APIMGTSTATS_DB, Tables: API_RESOURCE_USAGE_SUMMARY(Get call >>>> types for an API from here) >>>> - DB: WSO2AM_DB, Tables: AM_SUBSCRIPTION(This has the relationship >>>> between Application and API) >>>> - Need to run two separate queries on each DB and combine the data >>>> >>>> *Per App / Top users* >>>> >>>> - DB: APIMGTSTATS, Tables: API_REQUEST_SUMMARY(Get the users who >>>> made the API calls from here) >>>> - DB: WSO2AM_DB, Tables: AM_APPLICATION, AM_SUBSCRIBER(Get the >>>> Application that the user has registered for from here) >>>> - Need to run two separate queries on each DB and combine the data >>>> and Filter by a parameterized top limit(in the same way that the >>>> getUsageByAPIs() does above, see how its done there) >>>> >>>> >>>> Add comments where appropriate to places that you make changes so that >>>> anyone can understand why(the reason) the change was done. We want reuse >>>> existing code as much as possible so keep that in mind as well. >>>> >>>> Please reply to this thread with any questions or clarifications that >>>> you need, don't assume anything, when in doubt ask. >>>> >>>> -- >>>> Regards, >>>> Uvindra >>>> >>>> Mobile: 777733962 >>>> >>> >>> >>> >>> -- >>> /sumedha >>> m: +94 773017743 >>> b : bit.ly/sumedha >>> >> >> >> >> -- >> Regards, >> Uvindra >> >> Mobile: 777733962 >> > > > > > -- *Asiri Liyana Arachchi* Engineering Intern, WSO2 Inc.
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
