Module Suite Administration Tools¶
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.
Base Configuration¶
The Base Configuration page provides access to:
- Software activation status
- Content Script Volume Library version
- 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
Configuration Export and Import
Since Module Suite version 3.2, the Base Configuration settings can be export and/or imported using standard Content Server administration tools.
Base Configuration updates and system restarts
Since Module Suite version 3.2, most changes to the Base Configuration settings no longer require a restart.
Nevertheless, certain specific features will still request a system restart: they are flagged in the Base Configuration pages with a "restart required" label.
Software activation key status¶
The activation status of the Module Suite software can be found in the first section of the Base Configuration page.
The actual activation key can be found in the "Core" section of the configuration page.
Apply or update the activation key
The activation key can be manually applied as described in the "Activate Module Suite by manually setting the activation key" section in the installation.
Alternatively, since Module Suite version 3.2, the Base Configuration settings can be exported and/or imported using standard Content Server administration tools. This includes the Module Suite activation key.
See the "Activate Module Suite by importing the activation key" section in the installation guide for further details.
Content Script Volume Library¶
An indication of the current Content Script Volume library version is shown Within the top section of the Base Configuration page.
Library not yet initialized warning
Upon initial installation, the Volume Library will appear as "not yet imported" and a warning message will be shown.
To finalize the installation, import the Volume Library through the Content Script Volume Import Tool.
Enable / Disable Module Suite features¶
The amcs.core.debugEnabled is a "core" configuration bitmask you can use to customize your Module Suite instance enabling/disabling certain core features at once. Each bit in the mask represent a different feature that can be enabled (0) or disabled (1), or switched between different execution modes.
Enhanced management in version 3.2
Since Module Suite version 3.2, each separate feature within the "core" configuration bitmask can be controlled through checkbox selectors.
Upon toggling the single options, the overall bitmask decimal value will automatically be updated.
Additionally, the system will request a restart only in case where a feature that requires it is updated.
Here below a reference for the meaning of each bit in the mask.
| Position | Meaning | Valid values | Decimal value |
|---|---|---|---|
| 1 | RESERVED | 0 | |
| 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 scripts 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 determine 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 determine 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 | RESERVED | 0 | 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
Select default IP address¶
It is quite common for Content Server services to be installed on servers that have multiple network 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
hostname.domain.com=192.168.100.100.
Keep in mind that IP addresses must be valid and assigned to one of the server's network interfaces.
Logging administration¶
The Content Script logging utility allows administrators to:
- access the log file without the need to log on to the server where the log resides
- configure the log level of Content Script objects that include logging instructions.
Accessing the log file¶
When opening the utility, the last lines in the log file will be automatically shown to the user. It is possible to perform the following actions:
- Refresh the screen to check for changes in the log
- Rotate the log (replaces the log file with an empty one)
- Download the complete log file
Log level configuration¶
The log level management section allows to change the logging level for each single Content Script object, at runtime.
Log level selection is progressive: setting the log level to a certain threshold will instruct the system to log all entries of that specific level, in addition to any entry of higher severity. For example:
- when setting the log to DEBUG, INFO and ERROR entries will also be logged
- when setting the log to ERROR, INFO and DEBUG entries will not be logged.
No restart required
Logging level can be changed at runtime without restarting the Content Server.
Past logs below threshold cannot be recovered
Note that changing the log level will only affect any future logging operations.
Past log entries below the original threshold are discarded and cannot be recovered.
Default log level is restored on system restart
Changes to the log level performed through this tool do not survive a restart of the OTCS services.
Upon restart, the log level will be set back to the default value (typically "ERROR").
Where is my log ?
The log management utility is not centralized: when running on a clustered environment, it is important to note that the utility will only show log contents and loggers configuration for the current server that is being accessed.
Logging, on the other hand, is specific to the single server/instance where the operation triggering the log is performed. It is important to keep this in mind when analyzing the log data, as an operation could have been executed on different servers. For example, logging entries related to scheduled scripts or asynchronous callbacks will typically be found on the servers where the Distributed Agents are set to run.
Scheduling management utility (Manage Scheduling)¶
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.
Configuration
The complete set of configuration options for Content Script scheduling (as well as impersonation settings) are available through the Content Script editor Administration tab
Callbacks management utility (Manage Callbacks)¶
The Callbacks management utility provides a tool to verify in every moment what Content Script callbacks will be executed for specific objects in response to specific event types.
The utility provides a set of filters that allow to identify:
- the target object
- the specific callback type(s) to be analyzed
- the callback mode (synchronous or asynchronous)
Based on the filter, the result will show a list of affected nodes.
Module Suite Report utility¶
The Module Suite Report utility allows the administrators to generate a report containing information relevant to the installation, configuration and execution of Module Suite.
This is especially useful in case of issues to share details regarding the environment with product support representatives.
The generated report is in text format, as show below:
