Requisiti di sistema

Questa documentazione contiene le informazioni di base e le indicazioni riguardanti i dispositivi e il software necessari per installare Comarch ERP Enterprise.

Nota

Le specificazioni seguenti vanno adattate alle esigenze effettive del cliente.  

Nota

Questo documento può essere aggiornato a causa di un veloce cambiamento delle tendenze relative al software e i dispositivi.

Nota

In caso del sistema Comarch ERP Enterprise bisogna anche prendere in considerazione le necessità riguardanti i prodotti di altri produttori che funzionano sul server e adattarle in modo adeguato.

 

Installazione hardware

Nota

Le informazioni inclusi in questo documento prevedono un sistema basato sui processori Intel® x64  o compatibile.

Nota

Questa documentazione non contiene la specificazione riguardante il dimensionamento del sistema.

Memoria RAM per il server delle applicazioni del sistema ERP

I server delle applicazioni del sistema ERP (SAS) utilizzano la memoria cache che in modo rilevante accelera l’accesso agli oggetti più utilizzati. Alte prestazioni vengono raggiunte soltanto quando SAS possiede abbastanza memoria RAM. Se la memoria RAM non è sufficiente e il sistema operativo è forzato a mantenere una parte della memoria SES sul disco rigido (memoria di massa), le prestazioni possono peggiorare.

RAM per il sistema di gestione dei database

Il sistema di gestione dei database (DBMS) richiede anche una memoria cache sufficiente nella memoria RAM (conforme alle esigenze del motore del database e adattata alle esigenze del cliente). L’accesso al disco rigido è più lento rispetto all’accesso alla memoria RAM. Per questo motivo le prestazioni possono essere peggiore in caso dell’allocazione della memoria cache sul disco rigido (memoria di massa).

Utilizzo di più processori

In caso di utilizzo di più processori sulla piattaforma hardware, la configurazione hardware generale decide sulla velocità di elaborazione dei dati e non soltanto il numero dei thread del processore. Il rallentamento del sistema può risultare, principalmente, da un disco rigido lento nonché da una carta di rete lenta, per es. 10Mb/s.

Nota

Durante la configurazione del hardware bisogna verificare che l’ambiente soddisfaccia tutte le esigenze di Comarch ERP Enterprise.

 

Comarch ERP Enterprise può utilizzare un tempismo veloce del processore e numerosi processi. Con l’utilizzo di più di un SAS sullo stesso computer, il processo aggiuntivo si commuta tra questi SAS, sommando le prestazioni di tanti processi.

I processori non devono essere consolidati sullo stesso server. Comarch ERP Enterprise gestisce l’implementazione di tanti SAS che non devono essere avviati sullo stesso server. Questo permette di utilizzare Blade Centers (server blade), per esempio per SAS.

Comarch ERP Enterprise gestisce sia gli scenari “scaling up” (molti processori e memorie RAM sullo stesso computer) che “scaling out” (distribuzione verso più computer). La prevalenza di uno degli scenari sull’altro dipende dal carico generato e dal numero di utenti. Generalmente il sistema di gestione del database utilizza “scaling up” e i server delle applicazioni del sistema ERP “scaling out”.

Dischi rigidi veloci

Durante la selezione dei sistemi secondari dei dischi rigidi bisogna ricordare che i dischi rigidi SCSI sono generalmente più efficienti rispetto ai dischi rigidi EIDE o SATA. Durante la selezione della piattaforma bisogna prendere in considerazione la possibilità di creare copie speculari (Mirroring) di molti dischi rigidi. Un numero maggiore di dischi rigidi potrebbe distribuire in modo più effettivo il carico di input/output. Bisogna prevedere almeno 6-8 dischi per il sistema.

Nei sistemi ad altre prestazioni i dischi rigidi SCSI e i controller costituiscono la scelta preferita rispetto ai dischi rigidi SATA.

Suggerimento

Bisogna utilizzare i dischi rigidi ad alta velocità di rotazione (15 000 giri/minuto) per i sistemi di produzione. Utilizzo attuale dei dischi SSD potrebbe essere economico se una particolare attenzione viene prestata all’efficienza di input/output.

Requisiti hardware del server del sistema produttivo

In caso di installazione del sistema produttivo, sull’unico server vengono gestite le seguenti funzioni:

  • Sistema di gestione dei database (motore dei database),
  • Server dell’applicazione del sistema ERP (SAS),
  • ERP System Output Manager (SOM: solo per Windows)

I requisiti riguardanti le risorse del software aggiuntivo non sono inclusi in questa documentazione. Bisogna includerli dimensionando il sistema.

Requisiti minimi per il sistema Comarch ERP Enterprise

Nota

Gli alti requisiti riguardanti la sicurezza dei dati, l’accesso contemporaneo di più utenti ed elaborazione dei dati non saranno soddisfatti con questa configurazione. La configurazione seguente corrisponde alla configurazione di un computer portatile ed è adatta soltanto per i test.

  • Processore Intel/AMD DualCore
  • 4 GB della memoria principale
  • Disco rigido con possibilmente grande numero di giri

Requisiti minimi raccomandati per il sistema Comarch ERP Enterprise

Il server di base con l’installazione di alcuni componenti dovrebbe avere la configurazione seguente:

  • Processore attuale: 4 core
  • 32 GB della memoria RAM
  • 6 x disco rigido 15 000 giri/minuto o 250 GB/1200 IOPs
  • Disco backup
  • Alimentazione di emergenza (UPS)

