Hi All, After several offline discussions we concluded following. This "deletion of tenant related data in tables" scenario is pretty much common to several other products as well(eg : IS). Therefore we need to implement this in a way that the method is commonly accessible for each and every product. Then not only the API Manager (which is already in cloud) other future products which will enter the cloud, will also be able to delete tenant related table data. Following will be our approach.
1. Each product will have *tenantDataTables.xml* file configured with table names(according to deletion order) and data source name 2. New method called *deleteTenantTableData* will be implemented inside *TenantMgtutil* class to run "*DELETE*" queries for a given table name and a given tenant id. 3. Inside *onPredDelete* method of *each product's TenantMgtListener*(eg: APIMgtTenantMgtListener)* , *above method will be called with the table names grabbed from xml file of that product Any thoughts on this will be much appreciated... Thanks On Thu, Sep 18, 2014 at 11:53 AM, Lakshman Udayakantha <[email protected]> wrote: > Hi All, > > We are implementing deletion of tenant data from API Manager. According to > the offline chat with AmilaD, we have to delete a folder created in > <CARBON_HOME>/repository/tenants/$tenantId. After that we have to delete > database entries from WSO2AM_DB. Here we have to search the tenant data > from tenant id, and delete them all. But due to some restriction > constraints(FK,PFK,FAK) data deletion order of tables as we recognised can > be listed below. > > > SP_FEDERATED_IDP > SP_AUTH_STEP > SP_CLAIM_MAPPING > SP_INBOUND_AUTH > SP_ROLE_MAPPING > SP_REQ_PATH_AUTHENTICATOR > SP_PROVISIONING_CONNECTOR > SP_APP > > > > IDP_AUTHENTICATOR_PROPERTY > IDP_AUTHENTICATOR > IDP_LOCAL_CLAIM > IDP_CLAIM_MAPPING > IDP_CLAIM > IDP_ROLE_MAPPING > IDP_ROLE > IDP_PROV_CONFIG_PROPERTY > IDP_PROVISIONING_ENTITY > IDP_PROVISIONING_CONFIG > IDP > > > > > > > > > > > > > > > > > > *AM_APPLICATION_REGISTRATIONAM_APPLICATION_KEY_MAPPINGAM_SUBSCRIPTION_KEY_MAPPINGAM_SUBSCRIPTIONAM_APPLICATIONAM_API_RATINGSAM_API_COMMENTSAM_EXTERNAL_ROLESAM_API_SCOPESIDN_OAUTH2_RESOURCE_SCOPEIDN_OAUTH2_SCOPEAM_API_LC_EVENTAM_APIAM_SUBSCRIBER* > > > > > > > > > > *IDN_OAUTH2_AUTHORIZATION_CODEIDN_OAUTH1A_REQUEST_TOKENIDN_OAUTH1A_ACCESS_TOKENIDN_OAUTH2_ACCESS_TOKENAM_APP_KEY_DOMAIN_MAPPINGIDN_OAUTH_CONSUMER_APPS* > > > Is this approach ok or are there any better approaches to do this? is it > is ok, please suggest for any improvements. > > Thanks > Lakshman > -- > Lakshman Udayakantha > Software Engineer, WSO2 > Mobile: *0711241005* > > *[email protected] <[email protected]>* > > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- *Mahesh Chinthaka Vidanagama* | Software Engineer WSO2, Inc | lean. enterprise. middleware. #20, Palm Grove, Colombo 03, Sri Lanka Mobile: +94 71 63 63 083 | Work: +94 112 145 345 Email: [email protected] <[email protected]> | Web: www.wso2.com
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
