SIBEAR SIBEAR DESCRIZIONE TECNICA DEL SISTEMA SIBAR-SIBEAR APPROVATO CON DETERMINAZIONE REPUBBLICA ITALIANA UNIONE EUROPEA

Transcript

1 UNIONE EUROPEA REPUBBLICA ITALIANA Direzione Generale degli Affari Generali e Riforma della Regione Servizio per il sistema informativo di 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 DESCRIZIONE TECNICA DEL SISTEMA SIBAR-SIBEAR SIBEAR APPROVATO CON DETERMINAZIONE N. 334/AA.GG. DEL 15/05/ /05/2009

2 Indice 1 Premessa Descrizione del sottosistema SIBAR Architettura applicativa Portale (Netweaver 04 SR1 Enterprise Portal) ERP/HR (mysap ERP 2004 componenti stack ABAP) ERP/HR (mysap ERP 2004 componenti stack JAVA) Sistema di Reporting (Netweaver 04 SR1 BW 3.5) Solution Manager e Solution Manager Diagnostics (Netweaver 04s SM 4.0) Content Management System (EMC Documentum v.5.3) Sistema di OCR (Kofax Ascent Capture Vers. 7) Sistema per la Rilevazione delle presenze (Selewin) RDBMS (Oracle 10 g) Access Manager (Sun Java System Access Manager) Proxy Server Architettura esecutiva Piattaforma Infrastrutturale Infrastruttura hardware Infrastruttura di rete Infrastruttura SAN Architettura di sicurezza Sicurezza infrastrutturale Accesso ed autenticazione Autorizzazione e profilazione degli utenti Architettura di integrazione Architettura di sviluppo Ambienti di sviluppo Portal & Content Management (SB) Landscape progettuale Livelli del landscape Configurazione ambienti Strumenti di sviluppo Sistema ERP/HR (mysap ERP 2004 ECC 5.0) Sistema Reporting (Netweaver 04 SR1 BW 3.5) Portale (Netweaver 04 SR1 Enterprise Portal) Software logistics Sistema ERP/HR (mysap ERP 2004 ECC 5.0) Sistema Reporting (Netweaver 04 SR1 BW 3.5) Portale (Netweaver 04 SR1 Enterprise Portal) Architettura operativa Gestione sito fisico Gestione sicurezza Gestione sistemistica Sistemi di base (HW, SO, DB) Gestione disponibilità ambienti Infrastruttura backup Failover e HA Descrizione del sotto-sistema SIBEAR Architettura applicativa ERP (mysap ERP 2004 componenti stack ABAP) Sistema Reporting (Netweaver 04S BW 7.0) Solution Manager e Solution Manager Diagnostics (Netweaver 04s SM 4.0) DOCEBO Architettura esecutiva Piattaforma infrastrutturale Infrastruttura Hardware Infrastruttura di rete Accesso in VPN Infrastruttura SAN e backup Architettura di sicurezza PAGINA 2 DI 61

3 9.2.1 Sicurezza Infrastrutturale Accesso ed Autenticazione Architettura di sviluppo Landscape progettuale Configurazione degli ambienti Strumenti di sviluppo Sistema ERP/HR (mysap ERP 2004 ECC 5.0) Sistema Reporting (Netweaver 04 SR1 BW 3.5) Software logistics Sistema ERP (mysap ERP 2004 ECC 5.0) Sistema Reporting (Netweaver 04 SR1 BW 3.5) Architettura operativa Gestione sito fisico Gestione sicurezza Gestione sistemistica Gestione disponibilità ambienti Infrastruttura backup Failover e HA PAGINA 3 DI 61

4 1 Premessa 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 4 DI 61

5 2 Descrizione 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 5 DI 61

