To Aware Team: Request for Multi Tenancy guideline for Aware

BenHayat

Hello Team;

I have done the search and gone through most threads and posts. However, I think and I highly suggest that the team should put together a guideline document (part of V6 release) how the proper way multi tenancy should be done in Aware and close this subject once for all. Other systems I've worked on, each offer certain patterns and guidelines to follow to make sure it's done right. This is a critical decision that will affect our application, especially when data volume increases. Proper foundation is necessary.

Could you please add a PDF document to give us a step-by-step and a sample program how the BO structure, data access and query retrieval should be performed, so Aware makes proper DB indexes that fetching data for a tenant will be fast, efficient and secure?

Developers who like this idea, please show your vote and support, so the team would see the need and value of such document.

Thank you all and hoping to join you with my new project.
Have a great day!

BenHayat

Last night I was talking to an old friend and going over the powerful features of Aware with him and he seemed very interested in Aware. He too told me his company plans to re-write their current Windows desktop app to a Mult-tenancy SaaS Web application. So I know SaaS demand is increasing a lot and Aware could fit perfectly for this new market. It just needs to show how Aware does it. Education is the greatest Sales force! 😃

ACDC

This depends very much on the nature of the app you want to develop ?

In an enterprise system I don't think its a good idea to have multiple tenant data concentrated in one database. If a saas customer wishes to move on , they may want to take their data with them. This will present issues down the track in extracting the data from a concentrated database. (once again it depends on the nature of the application)

So I recommend each customer being allocated their own Business Space. This provides much more flexibilty in system management not to mention customization on any one of the business spaces.Life will be a lot easier that way

Also, bear in mind the AwareIm development environment needs a very different mindset. Normally where a project would take 10 software developers on one project, with AwareIM you place 1 software developer on 1 project because one developer can do what 10 software developers could normally do in another development environment. This fact needs to be taken into context to answer you question

BenHayat

ACDC wrote
This depends very much on the nature of the app you want to develop ?

In an enterprise system I don't think its a good idea to have multiple tenant data concentrated in one database. If a saas customer wishes to move on , they may want to take their data with them. This will present issues down the track in extracting the data from a concentrated database. (once again it depends on the nature of the application)

So I recommend each customer being allocated their own Business Space. This provides much more flexibilty in system management not to mention customization on any one of the business spaces.Life will be a lot easier that way

Also, bear in mind the AwareIm development environment needs a very different mindset. Normally where a project would take 10 software developers on one project, with AwareIM you place 1 software developer on 1 project because one developer can do what 10 software developers could normally do in another development environment. This fact needs to be taken into context to answer you question

Thanks for your feedback. But in this particular application, it needs to be within ONE database and ONE Business Space. Tenants share other COMMON data that is public data being updated regularly. All of these considerations have already been measured. I've designed and developed SaaS apps in other platform where I had full control on the database design, indexes and Queries. In Aware, I want to do it the "Aware Way" and not my old way.

What I'm asking the team to give us a guideline how to do it in Aware that is secure and fast. This way, same questions will be asked over and over. They can add it to "How-To" document.

kklosson

I think it should be easy enough to do as I have a multi-tenant app. Basically, you will have several queries that must reference something like:

Object.Account.ID=LoggedInUser.Account.ID

And you must set that value for certain objects using rules. But this has worked quite well for me.

Security is a whole other matter. Even though the application may have no way for the user to access objects in other accounts, with a bit of fiddling, it's not hard to do. For this, you must apply protect rules. A protect rule will prevent a user from intercepting a call to the server, modifying it, and sending it on. So if you have an object that should only be accessible by someone in their relevant account, a protect rule would be something like:

READ PROTECT MyObject WHERE MyObject.Account.ID = LoggedInUser.Account.ID

Read Protect rules work in conjunction with Access Level permission. First set access level permissions appropriately. Even though your application may no permit certain access, this is necessary from a security standpoint. Then use Protect Rules to prevent the kind of behavior I described above, where a user is operating outside the logic of your application.

