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 3
2.1 Descrizione del Problema . . . . . . . . . . . . . . . . . . 3
2.1.1 Contesto Aziendale . . . . . . . . . . . . . . . . . . 3
2.1.2 Overview Sistemi ed Entità . . . . . . . . . . . . . 4
2.1.3 Pratica Interna . . . . . . . . . . . . . . . . . . . . 4
2.1.4 Software Preesistente . . . . . . . . . . . . . . . . . 6
2.2 Analisi del Problema . . . . . . . . . . . . . . . . . . . . . 6
2.2.1 Definizione del Problema . . . . . . . . . . . . . . . 7
2.3 Analisi dei Requisiti . . . . . . . . . . . . . . . . . . . . . 8
2.3.1 Vincoli di progetto . . . . . . . . . . . . . . . . . . 8
2.3.2 Casi d’uso . . . . . . . . . . . . . . . . . . . . . . . 9
2.3.3 Planning delle attività . . . . . . . . . . . . . . . . 10
3 Progetto del Sistema 11

3.1 Moduli A e B: Generic Query . . . . . . . . . . . . . . . . 11
3.1.1 Il canale di comunicazione . . . . . . . . . . . . . . 11
3.1.2 Il Server Listener . . . . . . . . . . . . . . . . . . . 13
3.1.3 La Base Dati . . . . . . . . . . . . . . . . . . . . . 14
3.1.4 L’interfaccia Properties Framework . . . . . . . . . 19
3.2 Modulo C: Backup Manager . . . . . . . . . . . . . . . . . 22
3.2.1 La Procedura di Restore attuale . . . . . . . . . . 24
3.2.2 Problemi Rilevati . . . . . . . . . . . . . . . . . . . 24
3.2.3 Possibili Soluzioni . . . . . . . . . . . . . . . . . . 26
3.2.4 Schema E-R Backup Manager . . . . . . . . . . . . 27
3.3 Modulo D: Ridefinizione GSC Workflow . . . . . . . . . . 27
v
INDICE vi
4 Implementazione 33
4.1 Moduli A e B . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.1.1 Properties Framework . . . . . . . . . . . . . . . . 33
4.1.2 Gli oggetti serializzabili . . . . . . . . . . . . . . . 34
4.1.3 Server Listener . . . . . . . . . . . . . . . . . . . . 36
4.1.4 Schema Logico Database (Schema Properties) . . . 38
4.1.5 Stored Procedures . . . . . . . . . . . . . . . . . . 38
4.1.6 Indici . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.1.7 Triggers e Jobs . . . . . . . . . . . . . . . . . . . . 45
4.1.8 Transazioni . . . . . . . . . . . . . . . . . . . . . . 47
4.1.9 IO Risultati da server . . . . . . . . . . . . . . . . 50
4.2 MODULO C . . . . . . . . . . . . . . . . . . . . . . . . . 52
4.2.1 Applicazione BackupManager . . . . . . . . . . . . 53
4.2.2 Shrink Distribuito . . . . . . . . . . . . . . . . . . 53
4.2.3 Schema Logico Database (Schema BackupManager) 58
4.3 MODULO D . . . . . . . . . . . . . . . . . . . . . . . . . 60
5 Risultati ottenuti 65
5.1 Moduli A e B . . . . . . . . . . . . . . . . . . . . . . . . . 65
5.2 Modulo C . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
5.3 Modulo D . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
6 Conclusioni e Raccomandazioni 71
6.1 Miglioramenti moduli A e B . . . . . . . . . . . . . . . . . 71
6.2 Miglioramenti modulo C . . . . . . . . . . . . . . . . . . . 72
6.3 Considerazioni Finali . . . . . . . . . . . . . . . . . . . . . 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 Business One Workflow . . . . . . . . . . . . . . . . . . . 4

2.2 Business One System Overview . . . . . . . . . . . . . . . 5
2.3 Use Case del Sistema . . . . . . . . . . . . . . . . . . . . . 9
3.1 Channel . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.2 Listener . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.3 Properties Framework . . . . . . . . . . . . . . . . . . . . 14
3.4 Modello di Accesso ai dati . . . . . . . . . . . . . . . . . . 16
3.5 Schema definiti nel database TEC . . . . . . . . . . . . . . 19
3.6 Modello E-R Schema Properties . . . . . . . . . . . . . . . 20
3.7 Servizi Offerti da Properties Framework . . . . . . . . . . 21
3.8 Numero database ripristinati su server . . . . . . . . . . . 23
3.9 Totale spazio annualmente allocato sui server . . . . . . . 23
3.10 TEC 3 - GUI Richiesta ticket . . . . . . . . . . . . . . . . 25
3.11 Snapshot Sequoia . . . . . . . . . . . . . . . . . . . . . . . 27
3.12 Overview Backup Manager . . . . . . . . . . . . . . . . . 28
3.13 Modello E-R Schema BackupManager . . . . . . . . . . . 29
3.14 Workflow Attuale . . . . . . . . . . . . . . . . . . . . . . . 30
3.15 Workflow Ridefinito . . . . . . . . . . . . . . . . . . . . . 31
4.1 Interfaccia PropertiesFramework e sua implementazione . 35

4.2 Oggetti Serializzabili . . . . . . . . . . . . . . . . . . . . . 37
4.3 Servizi offerti dal Server Listener . . . . . . . . . . . . . . 39
4.4 Schema Logico DB (Schema Properties) . . . . . . . . . . 40
4.5 Stored Procedure GetRemoteQueryResult . . . . . . . . . 42
4.6 Stored Procedure GetSavedQueryResult . . . . . . . . . . 43
4.7 Livelli di Isolamenteo [16] . . . . . . . . . . . . . . . . . . 47
4.8 Interfaccia con la Base Dati per Backup Manager . . . . . 53
4.9 Interfacce e Implementazioni per Backup Manager . . . . 54
4.10 Schema Logico DB (Schema BackupManager) . . . . . . . 59
vii
ELENCO DELLE FIGURE viii
4.11 Directories orfane . . . . . . . . . . . . . . . . . . . . . . . 60

4.12 DBs non associati a Tickets . . . . . . . . . . . . . . . . . 61
5.1 Snapshot Sequoia dopo lo shrink e l’eliminazione delle cartelle orfane 66

5.2 Database ripristinati (media mobile su 45 gg) . . . . . . . 67
5.3 Database cancellati (media mobile su 45 gg) . . . . . . . . 67
5.4 Guadagno di spazio (in %) sui server di backend . . . . . 68
5.5 Ticket richiesti e ripristini manuali . . . . . . . . . . . . . 69
D.1 Configurazione SSMS . . . . . . . . . . . . . . . . . . . . . 82
E.1 GUI QueryProcessor . . . . . . . . . . . . . . . . . . . . . 85

