Note: this is a guest post by Vojta Jakubec of Concur Technologies, a travel management expense company that provides travel and expense management services to businesses.
At Concur, we have experience building software as a service for over 15 years. With 93 million airline passengers booking through our Travel & Expense product in the last year, we are leading the business travel market. To put this in perspective, any commercial airplane world-wide would have on average over 3 passengers who booked the ticket through our software.
However running a successful SaaS product for over a decade has some drawbacks as well. We found ourselves in a situation where we had to extend the lifespan of our front end UI well beyond the original expectations. A significant part of it is still in classic ASP, which was the go-to Microsoft tech stack before .NET came around. In order to keep up with our customer demands, we have taken several technical steps to modernize the environment.
Data caching in classic ASP
One of the initiatives we have taken was to introduce data caching in the ASP layer. Each call between UI and midtier takes several milliseconds. The problem is that the classic ASP rendering engine does not offer any way to parallelize these calls, so the total page execution time keeps adding up. In some cases it could reach up to several hundred milliseconds. For this reason, we need to keep the time to obtain mid-tier data to a minimum.
Our solution was to host a data cache in Couchbase. Instead of making an expensive 30ms call to the mid-tier, the UI can obtain the same data in less than 1ms from the cache in Couchbase. The mid-tier call is only necessary when the is no cached data.
To minimize data access time, we had to access the Couchbase data natively from classic ASP. Routing through an additional service layer would only increase latency and hinder our caching efforts. For this reason we created an open source COM wrapper around the .NET SDK for Couchbase. It allows any application capable of working with COM objects to natively work with Couchbase servers.
COM SDK Deployment
The simplest deployment scenario is to copy the Couchbase COM SDK files onto your server and register the COM classes with the Regasm tool. You can get the binaries from the latest GitHub release or build the project yourself. The Regasm tool is a part of the .NET Framework installation and should already be present on your server.
At this point the Couchbase COM SDK should be available to your applications.
COM SDK Configuration
Mapping the .NET configuration classes onto COM objects would mean significant long term effort to keep the two in sync. Luckily the .NET SDK gave us the option to use external configuration files. In practice it’s just like working with App.Config or Web.config files in any .NET application. For more details please refer to .NET SDK documentation.
Example of configuring the COM SDK in ASP code:
The above example will open a configuration file from the specified path, look up the configuration section named “aspCacheConfigSection” and configure the underlying .NET SDK with it. This is a one-time operation that can be done in global.asa on application start.
Optimizing resource use
In ASP, users typically create and destroy COM objects quite rapidly. By detaching the lifespan of the underlying .NET SDK objects from their COM object wrappers, we were able to optimize for this use case without negatively impacting resource use or performance. All COM SDK bucket objects representing one Couchbase bucket actually use a singleton .NET SDK bucket object underneath.
Example of simple ASP caching
The following example assumes you already configured the SDK to connect to a Couchbase cluster which has a bucket called “default” on it.
We always start by creating a factory class, from which we request an object that allows us to work with a named bucket (“default” in this example). Using the Get operation, we either find and immediately use the cached data, or we issue a mid-tier request and store the result in Couchbase. Note that the Upsert operation to store data takes an additional parameter specifying the expiration, in this case 60 seconds.
Conclusion
With this simple COM wrapper around the Couchbase .NET SDK, we gain all the power Couchbase can offer natively in classic ASP applications. This allowed us to easily scale our ASP UI with just a few code tweaks. Creation of the COM SDK also led to several contributions to improve the .NET SDK and push the limits of how it can be used.
