Scripts can be used added to Sage CRM in a number of different places. All these places together can create a web of interacting scripts.
You can see we have to think about
- the Browser in which the user interface is presented to the user
- the application layer that runs on the web server and
- the database which stores the business application data and metadata.
Sage CRM is a web application. When a user clicks on a hyperlink or when they submit a form, they send an HTTP request from the browser to the web server and the Sage CRM application responds by assembling the HTML that is returned to the browser.
If we think about an individual screen in Sage CRM. For example, think about the Opportunity Summary screen.
There are 3 types of script that can be added to each field in a screen. Below is the administration screen for just one block that makes up the screen.
We can see for each field
- Create scripts
- onChange scripts
- And Validate scripts
The big division is where these scripts are run and what they can control.
The diagram below is complex but it does show how everything works together.
As a screen like the Opportunity Summary screen is requested from the browser, the fields that are included in the screen definition are triggered to fire their ‘create scripts’. The create scripts are executed on the server. This is within the web server.
The create scripts can change the properties of the fields. The properties control how those fields look and behave and they do this by changing the HTML that is then delivered to the browser.
Within the browser, when a screen is in edit mode so that data can be entered or edited, the onChange scripts can fire when they detect the value in the field is altered.
These are scripts that fire inside the browser – so in the client and NOT the server. There will be different objects and data available for the script to reference.
If data has been changed then the user will want to save this into the database and they will submit the form as another HTTP request.
Each field within the screen may have a script associated. This script can check that the data submitted to be stored in the database makes business sense. The validation or validate rule checks the quality of the data to make sure that the data does not break any business rule. Is this an allowed value? Is this within the allowed range?
And if the data is not good then the validate rule can block the insertion into the database.
Table Level Scripts
Another type of script that is executed within the server are the Table Level Scripts. These table level scripts are executed still within the web server but before the data is committed into the database.
As data is inserted, as it is updated or as it is deleted it triggers an event. These events can have scripts attached to them that can cause other work to be done. This means that a change to an assigned user can trigger an email, a new opportunity being inserted can have a new task added to the user’s diary.
So far we have only been considering a static screen like the Opportunity Summary screen.
But entities like Opportunities, like Cases, can be "workflowed". The screens can be dynamically changed as we work our way through a business process.
The Scripting and Business Rule Web
And all these scripts fall into an even larger environment where we have time-based behaviour, notifications and escalations, that can also interact with the same data.
The links to the other articles in the series are listed below
- The syntax of the language and the different objects available.
- The objects that are available within the Browser.
- Binding a script to an event.
- Conditional behaviour and compound statements.
- Another look at Strings, regular expressions and other objects.
- Arrays, Functions, and techniques for processing objects.