About the Client
The client is a global medical knowledge and competitive intelligence database company serving the professional healthcare community worldwide, from clinical practitioners, to medical researchers and the pharmaceutical industry.
The client’s software product is a comprehensive single point portal for all information related to the Pharmaceutical Research practice. The client’s software product utilizes an array of US government as well as proprietary databases to deliver comprehensive Pharma research based BI solutions to its clients.
Some of the services that the client’s software provided its customers were:
- List of Pharma research institutions based on specialization
- List of Key opinion leaders for medical conditions, topics
- List of grants awarded to various research institutions from US Government / Private bodies
- List of patents related to Pharma research along with details
- List of conferences related to the Pharma research industry
- List of journal, business publications related to the Pharma research industry
Each of the above constituted a module that could be purchased from the client.
To serve its customers, the client maintained multiple application instances and partitioned its master data records for every purchasing customer. Maintaining multiple application instances required significant administrative overhead. Additionally, the master database was getting updated on a daily basis by the client’s medical and pharma research team, (up to 1-2 GB of updates per day) and the Client was finding it very cumbersome to update multiple instances.
The Client’s vision was to build a comprehensive single point application that could cater to all its customers by leveraging a multi-tenant architecture.
Need help with a SaaS Development project?Contact Silicus Sales
Silicus designed a SaaS based software application with multi-tenant architecture and database. A “Shared Database, Separate Schema” architecture approach was adopted for the database architecture of the SaaS application. This was based on the client’s business requirement of keeping hardware and back up costs to a minimum.
While designing the SaaS application, the following considerations were taken into account:
The following security measures were adopted during the design phase:
- Filtering: Using an intermediary layer between a tenant and a data source that makes it appear to the client as though its data is the only data in the database
- Permissions: Using access control and user’s security context based impersonation to determine who can access data in the application and what they can do with it
The nature of the client’s services were such that each tenant required highly customized intelligence data, with the ability to use custom fields to make tenant specific entries.
Based on the “Shared Database, Separate Schema” approach mentioned earlier, all data was stored in a master database that was accessed by all tenants.
Each tenant had a separate tenant database that contained tenant Meta data and specified the access details and rights for each tenant and their users. Here, a metadata table stores important information about every custom field defined by every tenant, including the field's name (label) and data type.
When an end user saves a record with a custom field, the record gets created or updated in the primary data table and values are saved for all of the predefined fields, but not the custom field. The application creates a unique identifier for the record and saves it in the Record ID field. Second, a new row is created in the extension table that contains the following pieces of information:
- The ID of the associated record in the primary data table
- The extension ID associated with the correct custom field definition
- The value of the custom field in the record that's being saved, cast to a string
When the application retrieves a customer record, it performs a lookup in the extension table, selects all rows corresponding to the record ID, and returns a value for each custom field used. To associate these values with the correct custom fields and cast them to the correct data types, the application looks up the custom field information in metadata using the extension IDs associated with each value from the extension table.
Silicus followed the partitioning technique for scalability. Partitioning was done horizontally based on Tenant ID. Load balancing between various tenants was also taken into consideration to equalize the total number of active end-user accounts on each server.
Silicus architected a SaaS platform that addressed the scalability, configurability and multi-tenant efficiency issues related to the software.
Daily updates and integrations were automated and standardized to offer quick up to date solutions to the client’s end customers.
- Architecture design included seamless integration of functional and admin modules for the client to manage application delivery to its customers
- Developed highly interactive front-end GUI for entire application using Adobe Flex, JMesa, Prefuse and other visualization and reporting tools
- Easy and efficient management and administration of data that ran into several TB’s and daily updates from at least 5 outside data sources
Java, JSP, HTML, SQL
SQL Server 2005
Apache Struts and Spring Framework
Version Control System
Jasper Reports, JCharts, Googlecharts, Adobe Flex3, Jmesa, Prefuse Visualization Toolkit, Google Maps API
Client side caching
Microsoft Internet Explorer 7.0 and Mozilla Firefox 3.0.x
Others Tools (if any)
Apache Ant (Automatic Build and Deployment)
Web service architecture
Silicus addressed the customers application delivery challenges by designing and developing a multi-tenant database architecture SaaS platform
Given the vast amount of daily updates that need to be released through the application, the SaaS platform simplified the entire application administration activities that was previously a cumbersome and tedious activity