Some more thoughts on Self Service Configuration

2 minute read time.

I wrote some time ago about "Installing Self Service". That earlier short article discussed that two separate installs of Sage CRM need to be used to set up Sage CRM with Self Service on a different web server and that the Self Service database can reside on a different SQL server than the main Sage CRM database.

I was asked recently about this by a business partner who had some concerns.

  • They we looking for reassurance about the validity of the architecture
  • How patches should be handled.
  • How metadata is refreshed.
  • How Sage CRM licensing works and whether their customer needed to purchase 2 licenses

Validity of Architecture

I have double checked with my support colleagues and they are happy with the set up that is described in this diagram.

The diagram above shows that two installs of Sage CRM are needed to allow the Self Service site to be housed on a web server beyond the corporate firewall.

The Self Service database (Visitor/VisitorProfile) and tables can sit on a different SQL server to the main Sage CRM database which holds the application and metadata. The System Administration documentation discusses that the Self Service install and the main system can be on different servers

http://help.sagecrm.com/on_premise/en/2018R3/administration/Content/Administrator/SA_SSConfiguration.htm

Note: The architecture detailed in this diagram is supported by Sage with the understanding and warning that the architecture requires careful change control management.

Patching of Servers

The Self Service server as a secondary instance of Sage CRM would have to have patched as any install of Sage CRM. This is not an automatic process.

Patches to the self-service server would have to be manually coincidental with the patching of the main application server.

Meta Data

Meta Data for the definitions of the Lists and Screens referenced by the Self Service install resides on the main server. Meta Data is only loaded on the initial instantiation of the Self Service object. This means that the separate Self Service install will not pick up changes to metadata definitions of screens and lists used by Self Service unless Meta Data is manually refreshed on the Self Service instance or if the Self Service instance is restarted.

Licensing

The one thing that is difficult for me to be firm on is the licensing question. Licensing considerations are a commercial matter for local Sage Operating Companies (e.g. Sage North America, Sage Asia etc) so whether this is an architecture that can work for a particular customer would need to be discussed with your local Sage team.

Parents
  • Hi, I followed this recommendations carefully but clearly found that metadata applied to the SelfService page come from the CRM database next to the Self Service Database and not from the production System database behind the firewall. I found this strange behaviour when I tried to add a Selection field in the default customerservice asp page and when I didn't found the customized value list and found the default value list coming from the defaut website instead.

    We use 7.1.h (= i 7.5 FR release)

Comment
  • Hi, I followed this recommendations carefully but clearly found that metadata applied to the SelfService page come from the CRM database next to the Self Service Database and not from the production System database behind the firewall. I found this strange behaviour when I tried to add a Selection field in the default customerservice asp page and when I didn't found the customized value list and found the default value list coming from the defaut website instead.

    We use 7.1.h (= i 7.5 FR release)

Children
No Data