Tesi_manfrin

UNIVERSITÀ DEGLI STUDI DI TRIESTE

An application to manage and automate common procedures in a server farm

LAUREANDO

RELATORE

Paolo Manfrin

Chiar.mo Prof. Alberto Bartoli

A.A. 2007/2008

Ringraziamenti

Desidero ringraziare quanti hanno contribuito alla mia formazione e alla realizzazione di questa tesi. In particolare ringrazio il Professor Bartoli Alberto per la revisione critica di questa tesi, tutto il Dipartimento di SAP Business One, i Team Leaders Valerie Maybin e Karen Martinez nonchè il Project Manager Aurelien Leblond. Ringrazio inoltre la Dott.ssa Mundt per i preziosi suggerimenti inerenti le basi dati di SAP Business One. Concludo ringraziando la mamma Gabriella, il papà Eligio e la nonna Maria per il sostegno durante l’intera carriera universitaria.

iii

Indice

1 Introduzione

1

2 Analisi 2.1 Descrizione del Problema . . . . . 2.1.1 Contesto Aziendale . . . . . 2.1.2 Overview Sistemi ed Entità 2.1.3 Pratica Interna . . . . . . . 2.1.4 Software Preesistente . . . . 2.2 Analisi del Problema . . . . . . . . 2.2.1 Definizione del Problema . . 2.3 Analisi dei Requisiti . . . . . . . . 2.3.1 Vincoli di progetto . . . . . 2.3.2 Casi d’uso . . . . . . . . . . 2.3.3 Planning delle attività . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

3 Progetto del Sistema 3.1 Moduli A e B: Generic Query . . . . . . . 3.1.1 Il canale di comunicazione . . . . . 3.1.2 Il Server Listener . . . . . . . . . . 3.1.3 La Base Dati . . . . . . . . . . . . 3.1.4 L’interfaccia Properties Framework 3.2 Modulo C: Backup Manager . . . . . . . . 3.2.1 La Procedura di Restore attuale . 3.2.2 Problemi Rilevati . . . . . . . . . . 3.2.3 Possibili Soluzioni . . . . . . . . . 3.2.4 Schema E-R Backup Manager . . . 3.3 Modulo D: Ridefinizione GSC Workflow . v

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

3 3 3 4 4 6 6 7 8 8 9 10

. . . . . . . . . . .

11 11 11 13 14 19 22 24 24 26 27 27

INDICE

vi

4 Implementazione 4.1 Moduli A e B . . . . . . . . . . . . . . . . . . . . . . . . . 4.1.1 Properties Framework . . . . . . . . . . . . . . . . 4.1.2 Gli oggetti serializzabili . . . . . . . . . . . . . . . 4.1.3 Server Listener . . . . . . . . . . . . . . . . . . . . 4.1.4 Schema Logico Database (Schema Properties) . . . 4.1.5 Stored Procedures . . . . . . . . . . . . . . . . . . 4.1.6 Indici . . . . . . . . . . . . . . . . . . . . . . . . . 4.1.7 Triggers e Jobs . . . . . . . . . . . . . . . . . . . . 4.1.8 Transazioni . . . . . . . . . . . . . . . . . . . . . . 4.1.9 IO Risultati da server . . . . . . . . . . . . . . . . 4.2 MODULO C . . . . . . . . . . . . . . . . . . . . . . . . . 4.2.1 Applicazione BackupManager . . . . . . . . . . . . 4.2.2 Shrink Distribuito . . . . . . . . . . . . . . . . . . 4.2.3 Schema Logico Database (Schema BackupManager) 4.3 MODULO D . . . . . . . . . . . . . . . . . . . . . . . . .

33 33 33 34 36 38 38 42 45 47 50 52 53 53 58 60

5 Risultati ottenuti 5.1 Moduli A e B . . . . . . . . . . . . . . . . . . . . . . . . . 5.2 Modulo C . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.3 Modulo D . . . . . . . . . . . . . . . . . . . . . . . . . . .

65 65 65 69

6 Conclusioni e Raccomandazioni 6.1 Miglioramenti moduli A e B . . . . . . . . . . . . . . . . . 6.2 Miglioramenti modulo C . . . . . . . . . . . . . . . . . . . 6.3 Considerazioni Finali . . . . . . . . . . . . . . . . . . . . .

71 71 72 72

A Raccolta Informazioni per la gestione query

73

B Elenco degli script realizzati

75

C Struttura base del Listener

79

D Setup dell’ambiente di test e sviluppo

81

E Interfacce Utente Applicativi

85

F Elenco dei server gestiti

91

Acronimi

95

Elenco delle figure

2.1 2.2 2.3

Business One Workflow . . . . . . . . . . . . . . . . . . . Business One System Overview . . . . . . . . . . . . . . . Use Case del Sistema . . . . . . . . . . . . . . . . . . . . .

3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8 3.9 3.10 3.11 3.12 3.13 3.14 3.15

Channel . . . . . . . . . . . . . . . . . . . . . Listener . . . . . . . . . . . . . . . . . . . . . Properties Framework . . . . . . . . . . . . . Modello di Accesso ai dati . . . . . . . . . . . Schema definiti nel database TEC . . . . . . . Modello E-R Schema Properties . . . . . . . . Servizi Offerti da Properties Framework . . . Numero database ripristinati su server . . . . Totale spazio annualmente allocato sui server TEC 3 - GUI Richiesta ticket . . . . . . . . . Snapshot Sequoia . . . . . . . . . . . . . . . . Overview Backup Manager . . . . . . . . . . Modello E-R Schema BackupManager . . . . Workflow Attuale . . . . . . . . . . . . . . . . Workflow Ridefinito . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

13 13 14 16 19 20 21 23 23 25 27 28 29 30 31

4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8 4.9 4.10

Interfaccia PropertiesFramework e sua implementazione Oggetti Serializzabili . . . . . . . . . . . . . . . . . . . . Servizi offerti dal Server Listener . . . . . . . . . . . . . Schema Logico DB (Schema Properties) . . . . . . . . . Stored Procedure GetRemoteQueryResult . . . . . . . . Stored Procedure GetSavedQueryResult . . . . . . . . . Livelli di Isolamenteo [16] . . . . . . . . . . . . . . . . . Interfaccia con la Base Dati per Backup Manager . . . . Interfacce e Implementazioni per Backup Manager . . . Schema Logico DB (Schema BackupManager) . . . . . .

. . . . . . . . . .

35 37 39 40 42 43 47 53 54 59

vii

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

4 5 9

viii

ELENCO DELLE FIGURE

4.11 Directories orfane . . . . . . . . . . . . . . . . . . . . . . . 4.12 DBs non associati a Tickets . . . . . . . . . . . . . . . . . 5.1 5.2 5.3 5.4 5.5

60 61

Snapshot Sequoia dopo lo shrink e l’eliminazione delle cartelle orfane 66 Database ripristinati (media mobile su 45 gg) . . . . . . . 67 Database cancellati (media mobile su 45 gg) . . . . . . . . 67 Guadagno di spazio (in %) sui server di backend . . . . . 68 Ticket richiesti e ripristini manuali . . . . . . . . . . . . . 69

D.1 Configurazione SSMS . . . . . . . . . . . . . . . . . . . . .

82

E.1 E.2 E.3 E.4 E.5 E.6

85 86 87 87 88 88

GUI GUI GUI GUI GUI GUI

QueryProcessor . . . ResultAnalyzer . . . ServerManager . . . AdminQueries . . . . DisplayQueriesPlugin IVUAutomation . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

Elenco delle tabelle

3.1 3.2 3.3 3.4

Tabella Tabella Tabella Tabella

Query . . Result . Batch . . Relazioni

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

18 18 18 20

4.1

Analisi delle Transazioni . . . . . . . . . . . . . . . . . . .

49

ix

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

Capitolo

1

Introduzione L’ottimizzazione delle risorse, la riduzione dei costi e l’aumento della capacità produttiva aziendale, sono di particolare interesse, specialmente in momenti di crisi economica come quello che stiamo vivendo in questi anni. Questa tesi è stata sviluppata presso il SAP Global Support Center di SAP Business One, in Irlanda, al fine di migliorare il processo di supporto fornito dai consulenti SAP durante le fasi di rilevamento e correzione dei malfunzionamenti sui database dei clienti. La tesi è stata sviluppata parallelamente alla attività di tirocinio di 6 mesi svolto a Galway, dedicata a prendere familiarità con il prodotto SAP Business One approfondendo in particolare i moduli Business Core (SBO-BC), Upgrade (SBO-BC-UPG) ed AddOn (SBO-BC-ADD) di SAP Business One. Il Global Support Center è composto da consulenti SAP con conoscenze specifiche relative all’ERP Sap Business One. Business One si basa su un database relazionale di elevata complessità, la cui struttura interna è descritta in [1]. Il Global Support Center offre supporto 24 x 7 a livello mondiale, risolvendo i malfunzionamenti sulla base dati in produzione presso i clienti SAP, che compromettono la produttività aziendale. I database aziendali possono essere trasferiti in uno dei server SAP localizzati in Germania, dove vengono ripristinati per condurre analisi off-line. I server SAP contengono tipicamente 1800 database. I problemi affrontati in questa tesi sono stati i seguenti: • semplificare la modalità con cui i consulenti si connettono alle base dati remote in Germania, dalle sedi in Irlanda, Israele, Slovacchia, Cina, India, e Canada ed eseguono query non note a priori, salvandone i risultati per analisi successive. 1

1. Introduzione

2

• fornire agli altri sviluppatori una interfaccia che consenta di automatizzare routine durante le procedure di backup, upgrade e ispezione dei database clienti • migliorare la gestione della server farm riducendo i crash di sistema che avvengono durante le operazioni di download e ripristino dei database clienti Alcuni dei moduli sviluppati fanno già parte dell’applicativo Test Environement Center 4.0, attualmente in fase di sviluppo dall’ SDK Team di SAP Business One. Altri verranno integrati in un secondo momento, una volta ultimata la fase di testing. Il nuovo applicativo, già in uso da alcuni consulenti pilota, andrà a sostituire il precedente nei prossimi mesi e verrà esteso a tutte le sedi di supporto di SAP Business One. Durante lo sviluppo della tesi, a stretto contatto con i consulenti SAP, si è inoltre evidenziato un possibile miglioramento produttivo raggiungibile modificando il workflow attualmente in essere. Tale modifica è stata proposta al SAP System Leader, il quale sta valutando le risorse da destinare alla implementazione della soluzione proposta. Per quanto concerne il raggiungimento degli obiettivi, i consulenti sono ora in grado di eseguire query, senza la necessità di ricorrere a MS Sql Server Management Studio come dovevano fare in precedenza, nella maggior parte dei casi. L’interfaccia software creata consente agli sviluppatori di interagire con le basi dati senza la necessità di conoscerne i dettagli come la localizzazione fisica sui server e le stringhe di connessione, consentendo loro di rimanere concentrati nei moduli che devono sviluppare. Le problematiche di cui soffriva la server farm sono state in parte risolte introducendo l’operazione di shrinking sui database e cambiando i parametri relativi alle stored procedures di eliminazione dei database. Gli applicativi software utilizzati sono stati Visual Studio 2005, Sql Server 2000, Sql Server 2005, Sql Profiler, Tortoise SVN per la gestione del versioning, Sequoia e SAP Business One. Il linguaggi di programmazione utilizzati sono stati C# e Sql. Il capitolo 2 inizia discutendo i problemi da risolvere, l’analisi dei requisiti ed i casi d’uso. Il capitolo 3 riporta il progetto del sistema e della base dati, seguito dal capitolo 4 in cui viene descritta l’implementazione del sistema. La trattazione continua con il capitolo 5 in cui vengono analizzati i risultati e si conclude nel capitolo 6 con la proposta di ulteriori miglioramenti.

Capitolo

2

Analisi 2.1

Descrizione del Problema

Per poter identificare le problematiche da risolvere è stato necessario comprendere chiaramente l’organizzazione aziendale e come i vari dipartimenti interagiscono tra loro. Tale analisi risulterà di particolare importanza specialmente per la fase di progettazione della base dati e la modifica del workflow.

2.1.1

Contesto Aziendale

Questo capitolo descrive come il Dipartimento di SAP Business One è organizzato per fornire supporto all’utente finale. Possiamo identificare 4 attori principali all’interno di Business One (B1): • L’Utente Finale: è una azienda che usa il prodotto SAP Business One come Enterprise Resource Planning (ERP) • Il partner SAP: è un rivenditore/consulente punto di contatto per il cliente. Quando un utente finale ha qualche problema con B1 contatta il partner il quale ha il compito di valutare il problema sollevato dal cliente • Il SAP Global Support Center (GSC): è una unità interna a SAP B1 che supporta i partner quando essi non sono in grado di risolvere un problema. Il partner in questo caso contatta il GSC per discutere la problematica incontrata dal cliente. Il GSC è diviso in differenti sezioni (System, Finance, Logistic, ...) ognuna delle quali offre supporto per differenti aree di B1. GSC offre supporto 24 x 7. Le sedi GSC sono situate in Irlanda (sede principale), Israele, Slovacchia, Cina, India e Canada. 3

4

2. Analisi

• L’ Install Base Development (IBD): IBD è il dipartimento più interno che ha il compito di correggere bugs e malfunzionamenti. GSC fa usi di Internal Notes che spiegano come affrontare e risolvere problematiche ricorrenti. Quando il GSC Consultant non è in grado di risolvere una problematica o scopre o sospetta un nuovo bug, egli lo inoltra in IBD per una analisi più approfondita. Una volta che il problema è risolto esso viene ritornato indietro nella catena dall’IBD al GSC, al Partner SAP e fino al cliente finale. Le interfacce sono di tipo 1-1 tra cliente finale e Partner SAP, Partner SAP e GSC, GSC e IBD come illustrato in figura 2.1. END CUSTOMER

SAP PARTNER

GSC

IBD

Figura 2.1: Business One Workflow

2.1.2

Overview Sistemi ed Entità

Nello schema di figura 2.2 sono presentati gli attori e i sistemi utilizzati. Più COMPANY-DB sono ripristinati sul medesimo TEC 1 server. Tutti i COMPANY-DB ripristinati sulla medesima istanza devono essere compatibili con l’SBO-COMMON di quella istanza. I server vengono mantenuti tramite le informazioni registrate nel database TEC Application Server. Il TEC Application Server è la base di informazioni per applicativo TEC. I consulenti GSC e IBD utilizzano sia Customer Support System New (CSN) 2 per il tracking del problema da risolvere che Test Environment Center (TEC) per il download e restore dei database dei clienti. I partner SAP hanno accesso esclusivamente al CSN per inserire messaggi e controllare lo stato di risoluzione.

2.1.3

Pratica Interna

Per meglio comprendere il resto della trattazione, vengono qui descritti i concetti principali circa la struttura di SAP Business One di particolare importanza per la definizione della base dati. 1 TEC: acronimo di Test Environment Center, l’applicativo utilizzato per ripristinare i database inviati dai Partner SAP, effettuare upgrade e salvare i backup. 2 CSN: Applicativo usato da Parner SAP, GSC ed IBD per comunicare e seguire l’evolvere della soluzione al problema inoltrato dal partner. Tutte le comunicazioni ufficiali, gli aggiornamenti, la proposta di soluzione e gli allegati vengono gestiti tramite tale applicativo.

5

Descrizione del Problema

GERMANY (WALLDORF)

WORLDWIDE

DOWNLOAD & RESTORE FTP Server

Patch Level (PL) Version (V) Db Type

COMPANY-DB

TEC Server

TEC Ticket

COMPANY-DB Patch Level (PL)

IBD

Version (V) Db Type

SBO-COMMON

TEC Appication Server

TEC Application CSN Message

GSC

TEC Server CSN Application

PARTNER SAP

Figura 2.2: Business One System Overview

Le frecce azzurre indicano gli applicativi utilizzati dall’IBD. Le frecce rosse indicano gli applicativi utilizzati dal GSC. La freccia nera individua l’applicativo utilizzato dal partner SAP. SAP Business One è un ERP per piccole medie aziende (fino a 100 clients) con architettura client/server 2 tiers. Tale architettura usa il presentation client per far eseguire la logica applicativa e si basa su un server condiviso per il mantenimento dei dati. I database attualmente supportati sono Microsoft SQL Server 2005 e IBM DB2. Versioni precedenti eseguivano invece su SQL Server 2000 [3]. B1 si basa su due database: • SBO-COMMON che contiene impostazioni di default e pacchetti di installazione per una certa versione di SAP B1. • COMPANY-DB contenente i dati cliente. Si noti che più COMPANY-DB possono condividere lo stesso SBO-COMMON. L’unico requisito è che la versione (V) e la Patch Level (PL) dei due sia la medesima. Una istanza di SAP B1 è completamente definita dalla versione, la patch level e il tipo di database (SQL 2000, SQL 2005, DB2). I GSC Consultant usano attualmente un applicativo chiamato CSN dove possono vedere i messaggi inseriti dai partner (ogni partner è identificato da un identificativo). Dopo che il messaggio è stato inserito nel

6

2. Analisi

CSN esso può essere inoltrato da consulente a consulente allo stesso livello (ad esempio da un consulente GSC ad un altro consulente GSC) oppure può essere inoltrato ad un altro livello (verso l’interno: IBD, verso l’esterno: Partner). Il messaggio rappresenta il centro di tutto il sistema in quanto raccoglie tutte le informazioni relative al cliente (Customer ID, ...), il Partner (Partner ID, ...), la versione di B1 (V, PL, DB type). Quando il GSC Consultant comincia a risolvere un messaggio, egli ha la possibilità di connettersi remotamente al partner o al cliente per analizzare il problema. Nel caso in cui non sia possibile fornire una soluzione da remoto, allora il partner deve trasferire il backup del COMPANY-DB in una cartella SFTP assegnata dal consulente. Una volta caricato il DB, il consulente GSC registra il messaggio nel TEC. TEC è un applicativo usato per importare i COMPANY-DB inviati dai partner nel corretto SAP server, dove i consulenti possono fare il login e risolvere i problemi che affettano la base dati. Spesso si richiede (specialmente per i membri del System Team) di eseguire determinate query nel database. Le informazioni relative al server e alla base dati a cui connettersi sono salvate in TEC.