In caso di mancanza del sistema di sviluppo o di un adeguato sistema di test nell’ambiente del cliente bisogna eseguire il test e assicurarsi che gli aggiornamenti del software possano essere importati verso il sistema di produzione in un altro ambiente gemellato.

Le risorse hardware devono essere adattate alle esigenze individuali del cliente.

Installazione distribuita: Comarch ERP Enterprise e DBMS

Comarch ERP Enterprise supporta l’installazione distribuita dei server delle applicazioni (SAS) e del server dei database (DBMS) su server diversi. Bisogna ricordare che la connessione di rete per l’installazione distribuita SAS e DBMS dovrebbe essere garantita al livello 1GB/s. Questo assicurerà la velocità appropriate della trasmissione di dati nella rete tra SAS e DBMS.

Requisiti del disco

Installazione singola:

Sistema di sviluppo (con il codice sorgente e la documentazione di classe Java™)

  • Sistema operativo circa 20 GB (memoria virtuale + codice, correzioni rapide)
  • Database
    • Oracle: circa 5 GB
    • Server MSSQL: circa 3 GB
    • PostgreSQL: circa 1 GB
  • Comarch ERP Enterprise
    • Database: circa 12 GB
    • Codice: circa 2,3 GB
    • Documentazione: circa 650 MB
    • JDK: circa 280 MB
    • SOM (System Output Manager): circa 150 MB + memoria temporanea per la preparazione dei compiti output

Sistema di produzione (senza codice sorgente e documentazione di classe Java™)

Il codice sorgente e la documentazione di classe Java™ non sono forniti all’installazione del sistema di produzione.

  • Sistema operativo circa 20 GB (memoria virtuale + codice, correzioni rapide)
  • Database
    • Oracle: circa 5 GB
    • Server MSSQL: circa 3 GB
    • PostgreSQL: circa 1 GB
  • Comarch ERP Enterprise
    • Database: circa 12 GB
    • SOM (System Output Manager): circa 150 MB + memoria temporanea per la preparazione dei compiti output

Il sistema di installazione richiede il totale di almeno 30 GB dello spazio sul disco rigido.

 

Schema raccomandato dei sistemi per il sistema di produzione

I seguenti sistemi sono raccomandati per l’installazione dal cliente:

  • Sistema di test che serve per eseguire i test degli aggiornamenti del software (obbligatorio) e per i test funzionali
  • Sistema di produzione (obbligatorio)

Il sistema di test dovrebbe trovarsi in un ambiente diverso. Se i server di produzione sono abbastanza grandi e se il sistema di test non deve essere continuamente disponibile, è possibile metterlo nell’ambiente di produzione.

Non tutti i sistemi devono lavorare nello stesso tempo (i sistemi di test non devono essere accesi tutto il tempo). Per questo motivo il fabbisogno iniziale dello spazio per entrambi i sistemi è circa 60 GB.

A seconda del modo di utilizzare, mantenere i backup e condurre il registro delle transazioni, il fabbisogno dello spazio cresce nel corso di utilizzo dell’ambiente.

Stazione di lavoro

Di seguito si trovano i requisiti per la stazione di lavoro nel caso in cui la stazione venga utilizzata soltanto per ottenere l’accesso a Comarch ERP Enterprise.

Requisiti minimi per la stazione di lavoro

  • Processore: almeno 2 core
  • Memoria RAM: almeno 1 GB
  • Scheda di rete 100 Mb/s
  • Schermo a 17 pollici e risoluzione di 1280×1024 pixel e profondità di colore di 16 bit

La memoria va adeguatamente incrementata a seconda delle esigenze del sistema operativo utilizzato e altro software utilizzato.

Configurazione raccomandata per la stazione di lavoro

  • Processore: 4 core o più
  • Memoria RAM: almeno 4 GB
  • Scheda di rete 1 GB/s

In questo caso Comarch ERP Enterprise utilizzerà l’hardware ad alte prestazioni il che si traduce nella velocità del servizio.

La memoria va adeguatamente incrementata a seconda delle esigenze del sistema operativo utilizzato e altro software utilizzato.

Configurazione raccomandata per la stazione di lavoro utilizzata per lo sviluppo e l’estensione del sistema

Il computer utilizzato per lo sviluppo del sistema (programmazione) dovrebbe avere almeno 8 GB della memoria RAM.

Citrix, server dei terminal, terminale fisico

Per le operazioni di produzione è raccomandata la stazione di lavoro. L’utilizzo di Citrix (strumento per la virtualizzazione delle macchine) o di altri cliente viene gestito ma generalmente non è raccomandato. L’accesso diretto del browser a SAS garantisce prestazioni migliori.

I servizi Citrix o i servizi di terminal non sono in grado di gestire in modo ottimo l’interfaccia dell’utente Comarch ERP Enterprise a elevata dinamicità, perché sono stati adattati a trasferire indici bassi di cambiamenti sullo schermo.

Rete

Rete locale (LAN)

L’infrastruttura della rete dovrebbe essere possibilmente veloce e soddisfare i seguenti requisiti.

Configurazione minima raccomandata

La rete raccomandata è 100 MB/s con l’interruttore o più veloce. Se vengono utilizzati più server, essi devono comunicare tramite la rete a un livello di almeno 1 GB/s.

Rete estesa (inglese: Wide Area Network – WAN)

Per ottenere l’accesso a Comarch ERP Enterprise tramite l’Internet bisogna soddisfare le seguenti esigenze.

Raccomandazioni