These rules can be persnickety (though they work as they should). In setting rules, you have to consider the value set to any parent objects. If you think of your data model in a standard diagram, the existence of a parent record will have an affect on how the rule operates at run time. It pays to play with them and learn.

Keep in mind this is all application layer protection. But it's what you need to do in a multi-tenant account.

aware_support

No need to have a separate PDF document for this, because it's really simple in Aware IM. But we will add an article on this to the How To document.

If you implement this in one database you need to:

Define an object representing a Tenant
For all objects that belong to the tenant add a reference to the Tenant that it belongs to, for example Account.Tenant
The user object must have a reference to Tenant that it operates on behalf of - LoggedInSystemUser.Tenant
For each object that belongs to some tenant add rules to initialise tenant from the tenant of the logged in user that created the object, for example:
IF Account.Tenant IS UNDEFINED Then
Account.Tenant = LoggedInSystemUser.Tenant
Finally add protection rules to the object that belong to the tenant so that other tenants do not see it, for example:
IF Account.Tenant <> LoggedInSystemUser.Tenant Then
READ PROTECT Account FROM ALL EXCEPT System

BenHayat

aware_support wrote
No need to have a separate PDF document for this, because it's really simple in Aware IM. But we will add an article on this to the How To document.

If you implement this in one database you need to:

Define an object representing a Tenant

For all objects that belong to the tenant add a reference to the Tenant that it belongs to, for example Account.Tenant

The user object must have a reference to Tenant that it operates on behalf of - LoggedInSystemUser.Tenant

For each object that belongs to some tenant add rules to initialise tenant from the tenant of the logged in user that created the object, for example:
IF Account.Tenant IS UNDEFINED Then
Account.Tenant = LoggedInSystemUser.Tenant

Finally add protection rules to the object that belong to the tenant so that other tenants do not see it, for example:
IF Account.Tenant <> LoggedInSystemUser.Tenant Then
READ PROTECT Account FROM ALL EXCEPT System

Thank you for speedy reply. Your points are crystal clear, but there is one significant point that is missing for me and here it is.

So the Account object (table) is under Tenant. So it has a Parent (Tenant) / Child (Account) relationship.

Let's take that a step a bit further.
An Account also have "Order" object that is the child of the account and grand child of the tenant. And this hierarchy can go deeper with line item as following.
Tenant -> Account -> Order -> Line item.

So here is my question:

Database design # 1) Just the same way we referenced the Tenant to it child (Account), should we also reference the tenant to it's grand children, like Order and line item?
In this way, I'm still referencing each level to it's above parent to maintain the chain, but an extra reference to grand father for safety measure.
This allows me to work with Line Item level and have an immediate reference to it's Tenant with one jump. Like Tenant.LineItem

Database design # 2) Have the tenant reference ONLY in the first level below the tenant, which is the account. And then Order will reference to Account and line item would reference to Order? Going this way, then any time I need the tenant of the line item, I must walk up all the way through the hierarchy chain like.
Tenant.Account.Order.LineItem
But my problem with this style is, a lineitem or order are almost an orphan grand children with no grand father (tenant) reference to them.

From Aware's point of view and query speed and DB indexing for fast retrieval, Should I design my database in the way of # 1 or #2?

In my previous designs and work, Every Object under tenant, regardless the level, they all have reference to their Grand father to make sure every record in database has a reference to it's original tenant. But I wanted to run this by you and your vision.

Thank you kindly.

BenHayat

kklosson wrote
I think it should be easy enough to do...

Thank you KK for your valuable points and suggestions. I'm reading a lot of materials now, because I want to design it based on the architecture of Aware and not fight it. I had designed this before under .Net and Entity Framework. But Aware has very powerful features that I want to take advantage. I hope in future we can bounce ideas.

Thanks again.

aware_support

Design 2 is preferable because it is less error prone and cleaner as well. However, the difference is more or less semantic, so if you want Design 1, that's fine too. Obviously resolving multi-level reference will take slightly longer, but it is unlikely to be noticeable.

By the way, you refer to the tenant like this:

LineItem.Order.Account.Tenant