E.2 GUI ResultAnalyzer . . . . . . . . . . . . . . . . . . . . . 86
E.3 GUI ServerManager . . . . . . . . . . . . . . . . . . . . . 87
E.4 GUI AdminQueries . . . . . . . . . . . . . . . . . . . . . . 87
E.5 GUI DisplayQueriesPlugin . . . . . . . . . . . . . . . . . . 88
E.6 GUI IVUAutomation . . . . . . . . . . . . . . . . . . . . . 88
Elenco delle tabelle
3.1 Tabella Query . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.2 Tabella Result . . . . . . . . . . . . . . . . . . . . . . . . 18
3.3 Tabella Batch . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.4 Tabella Relazioni . . . . . . . . . . . . . . . . . . . . . . . 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 pa-
rallelamente 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 cono-
scenze 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 produ-
zione presso i clienti SAP, che compromettono la produttività aziendale. I
database aziendali possono essere trasferiti in uno dei server SAP localiz-
zati 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 ba-

se dati remote in Germania, dalle sedi in Irlanda, Israele, Slovac-
chia, 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 au-

tomatizzare 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 En-
vironement 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 rag-
giungibile 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 loca-
lizzazione 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 com-
prendere chiaramente l’organizzazione aziendale e come i vari dipartimen-
ti 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 risol-
vere 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
2. Analisi 4
• L’ Install Base Development (IBD): IBD è il dipartimento più inter-

no che ha il compito di correggere bugs e malfunzionamenti. GSC
fa usi di Internal Notes che spiegano come affrontare e risolvere pro-
blematiche 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
SAP PARTNER GSC IBD
CUSTOMER
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 utiliz-
zati. Più COMPANY-DB sono ripristinati sul medesimo TEC 1 server.
Tutti i COMPANY-DB ripristinati sulla medesima istanza devono esse-
re compatibili con l’SBO-COMMON di quella istanza. I server vengono
mantenuti tramite le informazioni registrate nel database TEC Applica-
tion Server. Il TEC Application Server è la base di informazioni per
applicativo TEC. I consulenti GSC e IBD utilizzano sia Customer Sup-
port System New (CSN) 2 per il tracking del problema da risolvere che
Test Environment Center (TEC) per il download e restore dei databa-
se 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 ri-
pristinare 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
COMPANY-DB Ticket
Patch Level (PL)
IBD
Version (V)
Db Type
SBO-COMMON TEC Application
TEC Appication Server
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 pre-
sentation client per far eseguire la logica applicativa e si basa su un server
condiviso per il mantenimento dei dati. I database attualmente suppor-
tati 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 è iden-
tificato da un identificativo). Dopo che il messaggio è stato inserito nel
2. Analisi 6
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’e-
sterno: 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 ana-
lizzare 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 ese-
guire 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 installa-
zioni, 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 Ger-
mania 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 ricor-
renti 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 occu-

