Customizations within a multi-server Install of Sage CRM 2017 R2

Hints, Tips and Tricks

Technical Hints Tips and Tricks that cover customization and development using Sage CRM. API usage and coding are covered.

Customizations within a multi-server Install of Sage CRM 2017 R2

  • Comments 2
  • Likes

In larger Sage CRM implementation where there is a high demand on the application server, it is possible to distribute the system across several additional application servers where a single database is accessible through those multiple servers. Performance can be considerably enhanced through the load balancing provided by Sage CRM or by a dedicated load balancing application.

The guides within the Help Center describe how to implement such a multi-server Sage CRM environment.

One of the key characteristics of Sage CRM is that it is easily customizable and extendable. The screens and user interface can be changed to support new fields. Business rules can be added to the system in the form of workflow and time-based escalation rules. New entities can be modelled within the system and the screens and lists to display the new data can be scripted in classic ASP pages or by using the .NET API. And user-driven workflow can also invoke entirely new behaviour using ASP and .NET calls.

In this article, I want to consider customization within a multi-server environment.

There are 3 aspects of customization I wish to discuss.

  • The Distribution of Services
  • Meta Data customization
  • ASP and .NET Extensions.

The Distribution of Services

The services themselves can not be customized but they do interact with customizations.

For example, the QuickFind and Keyword search are controlled by configurations stored in metadata. The entities included in QuickFind (which may also include custom entities) can be controlled. And the views used in Keyword searches can be changed through metadata. Escalation rules are also defined completely in the metadata. Because this behaviour is metadata controlled I will mention this again in the next section when I discuss metadata customization more fully.

The CRM E-Mail Manager service (Advanced Email Manager) is different. Although its operation is controlled and defined in metadata the business rules by which the inbound emails are handled are actually defined in JavaScript files. These are the script template files.

These script template files must be placed on the server which is configured to have the CRM E-Mail Manager service running.

The example above shows a four server multiserver environment. In this case, we have one database server and then 3 application servers.

The Sage CRM Services should only have one instance running in the server cluster.

  • Server 1 – has CRM & Email manager running
  • Server 2 – CRM & Escalation service running
  • Server 3 – CRM & Keyword Indexer and QuickFind service running

Metadata customization

Metadata is customized through the user interface and stored in the database. This database set of definitions is common to all application servers within a multi-server environment.

Any customization carried out in metadata on one server will be reflected on all the other application servers in the system. This is because they are all sharing the same database.

Metadata will be refreshed for all users once any customizations are carried out on any of the web servers. For example, if the System Administrator adds a new field for the company entity or changes the columns in the Opportunity List then these changes will also appear for a user logged into another web server.

This happens because when metadata change occurs within the system there is a system parameter (called MetadataVersion) which has its value incremented by one.

All the other application servers will check this regularly and will refresh metadata automatically when they detect a change.

ASP and .NET Extensions.

ASP and .NET Extensions rely on additional file resources on the application server.

If during an implementation a new custom entity is created through the user interface on one of the application servers then the physical changes to the database will be common to all application servers. The metadata that describes the new tables, fields, screens and lists will also be common across the system.

But any ASP page or .NET assembly that is referenced by the system to draw the new interface will need to be manually copied to the other application servers.

For example, if you use the Advanced Customization Wizard this will create ASP pages for a new entity but these will only be added to the local directory of the web server where the wizard was run.

To resolve this you can copy the ASP pages over from one web server to the other web servers. This is true for customizations that use .NET assemblies and any client-side customizations that reference JavaScript library files.

As I noted earlier you will also need to make sure that the script template files used by the Advanced Email Manager must be placed on the server on which the CRM E-Mail Manager service is running.

Any additional resources such as new icons and images will also need to be copied to the other servers.