not the other way around.

BenHayat

aware_support wrote
By the way, you refer to the tenant like this:

LineItem.Order.Account.Tenant

not the other way around.

Yes, yes, yes! My bad. I was typing fast and I was excited... 🙂

You're right, # 2 is cleaner. Although, # 1 still has that same feature of # 2, except it gives me that peace of mind that every object under a tenant also has a reference to tenant, in case of I need to deal with.

ACDC

Let's take that a step a bit further.
An Account also have "Order" object that is the child of the account and grand child of the tenant. And this hierarchy can go deeper with line item as following.
Tenant -> Account -> Order -> Line item.

as a matter of interest, when you say Order object is a child of the Account do you intend for Order object to be "Owned by" the Account as opposed to a just a "Peer" relationship

BenHayat

ACDC wrote
Let's take that a step a bit further.
An Account also have "Order" object that is the child of the account and grand child of the tenant. And this hierarchy can go deeper with line item as following.
Tenant -> Account -> Order -> Line item.

as a matter of interest, when you say Order object is a child of the Account do you intend for Order object to be "Owned by" the Account as opposed to a just a "Peer" relationship

In this particular case "Yes"! in other cases, an object may have have reference of the Tenant and/ot account only in Peer relationship.

hpl123

Good stuff and discussion.

Ben, you could always use the best practises covered in this post and combine that with a TenantId on your instances. This would enable other operations as well where going "up the ladder" might not be the ideal.

BenHayat

hpl123 wrote
Good stuff and discussion.

Ben, you could always use the best practises covered in this post and combine that with a TenantId on your instances. This would enable other operations as well where going "up the ladder" might not be the ideal.

Exactly! Are you saying to have the "TenantId" as an Int attribute or a reference type in other instances? I'm Not clear which one you meant.

hpl123

Hi Ben,
Sorry, I confused this discussion with another one where TenantId was discussed. See this post and it covers it quite extensively:

ACDC

In this particular case "Yes"! in other cases, an object may have have reference of the Tenant and/ot account only in Peer relationship.

I have something similar (owned by relationship) running in one of my apps and it does present problems when the database starts to grow with regards to time taken to update a record. I haven't yet found out the reason why, but I suspect its the rules engine updating reference rules (also I have a very complex app)

So to achieve READ PROTECT , I would stay with a PEER relationship and follow through as support suggested in their reply (it may prove very usefully down the road)

BenHayat

ACDC wrote
In this particular case "Yes"! in other cases, an object may have have reference of the Tenant and/ot account only in Peer relationship.

I have something similar (owned by relationship) running in one of my apps and it does present problems when the database starts to grow with regards to time taken to update a record. I haven't yet found out the reason why, but I suspect its the rules engine updating reference rules (also I have a very complex app)

So to achieve READ PROTECT , I would stay with a PEER relationship and follow through as support suggested in their reply (it may prove very usefully down the road)

Basically, even in other systems (beside Aware), IF the "Owned relationship" chain becomes too long, it will have a major affect in performance in "Add and Delete" operation once Data grows, due to managing number of elements in the Foreign key, where as in "Peer" there is always just one element there.
For optimum performance, as Support mentioned, is not to have the Tenant reference in any of the children (but I get nervous 🙂 )

ACDC

For optimum performance, as Support mentioned, is not to have the Tenant reference in any of the children (but I get nervous Smile )

I don't know if support are saying that, I think they are saying its probably easier to setup, but as to system performance I dont know ...., maybe I am wrong

I am inclined to go with Database Design #1 - with no children, just peers

ACDC

you could start out with the Peer version and then convert to an owned version with minimal fuss. Going Owned to Peer could be another story - BUT hey! its AwareIM you can do these changes with no fuss and let the system take care of the rest

kklosson

I haven't been tracking this thread closely so forgive me if I'm off track. But if the discussion is whether to create the account object as an owner or a peer, then I would see a downside to setting it as peer because the deletion of the account would not delete all records related to it, at least not without some extra rules.

In my case, if I delete an account, everything related to it - gone.