A couple of our partners are using Adam to provide
SaaS solutions to their customers and we try to keep that in the back of our
mind whenever we’re designing a new module, studio or feature. A couple of examples:
- Sites are most often used to specify different setting values depending on the
physical server that connects to the Adam database. However, they can also be used
to set different setting values depending on the site that a user uses. In that
case you need to mutiple sites and setup multiple site registrations (check Admin Guide > System
Configuration > Sites > Sites for more info on how to do this) on one physical
server. After that, your Adam.Core.Server.exe.config file will look somewhat
like this:
| XML |
1
2
3
4
5
6
|
<databaseregistrations>
<add name="AdamCustomer1" sqlServer="LOCALHOST" sqlDatabase="AdamSaas"
workingFolder="D:\Adam\AdamCustomer1" siteName="Customer1"/>
<add name="AdamCustomer2" sqlServer="LOCALHOST" sqlDatabase="AdamSaas"
workingFolder="D:\Adam\AdamCustomer2" siteName="Customer2"/>
</databaseregistrations>
|
After this you simply install a separate AssetStudio/ConfigStudio/Custom Studio
for each of the sites and make them connect to the corresponding registrations.
That way, a user logging in through http://customer1.yoursaasprovider.com
will use different setting values compared to one logging in at http://customer2.yoursaasprovider.com.
- Another useful concept is Adam Organizations. These help you to shield of the
working areas of your different customers. Start by creating an organization for
each customer. Next you can create different user groups that belong to a specific
organization and assign different permissions to them. Once this is done, you’ll
automatically see new roles in the Security > Organization section of a user group
profile:
In a similar way you’ll also be able to make certain groups manage or view
fieldgroups, languages, filetypes, ... : just click a couple of the other links
of the Security-section of a user group profile. - The final piece of the puzzle
is where the actual work starts for a SaaS customer: simply create a root classification
node for each customer and given the right permissions, the customer will be able
to create/edit/delete classifications, fields, field groups, user groups and users
that only his users can see.
As you can imagine, putting all of this together can lead up to challenging situations
and results that –at first sight- seem to be quite unexpected. When fine-tuning
and debugging these things, the Permission Viewers can be very useful tools: try
them out; you can find them in the Config Studio in Advanced Features.
Hope someone finds this useful. Looking forward to your feedback!