2.1.4

Software Preesistente

I software attualmente in uso dal GSC sono: • CSN (basato su SAP R3) • TEC 3.0 (a breve sostituito da TEC 4.0 in sviluppo) • Microsoft Sql Server Management Studio (MS SSMS) è importante sottolineare che l’ambiente TEC è designato per supportare solamente database MS Sql Server dato il numero elevato di installazioni, comparate a quelle di IBM Database2 DBMS (DB2). TEC 3.0 è attualmente basato su infrastruttura CITRIX-Metaframe [14]. Tutti i server MS Sql Server 2003 sono localizzati a Walldorf, in Germania e sono accessibili globalmente tramite Virtual Private Network (VPN) da tutte le sedi B1.

2.2

Analisi del Problema

Il seguente capitolo presenterà solamente i moduli sviluppati. Per una discussione più generale si rimanda alla lettura di [2]

7

Analisi del Problema

2.2.1

Definizione del Problema

L’Azienda ha identificato i seguenti problemi, che dovevano essere rivisti ed analizzati: • Rivedere l’implementazione di TEC, aggiungendo un modulo per eseguire e salvare query remote ed automatizzare operazioni ricorrenti da effettuare durante le operazioni di ripristino, upgrade e backup delle base dati (moduli A e B). • Migliorare la gestione della server farm, riducendo lo spazio occupato dai database dei clienti ed eliminando database residui non più utilizzati (modulo C). • Rivedere il processo di supporto interno fornito dal GSC System Team al fine di migliorarne, se possibile, la produttività (modulo D). SAP ha dato incarico al Project Manager di coordinare lo sviluppo del nuovo TEC 4.0 che andrà a sostituire la versione attualmente in uso. La sezione seguente presenta i problemi affrontati, in coordinamento con il Project Manager e gli altri sviluppatori. Nello specifico verranno discussi i seguenti moduli:

[MODULO A] Esecuzione e salvataggio di query remote. Il problema attualmente evidenziato dai consulenti è l’assenza di una gestione automatizzata delle query da eseguire. Ogni qualvolta il consulente GSC deve reperire informazioni dalla base dati, egli deve ricorrere a Sql Server, selezionare il database su cui deve essere eseguita la query, ricordare la query da eseguire o selezionarne una da un repository, eseguirla e salvarne il risultato. Il risultato è tipicamente riportato a mano, copiato in un file excel o un’altra tabella temporanea.

[MODULO B] Automazione di routine durante i processi di ripristino, upgrade e backup della base dati. La versione attuale di TEC (3.0) non prevede alcun metodo per poter eseguire query preconfigurate. Ogni qual volta uno sviluppatore deve aggiungere, modificare o eliminare alcuni task, egli deve riscrivere nuovo codice o modificare il codice preesistente, toccando l’applicativo. Anche in questo caso si avverte la necessità di avere un repository per le query da eseguire.

8

2. Analisi

[MODULO C] Migliorare la gestione della server farm. Condurre una analisi al fine di rilevare le ragioni principali per cui TEC 3.0 fallisce, dove con fallimento si intende che il Db non è stato correttamente ripristinato sulla corretta istanza e risulta quindi non accessibile da parte del consulente GSC.

[MODULO D] Migliorare il workflow aziendale. Analizzare il processo aziendale interno del GSC System Team ed evidenziare, se possibile, i workflow più lenti proponendo ed implementando, una volta approvata, una possibile soluzione.

2.3

Analisi dei Requisiti

In questo capitolo vengono descritti i vincoli di progetto specificati dal Project Manager, tenuti in considerazione durante la fase di progetto e realizzazione.

2.3.1

Vincoli di progetto

Le linee guida ivi specificate sono state discusse con Aurelien Leblond, Project Manager del progetto TEC 4.0 • L’ambiente di sviluppo da utilizzare deve essere Visual Studio • Il linguaggio di programmazione deve essere C# in quanto il Team di sviluppo ha conoscenza pregressa con tale linguaggio • Tutti i client girano su piattaforma Windows. Eventuali client non NT potranno utilizzare l’applicativo tramite macchine virtuali VMWare [15] attualmente in fase di implementazione presso la sede centrale di Walldorf, in Germania • La base dati deve essere Sql Server 2005 per omogeneità con la base dati utilizzata da SAP Business One. E’ prevista una migrazione successiva a Sql Server 2008. • Data la necessità di concludere la prima release di TEC 4 entro marzo 2009 la progettazione e realizzazione dell’applicativo doveva essere concluso entro gennaio 2009, concentrandosi sulle caratteristiche fondamentali del sistema invece che sul progetto di dettaglio, da effettuarsi in un secondo momento.

9

Analisi dei Requisiti

• Tutte le operazioni che comportano iterazioni con le basi dati dei clienti devono essere eseguite in un ambiente di test 3 . Una volta validate le funzionalità, queste possono essere implementate in TEC.

2.3.2

Casi d’uso

In figura 2.3 sono rappresentati i casi d’uso relativi ai moduli A, B, C introdotti nella sezione 2.2.1. Come si può vedere, vengono separate le funzionalità riservate agli amministratori TEC (TECAdmin) dai consulenti (TEC User). Inoltre il TECAdmin risulta essere una specializzazione del TEC User per cui può accedere a tutte le funzionalità di quest’ultimo (indicate dai punti 1,2,3) più altre a lui riservate (4,5,6). I casi d’uso indicati ai punti 1,5,6,8,9 sono quelli stabiliti come essenziali già nella prima fase di realizzazione di progetto. I punti 2,3,4 sono quelli sviluppati nell’ambiente di test, per il punto 7 è invece stata ultimata da parte di un altro sviluppatore la sezione relativa al restore. uc Use Case Model TEC

1. Filter & View Result

«extend» TECUser 2. Execute Query & Sav e Result

8. TEC Client

«extend»

«extend» 3. Upgrade Manager «extend»

«extend» «communicate»

4. Backup Manager

Serv er Farm

«communicate»

TECAdmin

5. Query Admin «use»

6. Properties Framew ork

9. TEC Serv er «extend»

«use» TEC Database

7. Upgrade, Backup, Restore

Figura 2.3: Use Case del Sistema 3

Per l’ambiente di test si veda il progetto Visual Studio denominato RemoteQueries

10

2. Analisi

2.3.3

Planning delle attività

La fase di progettazione, descritta nel successivo Capitolo 3 inizia con lo sviluppo dei moduli A e B (in quanto il modulo B è stato inserito all’interno del modulo A), seguito dal modulo C ed infine viene presentata la proposta di ridefinizione del sistema del modulo D.

Capitolo

3

Progetto del Sistema 3.1

Moduli A e B: Generic Query

Nei paragrafi seguenti verranno descritte le fasi di progetto dei diversi elementi che costituiscono i moduli A e B. In particolare verrà descritto il canale di comunicazione tra client e server, il listener su server, la base dati, l’interfaccia PropertiesFramework, i plug-in Query Admin e Query Result.

3.1.1

Il canale di comunicazione

Data la struttura Client Server di TEC era necessario individuare il metodo di trasporto più opportuno per i dati che devono transitare nel canale di comunicazione che permette il dialogo tra l’applicativo client ed il server remoto. Sono stati considerati i seguenti fattori • Livello di trasporto da adottare • Operazioni da svolgere in ingresso e in uscita dal canale • Tipo di dati da fare transitare nel canale Dato il vincolo relativo al linguaggio di programmazione e all’ambiente di sviluppo imposto dal Team Leader, la scelta è ricaduta in una implementazione con .NET Remoting. Per quel che riguarda il livello di trasporto adottato, .NET Remoting supporta i protocolli TCP, HTTP ed altri protocolli personalizzabili. Dato che il contesto in cui opera il sistema è una VPN opportunamente configurata, si è scelto di implementare il sistema con Transmission Control Protocol (TCP) e formattatore binario, fornito di default. Utilizzando 11

3. Progetto del Sistema

12

TCP invece che Hypertext Transfer Protocol (HTTP), si riduce la quantità di dati scambiati tra gli end-point data l’assenza degli header introdotti da HTTP nel payload TCP. Si è scelto di sviluppare Client e Server in modo tale che sia comunque possibile cambiare il canale utilizzato (da TCP ad HTTP e viceversa) tramite file di configurazione. Per i dati in transito si sono valutate le operazioni di compressione, formattazione binaria e crittografia. La formattazione binaria risulta indispensabile per poter trasferire i dati sul canale. La crittografia è stata trascurata in quanto tale servizio è offerto dalla VPN aziendale mentre è stata implementata una compressione in ingresso\uscita al canale, considerata la scarsa capacità di serializzazione1 offerta da .NET. Come evidenziato da Rammer in [17], viene suggerita l’implementazione di un sink di compressione qualora gli oggetti da trasferire contengano prevalentemente stringhe o testo. Se tale condizione è verificata si può arrivare ad una dimensione dell’oggetto serializzato\compresso inferiore del 50% rispetto all’originale stream serializzato. Diverso è il caso in cui i dati da trasferire siano immagini o flussi audio\video nel qual caso l’interfaccia di compressione deve essere implementata direttamente nel serializzatore con opportune codifiche di compressione (e.g. JPG per le immagini). Oltre a questo, l’articolo di Schwarzkopf e Mathes [18] afferma a pagina 402 quanto segue: “[...] .NET seems to use a kind of UTF-8 for serialization of chars, which uses one, two or three bytes depending on the character ”. Questa assunzione giustificherebbe l’uso di un compressore dato il buon livello che è possibile ottenere usando un opportuno compressore come evidenziato nell’articolo Compression of Unicode files di Fenwick e Brierley [12]. Nel caso in esame gli stream da trasferire contengono quasi esclusivamente stringhe e risultati di esecuzione, che giustificano l’implementazione del sink di compressione. In figura 3.1 vengono visualizzate le operazioni svolte dal canale e viene indicato dove dovrebbe essere inserito l’algoritmo di compressione in caso si volesse implementare in un secondo momento. Come si può notare la compressione deve essere eseguita prima di criptare il messaggio in transito sul canale, altrimenti risulterebbe poco efficiente in termini di livello di compressione. Essendo .NET Remoting Object Oriented e quindi in grado di gestire oggetti, non sono stati specificati particolari requisiti circa il tipo di oggetti da scambiare. Saranno invece specificate alla sezione 4.1.2 le caratteristiche di tali oggetti. 1

Capacità di serializzazione intesa come dimensione in byte dello stream serializzato compresso rispetto allo stream serializzato

13

Moduli A e B: Generic Query

TEC User

SAP VPN TEC User

pwdf6541 Serializable Objects - Query - Result - Event - Db Type

CHANNEL

OBJs

CHANNEL SERVER

CLIENT

CHANNEL

CHANNEL

BINARY FORM.

COMPRESSION

ENC.

ENC.

COMPRESSION

BINARY FORM.

Figura 3.1: Channel

3.1.2

Il Server Listener

Scopo del Server Listener è quello di offrire servizi ai clients, gestendo le informazioni in input ed in output con la base dati.

CHANNEL LISTENER TEC DB

SERVER

Figura 3.2: Listener

Per poter dialogare con la base dati le possibilità erano o fornire un accesso autonomo indipendente per ognuno dei servizi implementati dal Listener oppure implementare un framework di comunicazione tra i servizi implementati sul listener e la base dati. La possibilità di poter usufruire di un accesso indipendente servizio per servizio permette allo sviluppatore di decidere in piena autonomia come gestire le comunicazioni con la base dati, come ad esempio il timeout di connessione, la gestione delle transazioni, la modalità di accesso alle tabelle. Questa autonomia si può comunque rilevare controproducente in quanto:

14

3. Progetto del Sistema

• Lo sviluppatore potrebbe non avere conoscenza relativa alla struttura dell’intera base dati • Lo sviluppatore potrebbe focalizzarsi sulla sue operazioni senza valutare le eventuali implicazioni che questo può avere su operazioni concorrenti svolte da altri sviluppatori • Si rischia di introdurre ridondanza nel caso in cui uno sviluppatore necessiti delle informazioni fornite da una certa vista, e non sia al corrente che tale funzionalità è già implementata in un servizio sviluppato da un altro programmatore La seconda possibilità è invece l’utilizzo di un framework per l’accesso alla base dati: il framework conterrà un insieme predefinito di funzionalità e nel caso in cui una funzionalità richiesta non sia presente, essa dovrà essere notificata allo sviluppatore del framework. Sarà compito di quest’ultimo fornire il metodo di accesso nel modo più opportuno. Questa soluzione toglie definitivamente allo sviluppatore del servizio la possibilità di accesso diretto alla base dati, dall’altro però garantisce la consistenza della base dati ed in caso di malfunzionamento o modifiche sarà necessario intervenire unicamente sul framework invece di mettere mano a tutti i servizi implementati dai diversi sviluppatori. Si noti in figura 3.3 dove si è deciso di implementare l’interfaccia PropertiesFramework per l’accesso alla base dati.

CHANNEL LISTENER

FRAMEWORK TEC DB

SERVER

Figura 3.3: Properties Framework

3.1.3

La Base Dati

L’accesso alla base dati poteva essere implementato in 2 differenti modi. I due modi di accesso verranno qui esposti e verrà data una giustificazione della scelta effettuata. Accesso con query definite nel codice In questo caso lo script della query da eseguire è nidificato all’interno del codice C# dell’interfaccia PropertiesFramework. Quando il programmatore richiama una funzionalità in PropertiesFramework, l’implementazio-

15

Moduli A e B: Generic Query

ne dell’interfaccia stabilisce una connessione con la base dati ed inoltra l’intera stringa contenente la query da eseguire. Accesso con Stored Procedures In questo caso nell’implementazione di PropertiesFramework viene specificato solamente il nome della stored procedure esistente all’interno della base dati, che deve essere richiamata. Quando il programma richiama una funzionalità in PropertiesFramework, l’implementazione stabilisce una connessione con la base dati e richiama la Stored Procedure. Durante la fase implementativa è stato scelto questo secondo approccio a seguito delle seguenti considerazioni: • Modularità offerta dalle stored procedures: in caso di bug o modifiche da eseguire sulla query in oggetto (o piu generalmente parlando del batch da eseguire) risulta indubbiamente più semplice effettuare il debug della stored procedure su Sql Server piuttosto che analizzare una stringa immersa nel codice C#. Oltretutto la nuova versione di Sql Server 2008 offre un ambiente di debug contenente molte delle funzionalità di debug presenti in Visual Studio. Data la retrocompatibilità con basi dati Sql2005 offerta da Sql Server 2008, è ora possibile utilizzare l’ambiente di debug offerto da quest’ultimo per l’analisi e il debug delle stored procedures. stesse. • è possibile effettuare il tuning delle stored procedures, utilizzando l’Execution Plan ed il Tuning Advisor integrati in Sql Server. Tramite questi programmi una stored procedure può essere rivista ed eventualmente modificata per diminuirne il tempo di esecuzione (quando possibile). Tale operazione è del tutto trasparente all’interfaccia Properties Framework che quindi non richiede d’essere modificata. • Per quanto detto a inizio paragrafo, il traffico di rete viene ridotto in quanto non è necessario passare a Sql Server l’intera stringa contenente la query ma solamente il nome della stored procedure. • Maggiore interoperabilità: nel caso in cui insorga la necessità di sviluppare applicativi in linguaggi differenti, basterà che questi abbiano una interfaccia di accesso ai dati per Sql Server, per poter richiamare le stored procedure preesistenti • Il codice definito all’interno delle stored procedures viene analizzato dal parser di Sql Server e dopo la prima esecuzione verrà generata una versione in-memory che verrà eseguita più velocemente ai richiami successivi.

16

3. Progetto del Sistema

A fronte di questa discussione si devono tuttavia ricordare alcuni casi in cui l’implementazione di stored procedures all’interno del codice possono offrire una valida alternativa, ossia quando: • La query da eseguire viene generata a runtime • I dati di ritorno di una stored procedure sono usati per creare una nuova stringa T-SQL. Lo schema finale che ne deriva è quello mostrato in figura 3.4

TABLE

CHANNEL

SERVER

FRAMEWORK

STORED PROCEDURE LIBRARY

VIEW LIBRARY TEC DB

Figura 3.4: Modello di Accesso ai dati

Viste Si è deciso di interfacciare le stored procedures con delle viste piuttosto che interfacciarle direttamente con le tabelle. Questa decisione è stata presa a seguito delle seguenti considerazioni: • La vista consente di visualizzare tabelle e relazioni tra tabelle in un formato più conveniente • Il tempo di accesso ai dati su una vista è esattamente lo stesso di accesso diretto alle tabelle da cui la vista è stata ottenuta. • Possono essere combinate con ruoli (che rappresentano diversi gruppi di utenti) per consentire l’accesso esclusivo a tabelle e\o viste a seconda del ruolo assegnato all’utente. • In caso di modifica alla tabella di origine, la vista può essere modificata in modo tale da offrire la medesima interfaccia alle query e\o stored procedure che la utilizzano. Lo svantaggio principale derivante dall’uso delle vista sta nel fatto che, in caso di modifica ad una determinata tabella, referenziata da viste

17

Moduli A e B: Generic Query

multiple, potrebbe essere necessario modificarle tutte per garantire il funzionamento delle stored procedures. Nel caso in oggetto, date le molteplici stored procedure che si andranno a sviluppare si è scelto di ricorrere all’uso delle viste Schema Un’altro concetto offerto da Sql Server che si è deciso di utilizzare è stato il concetto di schema. Scopo dello schema è quello di separare gli oggetti sul database dai diritti utente. Lo schema può essere visto come una unità logica che raccoglie più oggetti. Esso può essere utilizzato per diversi scopi [[6]] ma nel nostro caso si è scelto, in comune accordo con gli altri DBA di utilizzare gli schema per separare le varie aree del database. Le aree proposte sono state: • B1 • BackupManager • Core • Infrastructure • Internal • Properties • Security come evidenziato in figura 3.5. Per quanto sviluppato in questa Tesi, tabelle, viste, stored procedures saranno tutte identificate dallo schema Properties e dallo schema BackupManager. Ridefinizione dei requisiti I requisiti inerenti la base dati e riportati in Appendice A sono stati reinterpretati e riassunti nelle tabelle 3.1, 3.2, 3.4 e 3.3. Entity e Event sono qui omessi per non appesantire la trattazione. Il Modello E-R che ne deriva è mostrato in figura 3.6

