Hi Rukshan, Please my answer to your concern below
*I think we can reuse the existing data. Even though we define recording policy, all the possible data is stored in the analytics DBs regardless of the recording policy. So we should be able to correlate this recording policy with stat data and filter out required data from the Billing engine.* As discussed offline , I dont think that we can use only the existing data without modifying or creating a new Aggregation. If we assume we define the recording policy based on the response code , we do not store the response code anywhere in Request count Aggregation. So providing the successful count based on the response code is impossible without altering or creating a new aggregation. but we can decide whether we are going to add this to an existing aggregation or create a new one. If we try to add the above policy to the existing aggregations we will have to modify the queries that read the data from the aggregation to populate graphs. Also we will always have to modify the queries , whenever there is a change in the policy (based on some user requirement). Also it will compel to store the above data irrelevant of whether the monetization is enabled or not , hence i believe creating a separate aggregation(create tables internally) can ease lot of things in future Thanks, Silmy. On Fri, Apr 5, 2019 at 2:51 PM Rukshan Premathunga <[email protected]> wrote: > > > On Fri, Apr 5, 2019 at 2:46 PM Silmy Hasan <[email protected]> wrote: > >> Hi Bhathiya, >> >> Please find my answers for your concerns, >> >> *I think we can do this check at the time they enable monetization for an >> API*. >> +1 >> >> *Why do we need separate tables here? Can't we use the existing stats >> data here?* >> We need a separate table here because we check whether the response for a >> particular request is delivered successfully based on some set policy, >> before taking it as a count to bill. But in the current stats there is no >> such a check when we aggregate the request count and all of them are simply >> added to the count through API Request count Aggregation. So if we try to >> add this also to the same aggregation as a new column then it will create a >> separation among the request count aggregated and will have to modify the >> aggregation and existing queries which we used to get data from these >> aggregations. >> Hence creating a separate table would very much simplify this. >> > I think we can reuse the existing data. Even though we define recording > policy, all the possible data is stored in the analytics DBs regardless of > the recording policy. So we should be able to correlate this recording > policy with stat data and filter out required data from the Billing > engine. > >> >> Thanks, >> Silmy. >> >> On Fri, Apr 5, 2019 at 2:38 PM Silmy Hasan <[email protected]> wrote: >> >>> Hi Bhathiya, >>> >>> Please find my answers for your concerns, >>> >>> *I think we can do this check at the time they enable monetization for >>> an API*. >>> +1 >>> >>> *Why do we need separate tables here? Can't we use the existing stats >>> data here?* >>> We need a separate table here because we check whether the response for >>> a particular request is delivered successfully based on some set policy, >>> before taking it as a count to bill. But in the current stats there is no >>> such a check when we aggregate the request count and all of them are simply >>> added to the count through API Request count Aggregation. So if we try to >>> add this also to the same aggregation as a new column then it will create a >>> separation among the request count aggregated and will have to modify the >>> aggregation and existing queries which we used to get data from these >>> aggregations. >>> Hence creating a separate table would very much simplify this. >>> >>> Thanks, >>> Silmy. >>> >>> On Fri, Apr 5, 2019 at 2:25 PM Bhathiya Jayasekara <[email protected]> >>> wrote: >>> >>>> Hi Chamin, >>>> >>>> On Fri, Apr 5, 2019 at 1:26 PM Chamin Dias <[email protected]> wrote: >>>> >>>>> Hi all, >>>>> >>>>> We are in the process of providing support for monetization in APIM. >>>>> We have performed a pre-analysis of $subject and came up with the initial >>>>> design. >>>>> >>>>> For the initial implementation, we plan to use Stripe and implement >>>>> the necessary functions to support monetization flow in the product. >>>>> >>>>> Please find the details below. >>>>> >>>>> *A) Prerequisites* >>>>> >>>>> 1. API provider should have a stripe account. >>>>> 2. API subscriber should have a credit card (to use paid APIs). >>>>> 3. API analytics should be enabled (since we need to publish some data >>>>> in the DB related to this) >>>>> >>>>> >>>>> *B) There should be few mappings between APIM and Stripe for some >>>>> objects/actions.* >>>>> >>>>> - Object/action in APIM : Attaching a paid tier to an API >>>>> - Corresponding object/action in Stripe : Plan [1] >>>>> >>>>> >>>>> - Object/action in APIM : API subscriber >>>>> - Corresponding object/action in Stripe : Customer [2] >>>>> >>>>> >>>>> - Object/action in APIM : Subscribing to an API >>>>> - Corresponding object/action in Stripe : Create a subscription >>>>> [3] in stripe >>>>> >>>>> >>>>> - Object/action in APIM : Invoking APIs >>>>> - Corresponding object/action in Stripe : Charging [4] in stripe >>>>> >>>>> >>>>> *C) This is the flow.* >>>>> >>>>> 1. API provider creates an API. At the time of attaching a paid tier >>>>> to his API, we check for the existence for the stripe account of the >>>>> provider. If it is there, we create a "plan" [1] in the stripe side to >>>>> indicate the attachment if the tier to the API. If the API provider does >>>>> not have a stripe account, then we notify them to create an account and >>>>> come back. >>>>> >>>> >>>> I think we can do this check at the time they enable monetization for >>>> an API. >>>> >>>> >>>>> >>>>> 2. API subscriber (app developer) subscribes to an API. If this is >>>>> done through a paid tier, then we create a "customer" [2] object in stripe >>>>> side using the stripe account of the API provider. In other words, this is >>>>> the indication that this app developer is a customer if the corresponding >>>>> API provider. A "subscription" [3] will be created in stripe side after >>>>> capturing the credit card data. >>>>> >>>>> 3. When the API is consumed (i.e - invoked), we record the data in the >>>>> corresponding data table (we will need a separate table(s) for this). >>>>> >>>> >>>> Why do we need separate tables here? Can't we use the existing stats >>>> data here? >>>> >>>> Thanks, >>>> Bhathiya >>>> >>>> >>>>> >>>>> 4. Every day, at a given time (say at 00:00), we run a scheduled task >>>>> and identify the customers (i.e - who has reached the end of the billing >>>>> cycle - say 1 month) to be billed. If we find such customer, then APIM >>>>> sends a "charge" [4] request to the respective customer (i.e - App >>>>> developer) based on the usage data we have collected in the DB. >>>>> >>>>> Please share your thoughts/suggestions if you have any. >>>>> >>>>> [1] Plan : https://stripe.com/docs/api/plans?lang=curl >>>>> [2] Customer : https://stripe.com/docs/api/customers?lang=curl >>>>> [3] Subscription : https://stripe.com/docs/api/subscriptions?lang=curl >>>>> [4] Charge : https://stripe.com/docs/api/charges?lang=curl >>>>> >>>>> Thanks. >>>>> >>>>> -- >>>>> Chamin Dias >>>>> Mobile : 0716097455 >>>>> Email : [email protected] >>>>> LinkedIn : https://www.linkedin.com/in/chamindias >>>>> >>>>> >>>> >>>> -- >>>> *Bhathiya Jayasekara* >>>> *Technical Lead,* >>>> *WSO2 inc., http://wso2.com <http://wso2.com>* >>>> >>>> *Phone: +94715478185* >>>> *LinkedIn: http://www.linkedin.com/in/bhathiyaj >>>> <http://www.linkedin.com/in/bhathiyaj>* >>>> *Twitter: https://twitter.com/bhathiyax <https://twitter.com/bhathiyax>* >>>> *Blog: http://movingaheadblog.blogspot.com >>>> <http://movingaheadblog.blogspot.com/>* >>>> >>> >>> >>> -- >>> Shilmy Hasan >>> Associate Software Engineer | WSO2 >>> >>> E-mail :[email protected] >>> Phone :0779188653 >>> web : http://www.wso2.com >>> >>> [image: https://wso2.com/signature] <https://wso2.com/signature> >>> >> >> >> -- >> Shilmy Hasan >> Associate Software Engineer | WSO2 >> >> E-mail :[email protected] >> Phone :0779188653 >> web : http://www.wso2.com >> >> [image: https://wso2.com/signature] <https://wso2.com/signature> >> _______________________________________________ >> Architecture mailing list >> [email protected] >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> > > > -- > Rukshan Chathuranga. > WSO2, Inc. > +94711822074 > -- Shilmy Hasan Associate Software Engineer | WSO2 E-mail :[email protected] Phone :0779188653 web : http://www.wso2.com [image: https://wso2.com/signature] <https://wso2.com/signature>
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
