Hi I have a question related to SAAS model and multi-tenancy.
As far as I know SAAS multi-tenancy application means common functionality
for all clients, with some customizations of UI and functionality underNeath.
If I need make for some customers additional client specific-customization , how I can achieve it?
I know about approach of SalesForce
As for answer I apreciate to see you experience with such
- customizations under database level,
- architecture of backend in general or in
- any links for this topic.
There are the following two ways of customizing a multi-tenant application
1. Presentation tier changes
2. System change.
The following are the typical customization options preferred in web applications in a multi-tenant environment, they are
1) user interface and branding,
2) workflow and business rules,
3) data model extensions, and
4) access control
In which 1 belongs to the presentation tier change and the rest all form the system level change in a multi-tenant application.
MVC is considered as presentation tier customization option where in we have the option of allowing the tenant to have their own theme , logo and custom layout or custom controllers and custom page sections.
For System settings, there are many ways to achieve this, however the following are the most pervasive
Customization at the database level
Customization at the middleware level.
In SaaS app, there are features and implementation. In the case of the later, there will be a tenant specific configuration that governs which implementation to be invoked for the tenant under consideration based on his configuration and then provides the service. These are achieved using a custom dependency injection mechanism which is tenant aware and also will be required a tenant specific configuration that can be consumed during the runtime to facilitate this process.
In the case of (1), the data in the db should be isolated based on the tenant identifier so that the configuration or the metadata are not shared between the tenants in a multi-tenant environment.
So the main components will be
a tenant identifier obtained from a tenant context
multi-tenant datastorage
Tenant specific authentication [form signing / Single SignOn etc..]
IMHO, since your topic is broad, if you can present us more specific areas, we will discuss on their implementation.
Hope this answers your query, please do post your update.
Related
Consider an MVC4/EF5 project:
Creating a web application which will have 3 modules.
Based on the customer license, we will enable or disable 1-3 of the modules.
Each of the modules will deal with a handful of common tables (Users, Company, etc).
Each of the modules will deal with tables specific to their functionality (PO's, Timesheets, etc)
An admin portal, admin users in a seperate table from regular users.
data passed to views using view models
eventually there will be a JSON service for exposing parts of the applications functionality.
There will be multiple deployments of this application with slight customization (beyond just enabling/disabling each of the three modules).
The Plan so far:
Separate dll for Model
Separate dll for each Module/Functional area.
Separate dll for the ViewModels
Separate dll for admin portal
Seperate dll for the web service
Questions:
Is anything gained by a seperate dll for ViewModels?
Tips for managing multiple variations of the same application, with regards to project organization, and source control?
Should there be a separate dll for authentication (membership and role providers)?
Any other thoughts? (Sorry for the open ended/loaded question, maybe I should remove this one)
My advice:
Don't try to solve your problems with Source Control. Unless you are
really good with branching/merging and very very disciplined. I'd
recommend one code base that is pulled together with Di/IoC
DI/IoC lots and lots of it - Look at Autofac and the Mutli-tenancy
extra. Keep everything loosely coupled as much as possible
Testing - TDD as everything needs to be loosely coupled lots of testing - look at Autofixture/AutoMoq
Extension points galore - layers of re-direction are your friend as
everyone will want different implemenations. Our core architectural elements
is a CQRS light style - Commands, Command Validators, Queries, and
Domain Events
Keep everyone on the same database structure (unless you go NoSQL
etc)
Use Onion Architecture - Make 3 projects, Web
(MVC5/WebAPI/ViewModels), Infrastructure (all the technical stuff
Repository implemenations etc), Domain Layer
Then make projects per client with overrides - e.g. Custom
ITimeSheetCalculator etc
Include ViewModels in Web Project - Look at per tenant ViewModel
mappings if required. Use AutoMapper
Look at stuff like VirtualPathProvider EmbeddedVirtualPath provider
so you can put views CSS in client DLL
Create an Ambient Configuration file that defines what is turned on per tenant. Feature toggles will be required. Especially during dev for features not yet complete
Find yourself a canary - a client you can work with on a beta version who you trust and can give good feedback
For security look at using Claims Based Identity - comes baked into MVC5. Makes it easier to have different security rules pre tenant etc
If you are working with multiple clients and they all want different
features/or same feature but implemented differently you need get the strongest person you can get to gather requirements. You can't do traditional Scrum and have developers etc and work directly with all the clients. You need someone in your company acting as proxy product owner who will take ownership of the problem of getting all clients to agree on general features
Consider Azure has lots of nice features we have used. Easily allows scale up and down.
Good luck
I've found out n-Tier web application concept like following categories:
1- Database (including database business and table or store procedures and all database stuff)
2- Web. Data (including entities and repositories)
3- Web. Model (including not entities some simple model can transfer to client)
4- Web. Business (in some application is admitted it is not mandatory but it includes some functionality such as how to calculates things)
5- Web. Service (including web API on SOAP restful application)
6- Web. Security (it includes some custom security as you wish but it is not mandatory)
7- Web. Client (including client-side functionalities like jquery, mvvm and some other like authentication, securities implemented in UI)
8- Web. Extension (including extra helper methods and wrapper objects)
9- Web. Handler (including all handler and modules)
These layers could be placed on different projects they could be implemented by MVC or even by asp.net of course with the same concept.
I was wondering if my understanding was right or not? or got any better idea? Could you expand them more or are they limited and enough?
Please guide me what are standards about them?
Did you look MyPrettyCMS Framework in codeplex ?
It's exactely that...
https://myprettycms.codeplex.com
In the next release, it includes Web API and Web API OData Handling.
If you want to follow the developer group, find the Linked in group : myPrettyCMS Happy Contributors Associates
N-tier concept is wider than just listing the exact tiers. This concept helps to divite your application to manageble and isolated levels, which you could change, re-design, substitute without breaking and re-writing the entire application. The number of tiers could vary depending on technology stack you use.
read more here: http://en.wikipedia.org/wiki/Multitier_architecture
You should try looking into the XWA architecture if your primary concern is web applications.
http://madeyski.e-informatyka.pl/download/23.pdf
XWA architecture builds atop the concepts know from the MVC and PCMEF.
I don't have a lot of experience with MVC and am looking at a lot of authentication examples, which don't fit my needs.
I need to offer access to multiple systems from one MVC application. Each system manages it's own authentication and provides similar data (i.e. System X and System Y both provide a list of widgets). Further, a user can be logged into both System X and System Y and be able to view widgets from one or the other without being re-prompted for credentials.
My plan is to use a simple route {controller}/{action}/{systemName} (i.e. Widgets/Index/SystemX). The details are fuzzy but I think I need a custom AuthorizeAttribute and a SessionProvider. The SessionProvider would handle logging into a System, which returns a sessionID. This sessionID is used when I query data from each system. One of the most fuzzy details is the best way to store user info (SystemName, user, sessionId) for each System within the session. SessionState? Cookies? FormsAuthenticationTicket? Something else?
I'd love to leverage what's already in ASP.NET & MVC, but I don't need a database for users.
Any critiques or suggestions are welcome.
If SystemX and SystemY are different areas of the same application, you could potentially be better off using the Areas functionality of ASP.NET MVC. This allows you to partition an application into areas, which logically-related groups of controllers, views, models, etc.
Walkthrough: Organizing an ASP.NET MVC Application using Areas
For example, a single large e-commerce application might be divided into areas that represent the storefront, product reviews, user account administration, and the purchasing system. Each area represents a separate function of the overall application.
Each area can have it's own web.config and authentication method (e.g. ASP.Net MVC 3 Areas and Mixed Mode Authentication) so this might help.
If SystemX and SystemY are essentially the same widget list functionality, but just for different clients, you might want to look at multi-tenancy in ASP.NET MVC.
I am trying to understand how I can create an ASP.NET MVC site that exists as a VS2010 project in a solution, and then for multiple "tenants" I would create a site that inherits from that one. That would give the flexibility of adding modular features to one without affecting another one, and both could benefit from core library optimizations.
Is that a crazy idea? What patterns exist for that kind of thing? I have done something similar for a webform-based site (adding DLLS as plugins), but not in MVC.
A "tenant" is a business client. Each already has their own MSSQL database and seperate processing around them, each client is in its own silo. The databases are similar with a few features added here and there, they are versioned and deployed seperately, that whole process works well. A client has n logons. I want to develop a single "base site" that can then be used to give function to a tenant, and all activities are segerated for a tenant to a single database. Where things get ugly is how I can add a new component (say a forum) to one tenant site without mucking up the site experience for other tenants.
All ideas appreciated. Thanks.
I have worked extensively on the development of a multi-tenant web application. Here are three basic pointers to help you get started:
Security
The TenantId is part of the login credentials. These are stored in the Thread.CurrentPrincipal. This effectively binds each request (thread) to a specific user and thus tenant. Thread.CurrentPrincipal can be easily accessed from any code.
Database
We used a single database to store all data. A separation was made between tables (entities) that were specific for one tenant (multi-tenant), and tables that were not (cross-tenant). Tables that were multi-tenant had a column called 'TenantId'. In our entity model, we made sure these entities inherited from a special IMultiTenant interface. This interface contained the C# equivalent of the TenantId field. We extended the architecture of Entity Framework to provide default filtering on TenantId for multi-tenant entities. This ensured that one tenant could never access or modify the data of another tenant.
Plugins
We used a bit of Dependency Injection trickery in order to support the implementation of tenant specific code. Based on the current TenantId, our DI container injects a tenant-specific implementation of that interface.
I have a simple ASP.NET MVC + OpenID + NHibernate app (on top of MSSQL Server DB). The app is strictly single tenant and supports multiple users with only 2 roles (Admin and User).
I would like to convert this app into a multi-tenant app. My requirements are limited: I just need to introduce the notion of Accounts, each account having its own set of users and behaving exactly like the original non-multi-tenant app. There is no interactions between accounts.
What are the best practices to do this migration the most simple way? In particular, I am can manually update all entities and repositories with an Account_id field, and upload the logic too. But, I am wondering if there are no smarter approaches that would somehow abstract this aspect.
Ps: the app is very light, I do not wish to introduce a new DB instance for each account.
Probably the best thing I could think of is to embrace the Filter feature of NHibernate. It allows you to easily enable a filter on the query you're running and you can optionally enable them on tables that are setup to be multi-tenanted