18

3. Progetto del Sistema

QUERY HA una descrizione PUO’ riferire ad una SAP note PUO’ essere pubblica HA il testo della query PUO’ avere un ordine di esecuzione HA una data di modifica HA uno timestamp di modifica E’ ASSOCIATA ad un evento E’ inserita da un TECAdmin PUO’ produrre dei risultati PUO’ essere eseguita su un solo specifico tipo di database Tabella 3.1: Tabella Query

RESULT HA un risultato di esecuzione E’ ASSOCIATO ad una query E’ PRODOTTO da un utente APPARTIENE ad un ticket HA una data di modifica HA un timestamp di modifica PUO’ essere un risultato d’errore Tabella 3.2: Tabella Result

BATCH HA un ID di esecuzione HA uno Stato PUO’ generare nessuno, uno o più risultati Tabella 3.3: Tabella Batch

19

Moduli A e B: Generic Query

class Db Schemas Db Schemas

B1

Properties

Infrastructure

Core

Security

Internal

BackupManager

Figura 3.5: Schema definiti nel database TEC

3.1.4

L’interfaccia Properties Framework

In figura 3.7 sono rappresentati i servizi offerti dall’interfaccia PropertiesFramework e le relazioni con le stored procedure della base dati. I servizi offerti sono di 3 tipi: Salvataggio, Esecuzione e Selezione. Le operazioni di modifica ed eliminazione non sono state prese in considerazione in quanto il Project Manager ha proposto di creare un Framework comune a tutti gli schema per le operazioni di UPDATE, DELETE. Inoltre, data la disponibilità di un DBA, non ha senso provvedere allo sviluppo di operazioni INSERT, UPDATE e DELETE per entità quali ENTITY ed EVENT. ENTITY ed EVENT infatti sono raramente modificati, RESULT è sempre aggiunto automaticamente e non ha senso una modifica del risultato di una query. L’operazione di DELETE non deve essere effettuata da parte degli sviluppatori ma eseguita automaticamente nel caso un messaggio CSN venga chiuso o il database sia stato eliminato (si veda la parte di implementazione per le riflessioni in merito).

20

3. Progetto del Sistema

RELAZIONI QUERY può generare zero o più RISULTATI RISULTATO può essere generato da una e una sola QUERY QUERY è inserita da uno ed un solo TECADMIN TECADMIN può inserire zero o più QUERY QUERY può essere eseguita su una ed una sola ENTITà ENTITA’ può essere oggetto di zero o più QUERY QUERY può generare un RISULTATO di errore RISULTATO è output di una ESECUZIONE TECUSER può eseguire una o più ESECUZIONI RISULTATO può appartenere a un BATCH di esecuzione Un BATCH di esecuzione può generare uno o più risultati Una QUERY può eseguire come BATCH Tabella 3.4: Tabella Relazioni

EntityID Description

Properties.Entity

EventID Description

Properties.Event

0,N

0,N

ON

RAISE

0,1 1,1 QueryID QueryDescription SAPNote IsPublic QueryText

0,N

ResultID

1,1

Properties.Query

GENERATE

1,1

Properties.Reult

0,N

ADD

ResultDate ExecutionResult

1,1

BREED

RETRIEVE

0,N 0,N 0,1 TECUserID

0,N Security.TECUser

TicketID Core.Ticket

1,1 EXECUTE

1,1

Properties.Batch

0,N

BELONG

BatchID 0,N 1,1

OWN

Properties.Status

Figura 3.6: Modello E-R Schema Properties

StatusID Description

3

GetSavedQueryResult

Y

Y

Y

N

7

SetQuery GetSavedQueryResult GetSavedQueryResult, SetResult GetSavedQueryResult, SetResult GetRemoteQueryResult

2 3 4 5 6

12

11

10

9

8

9

GetEventList

GET LIST OF EVENTS

GetBatch

GetResult

GetEventList

GetEntityList

GetQueryResultList

GetQueryList

STORED PROCEDURES

GetEntityList

GET LIST OF ENTITIES

GET Line

Figura 3.7: Servizi Offerti da Properties Framework

SetResult

1

STORED PROCEDURES

6

7

GetQueryResult List 8

GET LIST OF RESULT

GetRemoteQueryResult

N

GetQueryList

GET LIST OF QUERY

ExecuteAndSave Result 5

TIME CONSUMING QUERY

N

ALREADY STORED ON DB

EXECUTE A QUERY

EXEC Line

WHAT TO DO

ExecuteAndSave ResultAsync 4

CHECK BEFORE SAVING

2

SaveQuery

SaveResult

1

SAVE A QUERY

SAVE A RESULT

SAVE Line

IPropertiesFramework

10

11

GetSavedResult

GET A SPECIFIC RESULT

12

GetBatchList

GET LIST OF BATCH

21 Moduli A e B: Generic Query

3. Progetto del Sistema

3.2

22

Modulo C: Backup Manager

Riprendendo quanto esposto nella sezione 2.2.1, lo scopo del modulo di Backup Manager è quello di identificare il problema che porta la procedura di restore a fallire, compromettendo il funzionamento dell’ambiente TEC. L’ambiente TEC è composto di 15 servers, locati in Germania sul quale sono installate 75 istanze tra Sql2000, Sql2005 (La lista completa delle istanze è riportata in appendice). L’impossibilità di ripristinare i database dipendeva dai seguenti malfunzionamenti: • userID e\o password dell’area Secure File Transfer Protocol (SFTP) non corretti • backup non compresso e\o compresso in formato differente dai formati supportati (.zip e .rar) • file compresso corrotto • mismatch tra la versione del backup (e.g. Sql2005) e il server su cui eseguire il restore (e.g. Sql2000) • versione di Business One non conforme alla versione dichiarata in fase di richiesta del TEC Ticket, con conseguente mismatch tra il COMPANY-DB e l’SBO-COMMON • fallimento della procedura di unzip a causa di mancanza di spazio su server • fallimento della procedura di restore a causa di mancanza di spazio su server • impossibilità di operare sulla base dati a causa della impossibilità di allocare spazio su server Per poter identificare quali di questi problemi erano i più significativi sono stati analizzati i messaggi IT inseriti in CSN dai consulenti SAP per risolvere le problematiche incontrate durante l’utilizzo di TEC. I consulenti hanno richiesto nell’arco di tre anni 3897 richieste di intervento da parte di un TECAdmin. Di tutti i TECAdmin (21 in totale) sono stati individuati quelli con il maggior numero di messaggi analizzati (8 TECAdmin) che da soli hanno provveduto a risolvere l’80% dei messaggi totali. Questi consulenti sono stati contattati per avere un loro feedback circa le cause di malfunzionamento. Oltre ai feedback dei consulenti sono stati analizzati 20 messaggi scelti a campione per ognuno dei consulenti individuati, per un totale di 160 messaggi analizzati.

23

Modulo C: Backup Manager

La verifica incrociata tra i feedback e i messaggi campione analizzati ha portato all’individuazione della causa principale per cui l’operazione di restore dei database falliva ossia la mancanza di spazio su server. Tale situazione è stata rilevata eseguendo un analisi dei Db (si veda lo script Analysis.sql e la tabella [snapshot].[RequiredDatabase] nel database TEC). Come si vede dal trend del grafico sottostante, il numero di database ripristinati sui server è andato via via aumentando, mese dopo mese. I database vengono eliminate automaticamente quando non utilizzati per più di 14 giorni, questo giustifica l’andamento discendente in alcuni punti.

Figura 3.8: Numero database ripristinati su server

Il secondo grafico mostra invece il totale annuo di database ripristinati su server. Si noti che per l’anno 2006 e 2009 i dati sono stati previsti dato che nel 2006 l’uso di TEC è iniziato a dicembre e nel 2009 I dati sono stati raccolti a metà febbraio.

Figura 3.9: Totale spazio annualmente allocato sui server

Le previsioni per il 2009 sono ottimistiche e non tengono conto di

3. Progetto del Sistema

24

possibili flessi dovuti alle minori richieste di supporto data l’attuale situazione economica a livello mondiale. Sulla base di tali considerazioni è quindi necessario ottimizzare l’utilizzo delle risorse a disposizione invece di fare investimenti economici puntando sull’acquisto di hardware dedicato (sempre che questo venga autorizzato dalla dirigenza).

3.2.1

La Procedura di Restore attuale

Quando il consulente necessita di ripristinare un database compila il form di figura 3.10, immettendo il message number del messaggio CSN, il customer number, la versione di Business One, il tipo di Server e i parametri di accesso all’area SFTP. L’applicativo determina, in base ad una logica interna 2 il server sul quale deve essere fatto il download del database compresso in formato .zip o .rar . Verrà quindi create una cartella nel network path \ \ServerName \backups$\Data ed ivi verrà creata una cartella nel formato Anno_CSNMessageNr_CSNCustomerNr_TECTicketNr. In questa cartella verrà riposto il database, esso verrà estratto nella sottocartella tmpTEC, ripristinato su server con nome Anno_CSNMessageNr_CSNCustomerNr_TECTicketNr e la cartella tmpTEC verrà immediatamente eliminata. Dopo 14 giorni di inutilizzo del database sia la cartella che il database con nome Anno_CSNMessageNr_CSNCustomerNr_TECTicketNr verranno eliminati 3 .

3.2.2

Problemi Rilevati

A seguito delle interviste condotte con gli sviluppatori del modulo TEC preposto all’operazione citata nel paragrafo precedente, le possibili cause di spreco di spazio sono: • creazione da parte dei TECAdmin di cartelle che non corrispondono a nessun database a seguito di restore manuale. • estrazione manuale e dimenticanza del file scompattato .bak nella directory tmpTEC • ripristino di database sui server senza seguire le regole di nomenclatura sopracitata 2 Per determinare l’istanza corretta viene comparata la versione, la patch level e il tipo di database dichiarato dal consulente al momento della richiesta del messaggio. Una volta determinata l’istanza corretta, viene scelto tra tutti i server con l’istanza richiesta, quello con spazio maggiormente libero. 3 La procedura di restore per òa versione TEC 4.0 ripristina il database con nome TECTicketNr per il COMPANY-DB e TECTicketNr_COM___ per l’SBO-COMMON.

25

Modulo C: Backup Manager

Figura 3.10: TEC 3 - GUI Richiesta ticket

3. Progetto del Sistema

26

• mismatch tra la nomenclatura della cartella e il database ripristinato. I database, una volta ripristinati vengono o utilizzati dai consulenti o ne viene fatto un upgrade: Tutte le transizioni eseguite nel database vengono salvate nel Transaction Log. Il Transaction Log risulta essenziale in caso di rollback ad una situazione precedente ma risulta controproducente nel caso in analisi in quanto va ad aumentare drasticamente lo spazio occupato dal database, specie a seguito di una operazione di upgrade. Per una trattazione più esauriente si rimanda a [5].

3.2.3

Possibili Soluzioni

I problemi rilevati possono essere risolti con le seguenti operazioni: • eliminazione delle cartelle su server non conformi al formato Anno_CSNMessageNr_CSNCustomerNr_TECTicketNr • eliminazione dei database non conformi al formato Anno_CSNMessageNr_CSNCustomerNr_TECTicketNr • shrink di tutti i database presenti su server Prima di poter procedure con tale implementazione deve essere valutato se vale la pena sviluppare un software appositamente per tali attività o se piuttosto conviene pulire manualmente i server. Il tempo necessario alla verifica deve essere limitato rispetto al tempo necessario a sviluppare l’eventuale software. Si è deciso di utilizzare il software SequoiaView [19], sviluppato dall’Università Tecnica di Eindhoven per verificare lo stato dei server. è stato creato uno ColorScheme (si veda il file SequoiaTecColors.txt) con la mappa colori. Un tipico screenshot è rappresentato in figura 3.11 Come si può notare la situazione è critica in quanto file di backup (rosso) occupano una grossa percentuale dello spazio su hard disk. Analogamente alcuni database hanno file .mdf (blu) e file .ldf (viola) piuttosto estesi a causa della mancata operazione di shrink. Per quanto detto si è deciso di sviluppare: • un applicativo per la rilevazione delle cartelle con mismatch • uno script per eseguire lo shrink distribuito sui server, da implementare come Job su Sql Server In figura 3.12 è riportato lo schema di funzionamento dell’applicativo BackupManager, la cui implementazione è descritta nel capitolo 4.

27

Modulo D: Ridefinizione GSC Workflow

Figura 3.11: Snapshot Sequoia

3.2.4

Schema E-R Backup Manager

Il modello E-R relativo allo schema BackupManager è rappresentato in figura 3.13. In questo caso la struttura della base dati è piuttosto semplice in quanto sono immediatamente distinguibili tre entità: Server, Directory e File. Un server può contenere più directory ed una directory può contenere più file. Analizzando in senso opposto si ha invece che un file può essere contenuto in una ed una sola directory ed una directory può essere contenuta in uno ed un solo server. Come si vede dal modello-ER vengono omesse tutte le informazioni non pertinenti (come ad esempio eventuali sottocartelle), questo perché lo scopo è quello di identificare cartelle con più di un file (che dovrebbe essere il file compresso contenente il backup del database) e cartelle orfane (ossia non associate a nessun ticket).

3.3

Modulo D: Ridefinizione GSC Workflow

Lo schema rappresentato in figura 3.14 riassume il workflow attualmente in uso. Quando un consulente (FI, LOG, AP\AR...) analizza un messaggio può essere necessario richiedere un upgrade. In tal caso la richiesta viene elaborata dall’ambiente TEC e quindi eseguita. Una volta ultimato il processo di upgrade il consulente viene notificato sull’esito positivo o meno dell’upgrade. In caso l’esito sia negativo, il consulente deve contattare un membro del System Team e notificare il fallimento dell’upgrade.

28

3. Progetto del Sistema BackupManager SCHEMA ServerManager

BackendRootList GetBackendRootList

1.

ServerManager()

COLLECT DATA TEC_LIVE

BackendServer SetServer

Pwdf2660

3.

2.

STORE DATA

Directory SetDirectory

File

SetFile

RestoredDatabase

4.

DistributedShrink_V2.sql (STEP 4)

1. Executed when the application starts 2. Executed when the button “COLLECT DATA” is pressed 3. Executed when the button “STORE DATA” is pressed 4. Executed on Step 4 in DistributedShrink_V2.sql

Figura 3.12: Overview Backup Manager

Il System Consultant a questo punto analizza il database di partenza per determinare la causa che ha impedito l’upgrade, determina quindi il fix da applicare e reinoltra la richiesta di upgrade. A questo punto egli otterrà l’esito dell’upgrade. Se positivo, potrà notificare a sua volta l’esito al consulente GSC che ha inoltrato la richiesta, altrimenti deve reiterare il processo di analisi\fix fino a quando la procedura non va a buon fine. Una volta che il consulente riceve notifica di avvenuto upgrade, può continuare con la sua attività di analisi sul database in oggetto e portare a termine l’attività di message processing. Si noti che l’attività del General Consultant è non bloccante in quanto nel momento in cui l’attività di restore solving viene delegata ad un membro del System Team, egli può proseguire con l’analisi di un nuovo messaggio. L’attività del System Consultant è invece bloccante in quanto egli tiene in carico il database sintantoche la procedura di upgrade continua a fallire. Le attività più dispendiose sono appunto quelle di analisi e problem solving. Oltretutto allo stato attuale vi sono solamente un paio di note SAP atte a rilevare possibili cause di upgrade failure (questo comporta che il System Consultant debba comunque intervenire manualmente per applicare il fix). L’idea di sviluppo è quella di automatizzare, per quanto possibile, le attività di failure analysis e problem solving, spostandole all’interno dell’ambiente TEC in modo tale da utilizzare il meno possibile i consulenti per la risoluzione di problemi interni. La soluzione proposta è quel-

29

Modulo D: Ridefinizione GSC Workflow

BackendID Servername BackupRoot

BACKEND SERVER

0,N

TO HOLD

1,1 DirectoryID Name CreationTime LastAccessTime

NumFiles DIRECTORY

0,N TO HOLD

1,1 FileID Name Type

FILE

Figura 3.13: Modello E-R Schema BackupManager

la di utilizzare la struttura messa a disposizione dalle query generiche sviluppate nel MODULO A. L’idea di ridefinizione del workflow è illustrata in figura 3.15. In questo nuovo schema è stato aggiunto il processo denominato Forced Upgrade allo scopo di modificare il database rendendolo compatibile con la procedura di upgrade. Tale processo si trova all’interno dell’ambiente TEC e non richiede quindi alcun dispendio di tempo da parte dei consulenti. Solo nel caso in cui tale procedura fallisca, il database sarà analizzato da un System Consultant. Lo scopo è quello di potenziare il più possibile tale processo, riducendo gli interventi del System Team. Per fare questo ogni qual volta una procedura di upgrade fallisce, il System Consultant valuta se questo è dovuto ad un problema specifico della base dati del cliente (ad esempio una User Defined Table (UDT) aggiunta o un User Defined Field (UDF) settato in modo non conforme alle specifiche SAP) o è un problema generale (tipicamente modifiche alle tabelle di sistema SAP: modifica lunghezza campi nelle System Table). In questo secondo caso la procedura potrebbe essere automatizzata. L’effettiva implementazione viene valutata dall’Upgrade Solution Desk (USD) (attore aggiunto che deve essere definito) tramite il processo di Issue Knowledge Transfer. I dettagli relativi alle procedure sono riportati nella sezione 4.3.

30

3. Progetto del Sistema

act Workflow GENERAL CONSULTANT

SYSTEM CONSULTANT

TEC ENVIRONMENT

Message Processing

PICK A NEW MESSAGE

CONSULTING Upg? Y UPGRADE GO TO Pick a new message UPG. NOTIFICATION

