<img height="1" width="1" style="display:none;" alt="" src="https://dc.ads.linkedin.com/collect/?pid=287945&amp;fmt=gif">

Transforming FlowWright: Full Multi-Tenant SaaS Support Now

Posted by Dileepa WIjayanayake on May 29, 2020 9:30:24 AM

FlowWright v9.7 full multi-tenant saasFlowWright has always supported multi-tenancy from an engine perspective,  Many customers who embed FlowWright's workflow capabilities into their applications and products see their users use their own application UI rather than using FlowWright's UI.  And still some customers wanted to leverage FlowWright's UI elements and its engines in  Saas multi-tenant environments.  The main goal of SaaS  - Software-as-a-Service is to have one copy of software serving many tenants or customers.

There are 2 main variations of multi-tenant. 

  1. Single database architecture: a single database holds all the data for all tenants and all data is tagged with a tenant id.  Every query is tagged with the tenant id filter to guarantee the correct data is served to the correct tenant.
  2. Multi-database architecture: each tenant has its database.  In certain industries, data separation is required for compliance reasons - with separate databases for each tenant, clear data separation can be achieved.

Making FlowWright fully supportive of multi-tenant/SaaS approaches has been in the works from the start.  Before choosing our design and implementation approach, our team thoroughly researched multi-tenant architecture and SaaS application development best practices.

Along the way, we came across 2 resources that provided significant help and insight.  Multi-tenant architecture design itself is half the battle, but what the technology choices can offer to SaaS customers is the other major consideration.

So, who are our heroes on this journey, first is a video on Youtube given by Carmel Hinks - Multi-tenant architecture in 20 minutes

https://www.youtube.com/watch?v=0N4KknY_zdU&t=671s

Carmel's experience was extremely instructive.  Applying caching early on was one of their principal lessons-learned from their multi-tenant Saas transformation efforts.  Atlassian's Jira product faced the same multi-tenant issues we needed to address and this video presentation on how they did it was excellent.  We learned that their solution, architected for Amazon AWS, use many technologies that the Amazon AWS cloud offers.

The next video was by Doug Merrett - Salesforce Multi-Tenant Architecture: How We Do the Magic We Do

https://www.youtube.com/watch?v=Tuy_O37H3O8&list=PLkuj7cbRlQDubQgi9TOxB6uAhOM1LaQej&index=2

According to SalesForce, they went with a single database concept but used a database feature called "data sharding" to separate the data: multi-tenant data separation is handled by the database and database server instead of by application logic.  As you will see from the video presentation, there are security risks with this kind of architecture.  SalesForce chose to build a database within a database and then to use their own data querying language.  SalesForce runs on Oracle and Amazon AWS - an expensive solution.  For an application that holds customer information, customer's customer’s information, financials, etc., a solution like this must have the most rigorous security around data.

How Did We Choose To Implement Multi-Tenant Capabilities in FlowWright?

We explored many potential architectural and technology avenues.  In the end, our choices reflected an emphasis on two requirements: supporting new and existing customers with diverse needs, and prioritizing technology independence.  We want our solution to be able to run on many platforms, on physical servers, in virtual environments, and in cloud environments such as Microsoft Azure and Amazon AWS.

From a development perspective, using most of what we have already developed was also a priority.  We retained, with some modifications, 90% of our existing code base.  From Carmel Hinks (above) we learned that efficient use of caching is vital to success, and therefore we put caching front and center.  Application-level caching pre-existed, and now we needed to implement caching to reduce the # of calls made to the database.  We built a multi-layered caching library that supports all tiers of the application.  The caching layer uses different caches based on which tier is being accessed.  For high performance caching, we built caching into our Workflow engine because the engine is always running and it is a good place to host a cache that is accessible at high speeds.  So, now FlowWright engine service includes a light-weight, high-performance. web server (also known as a self-hosted web server).  (Were we to have used Microsoft IIS for this purpose, performance would be terrible because IIS allocates many computing resources.)

How Does FlowWright Multi-Tenant Functionality Work?

FlowWright now supports multi-tenancy where one installed FlowWright application can support many customers, with each customer having its own database.   The first database is the “Master Tenant”, where you can configure and manage other tenants using the tenant manger, and also manage/configure other FlowWright functionality.  Other tenant databases can be replicated/created from the master tenant database, from other tenant databases, or by simply using the default template provided by FlowWright.  The process is shown below:

How FlowWright multi-tenant saas works

FlowWright tenant functions (some follow) are configured through the tenant manager interface.:

  • create and configure tenants, including master data
  • auto-configure a workflow step, and send the step to selected or all tenants
  • remove a workflow step from selected or all tenants
  • roll out other configuration changes to selected or all tenants

When it comes to tenant routing, FlowWright uses URL HOST to determine where to route the user to.  In a non-multi-tenant installation of FlowWright the URL will look as follows:

http://localhost/cDevworkflow

In a multi-tenant environment there are many URLs and FlowWright handles these URL configurations automatically.  Let’s say the application domain is: http://FlowWrightApp.com

The tenant manager can be accessed using the following URL: http://tenantmanager.FlowWrightApp.com/cDevWorkflow

And, let’s also assume there are 2 tenants, “azure” and “aws”, the following URLs will be used for accessing:

http://azure.FlowWrightApp.com/cDevWorkflow

http://aws.FlowWrightApp.com/cDevWorkflow

Tenants “azure” and “aws” will have their own tenant database,  FlowWright routes a user to the correct FlowWright tenant database using the HOST name within the URL.

When Is Version 9.7 Available?

Now.  Version 9.7 will be available after 15-JUL-2020.  Customer asked for more efficient multi-tenant support and here it is!

Want to access multi-tenant features for your business? Let's Talk! 

Start Software Trial

Topics: multitenant, Multitenancy, multi tenant saas workflow, software as a service, saas