Connessione di rete (A)DSL o a fibra ottica. Adattamento al traffico generato dagli utenti nella rete.

Nota

In caso di connessioni internet l’utilizzo di VPN potrebbe avere un grande influsso sulla capacità e velocità effettiva disponibile della connessione. Il VPN spesso riduce la capacità della rete a cui è connesso il dispositivo finale.

 

Quando si sceglie la connessione bisogna ricordate che i seguenti punti possono influire sulla velocità effettiva:

  • Tasso di perdita dei pacchetti
  • Capacità
  • Ritardo

In caso di connessione tramite la rete pubblica è valida la regola “best effort”. I pacchi arrivano al dispositivo in modo irregolare i le prestazioni, quando il traffico è elevato, potrebbero non essere sufficienti.

Installazione software

Durante l’installazione del software bisogna prendere in considerazione i seguenti elementi:

  • Sistema operativo
  • Sistema di gestione dei database (DBMS)
  • Java Virtual Machine (JVM)
  • Browser
  • Altri software (opzionalmente)

Nota

Prima di avviare un software aggiuntivo nel sistema di produzione bisogna eseguire il test di funzionamento sul server di test.

 

Java™

Comarch ERP Enterprise funziona su “Java Virtual Machine” fornita da Oracle o IBM con JDK.

Nota

Solo i JDK indicati in seguito vengono gestiti. Versioni JDK posteriori e correzioni rapide vanno testate nel sistema adi test prima di essere utilizzati nel sistema di produzione. Bisogna ricordare che sulla piattaforma IBM è possibile installare soltanto uno stato di patch della versione JDK. Per questo motivo, su questa piattaforma, è raccomandato avviare i sistemi di test su una partizione separata del sistema operativo.

 

Architettura OS Versione OS JDK Stato di conferma
x64

modalità EM64T a 64 bit

AMD64 Modalità a 64 bit

Windows®

Server

2008 R2

SP1

64 bit

6.1 11.0 o più alto a 64 bit
x64

modalità EM64T a 64 bit

AMD64 Modalità a 64 bit

Windows®

Server

2012

6.2 11.0 o più alto a 64 bit
x64

Modalità a 64 bit EM64T Modalità a 64 bit AMD64

Windows

Server

2012 R2

6.3 11.0 o più alto a 64 bit
x64

Modalità a 64 bit EM64T Modalità a 64 bit AMD64

Windows

Server

2016

6.10.0 11.0 o più alto a 64 bit
Power IBM e
x64

modalità EM64T a 64 bit

AMD64 Modalità a 64 bit

Linux®

64 bit

Attuale

Kernel 4.x

11.0 o più alto a 64 bit

 

Nota

La gestione del sistema operativo IBM verrà condivisa insieme alla fornitura successiva della correzione rapida.  

Funzioni del linguaggio Java

La verifica dell’adattamento avviene nella modalità di compatibilità con l’utilizzo della funzione del linguaggio JDK 1.8.

Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files

I file “Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files” sono allegati al JDK utilizzato.




Introduzione nell’installazione

L’installazione e gestione del sistema Comarch ERP Enterprise include un grande numero di componenti. Questo articolo include la descrizione delle tappe da eseguire per installare il sistema. Le descrizioni di aree particolari possono essere trovate nelle documentazioni appropriate.

Struttura dei sistemi

Un’installazione di produzione corretta del sistema CEE dovrebbe essere composta dai sistemi dipendenti uno dall’altro:

  • Sistema di produzione: sistema in cui viene condotto il lavoro corrente dell’impresa
  • Sistema di test: sistema gemello di quello di produzione, serve per eseguire i test delle correzioni rapide ed effettuare modifiche prima di installarle nel sistema di produzione
  • Sistema di sviluppo: sistema primario che serve per l’installazione di nuove correzioni rapide e applicazioni. Il sistema permette di connettere il compilatore e creare modifiche nel sistema.
    In aggiunta, consente di risolvere i conflitti di sviluppo dopo l’installazione delle correzioni rapide e delle modifiche.

Il flusso corretto degli aggiornamenti delle versioni, delle installazioni delle correzioni rapide e delle modifiche è come segue:
Sistema di sviluppo -> Sistema di test -> Sistema di produzione

Nota
I sistemi possiedono il database di configurazione comune. I nomi dei sistemi vengono assegnati con la stessa convenzione dei nomi.

Si può utilizzare il backup di produzione del database nell’ambiente di test. Comunque non è possibile utilizzare nel sistema di produzione un database proveniente dal sistema di test.

Nota
L’installazione di ogni sistema avviene separatamente.

Requisiti di sistema

L’articolo Requisiti di sistema descrive le piattaforme che gestiscono il sistema e i requisiti hardware e software riguardanti l’avvio del sistema CEE.
Bisogna assicurarsi che l’ambiente di installazione soddisfi almeno i requisiti minimi.

Licenza

Per creare un nuovo sistema bisogna avere la licenza per questo sistema. La licenza viene rilasciata separatamente per ogni sistema. La licenza contiene un insieme di informazioni riguardanti moduli, applicazioni e lingue disponibili per un sistema. Il suo contenuto dipende dai moduli acquisiti.
Per ottenerla bisogna creare una notifica adeguata nel sistema di gestione delle notifiche o contattare il commerciante.

Installazione del motore di database

Nell’ambiente è necessario un motore di database adeguato.
Vengono gestiti i seguenti motori (a seconda del sistema operativo):

  • MS SQL Server
  • PostgreSQL
  • Oracle
  • DB2

Altre informazioni riguardanti i motori gestiti possono essere trovate nell’articolo Requisiti di sistema.

Documentazione del sistema Comarch ERP Enterprise

Prima di installare il sistema vale la pena prendere visione della sua documentazione disponibile sul sito: guida.comarch.it/cee.

Nota

Il sito è in corso di creazione ed estensione. Per questo motivo i contenuti vi appaiono in modo graduale.

Installazione del sistema

La descrizione dell’installazione è disponibile in articolo dedicato al sistema e il motore di database selezionati.

 




Lavori dopo l’installazione

Introduzione

La documentazione contiene la descrizione delle attività che vanno eseguite dopo l’installazione del sistema o dopo creazione di un nuovo sistema.

Il documento va considerato come elenco di controllo che serve d’aiuto durante la verifica dell’esecuzione di tutti i lavori necessari. I capitoli particolari rinviano a istruzioni più dettagliate.

Elenco di controllo

Definizione del sistema in Sistema

L’applicazione Sistema serve per configurare il sistema. Vi si trovano le impostazioni riguardanti, tra l’altro, i database, i server delle applicazioni (SAS) e gli utenti.

Verifica del file system.properties

Bisogna verificare il file  semiramis/classes/system.properties  per quanto riguarda i parametri di inizio richiesti.

Nota
Perché il server delle applicazioni possa spedire la posta elettronica deve avere il server di posta da utilizzare indicato. Per indicare tale server bisogna introdurre l’inserzione mail.smtp.host=yourmailserver nel file semiramis/classes/system.properties .

Adattamento dei parametri JVM

Il server dell’applicazione standard MESSAGESERVER viene fornito con le dimensioni predefinite del stack di 300 MB, comunque questi valori potrebbero non essere adeguate alle applicazioni di produzione. Bisogna adattare le dimensioni dello stack di ogni SAS alle esigenze dell’impresa e inserire i parametri JVM adeguati.

Bisogna ricordare che per ogni piattaforma del sistema operativo i parametri sono definiti in modo diverso:

Nota
Dopo l’introduzione delle modifiche il server delle applicazioni deve essere riavviato perché le modifiche diventino valide.

Adattamento del parametro della memoria dello stack

Bisogna adattare il parametro Massima memoria HEAP per ogni SAS. Questo parametro dovrebbe corrispondere alla specificazione impostata per il parametro -Xmx JVM. Non è raccomandata l’inserzione di valori diversi.

Nota
Dopo l’introduzione delle modifiche il server delle applicazioni deve essere riavviato perché le modifiche diventino valide.

Creazione di nuovi certificati

Bisogna creare la propria gerarchia di certificati con il certificato principale, uffici di certificazione, certificati dei server e certificati degli utenti.

Nota
Dopo la creazione dei propri certificati bisogna ordinare i certificati già esistenti, per es. rimuovere quelli che non sono più utilizzati.

Timeout del database

Bisogna verificare i timeout per il database attualmente impostati. Nel sistema di produzione è raccomandato di non impostare il timeout. Questo significa che le connessioni al database stabilite vengono chiuse soltanto dopo l’arresto del lavoro di SAS.

Nota
Dopo l’introduzione delle modifiche il server delle applicazioni deve essere riavviato perché le modifiche diventino valide.

Server delle applicazioni

Per ogni server di applicazione bisogna verificare:

  • indirizzo URL
  • certificato generato da un ufficio richiesto e la sua validità
  • parametri JVM e gli stack
  • accesso ODBC: in caso di server di produzione ODBC per SOM (Standard Output Manager) l’accesso deve essere illimitato.

Nota
La limitazione dell’accesso ODBC causa l’incremento di carico del database.

  • il numero richiesto di connessioni al database

Impostazione della memoria cache del server delle applicazioni

Dopo l’impostazione del server delle applicazioni bisogna impostare la memoria cache per il server delle applicazioni.

Impostazione della memoria cache del server delle applicazioni costituisce il fattore chiave per le prestazioni del server delle applicazioni. Se la dimensione di cache selezionata è troppo piccola, questo porta a un numero troppo grande di query inviate direttamente al database il che influisce in modo negativo sulle prestazioni del sistema.

Bisogna monitorare il carico delle partizioni della memoria cache nell’applicazione Sistema.

In caso di creazione di nuovi database e del loro collegamento a SAS bisogna effettuare le impostazioni cache per questi database.

Thread di dialogo

I thread di dialogo servono per l’elaborazione delle attività e delle richieste chiamate dal livello dell’interfaccia verso il server dell’applicazione.
L’impostazione predefinita del numero dei thread nell’elaborazione di input è sufficiente per la maggioranza degli scenari dell’applicazione. Se il server delle applicazioni utilizzato principalmente dagli utenti interattivi dispone di più di un processore, è possibile incrementare il numero di thread per l’elaborazione di dialogo. Bisogna ricordare che l’impostazione di un numero troppo grande di thread di dialogo su CPU porta all’allungamento dei tempo di risposta del server delle applicazioni.

Database

Per le impostazioni dei database bisogna verificare:

  • i dati delle connessioni OLAP per il database OLTP
  • la correttezza dei dati dell’utente e dello schema
  • il numero richiesto di connessioni al database

Restrizioni dell’importazione

Bisogna verificare le restrizioni specifiche relative all’importazione dei pacchi per il sistema appena definito. Il percorso di trasportazione degli aggiornamenti deve essere strettamente osservato.

