Hi Nuwan,

On Tue, May 12, 2015 at 5:32 PM, Nuwan Dias <[email protected]> wrote:

> Aren't we tightly coupling the data publisher and the analyzer by this?
>

No we are not coupling data publishing with analytics here; By the proposed
method, it's simply you can send the tenanted data to respective tenant
space, rather to single super tenant space.

With the change you have proposed, a data published by a particular tenant
> would only be possible to analyze by the same tenant on DAS right?
>

Yes, this is the same way currently other toolboxes behave. Basically the
tenant data will be only analyzed and visualized as per tenant preference,
therefore if the tenant foo.com prefers to visualize the data then he/she
should install the toolbox on DAS. Ideally IMHO there should be a way to
enable to publishing/Monitoring per tenant basis at APIM than enabling
globally for all tenants.


> If that is the case it would cause us to live within a bunch of
> restrictions which might hinder some of our use cases. See below for some
> scenarios.
>
> 1. The analyzer script will have to run on each tenant space, isn't it? If
> so does someone need to manually deploy/configure it per each tenant?
>

Deployment of toolbox is required on DAS.

>
> 2. In API Manager, we have use cases where a particular tenant's API can
> be consumed by other tenant's applications. In this case, the stats related
> to the API are shown under the API owning tenant's space. The stats related
> to the application are shown under the App owning tenant's space. But all
> stats are triggered from the API invocation. At the moment we separate out
> the data based on the information available on the event payload. So we can
> nicely summarize the data accordingly.
>

You still can send the respective tenant data as however you extract
currently, but now it'll go to relevant tenant space, rather single super
tenant space.


>
> If we do the determination of the tenant based on a value in the event
> payload, would it not decouple the publisher and analyzer and cater for
> more possibilities in terms of data summarization/analytics?
>

Having the tenant id in the payload, and setting it in the data publisher
doesn't have any difference in the analytics as far as both are going to be
stored in respective tenant space.

Here the only difference is in the publishing method, where you need to
have separate publishers created for every tenant rather using the same
publisher (you can have a map for tenantId, and datapublisher and then
reuse the data publisher created for tenant). IMO since this is more
cleaner approach, than deciding with convention of having specific
'TenantId' property name. But sending the tenantId in event payload is not
going to have any difference in the analytics perspective, because once the
relevant data is there fore relevant tenant space it's tenant's preference
to deploy the toolbox and analyze it.

Thanks,
Sinthuja.

Thanks,
NuwanD.

>
> On Tue, May 12, 2015 at 11:38 PM, Sinthuja Ragendran <[email protected]>
> wrote:
>
>> Hi all,
>>
>> We (Isabelle, Anjana, Suho, NuwanD,  Mohan, Iranga, Jaminda, and Myself)
>> had a discussion about APIM 1.9 compatibility with DAS last week, and we
>> need $subject to support APIM with DAS in tenant mode. As per APIM stats
>> publishing to BAM 2.5.0, the events are published from super tenant (for
>> all tenants) and having tenant id as separate field in the event. Therefore
>> in BAM 2.5.0 the events are pushed in cassandra the super-tenant space, and
>> toolbox and hive scripts runs on the super tenant space and having another
>> field for tenant id in the summarized table as well. Finally dashboards in
>> APIM will be connecting to one summarized table, and then filter results
>> based on the tenant id for the respective tenants to visualize their
>> statistics.
>>
>> DAS dashboard is going to live in DAS side rather APIM side, and hence
>> the respective tenant users can only connect to their respective tenant
>> data store. Therefore we need to have the statistics events to be pushed
>> into respective tenant space, rather the super tenant space.
>>
>> To cater the above requirement, we will have to introduce below approach
>> in DataPublisher.
>>
>> 1) Create data publisher with privileged super tenant user credentials.
>> 2) setTenantId or setTenantDomain when you want to send the data on
>> behalf of specific tenant.
>> 3) publish events as usual. If the events are being received by BAM 2.5.0
>> then it will simply ignore the tenantId/domain part, and it will simply
>> store the events in the logged in tenant space. In DAS the additional
>> tenantId/domain will be considered, and it will be inserted in the relevant
>> tenant space if the logged in user is a valid user with required
>> permissions.
>>
>> For the above change to be used at APIM 1.9, we need to do a release for
>> DataPublisher on 4.2.0 as APIM 1.9 is based on 4.2.0 carbon. I'll work on
>> this, get the data publisher released soon. Let me know if you have any
>> concerns in above approach.
>>
>> Thanks,
>> Sinthuja.
>>
>> --
>> *Sinthuja Rajendran*
>> Associate Technical Lead
>> WSO2, Inc.:http://wso2.com
>>
>> Blog: http://sinthu-rajan.blogspot.com/
>> Mobile: +94774273955
>>
>>
>>
>
>
> --
> Nuwan Dias
>
> Technical Lead - WSO2, Inc. http://wso2.com
> email : [email protected]
> Phone : +94 777 775 729
>



-- 
*Sinthuja Rajendran*
Associate Technical Lead
WSO2, Inc.:http://wso2.com

Blog: http://sinthu-rajan.blogspot.com/
Mobile: +94774273955
_______________________________________________
Architecture mailing list
[email protected]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Reply via email to