Settings and administration tools specific to ModuleSuite components can be accessed from the Content Server Administration pages.
Detailed information related to the single tools and configuration pages is provided in the following sections.
The Base Configuration page provides access to:
utilities to perform initial import/upgrade/backup of the Content Script Volume contents
ModuleSuite database maintenance utilities
global configuration of the Content Script engine, and configuration of the single API services
configuration of custom Content Script extension modules
Every time changes are made to the Base Configuration, a Content Server restart is required.
Select default IP address¶
It is quite common for Content Server services to be installed on servers that have multiple newtork interfaces associated with different IP addresses.
Sometimes it is desirable to control which interface or IP address Module Suite uses for external communication (for example with the Content Script extension's csws service). In such a situation you can use an additional custom configuration parameter in the base configuration to control interface binding. In fact, the Custom property amcs.loopback.cIPs allows you to bind an IP address to its server host address. Multiple mappings are supported.
IP Mapping Configuration
Keep in mind that IP addresses must be valid and assigned to one of the server's network iterfaces
Enable / Disable Module Suite features¶
The amcs.core.debugEnabled is a "core" configuration flag you can use to customize your Module Suite instance enabling/disabling ModuleSuite core features. Each bit in the mask represent a different feature that can enabled (0) or disabled (1).
Here below a reference for the meaning of each bit in the mask.
|Position||Meaning||Valid values||Decimal value|
|2||Enable/Disable Module Suite internal cache (CSVolume, Form Templates, SubViews, Localization etc)||0 (default)= cache enabled, 1=cache disabled||2|
|3||Callback script execution context mode||0(default)= single execution context for each script of the chain, 1= shared execution context (same for all the scripts in the chain)||4|
|4||Content Script objects indexing||0(default)= Content Script objects are not indexed by the search engine, 1=Content Script objects are indexed by the search engine||8|
|5||Track in the audit trail when a Content Script is executed||0(default)= Do not track in the audit trail the execution of Content Scripts, 1=Track in the audit trail the execution of Content Scripts||16|
|6||Enable/Disable Asynch events management||0(default)= Asynch events management is enabled, 1=Asynch events management is disabled||32|
|7||Perform the lookup to determined if there are script to be executed asynchronously when the event is raised||0(default)= Any "interesting" event for Asynch events management is tracked in the Distributed Agent queue and the lookup required to determined if there are scripts to be executed is performed later on by the same DA worker that manages script execution, 1=The lookup required to determined if there are scripts to be executed asynchronously given the registered event is executed when the event is raised. The information is passed to the DA queue only if the lookup finds that there are scripts that need to be executed||64|
|8||Enable the Content Script Sandbox||128|
|9||Enables the Content Script Sandbox (disabled by default)||256|
|10||Enables the View Template Cache (The system is no longer going to check for the version of the Beautiful Webforms View Templates associated to the view when a WebForm is rendered)||512|
|11||For every Content Script, it is possible to define a set of static, precompiled variables whose values will be available when the script is executed. The framework supports the definition of these variables by means of a second script, whose outcome is the data map containing the values. For performance reasons, this second script is executed only when it changes (or when execution is explicitly forced by an editor), and the results are stored as part of the script object. The information is retrieved from the Database upon execution when you execute a subscript using the runCS API or you retrive this information using the getCSVars API on a CSScript object. In situation in which the Database is under stress or the retrieval of this information does not perform as expected it is possible to configure the framework so that this information is cached in memory.||0(default)=cache disabled. 1=cache enabled||1024|
|12||In environments where ACL evaluation is quite expensive it is possible to change strategy used by the API that fetches the information related to the list of nodes in a container||0(default)=standard strategy (should work well in most of the cases), 1=Alternative strategy (due to complex and convoluted ACLs)||2048|
Example of valid configuration values:
- Enable Content Script indexing while disabling Module Suite cache: 8+2 = 2
- Enable Content Script execution audit trail while disabling Asynch events management: 16 + 32 = 48
The Content Script logging page allows administrators to configure the logging level of Content Script services and objects, and also provides quick access to the log file. Logging level can be changed at runtime without restarting the Content Server.
Each Content Script is identified by the two capital letters "CS" followed by the Content Script's DataID (e.g. CS12345).
Where is my log ?
Logging configuration is a server-instance configuration, please keep it in consideration when trying to set the logging level of a scheduled script (in clustered environments), since it could actually be executed on any server on which Distributed Agents are activated.
Manage API Services¶
The Content Script Extension Package management page allows to configure the availability of Content Script API services during script execution.
When installed, services are active by default. A Content Server restart is required whenever changes are made to Content Script API extension package availability.
The Content Script Scheduling administration panel provides a quick overview of the Content Script objects that are queued for scheduled execution, together with the next fire time, the expression used to calculate the execution schedule, and generic information related to the object itself. The object menu allows to easily access the node standard functions.
An unschedule utility allows to stop the scheduling of the corresponding script.
The complete set of configuration options for Content Script scheduling (as well as impersonation settings) are available through the Content Script editor Administration tab
The Callbacks management panel provides a tool to verify in every moment what Content Script callbacks will be executed for specific objects in response to specific event types.
Details on how to configure Content Script Callbacks are provided in the following sections.