[CB 4.2] multi client application, client depending settings

Communities ColdBox HMVC
1

Hi,

I’m wondering what’s the best way is write a multi client application.
Which would mean depending on the request customer specific settings must be loaded.

Any ideas?

Thanks,

Gunnar

2

There’s many ways to do this. If you want all customers running inside the same application scope, I would encapsulate all custom-specific settings into a service and set some custom identifier on request start based on the URL or the logged in user. Then route requests for those settings (or even layouts) through the service that would take the custom into consideration.

Another option is to change the application name based on the customer and load settings as normal into each instance of ColdBox. I’m not a super fan of this due to the extra memory overhead of loading the entire framework for each customer and the hassle of needing to reinit each instance when code changes.

Thanks!

~Brad

ColdBox/CommandBox Developer Advocate
Ortus Solutions, Corp

E-mail: brad@coldbox.org
ColdBox Platform: http://www.coldbox.org
Blog: http://www.codersrevolution.com

3

Are you taking multi tenant?

Luis Majano
CEO
Ortus Solutions, Corp
www.ortussolutions.com
P/F: 1-888-557-8057

4

yes, that was the term is was looking for.

5

How would this service work for Coldbox settings if they are client dependent. Can they be loaded by request?

How would a multi tenant application containing Contentbox work? Contentbox has several ORM settings in the application.cfc
It requires a database to be setup before the framework initializes, right? In this cases we could only use application name based on the customer
or is there a way to handle this by the framework?

Thanks a lot for the feedback.

6

The Coldbox framework settings reside in the Application scope. They are “globals” and should not be used for request-level data. If you modify those settings during the request, then those modifications can affect other concurrent users. I would NOT change the application name, based on the tenant. It’s just not scalable.

For multi-tenant operations, anything in-request settings related to the tenant should reside in transient objects for be scoped in to the request. You can then leverage query/ORM caching to minimize the database overhead for those settings which are built/scoped on every request. Wirebox allows you to do this in the component attributes:

component name="TenantService" scope="REQUEST"{
 ...
}

If you really wanted to access those via the Coldbox settings, you would want to enclose any tennant-based config within a closure to ensure that the function which creates those settings is run every time:

tennantSettings = function(){
    return application.Wirebox.getInstance("TenantService").getSettings()    
}

Then you could inject that setting in to a component (which we scoped to the request previously), with the understanding that you would have to call the setting, itself, as a function:

property name="tenatSettings" inject="coldbox:setting:tenantSettings";


var tenantSettings = VARIABLES.tenantSettings();

As for your Contentbox questions, ContentBox is not yet setup for multi-tenant content, though that’s on the roadmap. Modifications to the core and the ORM models, which would take you off the upgrade path, would be required.

From a data model standpoint, a common method for handling multi-tenancy is composite primary keys. There will be a number of models which are global, but if your data is going to be tenant restricted on every query, then a composite key makes a good deal of sense.

HTH,

Jon