In this article I would like to look at how Sage CRM is designed and how its architecture enables its features.

Sage CRM is a product in transition; it is moving from one architecture to another. This is a evolution that started with Sage CRM 7.0 and has continued through to the current version and still has further to go.

Have a look at the screen below.

The screen shown here is the Person Summary screen from Sage CRM. It is important to remind ourselves that Sage CRM is a browser based application. The user interface is HTML and drawn in the browser as a result of a standard web HTTP request.

It is the address line in the browser that I want you to consider

http://localhost/crm/eware.dll/Do?SID=157613724028715 &Act=220 &Mode=1 &CLk=T &Key0=2 &Key1=28 &Key2=30 &T=Person

You will see that this is referencing something called "eware.dll".

Below is an image that shows Sage CRM's architecture before the evolution began. This is what the design of Sage CRM 6.2 would have been.

'eWare.dll' is a 32bit application written in a language called Delphi.

The diagram shows how a request is sent from the browser, this is either over HTTP or HTTPS, to the eWare.dll that runs under the IIS (Internet Information Services) Web Server. The eWare.dll is an ISAPI (Internet Server Application Programming Interface) extension that is accessed by the HTTP request in the same way as a static HTML file.

The web request passed by the browser is directed to the eWare.dll and it returns the HTML that draws the screen for the user.

The eWare dll is responsible for handling the security and session management and how the interface is generated to take into account business rules and workflow. It returns the HTML that builds the screens that the user sees.

The eWare.dll interacts with its database through ADO (ActiveX Data Objects). The database holds the meta data that describes how the screen should be built and the application data is the business information which is the focus for the system users.

It should be pointed out that the key aspect for system performance is the database. The resources and tuning of the database have the largest impact on the users experience of the system. Sage CRM and the eWare.dll can take full advantage of 64bit databases.

Sage CRM is fast, reliable and technically very rich and offers an excellent platform for customization around a customers requirements. BUT being 32bit and rather than 64bit does place a restriction on the way in which Sage CRM can be designed to take advantage of computing power within the web server. I will return to this idea a little later on in this article.

There are a number of Windows Services that are also installed on the web server that work alongside the eWare.dll and share its architecture.

These are the

• CRM Email Manager
  • This is responsible for the processing of Inbound emails
• CRM Escalation Service
  • This controls Notification, SLA Timings and Escalation Rules
• CRM Indexer Service
  • This enables the Keyword search feature.
• CRM Integration Service
  • This is to support ERP integration capabilities used by Sage CRM with certain Sage ERP software.
  • This is used only in systems with Sage developed integrations.

These can be seen under the Windows Management Console.

The eware.dll is also the key element for some the main APIs (Application Programming Interfaces).

The classic ASP pages and the .NET API both interact with the eware.dll. The ASP (Active Server Pages) can use COM objects (Component Object Model) that are exposed through the windows registry when Sage CRM is installed. This allows a programmer to write extensions to Sage CRM that uses its own objects to draw screens and fields, to insert and update data.

This also includes the Self Service API as it is based on the same ASP technology.

The .NET API uses COM Interop to allow Sage CRM's COM objects to be used in conjunction with .NET objects. Programmers can use .NET languages like C# and tools like Visual Studio to write sophisticated extensions to Sage CRM but these are all ultimately interacting with the eware.dll.

The different APIs are discussed in other articles that explain the way in which Sage CRM can be extended by developers.

Sage CRM 7 saw the start of evolution to the new product architecture and the move away from reliance on the eware.dll written in Delphi.

The diagram above shows the how Sage CRM has moved to a hybrid architecture that mixes Java technology with the existing eWare.dll design.

These supporting technologies include

• Apache Tomcat
• Spring Framework
• Hibernate

Apache Tomcat is developed by the Apache Software Foundation (ASF) and provides an ideal Java HTTP web server environment in which Java code can run. It is a simple robust web server and allows web applications written in Java to extend the features of Sage CRM. If you are a system administrator then you are likely to become aware of Tomcat as it is mentioned in system messages.

The Spring Framework is used by the developers who create Sage CRM to provide the structure for new features. It allows the use of industry standard code libraries that simplify the development process and speed up the delivery of additional functions. The use of the Spring Framework is completely invisible to all users including anyone wanting to extend the product using Sage CRM's APIs.

Hibernate or Hibernate Object Relational Mapping provides the developers who create Sage CRM a way of mapping the object oriented Java code with the underlying relational database. Hibernate enables Sage CRM to maintain the CRM metadata in memory so that it is database independent and fully managed and also maps Java data types to SQL data types and provides data query and retrieval facilities. The use of the Hibernate is completely invisible to all users including anyone wanting to extend the product using Sage CRM's APIs.

The Tomcat webapp (web application) uses JDBC to interact with the underlying database.

In Sage CRM there are large number of features that are provided through the new Java based technology. These include

• The Interactive Dashboard
• Data Import and Export
• Document drop panel
• Server Side Mail Merge

Other Java based features include printing to PDF.

In the diagram below you can see the way in which requests are redirected from IIS to Tomcat.

The Tomcat structure allows additional features to be added to Sage CRM through additional Tomcat web apps.

The Exchange Integration is an examples of the features provided through the use of extra web apps.

As existing features in Sage CRM are refreshed or as new features are added then these will be included within the Tomcat side of the architecture.

APIs such as SData and the Ajax features of the Client Side API all are based on the Java technology.

As Sage CRM evolves over the next few versions the Java technology will become more and more important and will eventually be free to fully use 64bit technology and all the richness that the underlying new technology can provide.