Multi Tenancy question

rocketman

Hi all,

I'm starting work on moving my main app to be multi-tenancy with the aim of providing a europe wide database of pilots and aircraft, but with each individual club retaining their local flight records, charging their own membership fees etc etc.

I was wondering - is there a type of BO that could hold records for each club - similar to what I now hold in SystemSettings, which could be searched for on first load and then held in context throughout the session irrespective of where the user jumps to?

The idea being a pilot will log on using their new unique european pilot license number. His record will hold a reference pointer to his home club, AIM will then search for the home club record where all the main club info is held, and then hold that record in context until the user logs out.

pbrad

Hi,
The way that I typically handle it is to create a Client(Club) object and then relate relevant objects to that client such as users and flight records. for example:

FIND FlightRecord WHERE(FlightRecord.xxx=yyy AND FlightRecord.Club=LoggedInRegularUser.Club

You will just need to tweak most of your queries to include a reference to the logged in user's club and you should be good to go.

Cheers,
Pete

rocketman

Woah .... So simple, thanks Pete.

customaware

Based on the above.....

How do you manage the situation whereby at some later point in time you may want to take all the data for a particular tenant and set it up on a separate server?

I assume it means you have to scan every BOs data and extract that one by one?

Would be nice if there was a way to have each different tenant in a different database but all accessing the same bsv. I am guessing there is no way to do that?

hpl123

Hi Mark,
It depends on the size I guess of every tenant but one way of achieving this is to create a new BSV for every tenant and I think this can be automated today so a new BSV is created when a new user registers. This would enable you to get more control over each tenant e.g. backup, email etc.

kklosson

To answer eagles, you'll need some sort of Account object and all primary objects will need a reference to an account. If you later want to migrate one account to its own server, you can port the whole database and delete all accounts except the one.

customaware

Thanx kk and Henrik.

Henrik's suggestion is exactly what I would like. Are you saying that is possible as the product sits now?

hpl123

Yes this is possible. I have seen it in 1 users application but I don´t know how it was implemented. Also I don´t know if he wants to share openly about this so will not name his name. Ask support about it, they know for sure how this was / can be done.

PS: If you figure this out, please share the details. Thanks

Markfre1

I have been grappling with this issue for months. How to offer a multi-tenant app with AIM and allow Tenants to create their account of the fly.

In my C/S app where I use PSQL, I can on the fly create a separate set of data for each tenant. All data is segregated and no tenant has any capability to access any other tenants data.

With AIM and SQL it seems there are only two realistic options. 1 is to manually create a BSV for each tenant and they can have their own data. This is only feasible for a small set of tenants.

The other option, is you must create a Tenant ID. Every query, process, etc must include the tenant id since all the data is in one database. User cannot use industry standard query tools. You must also look into the READ PROTECT.

To me I do not like mixing one tenants data with another due to the risk of inadvertant exposure. However, I believe AIM untilizing a Tenant Id combined with the Read Protect should be secure. Although this is not my preferred method but it looks like there is no other option and AIM is the best tool for web.

Anybody who has other ideas on a different multi-tenant approach where data is able to be segregated by tenant, please let me know as I am starting shortly on a mulit-tenant app.

Mark

kklosson

I use option B on a system with extremely sensitive information. There is no way for a user to get to another tenant's data. I sleep well. This is probably a much simpler approach in the short and long runs. Plus I can make queries and reports for myself that aggregate all data and report on each tenant's use and activities. I personally would not consider option A - sounds too complicated. I hate complicated.

weblike

Hi,

I also use option B and seems to work ok.

My question is if anyone managed to create "READ PROTECT" dynamic. Maybe it's stupid and easy to do....but I didn't get it.

By dynamic I mean to create a BO which will hold the security/access levels groups.

Now I have 3 AccessLevels declared in AWIM and inside each BO I have to declare a READ PROTECT so a tenant to not have access to other tenant.
IF I want another ACCESS LEVEL I have to manually create it and enter each BO and adjust the READ PROTECT.
It is possible to set-up this dynamically ? Anyone can give suggestions ...
thank you

Markfre1

I believe you were responding to my post. I want to confirm your A and B.

Was A creating seperate BSV's for each Tenant.

And B was having 1 database with each record including a Tenant ID.

Since you have done this, and sleep well, I want to make sure I understand your approach so I pick the right one. It seems B, one database would work the best for me since I can create tenants on the fly.

If I have thousands of tenants, the database is going to become large, but at that point I can look at having multiple servers, multiple bsv's, etc. I can only hope for those type of headaches.

Could you please confirm your A and B. Thanks.

Mark

kklosson

I do confirm. I would not worry about the size of your database unless you have a lot of document or file objects. My database is about 20GB compressed. I run one application server and one database server. I have a license for a second application server which I intended to set up in a load balancing situation, but never did. I may some day but at this time I have adequate capacity. The defining factor is number of concurrent users. I get about 500 logins per day but I don't have a metric on concurrent users. In the 10s I suspect.

hpl123

I also use option B as the standard way of developing all my multi-tenant applications. I use it on user level and also on group level so each user has for example attribute "UserId" and if the application has different groups "GroupId" and then these Id´s are used throughout the application (s) in queries etc. etc.. I have not used the protect rules that much yet and the application can function without these rules in most cases but for extra security they are necessary.

Regarding this "way" of developing, it´s not a big thing once you get used to it and takes a little shift in perspective I guess + some extra time (not much) when developing.

Markfre1

Thanks for the feedback. I agree the it may take a shift in my perspective as this seems to be the way most multi-tenant apps are designed. And since I want to use AIM for this app, this is the only route available.

As far as capacity goes, I'm assuming adding application servers should be able to handle any load. I would love to have the headache of too many users signing up.

Thanks again for the feedback.

Mark

customaware

Mark,

Please see the PM I have sent you day before yesterday.