ClaySys AppForms – Multi tenant logical architecture

ClaySys AppForms V1.0

This blog post will highlight the logical architecture of the New ClaySys AppForms Solution, and will describe how the operations of the ClaySys AppForms Solution could be managed by IT Infrastructure and Operations Team.

ClaySys AppForms Application Layer

ClaySys AppForms Application Server Layer will run on Multiple Load Balanced Application Servers on Windows Server 2003 – 64 bit editions. The SQL Server DB accessed by each  Tenant/Client is configured in the Database, and so each Tenant/Client  could access the Shared Multi-Tenant DB or an Isolated SQL DB if required.

The SQL Server DB supporting the shared storage for Multiple Tenants/Clients segmented by their Tenant ID’s will be setup as follows:

• The Tenant DB Schema will be finalized at design time, based on the requirements for the various individual modules.
• Each Table in the final Schema will store records by Tenant ID.
• The Table can be partitioned by Tenant ID, so a specific Tenant’s data could be on a separate Storage Array/ Volume to manage performance for data retrieval  as data size scales up etc .

Multiple Environments of ClaySys AppForms can be maintained by setting separate SQL Server Databases for each Environment. Note that the Application Layer will remain exactly the same, but there will be different URL’s or other navigation options to access the individual environments. Users can be configured to have different access rights on each Environment. Any number of environments can be theoretically setup, as required by the IT Operations Team.

The same AppForms Instance will enable Multi-Tenancy through Separate Logical Versions of Application to be made available for each Tenant or Client. Each Tenant can have its unique set of  Modules, Forms, Fields and Business Rules. This includes configuration to ‘Embed’ a custom Form or Module within a specific Tenant/Client.

The customized configuration for each application Tenant/Client will be saved as the Meta Data Describing the Application Functionality for each Tenant/Client as explained below.

The ClaySys AppForms DB, stores 2 Types of Data for each Tenant.

1.The Meta Data – Which are like CRM System Tables storing the Config Data for each Tenant/Client.

2.The Content Data – Which are like the CRM Transaction  Tables storing the Business Data for each Tenant/Client.

Note: All Changes such as Custom forms, Custom fields and Custom business rules, that are unique to each Tenant/Client are stored in the Meta Data Tables only. Even if you embed an external module or form within tenant, this type of integration is managed through configuration once the external customization is completed, to now embed it within tenant.

How tenant can be modified to meet Customer Requirements?

1.Using ClaySys AppForms Form Designer – New Forms can be created, new fields can be added to Existing Forms, Business Rules can be modified using the Rules Engine etc.

2.Embedding Custom Modules/Objects – Functionality that cannot be achieved with the tenant Configuration tools for clients, can be customized outside the tenant Environment, deployed on a separate Server at client environment, but can be embedded into the tenant UI as a new form or form object etc.

Note: All the Customization above, only means changes to the Meta Data stored against each Tenant/Client in the ClaySys AppForms DB.

The ClaySys AppForms Form Designer will allow Customizing CRM Tenant Forms without writing Code, to meet Client Requirements and to Publish the customizations into the Sandbox Environment.

The Form Designer that allows customizing the Meta-Data for the Forms and their associated Business Rules will be allowed to Publish the Meta-Data only to the Sandbox Env as a Best-Practice. Once the Change is tested in the Sandbox Env, it can be Published from Sandbox to Test Env by an Authorized User. Once the Change is tested in Test Env, it can be published to Production Env only by an authorized Release Manager for each respective Tenant/Client.

An Authorized User can Publish Meta-Data Changes from Sandbox Env to Multiple Env’s at the same time. Authorized Users can similarly Publish from any one of the other Environments, to any other existing environment as well.

Similarly the Publish Feature can also publish Meta-Data updated within One Tenant to Multiple Tenants in a single Publish Action, if the User has the Authority to do so.  The Target Tenants could be in the same Env or in other Env’s.

The Publish Feature can also publish Meta-Data updated or existing within One Tenant to Multiple Tenants  on another Environment in a single Publish Action, if the User has the Authority to do so. An Authorized User can Publish Meta-Data Changes from 1 Tenant in Any One Env to Multiple Tenants  within the same Environment or in any Other Env. E.g. Above shows Publishing from the QA Env to Multiple Tenants in  Training Env at the same time.

Note: Technically this Publish Feature, is simply copying the Meta-Data defining a Feature or Module within One DB Instance, and recreating or inserting the same into another DB Instance *. Since each Tenant has its own copy of the Meta-Data, if Publish is to multiple Tenants, it will recreate or insert the Meta-Data updates to the data slices of the Multiple Target Tenants.

* ClaySys AppForms will have naming conventions for the Modules, Forms & Sub-Forms within it. So whenever a Field is added or edited to a Form, the old version of the Form Meta-Data is archived, and the edited Version is made the Active Version.  An Authorized Admin User can toggle back to a historic version of a Entity Meta-Data, as and when this may be required.

For Customizing requirements for individual Tenants/Clients that cannot be addressed through just Configuration as described earlier, the architecture enables an option to host a Custom Form outside ClaySys AppForms, but still embed it within the existing Forms and Modules as required, which is supported with the Configuration options.

The schematic below shows how such an externally hosted customization can be managed within the ClaySys AppForms Hosting Infrastructure.

To support Custom Functionality for Clients that cannot be addressed through Configuration, IT can deploy the custom features on an external environment as shown here.  Within the tenant you can now configure the embedding of any such Custom feature onto any existing Module or Form as required.
IT Can share these servers between multiple Tenants/Clients or can have a dedicated server/s for each Tenant/Client.
Note that the custom feature could have its own separate DB or it could manage its data in a hybrid manner, where part of the data is in the Custom DB and part of the data is from the Core metadata DB. Access to the Core metadata DB will be through the ClaySys AppForms API as a recommended practice, but for special cases, direct access to Core metadata DB can be provided. Typically ‘Read’ access can be direct, but ‘Write’ access would need to go through the API.

Software Components

-Each Module of the Tenant will be a separate Component, that provides a Service to the rest of the ClaySys AppForms Components.

– Each Component can run as an independent application or process, based on Infrastructure Planning.

– Each Component in turn will have its own set of Objects, which would be the individual classes, forms etc.

– The ClaySys AppForms Application has a suite of ‘Shared Services’ Components & Content Module Components

– Shared Services – These are the common functions required across any and all ClaySys AppForms Tenants/Clients

– Content Modules – These are the ClaySys AppForms Feature Components, that could evolve to be unique for Individual Clients

Software Deployment Diagram

The ClaySys AppForms Components can be deployed on a Server Farm as shown below:

– Client Tier – Windows XP/Vista with Web Browser and Silverlight  Plugin.

– Web Server Tier – Windows Server 2003 64 bit, running the Content Module Components.

– App Server Tier – Windows Server 2003 64 bit, running the Shared Services Components

– Database Server – SQL Server 2005 or 2008 64 bit, running the CRM Database

The Deployment Diagram above shows how individual components grouped by Content Module and Shared Services can run on the Web Tier and App Tier.

Note: The Application Stack shown above can run as multiple applications on the same Server Stack if configured as Separate Applications, or as a Single Shared Application on the same Server Stack. This can be determined by Operations based on business and operational conditions and needs.