pato 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 attualmen-
te 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 risul-
tato. 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.
2. Analisi 8
[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 VM-
Ware [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 caratteri-
stiche 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 vol-
ta 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 consu-
lenti (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 svilup-
pati 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
«extend» 8. TEC Client
«extend»
3. Upgrade Manager
«extend»
«extend»
4. Backup Manager «communicate» Serv er Farm
«communicate»
TECAdmin
5. Query Admin
«use»
6. Properties 9. TEC Serv er

Framew ork «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
2. Analisi 10
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 meto-
do di trasporto più opportuno per i dati che devono transitare nel canale
di comunicazione che permette il dialogo tra l’applicativo client ed il ser-
ver 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’am-

biente 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. Da-
to che il contesto in cui opera il sistema è una VPN opportunamente con-
figurata, 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 quan-

tità di dati scambiati tra gli end-point data l’assenza degli header intro-
dotti 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 in-
dispensabile per poter trasferire i dati sul canale. La crittografia è stata
trascurata in quanto tale servizio è offerto dalla VPN aziendale men-
tre è 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’implementa-
zione di un sink di compressione qualora gli oggetti da trasferire conten-
gano prevalentemente stringhe o testo. Se tale condizione è verificata si
può arrivare ad una dimensione dell’oggetto serializzato\compresso infe-
riore 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 pa-
gina 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 compres-
sore 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 esclusiva-
mente stringhe e risultati di esecuzione, che giustificano l’implementazio-
ne 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 ge-
stire 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
CLIENT SERVER
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:
• Lo sviluppatore potrebbe non avere conoscenza relativa alla strut-

tura dell’intera base dati
• Lo sviluppatore potrebbe focalizzarsi sulla sue operazioni senza va-

lutare 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 funziona-
lità 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 programma-
tore richiama una funzionalità in PropertiesFramework, l’implementazio-
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 speci-
ficato 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 approc-

cio a seguito delle seguenti considerazioni:
• Modularità offerta dalle stored procedures: in caso di bug o modifi-
che 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 analizza-
re 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 retrocom-
patibilità 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, utilizzan-
do 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 esecuzio-
ne (quando possibile). Tale operazione è del tutto trasparente al-
l’interfaccia Properties Framework che quindi non richiede d’essere
modificata.
• Per quanto detto a inizio paragrafo, il traffico di rete viene ridot-
to 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 ab-
biano 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à genera-
ta una versione in-memory che verrà eseguita più velocemente ai
richiami successivi.
A fronte di questa discussione si devono tuttavia ricordare alcuni ca-

si 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
CHANNEL TABLE
STORED PROCEDURE VIEW

SERVER FRAMEWORK
LIBRARY 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 grup-

pi 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 mo-

dificata 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
multiple, potrebbe essere necessario modificarle tutte per garantire il

funzionamento delle stored procedures.
Nel caso in oggetto, date le molteplici stored procedure che si andran-
no 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 rac-
coglie 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 proce-
dures 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
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

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 Propertie-
sFramework e le relazioni con le stored procedure della base dati. I servizi
offerti sono di 3 tipi: Salvataggio, Esecuzione e Selezione. Le operazio-
ni di modifica ed eliminazione non sono state prese in considerazione in
quanto il Project Manager ha proposto di creare un Framework comu-
ne 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, RE-
SULT è 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).
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
EventID
EntityID Properties.Entity Properties.Event Description
Description
0,N 0,N
ON RAISE
0,1
1,1
QueryID 0,N 1,1 ResultID

Properties.Query GENERATE Properties.Reult
QueryDescription ResultDate
SAPNote ExecutionResult
IsPublic
QueryText 1,1 0,N
1,1
ADD BREED RETRIEVE
0,N
0,N
0,1 TicketID
0,N 1,1 Core.Ticket
TECUserID Security.TECUser EXECUTE
0,N
Properties.Batch BELONG
1,1
BatchID
0,N StatusID
1,1 OWN Properties.Status Description
Figura 3.6: Modello E-R Schema Properties

21
IPropertiesFramework
SAVE Line WHAT TO DO GET Line
EXEC Line
EXECUTE A GET LIST OF GET LIST OF GET LIST OF GET LIST OF GET A SPECIFIC GET LIST OF
SAVE A RESULT SAVE A QUERY
QUERY QUERY RESULT ENTITIES EVENTS RESULT BATCH
GetQueryResult
GetQueryList GetEntityList GetEventList GetSavedResult GetBatchList
List
SaveResult SaveQuery ALREADY 7 8 9 10 11 12
1 2 Y STORED ON N
DB
CHECK
Y BEFORE N GetRemoteQueryResult
SAVING 6
TIME
GetSavedQueryResult Y CONSUMING N
3 QUERY
ExecuteAndSave ExecuteAndSave
ResultAsync Result
4 5
STORED PROCEDURES STORED PROCEDURES

1 SetResult 7 GetQueryList
2 SetQuery 8 GetQueryResultList
3 GetSavedQueryResult 9 GetEntityList
Moduli A e B: Generic Query
4 GetSavedQueryResult, SetResult 10 GetEventList
5 GetSavedQueryResult, SetResult 11 GetResult
6 GetRemoteQueryResult 12 GetBatch
Figura 3.7: Servizi Offerti da Properties Framework

3.2 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 proce-
dura 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 mal-
funzionamenti:
• userID e\o password dell’area Secure File Transfer Protocol (SFTP)

non corretti
• backup non compresso e\o compresso in formato differente dai for-

mati 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 in-
tervento da parte di un TECAdmin. Di tutti i TECAdmin (21 in totale)
sono stati individuati quelli con il maggior numero di messaggi analiz-
zati (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 con-
sulenti 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 analiz-

zati ha portato all’individuazione della causa principale per cui l’ope-
razione 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

possibili flessi dovuti alle minori richieste di supporto data l’attuale si-
tuazione economica a livello mondiale.
Sulla base di tali considerazioni è quindi necessario ottimizzare l’u-
tilizzo 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 cu-
stomer 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 logi-
ca 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 net-
work path \ \ServerName \backups$\Data ed ivi verrà creata una cartel-
la nel formato Anno_CSNMessageNr_CSNCustomerNr_TECTicketNr.
In questa cartella verrà riposto il database, esso verrà estratto nella sot-
tocartella tmpTEC, ripristinato su server con nome
Anno_CSNMessageNr_CSNCustomerNr_TECTicketNr e la cartella tmp-
TEC verrà immediatamente eliminata. Dopo 14 giorni di inutilizzo del
database sia la cartella che il database con nome
Anno_CSNMessageNr_CSNCustomerNr_TECTicketNr verranno elimi-
nati 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 nomen-
clatura 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

• mismatch tra la nomenclatura della cartella e il database ripristi-

nato.
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 valu-

tato 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 dal-
l’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. Ana-
logamente 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 imple-

mentare 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ò conte-
nere 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 me-
no dell’upgrade. In caso l’esito sia negativo, il consulente deve contattare
un membro del System Team e notificare il fallimento dell’upgrade.
BackupManager SCHEMA
ServerManager
BackendRootList
1. ServerManager()
GetBackendRootList
COLLECT DATA 2.
TEC_LIVE
BackendServer 3.
SetServer STORE DATA
Pwdf2660
Directory
SetDirectory
File SetFile
DistributedShrink_V2.sql
RestoredDatabase 4. (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 quan-
to 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 quan-
to 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 solamen-
te 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 consu-
lenti per la risoluzione di problemi interni. La soluzione proposta è quel-
BackendID
BACKEND
Servername SERVER
BackupRoot
0,N
TO HOLD
1,1
DirectoryID
NumFiles
Name DIRECTORY
CreationTime
LastAccessTime
0,N
TO HOLD
1,1
FileID
Name FILE
Type
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 que-
sto nuovo schema è stato aggiunto il processo denominato Forced Upgrade
allo scopo di modificare il database rendendolo compatibile con la pro-
cedura 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 implementa-
zione 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.
act Workflow
GENERAL CONSULTANT SYSTEM CONSULTANT TEC ENVIRONMENT
Message
Processing
PICK A NEW MESSAGE
CONSULTING
Upg?
UPGRADE
GO TO Pick a new message
UPG. NOTIFICATION
Failure? Y
UPG. FAILURE
N ANALYSIS
GO T O Consulting PROBLEM SOLVING
POST FIX UPGRADE
UPG. NOTIFICATION
Upg?
Y
UPG. NOTIFICATION
N
MESSAGE SOLVING
End Message
Processing
Figura 3.14: Workflow Attuale

act Workflow
GENERAL CONSULTANT SYSTEM CONSULTANT TEC ENVIRONMENT UPG. SOLUTION DESK
Message
Processing
PICK A NEW MESSAGE
CONSULTING
Upg?
UPGRADE
GO T O Pick a new message
UPG. NOTIFICATION
Failure?
FORCED UPGRADE
GO T O Pick a new msg
UPGRADE NOTIFICATION
Failure? Y
UPG. FAILURE ANALYSIS
N
N
PROBLEM SOLVING
GO TO Message Solving
POST FIX UPGRADE
UPG. NOTIFICATION
Upg?
Y
Recurrent?
Y
UPG. ISSUE
KNOWLEDGE
N TRANSFER
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 omo-
geneità con la base dati cui i parametri verranno passati. I risultati in
output sono tipi primitivi, DataSet e DataTable. Per poter essere utiliz-
zati 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 ExecuteAndSaveRe-
sultAsync. 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’ela-
borazione 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 Thread-

Pool 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 // delegate for method ExecuteAndSaveResult
2 public delegate bool DelegExecuteAndSaveResult(int?
queryID, int? ticketID, int? TECUserID, int? batchID);
3
4 // Delegate of type
5 DelegExecuteAndSaveResult delegateExecuteAndSaveResult;
6
7 [...]
8
9 public int ExecuteAndSaveResultAsync(int? queryID, int?

ticketID, int? TECUserID)
10 {
11 int batchID = GetBatch(queryID, ticketID);
12 delegateExecuteAndSaveResult =
ExecuteAndSaveResult;
13 delegateExecuteAndSaveResult.BeginInvoke(
queryID, ticketID, TECUserID, batchID,
null, null);
14 return batchID;
15 }
Viene creato un delegato con la stessa firma (parametri e valori di

ritorno) del metodo che esegue in modalità sincrona. Il metodo asincro-
no 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 bat-
chID 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

- GetBatch() : int
+ 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 con-
tiene 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ò poten-
zialmente contenere una elevata quantità di dati. Questo influenzerebbe
negativamente il server ove è in esecuzione il listener, a causa della mag-
gior computazione necessaria per generare gli oggetti summenzionati e la
rete, per il maggior traffico dati generato. Ricordiamo inoltre, che quan-
do 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.
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<Result> GetAll(Ticket ticket)
e List<Result> 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 Single-
Call. 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 istan-
zia 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
- q_Entity: Entity IEquatable

- q_Event: Event Result
- q_ID: int?
- r_batchID: int
- q_IsPublic: bool
- r_dateT ime: DateT ime
- q_Order: int?
- r_executionResult: DataT able
- q_SAPNote: int?
- r_ID: int
- q_TECUserID: int?
- r_query: Query
- q_Text: string
- r_TECUserID: int
- q_timestampChg: byte ([])
- r_timeStamp: byte ([])
- q_Title: string
+ Equals(Result) : bool
+ Add() : Query
+ ExecuteAndSaveResult(Query, Ticket) : void
+ Delete() : void
+ ExecuteAndSaveResultAsync(Query, Ticket) : void
+ Equals(Query) : bool
+ Get(string) : Query -r_query + GetAll(T icket) : List<Result>
+ GetAll(Query, Ticket) : List<Result>
+ GetAll() : List<Query>
+ GetByKey(int) : Result
+ GetAll(Event) : List<Query>
+ 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 + Add() : Event

+ Delete(Entity) : void + Delete() : void
+ Entity(int, string) + Equals(Event) : bool
+ Equals(Entity) : bool + Event(int, string)
+ GetAll() : List<Entity> + GetAll() : List<Event>
+ ToString() : string + ToString() : string
+ Update(Entity) : Entity + Update() : Event
«property» «property»
+ Description() : string + EventID() : int?
+ ID() : int + Name() : string
Figura 4.2: Oggetti Serializzabili

Avere la logica sul client non garantisce che l’applicativo utilizzi sem-
pre 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 uti-
lizzare 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 QueryLo-
cal che implementa l’interfaccia IQuery, EventLocal che implementa l’in-
terfaccia 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 con-
sente di ritornare al client un oggetto Result cercandolo per ID, ritornare
una lista di Result fornendo alcuni parametri di ricerca, ritornare il da-
tatable che rappresenta il risultato, eseguire una certa query e salvare il
risultato.
Gli altri servizi offerti dal Listener, non essendo stati sviluppati dal-
l’autore, non trovano trattazione nel seguito.
Le classi QueryLocal, EventLocal, ResultLocal e EntityLocal istan-
ziano 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
PropertiesFramew ork::PropertiesFramew orkImpl
+ GetSavedResult(int?) : DataTable -propertiesFwkHandler
+ SaveQuery(string, int?, int?, string, bool?, int?, int?, int?) : int MarshalByRefObject
+ 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
«interface» MarshalByRefObject
TEC::IEvent PropertiesFramew ork::QueryLocal
+ Add(Event) : Event - propertiesFwkHandler: IPropertiesFramework
+ Delete(Event) : void
+ GetAll() : List<Event>
+ Update(Event) : Event
«interface»
TEC::IQuery
+ Add(Query) : Query
+ Delete(Query) : void
+ Get(string) : Query
MarshalByRefObject + GetAll() : List<Query>
+ GetAll(Event) : List<Query>
PropertiesFramew ork::ResultLocal
+ GetByKey(int?) : Query
- resultHandler: IPropertiesFramework + Update(Query) : Query
«interface»
TEC::IResult
«interface»
+ ExecuteAndSaveResult(Query, Ticket) : bool
TEC::IResultAdmin
+ ExecuteAndSaveResultAsync(Query, Ticket) : void
+ Add(Result) : Result + GetAll(int?) : List<Result>
+ Delete(Result) : Result + GetAll(Query, int?) : List<Result>
+ Update(Result) : Result + GetByKey(int?) : Result
+ GetQueryResultList(Ticket) : DataTable
+ GetResult(Query, Ticket) : DataSet
+ GetSavedQueryResult(Query, Ticket) : DataSet
Figura 4.3: Servizi offerti dal Server Listener

TECUser
Query
Entity PK TECUserID
PK QueryID
PK EntityID U1 NTUserName
U1 QueryDescription Result FirstName
Description FK1 FK_EntityID LastName
SAPNote PK ResultID
EMail
IsPublic LastLoginDate
FK3 FK_TECUserID FK3 FK_QueryID
FK_DepartmentID
Event QueryText FK4 FK_TECUserID
Active
FK2 FK_EventID ExecutionResult
TimestampChg
PK EventID QueryOrder FK1 FK_TicketID
TimestampDate
TimestampChg TimestampChg
Description TimestampDate TimestampDate
FK2 FK_BatchID
Error
Ticket
PK TicketID
FK_CompanyBackupID
Batch
FK_CompanyDatabaseID
Status PK BatchID FK_TicketStatus
TicketStatusDate
PK StatusID
FK3 FK_StatusID FK1 FK_OwnerID
RequestTime TicketCreationDate
Description
FK2 FK_QueryID TimestampChg
FK1 FK_TicketID U1 ComputCol
TimestampDate
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’u-
tilizzo 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 connessio-
ne tramite linked server al database remoto selezionato sulla base dei pa-
rametri 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 Compa-

nyDb o all’ Sbo-Common
NOTA: In caso venga aggiunto un nuovo tipo di database (detto En-
tity 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 ser-
ver, 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 risul-
tato. A differenza di [Properties].[GetRemoteQueryResult], la query da
eseguire in questo caso è salvata su db. Tale SP è pensata per l’esecu-
zione 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.
intTicketID intEntityID strRemoteQuery GetRemoteQueryResult
EntityID: 1 – CompanyDB
2 – SBOCOmmon
intTicketID
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 cor-

rente.
• GetBatchList: Ricerca per QueryID e TicketID su tabella

Batch.
• GetEntityList, GetEventList eseguono una select completa.
• GetHostInstance esegue una ricerca per TicketID su Pro-

perties.VIEW_TicketCompanyDbBackend
• GetQueryList accede a Properties.VIEW_Query con chia-

ve 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 chia-

ve di ricerca in QueryID
• LinkedServerConn accede alla tabella di sistema master.sys.sysservers

con chiave di ricerca in srvname
• SetBatch accede in scrittura alla colonna FK_StatusID di Proper-

ties.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 Ticke-

tID, 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 aggiorna-
te [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 auto-
incrementante. Per quanto detto una indicizzazione è opportuna.
VIEW_Query riflette la tabella Query e accede ad una elevata quan-

tità 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 indi-
ce sulla vista,è più opportuno indicizzare direttamente la tabella Result
aggiungendo un indice su TicketID di tipo unclustered, che ammetta du-
plicati.
Nel caso della tabella di sistema master.sys.sysservers, dato che i lin-

ked 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 tabel-

la è altresì sconsigliato in quanto questo significa assicurare che tut-
te 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 CREATE TRIGGER [Properties].[tgr_AdminExclusiveAllowance]
2 ON [Properties].[Query]
3 FOR INSERT, UPDATE, DELETE
4 AS
5
6 DECLARE @intCurrentID int
7
8 IF EXISTS(SELECT FK_TECUserID FROM INSERTED)
9 AND EXISTS(SELECT FK_TECUserID FROM DELETED)
10 BEGIN
11 PRINT ’UPDATE’;
12
13 IF -- Is admin or manager
14 BEGIN
15 -- Complete update
16 RETURN
17 END
18 ELSE
19 BEGIN
20 ROLLBACK
21 RETURN
22 -- EXIT POINT
23 END
24
25 END
26
27 IF EXISTS(SELECT * FROM INSERTED) -- Is an INSERT
28 BEGIN
29 PRINT ’INSERT’;
30
31 IF -- Is admin or manager
32 BEGIN
33 -- Complete admin
34 RETURN
35 END
36 ELSE
37 BEGIN
38 ROLLBACK
39 RETURN
40 -- EXIT POINT
41 END
42 END
43 ELSE
44 PRINT ’DELETE’;
45 -- delete is always executed. Must be combined in
46 -- Properties.DeleteQuery
La tabella RESULT contiene potenzialmente una elevata quantità di

dati e deve quindi essere valutata una strategia per mantenere esclusiva-
mente 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 pro-
cedure, 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.
Per una descrizione più dettagliata dei livelli di isolamento si rimanda

alla lettura di [7].
49
Stored Procedure Phantoms Non Repet. Read Dirty Read Lost Updates Transaction
GetBackendRootList Allowed Allowed Not Allowed Not Allowed READ COMMITTED SNAPSHOT
Reset Allowed Allowed Allowed Allowed READ UNCOMMITTED
SetDirectory Allowed Allowed Allowed Allowed READ UNCOMMITTED
SetFile Allowed Allowed Allowed Allowed READ UNCOMMITTED
SetServer Allowed Allowed Allowed Allowed READ UNCOMMITTED
DeleteQuery Allowed Allowed Not Allowed Not Allowed READ COMMITTED SNAPSHOT
ExecRemoteQuery Not Allowed Not Allowed Not Allowed Allowed SNAPSHOT
GetBatch Allowed Allowed Not Allowed Allowed READ COMMITTED SNAPSHOT
GetBatchList Allowed Allowed Not Allowed Not Allowed READ COMMITTED SNAPSHOT
GetEntityList Allowed Allowed Not Allowed Allowed READ COMMITTED SNAPSHOT
GetEventList Allowed Allowed Not Allowed Allowed READ COMMITTED SNAPSHOT
GetHostInstance Not Allowed Not Allowed Not Allowed Allowed SNAPSHOT
GetQueryList Allowed Allowed Not Allowed Allowed READ COMMITTED SNAPSHOT
GetQueryResultList Allowed Allowed Not Allowed Allowed READ COMMITTED SNAPSHOT
GetRemoteQueryResult Not Allowed Allowed Not Allowed Allowed SNAPSHOT
GetResult Allowed Allowed Not Allowed Allowed READ COMMITTED SNAPSHOT
GetSavedQueryResult Allowed Allowed Not Allowed Allowed –
Not Allowed Allowed Not Allowed Allowed –
Not Allowed Allowed Not Allowed Allowed SNAPSHOT
LinkedServerConn Allowed Allowed Not Allowed Allowed –
Not Allowed Allowed Not Allowed Allowed –
Allowed Allowed Not Allowed Allowed –
Not Allowed Allowed Not Allowed Allowed SNAPSHOT
SetBatch Allowed Allowed Not Allowed Not Allowed READ COMMITTED SNAPSHOT
SetQuery Allowed Allowed Not Allowed Not Allowed READ COMMITTED SNAPSHOT
SetQueryResult Allowed Allowed Not Allowed Not Allowed READ COMMITTED SNAPSHOT
SetResult Allowed Allowed Not Allowed Allowed READ COMMITTED SNAPSHOT
Tabella 4.1: Analisi delle Transazioni

Moduli A e B
4.1.9 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 infor-
mazioni 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 fac-
cia riferimento agli script 7_PreUpgradeCheck.sql e 17_IVUPreCalcula-
tionExample.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 dimen-
sioni 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 stabili-
re 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 è contro-
indicato 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 pro-
perty 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 SqlCommand cmd = new ...
2 SqlDataAdapter adapter = new ...
3 DataSet dataSetResult = new ...
4 [...]
5 adapter.SelectCommand = cmd;
6 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 MemoryStream memXmlStream = new ...
2 DataTable selectedDT = dataSetResult.Tables[indexTable];
3 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 <NewDataSet>
2 <xs:schema xmlns="" xmlns:xs="http://www.w3.org/2001/
XMLSchema" xmlns:msdata="urn:schemas-microsoft-com:
xml-msdata" id="NewDataSet">
3 <xs:element name="NewDataSet" msdata:IsDataSet="true"
msdata:MainDataTable="Table2" msdata:
UseCurrentLocale="true">
4 <xs:complexType>
5 <xs:choice minOccurs="0" maxOccurs="unbounded">
6 <xs:element name="Table2">
7 <xs:complexType>
8 <xs:sequence>
9 <xs:element name="Version" type="xs:int"
minOccurs="0" />
10 </xs:sequence>
11 </xs:complexType>
12 </xs:element>
13 </xs:choice>
14 </xs:complexType>
15 </xs:element>
16 </xs:schema>
17 <Table2>
18 <Version>860035</Version>
19 </Table2>
20 </NewDataSet>
Lo schema XML viene a sua volta utilizzato per creare un oggetto di

tipo SqlXml per essere salvato su DB:
1 SqlParameter tmpParam = null;
2 [..]
3 tmpParam = new SqlParameter("@xmlExecutionResult",
SqlDbType.Xml);
4 tmpParam.Value = new SqlXml(memXmlStream);
5 cmd.Parameters.Add(tmpParam);
Allo stesso modo i risultati salvati in formato XML vengono carica-

ti da DB e il datatable viene ricostruito sulla base dello schema che li
accompagna:
1 SqlXml xmlResult = null;
2 SqlDataReader rdr = ...
3 xmlResult = rdr.GetSqlXml(0);
4 XmlReader xmlReader = xmlResult.CreateReader();
5 DataTable dt = new DataTable();
6 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 Result tmpResult = ...
2 dataGridViewResult.DataSource = tmpResult.ExecutionResult
dove tmpResult.ExecutionResult ritorna il DataTable remoto, prece-

dentemente 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 raccoglie-
re le informazioni dai server (server, cartelle e file contenuti) e salvar-
le su database. In figura 4.9 è rappresentata la classe ServerManager,
che fa uso della classe BackupManager la quale contiene 2 metodi sta-
tici 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 ser-
ver 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 rappresen-

ta 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.
class Class Model
Serv er
- folderList: List<IFolder>
- name: string
- root: string
+ GetFolderList() : List<IFolder>
+ GetName() : string
+ GetRoot() : string
+ Server(string, string)
Folder
- dirInfo: DirectoryInfo
- fileList: List<IFile>
- parentServer: IServer
«interface»
IServer + Folder(IServer, DirectoryInfo)
-parentServer
+ GetFolderList() : List<IFolder> + GetCreationDate() : DateTime
+ GetName() : string + GetFileList() : List<IFile>
+ GetRoot() : string + GetFolderInfo() : DirectoryInfo
+ GetFolderList(IServer) : List<IFolder>
+ GetLastModification() : DateTime
+ GetNumberOfFiles() : int
+ GetServer() : IServer
File
«interface»
- fileName: string
- fileT ype: string IFolder
- parentFolder: IFolder + GetCreationDate() : DateTime
-parentFolder + GetFileList() : List<IFile>
+ File(IFolder, string, string) + GetFolderInfo() : DirectoryInfo
+ GetFileList(IFolder) : List<IFile> + GetLastModification() : DateTime
+ GetFileType() : string + GetName() : string
+ GetFolder() : IFolder + GetNumberOfFiles() : int
+ GetName() : string + GetServer() : IServer
- recursiveSearch(IFolder, List<IFile>*) : void
«interface»
IFile
+ GetFileType() : string
+ GetFolder() : IFolder
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 assimila-
bile al CLR.
• I linked server garantiscono compatibilità con Sql 2000, 2005 e 2008.

Vengono implementati a livello database, consentono l’accesso re-
moto 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 configurazio-
ne 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 quan-

to 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 in-

formazioni 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 in-

formazioni 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

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 data-
base che realmente offrono un vantaggio in termini di spazio deal-
locabile. Si ricorda infatti che un database di medie-grosse dimen-
sioni (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 sequen-
ziale 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’o-

perazione 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 ac-
cedere 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 atti-
vi 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 po-
sto ad 1. Solamente le istanze che hanno superato il test di connessione
vengono inserite nella tabella temporanea delle istanze attive #tmpActi-
veInstances.
2. Raccolta informazioni da ogni server

Viene creata la tabella #tmpDbStatistics dove vengono salvate le infor-
mazioni 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 data-
base 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 in-
formazioni qui salvate da release a release. In caso di upgrade è compito
del programmatore provvedere al riallineamento dei dati [13]. Tale que-
ry calcola lo spazio occupato dal database (@dbsize), i bytes per pagina
(@bytesperpage) e il totale delle pagine allocate. La differenza tra le di-
mensioni totali del database e le pagine realmente allocate dagli oggetti
ci da lo spazio allocato non utilizzato. Una volta terminata tale proce-
dura i dati di tutti i database attualmenti presenti nei server si trovano
all’interno della tabella temporanea #tmpDbUnallocatedSpace.
4. Integrazione con Backup Manager

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’o-
perazione 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 decrescen-
te e viene effettuata l’operazione di shrinking solamente per i database
con spazio allocato non utilizzato sopra una certa soglia (in MB) stabi-
lita dall’utente. La procedura inizia controllando che il database non sia
il tempdb. In tal caso esegue il comando sp_dboption [10] con l’opzio-
ne ’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 richie-
derà 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 inte-
ressati da tale operazione. Per quanto appena detto, si rende necessaria
anche una operazione di shrink dei file di log, tramite il comando SH-
RINKFILE 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 IBackup-
ManagerFramework e le tabelle Backend Server,Directory e File sono:
• [BackupManager].[Reset] per eliminare il contenuto delle sud-

dette 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 car-
tella ritornando il Directory ID
• [BackupManager].[SetFile] per inserire nome, estensione, Direc-

tory ID della cartella di appartenenza e ritornando il File ID.
• [BackupManager].[GetBackendRootList] è utilizzata per re-

perire le informazioni relative ai server e alle rispettive root di-
rectory 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 rela-

zione 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 ven-
gono 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
Name
CreationTime
LastAccessTime
NumFiles
FK1 FK_BackendServerID
RestoredDatabase
File
PK FileID server_type
linked_server
Name database_name
Type database_size
FK1 FK_DirectoryID unallocated_space
Figura 4.10: Schema Logico DB (Schema BackupManager)

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 data-
base 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_Dele-
teOrphanDir.sql.
4.3 MODULO D
In questa sezione viene descritto come implementare la modifica al work-
flow 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

Nel momento in cui un Upgrade fallisce, il consulente può richie-

dere tramite PlugIn TEC un Forced Upgrade selezionando da un elen-
co l’area a cui appartiene. Il plug-in dovrà quindi richiamare tutte le
query relative all’entity opportuna e rilanciare l’upgrade (Il procedimen-
to 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 Consul-

tant, i quali possono escludere tutte le problematiche automatica-
mente rilevabili dalla procedura automatica
• Knowledge transfer migliorato: I problemi rilevati durante la fase

di upgrade vengono condivisi e la soluzione proposta viene control-
lata 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 in-
consistenze e duplicati che riguardano i Business Partners.
Capitolo 5
Risultati ottenuti
In questo capitolo vengono riassunti i risultati raggiunti a seguito dell’im-

plementazione 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’auto-
mazione 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 ripor-
tato in appendice, che fa uso degli eventi IVUPreRecalculation, IVUPo-
stRecalculation 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 aspettati-
ve, i risultati a video sono fluidi e non si ha percezione di ritardo nel trasfe-
rimento 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 al-

locato 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 SELECT SUM(unallocated_space)
2 FROM [BackupManager].[RestoredDatabase]
3 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 gior-
ni. 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 da-
tabase è 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 TE-
CAdmin 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 sup-

porto 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 Novem-
bre 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 im-
portanza 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 tut-
te 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 in-

terfacce IListSource ed ISerializable (o eventualmente IXmlSeria-
lizable). In questo modo IListSource permetterebbe all’oggetto di
71
6. Conclusioni e Raccomandazioni 72
interfacciarsi direttamente al DataGridView. L’interfaccia ISeriali-

zable permetterebbe di trasferire l’oggetto al server e di memoriz-
zarlo come stream di byte o alternativamente l’interfaccia IXml-
Serializable 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 differen-
ti interfacce come IPropertiesQuery, IPropertiesResult, IPropertiesBatch,
IPropertiesEvent e IPropertiesEntity. Questo permetterebbe agli svilup-
patori 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 distri-
buito. 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 ammini-

stratori 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ù ese-
cuzioni, anche sullo stesso ticket.
73
A. Raccolta Informazioni per la gestione query 74
• Le query vengono eseguite sempre o sul COMPANY-DB o sull’SBO-

COMMON 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 modi-
ficata. 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 da-

tabase presente nell’istanza dove lo script viene eseguito (TEC 3 o
TEC 4).
• 2_BackupManager_DataAnalisys.sql : Script utilizzato per l’ana-

lisi dopo aver caricato tutte le tabelle riferite dallo schema Backu-
pManager. Vengono scritti a video il numero di database replica-
ti, 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 inco-

sistenze 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 Proper-

ties e le relative tabelle al database TEC 4. Usato nel porting in
produzione.
• 10_Query_MDF_LDF.sql : Script utilizzato per visualizzare l’e-

lenco 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 in-

cosistenze 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 Ripri-

stinati 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 ese-

guite dal DBA durante l’attività di amministrazione di TEC (TEC
3)
• 21_IRUProbeScript5.sql : Script utilizzato per generare una tabel-

la 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 que-

ry 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 class Listener
3 {
4 TcpChannel m_tcpChannel;
5 HttpChannel m_httpChannel;
6
7 private void Listen()
8 {
9 try
10 {
11 // ... implements IServerChannelSinkProvider
12 CompressionServerSinkProvider
compressedServerSinkProvider = new ...
13
14 // ... implements IServerFormatterSinkProvider,
IServerChannelSinkProvider
15 BinaryServerFormatterSinkProvider
binaryServerSinkProvider = new ...
16 [...]
17 compressedServerSinkProvider.Next =
binaryServerSinkProvider;
18
19 if (mySettings.Protocol.Equals("tcp")
20 {
21 m_tcpChannel = new TcpChannel(props, null,
compressedServerSinkProvider);
22 ChannelServices.RegisterChannel(m_tcpChannel, true)
;
23 }
24 if (mySettings.Protocol.Equals("http")
25 {
26 m_httpChannel = new HttpChannel(props, null,
compressedServerSinkProvider);
27 ChannelServices.RegisterChannel(m_httpChannel,
false);
28 }
29
30 // register here all services
31 RemotingConfiguration.RegisterWellKnownServiceType(...)
;
79
C. Struttura base del Listener 80
32 [...]
33
34 }
35 catch (Exception ex)
36 {
37 [...]
38 }
39 }
40 }
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 data-
base:
• 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 cop-

pie DatabaseName, SBODatabaseName che appartengono all’HostName
(local) e all’istanza CompanyDb_SQLInstanceName della vista Proper-
ties.VIEW_TicketInstance Tali informazioni possono essere ottenute ese-
guendo la query seguente sul database TEC precendetemente ripristinato:
1 SELECT TicketID, DatabaseName, SBODatabaseName
2 FROM Properties.VIEW_TicketInstance
3 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 EXEC sp_addlinkedserver
2 @server=’(local)\INSTANCE2’, -- server_instance_database
3 @srvproduct=’’,
4 @provider=’SQLNCLI’,
5 @datasrc=’(local)\INSTANCE2’ -- server\instance
Si abilita il supporto alle chiamate RPC su (local)\INSTANCE2 tra-

mite la stored procedure di sistema
1 exec sp_serveroption @server=’(local)\INSTANCE2’, @optname=’rpc’,
@optvalue=’true’
2 exec sp_serveroption @server=’(local)\INSTANCE2’, @optname=’rpc out’,
@optvalue=’true’
E’ possibile verificare la corretta configurazione dei linked server tra-

mite 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 CREATE ASSEMBLY CLRAssembly FROM ’C:\SqlServerProjectCLR.dll’
2 WITH PERMISSION_SET = SAFE
3 GO
4
5 CREATE PROCEDURE Properties.ExecRemoteQuery
6 @strLinkedServer nvarchar(max),
7 @strRemoteQuery nvarchar(max)
8 AS EXTERNAL NAME
9 CLRAssembly.StoredProcedures.RemoteQuery
10 GO
L’ultima operazione da effettuare sul database TEC è quella di abili-

tare il supporto alle transazioni di tipo snapshot, tramite il comando:
1 ALTER DATABASE TEC
2 SET READ_COMMITTED_SNAPSHOT ON;
3 GO
4
5 ALTER DATABASE TEC
6 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 SQLConnectionString-

Properties
Per verificare il funzionamento dei database di cui sopra, devono esse-
re inserito nel file di configurazione il TicketID 41 (associato al Database
105) oppure il TicketID 67 (associato al Database 147). L’aggiunta, mo-
difica o cancellazione di query avviene soltanto se nel file di configurazione
viene impostato un TECUserID con autorizzazioni di TECAdmin o Ma-
nager (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 Query-
Processor (Fig. E.1) e ResultAnalyzer (Fig. E.2). Queste GUI vengono
utilizzate durante la fase di sviluppo per testare l’implementazione dell’in-
terfaccia 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 DA-

TA)
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 grafi-
che:
L’UserControl AdminQueries (Fig. E.4) permette di aggiungere o ri-
muovere una query nell’evento selezionato. Per ogni query si deve spe-
cificare 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 POST-

CALCULATION.
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 PRE-
CALCULATION ritorna dei risultati.
Appendice F
Elenco dei server gestiti
ID SERVER INSTANCE AddOn VERSION

1 pwdf2412 B1_20042BADDON 1 2004
2 pwdf2412 B1_2004AADDON 1 2004
3 pwdf2412 B1_2005ASP00 0 2005 SP00
4 pwdf2412 B1_2005ASP01 0 2005 SP01
5 pwdf2412 O5B12005ASP1 0 2005 SP01
6 pwdf2413 B1_2004A 0 2004
7 pwdf2413 B1_2005ASP00ADD 1 2005 SP00
8 pwdf2413 B1_2005ASP01 0 2005 SP01
9 pwdf2413 B1_2005BSP00 0 2005 SP00
10 pwdf2413 B1_2005BSP00ADD 1 2005 SP00
11 pwdf2413 O5B12005ASP1 0 2005 SP01
12 pwdf2413 O5B12005BSP0 0 2005 SP00
13 pwdf2660 B1_2004A 0 2004
14 pwdf2660 B1_2005ASP01 0 2005 SP01
15 pwdf2660 O5B12005ASP1 0 2005 SP01
16 pwdf2681 B1_2005ASP01 0 2005 SP01
17 pwdf2681 B1_2005ASP01ADD 1 2005 SP01
18 pwdf2681 O5B12005ASP1 0 2005 SP01
19 pwdf2681 O5B12005ASP1ADD 1 2005 SP01
20 pwdf2806 B1_20042B 0 2004
21 pwdf2806 B1_20042BADDON 1 2004
22 pwdf2806 B1_2004A 0 2004
23 pwdf2806 B1_2004C 0 2004
24 pwdf2806 B1_2004CADDON 1 2004
25 pwdf2806 B1_2005ASP01ADD 1 2005 SP01
26 pwdf2806 B1_2007BSP00 0 2007
27 pwdf2806 O5B12005ASP1ADD 1 2005 SP01
28 pwdf2806 O5B12007BSP0 0 2007
29 pwdf2806 O5B12007BSP0ADD 1 2007
30 pwdf2807 B1_20042B 0 2004
31 pwdf2807 B1_2004A 0 2004
32 pwdf2807 B1_2004AADDON 1 2004
33 pwdf2807 B1_2005ASP00 0 2005 SP00
34 pwdf2807 B1_2005ASP01 0 2005 SP01
35 pwdf2807 B1_2005ASP01ADD 1 2005 SP01
36 pwdf2807 B1_2007AFP01 0 2007 FP01
37 pwdf2807 O5B12005ASP1 0 2005 SP01
38 pwdf2807 O5B12005ASP1ADD 1 2005 SP01
39 pwdf2807 O5B12007AFP01 0 2007 FP01
91
F. Elenco dei server gestiti 92
40 pwdf3119 B1_2004AADDON 1 2004

41 pwdf3119 B1_2005ASP00 0 2005 SP00
42 pwdf3119 B1_2005ASP01 0 2005 SP01
43 pwdf3119 B1_2005BSP00 0 2005 SP00
44 pwdf3119 O5B12005ASP1 0 2005 SP01
45 pwdf3119 O5B12005BSP0 0 2005 SP00
46 pwdf3129 B1_2004A 0 2004
47 pwdf3129 B1_2004C 0 2004
48 pwdf3129 B1_2005ASP00ADD 1 2005 SP00
49 pwdf3129 B1_2005ASP01 0 2005 SP01
50 pwdf3129 B1_2005BSP00 0 2005 SP00
51 pwdf3129 B1_2005BSP00ADD 1 2005 SP00
52 pwdf3129 O5B12005ASP1 0 2005 SP01
53 pwdf3129 O5B12005BSP0 0 2005 SP00
54 pwdf3129 O5B12007ASP0 0 2007
55 pwdf3130 B1_2004AADDON 1 2004
56 pwdf3130 B1_2005ASP00 0 2005 SP00
57 pwdf3130 B1_2005ASP01 0 2005 SP01
58 pwdf3130 B1_2005BSP00 0 2005 SP00
59 pwdf3130 O5B12005ASP1 0 2005 SP01
60 pwdf3130 O5B12005BSP0 0 2005 SP00
61 pwdf6003 B1_2005ASP01 0 2005 SP01
62 pwdf6003 B1_2005ASP01ADD 1 2005 SP01
63 pwdf6003 B1_2007ASP00 0 2007
64 pwdf6003 O5B12005ASP1 0 2005 SP01
65 pwdf6003 O5B12005ASP1ADD 1 2005 SP01
66 pwdf6003 O5B12007ASP0 0 2007
67 PWDF6500VM04 B1_2005ASP01 0 2005 SP01
68 PWDF6500VM04 B1_2005BSP00 0 2005 SP00
69 PWDF6500VM04 B1_2007ASP00 0 2007
70 PWDF6500VM04 O5B12005ASP1 0 2005 SP01
71 PWDF6500VM04 O5B12005BSP0 0 2005 SP00
72 PWDF6500VM04 O5B12007ASP0 0 2007
73 pwdf6544 B1_2005ASP01 0 2005 SP01
74 pwdf6544 B1_2005BSP00 0 2005 SP00
75 pwdf6544 B1_2007ASP00 0 2007
76 pwdf6544 O5B12005ASP1 0 2005 SP01
77 pwdf6544 O5B12005BSP0 0 2005 SP00
78 pwdf6544 O5B12007ASP0 0 2007
79 pwdf6545 B1_2005ASP01 0 2005 SP01
80 pwdf6545 B1_2005BSP00 0 2005 SP00
81 pwdf6545 B1_2007AFP01 0 2007 FP01
82 pwdf6545 B1_2007ASP00 0 2007
83 pwdf6545 O5B12005ASP1 0 2005 SP01
84 pwdf6545 O5B12005BSP0 0 2005 SP00
85 pwdf6545 O5B12007AFP01 0 2007 FP01
86 pwdf6545 O5B12007AFP01ADD 1 2007 FP01
87 pwdf6545 O5B12007ASP0 0 2007
88 pwdfe025 B1_2005ASP00 0 2005 SP00
89 pwdfe025 B1_2005ASP01 0 2005 SP01
90 pwdfe025 B1_2005BSP00 0 2005 SP00
91 pwdfe025 B1_2007ASP00 0 2007
92 pwdfe025 O5B12005ASP1 0 2005 SP01
93 pwdfe025 O5B12005BSP0 0 2005 SP00
94 pwdfe025 O5B12007ASP0 0 2007
95 pwdfe025 O5B12007ASP0ADD 1 2007
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. Understan-

ding 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).

2006. [cited at p. 48]
[8] Microsoft Corporation. sp_spaceused (transact-sql).

2008. [cited at p. 57]
[9] Microsoft Corporation. Designing indexed views.

http:// msdn.microsoft.com/ en-us/ library/ ms187864.aspx, 2009.
[cited at p. 44]
93
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 ser-

ver 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 - architec-
tural 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 ser-

ver 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 96
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

Tesi Manfrin

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Tesi Manfrin

Caricato da

Copyright:

Formati disponibili

UNIVERSITÀ DEGLI STUDI DI TRIESTE

An application to manage and automate

Desidero ringraziare quanti hanno contribuito alla mia formazione e alla

3 Progetto del Sistema 11

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

2.1 Business One Workflow . . . . . . . . . . . . . . . . . . . 4

4.1 Interfaccia PropertiesFramework e sua implementazione . 35

4.11 Directories orfane . . . . . . . . . . . . . . . . . . . . . . . 60

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

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

E.1 GUI QueryProcessor . . . . . . . . . . . . . . . . . . . . . 85

3.1 Tabella Query . . . . . . . . . . . . . . . . . . . . . . . . . 18

4.1 Analisi delle Transazioni . . . . . . . . . . . . . . . . . . . 49

L’ottimizzazione delle risorse, la riduzione dei costi e l’aumento della

• semplificare la modalità con cui i consulenti si connettono alle ba-

• fornire agli altri sviluppatori una interfaccia che consenta di au-

• migliorare la gestione della server farm riducendo i crash di sistema

2.1 Descrizione del Problema

2.1.1 Contesto Aziendale

• L’Utente Finale: è una azienda che usa il prodotto SAP Business

• L’ Install Base Development (IBD): IBD è il dipartimento più inter-

Figura 2.1: Business One Workflow

2.1.2 Overview Sistemi ed Entità

2.1.3 Pratica Interna

GERMANY (WALLDORF) WORLDWIDE

DOWNLOAD & RESTORE

Patch Level (PL)

Figura 2.2: Business One System Overview

2.1.4 Software Preesistente

• 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

2.2 Analisi del Problema

2.2.1 Definizione del Problema

• Rivedere l’implementazione di TEC, aggiungendo un modulo per

• Migliorare la gestione della server farm, riducendo lo spazio occu-

• Rivedere il processo di supporto interno fornito dal GSC System

SAP ha dato incarico al Project Manager di coordinare lo sviluppo

2.3 Analisi dei Requisiti

2.3.1 Vincoli di progetto

• L’ambiente di sviluppo da utilizzare deve essere Visual Studio

• Il linguaggio di programmazione deve essere C# in quanto il Team

• Tutti i client girano su piattaforma Windows. Eventuali client non

• Data la necessità di concludere la prima release di TEC 4 entro

• Tutte le operazioni che comportano iterazioni con le basi dati dei

2.3.2 Casi d’uso

1. Filter & View

4. Backup Manager «communicate» Serv er Farm

6. Properties 9. TEC Serv er

Figura 2.3: Use Case del Sistema

2.3.3 Planning delle attività

3.1 Moduli A e B: Generic Query

3.1.1 Il canale di comunicazione

• 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’am-