Failure?

Y N

UPG. FAILURE ANALYSIS

PROBLEM SOLVING

GO T O Consulting

POST FIX UPGRADE

UPG. NOTIFICATION

Upg?

Y UPG. NOTIFICATION

N MESSAGE SOLVING

End Message Processing

Figura 3.14: Workflow Attuale

31

Modulo D: Ridefinizione GSC Workflow

act Workflow GENERAL CONSULTANT

SYSTEM CONSULTANT

TEC ENVIRONMENT

UPG. SOLUTION DESK

Message Processing

PICK A NEW MESSAGE

CONSULTING

Upg? Y

UPGRADE GO T O Pick a new message UPG. NOTIFICATION

Failure?

Y

FORCED UPGRADE GO T O Pick a new msg UPGRADE NOTIFICATION

Failure?

Y UPG. FAILURE ANALYSIS N

N GO TO Message Solving

PROBLEM SOLVING POST FIX UPGRADE UPG. NOTIFICATION

Upg?

Y Recurrent? Y UPG. ISSUE KNOWLEDGE TRANSFER

N UPG. NOTIFICATION

N MESSAGE SOLVING

End Message Processing

Figura 3.15: Workflow Ridefinito

Capitolo

4

Implementazione 4.1

Moduli A e B

4.1.1

Properties Framework

L’interfaccia IPropertiesFramework e la sua implementazione è mostrata in figura 4.1. I parametri in input ai metodi sono tutti di tipo primitivo, per omogeneità con la base dati cui i parametri verranno passati. I risultati in output sono tipi primitivi, DataSet e DataTable. Per poter essere utilizzati in modo opportuno, il programmatore deve essere a conoscenza della struttura dei DataSet e dei DataTable tornati dall’interfaccia. In particolare i DataSet sono sempre tornati in seguito all’esecuzione di una query, i DataTable sono invece tornati ogni qual volta vengono acquisiti dati (siano essi relativi a Query, Result, Batch, ...) dalla base dati. Particolare attenzione è stata posta nel metodo ExecuteAndSaveResultAsync. Questo metodo riceve come parametri di ingresso il QueryID della query da eseguire, il ticketID sul quale la query deve essere eseguita e il TECUSerID dell’utente che sta effettuando l’operazione. Tale metodo deve eseguire in modalità asincrona per non bloccare l’applicativo client. Le possibilità analizzate sono state l’uso di un pool di thread e i thread multipli. In particolare sono state evidenziate le seguenti informazioni: • Non ci sono priorità differenti tra thread diversi • Il thread può eseguire per un tempo relativamente lungo ma l’elaborazione vera e propria (l’esecuzione della query) viene eseguita in un server diverso da quello dove il thread viene creato ovverosia nel server dove è fisicamente allocato il database target della query. 33

4. Implementazione

34

• Non è richiesto che i thread siano identificabili. Un thread viene eseguito e muore senza notificare la fine dell’elaborazione al client chiamante. • Deve essere eventualmente possibile impostare il numero massimo di thread in esecuzione, dato che le risorse sui server non devono solamente essere dedicate all’esecuzione di query. La classe che meglio rappresenta questa situazione è la classe ThreadPool che utilizza un pool di thread [11]. Il ThreadPool non è stato usato direttamente, ma tramite l’uso dei delegati, come mostrato nel frammento di codice qui riportato: 1 2

// delegate for method ExecuteAndSaveResult public delegate bool DelegExecuteAndSaveResult(int? queryID, int? ticketID, int? TECUserID, int? batchID);

3 4 5

// Delegate of type DelegExecuteAndSaveResult delegateExecuteAndSaveResult;

6 7

[...]

8 9

10 11 12

13

14 15

public int ExecuteAndSaveResultAsync(int? queryID, int? ticketID, int? TECUserID) { int batchID = GetBatch(queryID, ticketID); delegateExecuteAndSaveResult = ExecuteAndSaveResult; delegateExecuteAndSaveResult.BeginInvoke( queryID, ticketID, TECUserID, batchID, null, null); return batchID; }

Viene creato un delegato con la stessa firma (parametri e valori di ritorno) del metodo che esegue in modalità sincrona. Il metodo asincrono acquisisce dalla base dati l’ID del batch che deve essere eseguito. Il delegato viene inizializzato e viene eseguito il metodo BeginInvoke che fa partire l’esecuzione asincrona del metodo ExecuteAndSaveResult. Il batchID identificante la query in esecuzione viene immediatamente tornato al chiamante.

4.1.2

Gli oggetti serializzabili

Una volta stabilite le funzionalità che l’interfaccia PropertiesFramework è in grado di offrire (Sez. 3.1.4), si devono definire quali oggetti devono essere creati e trasferiti (mediante serializzazione) al client remoto.

35

Moduli A e B

class Class Model «interface» IPropertiesFramework + + + + + + + + + + +

ExecuteAndSaveResult(int?, int?, int?, int?) : bool ExecuteAndSaveResultAsync(int?, int?, int?) : int GetEntityList() : DataTable GetEventList() : DataTable GetQueryList(bool) : DataTable GetQueryResultList(int?) : DataTable GetRemoteQueryResult(int?, string, int?) : DataSet GetSavedQueryResult(int?, int?) : DataSet GetSavedResult(int?) : DataTable SaveQuery(string, int?, int?, string, bool?, int?, int?, int?) : int SaveResult(int?, int?, int?, DataSet, int?) : bool

PropertiesFramew orkImpl -

delegateExecuteAndSaveResult: DelegateExecuteAndSaveResult

+ + + + + + + + + + + +

DelegateExecuteAndSaveResult(int?, int?, int?, int?) : bool ExecuteAndSaveResult(int?, int?, int?, int?) : bool ExecuteAndSaveResultAsync(int?, int?, int?) : int GetBatch() : int GetEntityList() : DataTable GetEventList() : DataTable GetQueryList(bool) : DataTable GetQueryResultList(int?) : DataTable GetRemoteQueryResult(int?, string, int?) : DataSet GetSavedQueryResult(int?, int?) : DataSet GetSavedResult(int?) : DataT able SaveErrorResult(int?, int?, int?, string, int?) : bool SaveQuery(string, int?, int?, string, bool?, int?, int?, int?) : int SaveResult(int?, int?, int?, DataSet, int?) : bool

Figura 4.1: Interfaccia PropertiesFramework e sua implementazione

In tal caso si può fare riferimento alla struttura database creata, che fornisce utili informazioni circa la struttura degli oggetti: • un Risultato è sempre associato ad una Query • Una Query ha sempre associata una Entity ed un Evento Quindi una valida rappresentazione è fornita da un oggetto Risultato che contiene un oggetto Query. A sua volta l’oggetto Query contiene l’oggetto Entity e l’oggetto Evento. Analogamente si potrebbe definire che Entity contiene una lista di oggetti Query, Event contiene una lista di oggetti Query e Query contiene una lista di Results. Non si deve però dimenticare che tali oggetti devono essere scambiati all’interno di una rete WAN e la lista può potenzialmente contenere una elevata quantità di dati. Questo influenzerebbe negativamente il server ove è in esecuzione il listener, a causa della maggior computazione necessaria per generare gli oggetti summenzionati e la rete, per il maggior traffico dati generato. Ricordiamo inoltre, che quando si opera in una WAN una delle problematiche più importanti di cui si deve tener conto è la latenza. In questo caso l’obiettivo è quello di ridurre le chiamate cross-network trasferendo la maggior quantità di dati possibili ma necessari, in un singolo network round trip.

4. Implementazione

36

Il mancato uso delle liste negli oggetti costringe l’applicativo client a dover gestire le relazioni tra gli oggetti. Per offrire un maggior supporto a tali operazioni si è deciso di implementare due ulteriori metodi all’interno dell’oggetto Result. Tali metodi sono List GetAll(Ticket ticket) e List GetAll(Query query, Ticket ticket). Il primo metodo consente di reperire da server la lista di risultati di un particolare ticket, il secondo metodo invece ritorna la lista di risultati di un particolare ticket associati all’esecuzione di una specifica query. Da notare che l’implementazione di tali metodi non deve caricare il datatable relativo ad ogni risultato. Il datatable verrà tornato al client solamente a seguito dell’esecuzione del metodo ExecutionResult. Il diagramma delle classi che ne deriva, per le considerazioni fatte, è riportato in figura 4.2.

4.1.3

Server Listener

In questo paragrafo verrà descritto come si è scelto di implementare il ServerListener su server. .NET Remoting infatti offre diverse possibilità di attivazione degli oggetti remoti: • Server Activated Object (SAO) • Client Activated Object (CAO) SAO: prima che un metodo remoto sia invocato su un oggetto remoto, l’oggetto deve esistere o essere creato. SAObjects vengono creati quanto il client invoca la prima chiamata a metodo remoto. SAO a sua volta ha due metodi di registrazione: Singleton e SingleCall. Singleton viene istanziato una sola volta e serve tutte le chiamate da parte dei clients in maniera multithread. Oggetti Singlecall vengono invece creati ogni qual volta un metodo remoto viene invocato in questo tipo di oggetti. L’oggetto singlecall ha un tempo di vita assai limitato in quanto vive per il tempo necessario a processare la chiamata del client e sono quindi adatti per istanziare oggetti che non necessitano di uno stato. CAO: Sono creati sul server immediatamente alla richiesta del client. Un’istanza di un oggetto CAO è creata ogni qual volta un client ne istanzia una ed il tempo di vita è controllato dal client. La logica dei metodi CAO viene gestita nel proxy del client. Le informazioni riportate sono le minime essenziali per comprendere la scelta di implementazione. Per una descrizione più esaustiva si rimanda a [17]

37

Moduli A e B

class SerializableObj ects IEquatable Query -

IEquatable

q_Entity: Entity q_Event: Event q_ID: int? q_IsPublic: bool q_Order: int? q_SAPNote: int? q_TECUserID: int? q_Text: string q_timestampChg: byte ([]) q_Title: string

Result -

r_batchID: int r_dateT ime: DateT ime r_executionResult: DataT able r_ID: int r_query: Query r_TECUserID: int r_timeStamp: byte ([])

+ Equals(Result) : bool Add() : Query + ExecuteAndSaveResult(Query, Ticket) : void Delete() : void + ExecuteAndSaveResultAsync(Query, Ticket) : void Equals(Query) : bool -r_query + GetAll(T icket) : List Get(string) : Query + GetAll(Query, Ticket) : List GetAll() : List + GetByKey(int) : Result GetAll(Event) : List + GetQueryResultList(Ticket) : DataTable GetByKey(int?) : Query + GetResult(Query, T icket) : DataSet Query(int, string, int?, bool, int?, string, int?, byte[], Event, Entity) + GetSavedQueryResult(Query, T icket) : DataSet Query(string, int?, bool, int?, string, int?, Event, Entity) + Result(int, Query, int, byte[], DateTime, int) ToString() : string + Result(int, Query, int, byte[], DateTime, DataTable) Update() : Query + T oString() : string «property» «property» + Entity() : Entity + BatchID() : int + Event() : Event + DateTime() : DateT ime + ID() : int? + ExecutionResult() : DataT able + IsPublic() : bool + ID() : int + Order() : int? + Query() : Query + SAPNote() : int? + T ECUserID() : int + TECUserID() : int? + T imeStamp() : byte[] + Text() : string + TimeStamp() : byte[] + Title() : string + + + + + + + + + + +

-q_Entity

-q_Event IEquatable

IEquatable

Entity

Ev ent

-

e_description: string e_ID: int

-

e_ID: int e_name: string

+ + + + + + +

Add(Entity) : Entity Delete(Entity) : void Entity(int, string) Equals(Entity) : bool GetAll() : List<Entity> ToString() : string Update(Entity) : Entity

+ + + + + + +

Add() : Event Delete() : void Equals(Event) : bool Event(int, string) GetAll() : List<Event> ToString() : string Update() : Event

«property» + Description() : string + ID() : int

«property» + EventID() : int? + Name() : string

Figura 4.2: Oggetti Serializzabili

4. Implementazione

38

Avere la logica sul client non garantisce che l’applicativo utilizzi sempre la versione più aggiornata dei metodi e in caso di aggiornamento dei metodi sul server è necessario provvedere a riavviare gli applicativi client onde evitare comportamenti indesiderati. Questo esclude la possibilità di utilizzare gli oggetti di tipo CAO. Riguardo gli oggetti SAO, dato che si vogliono fornire servizi indipendenti ai diversi client ed essi non devono condividere uno stato comune, si è scartata anche la possibilità di utilizzare gli oggetti di tipo Singleton. La scelta finale ricade dunque negli oggetti SAO SingleCall. Il Listener sarà composto da una unica classe Listener, che conterrà l’elenco di tutti gli oggetti SAO SingleCall richiamabili dagli applicativi client. Ognuno di tali oggetti implementerà l’interfaccia per consentire le chiamate remote da client. La struttura base del listener è riportata in appendice C. In questa tesi sono state sviluppate, oltre al listener, le classi QueryLocal che implementa l’interfaccia IQuery, EventLocal che implementa l’interfaccia IEvent, ResultLocal che implementa l’interfaccia IResultAdmin, EntityLocal che implementa l’interfaccia IEntity. L’interfaccia IQuery permette le operazioni di aggiunta, modifica ed eliminazione di una query su database. Essa permette inoltre di ritornare un oggetto serializzabile Query al client. L’interfaccia IEvent permette di aggiungere, modificare ed eliminare un evento su database. Essa inoltre permette di ritornare una lista di oggetti serializzabili Event al client. L’interfaccia IEntity permette di aggiungere modificare ed eliminare un entità su database. Essa inoltre permette di ritornare una lista di oggetti serializzabili Entity al client. L’interfaccia IResultAdmin estende l’interfaccia IResult. IResult consente di ritornare al client un oggetto Result cercandolo per ID, ritornare una lista di Result fornendo alcuni parametri di ricerca, ritornare il datatable che rappresenta il risultato, eseguire una certa query e salvare il risultato. Gli altri servizi offerti dal Listener, non essendo stati sviluppati dall’autore, non trovano trattazione nel seguito. Le classi QueryLocal, EventLocal, ResultLocal e EntityLocal istanziano al momento della creazione, l’oggetto che implementa l’interfaccia IPropertiesFramework per l’iterazione con il database.

4.1.4

Schema Logico Database (Schema Properties)

4.1.5

Stored Procedures

Le stored procedure atte all’esecuzione delle query remote sono state sviluppate in modo modulare, partendo dall’interfaccia PropertiesFra-

39

Moduli A e B

class Proj ect «interface» PropertiesFramework::IPropertiesFramework + + + + + + + + + + +

ExecuteAndSaveResult(int?, int?, int?, int?) : bool ExecuteAndSaveResultAsync(int?, int?, int?) : int PropertiesFramew ork::PropertiesFramew orkImpl GetEntityList() : DataTable GetEventList() : DataTable GetQueryList(bool) : DataTable GetQueryResultList(int?) : DataTable GetRemoteQueryResult(int?, string, int?) : DataSet GetSavedQueryResult(int?, int?) : DataSet -propertiesFwkHandler GetSavedResult(int?) : DataTable MarshalByRefObject SaveQuery(string, int?, int?, string, bool?, int?, int?, int?) : int SaveResult(int?, int?, int?, DataSet, int?) : bool PropertiesFramew ork::EntityLocal

-propertiesFwkHandler

-resultHandler-propertiesFwkHandler

-

propertiesFwkHandler: IPropertiesFramework

MarshalByRefObject

«interface»

PropertiesFramew ork::Ev entLocal -

TEC::IEntity

propertiesFwkHandler: IPropertiesFramework

+ + + +

Add(Entity) : Entity Delete(Entity) : void GetAll() : List<Entity> Update(Entity) : Entity MarshalByRefObject

«interface»

PropertiesFramew ork::QueryLocal

TEC::IEvent + + + +

Add(Event) : Event Delete(Event) : void GetAll() : List<Event> Update(Event) : Event

-

propertiesFwkHandler: IPropertiesFramework

«interface» TEC::IQuery + + + + + + +

MarshalByRefObject PropertiesFramew ork::ResultLocal -

resultHandler: IPropertiesFramework

Add(Query) : Query Delete(Query) : void Get(string) : Query GetAll() : List GetAll(Event) : List GetByKey(int?) : Query Update(Query) : Query

«interface» TEC::IResult «interface» TEC::IResultAdmin + + +

Add(Result) : Result Delete(Result) : Result Update(Result) : Result

+ + + + + + + +

ExecuteAndSaveResult(Query, Ticket) : bool ExecuteAndSaveResultAsync(Query, Ticket) : void GetAll(int?) : List GetAll(Query, int?) : List GetByKey(int?) : Result GetQueryResultList(Ticket) : DataTable GetResult(Query, Ticket) : DataSet GetSavedQueryResult(Query, Ticket) : DataSet

Figura 4.3: Servizi offerti dal Server Listener

40

4. Implementazione

TECUser Query Entity PK

EntityID Description

PK

QueryID

U1 FK1

QueryDescription FK_EntityID SAPNote IsPublic FK_TECUserID QueryText FK_EventID QueryOrder TimestampChg TimestampDate

FK3 Event PK

EventID

FK2

Description

PK

TECUserID

U1

NTUserName FirstName LastName EMail LastLoginDate FK_DepartmentID Active TimestampChg TimestampDate

Result PK

ResultID

FK3 FK4

FK_QueryID FK_TECUserID ExecutionResult FK_TicketID TimestampChg TimestampDate FK_BatchID Error

FK1

FK2

Ticket PK

TicketID

FK1

FK_CompanyBackupID FK_CompanyDatabaseID FK_TicketStatus TicketStatusDate FK_OwnerID TicketCreationDate TimestampChg ComputCol TimestampDate

Batch Status PK

StatusID Description

PK

BatchID

FK3

FK_StatusID RequestTime FK_QueryID FK_TicketID

FK2 FK1

U1

Figura 4.4: Schema Logico DB (Schema Properties)

