10.2 Persistence
10.2.1 DataSources
|
Remember that in the SOR (System Of Record) the SaaS application will always use a Shared Schema structure, which means every entity in the application
will have an additional TenantId attribute. So the SOR uses a shared schema. This is fixed and cannot be altered. There is no capability to allow
different schemas for Tenants.
However the SaaS provider (or their clients) have the ability to organise the data across a number of datasources.
The granularity of this data organisation is at the entity and tenant level.
For instance: Tenant1 may wish for their data to be stored in a separate datasource DS1. Tenant2 and Tenant3 are happy to keep their data in a common datasource DS2.
Tenant 4 is also happy to use the common datasource DS2, except for Entity E1 which they want in their own datasource DS3.
The core data schema, as defined in the model must remain the same, but where two tenants share a datasource there will be the added attribute / data column to represent
the TenantId.
This organisation of the data at the persistent level is defined by configuration files, which are explained in detail in Entity DataSource Mapping
10.2.2 Additional Data
|
As has already been mentioned the data structure in the SOR and the underlying data structure at the persistence layer must be common for all tenants. To obtain
a degree of flexibility for Tenants it is recommended that SaaS providers add an additional number of attribute of various types to each entity. For example
in the MultiTenancy example in /examples/CloudTran/MultiTenancy the employee entity has 2 additional attributes that could be used to hold Tenant specific information.
<entity name="Employee"
>
<attribute name="isManager"
type="Boolean"
/>
<attribute name="employeeTitle"
/>
<attribute name="employeeFirstName"
/>
<attribute name="employeeLastName"
/>
<attribute name="employeeId"
/>
<attribute name="employeeTelNo"
/>
<attribute name="employeeEmail"
/>
<attribute name="employeeExtra1"
/>
<attribute name="employeeExtra2"
/>
</entity>
Of course the idea of adding additional attributes will only provide a certain amount of expansion. One problem is determining the number of extra attributes
required, the other is determining what types should be catered for.
Another solution is to store the additional information in Key Value pairs in String format. So in all entities of a SaaS application there is an extra attribute
generated by default to be used for just this purpose/
<attribute name="properties"
type="String"
/>
Neither of these techniques will solve all problems but they should be sufficient to cover most evenutalities. They can used or ignored as require by the
SaaS provider.
| 
