Sage ERP Accpac 6 Deployment
With the next version of Sage ERP Accpac, we are moving to the Web. What does that mean for deployment? For workstations that’s easy, there is none, you just need the URL to point the Browser at. For Servers it’s a bit more complicated. This will all be setup for you by the Accpac Installation, but what are the components running now? What Web Servers and Middleware are we going to be using?
First which Web Server will we be using? Accpac itself isn’t dependent on the Web Server and will run with most Web Servers; however, SageCRM depends on Microsoft’s Internet Information Server (IIS). Hence we will be installing and supporting Sage ERP Accpac 6.x on IIS.
However Accpac doesn’t run from IIS like SageCRM does. SageCRM was developed from the ground up as an IIS add-in called an ISAPI add-in. This means SageCRM is a DLL that integrates directly into IIS and uses the IIS API for support. Sage ERP Accpac 6.x has been developed based on the Google Web Toolkit. This tool kit works best if the Server side of things is written in Java. IIS does not directly support running Java programs. To run Java programs to answer requests from the Web you need a Java Application Server. The function of a Java Application Server is to connect a set of Java classes up to URL’s, so when a Browser enters a URL that goes to the Java Application Server, this server provides the middleware to figure out which Java class to call and to call it in an appropriate manner. The Java Application Server that we are using is Apache Tomcat. However, again we haven’t done anything that ties us to this Java Server over any other, we just need to pick one to install and support, and Tomcat seems to work really well for us.
So how do Web Requests originating as URLs entered into a Browser make it to Accpac? The Apache foundation has created an IIS ISAPI add-in called Jakarta that will forward any requests meant for Tomcat received via IIS directly to Tomcat. It has a very high speed low overhead way of doing this to keep performance high. Basically Jakarta is configured with a set or URL patterns to forward and then it does this. Jakarta also can maintain multiple instances of Tomcat and act as a foundation for load balancing.
The URL requests, which we saw previously, are using the SData protocol. These SData requests are received into the Accpac Java Servlet (or program) that processes SData. This program running inside Tomcat then parses and processes the SData requests which are translated into Accpac Business Logic Layer (or View) calls. Calls to the Views are made through a Java Native Interface (JNI) Layer to execute as normal. JNI is the mechanism inside Java to allow calls to underlying operating system DLLs (or SOs in the Linux case). And then the Views call through to the database in the normal Accpac manner.
Below is a simple diagram of the main processes involved.
Since IIS is receiving the Web Requests, it is IIS’s job to handle the security of the connection between the Web Browser and the Web Server. Usually IIS will be configured to only accept connections via TLS (Transport Layer Security, previously known as Secure Socket Layer (SSL)). That means the Web Server will require a digital certificate to properly identify itself and avoid many Browser warnings. Fortunately setting up TLS for IIS is quite simple and with modern computers the overhead of this encrypted communication isn’t too bad.
Otherwise Accpac is installed on the Web Server as a normal server install and the installation of the database (probably SQL Server to share with SageCRM) is the same as previous versions of Accpac.
IIS and SQL Server will need to be installed first. Accpac’s installation program will install and configure Tomcat, Jakarta and all required Java components. The SQL Server can be the same or a different server from the IIS server depending on the server load.
Hopefully this give a taste for how Sage ERP Accpac 6.x will be deployed for all the new Web based screens.