mework e sviluppando i moduli sottostanti. Data la necessità di eseguire query non note a priori, con result set non noto a priori e con server\istanze che possono cambiare dinamicamente, si è fatto uso di Dynamic Sql. A fronte di una maggiore flessibilità gli svantaggi maggiori sono il problema di SQL injection e l’uso di EXEC() per query pass-through che non possono essere ottimizzate dal query plan. Il problema di SQLInjection non rientra nei presupposti di utilizzo, in quanto i consulenti hanno comunque accesso a SSMS. Le query sono sempre e comunque manipolate da utenti con il dovuto training per l’utilizzo delle medesime. Non utilizzare il DynamicSql significa comunque dover spostare parte della logica all’esterno del database (ad esempio in codice di alto livello C#). Questo non aumenta la velocità di esecuzione ed inoltre costringe a gestire le transazioni dall’esterno del database. Le stored procedure più significative per lo sviluppo del MODULO A sono qui riportate. [Properties].[LinkedServerConn] La stored procedure [Properties].[LinkedServerConn] crea una connessione tramite linked server al database remoto selezionato sulla base dei parametri in ingresso e ritorna il nome stesso del linked server. I parametri di ingresso sono: • @intTicketID: identificativo del TEC Ticket • @strHost: backend server

41

Moduli A e B

• @strInstance: backend instance • @intEntityID: stabilisce se la connessione deve essere al CompanyDb o all’ Sbo-Common NOTA: In caso venga aggiunto un nuovo tipo di database (detto Entity nella SP) e sia necessario eseguire delle query su di esso, allora deve essere aggiunto nei due statement SELECT la signature del linked server e del nome del database Si può osservare come sono stati nominati i Linked Server per: • CompanyDb: HOST_INSTANCE_TICKETID • SBOCommon: HOST_INSTANCE_TICKETID_COM___ La stored procedure, una volta determinato il percorso al linked server, verifica se questo è già presente nella tabella master.sys.sysservers (tabella ove vengono memorizzate tutte le connessioni a Db remoti). Nel caso in cui un linked server non sia già presente, esso viene creato al momento. [Properties].[GetRemoteQueryResult] Questa SP è utilizzata per eseguire una query su un server remoto. I parametri di input sono: • @intTicketID: Identificativo del ticket • @strRemoteQuery: Testo della query da eseguire • @intEntityID: Il target della query ( Company-Db o SBO-COMMON) Questa query richiama [Properties].[GetHostInstance] per recuperare l’host e la istanza in cui il database è stato ripristinato. Quindi richiama [Properties].[LinkedServerConn] per acquisire il nome del linked server ed infine richiama [Properties].[ExecRemoteQuery] per eseguire la query sul server remoto e tornare il dataset contenente il risultato. [Properties].[GetSavedQueryResult] Questa query esegue una query su linked server remoto e torna il risultato. A differenza di [Properties].[GetRemoteQueryResult], la query da eseguire in questo caso è salvata su db. Tale SP è pensata per l’esecuzione di query ricorrenti, ossia query comunemente eseguite durante le procedure di pre/post-restore, pre/post-backup. Gli unici parametri di ingresso sono in questo caso il TicketID e il QueryID. L’uscita è data dal Result Set.

42

4. Implementazione

intTicketID

intEntityID

strRemoteQuery

intTicketID

GetRemoteQueryResult

EntityID: 1 – CompanyDB 2 – SBOCOmmon

GetHostInstance

strHost strInstance

LinkedServerConn

strLinkedServer

ExecRemoteQuery

RESULTSET ( xml representing a datatable )

Figura 4.5: Stored Procedure GetRemoteQueryResult

[Properties].[GetHostInstance] Questa SP è una semplice query che prende come parametro di ingresso il TicketID e ritorna l’Host e l’Istanza in cui il database è stato ripristinato. [Properties].[ExecRemoteQuery] Questa SP è sviluppata utilizzando il Sql Server CLR per l’esecuzione del comando EXECUTE(’strRemoteQuery’) AT [strLinkedServer], ovverosia per eseguire una query su linked server remoto e acquisirne il risultato. è stato necessario in questo caso ricorrere all’uso del CLR in quanto Sql Server non lascia nidificare 2 comandi EXECUTE. Le due possibili soluzioni erano l’uso del CLR o l’uso della SP di sistema sp_executesql. In questo caso è stato scelto di utilizzare il CLR solamente per la sintassi più chiara.

4.1.6

Indici

La scelta degli indici si basa sulla quantità di dati contenuti nelle diverse tabelle, sui campi di ricerca più utilizzati, il grado di INSERT e UPDATE confrontato con le operazioni di SELECT. Nelle tabelle Event, Entity e Status è stato inserito un indice non clustered per garantire l’unicità della descrizione (Description).

43

Moduli A e B

GetSavedQueryResult intTicketID

intQueryID

VIEW_Query

SELECT performed

intTicketID strQueryText intEntityID strRemoteQuery

GetRemoteQueryResult

RESULTSET ( xml representing a datatable )

Figura 4.6: Stored Procedure GetSavedQueryResult

Per comprendere come impostare gli indici nelle rimanenti tabelle si deve fare riferimento alle operazioni eseguite dalle stored procedure: • GetBatch: Accede in scrittura a tutte le colonne e torna l’ID corrente. • GetBatchList: Ricerca per QueryID e TicketID su tabella Batch. • GetEntityList, GetEventList eseguono una select completa. • GetHostInstance esegue una ricerca per TicketID su Properties.VIEW_TicketCompanyDbBackend • GetQueryList accede a Properties.VIEW_Query con chiave di ricerca IsPublic e QueryText. • GetQueryResultList accede a Properties.VIEW_QueryResult con chiave di ricerca in TicketID • GetResult accede a Properties.VIEW_Result con chiave di ricerca in ResultID • GetSavedQueryResult accede a Properties.VIEW_Query con chiave di ricerca in QueryID

4. Implementazione

44

• LinkedServerConn accede alla tabella di sistema master.sys.sysservers con chiave di ricerca in srvname • SetBatch accede in scrittura alla colonna FK_StatusID di Properties.Batch con chiave di ricerca in BatchID • SetQuery accede in scrittura a tutte le colonne e torna l’ID corrente • SetQueryResult richiama SetQuery e SetResult • SetResult accede a VIEW_Result in scrittura su tutte le colonne e torna l’ID corrente Nella lista sopraindicata sono indicate in grassetto le condizioni che suggeriscono l’aggiunta di un indice. Su Batch viene aggiunto un indice non cluster per QueryID e TicketID, dato che l’indice clustered è impostato su BatchID. Gli indici sulle viste (come nel caso di VIEW_TicketCompanyDbBackend) offrono miglioramenti se le tabelle sottostanti sono scarsamente aggiornate [9]. Questa situazione è verificata nella vista VIEW_TicketCompanyDbBackend che accede a Properties.VIEW_HostInstance, Core.CompanyDatabase e Core.Ticket. Properties.VIEW_HostInstance e Core.CompanyDatabase sono ad alta lettura ma basso tasso di INSERT e UPDATE praticamente nullo. Core.Ticket ha la chiave primaria su TicketID che è intero autoincrementante. Per quanto detto una indicizzazione è opportuna. VIEW_Query riflette la tabella Query e accede ad una elevata quantità di dati, equivalente ad una select * per cui non ha senso eseguire una indicizzazione. VIEW_QueryResult esegue una ricerca per TicketID, dove TicketID è salvato sulla tabella Result. In questo caso, invece di inserire un indice sulla vista,è più opportuno indicizzare direttamente la tabella Result aggiungendo un indice su TicketID di tipo unclustered, che ammetta duplicati. Nel caso della tabella di sistema master.sys.sysservers, dato che i linked server saranno potenzialmente molti, la colonna srvname, utilizzata dalla SP LinkedServerConn, deve essere indicizzata. Questo conclude la fase di indicizzazione.

45

Moduli A e B

4.1.7

Triggers e Jobs

In questa sezione si valuta l’eventuale inserimento di triggers e Sql Jobs. L’unica operazione che non può essere realizzate tramite il modello relazionale in oggetto è quella di controllare che le query siano inserite, modificate ed eliminate da TECAdmin. Questo si può ottenere modificando il modello logico del database oppure inserendo un trigger per le operazioni INSERT / UPDATE / DELETE nella tabella Query o inserendo un controllo su tutte le stored procedure che accedono a tale tabella. • La modifica alla struttura del database è sconsigliata dato che altre interfacce di accesso si basano sulla struttura attualmente in uso. • Inserire un controllo sulle Stored Procedure che accedono alla tabella è altresì sconsigliato in quanto questo significa assicurare che tutte le query sviluppate debbano contenere gli stessi controlli. Inoltre, il controllo che si vuole implementare è una proprietà sulla tabella e non sulle SP che vi accedono. • L’uso del trigger è suggerito in quanto la tabella sarà utilizzata prevalentemente per operazioni di lettura (SELECT) e in modo minoritario per UPDATE e DELETE. Tale soluzione svincola gli sviluppatori DBA dal dover definire di volta in volta i controlli che devono essere eseguiti sulla tabella query. Per quanto esposto, è stato inserito un trigger per le operazioni di INSERT, UPDATE e DELETE nella tabella [Properties].[Query]. Per poter garantire che il DELETE venga effettuata esclusivamente da un TECAdmin, questa operazione è stata inglobata nella stored procedure [Properties].[DeleteQuery] e preceduta da una operazione di UPDATE riportante l’userID di chi sta effettuando l’operazione. La struttura base del trigger è la seguente: 1 2 3 4

CREATE TRIGGER [Properties].[tgr_AdminExclusiveAllowance] ON [Properties].[Query] FOR INSERT, UPDATE, DELETE AS

5 6

DECLARE @intCurrentID int

7 8 9 10 11

IF EXISTS(SELECT FK_TECUserID FROM INSERTED) AND EXISTS(SELECT FK_TECUserID FROM DELETED) BEGIN PRINT ’UPDATE’;

12 13 14

IF -- Is admin or manager BEGIN

4. Implementazione

15 16 17 18 19 20 21 22 23

46

-- Complete update RETURN END ELSE BEGIN ROLLBACK RETURN -- EXIT POINT END

24 25

END

26 27 28 29

IF EXISTS(SELECT * FROM INSERTED) -- Is an INSERT BEGIN PRINT ’INSERT’;

30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46

IF -- Is admin or manager BEGIN -- Complete admin RETURN END ELSE BEGIN ROLLBACK RETURN -- EXIT POINT END END ELSE PRINT ’DELETE’; -- delete is always executed. Must be combined in -- Properties.DeleteQuery

La tabella RESULT contiene potenzialmente una elevata quantità di dati e deve quindi essere valutata una strategia per mantenere esclusivamente le informazioni rilevanti. Le possibili soluzioni sono: • Utilizzare il partizionamento delle tabella, per spostare risultati associate a ticket chiusi su una tabella di archivio (per esempio ResultArchive). • Inserire un trigger nella tabella Core.Ticket che elimina I risultati sulla tabella RESULT ogni qual volta un ticket viene settato nello stato chiuso • Creare un Sql Job per cancellare I risultati nella tabella RESULT per tutti i ticket con stato chiuso. La soluzione da adottare si basa sulle seguenti considerazioni: • Mantenere una tabella partizionata [20] è sconsigliato in quanto database associate a ticket chiusi verranno eliminate nell’arco di poco tempo e quindi I risultati salvati non sono più di alcuna utilità.

47

Moduli A e B

Esiste la possibilità che un ticket venga riaperto ma questo si verifica nel 5% dei casi, condizione per cui non si giustifica il mantenimento di un archivio dei risultati pregressi. • Un trigger garantisce che i risultati vengano eliminate non appena il ticket viene posto in stato ’Dropped’ ma ha lo svantaggio di essere esoso in termini di risorse. • Un Job Sql può essere impostato per eliminare I risultati di ticket chiusi e può essere eseguito in orari in cui il server non è utilizzato in maniera intensiva. Il Job richiede meno risorse di un trigger ed è possible impostare la frequenza con cui esso debba essere eseguito sulla base del carico di lavoro sul server. Dato che l’eliminazione immediate alla chiusura del ticket non è un requisito fondamentale, l’implementazione è stata fatta tramite Sql Job. Si faccia riferimento al Sql Job [Properties].[DeleteResultsWithDroppedTicket] per l’implementazione.

4.1.8

Transazioni

Le stored procedure non sono di per sè transazionali e deve pertanto essere condotta una verifica per ciascuna stored procedure al fine di individuare il livello di isolamento più opportuno, tenuto conto delle proprietà di atomicità, consistenza, isolamento e persistenza delle transazioni [16], secondo la figura seguente:

Figura 4.7: Livelli di Isolamenteo [16]

In tabella 4.1 sono stati analizzati, stored procedure per stored procedure, i fenomeni permessi sulla base dei quali è stato scelto il livello di isolamento in grado di soddisfare le restrizioni imposte usando come riferimento per la scelta la tabella di figura 4.7.

4. Implementazione

48

Per una descrizione più dettagliata dei livelli di isolamento si rimanda alla lettura di [7].

SetBatch SetQuery SetQueryResult SetResult

LinkedServerConn

Stored Procedure GetBackendRootList Reset SetDirectory SetFile SetServer DeleteQuery ExecRemoteQuery GetBatch GetBatchList GetEntityList GetEventList GetHostInstance GetQueryList GetQueryResultList GetRemoteQueryResult GetResult GetSavedQueryResult

Phantoms Allowed Allowed Allowed Allowed Allowed Allowed Not Allowed Allowed Allowed Allowed Allowed Not Allowed Allowed Allowed Not Allowed Allowed Allowed Not Allowed Not Allowed Allowed Not Allowed Allowed Not Allowed Allowed Allowed Allowed Allowed

Dirty Read Not Allowed Allowed Allowed Allowed Allowed Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed

Lost Updates Not Allowed Allowed Allowed Allowed Allowed Not Allowed Allowed Allowed Not Allowed Allowed Allowed Allowed Allowed Allowed Allowed Allowed Allowed Allowed Allowed Allowed Allowed Allowed Allowed Not Allowed Not Allowed Not Allowed Allowed

Tabella 4.1: Analisi delle Transazioni

Non Repet. Read Allowed Allowed Allowed Allowed Allowed Allowed Not Allowed Allowed Allowed Allowed Allowed Not Allowed Allowed Allowed Allowed Allowed Allowed Allowed Allowed Allowed Allowed Allowed Allowed Allowed Allowed Allowed Allowed

Transaction READ COMMITTED SNAPSHOT READ UNCOMMITTED READ UNCOMMITTED READ UNCOMMITTED READ UNCOMMITTED READ COMMITTED SNAPSHOT SNAPSHOT READ COMMITTED SNAPSHOT READ COMMITTED SNAPSHOT READ COMMITTED SNAPSHOT READ COMMITTED SNAPSHOT SNAPSHOT READ COMMITTED SNAPSHOT READ COMMITTED SNAPSHOT SNAPSHOT READ COMMITTED SNAPSHOT – – SNAPSHOT – – – SNAPSHOT READ COMMITTED SNAPSHOT READ COMMITTED SNAPSHOT READ COMMITTED SNAPSHOT READ COMMITTED SNAPSHOT

49 Moduli A e B

4. Implementazione

4.1.9

50

IO Risultati da server

Il risultato di una query deve essere salvato su server. Le query che tipicamente vengono eseguite, sono query utilizzate per acquisire informazioni relative al database come la versione, eventuali incongruenze di inventario, problemi di riconciliazione, ... . Per un esempio di query da eseguire prima della fase di upgrade si faccia riferimento agli script 7_PreUpgradeCheck.sql e 17_IVUPreCalculationExample.sql (forniti dall’IBD). La prima query è di tipo informativo (tipi string con riferimento alle SAP Note), mentre la seconda fornisce informazioni circa i beni d’inventario affetti da anomalie. I risultati tipicamente attesi sono dunque query multi dataset con numero di colonne compreso tra 0 e 20 e circa 10 - 1000 righe. Le dimensioni di una tabella sono massimo 20000 campi (informazioni acquisite da interviste con l’IBD). In base alla tipologia di result-set da manipolare si è valutato come questi debbano essere salvati su server. Le possibilità analizzate sono state 3: • Creare a runtime una tabella risultato per ogni risultato fornito dalla query • Salvare i dati in formato XML La seconda soluzione introduce un overhead nei dati salvati in quanto essi sono accompagnati dallo schema xml (non essendo possibile stabilire a priori lo schema del result-set, è necessario salvarlo congiuntamente ai dati) e dai tag che ne descrivono la formattazione. Il vantaggio sta nella possibilità di caricare i dati su un datatable (o un dataset nel caso di risultati multipli) il quale può essere associato ad un datagrid per la visualizzazione. Con la prima soluzione si eviterebbe di salvare i dati con overhead ma i risultati verrebbero salvati in tabelle distinte, disgiunte tra loro, senza alcun legame con le query che li hanno gestiti se non tramite riferimenti alle tabelle, salvati come campi di tipo testo. Questo è controindicato in quanto si ignorerebbe la prima Regola di Codd, qui riportata: [4, 1. Information Rule Data is presented only in one way. As values in columns in rows. Simple, consistent and versatile. A table (aka an entity or relation) is a logical grouping of related data in columns and rows. Each row (aka record or tuple) represents a single fact and each row contains information about just one fact. Each column (aka field or attribute) describes a single property of an object. Each value (datum) is defined by the intersection of

51

Moduli A e B

column and row. ] Un risultato di esecuzione può essere visto come dato omogeneo, il fatto di salvare dati omogenei su tabelle diverse scorrelate tra loro non conviene alla prima regola di Codd. Per quanto detto si è decisa una implementazione con salvataggio dei dati in formato XML. Data una query, questa viene salvata all’interno di un SqlCommand il quale viene a sua volta incapsulato in un SqlDataAdapter per fornire il risultato sottoforma di Dataset: 1 2 3 4 5 6

SqlCommand cmd = new ... SqlDataAdapter adapter = new ... DataSet dataSetResult = new ... [...] adapter.SelectCommand = cmd; adapter.Fill(dataSetResult);

Il dataset può quindi essere analizzato per estrarre le tabelle, ognuna delle quali rappresenta un risultato. 1

DataTable selectedDT = dataSetResult.Tables[indexTable];

I dati in formato XML vengono quindi estratti e salvati in uno stream in memoria 1 2 3

MemoryStream memXmlStream = new ... DataTable selectedDT = dataSetResult.Tables[indexTable]; selectedDT.WriteXml(memXmlStream, XmlWriteMode. WriteSchema);

Si noti come lo stream venga salvato accompagnato dallo Schema XML dei dati contenuti. L’esempio di un risultato salvato su server è riportato in figura: 1 2

3

4 5 6 7 8 9

10

<xs:schema xmlns="" xmlns:xs="http://www.w3.org/2001/ XMLSchema" xmlns:msdata="urn:schemas-microsoft-com: xml-msdata" id="NewDataSet"> <xs:element name="NewDataSet" msdata:IsDataSet="true" msdata:MainDataTable="Table2" msdata: UseCurrentLocale="true"> <xs:complexType> <xs:choice minOccurs="0" maxOccurs="unbounded"> <xs:element name="Table2"> <xs:complexType> <xs:sequence> <xs:element name="Version" type="xs:int" minOccurs="0" />

4. Implementazione

11 12 13 14 15 16 17 18 19 20

52

860035

Lo schema XML viene a sua volta utilizzato per creare un oggetto di tipo SqlXml per essere salvato su DB: 1 2 3

4 5

SqlParameter tmpParam = null; [..] tmpParam = new SqlParameter("@xmlExecutionResult", SqlDbType.Xml); tmpParam.Value = new SqlXml(memXmlStream); cmd.Parameters.Add(tmpParam);

Allo stesso modo i risultati salvati in formato XML vengono caricati da DB e il datatable viene ricostruito sulla base dello schema che li accompagna: 1 2 3 4 5 6

SqlXml xmlResult = null; SqlDataReader rdr = ... xmlResult = rdr.GetSqlXml(0); XmlReader xmlReader = xmlResult.CreateReader(); DataTable dt = new DataTable(); dt.ReadXml(xmlReader);

Si noti inoltre che nel caso insorga il problema di gestire resultset con dimensioni più esose è possibile usare uno FileStream invece di un MemoryStream e quindi salvare direttamente su disco senza caricare in memoria. Lato client, il risultato verrà visualizzato su un DataGridView tramite il comando: 1 2

Result tmpResult = ... dataGridViewResult.DataSource = tmpResult.ExecutionResult

dove tmpResult.ExecutionResult ritorna il DataTable remoto, precedentemente caricato con i comandi sopradescritti.

4.2

MODULO C

Il Modulo C fa uso dell’applicativo BackupManager e dello script di Shrink Distribuito.

53

MODULO C

4.2.1

Applicazione BackupManager

ServerManager rappresenta la console grafica che si occupa di raccogliere le informazioni dai server (server, cartelle e file contenuti) e salvarle su database. In figura 4.9 è rappresentata la classe ServerManager, che fa uso della classe BackupManager la quale contiene 2 metodi statici GetBackendRootList per recuperare da server l’elenco dei server e il metodo FillBackupManagerIntoDb per salvare su Db i dati raccolti. Questo secondo metodo ha come parametro d’ingresso la lista dei server precedentemente inizializzata. Si noti che BackupManager non si interfaccia direttamente col database, ma fa uso della implementazione BackupManagerFramework di IBackupManagerFramework.

Figura 4.8: Interfaccia con la Base Dati per Backup Manager

In figura 4.8 è riportato il diagramma delle classi che rappresenta le entità Server, Folder e File. Si noti come tale diagramma derivi direttamente dal modello ER del database descritta alla sezione 3.1.3.

4.2.2

Shrink Distribuito

L’operazione di shrink deve essere eseguita su server Sql2000 e Sql2005 (ed essere compatibile con la futura versione Sql 2008). Dato che l’interrogazione dei database deve avvenire su tutti i server sono state analizzate diverse possibilità tra cui: • Il Multi Server Management di Sql Server 2008 che però non è compatibile con le versioni precendenti di Sql Server • Il CLR (Common Language Runtime) di Sql Server 2005 può essere adattato per l’esecuzione di operazioni su server 2008, 2005 e 2000 ma sarebbe utilizzato con classi di alto livello quali SqlConnection, SqlComman per cui risulta equivalente ad un applicativo esterno.

54

4. Implementazione

class Class Model

Serv er -

folderList: List name: string root: string

+ + + +

GetFolderList() : List GetName() : string GetRoot() : string Server(string, string) Folder

«interface» IServer + + +

-parentServer

GetFolderList() : List GetName() : string GetRoot() : string

-

dirInfo: DirectoryInfo fileList: List parentServer: IServer

+ + + + + + + + +

Folder(IServer, DirectoryInfo) GetCreationDate() : DateTime GetFileList() : List GetFolderInfo() : DirectoryInfo GetFolderList(IServer) : List GetLastModification() : DateTime GetName() : string GetNumberOfFiles() : int GetServer() : IServer

File -

fileName: string fileT ype: string parentFolder: IFolder

+ + + + + -

File(IFolder, string, string) GetFileList(IFolder) : List GetFileType() : string GetFolder() : IFolder GetName() : string recursiveSearch(IFolder, List*) : void

«interface» IFolder + -parentFolder + + + + + +

GetCreationDate() : DateTime GetFileList() : List GetFolderInfo() : DirectoryInfo GetLastModification() : DateTime GetName() : string GetNumberOfFiles() : int GetServer() : IServer

«interface» IFile + + +

GetFileType() : string GetFolder() : IFolder GetName() : string

Figura 4.9: Interfacce e Implementazioni per Backup Manager

55

MODULO C

• SMO (Sql Management Object) consente l’accesso a Sql2000 e Sql2005 ma la gestione avviene da un applicativo esterno e quindi assimilabile al CLR. • I linked server garantiscono compatibilità con Sql 2000, 2005 e 2008. Vengono implementati a livello database, consentono l’accesso remoto ai server, offrono la possibilità di eseguire query distribuite, possono eventualmente essere estesi per l’utilizzo con data source differenti (ma risultano ottimizzati per l’impiego con provider di dati sql server). Lo svantaggio principale risiede nella configurazione dell’ambiente distribuito, che deve essere fatto su ogni server (si veda lo script Project.sql) e nella maggior complessità delle query distribuite. Si è scelto di sviluppare lo script ricorrendo ai LinkedServer, in quanto a fronte di una maggiore complessità di computazione, la velocità di esecuzione risulta più elevate grazie ai piani di esecuzione che vengono ottimizzati da Sql Server una volta che lo script è memorizzato come Stored Procedure o Job. A questo punto, una volta configurati I linked server per il supporto alle query distribuite resta da definire la modalità di interrogazione dei vari database. Le possibilità sono: • Collegamento ai linked servers uno dopo l’altro ed esecuzione della procedura di shrink nell’ordine in cui vengono trovati I database • Collegamento ai linked server uno dopo l’altro, acquisizione di informazioni circa lo spazio che è possible liberare da ogni database, ordinamento dei DB per spazio avibile decrescente ed esecuzione della procedura di shrinking secondo il nuovo ordine. I vantaggi della prima soluzione sono: • la necessità di collegarsi una sola volta ad ogni linked server • non è necessario interrogare ogni sinolo database per acquisire informazioni circa lo spazio allocate che è possible liberare • minor tempo necessario per implementare la soluzione Gli svantaggi sono • necessità di eseguire lo shrink su tutti I database in quanto non è nota la quantità di spazio liberabile tramite la procedura di shrink • lungo tempo di attesa prima che venga processato l’ultimo server

4. Implementazione

56

I vantaggi offerti dalla seconda soluzione sono: • Possibilità di definire l’operazione di shrink solo per database che superano una certa soglia di spazio allocato che è possibile liberare. Questo garantisce che lo shrink venga eseguito solamente sui database che realmente offrono un vantaggio in termini di spazio deallocabile. Si ricorda infatti che un database di medie-grosse dimensioni (40 - 100 GB) appena ripristinato avrà poco spazio allocato ma l’operazione di shrink sarà comunque lunga. • Possibilità di raccogliere alter informazioni durante l’operazione di shrink Ipotizzando una equidistribuzione dei database nei vari server (come effettivamente è) l’operazione di shrink viene effettuata su diversi server già nelle prime fasi dell’elaborazione e non c’è più ordinamento sequenziale dei server. Questo significa che se uno dei server con meno spazio a disposizione contiene database con elevato spazio allocato che si può liberare, esso verrà posizionato in testa alla coda di elaborazione. Gli svantaggi risultano: • Overhead introdotto nella prima fase per la raccolta dati database per database • Necessità di connessione a linked server alternati, che rallenta il tempo di esecuzione (fattore questo non significativo dato che lo shrink è operazione molto più dispendiosa in termini di tempo se comparata al tempo necessario alla connessione ad un linked server). • Maggior complessità computazionale • Necessità di diversificare la modalità di calcolo dello spazio allocato per server sql server 2000 e sql server 2005 in quanto differenti. Lo script DistributedShrink_V2.sql riporta l’implementazione dell’operazione di shrink. La logica dell’algoritmo e le scelte adottate sono qui descritte: Lo script di shrinking distribuito esegue in 5 fasi: 1.Raccolta Linked Servers Crea una temporary table contenente le informazioni essenziali per accedere ai server quali nome e istanza del server, nome del linked server associato al server\istanza, l’indicazione se il server e l’istanza sono attivi e un campo ConnectionError per stabilire se la connessione al linked

57

MODULO C

server ha esito positivo o meno. Tutti i linked server vengono controllati tramite la SP di sistema sp_testlinkedserver per verificarne il corretto funzionamento. In caso di errore il campo ConnectionError viene posto ad 1. Solamente le istanze che hanno superato il test di connessione vengono inserite nella tabella temporanea delle istanze attive #tmpActiveInstances. 2. Raccolta informazioni da ogni server Viene creata la tabella #tmpDbStatistics dove vengono salvate le informazioni relative a tutti i database presenti sui server precedentemente selezionati. In questo caso è stato necessario considerare se il server in oggetto è un server SQL2000 o SQL2005. Questo perché le informazioni relative agli oggetti contenuti nel server si possono avere interrogando oggetti del master database differenti (la tabella di sistema sysaltfiles e la tabella sysdatabases su SQL 2000, la vista sys.master_file e la vista sys.systemdatabases su SQL2005). In ambo i casi le dimensioni del database sono memorizzate come numero di pagine da 8KB. Le informazioni vengono reperite tramite l’esecuzione di query dinamica, con la SP di sistema sp_executesql. 3. Raccolta informazioni da ogni database Durante questa fase vengono raccolte informazioni relative allo spazio allocato non utilizzato da ogni database (oggetto della successiva fase di shrink). SQL Server mette a disposizione in questo caso la stored procedure sp_spaceused [8]. Il problema consiste nel fatto che tale stored procedure contiene più di un result set. La direttiva INSERT INTO può essere usata in combinazione con una stored procedure solo se questa restituisce un unico result set, altrimenti non è possibile gestirla. In questo caso si è deciso di implementare manualmente lo script equivalente alla SP sp_spaceused in modo da tornare un solo result set. Anche in questo caso la query da eseguire differisce tra SQL2000 e SQL2005. E’ importante ricordare che eseguire query sulle system table è una operazione non supportata da Microsoft. Microsoft può e cambia le informazioni qui salvate da release a release. In caso di upgrade è compito del programmatore provvedere al riallineamento dei dati [13]. Tale query calcola lo spazio occupato dal database (@dbsize), i bytes per pagina (@bytesperpage) e il totale delle pagine allocate. La differenza tra le dimensioni totali del database e le pagine realmente allocate dagli oggetti ci da lo spazio allocato non utilizzato. Una volta terminata tale procedura i dati di tutti i database attualmenti presenti nei server si trovano all’interno della tabella temporanea #tmpDbUnallocatedSpace. 4. Integrazione con Backup Manager

4. Implementazione

58

I dati relativi ai database presenti su server vengono copiati all’interno della tabella [BackupManager].[RestoredDatabase]. Tale operazione non riguarda l’operazione di shrinking ma permette di combinarla con l’operazione di controllo delle directory su server, minimizzando l’uso dei processi in esecuzione sui server. 5. Shrinking I database vengono ordinati per spazio allocato non utilizzato decrescente e viene effettuata l’operazione di shrinking solamente per i database con spazio allocato non utilizzato sopra una certa soglia (in MB) stabilita dall’utente. La procedura inizia controllando che il database non sia il tempdb. In tal caso esegue il comando sp_dboption [10] con l’opzione ’trunc. log on chkpt.’ per troncare il transaction log fino all’ultimo checkpoint (restore). Si noti che il processo di compattazione non ha lo scopo di migliorare le prestazioni del database (in realtà le peggiora in quanto la successiva operazione di inserimento o aggiornamento richiederà un incremento della dimensione del file dati che si traduce in una richiesta di spazio su disco da parte del DBMS al sistema operativo) ma ha il solo scopo di liberare spazio dal sistema. La successiva operazione è quella di impostare per ogni database (eccetti master e tempdb) l’opzione AUTOSHRINK attiva, il che consente di compattare automaticamente il database ad intervalli regolari. Viene quindi eseguita l’operazione di Shrink vero e proprio (comando SHRINKDATABASE) con le opzioni TRUNCATEONLY e NO_INFOMSGS. TRUNCATEONLY garantisce che lo spazio non allocato venga rilasciato (invece che compattato). Si noti che solo i file dati sono troncati, mentre i file di log non sono interessati da tale operazione. Per quanto appena detto, si rende necessaria anche una operazione di shrink dei file di log, tramite il comando SHRINKFILE per tutti i file di log attualmente in uso. Tale script è stato pensato per essere eseguito come Sql Server Job schedulato alle ore 20.00 GMT, ossia quando vi è il minor numero di utenti connessi e quindi minor uso dei server.

4.2.3

Schema Logico Database (Schema BackupManager)

Viene qui riportato lo schema logico della parte di database afferente allo schema BackupManager. Le stored procedures che si interpongono tra l’interfaccia IBackupManagerFramework e le tabelle Backend Server,Directory e File sono: • [BackupManager].[Reset] per eliminare il contenuto delle suddette tabelle

59

MODULO C

• [BackupManager].[SetServer] per inserire Nome e Root di ogni server ritornando il ServerID • [BackupManager].[SetDirectory] per inserire ServerID, nome, data di creazione, data di ultimo accesso, numero di file della cartella ritornando il Directory ID • [BackupManager].[SetFile] per inserire nome, estensione, Directory ID della cartella di appartenenza e ritornando il File ID. • [BackupManager].[GetBackendRootList] è utilizzata per reperire le informazioni relative ai server e alle rispettive root directory di backup durante la prima fase di raccolta informazioni. Questa stored procedure allo stato attuale si appoggia alla tabella [BackupManager].[BackendRootList]. La tabella [BackupManager].[RestoredDatabase] non ha alcuna relazione diretta con le tabelle BackendServer, Directory e File. Essa viene aggiornata ad ogni esecuzione dello script di Shrinking (pensata come operazione OLAP). L’elenco delle directory che non sono associate a nessun database vengono visualizzate dalla vista [BackupManager].[VIEW_OrphanDirectory] la quale effettua una operazione di confronto tra le tabelle Directory, BackendServer e la tabella dbo.CustomerDatabase. BackendServer PK

BackendServerID HostName BackupRoot

Directory PK

DirectoryID

FK1

Name CreationTime LastAccessTime NumFiles FK_BackendServerID RestoredDatabase File

PK

FileID

FK1

Name Type FK_DirectoryID

server_type linked_server database_name database_size unallocated_space

Figura 4.10: Schema Logico DB (Schema BackupManager)

60

4. Implementazione

Il risultato fornito dalla vista dopo una esecuzione dello script di Shrink e dell’applicativo BackupManager è riportato in figura 4.11.

Figura 4.11: Directories orfane

Lo script 2_BackupManager_DataAnalysis.sql permette di rilevare database replicati (ossia database con stesso nome allocati su molteplici istanze) e i database che non corrispondono a nessun Ticket registrato. Una esecuzione di tale script ha portato in luce l’esistenza di 568 database replicati e 68 database non associati ad alcun ticket, per uno spazio allocato eguale a circa 59Gb, come mostrato in figura 4.12. L’eliminazione delle cartelle orfane è operazione eseguita da un TECAdmin dopo opportuna verifica (devono infatti essere escluse le cartelle afferenti ai DemoDatabase). Lo script utilizzato per tale operazione è 16_DeleteOrphanDir.sql.

4.3

MODULO D

In questa sezione viene descritto come implementare la modifica al workflow proposto, riportato in figura 3.15. Per implementare il modulo di Forced Upgrade Process (FUP) devono essere definito un [Properties].[EVENT] a livello DB per ognuna delle sezioni GSC (sezioni diverse possono consentire o meno l’esecuzione di determinate query, a seconda del problema in analisi). Ogni EVENT viene registrato con una Description con prefisso ForcedUpg_ seguita dal nome della sezione GSC, ad esempio ForcedUpg_SYSTEM per l’area sistema, ForcedUpg_FINANCE per l’area finanza, e così via.

61

MODULO D

Figura 4.12: DBs non associati a Tickets

4. Implementazione

62

Nel momento in cui un Upgrade fallisce, il consulente può richiedere tramite PlugIn TEC un Forced Upgrade selezionando da un elenco l’area a cui appartiene. Il plug-in dovrà quindi richiamare tutte le query relative all’entity opportuna e rilanciare l’upgrade (Il procedimento di selezione ed esecuzione delle query può essere ripreso dal plug-in IVUAutomationClient). Per ognuno degli EVENT creati verranno aggiunte a mano a mano nuove queries, concordate dall’Upgrade Solution Desk (USD). L’USD è costituito da TECAdmin (designati dal System TeamLeader) e da membri dell’IBD di differenti aree (System, Finance, Logistic, ...). Scopo dell’USD è quello di analizzare le query proposte dai System consultant e decidere su quali EVENT tale query possono essere inserite. Nel caso in cui un Upgrade fallisca anche dopo il forced upgrade, il System Consultant procederà ad analizzare e rilevare i problema. Egli può avvalersi delle query eseguite durante l’FUP per escludere a priori determinate problematiche. Una volta risolto il problema, il System Consultant informerà l’USD tramite il processo di Upgrade Issue Knowledge Transfer il quale valuterà il problema, la soluzione proposta (effettuando eventuali modifiche se necessario) e registrerà la query nelle ENTITY di rilievo. Finito tale processo il consulente GSC verrà notificato dell’avvenuto upgrade. I vantaggi derivanti dall’uso di questa soluzione sono: • Minor carico di lavoro dei System Consultant a mano a mano che nuove query vengono aggiunte al sistema • Maggior velocità di risoluzione dei problemi per i GSC Consultant: La procedura FUP risulta più veloce di un controllo manuale e permette di controllare e risolvere problemi multipli in una sola esecuzione • Maggiore velocità di risoluzione dei problemi per i System Consultant, i quali possono escludere tutte le problematiche automaticamente rilevabili dalla procedura automatica • Knowledge transfer migliorato: I problemi rilevati durante la fase di upgrade vengono condivisi e la soluzione proposta viene controllata dall’IBD, che possiede maggiori informazioni circa le possibili implicazioni che una determinata query può avere nelle diverse aree. I punti critici, che devono essere valutati dai diversi GTL sono: • Modifica del workflow: è necessario modificare la pratica d’uso dei consulenti GSC e dei System Consultants

63

MODULO D

• Maggior carico di lavoro iniziale dei System Consultants: Le query proposte devono essere generiche, in modo da adattarsi a futuri usi piuttosto che precise per risolvere uno specifico problema su un certo database. • Necessità di definire i membri dell’USD e relativi compiti (controllo query, validazione, ...). A tal proposito si sono sviluppate le queries 6_OCRD_InconsistencyRemoval.sql e 14_RemoveDuplicatesOCPR_CRD1.sql per rimuovere alcune delle inconsistenze e duplicati che riguardano i Business Partners.

Capitolo

5

Risultati ottenuti In questo capitolo vengono riassunti i risultati raggiunti a seguito dell’implementazione dei moduli precedentemente progettati e sviluppati.

5.1

Moduli A e B

Il modulo relativo alla gestione delle query e dei risultati si è rilevato di immediato utilizzo: altri sviluppatori lo hanno utilizzato per l’automazione delle operazioni da effettuare immediatamente dopo il restore di un database (Evento AfterRestore) e prima di un upgrade (Evento BeforeUpgrade). L’autore ha inoltre utilizzato quanto sviluppato nei moduli A e B per estendere le funzionalità del Client TEC, aggiungenfo il PlugIn IVU riportato in appendice, che fa uso degli eventi IVUPreRecalculation, IVUPostRecalculation e delle query IVU_PreRecalculation_2005, IVU_PreRecalculation_2007, Diff_OpenQty_OINM_&_Qty_OITW_OITM_FIFO, Item_Neg_Qty_&_Pos_Inv_&_Viceversa, None_Recalculated_Documents_V5.16, OpenValue_smaller_than_0_for_FIFO_items, StockDiff_OINM&OITM&OITW_07A.V1.1. Lo schema Client-Server proposto si è rilevato conforme alle aspettative, i risultati a video sono fluidi e non si ha percezione di ritardo nel trasferimento dati. Il server listener è stato popolato dagli altri programmatori con i moduli da loro sviluppati.

5.2

Modulo C

Come si può vedere dalla Figura 5.1, lo snapshot sui server è decisamente migliorato (rispetto allo snapshot di figura 3.11): I file di backup non sono più presenti, i file .ldf (viola) hanno dimensioni inferiori ed è aumentato 65

5. Risultati ottenuti

66

lo spazio occupato dai file .mdf (blu) il che significa un maggior numero di database gestiti sul server.

Figura 5.1: Snapshot Sequoia dopo lo shrink e l’eliminazione delle cartelle orfane

Inoltre, schedulando lo shrink distribuito giornalmente, lo spazio allocato che viene liberato è di circa 70 Gb (media osservata su un arco di tempo di una settimana). Lo spazio allocato, rilasciato dall’operazione di shrink si può ottenere dalla query: 1 2 3

SELECT SUM(unallocated_space) FROM [BackupManager].[RestoredDatabase] WHERE unallocated_space > 0

Per valutare se tale spazio sia sufficiente a garantire che i server non vengano saturati, deve essere valutato il carico giornaliero di database che vengono ripristinati su server. La permanenza media di un database su server è pari a 45 giorni. Recentemente vengono ripristinati circa 30 database al giorno (come riportato dal grafico 5.2 della media mobile su 45 giorni). Mediamente vengono cancellati circa 35 database al giorno (Fig. 5.3). Questo risultato è in accordo con il dato sulla permanenza media dei database sui server. Se consideriamo che la dimensione media di un database è pari a 3.5GB (più 0.5GB per il backup compresso), lo spazio giornalmente liberato dall’operazione di shrink consente di sopperire alla richiesta di 10 database di dimensione media, pari al 33% della richiesta totale giornaliera. La differenza tra i database ripristinati e quelli cancellati, rilevata nell’ultimo periodo, fornisce un ulteriore incremento pari a (35-30) = 5 database pari al 16% della richiesta giornaliera.

67

Modulo C

Figura 5.2: Database ripristinati (media mobile su 45 gg)

Figura 5.3: Database cancellati (media mobile su 45 gg)

5. Risultati ottenuti

68

Sommando i due valori si ottiene un totale di incremento pari al 49% delle richieste. Tale valore si avvicina al guadagno di spazio pari al 41.06% rilevato dalla comparazione del report di backend nei mesi di novembre 2008 e marzo 2009 (Si vedano i file BackendInfo_28_11_2008.html e BackendInfo_22_03_2009.html). La differenza tra il 49% ed il 41.06% è in parte dovuta all’allocazione di ulteriori backup eseguita da alcuni TECAdmin durante la fase di migrazione da TEC 3 a TEC 4). In figura 5.4 viene riportata la differenza in percentuale tra lo spazio disponibile su server in novembre ’08 e marzo ’09.

