Appendix B
Client Configuration #
Configuration Files #
SICS has several configuration files:
- Command line parameters
- Ini file settings
- Resource registry settings
- Log configuration
- Class loader configuration
Command Line Parameters #
See Appendix C - Command line parameters
Ini File Settings #
NOTE:
This information does not apply to SICS API Server. Please see separate installation documentation for SICS API Server.
The ini file settings serve to configure one or more login properties.
The settings are stored in a so-called ‘property’ file. This is a text file where each line represents one property and its value. The property name and the value are separated by an equal sign.
These properties are all read-only, that is, the value in the file will be read by SICS but never modified. The ini file settings must be configured per user. There is no global settings file.
The ini file is named sics.inifile.properties. If the Java system property sics.user.home has been set (by including it with the -D switch on the java command line or in the SicsJavaLauncher.ini file), then SICS will look in this place for the settings file (note that when -D is provided in the SicsJavaLauncher.ini file, then there will be NO substitution of Windows environment variable names, except for %USERNAME%). If the settings file was not found in this place, then SICS will look in the place determined by the Java JDK as the ‘user home’. Where this is, depends both on the JDK version / implementation, and the Windows version.
The following table lists all ini file settings:
| PROPERTY | TYPE | DESCRIPTION |
|---|---|---|
SINGLESIGNON |
read-only | N or Y(please see the System Administration Guide for details on Single Sign On) |
USER |
read-only | User Id |
PASSWORD |
read-only | Password (can be encrypted, please see Appendix F - Password Encryption) |
DATABASE |
read-only | Database name |
OS_AUTHENTICATION |
read-only | N or Y |
ENVIRONMENT |
read-only | Login environment |
Resource Registry Settings #
The resource registry settings serve partly to configure various behavioral aspects of SICS, partly to remember certain settings from one login session to another.
The settings are stored in a so-called ‘property’ file. This is a text file where each line represents one property and its value. The property name and the value are separated by an equal sign.
Some properties are read-only, that is, the value in the file will be read by SICS but never modified. Other properties are read/write. SICS uses read/write properties to remember certain settings from one login session to another.
There are two levels of resource registry settings:
- Global settings
- User settings
When SICS needs to look up a property setting, it will look in the user settings file first. If this file is missing, or if the property is missing in this file, SICS will look in the global setting file.
The user settings file is named sics.resourceregistry.properties. Please note that there is no dot between ‘resource’ and ‘registry’ (as opposed to the global settings file). If the Java system property sics.user.home has been set (by including it with the -D switch on the java command line), then SICS will look in this place for the settings file. If the user settings file was not found in this place, then SICS will look in the place determined by the Windows environment variable UserProfile. This variable is always defined and points to either <root>\Documents and Settings\<username> (Prior to Windows Vista) or <root>\Users\<username> (Windows Vista onwards).
The global settings file is named sics.global.resource.registry.properties. If the Java system property sics.global.resource.registry.path has been set (by including it with the -D switch on the java command line), then SICS will look in this place for the settings file, else SICS will look in the classpath. The classpath starts with the SICS installation’s \conf subfolder and this is where the SICS installation has its default global settings file.
When SICS needs to write (store) a property setting, it will always write it to the user settings file. If such a file is not existing, SICS will create one in the place determined by the Windows environment variable UserProfile (see above).
The following table lists all read-only settings and the most interesting read/write settings:
| PROPERTY | TYPE | DESCRIPTION |
|---|---|---|
UserId |
read/write | User Id from last login |
ConnectString |
read/write | Database name from last login |
ConnectUsingDatabaseRemoteOsAuthentication |
read/write | N or Yvalue from last login |
ConnectUsingSingleSignOn |
read/write | N or YWhether SICS should connect to the database using Single Sign On (this is described in the sections Ini File Settings and SICS Application Command Line Arguments). The default is N. |
ShouldAttemptReconnect |
read-only(2) | N or YThe default is Y. Y means SICS will attempt to reconnect to the database when the database connection is lost. This reconnect feature is only available for Oracle databases. |
WalkbackFolder |
Folder for writing walkbacks. NOTE: Use double backslashes in Windows. |
|
LocalTime |
read-only | Global or Local. Whether to get ‘current’ date and timestamp from the database server of from the local computer. The default is Global. The value “Local” may be used for problem finding purposes when instructed by DXC. Note that this may have unpredictable consequences on the behavior of SICS and the data it stores in the database, especially if the PC’s local timestamp is very different from that of the database server. Experiments with setting this property to “Local” should only be done on a test database, never in production. |
DecimalPointCharacter |
read-only | Defaults to dot/period . if missing, but the default value will not be written to the user settings file |
OrderedObjectMaxSize |
read/write(1) | See description in maintenance window |
WindowCenterX |
read/write(1) | See description in maintenance window |
WindowCenterY |
read/write(1) | See description in maintenance window |
ShouldPositionDialogBoxes |
read/write(1) | N or YSee description in maintenance window. |
ShouldPromptForServerLoginFields |
read-only | N or YWhether SICS API Server should prompt for database login fields (username, password, database). The default is N. |
UserExitImplementation |
read-only | Name of Java class implementing a custom UserExit. It must implement interface: SicsUserExitInterfacein package com.csc.cnu.base.domain.eventlog.implThe default implementation is class: SicsUserExitDefaultImplin package com.csc.cnu.base.domain.eventlog.implThe default implementation is a DXC-provided ‘dummy’ implementation which does nothing. |
DMSInterface |
read-only | Name of Java class used to interact with a Document Management System (DMS) external to SICS. It must implement interface: SicsDocumentManagementSystemInterfacein package com.csc.cnu.base.domainThe default implementation is class: SicsDocumentManagementSystemDefaultImplin package com.csc.cnu.base.domainThe default implementation is a DXC-provided proof-of-concept implementation which uses simple folders in the file system. |
InstallationSetupFileDirectory |
read-only(2) | Path to the database setup files (initial values for currencies, countries, states and users). The default value is the /setup subfolder relative to the folder from where SICS is started. |
- Value can be edited using the ‘Resource Registry Maintenance’ function in SICS System Administration.
- The default value will be written to the user settings file if this property is not found in either the user settings or the global settings file.
Log Configuration #
Logging is done using the Apache Log4j 2 framework.
Among other things, this is where logging / tracing of SQL can be activated.
The configuration file is \conf\log4j2.xml.
For SICS API Server, the file is SwanLake\src\resources\log4j2.xml. Please see separate installation documentation for SICS API Server.
Logging options are described inside the log4j2 file. Some options are enabled at installation time, others are disabled. Please read the comments and instructions in the log4j2 file.
Class Loader Configuration #
SICS uses its own, specialized class loader for loading Java classes. There are a number of properties that can be set for this class loader.
These properties are initially read from the file sics.classpath.xml in the \conf subfolder.
The initial values can be overridden by setting Java VM arguments with the -D switch on the command line.
The default initial values contained in the sics.classpath.xml file are those which have been used by DXC when testing the product. Under normal circumstances, these values should not be modified. Please contact DXC for further details.
Email Configuration #
Several functions in SICS allow for the sending of email. Examples are, Task Management, Batch Job Processing, Notifiers.
Usually, such emails are sent synchronously from the computer where SICS executes, to the configured SMTP server.
Some clients may have a security policy which does not allow the sending of email from ‘any’ SICS runtime, but only from a few clearly identified computers. In such a case, SICS can be configured to use centralized, asynchronous email sending, which means that outgoing emails are stored in a staging area (database table) which can later be processed by a batch job running on an email-enabled computer. This batch job will then (try to) send the staged emails to the configured SMTP server.
The configuration file is \conf\sics.mail.properties. The various settings are documented in this file and will not be repeated here.
Please note the following restrictions regarding centralized email sending:
- There is no support for viewing or updating staged emails.
- There is no support for deleting staged emails, except from the above mentioned batch job. Specifically, there is no support for deleting staged emails that have reached their retry threshold when
mail.centralized.keep.unsentis true. Such emails will stay in the staging area indefinitely (unless deleted by manually executed SQL). - A staged email will know which domain object (task/job/notifier) is its ‘parent’, but there is (currently) no functionality using this information. In other words, a staged email cannot be ‘seen’ or opened from anywhere.
- There is no support for retrieving / updating / deleting staged emails via SICS API Server.
- There is no BO reporting support for staged emails.