Post-Installation Tasks

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.

Note
For an application server to be able to send e-mail, it needs to know which e-mail server is to be used. This is done by making the following entry in the semiramis/classes/system.properties file: mail.smtp.host=yourmailserver

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.

Note
After making changes, the application server must be restarted for the changes to take effect.

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.

Note
After making changes, the application server must be restarted for the changes to take effect.

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.

Note
After creating own certificates, it is necessary to sort and organize the existing certificates, for instance, delete those which are no longer used.

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.

Note
After making changes, the application server must be restarted for the changes to take effect.

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.
Note
Restricted ODBC access results in a higher database workload.
  • 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.

[/alert]Each batch job specified in the above table needs one persistent thread constantly.[/alert]

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.

Note
Each inventory management server requires two threads in a processing queue.

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.

Example
https://localhost/kstore/
Note
Access to Knowledge Store is granted as part of authorization roles.

Authorizations

It is necessary to verify or create authorization roles conforming to the system’s security policy and its intended use. More information may be found in the documentation Authorization Roles.

The documentations Authorization Roles and Authorization Elements provide an in-depth overview of the Comarch ERP Enterprise authorization concept.

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. More information may be found in the documentation Checklist: System Configuration.

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.

More information may be found in the documentation ODBC Data Sources.

Further configuration

Further work to start the system must be done in areas described in the following articles:

  • Setting Up a New OLTP Database
  • Customizing: ERP Functions
  • Introduction: Organizations

 

Czy ten artykuł był pomocny?

Wyślij opnie