Stephen Smith's Blog

Musings on Machine Learning…

SaaSifying Accpac

with 4 comments

I talked in general terms about types of cloud solutions in my blog post “Accpac in the Cloud”. In this blog post I’m going to talk more specifically about how Accpac currently runs in our environment and the changes we are making to support running the 6.x Web version as a true SaaS solution. is our current cloud offering for both Sage ERP Accpac and SageCRM. This site hosts Sage products as well as a number of associated ISV solutions. For the current Accpac we use Citrix to run separate sessions for each client logging in. Clients are load balanced across our servers, but any combination of clients can be running on any given server. There is then a separate cluster of SQL Servers to contain all the various customer databases. Below is a diagram of the infrastructure.

When you access Citrix to run Accpac, you first login to Windows then you run the regular Accpac desktop and get the regular Accpac desktop displaying its sign on screen. In the sign on screen you only get the list of your companies (and no one else’s) plus you can only sign on with user ids that are issued to you. So how does keep all the various users of Accpac straight given that several completely unrelated customers’ users can be running Accpac on the same server?

When you install Accpac you have to specify two directories the program files and the shared data directory. The program files are where all the program executables are stored, all the DLLs, OCXs and EXEs. These programs are the same for all customers of AccpacOnline and are shared. However the shared data directory is kept separate so that all the users for a particular customer get their own shared data directory and hence their own preferences, users and companies. But how do we do this? Since technically inclined users of Accpac will know that the location of the shared data directory is stored in the registry under HKEY_LOCAL_MACHINE which is global to all users. Basically we rely on Windows to do this, we install the program files to the regular location on c:, but then we install the shared data to a g: drive. This drive is a mapped drive that points to a different folder for each AccpacOnline customer. So when a user of that customer signs into Windows through Citrix, a login script then maps the G: drive to the appropriate folder for that customer.

This then gets the user up and running with the correct environment. This isn’t a security measure though; all the various folders are additionally protected by Windows security settings so users of a given customer don’t have any sort of access to data belonging to another customer. So even if they could figure out how to map drives to other peoples folders, it still wouldn’t work for their login id.

An alternative approach used by many vendors is to run a separate virtual server for each customer. Basically this model is managed hosting where rather than have a physical server on-premise; you have a virtual server in the cloud. However going this way is more expensive for a number of reasons. With the AccpacOnline model all the users are sharing the same installation, so for us, updating the program files is easy, we don’t need to login in to hundreds of virtual servers to apply hotfixes or product updates. Plus we are only running one copy of the operating system, so the operating system memory and resources are shared. With the managed hosting model each customer has their own copy of the operating system using memory and resources. This means that with the AccpacOnline model we can run many more users per physical server bring down the cost of the service.  The real game of cloud services is how you can architect it, to bring down the cost per user in order to run a competitive service.

Moving to Accpac 6

With Sage ERP Accpac 6 we are rolling out Accpac as a true Web based application. There are many reasons to do this that have considerable customer value. One of the primary reasons to move Accpac to the web is to improve the experience and to reduce the costs to operate to reduce the overall TCO. Basically we are looking to run a modern Internet SaaS business running Accpac. You will access it through the browser like most other Web based applications.

The key to today is that you first login to Windows, this then establishes which customer you are a user for and sets up the environment for you. The key point is that this is a two-step sign on process, first you sign on to Windows to establish which customer (or tenant) you are and then you sign on to a given Accpac user for that customer. In the web world we will do the same thing. Sign on will be a two-step process where first you sign on using the same credentials you would use to sign on to Windows, this will then establish which customer (tenant) you are and connect then present you with the Accpac sign on screen where you select which company you are currently using (and you can only choose from one of your own companies) and your session date. What is happening behind the scenes will be transparent to the user, they will just see nice Web screens where first they type in their user and password then next choose their company and session date.

In this environment Accpac is running under a Web Server and all customers are sharing the same pool of Web Servers. So we don’t have fancy Windows drive mappings to keep things separate for us. Back when we developed Sage ERP Accpac 5.6A, we knew this was coming, so we changed the Accpac API so that all calls would reflect the given customer (tenant) and retrieve the correct data for them. So most ISVs that develop third party applications should have adapted to this environment as part of supporting the 5.6A View Template. In the on-premise version of Accpac any older APIs are still present for compatibility. However in the version, these APIs will be removed (usually low level functions missing an hSIB or hPIB parameter).

The new Sage ERP Portal that was introduced in 6.0A is implemented as a common component and as a result keeps its data in separate files and databases from the main Accpac application. As a result it underwent a bit of refactoring to separate out this data by customer and to tie into the new multi-step sign on process.

When running our VB UIs under Citrix, multiple customers are sharing the same operating system running as Citrix users on the Windows Server, but each user is running their own copy of the various Acccpac EXEs and DLLs. Basically Citrix and Windows Terminal Services keeps each user quite isolated from each other and each gets their own running programs. This then becomes quite expensive on memory since each process has its own memory space. Although this is far better than virtualizing each customer, we can do quite a bit better. With the new AccpacOnline we will run far fewer processes. We will pool resources and requests will be processed by worker threads for the duration of the run. This then means each user uses far less memory and other server resources allowing more users per server and again reducing the TCO of the AccpacOnline service.

Of course we will have multiple application servers available to handle requests and then load balance these requests across the servers (as we do today with Citrix).

We won’t be combining client databases into one database like does. Part of what they do is a result of using Oracle as their database where each database requires a database server process running. We will be using SQL Server where we can have multiple databases kept separately within one SQL Server process. Further this allows us to use Accpac’s inherent multi-version support to allow clients to upgrade to new versions when they wish. Most ERP customers want control over version upgrades. NetSuite accomplishes this with separate sets of servers per version, but we can do a bit better than this.

Even though clients can upgrade when they wish, we will be trying to make it as easy as possible to upgrade. We call this frictionless upgrade. We want to reach a state where we can regularly roll out new product updates or even versions where clients are upgraded silently in the night and it just works the next day. We still have a ways to go down this road, but that is the end goal.


We are really excited about clients running Accpac both as an on-premise installed Web application and as a true hosted Web application. I previously blogged about SaaSifying Sage and a lot of that ties in to how we deliver and operate

Written by smist08

June 18, 2011 at 5:11 pm

4 Responses

Subscribe to comments with RSS.

  1. […] I talked a bit about AccpacOnline and how it hosts Accpac currently as well as some of our plans here, this article looks a little deeper into how we will be deploying the Web version of Accpac Online, […]

  2. […] talked a bit about SaaSifying Accpac and SaaSifying Sage. Today I’m going to talk a bit more about continuous deployment which is one […]

  3. […] version for over ten years now with Sage 300 Online. I blogged a bit about how this offering works here. Basically we offer our on-premise product in the cloud relying on Citrix and Terminal Services […]

  4. […] on a much frequent basis. I’ve blogged about this before in these articles: SaaSifying Sage and SaaSifying Accpac. This article is really just covering one aspect of this process, namely around how we now use our […]

Leave a Reply to Azure and PaaS Versus IaaS « Stephen Smith's Blog Cancel reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: