procedura aperta per la gestione, manutenzione, e supporto al change management del ... ·...

UNIONE EUROPEAUNIONE EUROPEAUNIONE EUROPEAUNIONE EUROPEA

REPUBBLICA ITALIANAREPUBBLICA ITALIANAREPUBBLICA ITALIANAREPUBBLICA ITALIANA

Direzione Generale degli Affari Generali e Riforma della Regione Servizio per il sistema informativo di base dell’amministrazione di base (SIBAR) e il superamento del digital divide

DESCRIZIONE TECNICA DEL SISTEMA SIBARDESCRIZIONE TECNICA DEL SISTEMA SIBARDESCRIZIONE TECNICA DEL SISTEMA SIBARDESCRIZIONE TECNICA DEL SISTEMA SIBAR----SIBEARSIBEARSIBEARSIBEAR APPROVATO CON DETERMINAZIONEAPPROVATO CON DETERMINAZIONEAPPROVATO CON DETERMINAZIONEAPPROVATO CON DETERMINAZIONE N. N. N. N. 333333334444////AA.GG. DEL AA.GG. DEL AA.GG. DEL AA.GG. DEL 11115555/05//05//05//05/2222000000009999

PROCEDURA APERTA PER LA GESTIONE, MANUTENZIONE, E SUPPORTO AL CHANGE

MANAGEMENT DEL SISTEMA DI BASE DELL’AMMINISTRAZIONE REGIONALE “SIBAR” E

DEL SISTEMA DEGLI ENTI E DELLE AGENZIE “SIBEAR”

Assessorato degli affari generali, personAssessorato degli affari generali, personAssessorato degli affari generali, personAssessorato degli affari generali, personale e riforma della Regione Direzione generale ale e riforma della Regione Direzione generale ale e riforma della Regione Direzione generale ale e riforma della Regione Direzione generale degli Affari Generali e Riforma della Regione degli Affari Generali e Riforma della Regione degli Affari Generali e Riforma della Regione degli Affari Generali e Riforma della Regione ---- Servizio per il sistema informativo di Servizio per il sistema informativo di Servizio per il sistema informativo di Servizio per il sistema informativo di base dell’amministrazione di base (SIBAR) e il superamento del base dell’amministrazione di base (SIBAR) e il superamento del base dell’amministrazione di base (SIBAR) e il superamento del base dell’amministrazione di base (SIBAR) e il superamento del digital dividedigital dividedigital dividedigital divide

S I BAR - S I B EA R

ALLEGATO AL DISCIPLINARE TECNICO: DESCRIZIONE TECNICA DEL SISTEMA SIBAR-SIBEAR

PAGINA 2 DI 61

Indice

1 Premessa........................................................................................................................................ 4 2 Descrizione del sottosistema SIBAR .............................................................................................. 5 3 Architettura applicativa ................................................................................................................... 6

3.1 Portale (Netweaver ’04 SR1 – Enterprise Portal).................................................................... 8 3.2 ERP/HR (mySAP ERP 2004 – componenti stack ABAP) ...................................................... 9 3.3 ERP/HR (mySAP ERP 2004 – componenti stack JAVA)....................................................... 9 3.4 Sistema di Reporting (Netweaver ’04 SR1 – BW 3.5)........................................................... 10 3.5 Solution Manager e Solution Manager Diagnostics (Netweaver ’04s – SM 4.0) ................ 11 3.6 Content Management System (EMC Documentum v.5.3) .................................................... 12 3.7 Sistema di OCR (Kofax Ascent Capture Vers. 7).................................................................. 13 3.8 Sistema per la Rilevazione delle presenze (Selewin) ........................................................... 13 3.9 RDBMS (Oracle 10 g)............................................................................................................ 14 3.10 Access Manager (Sun Java System Access Manager) .................................................... 14 3.11 Proxy Server...................................................................................................................... 14

4 Architettura esecutiva ................................................................................................................... 15 4.1 Piattaforma Infrastrutturale.................................................................................................... 15

4.1.1 Infrastruttura hardware .................................................................................................. 15 4.1.2 Infrastruttura di rete ....................................................................................................... 17 4.1.3 Infrastruttura SAN.......................................................................................................... 22

4.2 Architettura di sicurezza ........................................................................................................ 23 4.2.1 Sicurezza infrastrutturale............................................................................................... 23 4.2.2 Accesso ed autenticazione............................................................................................ 23 4.2.3 Autorizzazione e profilazione degli utenti ...................................................................... 25

4.3 Architettura di integrazione.................................................................................................... 28 5 Architettura di sviluppo ................................................................................................................. 29

5.1 Ambienti di sviluppo Portal & Content Management (SB)..................................................... 29 5.2 Landscape progettuale.......................................................................................................... 30

5.2.1 Livelli del landscape ...................................................................................................... 30 5.2.2 Configurazione ambienti................................................................................................ 32

5.3 Strumenti di sviluppo ............................................................................................................. 35 5.3.1 Sistema ERP/HR (mySAP ERP 2004 – ECC 5.0) ........................................................ 35 5.3.2 Sistema Reporting (Netweaver ’04 SR1 – BW 3.5) ...................................................... 36 5.3.3 Portale (Netweaver ’04 SR1 – Enterprise Portal).......................................................... 36

5.4 Software logistics................................................................................................................... 38 5.4.1 Sistema ERP/HR (mySAP ERP 2004 – ECC 5.0) ........................................................ 38 5.4.2 Sistema Reporting (Netweaver ’04 SR1 – BW 3.5) ...................................................... 39 5.4.3 Portale (Netweaver ’04 SR1 – Enterprise Portal).......................................................... 39

6 Architettura operativa.................................................................................................................... 40 6.1 Gestione sito fisico ................................................................................................................ 40 6.2 Gestione sicurezza ................................................................................................................ 40 6.3 Gestione sistemistica............................................................................................................. 40

6.3.1 Sistemi di base (HW, SO, DB) ...................................................................................... 40 6.4 Gestione disponibilità ambienti.............................................................................................. 42

6.4.1 Infrastruttura backup...................................................................................................... 42 6.4.2 Failover e HA................................................................................................................. 43

7 Descrizione del sotto-sistema SIBEAR ........................................................................................ 44 8 Architettura applicativa ................................................................................................................. 45

8.1 ERP (mySAP ERP 2004 – componenti stack ABAP) ......................................................... 46 8.2 Sistema Reporting (Netweaver ’04S – BW 7.0) .................................................................... 47 8.3 Solution Manager e Solution Manager Diagnostics (Netweaver ’04s – SM 4.0) ................ 48 8.4 DOCEBO ............................................................................................................................... 48

9 Architettura esecutiva ................................................................................................................... 49 9.1 Piattaforma infrastrutturale .................................................................................................... 49

9.1.1 Infrastruttura Hardware.................................................................................................. 49 9.1.2 Infrastruttura di rete ....................................................................................................... 49 9.1.3 Accesso in VPN............................................................................................................. 51 9.1.4 Infrastruttura SAN e backup .......................................................................................... 51

9.2 Architettura di sicurezza ........................................................................................................ 52




PAGINA 3 DI 61

9.2.1 Sicurezza Infrastrutturale............................................................................................... 52 9.2.2 Accesso ed Autenticazione ........................................................................................... 52

10 Architettura di sviluppo .............................................................................................................. 53 10.1 Landscape progettuale ...................................................................................................... 53

10.1.1 Configurazione degli ambienti ................................................................................... 54 10.2 Strumenti di sviluppo ......................................................................................................... 57

10.2.1 Sistema ERP/HR (mySAP ERP 2004 – ECC 5.0) .................................................... 57 10.2.2 Sistema Reporting (Netweaver ’04 SR1 – BW 3.5) .................................................. 57

10.3 Software logistics............................................................................................................... 58 10.3.1 Sistema ERP (mySAP ERP 2004 – ECC 5.0) .......................................................... 58 10.3.2 Sistema Reporting (Netweaver ’04 SR1 – BW 3.5) .................................................. 59

11 Architettura operativa ................................................................................................................ 60 11.1 Gestione sito fisico ............................................................................................................ 60 11.2 Gestione sicurezza ............................................................................................................ 60 11.3 Gestione sistemistica......................................................................................................... 60 11.4 Gestione disponibilità ambienti.......................................................................................... 60

11.4.1 Infrastruttura backup.................................................................................................. 60 11.4.2 Failover e HA............................................................................................................. 60




PAGINA 4 DI 61

1111 PremessaPremessaPremessaPremessa

Il presente documento ha l’obiettivo di fornire in modo dettagliato le specifiche tecniche dei sistemi cui

si riferiscono i servizi di manutenzione, gestione e servizi specialistici del sistema informativo di base

dell’amministrazione regionale (SIBAR) e del sistema informativo di base degli enti ed agenzie

regionali (SIBEAR) richiesti dal bando.

Nel seguito i due sistemi informativi saranno presentati considerando che condividono la stessa

piattaforma tecnologica e applicativa e che il secondo è stato realizzato riusando componenti

applicative e infrastrutturali del primo.

La Regione Sardegna considera tali sistemi informativi connessi in un unico sistema informatico del

quale ciascuno dei due può essere considerato un singolo sottosistema. In considerazione della

realizzazione avvenuta in tempi diversi, la descrizione tecnica del secondo (SIBEAR) sarà, espressa

per differenza rispetto al primo (SIBAR) con riferimento agli aspetti tecnologici ed architetturali. Per

ciascun sottosistema sarà dettagliata l’Architettura applicativa, intesa come descrizione delle diverse

piattaforme tecnologiche adottate,l’architettura esecutiva,vista come descrizione degli apparati

dell’infrastruttura, in ottica di integrazione dei sistemi e con l’indicazione dei criteri di sicurezza. La

descrizione tecnica è infine corredata delle specifiche relative all’architettura di sviluppo, cioè la

descrizione delle piattaforme e degli ambienti adottati per lo sviluppo e la personalizzazione delle

applicazioni nonché di quella operativa .

L'infrastruttura tecnologica del sistema SIBAR-SIBEAR include le seguenti componenti:

• una server farm, allocata presso i locali del ex CED in via Posada, che garantisce sia i servizi

applicativi che quelli sistemistici (storage, backup, security, balancing, ecc)

• una infrastruttura di comunicazione che interconnette i locali dell’ex Ced alle varie sedi

dell’amministrazione regionale, presso le quali sono dislocate reti locali;

• un’infrastruttura di comunicazione denominata RTR, Rete Telematica Regionale, che

interconnette le sedi periferiche dei vari uffici regionali nel territorio;

tali componenti sono inseriti in un’architettura distribuita multilivello che prevede server per

l’erogazione di servizi applicativi e client che accedono agli stessi mediante la rete. Il sistema è

completato da apparati per la scansione dei documenti e loro compressione e da una rete di terminali

rilevazione presenze e relativi concentratori.

Tale architettura si caratterizza per

• la presenza di sistemi completamente ridondati per garantire l’alta affidabilità;

• un sistema di autenticazione per accesso unificato a tutti i sistemi;

• un sistema di datawarehouse unico per consolidare i dati contabili degli Enti e della RAS;




PAGINA 5 DI 61

2222 Descrizione del sottosistema SIBARDescrizione del sottosistema SIBARDescrizione del sottosistema SIBARDescrizione del sottosistema SIBAR

Nel seguito è presentata l’architettura tecnica del sottosistema SIBAR. L’architettura è illustrata da

quattro punti di vista:

• Architettura applicativa: descrizione delle diverse piattaforme utilizzate;

• Architettura esecutiva: descrizione degli apparati dell’infrastruttura, in ottica di integrazione

dei sistemi e con l’indicazione dei criteri di sicurezza;

• Architettura di sviluppo: descrizione delle piattaforme e degli ambienti adottati per lo

sviluppo e la personalizzazione delle applicazioni;

• Architettura operativa: descrizione delle modalità e degli strumenti per la gestione

dell’infrastruttura SIBAR.




PAGINA 6 DI 61

Servizi SIBAR su Internet

Pratiche Online Portale Imprese Servizi Enti Locali Modulistica

Sistemi Regione Sardegna

Portale Regione

Sardegna

Back Office Regionale

Gestione Documentale

Workflow Procedimenti

SIBAR - SB

Firma Digitale

Protocollo Informatico

Business Process Management

SIBAR - SCI

Contabilità Economico Patrimoniale

Contabilità Economico Analitica

Gestione Cespiti Contabilità Finanziaria

Gestione Approvvigionamenti

Controllo di Gestione

SIBAR - HR

Banca Dati del Personale Fascicolo Elettronico Organizzazione Gestione Formazione

Gestione della valutazione Sistema Premiante

Gestione carichi di lavoro Rilevazione Presenze

Gestione concorsi e selezioni Gestione FITQ

Stipendi, ricalcoli e gestione fiscale Buoni pasto

Missioni Portale del Personale Gestione Timbrature Relazioni sindacali

Decision Support System integrato SIBAR

Reportistica Data Warehouse Simulazione

Servizi per Cittadini, Imprese ed Enti Locali

Sistemi Esterni

Banca d’Italia (SIOPE)

Ministero del Tesoro

Poste Italiane

Tesoreria Regionale

Enti Pubblici Regionali

Ministero Economia e Finanze

Tesoreria centrale dello Stato

Interfacciamento

Integrazione

3333 Architettura applicativaArchitettura applicativaArchitettura applicativaArchitettura applicativa

Il sottosistema SIBAR è strutturato in differenti aree applicative (Figura 1)

Per ciascuna area il sottosistema SIBAR adotta una opportuna combinazione di piattaforme (Figura

2). In particolare, sono utilizzate le seguenti piattaforme:

• SAP NetWeaver ’04 - Enterprise Portal: portale unico d’accesso ai servizi applicativi che

aggrega i contenuti in funzione dei ruoli utente;

• SAP mySAP ERP 2004: realizza le funzionalità di HR, contabilità, gestione

approvvigionamenti;

• SAP NetWeaver ’04 - BW 3.5: realizza le funzionalità di data warehouse, reporting e

simulazione;

• EMC Documentum Ver. 5.3 SP2: piattaforma di Enterprise Content Management per la

gestione e la catalogazione dei contenuti. Rende disponibili una serie di funzionalità avanzate

per la ricerca dei documenti, il controllo delle versioni, la gestione del workflow. Le estensioni

Web della piattaforma ne consentono l’uso anche mediante browser;

Figura 1: Architettura funzionale del sottosistema SIBAR




PAGINA 7 DI 61

• Italdata Prot@Flow vers. 2: piattaforma per la gestione del protocollo informatico

completamente integrata con Documentum;

• Oracle Enterprise Edition 10g: RDBMS;

• Sun Java System Access Manager: sistema di Access Management per le funzionalità di

Single Sign On, Autenticazione, Autorizzazione;

• Kofax Ascent Capture Vers. 7: sistema per la scannerizzazione dei documenti protocollati,

completo di funzionalità OCR;

• Apache Tomcat: application server Java Enterprise Edition per le componenti web del

SIBAR;

• Selewin: sistema per rilevazione presenze.

A supporto delle soluzioni SAP sono stati adottati inoltre i seguenti software:

• Sap Solution Manager: adottato in landscape SAP Netweaver con la finalità di supportare le

applicazioni basate su Stack ABAP. Il Solution manager è adottato per il monitoraggio dei

sistemi SAP sia internamente cha da SAP AG tramite il sistema Early Watch Alert

• Sap Solution Manager Diagnostics: Strumento per la diagnostica e per il monitoraggio

SMD;

• System Landscape Directory: repository delle informazioni relative al landscape SAP, in

termini di sistemi installati, delle release e del livello di patch dei singoli elementi software, de

delle comunicazioni tra i sistemi;

• Sap Router: proxy software per la connessione di SAP OSS (supporto remoto) ai sistemi SAP

del cliente.

Figura 2: Piattaforme utilizzate per ciascuna area funzionale




PAGINA 8 DI 61

L’architettura applicativa generale è mostrata in Figura 3. Nei paragrafi seguenti verrà descritto il

dettaglio delle componenti software per ogni elemento della piattaforma applicativa.

3.13.13.13.1 Portale (Netweaver ’04 SR1 Portale (Netweaver ’04 SR1 Portale (Netweaver ’04 SR1 Portale (Netweaver ’04 SR1 –––– Enterprise Portal) Enterprise Portal) Enterprise Portal) Enterprise Portal)

La soluzione Enterprise Portal è realizzata attraverso le seguenti componenti:

• Oracle 9.2.0.7: database;

• WAS 6.40 (Java Stack): piattaforma applicativa Java di SAP Netweaver. Fornisce

l’infrastruttura per lo sviluppo, il rilascio e l’esecuzione di le applicazioni Netweaver in

tecnologia Java, J2EE e Web Services;

• Portal Platform 6.0_640: applicazione che offre un singolo punto di accesso, attraverso il

browser, alle funzionalità offerte dagli applicativi SAP; da installare sul WAS 6.40 Java Stack;

• Business Package ESS 60.2: estensione di Portal Platform per la gestione delle informazioni

personali dell’utente;

• Business Package MSS 60.1 (mySAP ERP 2004 – Web Dynpro): estensione di Portal

Platform che fornisce ai dirigenti funzionalità di supporto decisionale per la gestione dello staff

e del budget.

Il livello di patching per l’ambiente è NETWEAVER 04 - SP Stack 15. In Figura 4 è mostrato il dettaglio

delle componenti software.

Web Browser

Presentation

SAPgui

Apache Web Proxy

Web Access Control

SJS Access Manager

SAP Enterprise Portal

Front End

Apache

SAP ERP/HR

Back End

Documentum Context Server

Oracle RDBMS

Data Layer

Tomcat

Protoflow

Acis Kofax

CONGEXP

SAP BW

SAP Connector

Applicazioni Monitoring e Infrastrutturali

Sun Management Center

Enterprise Storage Manager

N1 Storage Manager SAP SLD

SAP Solution Manager SAP router

Figura 3: Architettura applicativa del sottosistema SIBAR

Figura 4: Dettaglio delle componenti software (Portale)

Portale (SAP NetWeaver ’04 SR1 – BW 3.5)

Database

Oracle 9.2i 9.2.0.7 SAP NW – Enterprise Portal

SAP J2EE ENGINE 6.40 SP015 PORTAL PLATFORM 6.0_640 SP015 Portal Content

BP ESS (ERP 2004) 60.2 SP000 BP MSS (ERP 2004) 60.1 SP002




PAGINA 9 DI 61

3.23.23.23.2 ERP/HR (mySAP ERP 2004 ERP/HR (mySAP ERP 2004 ERP/HR (mySAP ERP 2004 ERP/HR (mySAP ERP 2004 –––– componenti stack componenti stack componenti stack componenti stack ABAP) ABAP) ABAP) ABAP)

La soluzione ERP è composta dai seguenti elementi:


• WAS 6.40 (ABAP Stack): piattaforma applicativa ABAP di SAP Netweaver. Fornisce


tecnologia ABAP;

• SAP ECC 5.0: componente core di mySAP ERP 2004;

Il livello di patching per l’ambiente è NETWEAVER 04 - SP Stack 15. In Figura 5 è mostrato il dettaglio

delle componenti software.

Figura 5: Dettaglio delle componenti software (ERP/HR, stack ABAP)

3.33.33.33.3 ERP/HR (mySAP ERP 2004 ERP/HR (mySAP ERP 2004 ERP/HR (mySAP ERP 2004 ERP/HR (mySAP ERP 2004 –––– componenti stack JAVA) componenti stack JAVA) componenti stack JAVA) componenti stack JAVA)

Il componente XSS è necessario quando si utilizzano i Business Packages del portale ESS o MSS

che adottano la tecnologia Web Dynpro: XSS si basa sullo stack Java di NetWeaver 2004 ed è

utilizzato per la connessione alle funzionalità ESS ed MSS di back-end presenti su ECC. La soluzione

XSS è composta da:


• WAS 6.40 (Java Stack): piattaforma applicativa Java di SAP Netweaver. Fornisce


tecnologia Java, J2EE e Web Services;

• Employee Self-Service ESS 100: componente necessario per interfacciare il “Business

Package ESS 60.2” al prodotto mySAP ERP 2004;

• Manager Self-Service MSS 100: componente necessario per interfacciare il “Business

Package MSS 60.1” al prodotto mySAP ERP 2004;

• PCUI_GP 100: componente che contiene generiche funzionalità WebDynPro.

Sistema ERP/HR(mySAP ERP 04 – ECC 5.0)

Database

Oracle 9.2i 9.2.0.7 Kernel

SAP KERNEL 6.40 64bit SP101 SAP ECC Server

SAP ABA 6.40 SAPKA64015 SAP APPL 5.00 SAPKH50011 SAP BASIS 6.40 SAPKB64015 SAP BW 3.50 SAPKW35015 SAP HR 5.00 SAPKE50015 EA-APPL 500 SAPKGPAC11 EA-DFPS 500 SAPKGPDC11 EA-FINSERV 500 SAPKGPFC11 EA-GLTRADE 500 SAPKGPGC11 EA-HR 500 SAPKGPHC15 EA-IPPE 300 SAPKGPIC09 EA-PS 500 SAPKGPPC11 EA-RETAIL 500 SAPKGPRC11 PI 2004_1_500 SAPKIPZI6B PI_BASIS 2005_1_640 SAPKIPYJ65 ST-PI 2005_1_640 SAPKITLQH3




PAGINA 10 DI 61

Come J2EE engine per le componenti XSS è impiegato l’engine del portale. Il livello di patching per

l’ambiente è NETWEAVER 04 - SP Stack 15. In Figura 6 è mostrato il dettaglio delle componenti

software.

Figura 6: Dettaglio delle componenti software (XSS)

3.43.43.43.4 Sistema di Reporting (Netweaver ’04 SR1 Sistema di Reporting (Netweaver ’04 SR1 Sistema di Reporting (Netweaver ’04 SR1 Sistema di Reporting (Netweaver ’04 SR1 –––– BW 3.5) BW 3.5) BW 3.5) BW 3.5)

L’ambiente completo della soluzione di Business Warehouse è si compone di:

• Oracle 9.2.0.7: database

• WAS 6.40 (ABAP Stack): piattaforma applicativa ABAP di SAP Netweaver. Fornisce


tecnologia ABAP

• SAP BW Business Content Add-On (BI_CONT 3.5.3): estensione del WAS 6.40 ABAP che

fornisce le funzionalità di Data Warehouse

Il livello di patching per l’ambiente è NETWEAVER 04 - SP Stack 15. Il dettaglio delle componenti

software è mostrato in Figura 7.

Figura 7: Dettaglio delle componenti software (Sistema Reporting)

SAP XSS (Self Services)

SAP J2EE ENGINE 6.40 SP015 SAP PCUI_GP 100 SP011 SAP ESS 100 SP011 SAP MSS 100 SP011

Sistema Reporting (SAP NetWeaver ‘04 SR1 – BW 3.5)

Database


SAP KERNEL 6.40 64bit SP101 SAP NW – Business Intelligence

SAP ABA 6.40 SAPKA64015 SAP BASIS 6.40 SAPKB64015 SAP BW 3.50 SAPKW35015 BI CONT 3.53 SAPKIBIFP7 PI_BASIS 2005_1_640 SAPKIPYJ65




PAGINA 11 DI 61

3.53.53.53.5 Solution Manager e Solution Manager Diagnostics (Netweaver ’04s Solution Manager e Solution Manager Diagnostics (Netweaver ’04s Solution Manager e Solution Manager Diagnostics (Netweaver ’04s Solution Manager e Solution Manager Diagnostics (Netweaver ’04s –––– SM 4.0) SM 4.0) SM 4.0) SM 4.0)

Il dettaglio delle componenti software è mostrato in Figura 8.

Figura 8: Dettaglio delle componenti software (Solution Manager e Solution Manager Diagnostics)

Solution Manager (SAP NetWeaver ‘04s – MS 4.0)

Database


SAP KERNEL 7.00 64bit SP041 SAP Solution Manager 4.0

SAP ABA 7.00 SAPKA70006 SAP AP 7.00 SAPKNA7002 SAP BASIS 7.00 SAPKB70006 SAP BBPCRM 5.0 SAPKU70002 SAP BW 7.00 SAPKW70006 CPRXRPM 400 SPAK-40002INCPRXRPM ST 400 SAPKITL412 ST-ICO 150_700 SAPK-15072INSTPL ST-PI 2005_1_700 SAPKITLQI1 ST-SER 700_2005_2 SAPKITLOC2 PI_BASIS 2005_1_700 SAPKIPYJ66 Solution Manager Diagnostics SAP J2EE ENGINE 7.00 SP006 SAP J2EE ENGINE CORE 7.00 SP006 J2EE ENGINE BASE TABLES 7.00 SP006 J2EE ENGINE CORE TOOLS 7.00 SP006 JAVA LOG VIEWER 7.00 SP006 JAVA SP MANAGER 7.00 SP006 ADOBE DOCUMENT SERVICES 7.00 SP006 BI META MODEL REPOSITORY 7.00 SP006 BI UDI 7.00 SP006 DI BUILD TOOL 7.00 SP006 LIFECYCLE MANAGEMENT TOOLS 7.00 SP006 SAP CAF 7.00 SP006 SAP CAF-UM 7.00 SP006 SAP IGS 7.00 SP001 SAP SOFTWARE DELIVERY MANAGER 7.00 SP006 SAP TECH S 7.00 OFFLINE SP006 SAP IKS 7.00 SP006 UME ADMINISTRATION 7.00 SP006




PAGINA 12 DI 61

3.63.63.63.6 Content Management System (EMC Documentum v.5.3)Content Management System (EMC Documentum v.5.3)Content Management System (EMC Documentum v.5.3)Content Management System (EMC Documentum v.5.3)

Il sistema di content management ha una architettura distribuita su differenti host fisici, su cui sono

installati i software di base e di sistema certificati da Documetum.

La piattaforma EMC² Documentum si compone di quattro livelli:

• Livello dei Servizi, costituito da Documentum Content. Fornisce le funzionalità per la

gestione dei contenuti e costituisce la base per tutti gli altri prodotti.

Il software installato nei server comprende:

o Site Caching Services (Sources): servizio di caching e replica su altri ambienti dei

contenuti;

o Application DocApp (WebPublisher server): server di integrazione con WebPublisher;

o WDK (Web Development Kit 5.3 SP2): framework per lo sviluppo di applicazioni Web

di gestione dei contenuti Documentum;

o DOCBroker: modulo di load balancing per il servizio Content Server;

o Index Server: servizio di indicizzazione e ricerca full-text dei contenuti;

o Content Server 5.3 SP2 (DMCL, DFC): fornisce alle applicazioni client i servizi di

accesso ai contenuti del repository Documentum;

o Oracle Client 10.2.0.1: client e API di accesso a sistemi RDBMS Oracle;

o JRE 1.4.02_05: macchina virtuale Java;

o Solaris 10: sistema operativo.

• Livello Client, costituito dai prodotti per gli utenti finali, dagli strumenti di sviluppo e dalle

integrazioni con altri sistemi. Fornisce l’accesso alla funzionalità di gestione contenuti nel

contesto di determinate funzioni di business. I requisiti minimi per i client sono

o Internet Explorer 6.0 SP1

o MS JVM 5.0.0.3810

o Windows 2000 /XP

• Livello di Interfaccia, di cui fanno parte le Documentum Foundation Classes (DFC) e le API

correlate. Rappresenta lo strato di interfacciamento con le funzionalità fornite dal Livello dei

Servizi.

• Livello Applicativo, costituito dalle applicazioni integrate che utilizzano la funzionalità di

gestione contenuti come parte delle proprie soluzioni di business. Il livello applicativo è

installato su due server Sun Fire T2000 uguali; ciascuna installazione comprende:

o Site Caching Services (Target): servizio di caching destinazione;

o WebPublisher 5.3 SP2: applicazione web J2EE di editing e pubblicazione contenuti

Documentum;

o Italdata Prot@Flow vers. 2: sistema di gestione del protocollo informatico;




PAGINA 13 DI 61

o WebTop: client WDK per Documentum, realizzato come applicazione Web J2EE

o Documentum Administrator 5.3 SP2: applicazione web J2EE di amministrazione

Documentum;

o Documentum Foundation Classes 5.3 SP2: API Javaper di Documentum;

o DMCL Libraries: librerie di comunicazione tra applicazione client e Documentum

Content Server;

o Apache Tomcat 5.0.28: application server J2EE;

o Client Oracle 10.2.0.1: client e API di accesso a sistemi RDBMS Oracle;

o JVM (JRE 1.4.2_X - J2SE): virtual machine Java;

o Solaris 10: sistema operativo.

L’architettura del sistema di gestione documentale include inoltre i servizi di connessione

verso i sistemi SAP, e di trasformazione dei documenti (Documentum Trasformation Services

5.3 SP2). I due servizi sono installati su una coppia di server SunFire X4200.

3.73.73.73.7 Sistema di OCR (Kofax Ascent Capture Vers. 7)Sistema di OCR (Kofax Ascent Capture Vers. 7)Sistema di OCR (Kofax Ascent Capture Vers. 7)Sistema di OCR (Kofax Ascent Capture Vers. 7)

Il sistema di OCR è configurato in cluster software su ambiente Windows, Sql Server e Microsoft

Clustering Services. Lo stack applicativo è composto da:

• Acis Release Script for Documetnum: script per l’integrazione documentum – Kofax;

• Acis Kofax Remote Station Vers 7: componente per la gestione delle stazioni di scansione

remote;

• Acis Kofax Vers 7: sistema server di OCR;

• Microsoft Cluster Service: servizio di clustering software;

• SQL Server Enterprise Edition: RDBMS;

• Windows 2003 Server Enterprise Edition: sistema operativo.

3.83.83.83.8 Sistema per la Rilevazione delle presenze (Selewin)Sistema per la Rilevazione delle presenze (Selewin)Sistema per la Rilevazione delle presenze (Selewin)Sistema per la Rilevazione delle presenze (Selewin)

Il sistema di rilevazione presenze basato sul prodotto Selewin di Selesta è installato su due macchine

windows con il seguente stack applicativo:

• Selewin (Vers. 3.0.X): modulo di gestione di tutte le funzioni di configurazione dei terminali,

controllo dello stato, invio di comandi;

• SeleSap45 (Vers. 2.0.X): interfaccia di tipo grafico mediante la quale sono possibili tutte le

funzioni di configurazione dei flussi da e verso SAP, le modalità di interscambio dati con i

terminali ed il monitoraggio del funzionamento del sistema;

• IDOUP: servizio windows per l’invio delle timbrature;

• IDODN: servizio per la comunicazione con SAP;

• Windows 2003 Server Enterprise Edition: sistema operativo.




PAGINA 14 DI 61

3.93.93.93.9 RDBMS (Oracle 10 g)RDBMS (Oracle 10 g)RDBMS (Oracle 10 g)RDBMS (Oracle 10 g)

Il cluster Oracle è gestito via software con SUN Cluster 3.1. Sono presenti tra instanze di DB: la prima

per Documentum, la seconda per eventuali necessità di sviluppi custom, la terza per gestire i requisiti

d’integrazione e utilizzata come area di staging. Lo stack applicativo è

• Oracle 10.2.0.1: RDBMS;

• Cluster Solaris 3.1: servizio di clustering software;

• Solaris 10: sistema operativo.

3.103.103.103.10 Access Manager (Sun Java System Access Manager)Access Manager (Sun Java System Access Manager)Access Manager (Sun Java System Access Manager)Access Manager (Sun Java System Access Manager)

L’access manager di Sun è installato su due macchine T2000 in load balancing con il seguente stack

applicativo:

• Sun Java System Directory Server 5 2005Q4: server LDAP;

• Sun Java System Web Server 6.1 2005Q4 SP5: server web;

• J2SE platform 1.5.0_04: Piattaforma java standard edition;


3.113.113.113.11 Proxy ServerProxy ServerProxy ServerProxy Server

Il Proxy Server, realizzato tramite Apache, è installato su due macchine T2000 in load balancing

direttamente sulla DMZ SIBAR e hanno il seguente stack applicativo:

• Apache: configurato come proxy server;

• Sap Router: componente Sap per la gestione dell’accesso ai sistemi Sap in back-end;


La Figura 9 mostra l’architettura applicativa nel suo insieme.

Figura 9: Architettura applicativa nel dettaglio

Was Abap 640 BI Cont 353

Reporting /simul .

Was Abap 640 ECC 5.0

Sistema ERP/HR

Abap Schema

Abap Schema

Was Abap 700 Solution Mgr & Diagnostic 700

Abap Schema

Was Java 700

J2EE Schema Sol Mgr

Apache Proxy Server IAM

LDAP SapGui 640 Web Browser

Client Utente

Web Browser Client Utente Esterno

Saprouter

Applicazioni Infrastrutturali SAP

SAP Front - End

Portal & Content Management

Presentation

Acis kofax

Was Java 640 Portal Platf . 6.0

Portale / XSS

BP - ESS 60.2 BP - MSS 60.3

S L D

J2EE Schema

XSS 500

SelWin

Rilevazione Presenze

Back - End

Oracle 10. .2.0.1

Back - End DB

Content Server 5.3 SP2

(DMCL, DFC) WDK Kit 5.3

SP2 Docapp

Site Caching Services

DOCBroker Index Server Oracle Client

JRE

Tomcat 5.0.28

Foundation Classes 5.3

SP2

Webtop DMCL Libraries

Italdata Prot@Flow

vers. 2 Documentum Administrator

5.3 SP2

D.T.S. 5.3 SP2 Content Services for

SAP




PAGINA 15 DI 61

4444 Architettura esecutivaArchitettura esecutivaArchitettura esecutivaArchitettura esecutiva

In questa sezione viene descritto come il sottosistema SIBAR opera in condizioni di esercizio. In

particolare sono analizzate:

• Piattaforma infrastrutturale: infrastruttura hardware, infrastruttura di rete, infrastruttura di

storage)

• Architettura di sicurezza;

• Architettura d’integrazione.

4.14.14.14.1 Piattaforma InfrastrutturalePiattaforma InfrastrutturalePiattaforma InfrastrutturalePiattaforma Infrastrutturale

La piattaforma infrastrutturale prevista per il sottosistema SIBAR, è composta da hardware SUN

completamente ridondato.

L’infrastruttura di rete è realizzata presso il CED della Regione Sardegna, attualmente in carico alla

società in-house della Regione. Gli aspetti di sicurezza sono di conseguenza a carico del personale

della Regione, mentre il routing all’interno della zona di back-end è effettuato attraverso un apparato

Cysco Catalist 4506. L’infrastruttura di storage è costituita da una Storage Area Network collegata in

Fiber Channel alle macchine e da una Tape Library L500 di SUN. La rete in fibra è gestita da due

switch ottici Qlogic.

4.1.14.1.14.1.14.1.1 InfrastrutturaInfrastrutturaInfrastrutturaInfrastruttura hardware hardware hardware hardware

L’architettura hardware è mostrata in Figura 10.

Nel dettaglio, essa è costituita da

• 18 Sun Fire T2000

• 7 Sun Fire X4200 con processori AMD Opteron

• 1 Sun Fire V20z con un processore AMD Opteron




PAGINA 16 DI 61

Figura 10: Infrastruttura hardware

L’hardware è allocato sulle diverse aree del sottosistema SIBAR secondo la tabella seguente.

Area SIBAR Descrizione Caratteristiche Q.tà Cluster

DMZ Internet Apache Web Proxy

Server T2000 8core 1.2GHz US-T1 32GB 4x 73GB – 6 FE – 2 FC 2 NO

DMZ Internet Load Balancer LB N1400 – 4 FE 2 n.a.

DMZ Intranet Selesta SeleWIN X4200 1x AMD/Opt. Mod 254 @2.8GHz 8 GB 4x 73GB – 4

FE 2 NO

B.E. Identity

Management

SJS Access

manager T2000 8core 1.2GHz US-T1 32GB 4x 73GB – 6 FE – 2 FC 2 NO

B.E. Content

management

Application Server

Content

Management

T2000 8 core 1.2GHz US-T1 32 GB 4x 73GB – 6 FE – 2 FC 2 NO

B.E. Content

management

Content Server

Documentum T2000 8 core 1.2GHz US-T1 32 GB 4x 73GB – 6 FE – 2 FC 2 NO

B.E. Content

management Acis Kofax

X4200 2x AMD/Opt. Mod 254 @2.8GHz 16 GB 4x

73GB – 4 FE – 2 FC 2 NO

B.E. Content

management Sap Connector


73GB – 4 FE 2 NO

Load Balancer #1 Sun N1400

Load Balancer #2 Sun N1400

2 X SunFire X4200 Selesta Selewin

2 X SunFire T2000 (4 Core/8 GB) Apache Web Proxy Server

Z1

Z2 Z1

Z2

2 X SunFire T2000 (8 Core/32 GB) SJS Access Manager

Z1

Z2 Z1

Z2

2 X SunFire T2000 (8 Core/32 GB) Application Server Documentum

Z1

Z2 Z1

Z2

2 X SunFire T2000 (8 Core/32 GB) Web/Application Server Prot@Flow

Sun Blade 150 Console

2 X SunFire X4200

Acis Kofax

Z1

Z2 Z1

Z2

Z3

Cluster SunFire T2000 (8 Core/32 GB) #1 & #2

SJS Access Manager

Z1

Z2 Z1

Z2

Z3

Cluster SunFire T2000 (8 Core/32 GB) #3 & #4

SJS Access Manager

Cluster SunFire T2000 (8 Core/32 GB) Oracle

SJS Access Manager

2 X SunFire X4200 SAP Connector

Z1

Z2

Z3

SunFire T2000 (8 Core/32 GB) Monitoring & Backup Server

Sun Tape Library 500

4 X QLogic 5200

3 X StorEdge 6130

Z1

Z2

Z3

SunFire T2000 (8 Core/32 GB) SunFire X4200

Z4

Z1

Z2

Z3

SunFire T2000 (8 Core/32 GB)

SVILUPPO

Sun Blade 150




PAGINA 17 DI 61

B.E. SAP SAP ERP/HR T2000 8 core 1.2GHz US-T1 32 GB 4x 73GB – 6 FE – 2 FC 2 SI

B.E. SAP SAP BW/ EP T2000 8 core 1.2GHz US-T1 32 GB 4x 73GB – 6 FE – 2 FC 2 SI

B.E. DataBase Oracle T2000 8 core 1.2GHz US-T1 32 GB 4x 73GB – 6 FE – 2 FC 2 SI

Backup &

Administration Backup Server T2000 8 core 1.2GHz US-T1 32 GB 4x 73GB – 6 FE – 2 FC 1 n.a

Backup &

Administration

Enterprise

Manager T2000 6 core 1.2GHz US-T1 8 GB 2x 73GB 1 n.a.

Backup &

Administration Storage Manager V20z 1x AMD/Opt. Mod 250 2 GB 1x 73GB 1 n.a.

Backup &

Administration

Management

Console 1 @ 650Mhz US-Iii 512 MB 1x 80GB – 5 FE 2 NO

Sviluppo SAP T2000 8 core 1.2GHz US-T1 32 GB 4x 73GB – 6

FE – 2 FC 1 NO

Sviluppo Portal & Content

management

T2000 8 core 1.2GHz US-T1 32 GB 4x 73GB – 6

FE – 2 FC 1 NO

Sviluppo Acis Kofax e Sap

Connector


73GB – 4 FE 1 NO

Switch per Cluster Switch Cisco Cisco 2906 – 24 Porte 2 n.a.

4.1.24.1.24.1.24.1.2 InfrastrutturaInfrastrutturaInfrastrutturaInfrastruttura di rete di rete di rete di rete

La Figura 11 illustra l’infrastruttura di rete. Il Firewall è il punto d’accesso al sottosistema SIBAR per la

rete Internet e per la rete degli uffici regionali. Sul Firewall sono terminate inoltre le reti considerate ad

alto rischio (proxy server, rilevazione presenze) e le reti di backup, connesse verso il server di backup

dall’infrastruttura ad hoc realizzata dal CSR.

Le reti di back-end, su cui risiedono i servizi, sono instradate direttamente sui Cisco Catalyst 4506

CoreSBR, a cui sono inoltre attestate le reti di management dei sistemi e degli apparati di rete. Tutti i

servizi di back-end e i sistemi di sviluppo sono collegati allo storage tramite link in fiber-channel.

Figura 11: Infrastruttura di rete




PAGINA 18 DI 61

Sono definite le seguenti sottoreti:

• Rete di Point-to-point tra Firewall e ambiente SIBAR.

• DMZ servizi front END Internet. Comprende tutti gli indirizzi di sistemi che sono all’esterno di

SIBAR, raggiungibili da Internet e che hanno necessità di routing verso l’ambiente SIBAR. In

questa rete, ad esempio, è presente il VIP (Virtual IP) che bilancia sui proxy server. In

considerazione delle sue caratteristiche di potenziale rischio, il suo gateway è il firewall.

• DMZ servizi front END Intranet. Comprende tutti gli indirizzi che erogano servizi alla intranet

R.A.S. In questa rete è presente il VIP che bilancia il SAP-Router, per indirizzare le

connessioni dei client SAPgui nella intranet verso l’ambiente SAP senza che quest’ultimo sia

esposto nel front-end. In questa rete sono inoltre contenuti i rilevatori di presenza. In

considerazione delle sue caratteristiche di potenziale rischio, il suo gateway è il firewall.

• Rete LAN per i Server adibiti a Management e Monitoring. Prevista per necessità di

amministrazione e management. E’ suddivisa nelle seguenti sottoreti, ciascuna delle quali ha

come gateway una interfaccia del CoreSBR:

o Rete di management per i sistemi, in cui risiedono le interfacce di amministrazione dei

sistemi e quelle di console dei T2000;

o Rete di management per gli apparati di rete.

• Rete LAN per le attività di sviluppo e test (Server e Pc Client). Zona destinata alla

presenza di server di sviluppo, test dei prodotti software e dei servizi di futura

implementazione in produzione. E’ previsto l’accesso in modalità VPN, per i Pc Client degli

sviluppatori. Tale rete ha come gateway una interfaccia del firewall.

• Back End Backup. Il sottosistema di Backup è diviso nelle seguenti sottoreti:

o LAN Backup per SAP;

o LAN Backup per ambienti di sviluppo;

o LAN Backup per proxy server;

o LAN Backup rilevatori di presenze;

o LAN Backup per gli altri sistemi interni.

Tutte le reti elencate hanno come gateway il firewall: la segmentazione in diverse sottoreti

garantisce la separazione di traffico a livello 3 aumentando la sicurezza e diminuendo il rischio

di attacco dall’interno in caso di compromissione di un sistema che abbia un’interfaccia

nell’ambiente di backup.

Tutte le reti, verso le quali convergono le seconde interfacce dei server, indirizzano il traffico

nella rete di Backup di competenza CSR, con indirizzamento esterno rispetto all’ambiente

SIBAR ove risiede il server di Backup connesso con la Tape Library SUN L500 tramite fibra

ottica.




PAGINA 19 DI 61

• Rete di Back End Applicativi e Database. Suddivisa in sottoreti, assegnate ciascuna ad uno

specifico servizio di backend e avente come gateway una interfaccia del CoreSBR:

o Rete di BE di SAP, in cui sono presenti tutti i componenti SAP e le istanze dei

database di SAP;

o Rete di BE di Portal&Content Management, in cui risiedono gli applicativi:

� Documentum (Content Server e WebApp Server);

� Acis Kofax;

� Content Services for SAP (interfaccia tra Documentum e SAP).

o Rete di BE di Identity Management, in cui è presente l’Access Manager per

l’autenticazione e l’autorizzazione alle applicazioni web in SSO;

o Rete di BE del database Oracle le cui istanze servono al sistema di Documentum.

Il traffico tra le reti instradate dai CoreSBR e quelle instradate dai Firewall è garantito da una subnet di

transito tra B.E. Core e Firewall.

L’infrastruttura di rete è composta da quattro sezioni:

• Backbone di uplink verso gli ambienti esterni e verso le reti SIBAR direttamente attestate sui

firewall;

• Core di aggregazione per l’erogazione, costituito da una coppia di switch Cisco Catalyst

4500; forniscono la connettività direttamente alle interfacce di rete dei sistemi, utilizzando

tecnologia ethernet su rame e con banda di 1Gbps su ogni interfaccia. A tale sezione

appartengono anche i due bilanciatori SUN1400;

• Backbone S.A.N., costituito da quattro switch QLogic 5200; forniscono la connettività ottica a

tutte le macchine verso l’array di dischi SUN SE6130;

• Backbone hearthbeat dei cluster, costituito da due switch Cisco Catalyst 2906; fornisce la

connettività alle interfacce dei cluster utilizzate per heart-beat.

Gli ultimi due segmenti sono isolati rispetto all’ambiente di core e di backbone. Per quanto riguarda

l’architettura di backbone di uplink verso gli ambienti esterni e verso le reti SIBAR direttamente

attestate sui firewall, lo schema logico di cablaggio è mostrato in Figura 12.




PAGINA 20 DI 61

Figura 12: Interconnessione tra gli apparati di core e quelli di backbone

Ogni CoreSBR ha un link verso ciascuno dei due firewall per ridondanza; è inoltre attivo un link in

giga-etherchannel da 2Gbps tra i due core in modo da garantire la ridondanza anche nell’ambiente di

aggregazione.

Gli uplink tra i CoreSBR e i firewall sono realizzati tramite interfacce da 1Gbps su rame, garantendo

una banda massima di 1Gbps di uplink. E’ prevista un’ulteriore interfaccia da 1Gbps per ogni core da

utilizzare per realizzare un Giga-Etherchannel da 2Gbps di banda nel caso l’entità del traffico di uplink

lo renda necessario.

Per quanto riguarda la struttura di core di aggregazione per l’erogazione, tutti i sistemi hanno, per ogni

interfaccia di erogazione e/o backup, un link verso il CoreSBR1 e uno verso il CoreSBR2,

privilegiando come link attivo quello verso il CoreSBR1. I due link fisici sono aggregati a livello di

sistema operativo, utilizzando l’IPMP su sistema SOLARIS 10.0 e il NIC-BRIDGING su sistemi

Windows XP.

Tutti i sistemi che hanno porzione di filesystem direttamente residenti sullo storage e hanno una

connessione diretta alla S.A.N. in fiber-channel, hanno tali interfacce connesse agli switch del

Backbone S.A.N. Anche questo link è ridondato.

I tre nodi dei cluster hanno le interfacce di heartbeat connesse con gli switch appartenenti al

Backbone hearthbeat dei cluster. Tale scelta architetturale garantisce impatto nullo sulla stabilità dei

cluster in caso di fault di altri segmenti della rete.




PAGINA 21 DI 61

Nella tabella seguente è indicato il dettaglio della fornitura di rete:

Codice Descrizione Quantità

WS-C4506 Catalyst 4500 Chassis (6-Slot),fan, no p/s 2

PWR-C45-1000AC Catalyst 4500 1000W AC Power Supply (Data Only) 4

WS-X4548-GB-RJ45

Catalyst 4500 Enhanced 48-Port 10/100/1000 Module (RJ45) 2

WS-X4424-GB-RJ45

Catalyst 4500 24-Port 10/100/1000 Module (RJ45) 2

WS-X4516 Catalyst 4500 Supervisor V (2 GE),Console(RJ-45) 2

BRET-UTP-CAT6-2

Patch Cord UTP CAT.6 260

BRET-SC/SC-2 Bretella in F.O. 50/125 multimode SC/SC, MM da 2 m 2

S4KL3K9-12225EWA

Cisco IOS BASIC L3 Cat4500 SUP2+/4/5,3DES(RIP,St.Rts,IPX,AT) 2

WS-G5484 1000BASE-SX Short Wavelength GBIC (Multimode only) 4

4.1.2.14.1.2.14.1.2.14.1.2.1 Bilanciamento hardware (SUN N1400Bilanciamento hardware (SUN N1400Bilanciamento hardware (SUN N1400Bilanciamento hardware (SUN N1400))))

I servizi per i quali è necessario effettuare il bilanciamento di carico su più macchine sono supportati

da una coppia di balancer SUN N1400 in configurazione active-standby.

I balancer rendono disponibili seguenti VIP (Virtual IP):

• VIP di erogazione Proxy verso Internet;

• VIP di erogazione di SAP-Router verso Intranet;

• VIP di erogazione di Access Manager verso i proxy;

• VIP di erogazione Application Server verso i proxy.

A livello 2, il balancer 1 è connesso al CoreSBR1, il balancer 2 al CoreSBR2. Per ciascuno dei due è

configurato un link di banda 1Gbps; il sistema è predisposto per l’ampliamento della banda in caso di

necessità.

Il bilanciamento dei Proxy e del SAP-Router è in modalità “routed”: i VIP sono su una rete differente

rispetto a quella dei server reali. Tale modalità risulta più sicura rispetto ad altre modalità di

bilanciamento e garantisce maggiore semplicità di troubleshooting.

A livello 3, la struttura di bilanciamento è mostrata in Figura 13.




PAGINA 22 DI 61

Figura 13: struttura di bilanciamento a livello 3

4.1.2.24.1.2.24.1.2.24.1.2.2 Accesso in VPNAccesso in VPNAccesso in VPNAccesso in VPN

L’accesso ai sistemi del sottosistema SIBAR tramite VPN da parte del personale responsabile della

manutenzione dei sistemi e lo sviluppo è garantito dal Firewall e risulta quindi in totale gestione al

CED della Regione.

L’utente stabilisce una connessione tramite IPSEC o PPTP verso il firewall; fornisce quindi le

credenziali in proprio possesso e ottiene accesso e visibilità/servizi per i quali è abilitato. Ogni utente

ha un IP univoco e sempre uguale per tutte le connessioni, fino a quando è abilitato all’accesso in

VPN. L’IP assegnato in fase di setup dell’account, viene estratto da una rete a discrezione del CED

della Regione e esterna a SIBAR.

È prevista la modalità di tunnel lan-to-lan per l’accesso ai sistemi SIBAR da parte di SAP@Walldorf.

4.1.34.1.34.1.34.1.3 Infrastruttura SANInfrastruttura SANInfrastruttura SANInfrastruttura SAN

L’infrastruttura di storage è configurata in RAID 5 ed è composta da 42 dischi da 146 GB per un totale

lordo di 6,1 TB (4,7 TB disponibili). Lo storage esterno è utilizzato da tutti i sistemi di produzione

attraverso un collegamento in Fiber Channel.

Il dettaglio della fornitura è mostrato nella tabella seguente:

Area SIBAR Descrizione Caratteristiche Quantità

Storage Storage Area

Network

SE6130 1 14x 146GB

10K rpm 3

Switch Ottici Switch Ottici Qlogic 5200 2

Backup Tape Library L500 – 2 Drive LTO3 e

100 Slots 1




PAGINA 23 DI 61

4.24.24.24.2 Architettura di sicurezzaArchitettura di sicurezzaArchitettura di sicurezzaArchitettura di sicurezza

Nel presente capitolo è illustrata l’architettura di sicurezza del sottosistema SIBAR, con particolare

riguardo all’integrazione tra gli ambienti applicativi ed il sistema di sicurezza per l’identificazione,

autenticazione ed autorizzazione degli utenti.

4.2.14.2.14.2.14.2.1 Sicurezza infrastrutSicurezza infrastrutSicurezza infrastrutSicurezza infrastrutturaleturaleturaleturale

La sicurezza infrastrutturale è garantita dal CED regionale, attualmente in gestione alla società in-

house della Regione, in cui l’infrastruttura SIBAR è ospitata. Le politiche relative a sicurezza

perimetrale e accesso a livello di infrastruttura hardware e di rete sono pertanto a carico del personale

di tale società. Il firewall garantisce anche accesso VPN agli utenti sviluppatori, effettuato tramite

protocollo IPSEC.

4.2.24.2.24.2.24.2.2 Accesso ed autenticazioneAccesso ed autenticazioneAccesso ed autenticazioneAccesso ed autenticazione

Il processo di autenticazione si basa su verifica di credenziali costituite da Username e Password; in

particolare, per l’accesso via web alle applicazioni è utilizzata l’architettura di Web Access Control

(WAC), realizzata mediante piattaforma Sun Java System Access Manager, che garantisce la

funzionalità di Single Sign-On (SSO) per tutti gli accessi alle applicazioni web.

4.2.2.14.2.2.14.2.2.14.2.2.1 Architettura di autenticazione per l’Enterprise PortalArchitettura di autenticazione per l’Enterprise PortalArchitettura di autenticazione per l’Enterprise PortalArchitettura di autenticazione per l’Enterprise Portal

Di seguito è illustrata l’architettura di autenticazione sul portale SAP per le funzionalità di Employee

self-service, Manager self-service e per accedere al sistema BW-SEM via web. L’architettura di

Autenticazione è schematizzata in Figura 14.

Figura 14: Architettura e processo di autenticazione




PAGINA 24 DI 61

I passi logici del processo sono i seguenti:

• richiesta;

• autenticazione;

• accesso al portale via canale sicuro;

• verifica esistenza utente;

• generazione “Logon Ticket”;

• restituzione “Logon Ticket”;

• accesso alla risorsa richiesta.

Richiesta

Tramite browser viene richiesta la Home Page del portale SAP. Ogni richiesta è indirizzata alla

componente Reverse Proxy dell’architettura WAC.

Autenticazione

L’autenticazione dell’utente è garantita dalla componente esterna WAC.

Accesso al portale via canale sicuro

Le chiamate dirette all’Enterprise Portal non provenienti dal Reverse Proxy dell’architettura WAC

sono filtrate. A questo scopo, sono previste due modalità operative:

• hardening del canale di comunicazione tra Reverse Proxy e Presentation Server, mediante

impiego di SSL con mutua autenticazione;

• utilizzo di ACL (Access Control List) sul Presentation Server dell’Enterprise Portal, allo scopo

di accettare solo richieste provenienti dallo specifico indirizzo IP del Reverse Proxy.

Verifica esistenza utente

E’ previsto che l’uso della Password possa essere inibito, consentendo agli utenti l’accesso mediante

il solo Username, previa verifica dell’esistenza dell’utente in un repository esterno o interno.

Tale verifica è effettuata su un repository esterno LDAP Sun Enterprise Directory Server.

Generazione e restituzione “Logon Ticket”

Una volta verificata l’esistenza dell’utente, è generato e restituito al client un “logon Ticket” necessario

per garantire la funzionalità di SSO sull’Enterprise Portale e tutte le componenti di back-end integrate.

Accesso alla risorsa richiesta

Al termine del processo di autenticazione la pagina richiesta è fornita al client.

Per tutte le richieste successive alla prima, l’autenticazione dell’utente è garantita dal Logon Ticket

conservato nel client e inviato nell’header della richiesta stessa.




PAGINA 25 DI 61

4.2.2.24.2.2.24.2.2.24.2.2.2 Architettura di autenticazione per le Architettura di autenticazione per le Architettura di autenticazione per le Architettura di autenticazione per le altre applicazioni webaltre applicazioni webaltre applicazioni webaltre applicazioni web

Il meccanismo di autenticazione per le altre applicazioni web è identico a quello illustrato per

Enterprise Portal.

4.2.2.34.2.2.34.2.2.34.2.2.3 Architettura di autenticazione per accessi via applicazArchitettura di autenticazione per accessi via applicazArchitettura di autenticazione per accessi via applicazArchitettura di autenticazione per accessi via applicazioni clientioni clientioni clientioni client

L’autenticazione degli utenti che accedono via applicazione client SAPgui al backend SAP avviene

mediante scambio di credenziali (Username e Password) tra il client ed il componente di

autenticazione presente su SAP.

4.2.34.2.34.2.34.2.3 Autorizzazione e profilaziAutorizzazione e profilaziAutorizzazione e profilaziAutorizzazione e profilazione degli utentione degli utentione degli utentione degli utenti

L’autorizzazione degli utenti all’accesso alle applicazioni è gestita in modo centralizzato mediante

l’infrastruttura di I&AM. L’accesso alle specifiche funzionalità di back-end è gestito secondo un

modello decentralizzato: lo specifica componente provvede a verificare sl’autorizzazione dell’utente

sul sistema chiamato.

4.2.3.14.2.3.14.2.3.14.2.3.1 Ruoli di navigazione e processo di Autorizzazione su EP (SAP Netweaver ’04 SR1Ruoli di navigazione e processo di Autorizzazione su EP (SAP Netweaver ’04 SR1Ruoli di navigazione e processo di Autorizzazione su EP (SAP Netweaver ’04 SR1Ruoli di navigazione e processo di Autorizzazione su EP (SAP Netweaver ’04 SR1))))

Un Ruolo di navigazione è costituito da una collezione di permessi d’accesso alle funzionalità messe a

disposizione dal portale SAP Enterprise Portal. Le informazioni su Utenti e Gruppi e sull’associazione

Utenti-Gruppi sono conservati su di un server LDAP esterno.

L’associazione utente-ruolo è realizzata mediante introduzione di gruppi profilativi legati all’utente,

ciascuno dei quali può essere associato a più ruoli di navigazione. Per quanto concerne la definizione

e la gestione delle associazioni Ruolo di navigazione-Gruppo, questa avviene nel Repository interno

di SAP EP.

L’architettura ed il processo di

autorizzazione sono schematizzati

in Figura 15.

Utenti, gruppi e associazioni utenti-

gruppi sono conservati all’interno

dell’LDAP esterno a SAP, mentre

ruoli di navigazione e associazioni

gruppi-ruoli sono mantenuti nel

repository interno di SAP. La

definizione del ruolo di navigazione

è possibile attraverso gli strumenti

messi a disposizione dal portale.

Figura 15: Architettura logica e processo di autorizzazione




PAGINA 26 DI 61

I passi logici del processo sono:

• richiesta

• autenticazione

• autorizzazione e assegnazione ruolo di navigazione

• accesso alle funzionalità di back-end in relazione col ruolo di navigazione assegnato all’utente

Richiesta

Tramite browser viene richiesta la Home Page del portale SAP.

Autenticazione

L’autenticazione dell’utente è garantita dalla componente esterna WAC, realizzata mediante SUN

Java Access Manager.

Autorizzazione

Il processo di autorizzazione prevede:

• interrogazione su LDAP per recuperare i gruppi di cui è membro l’utente (punto 3.1 in Figura

15);

• interrogazione sul Repository interno di SAP EP di tutti i ruoli posseduti dall’utente in base

all’appartenenza ai gruppi (punto 3.2 in Figura 15).

A seconda dei ruoli di navigazione posseduti dall’utente, sono attivate le opportune viste.

Accesso alle funzionalità di back-end in relazione col ruolo di navigazione

Una volta che l’utente è autorizzato all’accesso al portale con l’opportuno ruolo di navigazione, in caso

di accesso a funzionalità di back-end la specifica componente provvede a verificare se l’utente

possiede le autorizzazioni necessarie sul sistema chiamato.

4.2.3.24.2.3.24.2.3.24.2.3.2 ProfiliProfiliProfiliProfili autorizzativi autorizzativi autorizzativi autorizzativi e processo di autorizzazione sui sistemi SAP di back e processo di autorizzazione sui sistemi SAP di back e processo di autorizzazione sui sistemi SAP di back e processo di autorizzazione sui sistemi SAP di back----endendendend

Per “profilo autorizzativo” si intende l’insieme delle abilitazioni necessarie ad un utente per poter

accedere e operare sui sistemi di back-end, in termini di operazioni consentite e privilegi di accesso

alle informazioni.

Tutti gli utenti abilitati ad operare in SAP devono essere associati ad almeno un profilo autorizzativo.

La soluzione realizzata prevede la propagazione dell’identità degli utenti su LDAP (lo stesso impiegato

nel processo di autorizzazione per l’accesso al portale), e garantisce la propagazione delle

anagrafiche degli utenti verso i repository interni di SAP (ECC 5.0, BW) mediante impiego di un

connettore LDAP (SAP LDAP Connector) presente sulle componenti di back-end.

La gestione e la definizione dei profili autorizzativi e dell’associazione utenti-profili autorizzativi è

effettuata all’interno dei sistemi di back-end, mediante specifici strumenti di amministrazione di SAP.




PAGINA 27 DI 61

4.2.3.34.2.3.34.2.3.34.2.3.3 Profili Profili Profili Profili autorizzativi autorizzativi autorizzativi autorizzativi e processo di autorizzazione sui e processo di autorizzazione sui e processo di autorizzazione sui e processo di autorizzazione sui altri sistemi altri sistemi altri sistemi altri sistemi di backdi backdi backdi back----endendendend

In Documentum è prevista la possibilità di creare utenti e gruppi e definirne i privilegi. E’ possibile

specificare, per ogni tipo di oggetto contenuto nel repository, i permessi di default (ex. solo lettura,

modifica, cancellazione etc.) per ogni utente/gruppo ed eventualmente personalizzarli per ogni singolo

documento.

E’ inoltre consentita la creazione di ruoli per definire quali utenti/gruppi possano utilizzare le singole

funzionalità messe a disposizione dalle applicazioni client di Documentum.

L’autenticazione avviene tramite il server LDAP centralizzato utilizzato anche per gli altri servizi; la

profilatura risiede invece all’interno del repository Documentum.

Prot@flow, essendo basato sulla piattaforma Documentum, usufruisce dello stesso meccanismo di

autenticazione e profilatura.

4.2.3.44.2.3.44.2.3.44.2.3.4 Architettura di autorizzazioArchitettura di autorizzazioArchitettura di autorizzazioArchitettura di autorizzazione: il quadro di sintesine: il quadro di sintesine: il quadro di sintesine: il quadro di sintesi

In Figura 16 è mostrata l’infrastruttura tecnologica e i componenti applicativi descritti nei paragrafi

precedenti.

Figura 16: Architettura di autorizzazione

La funzionalità di provisioning del software I&AM provvede a popolare l’LDAP con l’anagrafica utente

comune a tutti gli applicativi (username, nome, cognome, gruppi di appartenenza).

Le altre eventuali informazioni specifiche del singolo applicativo sono gestite e memorizzate

localmente:

• Enterprise Portal e Documentum: l’utente è autenticato grazie alle informazioni presenti su

LDAP; i Ruoli e le associazioni Gruppi-Ruoli vengono gestite direttamente dalle applicazioni, e

memorizzate sui loro database;

• Back-end SAP (ECC e BW): l’utente viene autenticato grazie alle informazioni presenti sul

proprio database, che viene allineato periodicamente all’LDAP per mezzo dell’LDAP

Connector; i Profili e le associazioni Utenti-Profili vengono gestite direttamente da SAP per

mezzo degli strumenti che questo mette a disposizione, e memorizzate sul proprio database.




PAGINA 28 DI 61

4.34.34.34.3 Architettura di integrazioneArchitettura di integrazioneArchitettura di integrazioneArchitettura di integrazione

L’architettura d’integrazione del progetto SIBAR garantisce due modalità di integrazione, Sincrona e

Asincrona.

Modalità Sincrona

Riguarda l’integrazione tra Sap e Documentum ed è implementata in modo monodirezionale. È basata

su EMC Content Services for SAP e sugli agent collegati.

Il servizio software, basato sulle interfacce standard SAP DMS e ArchiveLink, fornisce funzionalità di:

• accesso e visualizzazione dai diversi moduli di SAP dei documenti conservati su

Documentum;

• memorizzazione oggetti Sap standard su Documentum attraverso l’interfaccia certificata

ArchiveLinkTM.

Content Services for SAP è costituito dai seguenti

componenti:

• Agent services. Automatizza il collegamento

tra gli oggetti e i documenti SAP e gli oggetti

Documentum;

• Capture. Permette di associare un

documento di Documentum con l’appropriata

transazione SAP. Una volta realizzata

l’associazione, il documento è visualizzabile

direttamente dalla SAPgui.

• Manage. Permette la gestione dei documenti

su Documentum da Sap;

• View. Permette la visualizzazione diretta su

SAPgui degli oggetti Documentum. Il

componente View deve essere installato su

ogni client che necessita di accedere e visualizzare i documenti salvati su EMC Documentum.

L’architettura di Content Services for SAP è mostrata in Figura 17.

Modalità Asincrona Batch

Questa modalità è adottata per l’integrazione tra il sottosistema SIBAR (in particolare SAP) e il mondo

esterno. Tutti i flussi verso entità interne ed esterne all’Amministrazione Regionale sono gestiti tramite

flat-file in formato ASCII.

La produzione dei flat-file per i flussi in uscita da SAP avviene attraverso programmi ABAP di tipo

"estrattori" eseguiti in modalità batch; il caricamento dei flat-file per i flussi in ingresso a SAP avviene

sempre attraverso programmi ABAP che adottano tecniche differenti secondo l'oggetto di business su

cui lavorano (sessioni di batch-input, call-transaction, direct-input, etc.). In entrambi casi la

temporizzazione delle attività è gestita con il Job Scheduler di SAP.

Figura 17: Architettura di Content Servicces for SAP




PAGINA 29 DI 61

5555 Architettura di Architettura di Architettura di Architettura di svilupposvilupposvilupposviluppo

L’architettura di sviluppo definisce tutti i sistemi di sviluppo utilizzati sul sottosistema SIBAR in

funzione dell’area di riferimento:

• SB – Documentale;

• SCI – Contabilità (SAP);

• HR – Risorse Umane (SAP).

5.15.15.15.1 Ambienti di sviluppo Portal & Content Management (SB)Ambienti di sviluppo Portal & Content Management (SB)Ambienti di sviluppo Portal & Content Management (SB)Ambienti di sviluppo Portal & Content Management (SB)

Il processo di sviluppo per le applicazioni documentali e le applicazioni web che compongono questo

sistema segue un approccio a prototipi. Questo modello prevede delle fasi di verifica e validazione dei

requisiti, da parte dell’utente, attraverso delle sessioni dimostrative che permettano di validare e

verificare come le applicazioni vengono progettate e sviluppate.

Gli ambienti per lo sviluppo di quest’area funzionale sono:

• Sviluppo. Costituita da una macchina SUN T2000 con installati i seguenti applicativi:

o EMC Documentum vers. 5.3 SP2

o Tomcat

o Oracle 10g (10.2.0.1)

o Prot@Flow

o Access Manager

Lo sviluppo delle applicazioni fa uso lato client di un IDE basato su Eclipse 3.1.2 e su i tool di

sviluppo forniti da EMC Documentum. I client di sviluppo hanno i seguenti requisiti:

Software

o Sistema operativo: Windows 2000 (Service Pack4) o Windows XP (Home or

Professional Service Pack1);

o Internet Explorer 6.0 sp1 o superiore;

o IDE Eclipse 3.1.2;

o Apache Tomcat;

o Documentum Application Builder;

o Documentum Developer Studio;

Hardware

o RAM: 1 GB required, 2 GB recommended

o CPU: 2 GHz required, 3 GHz recommended




PAGINA 30 DI 61

5.25.25.25.2 Landscape progettualeLandscape progettualeLandscape progettualeLandscape progettuale

Sono di seguito definiti gli ambienti resisi necessari alla gestione dell’intero ciclo di vita della soluzione

per le aree funzionali SCI e HR;

5.2.15.2.15.2.15.2.1 Livelli del landscapeLivelli del landscapeLivelli del landscapeLivelli del landscape

Le seguenti macro-attività progettuali che hanno avuto impatto sulla definizione degli ambienti sono:

• Realizzazione (1..N)

• Test unitario (1..N)

• Demo Prototipo (1..N)

• Test di sistema funzionale

• Test integrato

• Collaudo utente

• Formazione

• Esercizio

La macro-attività di Realizzazione consiste nello sviluppo dei moduli software che costituiscono il

sistema.

L’obiettivo del Test unitario è verificare l’aderenza dei componenti software ai requisiti funzionali

richiesti.

La “Demo Prototipo” è la fase in cui l’utente verifica e valida il disegno e la realizzazione fin qui svolta,

effettua delle correzioni/integrazioni, che danno vita ad un ulteriore ciclo di realizzazione�test

unitario�demo prototipo.

Il Test di sistema è volto ad assicurare, in assenza dei soli sistemi con i quali SIBAR dovrà

interfacciarsi, la consistenza dell’intera soluzione implementata con le specifiche funzionali ed

architetturali.

La finalità del Test integrato è quella di verificare l’aderenza ai requisiti di integrazione del

sottosistema SIBAR nell’ambiente integrato. Tale test è da effettuarsi attivando tutte le connessioni tra

i sistemi in ambito, con i quali la soluzione SIBAR deve interfacciarsi.

Obiettivo del Collaudo utente è quello di consentire agli utenti di verificare l’aderenza di quanto

realizzato ai requisiti di business definiti in ambito progettuale.

Sulla base delle attività progettuali suddette, della loro collocazione temporale e della disponibilità di

hardware, sono identificati tre ambienti completi dei prodotti in precedenza indicati (si veda Figura 18).

Ambiente di Sviluppo

All’interno dell’Ambiente di Sviluppo è possibile sviluppare, eseguire i test unitari e generare le build di

rilascio ufficiali di qualsiasi componente software previsto dal sottosistema sibar. Esiste inoltre un

ambiente Demo su cui verificare e validare con l’utente i requisiti e il disegno della soluzione in fieri.

Ambiente di Test - Formazione




PAGINA 31 DI 61

Sull’Ambiente di Test sono eseguite le attività di test e collaudo dell’intero sistema. L’ambiente è

costruito in modo tale da poter effettuare l’esecuzione parallela delle sessioni di test integrato da parte

del gruppo di lavoro e di collaudo funzionale per consentire al cliente di eseguire direttamente i casi di

test. E’ inoltre utilizzato per l’erogazione delle sessioni di formazione agli utenti.

Può infine essere utilizzato per simulare la conversione iniziale dei dati prima dell’effettiva esecuzione

in produzione.

Ambiente di Produzione

L’Ambiente di Produzione è l’ambiente che ospita il sistema in esercizio, incluse le applicazioni, i dati

e i processi di business.

Figura 18: Ambienti di sistema

Test Test Produzione Produzione

� 100 Test

integrato � 500 Master

training � 510 Aula1 � 520 Aula2 � 550 Post-corso � 600 Conversioni

� 100 Esercizio � 100 Customizz. � 200 ABAP � 300 Sandbox

Sviluppo




PAGINA 32 DI 61

5.2.25.2.25.2.25.2.2 Configurazione ambientiConfigurazione ambientiConfigurazione ambientiConfigurazione ambienti

Gli applicativi SAP basati sull’application server ABAP, consentono per mezzo della definizione dei

mandanti di separare logicamente all’interno dello stesso sistema diversi ambienti indipendenti: le

configurazioni ed i dati associati ad un mandante possono differire da quelli presenti su un altro

mandante. In questo modo, è possibile associare a mandanti diversi dello stesso sistema, ruoli

progettuali diversi. Nel presente paragrafo è definita per i 3 ambienti precedentemente indicati la

configurazione prevista.

5.2.2.15.2.2.15.2.2.15.2.2.1 SviluppoSviluppoSviluppoSviluppo

Sistema ERP/HR (mySAP ERP 2004 Sistema ERP/HR (mySAP ERP 2004 Sistema ERP/HR (mySAP ERP 2004 Sistema ERP/HR (mySAP ERP 2004 –––– ECC 5.0) ECC 5.0) ECC 5.0) ECC 5.0)

L’ambiente di sviluppo ECC 5.0 è caratterizzato dalla seguente configurazione di mandanti:

MASTER 100

Mandante utilizzato come master delle configurazioni client dependent. Le configurazioni realizzate

sul MASTER sono poi trasferite, tramite Client Copy Of Change Request, sul mandante 200 di

WORKBENCH per il test unitario. Sono consentite modifiche al "Customizing Client Dependent" con

registrazione automatica, mentre non sono consentite modifiche al "Repository e Customizing valido

per più mandanti".

WORKBENCH 200

Questo mandante è utilizzato per:

• Sviluppo per ABAP e customizing client independent.

• Test unitario

E’ allineato, tramite Client Copy Of Change Request, con il mandante 100 a seguito di nuovi sviluppi

di customizing client dependent, al fine di consentirne il test unitario. Il profilo utilizzato per

l’allineamento è SAP_APPL (customizing e dati applicativi).

Non sono consentite modifiche al "Customizing Client Dependent", mentre sono consentite modifiche

al "Repository e Customizing valido per più mandanti".

SANDBOX 300

Mandante di prova per customizing client dependent e per unit test sviluppi ABAP. Le prove di

customizing effettuate su questo mandante devono essere riportate manualmente sul MASTER 100. Il

mandante SANDBOX viene allineato periodicamente e su richiesta tramite Client Copy dal mandante

100. Il profilo utilizzato per l’allineamento è SAP_APPL (customizing e dati applicativi) o SAP_CUST

(customizing) in funzione delle esigenze richieste da chi effettua le parametrazioni di customizing. Le

modifiche al "Customizing Client Dependent" sono consentite senza registrazione automatica, mentre

non sono consentite modifiche al "Repository e Customizing valido per più mandanti".




PAGINA 33 DI 61

CRP 400

Il mandante di CRP è adibito alle sessioni di Conference Room Pilot (CRP). A differenza del

mandante di sandbox, qui non vengono effettuate prove a sistema, ma vengono create le casistiche

oggetto di discussione all’interno di tali sessioni. Le modifiche al "Customizing Client Dependent" sono

consentite senza registrazione automatica, mentre non sono consentite modifiche al "Repository e

Customizing valido per più mandanti".

Il customizing CRP scelto come definitivo a seguito della sessione CRP deve essere replicato

manualmente sul mandante MASTER 100.

Sistema Reporting (Netweaver ’04 SR1 Sistema Reporting (Netweaver ’04 SR1 Sistema Reporting (Netweaver ’04 SR1 Sistema Reporting (Netweaver ’04 SR1 –––– BW 3.5) BW 3.5) BW 3.5) BW 3.5)

Il sistema SAP BW è definito come entità “sovramandante”: anche se tecnicamente permane il

concetto di mandante, è possibile configurare ed utilizzare un unico mandante.

MASTER 100

E’ dedicato prevalentemente per le attività di configurazione/customizing, sviluppo e unit test di oggetti

di Workbench, prototipazione e sperimentazione.

Le impostazioni di tale mandante comportano l'obbligatorietà di registrazione all'interno di Change

Request del customizing e dello sviluppo, per il successivo trasporto verso gli altri ambienti definiti nel

landscape.

Portale (Netweaver ’04 SR1 Portale (Netweaver ’04 SR1 Portale (Netweaver ’04 SR1 Portale (Netweaver ’04 SR1 –––– Enterprise Portal) Enterprise Portal) Enterprise Portal) Enterprise Portal)

L’Enterprise Portal, a differenza degli altri componenti SAP, non prevede il concetto di mandanti.

5.2.2.25.2.2.25.2.2.25.2.2.2 Test Test Test Test ---- Formazione Formazione Formazione Formazione

Questo ambiente è dedicato all’esecuzione delle sessioni di test integrato da parte del gruppo di

lavoro e di collaudo funzionale da parte del cliente. E’ inoltre utilizzato per la definizione e

conseguente erogazione delle sessioni di formazione agli utenti.


L’ambiente di test ECC 5.0 è caratterizzato dalla seguente configurazione di mandanti:

Test 100

Utilizzato per le attività di test (System e Integration) della configurazione e degli sviluppi realizzati.

All’interno del mandante non sono consentite modifiche al customizing o workbench, ma queste

devono provenire dalle Change Request rilasciate dal sistema di sviluppo.




PAGINA 34 DI 61

Collaudo 110

Utilizzato dagli utenti per i test di validazione e accettazione delle funzionalità rilasciate. All’interno del

mandante non sono consentite modifiche al customizing o workbench.

Training Master 500

Utilizzato per la preparazione delle sessioni di formazione. All’interno del mandante non sono

consentite modifiche al customizing o workbench, ma queste devono provenire dalle Change Request

rilasciate dal sistema di sviluppo, e che hanno superato il collaudo nel relativo mandante sul sistema

di test.

Training Aula 510 e Training Aula 520

Utilizzato per l’erogazione delle sessioni di formazione. All’interno del mandante non sono consentite

modifiche al customizing o Workbench. Il mandante è creato e aggiornato periodicamente a partire dal

mandante Training Master tramite client copy.

Conversioni 600

Utilizzato per simulare la conversione iniziale dei dati, prima dell’effettiva esecuzione in produzione.

All’interno del mandante non sono consentite modifiche al customizing o workbench; queste devono

provenire dalle Change Request rilasciate dal sistema di sviluppo, e che hanno superato il collaudo

nel relativo mandante sul di sistema di test.


Il sistema SAP BW è definito come entità “sovramandante”: anche se tecnicamente permane il


Test 100

E’ dedicato alle attività di test di sistema, di integrazione, di collaudo delle funzionalità realizzate nel

mandante Master di sviluppo, e di formazione agli utenti.

All’interno del mandante non sono consentite modifiche al customizing o wokbench, ma queste





PAGINA 35 DI 61

5.2.2.35.2.2.35.2.2.35.2.2.3 ProduzioneProduzioneProduzioneProduzione

E’ l'ambiente di esercizio delle applicazioni.


All’interno dell’ambiente di Produzione è definito un unico mandante.

Esercizio 100

Utilizzato dagli utenti per le applicazioni in esercizio, contiene i dati anagrafici e transazionali effettivi.

All’interno del mandante non sono consentite modifiche al customizing o Workbench, ma queste

devono provenire dalle Change Request rilasciate dal Sistema di sviluppo, e che hanno superato il

collaudo nel Sistema di Test.


Il landscape applicativo prevede l’installazione e la configurazione di un unico mandante.

Esercizio 100

E’ utilizzato dagli utenti finali per l’esecuzione dei reali processi di business. All’interno del mandante

non sono consentite modifiche al customizing o workbench, ma queste devono provenire dalle

Change Request rilasciate dal sistema di sviluppo, e che hanno superato il collaudo nel Sistema di

test.

5.35.35.35.3 Strumenti di sviluppoStrumenti di sviluppoStrumenti di sviluppoStrumenti di sviluppo

Nel presente paragrafo sono elencati, per ogni modulo previsto nell’architettura applicativa del

sottosistema SIBAR, le tipologie di componenti software adottate e gli strumenti a supporto per il

sistema.

5.3.15.3.15.3.15.3.1 Sistema ERP/HR Sistema ERP/HR Sistema ERP/HR Sistema ERP/HR (mySAP ERP 2004 (mySAP ERP 2004 (mySAP ERP 2004 (mySAP ERP 2004 –––– ECC 5.0) ECC 5.0) ECC 5.0) ECC 5.0)

Gli sviluppi sul back end mySAP ERP 2004 sono sostanzialmente di due tipi:

• configurazione delle funzionalità standard fornite dal package in modo da adattarle ai requisiti

del cliente (“customizing”);

• sviluppi di componenti ulteriori per quelle funzionalità non coperte dal pacchetto.

Nel primo caso, la Guida di Implementazione (IMG – Implementation Guide) consente di effettuare le

attività di customizing necessarie. Nel secondo caso il software, oltre a fornire l’ambiente di run-time

per l’applicazione, mette a disposizione un framework per lo sviluppo, utilizzabile per l’estensione di

oggetti già esistenti o la creazione di nuovi.

Le componenti tecniche oggetto di sviluppo sul SAP back-end sono:

• Oggetti del Dictionary (Tabelle, Strutture, View etc.), per l’implementazione del data layer

• Report, Function e BAPI (Business API), per l’implementazione dell’application layer




PAGINA 36 DI 61

• Screen, per la gestione della logica di presentazione

Le function (RFC -Remote function call) e le BAPI rendono fruibile all’esterno la logica applicativa

implementata: in particolare, via classi Java (JCO) è possibile estrarre i dati dal sistema di back-end

affinché siano visualizzati in una iView del Portale.

Lo sviluppo sul back-end SAP non prevede l’installazione e l’utilizzo di particolari applicazioni se non il

client di accesso (SAPgui). Gli strumenti per sviluppare oggetti sul sistema di back-end, così come le

funzionalità applicative, vengono forniti via transazione: facendo il logon al sistema tramite questa

componente sul client si hanno a disposizione tutte le applicazioni e i tool necessari alla creazione ed

implementazione di oggetti custom.

Requisiti stazione di sviluppo

Software

• SAPgui 6.40 disponibile per Windows 2000 o XP

Hardware

• Gli requisiti hardware sono ridotti, e non richiedono particolari attenzioni.

5.3.25.3.25.3.25.3.2 Sistema Reporting (Netweaver ’04 SR1 Sistema Reporting (Netweaver ’04 SR1 Sistema Reporting (Netweaver ’04 SR1 Sistema Reporting (Netweaver ’04 SR1 –––– BW 3.5) BW 3.5) BW 3.5) BW 3.5)

L’attività principale in ambito BW è la modellazione degli oggetti e delle regole necessarie per il

trasporto, l’elaborazione e l’analisi dei dati.

Mediante l’Administrator Workbench, accessibile via client SAPgui (transazione RSA1), è possibile

modellare tutti gli oggetti relativi ai vari flussi, iniziando dalla Persistent Staging Area (PSA), in cui i

dati ricevuti dai sistemi alimentanti sono memorizzati in formato non modificato, fino ad arrivare agli

InfoProviders su cui è possibile costruire le interrogazioni necessarie per il reporting.

La costruzione di query per l’accesso alle informazioni presenti sul sistema BW è possibile per mezzo

dello strumento Query Designer, parte integrante della suite Business Explorer (BEx), che richiede

una installazione sul client della SAPgui per windows con il BW add-on.

Requisiti stazione di sviluppo

Software

• SAPgui 6.40 disponibile per Windows 2000 o XP comprensiva del BW add-on

Hardware

I requisiti di installazione sono ridotti, e non richiedono particolari attenzioni.

5.3.35.3.35.3.35.3.3 Portale (Netweaver ’04 SR1 Portale (Netweaver ’04 SR1 Portale (Netweaver ’04 SR1 Portale (Netweaver ’04 SR1 –––– Enterprise Portal) Enterprise Portal) Enterprise Portal) Enterprise Portal)

L’Enterprise Portal, oltre ad essere l’ambiente di run-time per l’utente finale, è lo strumento base per

gli utenti progettisti, perché è mediante il portale stesso che vengono gestiti i contenuti e la possibilità

per gli utenti di fruirne.




PAGINA 37 DI 61

Lo user administrator è in grado sul portale di combinare i “tasselli informativi” costruiti dal content

administrator, aggregandoli per ruoli funzionali, in modo da ritagliare per ogni figura il contenuto

specifico per le attività di pertinenza.

La figura del content administrator può tramite il PCD (Portal Content Directory) definire il contenuto

da rendere disponibile sul portale: tramite la creazione di iView custom, o l’utilizzo di iView preesistenti

fornite da SAP e altri vendor è presentata sul portale l’integrazione con le fonti dati esterne.

Nel caso sia necessario dal punto di vista progettuale sviluppare applicazioni web custom, sia che si

tratti di applicazioni J2EE, sia che venga utilizzato il modello SAP delle web dynpro (modello di

implementazione SAP del design-pattern Model-View-Controller), è previsto l’utilizzo del software SAP

Netweaver Developer Studio.

SAP Netweaver Developer Studio è lo strumento di sviluppo rilasciato da SAP per implementare

componenti di applicazioni web, che possono essere successivamente utilizzate ed integrate con il

portale. Il tool è derivato da Eclipse.

Dal punto di vista dello sviluppo sono possibili due configurazioni:

• SAP J2EE engine locale: il deploy ed il conseguente unit test dei componenti custom

sviluppati viene effettuato sull’ambiente di run time presente sulla workstation dello

sviluppatore;

• SAP J2EE engine remoto: il deploy ed il conseguente unit test dei componenti custom

sviluppati viene effettuato sull’ambiente di run time centralizzato del server di sviluppo.

Requisiti stazione di sviluppo (SAP J2EE engine locale)

Software

• Sistema operativo Windows 2000 SP3 o Windows XP SP1;

• Internet Explorer 5.5 o superiore;

• SAP NetWeaver ‘04 Developer Workplace (comprensivo di SAP NetWeaver ‘04 Developer

Studio, J2EE engine di SAP WebAS 6.40, MaxDB Database (SQL DB)).

Hardware

• RAM: 1 GB required, 2 GB recommended;

• CPU: 1 GHz required, 2 GHz recommended.

Requisiti stazione di sviluppo (SAP J2EE engine remoto)

Software

• Sistema operative Windows 2000 SP3 o Windows XP SP1;

• Internet Explorer 5.5 o superiore;

• SAP NetWeaver ‘04 Developer Studio.

Hardware

• RAM: 512 MB.




PAGINA 38 DI 61

5.45.45.45.4 SoftSoftSoftSoftware logisticsware logisticsware logisticsware logistics

In questo capitolo è descritta la modalità con cui sono gestite e propagate, ai diversi stadi del

landscape progettuale, le configurazioni applicative e gli sviluppi effettuati dal gruppo di lavoro.

5.4.15.4.15.4.15.4.1 Sistema ERP/HR (mySAP ERP 2004 Sistema ERP/HR (mySAP ERP 2004 Sistema ERP/HR (mySAP ERP 2004 Sistema ERP/HR (mySAP ERP 2004 –––– ECC 5.0) ECC 5.0) ECC 5.0) ECC 5.0)

Le configurazioni e gli sviluppi realizzati in ambiente di sviluppo, tranne quelli effettuati sul mandante

di sandbox, sono registrati automaticamente all’interno delle change request.

In ambito progettuale, gli allineamenti necessari possono essere sia interni alle singole istanze (ad

esempio tra mandanti diversi dello stesso ambiente), che coinvolgere istanze diverse (ad esempio da

sviluppo a test).

In Figura 19 è riportata una rappresentazione di tali allineamenti, evidenziando le modalità utilizzate:

Trasporto di Change Request fra le istanze del Landscape

• Client Copy, utilizzata per riallineamenti periodici o su richiesta. I profili utilizzati per la copia

sono in genere SAP_APPL (customizing e dati applicativi) o SAP_CUST (customizing) in

funzione delle esigenze di riallineamento.

• Client Copy of Change Request per allineamenti di CR all'interno della stessa istanza.

• Allineamento manuale, utilizzato per riportare sul MASTER 100 di sviluppo le prove di

Customizing mandatario effettuate sul mandante di gioco Sandbox. Tale modalità di

allineamento prevede di riportare manualmente le modifiche realizzate precedentemente.

Figura 19: schema degli allineamenti - Sistema ERP/HR

Le configurazioni e gli sviluppi realizzati sull'istanza di sviluppo sono trasportati sull'istanza di Test e

Collaudo al mandante 400, sul quale viene effettuato il test di sistema e di integrazione. In seguito,

viene allineato il mandante 401 di collaudo relativamente agli oggetti mandatari.

My SAP ERP 2004

100 Master

Test

Funzionale Test

CollaudoProduzione Produzione

200 Cust Int+

Workbench

300 Sandbox

100 Test

110 Collaudo

600 Esercizio

Trasporto change request

Client Copy Client copy of change request Allineamento manuale

Sviluppo

400 CRP

500 Training

Master

510 Training

Aula

600 Conversioni




PAGINA 39 DI 61

L'allineamento iniziale degli ambienti di Produzione è realizzato tramite un trasporto "massivo" degli

sviluppi testati e collaudati, secondo le tempistiche delle attività progettuali relative ai due ambienti.

Il tool adottato per la gestione degli allineamenti è “Transport Management System” di SAP, integrato

nel sottosistema SIBAR.


Le istanze di BW sono caratterizzate da un unico mandante. Per questo motivo gli allineamenti

avvengono mediante trasporto di change request fra le istanze del landscape.

Il tool previsto per la gestione degli allineamenti è “Transport Management System” di SAP, integrato

nella soluzione.

Figura 20: Schema degli allineamenti - Sistema BW

5.4.35.4.35.4.35.4.3 Portale (Netweaver ’04 SR1 Portale (Netweaver ’04 SR1 Portale (Netweaver ’04 SR1 Portale (Netweaver ’04 SR1 –––– Enterprise Portal) Enterprise Portal) Enterprise Portal) Enterprise Portal)

Un certo numero di oggetti sviluppabili o configurabili a livello di portale necessitano di essere allineati

tra le varie istanze che compongono il landscape:

• Content Object Transports (iView, Pages, Roles, Worksets,..)

• PAR file transports

• Theme transports

Diversamente dai prodotti precedenti, sul portale è necessario costruire in modo manuale i contenitori

di trasporto: mediante le funzionalità di export è possibile costruire dei contenitori definiti transport

packages, nei quali inserire gli oggetti da allineare nel landscape.

Con la funzionalità di import, gli oggetti contenuti all’interno dei transport packages vengono trasferiti

ed attivati sugli ambienti target.

Per il versioning dei sorgenti Java, su ambiente Solaris si utilizza il sistema CVS, mentre su ambiente

Windows si utilizza SourceSafe.

BW

100 Master

Produzione Produzione

100 Test -

Collaudo 100 Esercizio


Sviluppo Test




PAGINA 40 DI 61

6666 Architettura operativaArchitettura operativaArchitettura operativaArchitettura operativa

Il seguente capitolo illustra le modalità di gestione dell’infrastruttura hardware e software di SIBAR sia

dal punto di vista infrastrutturale/sistemistico che dal punto di vista applicativo.

6.16.16.16.1 Gestione sito fisicoGestione sito fisicoGestione sito fisicoGestione sito fisico

Il sito fisico è a carico della società in-house della Regione. che ha in gestione il CED regionale.

6.26.26.26.2 Gestione sicurezzaGestione sicurezzaGestione sicurezzaGestione sicurezza

La sicurezza perimetrale e di accesso all’infrastruttura hardware e di rete è a carico della società in-

house che ha in gestione il CED della Regione.

6.36.36.36.3 Gestione sistemisticaGestione sistemisticaGestione sistemisticaGestione sistemistica

La gestione sistemistica è affidata alla società in-house della Regione.

6.3.16.3.16.3.16.3.1 Sistemi di base (HSistemi di base (HSistemi di base (HSistemi di base (HWWWW, SO, SO, SO, SO, DB), DB), DB), DB)

La gestione dell’infrastruttura di base viene effettuata periodicamente per hardware, sistema operativo

e database.

6.3.1.16.3.1.16.3.1.16.3.1.1 HardwareHardwareHardwareHardware

Periodicamente viene eseguita una verifica dello stato dell’hardware e degli apparati di rete, sia per

ispezione che tramite tool di monitoraggio appositi. Sono verificati inoltre periodicamente, mediante

tool appositi o per ispezione, il carico di lavoro per CPU, sistema, dischi; è infine verificato

periodicamente per ispezione lo stato di occupazione del filesystem.

Vengono inoltre analizzati i log di sistema in maniera automatica e manuale al fine di reperire

messaggi di diagnostica rilevanti.

6.3.1.26.3.1.26.3.1.26.3.1.2 Sistemi OperativiSistemi OperativiSistemi OperativiSistemi Operativi

E’ effettuato un costante aggiornamento tramite l’applicazione di patch e update rilasciati dal

produttore.

6.3.1.36.3.1.36.3.1.36.3.1.3 DataBaseDataBaseDataBaseDataBase

La gestione operativa dei database è effettuata attraverso l’Enterprise Manager di Oracle, che offre

tutte le funzionalità di gestione, monitoraggio, aggiornamento di tutti parametri di sistema (SGA,

DataFile, tablespace, ecc), verifica dello stato delle diverse istanze di DB presenti.

6.3.1.46.3.1.46.3.1.46.3.1.4 NetworkNetworkNetworkNetwork

Tutti gli apparati di rete hanno un distinto IP per la gestione, appartenente alla rete di management

degli apparati, instradata dai Catalyst 4500. Tale rete permette l’accesso soltanto alle reti delle




PAGINA 41 DI 61

workstation di lavoro locali nel palazzo del CED e agli IP degli accessi in VPN dei network

administrator.

L’autenticazione degli accessi avviene tramite verifica delle credenziali (user/password) definite

localmente su ogni apparato. Ove possibile, le utenze definite hanno privilegi minimali e per svolgere

funzioni di configurazione/manutenzione è necessario immettere apposita password di super-utente

(enable, nel caso di apparati Cisco).

Su ogni apparato che lo permette è stato definito l’elenco di IP/sottoreti che hanno diritto di accesso al

management dell’apparato, in modo da avere una ridondanza sui meccanismi di sicurezza. L’accesso

tramite console seriale è permesso previa autenticazione dell’utente tramite le credenziali definite

localmente sulla macchina. Tali credenziali coincidono con quelle di accesso tramite rete.

Su ogni apparato che lo permette è stato attivato l’SNMP per consentire il monitoraggio: ogni apparato

risponde solo a una specifica community SNMP, ed è definita in sola lettura (onde prevenire

accidentali o maligne configurazioni remote via SNMP); inoltre è stato definito l’elenco di IP/sottoreti

da cui l’apparato si aspetta query SNMP e per le quali invia risposta: tutte le richieste che non

soddisfano tutti i requisiti elencati non ottengono risposta alla query.

Ad ogni variazione, le configurazioni degli apparati vengono trasferite via ftp da un applicativo che si

occupa di cifrarle e copiarle nella tape-library in modo da avere sempre disponibile l’ultima versione

della configurazione in caso di disastro.

Su ogni apparato è attivato il massimo livello di logging, in modo da tenere traccia degli eventi che si

verificano durante l’erogazione; tali eventi vengono inoltrati anche al syslog-server, in modo da avere

copia duratura degli eventi.

Con frequenza periodica è effettuata una verifica sul sito dei vendor degli apparati in modo da

accertare eventuali necessità di aggiornamento dei sistemi operativi onde evitare l’applicazione di

exploit e scongiurare la possibilità di incorrere in bug software durante l’esercizio. Su tutti gli apparati è

disattivata l’amministrazione via web.




PAGINA 42 DI 61

6.46.46.46.4 Gestione disponibilità ambientiGestione disponibilità ambientiGestione disponibilità ambientiGestione disponibilità ambienti

6.4.16.4.16.4.16.4.1 Infrastruttura backupInfrastruttura backupInfrastruttura backupInfrastruttura backup

L'infrastruttura di backup è costituita da un backup server connesso tramite fiber-channel alla tape

library L500, costituita da 2 drive dal troughput di 80Mpbs/drive e dotata di 100 slot.

Il server di backup è posto in una rete esterna all'indirizzamento SIBAR, attestata su apparati del

CSR; il routing verso l'ambiente SIBAR è a cura del firewall.

A livello 2, il backup server ha l'interfaccia di erogazione attestata sui due CoreSBR, in modo da

garantire la ridondanza in caso di fault; la VLAN che veicola la rete del CSR è propagata fino al

CoreSBR e posta sulle porte di accesso del server.

Ogni server che deve effettare il backup ha due interfacce attestate sulla propria rete di backup in

modo da garantire alta affidabilità in caso di failover.

BCK_SAP

BCK_DEV

BCK_PROXY BCK_PRES

BCK_GEN

Tape

library

Backup

Server

Firewall

SIBAR

Altri

Progetti

Figura 21: Infrastruttura di backup

Alla rete BCK_SAP sono attestati tutti i sistemi dell’ambiente SAP. Questa rete viene utilizzata per

copiare su nastro i dati relativi a quell’ambiente; nella rete BCK_DEV sono attestate le macchine di

sviluppo, in quella BCK_PROXY sono attestati i Proxy Server in caso necessitino di effettuare backup,

in quella BCK_PRES i rilevatori di presenza per effettuare il backup dei file di report delle presenze.

Rete particolare è quella BCK_GEN, in cui sono attestate le interfacce dei vari sistemi di produzione

(Documentum, Kofax, Database per Documentum etc..).

I backup, tanto dell’ambiente SIBAR quanto degli altri ambienti, sono programmati in modo da evitare

il più possibile il degrado dell’erogazione dei servizi durante le business hour.

Dal punto di vista applicativo, l’ambiente di protezione dei dati è basato principalmente sul software di

gestione Sun StorEdge Enterprise Backup (ovvero EMC2/Legato NetWorker nella versione OEM

Sun).




PAGINA 43 DI 61

6.4.26.4.26.4.26.4.2 Failover e HAFailover e HAFailover e HAFailover e HA

La continuità di tutti i servizi è garantita da idonee soluzioni tecnologiche implementate nei diversi

livelli dell’infrastruttura IT.

A livello network, la gestione del failover e la continuità di servizio sono garantiti da una ridondanza

fisica tanto degli apparati quanto dei cablaggi. Sono utilizzati due switch multilayer di aggregazione

configurati in modalità active-standby e la continuità dell’erogazione è garantita dal sistema in standby

che entra in servizio quando la macchina attiva dovesse subire dei failure. Per scongiurare

discontinuità di servizio dovute a fail delle schede di rete dei server o delle porte degli switch, ogni

server in produzione ha una doppia interfaccia per ogni rete e tale interfacce sono connesse ciascuna

ad un apparato. La ridondanza della connettività verso l’intranet RAS e verso Internet è garantita da

un doppio collegamento in gigabit ethernet verso gli switch di uplink messi a disposizione dal C.E.D.

A livello applicativo, l’alta affidabilità per tutti i servizi bilanciati è garantita dalla coppia di bilanciatori, in

configurazione active-stanby. Tutti gli IP virtuali sono configurati in modo da verificare la corretta

funzionalità del servizio (health check) prima di inoltrare la connessione al server scelto dall’algoritmo

di bilanciamento, in modo da escludere dall’erogazione le macchine che risultassero fuori servizio dal

punto di vista applicativo e/o sistemistico.




PAGINA 44 DI 61

7777 DescDescDescDescrrrrizione del sottoizione del sottoizione del sottoizione del sotto----sistema SIBEARsistema SIBEARsistema SIBEARsistema SIBEAR

Nel seguito è presentata l’architettura tecnica relativa al sottosistema SIBEAR. L’architettura viene

prospettata da quattro punti di vista differenti:

• Architettura applicativa: descrive delle diverse piattaforme utilizzate;

• Architettura esecutiva: descrive degli apparati dell’infrastruttura assieme anche in ottica

d’integrazione dei sistemi e con l’indicazione dei criteri di sicurezza adottati;

• Architettura di sviluppo: descrive le piattaforme e gli ambienti adottati per lo sviluppo delle

applicazioni;

• Architettura operativa: descrive le modalità e gli strumenti per la gestione dell’infrastruttura

SIBEAR.




PAGINA 45 DI 61

8888 Architettura applicativaArchitettura applicativaArchitettura applicativaArchitettura applicativa

Il sottosistema SIBEAR è suddiviso in differenti aree applicative.

Back - Office Enti/Agenzie

Data Warehouse

Reportistica

Sistema di governance

ContabilitàFinanziaria Cont abilitàEconomico Patrimoniale

Sistema gestione contabi le

Contabilità Economico Analitica

Gestione Approvvigionamenti

Progetto SIBEAR

Controllo di Gestione

SAPMySAP ERP

Gestione Cespiti

Mandato Informatico

SAP BW

Legenda

GESTIONE DEGLI ADEMPIMENTI FISCALI

Figura 22: Architettura Funzionale

La piattaforma applicativa SIBEAR è composta da:

• SAP mySAP ERP 2004: realizza le funzionalità contabilità, gestione approvvigionamenti;

• SAP NetWeaver ’04S - BW 7.0: adottato per la realizzazione delle funzionalità del sistema di

governance con reporting e datawarehouse;

I prodotti SAP a supporto sono i seguenti:

• Sap Solution Manager: adottato in landscape SAP Netweaver con la finalità di supportare le

applicazioni basate su Stack Abap. Il Solution manager è adottato per il monitoraggio dei

sistemi SAP sia internamente cha da SAP AG tramite Early Watch Alert;

• Sap Solution Manager Diagnostics: Strumento per la diagnostica e per il monitoraggio

SMD; è necessario in landscape SAP Netweaver nel quale sono previste applicazioni basate

su Stack Java;

• System Landscape Directory: repository delle informazioni relative ai sistemi SAP (l

landscape sap), dal punto di vista dei sistemi installati, delle release e del livello di patch dei

vari elementi software, e della comunicazioni tra sistemi;

• Sap Router: sw che agisce da proxy per la connessione di SAP OSS (supporto remoto) ai

sistemi SAP del cliente.

L’architettura applicativa del sistema è mostrata in Figura 23. Il sottosistema SIBEAR è inoltre

integrato dalla piattaforma e-learning DOCEBO, per l’erogazione di FAD – formazione a distanza




PAGINA 46 DI 61

Figura 23: Architettura Applicativa

8.18.18.18.1 ERP (mySAP ERP ERP (mySAP ERP ERP (mySAP ERP ERP (mySAP ERP 2004 2004 2004 2004 –––– componenti stack ABAP) componenti stack ABAP) componenti stack ABAP) componenti stack ABAP)

La soluzione ERP per il sistema contabile, adottale seguenti componenti:


• WAS 6.40 (ABAP Stack): piattaforma applicativa ABAP di SAP Netweaver. Realizza

l’infrastruttura necessaria per lo sviluppo, il rilascio nonché l’esecuzione di tutte le applicazioni

Netweaver in tecnologia ABAP;

• SAP ECC 5.0: componente core di mySAP ERP 2004.

Dettaglio delle componenti software:

SCI - Sistema Contabile Integrato Versione

Database

ORACLE 10.2.0.2.0

Kernel

SAP Kernel 64 Bit SP159

Sap ECC Server

SAP_BASIS 640

SAP_ABA 640

ST-PI 2005_1_640

PI_BASIS 2005_1_640

SAP_BW 350

SAP_HR 500

Was Abap 700 BI Cont 700

Reporting

/ simul

. Was Abap 640

ECC 5.0

Sistema ERP/HR

Abap Schema Abap Schema

Was Abap 700 Solution

Mgr & Diagnostic

700

Abap Schema

Was Java 700

J2EE Schema

Sol Mgr

SapGui 640 Client Utente

Saprouter

Applicazioni Infrastrutturali SAP

SAP

Present.

Oracle 10. .2.0.1

Back-End

DB

Back - End




PAGINA 47 DI 61

SAP_APPL 500

EA-IPPE 300

EA-RETAIL 500

EA-PS 500

EA-HR 500

EA-GLTRADE 500

EA-FINSERV 500

EA-DFPS 500

EA-APPL 500

ST-A/PI 01I_ECC500

8.28.28.28.2 SistemaSistemaSistemaSistema Reporting (Netweaver ’04S Reporting (Netweaver ’04S Reporting (Netweaver ’04S Reporting (Netweaver ’04S –––– BW BW BW BW 7777....0000))))

L’ambiente per la componente Business Warehouse prevede i seguenti componenti:


• WAS 7.00 (ABAP Stack): piattaforma applicativa ABAP di SAP Netweaver. Realizza

l’infrastruttura necessaria per lo sviluppo, il rilascio nonché l’esecuzione di tutte le applicazioni

Netweaver in tecnologia ABAP;

• SAP BW Business Content Add-On (BI_CONT 7.0.3): modulo aggiuntivo del WAS 7.00

ABAP che consente le funzionalità di Data Warehouse.

Il livello di patching per l’ambiente è SAP NETWEAVER 04S - SP Stack 15

Dettaglio componenti software:

Sistema di governance Versione

Database

ORACLE 10.2.0.2.0

Kernel

SAP Kernel 64 Bit SP159

Sap NW - Business Intelligence

SAP_ABA 700

SAP_BASIS 700

PI_BASIS 2005_1_700

SAP_BW 700




PAGINA 48 DI 61

8.38.38.38.3 Solution Solution Solution Solution ManagerManagerManagerManager e Solution Manager Diagnostics (Netweaver ’04s e Solution Manager Diagnostics (Netweaver ’04s e Solution Manager Diagnostics (Netweaver ’04s e Solution Manager Diagnostics (Netweaver ’04s –––– SM 4.0) SM 4.0) SM 4.0) SM 4.0)

Il sottosistema SIBEAR riusa il Solution Manager adottato nel sottosistema SIBAR.

8.48.48.48.4 DOCEBODOCEBODOCEBODOCEBO

La piattaforma e-learning utilizza un’infrastruttura software completamente open source e prevede i

seguenti prodotti:

• Docebo - versione 3.5.0.4, piattaforma e-learning open source;

• My-SQL versione 5.0, RDBMS open source, come back end per i dati della piattaforma.




PAGINA 49 DI 61

9999 Architettura esecutivaArchitettura esecutivaArchitettura esecutivaArchitettura esecutiva

L’architettura esecutiva descrive la piattaforma SIBEAR dal punto di vista delle componenti

infrastrutturali e della loro integrazione:

• Piattaforma infrastrutturale (infrastruttura hardware, infrastruttura di rete, infrastruttura di

storage);

• Architettura di sicurezza;

• Architettura d’integrazione.

Il sottosistema SIBEAR riusa parte delle componenti del sottosistema SIBAR. Molteplici aspetti legati

all’architettura esecutiva sono pertanto ereditati da SIBAR.

9.19.19.19.1 Piattaforma infrastrutturalePiattaforma infrastrutturalePiattaforma infrastrutturalePiattaforma infrastrutturale

La piattaforma infrastrutturale per la componente del SCI (sistema contabile integrato) del

sottosistema SIBEAR, è composta integralmente da Hardware SUN completamente ridondato. Per il

sistema di governance è stato riutilizzato l’hardware di SIBAR dedicato ai sistemi Business

dataWarehouse (BW) di SAP.

L’hardware del SIBEAR è stato inserito all’interno dell’infrastruttura di rete del sottosistema SIBAR,

mediante opportune integrazioni, anche al fine di estendere e garantire gli stessi livelli di sicurezza sia

interni che esterni.

9.1.19.1.19.1.19.1.1 InfrastruttInfrastruttInfrastruttInfrastruttura Hardwareura Hardwareura Hardwareura Hardware

Area

SIBEAR Descrizione Caratteristiche Quantità Cluster

B.E. SAP ERP-PRD T5220 – 6core 1.2Ghz / 16GB

RAM /2 x 146 Gb HDD 2 SI

Sviluppo ERP-DEV T5120 6core 1.2Ghz / 8GB

RAM/ 2x 146Gb HDD 1 NO

Test ERP-TEST T5120 6core 1.2Ghz / 8GB

RAM/ 2x 146Gb HDD 1 NO

FAD FAD X4150 Quad-Core Intel Xeon

4 x 146GB HDD 1 NO

Il sottosistema di storage, anch’esso costituito da macchine SUN, è costituito da una Storage Area

Network collegata in Fiber Channel alle macchine. La rete in fibra è gestita da due switch ottici Qlogic

5600. Il sottosistema di backup prevede il riuso del sottosistema di back del SIBAR.

9.1.29.1.29.1.29.1.2 Infrastruttura di reteInfrastruttura di reteInfrastruttura di reteInfrastruttura di rete

L’architettura del sottosistema SIBEAR è installata all’interno dell’infrastruttura di rete del CED

Regionale ed è stata realizzata per essere un’estensione della rete attualmente presente su SIBAR

Figura 24.




PAGINA 50 DI 61

Figura 24: Infrastruttura di rete

Il Firewall costituisce il punto d’accesso al sottosistema SIBEAR dall’esterno, intendendo per “esterno”

la rete degli uffici regionali. Sul firewall sono terminate le reti dei proxy server, ovvero dei sap router,

nonché le reti di backup, le quali sono ruotate verso il server di backup dall’infrastruttura.

Le reti di backend, in cui girano i servizi, sono ruotate direttamente sui Cisco Catalyst 4506 CoreSBR,

a cui sono attestate le reti di management dei sistemi e degli apparati di rete.

Le reti implementate per il sottosistema SIBEAR sono:

• LAN per i sistemi di sviluppo e test (Server e Pc Client). Zona destinata alla presenza di

server per lo sviluppo, per il test dei prodotti software e dei servizi di futura implementazione in

produzione. E’ previsto l’accesso in modalità VPN, per i Pc Client degli sviluppatori. Tale rete

ha come gateway una interfaccia del firewall.

• Back End di SAP- ERP, in cui sono posizionati i componenti SAP e le istanze dei database

di SAP:

• Back End ERP: rete di Backup dei sistemi di produzione, Sviluppo e Test.

• L’indirizzamento delle diverse istanze del sistema di governance è basato per intero su quello

definito per il sottosistema SIBAR.

Le seconde interfacce dei server, smisteranno il traffico alla rete di Backup con indirizzamento esterno

rispetto all’ambiente SIBEAR dove risiede il server di Backup connesso con la Tape Library SUN L500

tramite connettività ottica. Il sottosistema SIBEAR prevede l’integrazione di due moduli aggiuntivi per

gli apparati Cisco Catalyst 4506. Nel tabella seguente il dettaglio delle componenti di rete:




PAGINA 51 DI 61

Codice Descrizione Quantità

G0505-WS-

X4448GBRJ4 CATALYST 4500 48-Port 10/100/1000 Module 2

9.1.39.1.39.1.39.1.3 Accesso in VPNAccesso in VPNAccesso in VPNAccesso in VPN

L’accesso in VPN ai sistemi del sottosistema SIBEAR viene garantito dal Firewall ed è in gestione alla

RAS (attraverso la propria società in-house).

Le caratteristiche della VPN sono le seguenti:

• l’utente stabilisce una connessione tramite IPSEC o PPTP verso il firewall; fornisce quindi le

credenziali in proprio possesso e ottiene accesso e visibilità/servizi per i quali è abilitato;

• ogni utente ha un IP univoco e sempre uguale per tutte le connessioni, fino a quando è

abilitato all’accesso in VPN. L’IP assegnato in fase di setup dell’account, viene estratto da una

rete esterna a SIBEAR. È disponibile la mappa dettagliata delle coppie username-indirizzo IP

degli utenti legati al sottosistema SIBEAR.

La creazione, la modifica e l’eliminazione delle credenziali di uno specifico utente, nonché le modalità

di autenticazione e i sistemi coinvolti in essa sono a carico della RAS.

9.1.49.1.49.1.49.1.4 Infrastruttura SAN e backupInfrastruttura SAN e backupInfrastruttura SAN e backupInfrastruttura SAN e backup

L’infrastruttura di storage è configurata con modalità RAID 5 ed impiega 16 dischi da 300 GB. Lo

storage esterno è utilizzato da tutti i server SIBEAR attraverso un collegamento in Fiber Channel. I

server dedicati al sistema di governance riutilizzano l’infrastruttura di storage di SIBAR.

La tabella seguente descrive le componenti di storage e di backup prevista per il sottosistema

SIBEAR.

Area Descrizione Caratteristiche Quantità

Storage Storage Area Network Sun StorageTek (tm) 6140, 16

* 300GB 15Krpm 4Gb 1

Switch Ottici Switch Ottici QLogic 5600 FC Switch 8P 2

Backup Tape Library 20 Cassette 1

I server SIBEAR adottano l’infrastruttura di backup di SIBAR, la cui gestione è affidata alla RAS

(mediante la propria società in house). Nei server ERP del sottosistema SIBEAR sono istallati i client

di backup, mentre la componente BW, essendo parte dell’architettura del sottosistema SIBAR, adotta i

client precedentemente installati sui previa riconfigurazione.




PAGINA 52 DI 61

9.29.29.29.2 Architettura di sicurezza Architettura di sicurezza Architettura di sicurezza Architettura di sicurezza

L’architettura di sicurezza del sottosistema SIBEAR è basata su quella del sottosistema SIBAR.

9.2.19.2.19.2.19.2.1 Sicurezza InfrastrutturaleSicurezza InfrastrutturaleSicurezza InfrastrutturaleSicurezza Infrastrutturale

La sicurezza infrastrutturale è garantita dall’attuale struttura del CED, in cui l’infrastruttura SIBEAR è

ospitata. In questo contesto, sono garantite direttamente dal personale della Regione e della sua

società in house, le politiche relative a sicurezza perimetrale e accesso a livello di infrastruttura

hardware e di rete.

9.2.29.2.29.2.29.2.2 Accesso ed AutenticazioneAccesso ed AutenticazioneAccesso ed AutenticazioneAccesso ed Autenticazione

L’architettura per implementare il processo di Autenticazione, prevede l’utilizzo di un meccanismo di

“autenticazione esterna” basata su verifica di credenziali costituiti da Username e Password.

L’autenticazione degli utenti che accedono via applicazione client SAPGUI alla componente di

backend SAP avviene mediante scambio di credenziali (username e password) tra il client ed il

componente di autenticazione presente su SAP.

9.2.2.19.2.2.19.2.2.19.2.2.1 Profili e processo di autorizzazione sui sistemi SAP di backProfili e processo di autorizzazione sui sistemi SAP di backProfili e processo di autorizzazione sui sistemi SAP di backProfili e processo di autorizzazione sui sistemi SAP di back----endendendend

Il profilo autorizzativo è l’insieme delle abilitazioni necessarie ad un utente per poter avere accesso e

operare sui sistemi di back-end, dal punto di vista delle operazioni consentite all’interno di applicazioni

e privilegi su set di informazioni. Gli utenti che possono operare con SAP (mediante client GUI),

devono essere associati ad almeno un profilo autorizzativo, poiché le funzionalità fruibili tramite GUI

utilizzano risorse relative a componenti di back-end (ERP o BW).

La definizione dei profili autorizzativi e dell’associazione utenti-profili autorizzativi sono gestiti

all’interno dei sistemi di back-end con specifici strumenti di amministrazione di SAP.




PAGINA 53 DI 61

10101010 Architettura di sviluppoArchitettura di sviluppoArchitettura di sviluppoArchitettura di sviluppo