Figura 5.4: Guadagno di spazio (in %) sui server di backend

La bontà del risultato ottenuto trova conferma nelle richieste di supporto per il ripristino manuale dei database restore falliti. Come si può osservare nel grafico di figura 5.5 le richieste sono drasticamente diminuite nel momento in cui è stato fatto il porting in produzione della soluzione descritta (01.02.2009) nonostante i database ripristinati siano aumentati. Osservando il grafico si nota come nei periodi precedenti, all’aumentare dei database ripristinati aumentavano le richieste di supporto da parte di un TECAdmin (eccetto il 17/07/2008). Comparando i report relativi allo spazio libero su server di Novembre 2008 e Marzo 2009 (si vedano i report BackendInfo_28_11_2008 e BackendInfo_22_03_2009) si ha un aumento dello spazio disponibile su server pari a 1277Gb pari ad un incremento del 26,35%. Lo script 5_DistributedShrink_V2.sql si è rivelato di particolare importanza per il modello con cui è stato costruito. Esso è infatti stato utilizzato per sviluppare altri 2 script (19_IRUProbeScript5.sql prima

69

Modulo D

Figura 5.5: Ticket richiesti e ripristini manuali

e 20_IRUProbeScript5.sql poi) richiesti da alcuni Consulenti nei tempi previsti (5 giorni su 7 assegnati).

