Introduction
This documentation provides a description of steps that should be carried out when an installation system has been installed or a new system created.
The document should be regarded as a checklist to help verify that all necessary work has been completed. The individual chapters refer the reader to detailed step-by-step instructions.
Checklist
System definition in System cockpit
The System cockpit application is used to configure the system; it contains settings for databases, application servers (SAS), and users, among others. More information on particular parameters referred to below may be found in the documentation of the System cockpit application.
Verify system.properties
It is necessary to verify the semiramis/classes/system.properties file on the desired properties.
Adapt the JVM parameters
The standard MESSAGESERVER application server is delivered with a default heap size of 300 MB, although these values are not suitable for production performance. The heap size of each SAS needs to be adjusted to enterprise requirements and appropriate JVM parameters need to be entered.
The JVM Settings documentation lists recommended JVM parameters for a variety of usage scenarios. Please note that for each operating system platform, different parameters are specified in this documentation.
Adjust the heap memory parameters
The Maximum heap memory parameter needs to be adjusted for each SAS. This parameter should correspond to the specifications made for the -Xmx JVM parameter. It is not recommended to enter different values.
Create new certificates
It is necessary to create an individual certificate hierarchy, with a root certificate, certificate authorities, server certificates, and user certificates. More information may be found in the documentation Generate Certificates.
Database timeout
The database timeouts set currently should be verified. No timeout should be set in the production system. This means that connections that are established with the database are closed only when SAS is stopped.
Application server
For each application server, it is necessary to verify:
- a URL address
- a certificate generated by the desired certificate authority and its validity date
- JVM and heap parameters
- ODBC access – in the case of an ODBC production server for SOM (Standard Output Manager), access must be unrestricted.
- required number of database connections – recommendations can be found in the System Cockpit
Set application server caches
After setting the application server, it is necessary to set the cache for the application server. More information may be found in the documentation Application Server Settings.
Setting the cache is a crucial factor for the application server performance. If the chosen cache size is too small, it leads to a large number of queries sent directly to the database, and this negatively affects the overall system performance.
It is necessary to monitor partition loads in the System cockpit application. More information and recommended cache sizes may be found in the documentation Share Cache Management.
If new databases are being set up and connected to SAS, it is necessary to make cache settings for those databases.
Verify dialog threads
Dialog threads are used to process tasks and requests invoked from the interface to the application server.
The default setting for the number of threads in batch processing is sufficient for most application scenarios. If the application server which is primarily used by interactive users has more than one processor available, it is possible to increase the number of threads for dialog processing. Please note that setting a too high number of dialog threads per CPU leads to a deterioration of the application server response times. More information may be found in the documentation ERP Properties.
Databases
In the case of database settings, it is necessary to verify:
- OLAP connection data for the OLTP database
- correctness of user and schema data
- defined number of connections to the database – more information may be found in the System Cockpit
Import restrictions
It is necessary to verify specified import restrictions for the newly defined system. The transport path must be strictly observed.
It must be made sure that no software updates can be imported from incorrect predecessor systems.
Assign a user to the system
Assigning users to the system is necessary for the user appearing in the configuration database to have access to the indicated system.
Languages
The languages provided in the installation system are German and English. In order to use other languages, it is necessary to have a license for them and install appropriate language updates. More information may be found in the documentation Install Language Updates Automatically.
Set up additional OLTP secondary languages
If other secondary languages are set in addition to the primary language in the OLTP database after the database is created, all fields of the secondary language tables will be left empty. The batch application Reorganize database languages fills the secondary language tables according to the value of the default language. Alternatively, the rgzdbt shell tool command may be used.
Batch processing
Standard batch and reorganization jobs
Batch jobs are tasks which are executed or start to be executed as soon as the system starts. The system should have defined batch and reorganization tasks required for a given system. More information may be found in the documentations Batch Jobs and Reorganization Jobs.
In particular, performance-impacting data reorganization should be activated at regular intervals. Otherwise, database volume will increase quickly. When doing so, note that some jobs need to be set up only once per system, but some need to be set up for each OLTP database connected.
| Batch job | Properties | Technical name |
| Synchronize Financials data
|
• No more than once for each OLTP database
• Start type: at each SAS start • SAS can start several TransferBatches |
com.cisag.app.financials.
batch.log. StartTransferBatches |
| Transfer partners to Financial
Accounting
|
• No more than once for each OLTP database
• Start type: at each SAS start • SAS can start several TransferBatches |
com.cisag.app.financials.
batch.log. PartnerTransferBatch |
| Reorganize history
|
• No more than once for each OLTP database
• Start type: at each SAS start • SAS can start several TransferBatches |
com.cisag.sys. preferences.log.
UserHistoryReorganization |
| Reorganization job | Properties | Technical name |
| Reorganize performance data
|
For each database
|
com.cisag.sys.tools.profiling.log.Database MonitoringReorganization |
| Reorganize output jobs | com.cisag.sys.print.ou tqueue.log.OutQueueEnt ryReorganization | |
| Reorganize message log entries | com.cisag.sys.tools.me ssagelog.log.MessageLo gEntryReorganization | |
| Reorganize change journal | com.cisag.sys.tools.mo dificationjournal.log. ModificationJournalReorganization | |
| Reorganize activities | com.cisag.sys.workflow . log.ActivityReorganization | |
| Reorganize data exchange logs | com.cisag.sys.tools.bi . log.ProcessProtocolReorganization |
In the processing queues used, the number of threads should be adjusted sufficiently. The number of threads depends on the number of batch jobs that the processing queue is intended to handle.
Planning server
At least one planning server should be started. Planning servers are defined separately for each OLTP database. More information may be found in the documentation Material Requirements Planning. Planning servers are started and stopped in the Material Requirements Planning application. To do this, the processing queue is specified in the application, according to which the planning shall run. Several planning server instances may run on each SAS. This number is restricted by the maximum number of threads in the processing queue and by available RAM.
Inventory management server
At least one inventory management server should be started. Inventory management servers are defined separately for each OLTP database.
Output management
The Introduction: Output Management document provides an overview of output management and related processes.
System Output Manager (SOM)
The system’s output server settings should be verified. For the Windows operating system, it is necessary to install the System Output Manager program. More information may be found in the documentation Install System Output Manager.
To verify proper SOM configuration, it is necessary to check:
- possibility to output vouchers and reports and send them by e-mail
- whether the Outputserver user is assigned to the system and belongs to the Administrators user group
- whether an open database connectivity (ODBC) to the relevant application server has been established and activated
- whether the application server allows unrestricted ODBC access
- defined threads to handle reports according to the definition of output priorities and infrastructure capacity.
Set up output devices
Output devices should be defined for output via e-mail, printers, and fax machines. More information may be found in the documentation Output Devices. The user can only use the output devices defined in a relevant authorization role.
Define voucher document templates
Templates for voucher documents used in the system should be defined and tested. For users with differing output requirements and specifications, it is possible to define substitute voucher document templates. More information may be found in the documentation Voucher Document Templates.
Knowledge Store connection
It is necessary to verify connection to the Knowledge Store (Kstore). To do this, it is necessary to create a new network drive in Windows Explorer that provides a shortcut to a web folder. More information may be found in the documentation Knowledge Store.
The standard Knowledge Store workspace is available at the system address with a kstore suffix.
Authorizations
It is necessary to verify or create authorization roles conforming to the system’s security policy and its intended use.
System configuration checklist
The system configuration checklist should be used to verify that the system is configured correctly. Many of the points discussed in this documentation are also part of the checklist.
Infrastructure
File system
It is necessary to verify the Comarch ERP Enterprise directory structure. For instance, a test system should have an empty source directory. For a production system, the import of software updates should be limited to packages originating from a test or development system.
Database management system
It is necessary to monitor the database engine, follow best practices, and respond to system events to best tune the system.
Microsoft SQL Server
It is necessary to pay attention to parameters that may require database adjustments depending on how the installation is used. Below are the most important of these:
- Optimization configuration
- Adjusting the size of data and log files
- Backup creation
- Archiving server log files
- Archiving and shrinking the transaction log. The backup plan should include saving transaction logs and then emptying them to ensure efficient use of available hard drive space.
- Increasing the size of the TempDB database to approximately 4 GB. If the hard drive space is limited, it is necessary to make sure that the database will not continue to grow dynamically.
- Monitoring performance using tools built into the SQL engine to identify performance degradation early and take appropriate action.
- The database isolation level should be set to READ_COMMITTED_SNAPSHOT.
- Creating weekly tasks for index reorganization/recompilation.
Oracle
After importing a Comarch ERP Enterprise database, it is necessary to use the Oracle Analyze tables command to update statistics for the Optimizer. After that, it should be done at regular intervals. The Optimizer statistics are absolutely essential for maintaining high performance of the Oracle engine. It is necessary to verify the following tasks:
- Adapting the initialization parameters
- Setting the required archiving mode
- Separating the DBMS log files from the payload (user data)
- Monitoring the system’s storage increase and creating new data files for the tablespaces used
- Ensuring the TEMPT tablespace is situated on a partition with sufficient free memory space. This tablespace can grow up to 32 GB, unless its size is restricted. If possible, the TEMP and UNDO tablespaces should be created on their own partitions.
- Monitoring performance using tools built into the SQL engine to identify performance degradation early and take appropriate action.
- Increasing the number of Redo logs, if it is necessary
i5/OS
For an SQL engine on the i5/OS system, it is necessary to take care of:
- Own sub-system and cache pools for all SAS
- Monitoring performance using tools built into the SQL engine to identify performance degradation early and take appropriate action.
- Using the latest version of the JDBC driver
- Using the latest PTF version
Backup
It is necessary to set up regular backups for databases and the file system.
Databases and the file system must have a consistent state and mirror each other, so it is important that copies come from a single time period.
Losing one system in the update transport path is a severe impediment and involves considerable efforts in establishing a new transport path. For this reason, these systems must also be integrated in a well-functioning backup routine.
Time server
All application servers started in the production system landscape should run synchronously. This is impeded by the fact that the longer computers are running, the more their time managements differ. Therefore, it is necessary to set up a central time server for synchronizing all computers in the network at regular intervals.
Network configuration
It is necessary to make sure that all deployed servers are connected to each other with the highest possible speed. In order to minimize the effects of a large number of computers in the network, it may be expedient to subdivide the network in several segments and set up a proprietary network segment for the Comarch ERP Enterprise system servers.
If VPNs are used, consistent Quality of Service Policies should be established for all satellite stations connected via VPN so that https traffic from and to SAS is prioritized over, for example, e-mail.
Client hardware checklist
Web browser configuration
In order for the system to function properly in the browser, it is necessary to:
- Install the user certificates
- Test access to the system
- Verify the Internet access options
- Verify the proxy settings
- Add the system address to trusted sites
Configuration of antivirus programs
Antivirus programs are needed to protect servers and clients from malware and viruses. The negative impact of virus scanners on performance should be considered during installation and production work of the system.
- Depending on their configuration, virus scanners may scan every picture and every web page downloaded by an application server. This may negatively affect performance on the client side.
- Scanning every incoming and outgoing network packet on the server will have a negative impact on performance. It is worthwhile to periodically check the entire system for viruses. It should be avoided to continuously use the server-side virus scanner; alternatively, the Comarch ERP Enterprise system directory should be excluded from continuous monitoring by using appropriate rules.
Firewall configuration
If a firewall is used, it is necessary to allow access to Comarch ERP Enterprise system through the definition of a rule which would always enable access with the use of the https protocol.
Configuration of Knowledge Store connections
In the file explorer, it is possible to configure access to WebDAV Knowledge Store drives as network drives.
Access is generally through the following address:
https://[system_address]/kstore
Installation of the ODBC driver
To enable ODBC access to databases from third-party software, it is necessary to install the ODBC driver. Software products that use ODBC include Crystal Reports, Microsoft Excel, and Cognos PowerPlay.