L’architettura di sviluppo prevede la definizione di tutti i sistemi di sviluppo utilizzati sul sottosistema

SIBEAR in funzione delle due area di riferimento SCI – Contabilità (ERP) e GOV – Governance (BW).

10.110.110.110.1 Landscape progettualeLandscape progettualeLandscape progettualeLandscape progettuale

Il presente paragrafo definisce gli ambienti per la gestione dell’intero ciclo di vita della soluzione per le

aree funzionali del SCI e del sistema di governance. In particolare, sono presenti tre ambienti:

Ambiente di Sviluppo

Ambiente predisposto per lo sviluppo, il test unitario e la realizzazione dei build ufficiali dei componenti

software nel sottosistema SIBEAR.

Ambiente di Test

Ambiente per le attività di test e collaudo dell’intero sistema. L’ambiente è costruito con finalità di

supportare l’esecuzione parallela delle sessioni di test integrato da parte del gruppo di lavoro e di

collaudo funzionale; ciò al fine di consentire alla RAS l’esecuzione diretta dei i casi di test, progettati al

fine di certificare la corrispondenza funzionale del sistema rilasciato. Il sistema può essere infine

utilizzato per la simulazione della conversione iniziale dei dati prima dell’effettiva esecuzione in

produzione.

Ambiente di Produzione

Ambiente che ospita la soluzione finale in esercizio.

Figura 25 – Ambienti di progetto

Sviluppo Sviluppo

110 ARPAS

120 EFDS

130 ARGEA

140 ARASE

150 LAORE

160 AGRIS

SviluppoTest

110 ARPAS

120 EFDS

130 ARGEA

140 ARASE

150 LAORE

160 AGRIS

SviluppoProduzione

110 ARPAS

120 EFDS

130 ARGEA

140 ARASE

150 LAORE

160 AGRIS




PAGINA 54 DI 61

10.1.110.1.110.1.110.1.1 ConfigurazioneConfigurazioneConfigurazioneConfigurazione degli degli degli degli ambienti ambienti ambienti ambienti

Gli applicativi SAP basati sull’application server ABAP consentono attraverso la definizione dei

mandanti di separare in modo logico e all’interno dello stesso sistema numerosi ambienti. Nel

presente paragrafo viene illustrata, per ciascuno dei tre ambienti descritti in precedenza, la

configurazione dei mandanti prevista.

10.1.1.110.1.1.110.1.1.110.1.1.1 SviluppoSviluppoSviluppoSviluppo

Sistema ERP/HR (mySAP ERP 2004 – ECC 5.0)

L’ambiente di sviluppo ECC 5.0 è caratterizzato dalla seguente configurazione di mandanti:

MASTER MANDANTI 110,120,130,140,150,160,170

I mandanti sono utilizzati come master delle configurazioni client dependent per i 7 Enti ed Agenzie e

nello specifico:

110 ARPAS;

120 EFDS;

130 ARGEA;

140 ARASE;

150 LAORE;

160 AGRIS;

170 Sardegna Promozione.

Le configurazioni realizzate nel MASTER 110 possono essere trasportate, tramite Client Copy sul

mandante 200 di WORKBENCH per il test unitario. In tali mandanti sono permesse le modifiche al

"Customizing Client Dependent" con registrazione automatica, mentre non sono consentite modifiche

al "Repository e Customizing valido per più mandanti".

WORKBENCH 200

Tale mandante consente sia lo Sviluppo per Abap e customizing client independent sia il Test unitario.

Il mandante WORKBENCH può essere allineato su richiesta tramite Client Copy dal mandante 110 - il

profilo utilizzato per la copia è SAP_APPL (customizing e dati applicativi). Non sono permesse

modifiche al "Customizing Client Dependent", mentre sono consentite modifiche al "Repository e

Customizing valido per più mandanti".




PAGINA 55 DI 61

Sistema Reporting (Netweaver ’04S – BW 7.0)

Il sistema SAP BW è definito come entità “sovramandante”; nonostante tecnicamente permanga il


MASTER 100

Tale ambiente è finalizzato prevalentemente alle attività di configurazione/customizing, sviluppo e unit

test di oggetti di Workbench, prototipazione e sperimentazione. È impiegato come mandante Master di

consolidamento del customizing per le successive fasi di trasporto negli altri ambienti. La

configurazione (setting) di questo mandante comporta l’obbligatorietà di registrazione all’interno di

Change Request del customizing e dello sviluppo, per il successivo trasporto verso gli altri ambienti

definiti nel landscape.

10.1.1.210.1.1.210.1.1.210.1.1.2 TestTestTestTest

L’ambiente di test è definito in modo da permettere l’esecuzione delle sessioni di test integrato da

parte del gruppo di lavoro e di collaudo funzionale da parte del cliente.


L’ambiente di test ECC 5.0 è caratterizzato dalla seguente configurazione di mandanti:

Test 110,120,130,140,150,160,170

I mandanti dal 110 al 170 sono impiegati per le attività di test ( System e Integration ) della

configurazione e degli sviluppi realizzati per ciascun singolo Ente ed Agenzia. All’interno dei mandanti

non sono permesse modifiche al customizing o workbench, ma queste devono provenire dalle Change

Request rilasciate dal sistema di sviluppo. Esso contiene i dati anagrafici e transazionali di prova,

caricati per le attività di test.

Sistema Reporting (Netweaver ’04S – BW 7.0)

Il sistema SAP BW è definito come entità “sovra mandante”; nonostante tecnicamente permanga il


Test 100

Tale ambiente dedicato alle attività di test di sistema, di integrazione, di collaudo delle funzionalità

realizzate nel mandante Master di sviluppo; esso utilizzato anche per l’addestramento agli utenti.

All’interno del mandante non sono permesse modifiche al customizing o wokbench, ma queste





PAGINA 56 DI 61

10.1.1.310.1.1.310.1.1.310.1.1.3 PrPrPrProduzioneoduzioneoduzioneoduzione

Tale ambiente consente l’esercizio delle applicazioni, contiene i dati degli Enti ed Agenzie ed è

l’ambiente dove vengono eseguiti i reali processi di business.


All’interno dell’ambiente di Produzione sono definiti 7 mandanti, uno per ciascun Ente ed Agenzia.

Esercizio 110,120,130,140,150,160,170

Utilizzato dagli utenti per l’esercizio delle applicazioni, contiene i dati anagrafici e transazionali effettivi.

All’interno del mandante non sono consentite modifiche al customizing o Workbench, ma queste

devono provenire dalle Change Request rilasciate dal Sistema di sviluppo, e che hanno superato il

collaudo nel Sistema di Test.

Sistema Reporting (Netweaver ’04 SR1 – BW 3.5)

Il landscape applicativo prevede l’installazione e la configurazione di un unico mandante.

Esercizio 100

Il mandante da definire all’interno dell’istanza di produzione è utilizzato dagli utenti finali per

l’esecuzione dei reali processi di business. All’interno del mandante non sono permesse modifiche al

customizing o workbench, ma queste devono provenire dalle Change Request rilasciate dal sistema di

sviluppo, e che hanno superato il collaudo nel sistema di test.




PAGINA 57 DI 61

10.210.210.210.2 Strumenti di sviluppoStrumenti di sviluppoStrumenti di sviluppoStrumenti di sviluppo

Nel seguito sono decritti, per ciascun software previsto nell’architettura applicativa del sottosistema

SIBEAR, le tipologie di componenti software prodotti e gli strumenti a supporto per le attività di

sviluppo.

10.2.110.2.110.2.110.2.1 Sistema ERP/HR (mySAP ERP 2004 Sistema ERP/HR (mySAP ERP 2004 Sistema ERP/HR (mySAP ERP 2004 Sistema ERP/HR (mySAP ERP 2004 –––– ECC 5.0) ECC 5.0) ECC 5.0) ECC 5.0)

Le attività di sviluppo sul back end mySAP ERP 2004 consistono principalmente in:

• configurazione delle funzionalità standard fornite dal package in modo da adattarle ai requisiti

del cliente (“customizing”); in questo caso la Guida di Implementazione (IMG –

Implementation Guide) consente di effettuare le attività di customizing necessarie

• sviluppo di componenti ulteriori per quelle funzionalità non coperte dal pacchetto; in questo

caso il software, oltre a fornire l’ambiente di run-time per l’applicazione, mette a disposizione

un framework per lo sviluppo, che può essere utilizzato l’estensione di oggetti già esistenti o la

creazione di nuovi.

Lo sviluppo del SIBEAR sul SAP back-end prevede:

• Oggetti del Dictionary (Tabelle, Strutture, View etc.), per l’implementazione del data layer;

• Report, Function e BAPI (Business API), per l’implementazione dell’application layer;

• Screen, per gestire il lato di presentazione.

Lo sviluppo sul back-end SAP non prevede l’installazione e l’utilizzo di particolari applicazioni se non il

client di accesso (SAPgui). Gli strumenti per sviluppare oggetti sul sistema di back-end, così come le

funzionalità applicative, sono forniti via transazione: mediante il logon al sistema si hanno a

disposizione tutte le applicazioni e i tool necessari alla creazione ed implementazione di oggetti

custom.


L’attività di sviluppo in ambito BW consiste nella modellazione degli oggetti e delle regole necessarie

per il trasporto, l’elaborazione e l’analisi dei dati. Mediante l’Administrator Workbench, accessibile via

client sapgui (transazione RSA1), è possibile modellare tutti gli oggetti relativi ai vari flussi, iniziando

dalla Persistent Staging Area (PSA), in cui i dati ricevuti dai sistemi alimentanti sono memorizzati in

formato non modificato, fino ad arrivare agli InfoProviders su cui è possibile costruire le query

necessarie per il reporting.

Lo strumento Query Designer, parte integrante della suite Business Explorer (BEx) consente lo

sviluppo di query per l’accesso alle informazioni presenti sul sistema BW; esso necessita

dell’installazione del BW add-on sulla sul client della SAPGUI.




PAGINA 58 DI 61

10.310.310.310.3 Software logisticsSoftware logisticsSoftware logisticsSoftware logistics

Nel seguito sono descritte la modalità con cui le configurazioni applicative e gli sviluppi effettuati

vengono gestiti e propagati ai diversi stadi del landscape progettuale. Per i singoli componenti

applicativi è presentato lo scenario progettuale di allineamento.

10.3.110.3.110.3.110.3.1 Sistema ERP (mySAP ERP 2004 Sistema ERP (mySAP ERP 2004 Sistema ERP (mySAP ERP 2004 Sistema ERP (mySAP ERP 2004 –––– ECC 5. ECC 5. ECC 5. ECC 5.0)0)0)0)

L’ambiente di sviluppo è configurato con 8 mandanti:

i mandanti dal 110 al 170 sono dedicati alle attività di personalizzazione (customizing) specifiche di

ciascun Ente/Agenzia;

il mandante 200 è dedicato a tutte le attività di sviluppo inframandante ovvero alle attività di sviluppo di

nuovi programmi.

Le configurazioni e gli sviluppi eseguiti in ambiente di sviluppo sono registrati automaticamente

all’interno delle change request (CR). Sli allineamenti possono essere solo tra mandanti omologhi su

istanze diverse come dettagliato nella figura che segue, con l’eccezione del mandate 200. Gli

allineamenti sono realizzati con il Trasporto di Change Request fra le istanze del Landscape.

Figura 26 – Allineamento sistemi mySAP ERP

My SAP ERP 2004

110 ARPAS

120 EFDS

150 LAORE

Trasporto change request Client Copy

Sviluppo

200 Workbench

130 ARGEA

140 ARASE

160 AGRIS

170 Sardegna Digitale

110 ARPAS

120 EFDS

150 LAORE

Test Collaudo

130 ARGEA

140 ARASE

160 AGRIS


110 ARPAS

120 EFDS

150 LAORE

Produzione

130 ARGEA

140 ARASE

160 AGRIS





PAGINA 59 DI 61

Lo strumento previsto per la gestione degli allineamenti è “Transport Management System” di SAP,

integrato nella soluzione.


Le istanze di BW sono caratterizzate da un unico mandante. Perciò gli allineamenti avvengono

mediante trasporto di change request fra le istanze del landscape. Il tool previsto per la gestione degli

allineamenti è “Transport Management System” di SAP, integrato nella soluzione.

Figura 27 – Allineamento sistemi BW

BW

100 Master

Produzione Produzione

100 Test -

Collaudo 100 Esercizio


Sviluppo Test




PAGINA 60 DI 61

11111111 Architettura operativaArchitettura operativaArchitettura operativaArchitettura operativa

Nel seguito sono esposte le modalità di gestione dell’infrastruttura hardware e software di SIBEAR sia

dal punto di vista infrastrutturale/sistemistico che dal punto di vista applicativo.

11.111.111.111.1 Gestione sito fisicoGestione sito fisicoGestione sito fisicoGestione sito fisico

Il sito fisico è gestito direttamente dal personale del CED Regionale.

11.211.211.211.2 Gestione sicurezzaGestione sicurezzaGestione sicurezzaGestione sicurezza

La sicurezza perimetrale e di accesso all’infrastruttura hardware e di rete è gestita dal personale della

società in house della RAS.

11.311.311.311.3 Gestione sistemisticaGestione sistemisticaGestione sistemisticaGestione sistemistica

La gestione sistemistica delle del sottosistema del SIBEAR è affidata alla società in house della RAS.

11.411.411.411.4 Gestione diGestione diGestione diGestione disponibilità ambientisponibilità ambientisponibilità ambientisponibilità ambienti

11.4.111.4.111.4.111.4.1 Infrastruttura backupInfrastruttura backupInfrastruttura backupInfrastruttura backup

Per l’infrastruttura di backup viene riutilizzata l’architettura presente su SIBAR che è costituita da un

backup server connesso tramite fiber-channel alla tape library L500, costituita da 2 drive dal troughput

di 80Mpbs/drive e 100 cartridge.

Il server di backup è posto in una rete esterna all’indirizzamento SIBEAR, attestata su apparati della

società in house della RAS; il routing verso l’ambiente SIBEAR è a cura del firewall. I backup, tanto

dell’ambiente SIBEAR quanto degli altri ambienti, sono programmati in modo da evitare il più possibile

il degrado dell’erogazione dei servizi durante le business hour. L’ambiente di protezione dei dati è

basato principalmente sul software di gestione Sun StorEdge Enterprise Backup (ovvero

EMC2/Legato NetWorker nella versione OEM Sun).

L’intera gestione dell’infrastruttura di backup, sia in termini di backup degli applicativi che restore degli

stessi è affidata alla società in house della RAS.

11.4.211.4.211.4.211.4.2 Failover e HAFailover e HAFailover e HAFailover e HA

La continuità di tutti i servizi è garantita da idonee soluzioni tecnologiche applicate ai diversi livelli

dell’infrastruttura IT.

A livello network, la gestione del failover e la continuità di servizio sono garantiti da una ridondanza

fisica tanto degli apparati quanto dei cablaggi. Sono presenti due switch multilayer di aggregazione

configurati in modalità active-standby e la continuità dell’erogazione è garantita dal sistema in standby

che entra in servizio quando la macchina attiva dovesse subire dei failure. Per evitare discontinuità di

servizio dovute a fail delle schede di rete dei server o delle porte degli switch, ogni server in

produzione ha una doppia interfaccia per ogni rete e tale interfacce sono connesse ciascuna ad un

apparato. La ridondanza della connettività verso l’intranet RAS e verso Internet è garantita da un

doppio collegamento in gigabit ethernet verso gli switch di uplink messi a disposizione dal C.E.D.




PAGINA 61 DI 61

A livello applicativo, l’alta affidabilità per il servizio “sap router” è garantita dalla coppia di load

balancer, in configurazione active-standby. Tutti gli IP virtuali sono configurati in modo da verificare la

corretta funzionalità del servizio (health check) prima di inoltrare la connessione al server scelto

dall’algoritmo di bilanciamento, in modo da escludere dall’erogazione le macchine che risultassero

fuori servizio dal punto di vista applicativo e/o sistemistico.

I servizi ERP e BW sono stati implementati su due differenti coppie di server che utilizzano il prodotto

SUN Cluster che garantisce elevate caratteristiche di affidabilità e robustezza, assicurando la

continuità di erogazione dei servizi, grazie al bilanciamento delle risorse nel caso di mancato

funzionamento di uno dei server.

procedura aperta per la gestione, manutenzione, e supporto al change management del ... ·...

Documents