Bisogna assicurarsi che nessun aggiornamento del software possa essere importato dai sistemi esterni.

Assegnazione dell’utente al sistema

L’assegnazione dell’utente al sistema è indispensabile perché l’utente esistente nel database di configurazione possa accedere a un sistema indicato.

Lingue

Le lingue fornite con il sistema di installazione sono l’inglese e il tedesco. Per utilizzare altre lingue bisogna possedervi le licenze e installare gli aggiornamenti linguistici per queste lingue.

Configurazione delle lingue ausiliarie aggiuntive OLTP

Se nel database OLTP, dopo la creazione del database, oltre alla lingua principale verranno impostate altre lingue aggiuntive, tutti i campi delle tabelle delle lingue aggiuntive rimarranno vuoti. L’applicazione in background Riorganizza lingue database completa le tabelle delle lingue aggiuntive secondo il valore della lingua predefinita. Alternativamente, è possibile utilizzare il commando dello strumento dello strato rgzbt.

Elaborazione input

Attività standard di input e di riorganizzazione

Le attività di input sono le attività che vengono eseguite o cominciano ad essere eseguite nel momento di avvio del sistema. Nel sistema dovrebbero essere definite le attività di input e di riorganizzazione necessarie per un dato sistema.

In particolare, bisogna attivare la riorganizzazione dei dati che hanno effetto sulla capacità. La riorganizzazione va attivata ad intervalli di tempo regolari. Se no, il volume del database crescerà velocemente. Bisogna anche ricordare che alcune attività devono essere configurate solo una volta per il sistema e alcune separatamente per ogni database OLTP connesso.

Attività input Proprietà Nome tecnico
Sincronizzazione dei dati finanziari

 

•        Non più di una volta per ogni database OLTP

•        Tipo di avvio: a ogni avvio SAS

•        SAS può cominciare qualche

TransferBatches

com.cisag.app.financials.

batch.log.

StartTransferBatches

Trasferimento dei partner verso

Finanze

 

 

•        Non più di una volta per ogni database OLTP

•        Tipo di avvio: a ogni avvio SAS

•        SAS può cominciare qualche

TransferBatches

com.cisag.app.financials.

batch.log.

PartnerTransferBatch

Riorganizzazione delle immissioni di percorso

 

•        Non più di una volta per ogni database OLTP

•        Tipo di avvio: a ogni avvio SAS

•        SAS può cominciare qualche

TransferBatches

com.cisag.sys. preferences.log.

UserHistoryReorganization

 

Riorganizzazione di lavoro Proprietà Nome tecnico
Riorganizzazione delle informazioni sulle prestazioni

 

•        Per ogni database

 

 

 

 

 

com.cisag.sys.tools.profiling.log.Database MonitoringReorganization
Riorganizzazione degli ordini di rilascio com.cisag.sys.print.ou tqueue.log.OutQueueEnt ryReorganization
Riorganizzazione delle immissioni nel registro dei messaggi com.cisag.sys.tools.me ssagelog.log.MessageLo gEntryReorganization
Riorganizzazione del giornale della modifica com.cisag.sys.tools.mo dificationjournal.log. ModificationJournalReorganization
Riorganizzazione delle attività com.cisag.sys.workflow . log.ActivityReorganization
Riorganizzazione delle immissioni del protocollo dello scambio di dati com.cisag.sys.tools.bi . log.ProcessProtocolReorganization

 

Nelle code di elaborazione utilizzate bisogna adattare il numero di thread gestiti. Il numero di thread necessari dipende dalle attività di input che vanno elaborati da una data coda di elaborazione.

Nota
Ogni attività di input specificato nella tabella sopra richiede un thread fisso.

Server di pianificazione

Bisogna avviare almeno un server di pianificazione. Il server di pianificazione viene definito separatamente per ogni database OLTP.  I server di pianificazione vengono avviati e fermati nell’applicazione Pianificazione del fabbisogno di materiale. Per farlo, in questa applicazione viene definita la coda di elaborazione secondo cui va avviata la pianificazione. Su ogni SAS può essere avviata qualche istanza del server di pianificazione. Questo numero è limitato da un numero massimo di thread nella coda di elaborazione e dalla memoria RAM disponibile nell’ambiente.

Server della logistica di magazzino

Bisogna avviare almeno un server della logistica di magazzino. Il server della logistica di magazzino viene definito separatamente per ogni database OLTP.

Nota
Ogni server della logistica di magazzino richiede due thread nella coda di elaborazione.

System Output Manager (SOM)

Bisogna verificare le impostazioni del server di output del sistema. In caso del sistema operativo Windows bisogna installare il programma System Output Manager.

Per verificare la configurazione corretta SOM bisogna controllare:

  • la possibilità di creare gli output, i rapporti e di inviarli tramite la posta elettronica
  • se l’utente Outputserver è assegnato al sistema e appartiene al gruppo di utenti Amministratori
  • se è stato immesso e avviato un collegamento aperto al database (ODBC) al server delle applicazioni adeguato
  • se il server delle applicazioni consente l’accesso a ODBC
  • i thread definiti dedicati alla gestione dei rapporti secondo le definizioni delle priorità delle attività output e della capacità dell’infrastruttura hardware.

Impostazione dei dispositivi output

Bisogna definire i dispositivi output per e-mail, stampane e fax.  L’utente può utilizzare soltanto i dispositivi output definiti nel suo ruolo delle autorizzazioni.

Definizione dei modelli degli output

