When building applications in the cloud, a common challenge is to create applications that can serve multiple customers with just one instance of the application running. Now with Mule Studio and CloudHub, the effort required to do just that has been greatly reduced. Here I will like to walk through one example to illustrate how easily it can be done. For this example, we will use Zuora, a popular SaaS billing system for subscription services, and Amazon RDS MySQL to demonstrate the steps involved. We will build a simple Data Warehousing integration App (iApp) that will retrieve invoice records for different Zuora customers and store them in a relational database (e.g. for reporting purpose). Please note that the information presented here is general enough that the same basic configuration can work with other SaaS systems.
When planning for a multi-tenant application, there are several things that must be taken into consideration upfront during the design phase:
Where will the tenant credentials be stored? Generally, the best place to store credentials is, encrypted, in a database. Nowadays there are may cloud-based database systems to choose from and for the example here, we will use Amazon RDS and for simplistic, leave the data unencrypted. Best practice is definitely to encrypt all credential data though.
How will the records that need to be synchronized be picked up? Some systems (e.g. Salesforce.com) support near-real-time outbound messaging (e.g. Streaming API or webhooks) when records are changed, but polling for changes is still the most common method and will be used by the example here.
How do you manage the synchronization cycles? Here we will use the Mule quartz transport combined with couple stored procedures to manage the process. We use the sprocs to ensure that for each individual tenant, if a prior sync operation is still in process, a new one will not be started.
Connecting to Amazon RDS in the cloud is just like connecting to any other RDS via JDBC and how to do it in Mule has been well covered by prior blog posts. We do highly recommend that for the customer table, include a column for account status (e.g. active or inactive), that way you can easily enable and disable a customer.
To set the synchronization to run on a regular schedule, simply use the Mule quartz scheduler to trigger a call to the database:
To prevent a synchronization cycle from being fired off when the prior one still in progress, a simple control table combined with couple small stored procedures is sufficient. The control table simply records whether a particular tenant’s process is still running:
By calling the stored procedures using JDBC outbound endpoint then parse the results using choice flow control, we can determine whether a prior process is still in running and when the process has finished.
The very simple yet poweful mechanism that allows an iApp to become multi-tenant, is that you can pass in the connection credentials to the cloud connectors when invoking the operations, instead of having to declare it globally. Therefore, once you have retrieved all the tenants’ credentials, you just need to simply pass each one of them to be used for the cloud connector operations you want to perform. Then your iApp will become multi-tenant enabled. Here is an example of how the credentials are passed only when the operation is invoked.
One last note. If you have any synchronization control measure in place, please remember to include the releasing mechanism in the exception strategy as well so the process can resume automatically after fixes have been made. The screenshot for the finished example iApp is shown below in its entirety. The iApp is ready to be deported onto CloudHub.
These few steps are all it takes to create a multi-tenant iApp using the Mule Studio. The potential is really limitless and entirely up to each developer’s imagination. The source code for the sample iApp is shown below and please feel free to copy.