5.3

Modulo D

Allo stato attuale non è possibile fornire una valutazione sugli obiettivi preposti dallo sviluppo del Modulo D data la prematura fase di test in cui si trova.

Capitolo

6

Conclusioni e Raccomandazioni In questo capitolo vengono riportate alcune considerazioni sorte durante la fase di sviluppo delle soluzioni ai problemi trattati.

6.1

Miglioramenti moduli A e B

Nel modulo A, si è scelto di interfacciare il datasource del DataGridView con il DataDataTable in quanto quest’ultimo ha la possibilità di essere generato a partire dallo schema in formato XML, su cui poi possono essere caricati i dati. Il problema principale sta nella ridondanza elevata introdotta dallo schema XML del DataTable. La soluzione proposta non si propone comunque di sostituire tutte le funzionalità fornite da SSMS. Il limite principale, è relativo alla trasmissione e visualizzazione di elevate moli di dati. I possibili miglioramenti possono essere alternativamente due: • creare uno schema xml personalizzato in cui i tag siano minimali, sostituendo ad esempio xs:element, xs:sequence, xs:choice, ... con tag e, s, c. Tale soluzione ridurrebbe notevolmente la quantità di dati trasmessi tra gli end-point. Lato client si potrebbe quindi rigenerare il DataTable con lo schema originale, riformattando lo schema xml ricevuto dal server. • creare un oggetto DataTable personalizzato, che implementi le interfacce IListSource ed ISerializable (o eventualmente IXmlSerializable). In questo modo IListSource permetterebbe all’oggetto di 71

6. Conclusioni e Raccomandazioni

72

interfacciarsi direttamente al DataGridView. L’interfaccia ISerializable permetterebbe di trasferire l’oggetto al server e di memorizzarlo come stream di byte o alternativamente l’interfaccia IXmlSerializable permetterebbe una funzionalità equivalente a quella implementata, con gli accorgimenti specificati al punto precedente. Modificando l’XML dello schema si ridurrebbe anche la quantità di dati immagazzinata sul server. L’interfaccia IPropertiesFramework potrebbe essere scissa in differenti interfacce come IPropertiesQuery, IPropertiesResult, IPropertiesBatch, IPropertiesEvent e IPropertiesEntity. Questo permetterebbe agli sviluppatori di gestire oggetti che implementano un minor numero di metodi eventualmente eseguendo cast diversi su IPropertiesFramework a seconda della funzionalità richiesta.

6.2

Miglioramenti modulo C

Durante la fase di Shrink distribuito, l’operazione di shrink potrebbe essere parallelizzata per eseguire su server diversi inserirendo una Stored Procedure CLR che, una volta ultimata la fase di raccolta informazioni da ogni server, ricorre ad un ThreadPool per eseguire lo shrink su server diversi. Si noti che non è necessario parallelizzare la raccolta informazioni in quanto il tempo di tale operazione è di qualche secondo, comparato con l’operazione di shrink (45 - 60 minuti).

6.3

Considerazioni Finali

Lo studio ha rilevato la mancanza di un supporto a livello database per il salvataggio di esecuzioni di query non note a priori su ambiente distribuito. Tale argomento offre spunti per una ricerca più approfondita sulle modalità di gestione di tali scenari.

Appendice

A

Raccolta Informazioni per la gestione query Il committente ha espresso le seguenti richieste durante la fase di raccolta informazioni: • Si vuole realizzare un sistema per permettere a consulenti e amministratori di poter eseguire query sui database utenti. Una query può essere eseguita sull’SBO-COMMON oppure sul COMPANY-DB del cliente. Le query possono avere più di un risultato. • Il risultato di una query necessita di essere salvato. • Ogni COMPANY-DB è legato ad un TEC Ticket. • Ogni TEC Ticket può contenere al più un COMPANY-DB ed un SBO-COMMON. • Lo script della query da eseguire può essere specificato dall’utente oppure può essere già esistente ed associato ad una SAP Note. • Una query può essere eseguita in un particolare momento, come ad esempio subito dopo un restore, prima o dopo un upgrade, prima di un backup. • Le query possono essere eseguite più volte su differenti ticket. • Ogni volta che la query viene eseguita può generare un risultato o un errore. • Ci possono essere più risultati della stessa query dovute a più esecuzioni, anche sullo stesso ticket. 73

A. Raccolta Informazioni per la gestione query

74