6 3 Architettura applicativa Il sottosistema SIBAR è strutturato in differenti aree applicative (Figura 1) Servizi SIBAR su Internet Servizi per Cittadini, Imprese ed Enti Locali Pratiche Online Portale Imprese Servizi Enti Locali Modulistica Sistemi Regione Sardegna Portale Regione Sardegna Integrazione Back Office Regionale Sistemi Esterni SIBAR - SB Protocollo Informatico Firma Digitale Gestione Documentale Workflow Procedimenti Business Process Management Banca d Italia (SIOPE) Interfacciamento SIBAR - SCI Contabilità Finanziaria Contabilità Economico Patrimoniale Contabilità Economico Analitica Gestione Cespiti Ministero del Tesoro Gestione Approvvigionamenti Controllo di Gestione Poste Italiane SIBAR - HR Banca Dati del Personale Fascicolo Elettronico Organizzazione Gestione Formazione Tesoreria Regionale Gestione della valutazione Gestione concorsi e selezioni Sistema Premiante Gestione FITQ Gestione carichi di lavoro Stipendi, ricalcoli e gestione fiscale Rilevazione Presenze Buoni pasto Enti Pubblici Regionali Missioni Portale del Personale Gestione Timbrature Relazioni sindacali Ministero Economia e Finanze Decision Support System integrato SIBAR Reportistica Data Warehouse Simulazione Tesoreria centrale dello Stato Figura 1: Architettura funzionale del sottosistema SIBAR 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; PAGINA 6 DI 61

7 Italdata 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 Figura 2: Piattaforme utilizzate per ciascuna area funzionale 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. PAGINA 7 DI 61

8 L architettura applicativa generale è mostrata in Figura 3. Nei paragrafi seguenti verrà descritto il dettaglio delle componenti software per ogni elemento della piattaforma applicativa. Presentation Web Access Control Front End Back End Data Layer Web Browser Apache Web Proxy SAP Enterprise Portal SAP ERP/HR Acis Kofax Oracle RDBMS SAPgui SJS Access Manager Apache Documentum Context Server CONGEXP Tomcat SAP BW Protoflow 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 3.1 Portale (Netweaver 04 SR1 Enterprise Portal) La soluzione Enterprise Portal è realizzata attraverso le seguenti componenti: Oracle : 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. Portale (SAP NetWeaver 04 SR1 BW 3.5) Database Oracle 9.2i 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 Figura 4: Dettaglio delle componenti software (Portale) PAGINA 8 DI 61