Bisogna definire ed eseguire i test dei modelli degli output dei documenti utilizzati nel sistema. In caso di esigenze personalizzate dell’utente esiste la possibilità di definire modelli degli output dei documenti aggiuntivi.

Connessione a Knowledge Store

Bisogna verificare la connessione a Knowledge Store (Kstore). Per farlo nel sistema Windows bisogna creare un nuovo disco di rete in Windows Explorer che costituirà la scorciatoia per la cartella on-line.

L’area di lavoro standard Knowledge Store è disponibile all’indirizzo del sistema con l’aggiunta kstore.

Esempio
https://localhost/kstore/

Nota
L’accesso a Knowledge Store è assegnato nell’ambito del ruolo delle autorizzazioni.

Autorizzazioni

Bisogna verificare o creare i ruoli delle autorizzazioni secondo la politica di sicurezza del sistema e la sua destinazione d’uso.

Elenco di controllo della configurazione del sistema

Per verificare che il sistema sia configurato in modo corretto bisogna utilizzare l’elenco di controllo della configurazione del sistema. Molti punti descritti in questo documento anche fanno parte dell’elenco di controllo della configurazione del sistema.

Infrastruttura

Sistema dei file

Bisogna verificare la struttura delle directory in Comarch ERP Enterprise Il sistema di test dovrebbe avere una directory source vuota. In caso di un sistema di produzione l’importazione degli aggiornamenti del software dovrebbe essere limitata ai pacchi provenienti dal sistema di test o dello sviluppo.

Motore dei database

Bisogna controllare il lavoro del motore dei database e osservare le buone partiche nonché reagire agli eventi nel sistema per adattarlo al meglio possibile.

Microsoft SQL Server

Bisogna prestare attenzione ai parametri che possano richiedere l’adattamento dei database a seconda dell’utilizzo dell’installazione. Ecco i più importanti:

  • Configurazione di ottimizzazione
  • L’adattamento delle dimensioni dei file dei dati e dei file del giornale
  • Creazione dei backup
  • Archiviazione dei log del server
  • Archiviazione e riduzione del log di transazione. Nella pianificazione di creazione delle copie backup bisogna prevedere il salvataggio dei log delle transazioni e poi il loro svuotamento per garantire l’utilizzo efficace dello spazio disponibile sul disco rigido.
  • Incremento delle dimensioni del database TempDB a circa 4 GB. Nel caso lo spazio sul disco rigido sia limitato bisogna assicurarsi che il database non continuerà a crescere in modo dinamico.
  • Il monitoraggio delle prestazioni con l’utilizzo degli strumenti integrati nel motore SQL per riconoscere presto il peggioramento delle prestazioni e intraprendere delle azioni adeguate.
  • Il livello di isolamento del database dovrebbe essere impostato su READ_COMMITTED_SNAPSHOT.
  • Creazione delle attività settimanali per le riorganizzazioni/ricomposizioni degli indici.

Oracle

Dopo l’importazione del database Comarch ERP Enterprise bisogna utilizzare il commando Oracle Analyze tables per aggiornare le statistiche per l’ottimizzatore. Poi bisogna farlo ad intervalli di tempo regolari. Le statistiche dell’ottimizzatore sono indispensabili per mantenere un’alta efficienza di lavoro del motore Oracle.  Bisogna verificare le seguenti attività:

  • Adattamento dei parametri di inizializzazione
  • Impostazione della modalità di archiviazione
  • Separazione dei file dei log del motore da playload (dati dell’utente)
  • Monitoraggio dell’incremento della memoria nel sistema e creazione di nuovi file di dati per gli spazi di tabelle utilizzati.
  • Lo spazio di tabelle TEMP dovrebbe trovarsi in una partizione con uno spazio libero sufficiente. Tale spazio potrebbe crescere fino a 32 GB a meno che le sue dimensioni non siano limitate. Se possibile, gli spazi di tabelle TEMP e UNDO dovrebbero trovarsi nelle loro proprie partizioni.
  • Il monitoraggio delle prestazioni con l’utilizzo degli strumenti integrati nel motore SQL per riconoscere presto il peggioramento delle prestazioni e intraprendere delle azioni adeguate.
  • Incremento del numero di giornali Redo, se necessario

i5/OS

Per il motore SQL nel sistema i5/OS bisogna garantire:

  • Il sistema secondario proprio e un pool cache per ogni SAS
  • Il monitoraggio delle prestazioni con l’utilizzo degli strumenti integrati nel motore SQL per riconoscere presto il peggioramento delle prestazioni e intraprendere delle azioni adeguate.
  • Utilizzo della versione più recente del driver JDBC
  • Utilizzo della versione più recente di PTF

Copia backup

Bisogna configurare il meccanismo della creazione regolare delle copie backup dei database e del sistema dei file.

I database e il sistema dei file devono avere uno stato coerente e rispecchiarsi reciprocamente, perciò è importante che le copie backup provengano dallo stesso periodo di tempo.

La perdita di uno dei sistemi nel percorso di trasportazione degli aggiornamenti è una grave difficolta e causa la necessità di un grande carico di lavoro per creare un nuovo percorso di trasportazione. Per questo motivo anche questi sistemi devono essere integrati in una procedura di backup efficiente.

Server del tempo

Tutti i server delle applicazioni avviati in un ambito di produzione dovrebbero funzionare in modo sincronico. Questo è reso più difficile dal fatto che da più tempo le macchine lavorano, più sono diverse tra di loro. Per questo motivo bisogna configurare il server centrale di tempo che sincronizzerà tutti i computer nella rete ad intervalli di tempo regolari.