• Le query vengono eseguite sempre o sul COMPANY-DB o sull’SBOCOMMON ad esso associato. • Non si esclude la possibilità di eseguire in futuro query su tipi diversi di database ( ad esempio certi AddOn installano un nuovo database che riferisce al COMPANY-DB o all’ SBO-COMMON. • Ogni query può avere una descrizione della query stessa. • Ogni qual volta viene modificata una tabella nel database, deve essere possibile identificare se e quando la tabella è stata modificata. Questo serve data la natura asincrona dell’applicativo da sviluppare. • Quando viene eseguito un certo task, comprendente l’esecuzione di piu query, esso può specificare l’ordine in cui tali query vengono eseguite. • E’ compito del TECAdmin definire l’ordine con cui le query vengono eseguite. • Una certa query può essere disabilitata quando non la si vuole utilizzare. • Per ogni risultato deve essere possibile identificare la query che lo ha generato e il risultato della esecuzione deve essere salvato. • Il risultato di esecuzione deve essere solamente analizzato. Non devono essere fatte ulteriori query sul risultato. • Deve essere possibile inserire, modificare e cancellare query da parte dei TECAdmin. • Deve essere possibile inserire, modificare e cancellare risultati. In un secondo momento sono stati specificati i seguenti requisiti: • Alcune query possono avere tempi di esecuzione lunghi (fino a 3 giorni) e tali query devono essere NON bloccanti per l’appliativo client • Deve essere possibile controllare se una query è in esecuzione su un certo ticket ed evitare che essa venga lanciata nuovamente nel caso questo si verifichi • Deve essere possibile specificare un timeout massimo di esecuzione per le query con tempi di processamento lunghi.

Appendice

B

Elenco degli script realizzati • 1_BackupAllDatabases.sql : Crea un file di backup per ogni database presente nell’istanza dove lo script viene eseguito (TEC 3 o TEC 4). • 2_BackupManager_DataAnalisys.sql : Script utilizzato per l’analisi dopo aver caricato tutte le tabelle riferite dallo schema BackupManager. Vengono scritti a video il numero di database replicati, l’elenco dei database replicati, database non associati a ticket, spazio allocato dai database (TEC 3). • 5_DistributedShrink_V2.sql : Script per eseguire l’operazione di shrink su tutti i server (Modulo C, TEC 3) • 6_OCRD_Inconsistency_Removal.sql : Script per rimuovere incosistenze nella tabella OCRD (Business Partner Table). Usato nella fase di Test per il Modulo D. (TEC 3 o 4). • 8_Project.sql : Script utilizzato durante la fase di testing (TEC 3 o 4) • 9_Properties_Script.sql: Script per aggiungere lo schema Properties e le relative tabelle al database TEC 4. Usato nel porting in produzione. • 10_Query_MDF_LDF.sql : Script utilizzato per visualizzare l’elenco dei file .MDF e .LDF di tutti i database presenti nell’istanza ove lo script viene eseguito (TEC 3 o 4) • 12_UpgradeCheck_V2.sql : Script per i membri del System TEAM che serve a verificare: 75

B. Elenco degli script realizzati

76

– tabelle presenti nel Customer-DB, che non sono presenti nel Reference-DB – tabelle presenti sia nel Customer-DB che nel Reference-DB, con campi di differente tipo\lunghezza – tabelle presenti sia nel Customer-DB che nel Reference-DB con campi presenti SOLO nel Customer-DB (TEC 3) • 14_RemoveDuplicatesOCPR_CRD1.sql : Script per rimuovere incosistenze nelle tabelle OCPR (Contact Persons) e CRD1(Business Partners - Addresses). Usato nella fase di Test per il Modulo D. (TEC 3 o 4). • 15_Analysis.sql : Script utilizzato nella fase di analisi per il Modulo C. Visualizza: – una tabella con Anno, Mese, Anno\Mese, Numero Db Ripristinati raggruppati per mese – una tabella con Anno, Numero Db ripristinati per anno – Una tabella con il numero di Db ripristinati giornalmente (TEC 3) • 16_DeleteOrphanDir.sql : script utilizzato per cancellare le cartelle orfane, alla fine della raccolta informazioni eseguita nel Modulo C. (TEC 3 o 4) • 19_Utilities.sql : Script utilizzato per facilitare le operazioni eseguite dal DBA durante l’attività di amministrazione di TEC (TEC 3) • 21_IRUProbeScript5.sql : Script utilizzato per generare una tabella con le seguenti informazioni: – CustomerID del cliente – Nome del cliente – Numero del ticket – Linked server dove si trova il database – Nome del database – Versione attuale del database – Localizzazione del database

77 – Messaggio IRU (Corruzione IRU ripristinata, Corruzione IRU non ripristinata, Corruzione IRU non presente) – ID associato al Messaggio IRU – Storia degli upgrade eseguiti sul database – Indicazione se il ticket è un ticket di upgrade Nota: Per lo sviluppo del suddetto script si sono utilizzate le query fornite nel documento IBD_KP_IRU_query_Specification.doc dal dipartimento Finance di SAP B1, opportunamente modificate e adattate (Il documento con le specifiche è contenuto nella cartella IRUProbe).

Appendice

C

Struttura base del Listener 1 2 3 4 5

class Listener { TcpChannel m_tcpChannel; HttpChannel m_httpChannel;

6 7 8 9 10 11 12

private void Listen() { try { // ... implements IServerChannelSinkProvider CompressionServerSinkProvider compressedServerSinkProvider = new ...

13 14 15 16 17

// ... implements IServerFormatterSinkProvider, IServerChannelSinkProvider BinaryServerFormatterSinkProvider binaryServerSinkProvider = new ... [...] compressedServerSinkProvider.Next = binaryServerSinkProvider;

18 19 20 21 22 23 24 25 26 27 28

if (mySettings.Protocol.Equals("tcp") { m_tcpChannel = new TcpChannel(props, null, compressedServerSinkProvider); ChannelServices.RegisterChannel(m_tcpChannel, true) ; } if (mySettings.Protocol.Equals("http") { m_httpChannel = new HttpChannel(props, null, compressedServerSinkProvider); ChannelServices.RegisterChannel(m_httpChannel, false); }

29 30 31

// register here all services RemotingConfiguration.RegisterWellKnownServiceType(...) ;

79

C. Struttura base del Listener

[...]

32 33

} catch (Exception ex) { [...] }

34 35 36 37 38

}

39 40

}

80

Appendice

D

Setup dell’ambiente di test e sviluppo Per poter far funzionare l’ambiente di test devono essere create almeno 2 istanze Sql Server 2005, così nominate: • (local) • (local)\INSTANCE2 Nell’istanza (local) deve essere fatto il restore del database TEC.bak e rinominato TEC (TEC 4 database) Nell’istanza (local)\INSTANCE2 deve essere fatto il restore dei database: • SBO-COMMON.bak, rinominato in 105 • SBODemo_Austria_800181.bak, rinominato in 105_COM___ • SBO-COMMON.bak, rinominato in 147 • SODemo_Italy_800181.bak, rinominato in 147_COM___ Piu in generale in (local)\INSTANCE2 devono essere inserite le coppie DatabaseName, SBODatabaseName che appartengono all’HostName (local) e all’istanza CompanyDb_SQLInstanceName della vista Properties.VIEW_TicketInstance Tali informazioni possono essere ottenute eseguendo la query seguente sul database TEC precendetemente ripristinato: 1 2 3

SELECT TicketID, DatabaseName, SBODatabaseName FROM Properties.VIEW_TicketInstance WHERE HostName = ’(local)’ AND CompanyDb_SQLInstanceName = ’INSTANCE2’

81

D. Setup dell’ambiente di test e sviluppo

82

Dopo aver ripristinato i database, si crea un linked server all’istanza (local)\INSTANCE2 con la SP seguente: 1 2 3 4 5

EXEC sp_addlinkedserver @server=’(local)\INSTANCE2’, -- server_instance_database @srvproduct=’’, @provider=’SQLNCLI’, @datasrc=’(local)\INSTANCE2’ -- server\instance

Si abilita il supporto alle chiamate RPC su (local)\INSTANCE2 tramite la stored procedure di sistema 1 2

exec sp_serveroption @server=’(local)\INSTANCE2’, @optname=’rpc’, @optvalue=’true’ exec sp_serveroption @server=’(local)\INSTANCE2’, @optname=’rpc out’, @optvalue=’true’

E’ possibile verificare la corretta configurazione dei linked server tramite la stored procedure di sistema 1

exec sp_helpserver

Le colonne rpc ed rpc out dovrebbero essere settate ad 1 in caso la configurazione sia andata a buon fine. Una volta ripristinati i database, l’ambiente SSMS dovrebbe riportare una configurazione come quella in figura D.1:

Figura D.1: Configurazione SSMS

83 La succesiva operazione da effettuare è quella di registrare la Stored Procedure sviluppata in CLR, all’interno del database TEC. L’assembly generato dalla compilazione è SqlServerProjectCLR.dll. Ipotizzando che questo venga posto nel drive C:\, nel database TEC precedentemente configurato deve essere eseguita la seguente query: 1 2 3

CREATE ASSEMBLY CLRAssembly FROM ’C:\SqlServerProjectCLR.dll’ WITH PERMISSION_SET = SAFE GO

4 5 6 7 8 9 10

CREATE PROCEDURE Properties.ExecRemoteQuery @strLinkedServer nvarchar(max), @strRemoteQuery nvarchar(max) AS EXTERNAL NAME CLRAssembly.StoredProcedures.RemoteQuery GO

L’ultima operazione da effettuare sul database TEC è quella di abilitare il supporto alle transazioni di tipo snapshot, tramite il comando: 1 2 3

ALTER DATABASE TEC SET READ_COMMITTED_SNAPSHOT ON; GO

4 5 6

ALTER DATABASE TEC SET ALLOW_SNAPSHOT_ISOLATION ON;

L’ambiente di test è ora configurato e può essere utilizzato con il programma RemoteQueries. RemoteQueries deve essere configurato impostando i parametri di configurazione nel file xml app.config. I parametri da configurare sono: • SQLConnectionString: Stringa di connessione al server principale (puo’ coincidere con il database (local)). • TicketID: TicketID sul quale si vuole condurre il test • TECUserID: UserID dell’utente che effettua le operazioni su DB • SQLConnectionStringProperties: stringa di connessione al server di test (tipicamente (local)) • SQLTimeOut: Timeout del server puntato da SQLConnectionStringProperties Per verificare il funzionamento dei database di cui sopra, devono essere inserito nel file di configurazione il TicketID 41 (associato al Database 105) oppure il TicketID 67 (associato al Database 147). L’aggiunta, modifica o cancellazione di query avviene soltanto se nel file di configurazione viene impostato un TECUserID con autorizzazioni di TECAdmin o Manager (come ad esempio l’user 254). In caso si utilizzi un utente con

D. Setup dell’ambiente di test e sviluppo

84

autorizzazione di TECUser (es. user 248), il sistema inibirà l’aggiunta, modifica o cancellazione di queries.

Appendice

E

Interfacce Utente Applicativi In questa sezione vengono riassunte le interfacce grafiche con cui l’utente può interagire. Il progetto RemoteQueries mostra a video gli UserControl QueryProcessor (Fig. E.1) e ResultAnalyzer (Fig. E.2). Queste GUI vengono utilizzate durante la fase di sviluppo per testare l’implementazione dell’interfaccia PropertiesFramework prima del porting in produzione. Ognuna delle funzionalità numerate presenti in figura 3.7 trova corrispondenza nelle schermate QueryProcessor e ResultAnalyzer.

Figura E.1: GUI QueryProcessor

85

E. Interfacce Utente Applicativi

86

Figura E.2: GUI ResultAnalyzer

In particolare QueryProcessor permette di testare tutte le funzionalità relative al caricamento, esecuzione e salvataggio delle query e dei risultati. ResultAnalizer permette di verificare il caricamento dei dati dalla tabella Result e i Batch di esecuzione. La GUI del progetto ServerManager (Fig. E.3) fornisce 2 funzionalità: • Analisi delle cartelle presenti su server (bottone COLLECT DATA) • Salvataggio dei dati su database TEC_LIVE(bottone STORE DATA) La listbox nella parte sinistra della videata, listBoxServer, visualizza l’elenco dei server da analizzare con evidenziato il server correntemente sotto analisi. La listbox nella parte destra della videata, listBoxResult, visualizza l’elenco delle cartelle analizzate. La barra di stato in basso, visualizza la percentuale di server processati. All’interno del progetto TEC sono stati sviluppate 3 interfacce grafiche: L’UserControl AdminQueries (Fig. E.4) permette di aggiungere o rimuovere una query nell’evento selezionato. Per ogni query si deve specificare su che tipo di database la query sarà eseguita (Performed on), si deve assegnare un titolo (Title), una Nota SAP di riferimento (SAP Note) e un ordine di esecuzione (Order ). La parte destra della videata permette di inserire il testo della query. Il plugin DisplayQueriesPlugin (Fig. E.5), una volta selezionato un Ticket sulla Dashboard di sinistra, permette di filtrare tutti i risultati

87

Figura E.3: GUI ServerManager

Figura E.4: GUI AdminQueries

salvati sul database in base al tipo di database (DB TYPE ), l’evento (EVENT ) e la query (QUERY ). Una volta selezionato il risultato tramite il menu a tendina RESULT, clikkando su LOAD esso viene visualizzato a video. Il plugin IVUAutomation (Fig. E.6) permette di eseguire il pre-calcolo dei beni in inventario, richiamabile con il bottone PRE-CALCULATION. Nel caso in cui il pre-calcolo non fornisca alcun risultato, è possi-

E. Interfacce Utente Applicativi

88

Figura E.5: GUI DisplayQueriesPlugin

Figura E.6: GUI IVUAutomation

bile procedere con il riordino dell’inventario tramite il bottone POSTCALCULATION. Nel caso in cui il pre-calcolo fornica dei risultati, l’utente può vi-

89 sualizzare i risultati selezionando l’esecuzione e il risultato di esecuzione tramite i due menu a tendina. Una volta corretti gli errori di inventario direttamente sul database è possibile ripetere il pre-calcolo. Si noti che il POST-CALCULATION è inibito sintantochè il PRECALCULATION ritorna dei risultati.

Appendice

F

Elenco dei server gestiti ID 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39

SERVER pwdf2412 pwdf2412 pwdf2412 pwdf2412 pwdf2412 pwdf2413 pwdf2413 pwdf2413 pwdf2413 pwdf2413 pwdf2413 pwdf2413 pwdf2660 pwdf2660 pwdf2660 pwdf2681 pwdf2681 pwdf2681 pwdf2681 pwdf2806 pwdf2806 pwdf2806 pwdf2806 pwdf2806 pwdf2806 pwdf2806 pwdf2806 pwdf2806 pwdf2806 pwdf2807 pwdf2807 pwdf2807 pwdf2807 pwdf2807 pwdf2807 pwdf2807 pwdf2807 pwdf2807 pwdf2807

INSTANCE AddOn VERSION B1_20042BADDON 1 2004 B1_2004AADDON 1 2004 B1_2005ASP00 0 2005 SP00 B1_2005ASP01 0 2005 SP01 O5B12005ASP1 0 2005 SP01 B1_2004A 0 2004 B1_2005ASP00ADD 1 2005 SP00 B1_2005ASP01 0 2005 SP01 B1_2005BSP00 0 2005 SP00 B1_2005BSP00ADD 1 2005 SP00 O5B12005ASP1 0 2005 SP01 O5B12005BSP0 0 2005 SP00 B1_2004A 0 2004 B1_2005ASP01 0 2005 SP01 O5B12005ASP1 0 2005 SP01 B1_2005ASP01 0 2005 SP01 B1_2005ASP01ADD 1 2005 SP01 O5B12005ASP1 0 2005 SP01 O5B12005ASP1ADD 1 2005 SP01 B1_20042B 0 2004 B1_20042BADDON 1 2004 B1_2004A 0 2004 B1_2004C 0 2004 B1_2004CADDON 1 2004 B1_2005ASP01ADD 1 2005 SP01 B1_2007BSP00 0 2007 O5B12005ASP1ADD 1 2005 SP01 O5B12007BSP0 0 2007 O5B12007BSP0ADD 1 2007 B1_20042B 0 2004 B1_2004A 0 2004 B1_2004AADDON 1 2004 B1_2005ASP00 0 2005 SP00 B1_2005ASP01 0 2005 SP01 B1_2005ASP01ADD 1 2005 SP01 B1_2007AFP01 0 2007 FP01 O5B12005ASP1 0 2005 SP01 O5B12005ASP1ADD 1 2005 SP01 O5B12007AFP01 0 2007 FP01

91

F. Elenco dei server gestiti

40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95

pwdf3119 B1_2004AADDON 1 2004 pwdf3119 B1_2005ASP00 0 2005 SP00 pwdf3119 B1_2005ASP01 0 2005 SP01 pwdf3119 B1_2005BSP00 0 2005 SP00 pwdf3119 O5B12005ASP1 0 2005 SP01 pwdf3119 O5B12005BSP0 0 2005 SP00 pwdf3129 B1_2004A 0 2004 pwdf3129 B1_2004C 0 2004 pwdf3129 B1_2005ASP00ADD 1 2005 SP00 pwdf3129 B1_2005ASP01 0 2005 SP01 pwdf3129 B1_2005BSP00 0 2005 SP00 pwdf3129 B1_2005BSP00ADD 1 2005 SP00 pwdf3129 O5B12005ASP1 0 2005 SP01 pwdf3129 O5B12005BSP0 0 2005 SP00 pwdf3129 O5B12007ASP0 0 2007 pwdf3130 B1_2004AADDON 1 2004 pwdf3130 B1_2005ASP00 0 2005 SP00 pwdf3130 B1_2005ASP01 0 2005 SP01 pwdf3130 B1_2005BSP00 0 2005 SP00 pwdf3130 O5B12005ASP1 0 2005 SP01 pwdf3130 O5B12005BSP0 0 2005 SP00 pwdf6003 B1_2005ASP01 0 2005 SP01 pwdf6003 B1_2005ASP01ADD 1 2005 SP01 pwdf6003 B1_2007ASP00 0 2007 pwdf6003 O5B12005ASP1 0 2005 SP01 pwdf6003 O5B12005ASP1ADD 1 2005 SP01 pwdf6003 O5B12007ASP0 0 2007 PWDF6500VM04 B1_2005ASP01 0 2005 SP01 PWDF6500VM04 B1_2005BSP00 0 2005 SP00 PWDF6500VM04 B1_2007ASP00 0 2007 PWDF6500VM04 O5B12005ASP1 0 2005 SP01 PWDF6500VM04 O5B12005BSP0 0 2005 SP00 PWDF6500VM04 O5B12007ASP0 0 2007 pwdf6544 B1_2005ASP01 0 2005 SP01 pwdf6544 B1_2005BSP00 0 2005 SP00 pwdf6544 B1_2007ASP00 0 2007 pwdf6544 O5B12005ASP1 0 2005 SP01 pwdf6544 O5B12005BSP0 0 2005 SP00 pwdf6544 O5B12007ASP0 0 2007 pwdf6545 B1_2005ASP01 0 2005 SP01 pwdf6545 B1_2005BSP00 0 2005 SP00 pwdf6545 B1_2007AFP01 0 2007 FP01 pwdf6545 B1_2007ASP00 0 2007 pwdf6545 O5B12005ASP1 0 2005 SP01 pwdf6545 O5B12005BSP0 0 2005 SP00 pwdf6545 O5B12007AFP01 0 2007 FP01 pwdf6545 O5B12007AFP01ADD 1 2007 FP01 pwdf6545 O5B12007ASP0 0 2007 pwdfe025 B1_2005ASP00 0 2005 SP00 pwdfe025 B1_2005ASP01 0 2005 SP01 pwdfe025 B1_2005BSP00 0 2005 SP00 pwdfe025 B1_2007ASP00 0 2007 pwdfe025 O5B12005ASP1 0 2005 SP01 pwdfe025 O5B12005BSP0 0 2005 SP00 pwdfe025 O5B12007ASP0 0 2007 pwdfe025 O5B12007ASP0ADD 1 2007

92

Bibliografia

[1] SAP AG. Database tables reference 2005a sp1. REFDB_2005, 2005. [cited at p. 1]

[2] SAP AG.

Tec test environment center.

TEC_Overview, 2007.

[cited at p. 6]

[3] SAP AG. Sap business one system requirements v3.0. SBO_SystemRequirements, 2009. [cited at p. 5] [4] Edgar F. Codd. Is your dbms really relational? ComputerWorld, 1985. [cited at p. 50] [5] Microsoft Corporation. Understanding and managing transaction logs. http:// technet.microsoft.com/ en-us/ library/ ms345583( SQL.90).aspx, 2005. [cited at p. 26] [6] Microsoft Corporation. User schema separation. http:// msdn.microsoft.com/ en-us/ library/ ms190387( SQL.90).aspx, 2005. [cited at p. 17] [7] Microsoft Corporation. Set transaction isolation level (transact-sql). http:// msdn.microsoft.com/ en-us/ library/ ms173763( SQL.90).aspx, 2006. [cited at p. 48] [8] Microsoft Corporation. sp_spaceused (transact-sql). http:// msdn.microsoft.com/ en-us/ library/ ms188776( SQL.90).aspx, 2008. [cited at p. 57] [9] Microsoft Corporation. Designing indexed http:// msdn.microsoft.com/ en-us/ library/ ms187864.aspx, [cited at p. 44]

93

views. 2009.

BIBLIOGRAFIA

94

[10] Microsoft Corporation. sp_dboption. http:// msdn.microsoft.com/ en-us/ library/ aa933268( SQL.80).aspx, 2009. [cited at p. 58] [11] Microsoft Corporation. Threads and threading. http:// msdn.microsoft.com/ en-us/ library/ 6kac2kdh( VS.80).aspx, 2009. [cited at p. 34] [12] Peter Fenwick and Simon Brierley. Compression of unicode files. Data Compression Conference, 1998. DCC ’98. Proceedings, 1998. [cited at p. 12]

[13] Mike Gunderloy and Joseph L. Jorden. Mastering SQLServer 2000. Sybex, 2000. [cited at p. 57] [14] Citrix Systems Inc. Citrix metaframe application server for windows 2000 servers - administrator’s guide. http:// support.citrix.com/ servlet/ KbServlet/ download/ 2171-102-8281/ MF18EN.pdf , 2000. [cited at p. 6] [15] VMware Inc. Vmware server2 datasheet. http:// www.vmware.com/ files/ pdf/ server_datasheet.pdf , 2009. [cited at p. 8]

[16] Davide Mauri. Sequel server 2005 overview. Solid Quality Learning Article, 2007. [cited at p. vii, 47] [17] Ingo Rammer and Mario Szpuszta. Advanced .NET Remoting. Apress, 2 edition, 2005. [cited at p. 12, 36] [18] Mathes e altri Schwarzkopf. Java rmi versus .net remoting - architectural comparison and performance evaluation. Seventh International Conference on Networking, 2008. [cited at p. 12] [19] Eindhoven University Of Technology. Sequoiaview. http:// w3.win.tue.nl/ nl/ onderzoek/ onderzoek_informatica/ visualization/ sequoiaview/ / , 2002. [cited at p. 26] [20] Kimberly L. Tripp. Partitioned tables and indexes in sql server 2005. http:// msdn.microsoft.com/ en-us/ library/ ms345146.aspx, 2005. [cited at p. 46]

Acronimi SAP Systeme Anwendungen Produkte in der Datenverarbeitung GSC SAP Global Support Center TEC Test Environment Center IBD Install Base Development B1 SAP Business One SSP Software Solution Partner IVU Inventory Valuation Utility USD Upgrade Solution Desk SBO-COMMON SAP Business One Common Database FUP Forced Upgrade Process SFTP Secure File Transfer Protocol GTL Gobal Topic Lead B1 Business One SBO-BC Business Core SBO-BC-UPG Upgrade SBO-BC-ADD AddOn ERP Enterprise Resource Planning CSN Customer Support System New PL Patch Level MS Microsoft 95

F. Acronimi

MS SSMS Microsoft Sql Server Management Studio DB2 IBM Database2 DBMS DBMS Database management system VPN Virtual Private Network TCP Transmission Control Protocol HTTP Hypertext Transfer Protocol UDT User Defined Table UDF User Defined Field SAO Server Activated Object CAO Client Activated Object OLAP Online Analytical Processing TEC Admin TEC System Administrator

96