9 3.2 ERP/HR (mysap ERP 2004 componenti stack ABAP) La soluzione ERP è composta dai seguenti elementi: Oracle : database; WAS 6.40 (ABAP Stack): piattaforma applicativa ABAP di SAP Netweaver. Fornisce l infrastruttura per lo sviluppo, il rilascio e l esecuzione di le applicazioni Netweaver in 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. Sistema ERP/HR(mySAP ERP 04 ECC 5.0) Database Oracle 9.2i Kernel SAP KERNEL bit 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 Figura 5: Dettaglio delle componenti software (ERP/HR, stack ABAP) 3.3 ERP/HR (mysap ERP 2004 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: Oracle : 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; 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. PAGINA 9 DI 61

10 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. SAP XSS (Self Services) SAP J2EE ENGINE 6.40 SAP PCUI_GP 100 SAP ESS 100 SAP MSS 100 SP015 SP011 SP011 SP011 Figura 6: Dettaglio delle componenti software (XSS) 3.4 Sistema di Reporting (Netweaver 04 SR1 BW 3.5) L ambiente completo della soluzione di Business Warehouse è si compone di: Oracle : database WAS 6.40 (ABAP Stack): piattaforma applicativa ABAP di SAP Netweaver. Fornisce l infrastruttura per lo sviluppo, il rilascio e l esecuzione di le applicazioni Netweaver in 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. Sistema Reporting (SAP NetWeaver 04 SR1 BW 3.5) Database Oracle 9.2i Kernel SAP KERNEL bit 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 Figura 7: Dettaglio delle componenti software (Sistema Reporting) PAGINA 10 DI 61

11 3.5 Solution Manager e Solution Manager Diagnostics (Netweaver 04s SM 4.0) Il dettaglio delle componenti software è mostrato in Figura 8. Solution Manager (SAP NetWeaver 04s MS 4.0) Database Oracle 9.2i Kernel SAP KERNEL bit 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 Figura 8: Dettaglio delle componenti software (Solution Manager e Solution Manager Diagnostics) PAGINA 11 DI 61

12 3.6 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 : client e API di accesso a sistemi RDBMS Oracle; o JRE _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 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 12 DI 61

13 o o o o o o o o WebTop: client WDK per Documentum, realizzato come applicazione Web J2EE Documentum Administrator 5.3 SP2: applicazione web J2EE di amministrazione Documentum; Documentum Foundation Classes 5.3 SP2: API Javaper di Documentum; DMCL Libraries: librerie di comunicazione tra applicazione client e Documentum Content Server; Apache Tomcat : application server J2EE; Client Oracle : client e API di accesso a sistemi RDBMS Oracle; JVM (JRE 1.4.2_X - J2SE): virtual machine Java; 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 X 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.8 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 13 DI 61

14 3.9 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 : RDBMS; Cluster Solaris 3.1: servizio di clustering software; Solaris 10: sistema operativo 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 Q4: server LDAP; Sun Java System Web Server Q4 SP5: server web; J2SE platform 1.5.0_04: Piattaforma java standard edition; Solaris 10: sistema operativo Proxy 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; Solaris 10: sistema operativo. La Figura 9 mostra l architettura applicativa nel suo insieme. Presentation Front - End Back - End SAP Portal & Content Management Client Utente SapGui 640 Web Browser Client Utente Esterno Web Browser IAM Apache Proxy Server LDAP Rilevazione Presenze SelWin Sistema ERP/HR Was Abap 640 ECC 5.0 Abap Schema Reporting /simul. Was Abap 640 BI Cont 353 Abap Schema Portale / XSS Was Java 640 Portal Platf. 6.0 BP - ESS 60.2 BP - MSS 60.3 XSS 500 J2EE Schema Back - End DB Oracle S L D Content Server 5.3 SP2 (DMCL, DFC) WDK Kit 5.3 SP2 Docapp Site Caching Services DOCBroker Index Server Oracle Client D.T.S. 5.3 SP2 JRE Webtop DMCL Libraries Italdata Prot@Flow vers. 2 Documentum Administrator 5.3 SP2 Foundation Classes 5.3 SP2 Tomcat Content Services SAP for Acis kofax Applicazioni Infrastrutturali SAP Solution Mgr & Diagnostic 700 Saprouter Was Abap 700 Sol Mgr Was Java 700 Abap Schema J2EE Schema Figura 9: Architettura applicativa nel dettaglio PAGINA 14 DI 61

15 4 Architettura 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.1 Piattaforma 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 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 Infrastruttura hardware L architettura hardware è mostrata in Figura 10. Nel dettaglio, essa è costituita da 18 Sun Fire T Sun Fire X4200 con processori AMD Opteron 1 Sun Fire V20z con un processore AMD Opteron PAGINA 15 DI 61

16 Assessorato degli affari generali, personale person ale e riforma della Regione Direzione generale Load Balancer #1 Sun N1400 Load Balancer #2 Sun N X SunFire X4200 Selesta Selewin 2 X SunFire T2000 (8 Core/32 GB) SJS Access Manager Z1 2 X SunFire T2000 (4 Core/8 GB) Apache Web Proxy Server 2 X SunFire T2000 (8 Core/32 GB) Application Server Documentum Z2 Z1 Z1 Z1 Z1 Z1 Z2 Z1 Z1 Z2 Z3 2 X SunFire X4200 Acis Kofax Z2 Z2 Z1 Z2 Z2 Z1 Cluster SunFire T2000 (8 Core/32 GB) #1 & #2 SJS Access Manager 2 X SunFire T2000 (8 Core/32 GB) Web/Application Server Prot@Flow Z2 Z2 Sun Blade 150 Console 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 SunFire T2000 (8 Core/32 GB) Monitoring & Backup Server Z1 Z2 SVILUPPO Z3 SunFire T2000 (8 Core/32 GB) 4 X QLogic 5200 Z1 Z2 Z3 SunFire X4200 Z4 Sun Blade 150 Sun Tape Library 500 Z1 3 X StorEdge 6130 Z2 Z3 SunFire T2000 (8 Core/32 GB) 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 N FE 2 n.a. DMZ Intranet Selesta SeleWIN X4200 1x AMD/Opt. Mod 8 GB 4x 73GB 4 FE 2 NO B.E. Identity Management SJS Access manager Application Server Content Management Content Server Documentum T2000 8core 1.2GHz US-T1 32GB 4x 73GB 6 FE 2 FC 2 NO T core 1.2GHz US-T1 32 GB 4x 73GB 6 FE 2 FC 2 NO T core 1.2GHz US-T1 32 GB 4x 73GB 6 FE 2 FC 2 NO 2 NO 2 NO B.E. Content management B.E. Content management B.E. Content management B.E. Content management Acis Kofax Sap Connector X4200 2x AMD/Opt. Mod 16 GB 73GB 4 FE 2 FC X4200 2x AMD/Opt. Mod 16 GB 73GB 4 FE SIBAR-SIBEAR PAGINA 16 DI 61 4x 4x

17 B.E. SAP SAP ERP/HR T core 1.2GHz US-T1 32 GB 4x 73GB 6 FE 2 FC 2 SI B.E. SAP SAP BW/ EP T core 1.2GHz US-T1 32 GB 4x 73GB 6 FE 2 FC 2 SI B.E. DataBase Oracle T core 1.2GHz US-T1 32 GB 4x 73GB 6 FE 2 FC 2 SI Backup & Backup Server T core 1.2GHz US-T1 32 GB 4x 73GB 6 FE 2 FC 1 n.a Administration Backup & Administration Backup & Administration Backup & Administration Enterprise Manager T core 1.2GHz US-T1 8 GB 2x 73GB 1 n.a. Storage Manager V20z 1x AMD/Opt. Mod GB 1x 73GB 1 n.a. Management Console 650Mhz US-Iii 512 MB 1x 80GB 5 FE 2 NO Sviluppo SAP T core 1.2GHz US-T1 32 GB 4x 73GB 6 FE 2 FC 1 NO Sviluppo Portal & Content T core 1.2GHz US-T1 32 GB 4x 73GB 6 management FE 2 FC 1 NO Sviluppo Acis Kofax e Sap X4200 2x AMD/Opt. Mod 16 GB 4x Connector 73GB 4 FE 1 NO Switch per Cluster Switch Cisco Cisco Porte 2 n.a Infrastruttura 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 17 DI 61

18 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 18 DI 61

19 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 o Rete di BE di Identity Management, in cui è presente l Access Manager per l autenticazione e l autorizzazione alle applicazioni web in SSO; 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 19 DI 61

20 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 20 DI 61

21 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-C AC Catalyst W 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 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 BRET-SC/SC-2 Bretella in F.O. 50/125 multimode SC/SC, MM da 2 m 2 S4KL3K EWA Cisco IOS BASIC L3 Cat4500 SUP2+/4/5,3DES(RIP,St.Rts,IPX,AT) 2 WS-G BASE-SX Short Wavelength GBIC (Multimode only) Bilanciamento 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 21 DI 61

22 Figura 13: struttura di bilanciamento a livello Accesso 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 Infrastruttura 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 SE x 146GB Network 10K rpm 3 Switch Ottici Switch Ottici Qlogic Backup Tape Library L500 2 Drive LTO3 e 100 Slots 1 PAGINA 22 DI 61

23 4.2 Architettura 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 Sicurezza infrastrutturale turale La sicurezza infrastrutturale è garantita dal CED regionale, attualmente in gestione alla società inhouse 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 Accesso 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 Architettura 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 23 DI 61

24 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 24 DI 61

25 Architettura di autenticazione per le altre applicazioni web Il meccanismo di autenticazione per le altre applicazioni web è identico a quello illustrato per Enterprise Portal Architettura di autenticazione per accessi via applicazioni ioni 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 Autorizzazione e profilazione one 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 Ruoli 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 utentigruppi 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 25 DI 61

26 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 Profili autorizzativi e processo di autorizzazione sui sistemi SAP di back-end 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 26 DI 61

27 Profili autorizzativi e processo di autorizzazione sui altri sistemi di back-end 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 Architettura di autorizzazione: 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 27 DI 61

28 4.3 Architettura 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 Figura 17: Architettura di Content Servicces for SAP 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. PAGINA 28 DI 61