Configurazione della rete

Bisogna controllare che tutti i sistemi utilizzati siano connessi uno con l’altro con la velocità possibilmente più alta. Per minimizzare gli effetti di un numero elevato di computer nella rete è possibile dividere la rete in reti secondare e dedicarne una ai server per il sistema Comarch ERP Enterprise.

In caso di utilizzo di VPN bisogna stabilire le Regole riguardanti la qualità dei servizi coerenti per tutte le stazioni satellitari connesse tramite VPN perché il traffico https in entrambe le direzioni verso SAS sia considerato in modo prioritario rispetto, per esempio, alla posta elettronica.

Elenco di controllo della stazione del cliente

Configurazione del browser

Per garantire il funzionamento corretto del sistema nel browser bisogna:

  • Installare il certificato dell’utente
  • Eseguire il test di accesso al sistema
  • Verificare le opzioni di accesso all’internet
  • Verificare le impostazioni proxy
  • Aggiungere l’indirizzo del sistema ai siti attendibili

Configurazione dei programmi antivirus

I programmi antivirus sono necessari per proteggere i server e i clienti dal malware e dai virus. Durante l’installazione e il lavoro di produzione bisogna prendere in considerazione l’effetto negativo degli scanner antivirus sulle prestazioni.

  • A seconda della configurazione, gli scanner antivirus possono scannare ogni immagine e ogni sito web scaricato dal server delle applicazioni. Questo potrebbe avere un effetto negativo sulle prestazioni dal Cliente.
  • La scansione di ogni pacchetto di rete in arrivo e in uscita sul server avrà un effetto negativo sulle prestazioni. Vale la pena controllare l’intero sistema periodicamente per verificare la presenza dei virus. Occorre evitare l’utilizzo continuo dello scanner antivirus nel server o, eventualmente, escludere il catalogo del sistema Comarch ERP Enterprise dal monitoraggio continuo, adottando eccezioni adeguate.

Configurazione del firewall

In caso di utilizzo del firewall bisogna acconsentire l’accesso al sistema Comarch ERP Enterprise definendo una regola che renderà sempre possibile l’accesso con l’utilizzo del protocollo https.

Configurazione delle connessioni a Knowledge Store

Nell’esploratore dei file è possibile configurare l’accesso ai dischi WebDAV Knowledge Store come dischi di rete.

Di solito, l’accesso avviene tramite l’indirizzo seguente:

https://[indirizzo_sistem]/kstore

Installazione del driver ODBC

Per rendere possibile l’accesso ai database tramite ODBC dal livello del software di altre aziende bisogna installare il driver ODBC. Gli esempi di software che utilizzano ODBC sono: Crystal Reports, Microsoft Excel e Cofnos PowerPlay.

 




Convenzione dei nomi

Comarch ERP Enterprise gestisce i sistemi di gestione dei database che pongono dei limiti sul formato dei nomi dei database, degli utenti, degli intervalli di dati e di molti altri oggetti. Inoltre un partner o un cliente può avviare allo stesso tempo più sistemi o database, diverse versioni di Comarch ERP Enterprise. Questi fattori generano la necessità di impostare la convenzione per i nomi dei sistemi e dei database. Le convenzioni dipendono dagli elementi seguenti:

  • utilizzo del sistema
  • versione del sistema
  • sistema di gestione del database (DBMS)
  • contenuto del database

Convenzione dei nomi dei sistemi

Il nome di un nuovo sistema è definito nella licenza del sistema e non può essere cambiato. Il database di configurazione è responsabile per il controllo della convenzione dei nomi degli oggetti di sistema. I nomi di sistema nella configurazione del sistema hanno di solito da sei a otto caratteri:

Caratteri 1-3: Codice Cliente

Caratteri 4-6, opzionali: Versione, rilascio

Caratteri 7-8: codice opzionale per la funzione del sistema:

  • DV: sistema di sviluppo, cioè il sistema che consente di introdurre delle modifiche e di verificarle
  • PV: sistema di sviluppo per i Partner, cioè il sistema del Partner che consente di introdurre delle modifiche e di verificarle
  • DT: sistema di sviluppo di test, cioè il sistema di test utilizzato per l’esecuzione dei test delle modifiche introdotte
  • PT: sistema di test per i Partner, cioè il sistema di test del Partner utilizzato per l’esecuzione dei test delle modifiche introdotte
  • T: sistema di test di produzione, cioè il sistema di test utilizzato per eseguire i test prima di produzione, eseguiti dal Cliente
  • P (o nessun codice): sistema di produzione, cioè il sistema utilizzato per il lavoro dal Cliente.

Caratteri 9-10: Codice opzionale che indica il motore del database:

  • OR: Oracle
  • D4: DB2/400
  • MS: Microsoft SQL Server

Inoltre esistono le seguenti convenzioni riguardanti i sistemi di test e i database temporanei. Tali sistemi e tali database vengono creati per gli scopi relativi all’esecuzione di brevi test i di solito non sono collegati in nessun modo al sistema di produzione del Cliente.

  • Txx: sistema temporaneo, xx è il numero successivo del sistema(00-99)
  • DB xx: database del sistema temporaneo, xx è il numero successivo del database(00-99)

Esempi:

Nome sistema Descrizione sistema
PAR610DV Sistema di sviluppo per la versione 6.1 per un Cliente con il codice PAR
WUG600PTOR Sistema di test per i Partner nella versione 6.0 per un Cliente con il codice WUG. Motore del database Oracle
T01 Sistema temporaneo 01
CUS610P Sistema di produzione nella versione 6.1 per un Cliente con il codice CUS
CUS610
CUS610T Sistema di test nella versione 6.1 per un Cliente con il codice CUS
CUS610DV Sistema di sviluppo nella versione 6.1 per un Cliente con il codice CUS

Convenzione dei nomi dei database

I nomi dei database hanno di solito 10 caratteri, 12 al massimo. Sono composti dai seguenti elementi:

  • nome del sistema
  • simbolo a due caratteri che specifica il tipo di contenuto del database

Nota
I nomi delle collezioni in IMB DB2 UDB per iSeries non possono avere più di 10 caratteri.

Simboli aggiunti al nome del sistema:

  • xx – xx come numeri successivi (00-99): database OLTP (database che mantiene i dati dell’azienda, per es. articoli, documenti)
  • Dx – x come numeri successivi (0-9) (se uno dei database è DW): database OLAP (database che mantiene i dati dei report)
  • RP: database del repositorio (database che mantiene gli oggetti standard del sistema, per es. traduzioni)
  • CF: database di configurazione (database che mantiene la configurazione del sistema, per es. i dati di connessione per gli altri database)

Nota
Il database di configurazione è comune per i sistemi con destinazioni d’uso diverse, perciò il suo nome non dovrebbe contenere il codice che specifichi la funzione del sistema.

Nome del database Descrizione del database
CUS610CF Database di configurazione dei sistemi con il nome CUS610
CUS61001 Database OLTP 01 per il sistema di produzione
CUS610T03 Database OLTP 03 per il sistema di test
CUS610DV02 Database OLTP 02 per il sistema di sviluppo
CUS610D1 Database OLAP 1 per il sistema di produzione
CUS610RP Database del repositorio per il sistema di produzione
CUS610TRP Database del repositorio per il sistema di test

Convenzioni riguardanti la costruzione della struttura delle directory per il sistema Comarch ERP Enterprise

Windows

Durante l’installazione del sistema Comarch ERP Enterprise nel sistema Windows bisogna utilizzare la seguente struttura delle directory del sistema:

<lettera_disco>:\\comarch\<nome_sisema>\semiramis

\servers

\<nome_SAS>

\log

  • Bisogna sostituire <nome_sistema> con il nome del sistema, per es. CUS610T
  • Ogni server delle applicazioni (SAS) possiede la propria directory nella directory servers. Bisogna sostituire <nome_SAS> con il nome effettivo di ogni SAS, per es. MESSAGESERVER

La directory \comarch\<nome_sistema> è chiamata SYSTEM_HOME.

La directory \comarch\<nome_sistema>\semiramis è chiamata SEMIRAMIS_HOME.

La directory \comarch\<nome_sistema>\semiramis\servers\<nome_SAS> è chiamata directory SAS_HOME per server particolari dell’applicazione. Questa è una directory di lavoro del server dell’applicazione. La directory contiene gli script di avvio necessari e potrebbe contenere il file server.properties nella directory secondaria class.

La directory log mantiene i file log SAS, file di log di monitoraggio delle prestazioni ecc.

Linux

Durante l’installazione del sistema Comarch ERP Enterprise nel sistema Linux bisogna utilizzare la seguente struttura delle directory del sistema:

/opt/comarch/<nome_sistema>/semiramis

/servers

/<nome_SAS>

/log

  • Bisogna sostituire <nome_sistema> con il nome del sistema, per es. CUS610T
  • Ogni server delle applicazioni (SAS) possiede la propria directory nella directory servers. Bisogna sostituire <nome_SAS> con il nome effettivo di ogni SAS, per es. MESSAGESERVER

La directory /opt/comarch/<nome_sistema> è chiamata SYSTEM_HOME.

La directory \comarch\<nome_sistema>\semiramis è chiamata SEMIRAMIS_HOME.

La directory \comarch\<nome_sistema>\semiramis\servers\<nome_SAS> è chiamata directory SAS_HOME per server particolari dell’applicazione. Questa è una directory di lavoro del server dell’applicazione. La directory contiene gli script di avvio necessari e potrebbe contenere il file server.properties nella directory secondaria class.

La directory log mantiene i file log SAS, file di log di monitoraggio delle prestazioni ecc.

i5

Durante l’installazione del sistema Comarch ERP Enterprise nel sistema i5 bisogna utilizzare la seguente struttura delle directory del sistema:

/qopensys/usr/comarch/<nome_sistema>/semiramis

/servers

/<nome_SAS>

/log

  • Bisogna sostituire <nome_sistema> con il nome del sistema, per es. CUS610T
  • Ogni server delle applicazioni (SAS) possiede la propria directory nella directory servers. Bisogna sostituire <nome_SAS> con il nome effettivo di ogni SAS, per es. MESSAGESERVER

La directory  /qopensys/usr/comarch/<nome_sistema> è chiamata SYSTEM_HOME.

La directory /qopensys/usr/comarch/<nome_sistema >/semiramis è chiamata SEMIRAMIS_HOME.

La directory /qopensys/usr/comarch/<nome_sistema>/semiramis/servers/<nome_SAS> è chiamata directory SAS_HOME per server particolari dell’applicazione. Questa è una directory di lavoro del server dell’applicazione. La directory contiene gli script di avvio necessari e potrebbe contenere il file server.properties nella directory secondaria class.

La directory log mantiene i file log SAS, file di log di monitoraggio delle prestazioni ecc.