REALIZZAZIONE DI UNA WEB PART PER L'ACCESSO A MOTORI DI BASI DI DATI RELAZIONALI

1. 1
UNIVERSITA’ DEGLI STUDI DI TRIESTE
FACOLTA’ DI INGEGNERIA
DIPARTIMENTO DI INGEGNERIA E ARCHITETTURA
REALIZZAZIONE DI UNA WEB PART PER
L'ACCESSO A MOTORI DI BASI DI DATI
RELAZIONALI
Relatore: Chiar.mo prof. Maurizio Fermeglia
Laureando: Stefano Cenizzi
Anno Accademico: 2012-2013

2. 2
INDICE
1.Introduzione ................................................................................................................. 4
2. Presentazione delle richieste ...................................................................................... 5
3.Analisi delle richieste.................................................................................................... 6
4. Strumenti necessari allo sviluppo del Progetto............................................................ 6
4.1 Hardware ............................................................................................................... 6
4.1.1 PC notebook G73SW ...................................................................................... 6
4.2 Software................................................................................................................. 7
4.2.1 Sharepoint 2010 e 2013 e Hyper-V ................................................................. 7
4.2.2 SQL Server 2008 R2 e SQL Server 2012........................................................ 7
4.2.3 Microsoft Visual Studio 2008 e 2012 ............................................................... 7
4.2.4 Linguaggio C#.................................................................................................. 7
5 Setup Ambiente di sviluppo.......................................................................................... 8
5.1 Configurazione framework ..................................................................................... 8
5.2 Connessione con ambiente SharePoint................................................................. 8
5.3 PFX e Strong Names Signature............................................................................. 8
5.3.1 PFX.................................................................................................................. 8
5.3.2 Strong-Name Signature ................................................................................... 8
6. Analisi del Progetto ................................................................................................... 10
6.1 Analisi delle Tabelle ............................................................................................. 10
6.2 Analisi della Compatibilità .................................................................................... 14
7 Struttura del progetto.................................................................................................. 15
7.1 DbConnector........................................................................................................ 15
7.1.1 DbConnection.cs ........................................................................................... 16
7.1.2 QueryRunner.cs............................................................................................. 17
7.2 DbSource............................................................................................................. 18
7.2.1 DataTypeField.cs........................................................................................... 18
7.2.1 DBField.cs ..................................................................................................... 19
7.2.2 DbSource.cs .................................................................................................. 22
7.2.3 DBTable.cs ................................................................................................... 23

3. 3
7.3 GestioneDB.......................................................................................................... 25
7.3.1 MAL.cs........................................................................................................... 25
7.3.2 WebPartDB.cs ............................................................................................... 25
8.Installazione e visualizzazione ................................................................................... 27
8.1 Installazione......................................................................................................... 27
8.2 Disinstallazione della Web Part............................................................................ 31
8.3 Esempi di installazione......................................................................................... 31
8.3.1 AdventureWorks ............................................................................................ 31
8.3.2 Nanotech ....................................................................................................... 33
8.3.3 Gestione Ambiente e Territorio...................................................................... 35
9.Conclusioni............................................................................................................... 36

4. 4
1.Introduzione
La tesi proposta nel seguente documento andrà a trattare l’aggiornamento ed un
eventuale sviluppo di una WebPart la quale inizialmente nasce come applicazione per
SharePoint 2008 supportando un unico database relazionale sviluppato ad-hoc.
L’obbiettivo ora è quello di analizzare la struttura e la logica del funzionamento della
WebPart e aggiornarla in modo da poter essere utilizzabile su sistemi più moderni quali
SharePoint 2010 con SQL Server 2008 e SharePoint 2013 con SQL Server 2012.
Successivamente si potrà quindi modificare il progetto affinché diventi funzionante con
qualsiasi database creato (sempre su SQL Server).
Per iniziare lo sviluppo dobbiamo installare SharePoint 2008 per vedere come appare la
WebPart e farci un’idea sul suo funzionamento.
In seguito, dopo aver importato il progetto su Visual Studio 2010 si utilizzerà il deploy
dell’ambiente di sviluppo per tentare di caricare il programma su SharePoint 2010
analizzando l’eventuale errore.
A questo punto dopo aver analizzato le funzioni della WebPart, si individueranno quali
siano state deprecate o eliminate da SharePoint 2010 rispetto alla versione 2008.
Dopo un’eventuale modifica di alcune funzioni si riuscirà a caricare la WebPart senza
ricevere alcun errore: sarà comunque necessario verificarne il completo funzionamento
con il database su cui precedentemente è stata sviluppata.
Una volta che il deploy avrà avuto successo, sarà necessario modificare ulteriormente il
progetto per renderlo completamente funzionante con il database esistente, verrà quindi
utilizzato lo strumento di debug in real-time per trovare e correggere eventuali errori.
Infine dopo che la WebPart sarà funzionante su SharePoint 2010 con il database su cui
è stata sviluppata, si potrà aggiornare un’ultima volta per renderla compatibile con un
maggior numero possibile di database.
Per motivi dettagliati in seguito, la stessa procedura dovrà essere attuata anche per
SharePoint 2013.
I capitoli della tesi sono così distribuiti:
● 2) e 3) presentazione delle specifiche richieste dal committente e la
relativa analisi del progetto
● 4) descrizione delle strumentazione hardware e software utilizzate
● 5) definizione del setup per poter procedere nel progetto
● 6) analisi delle tabelle necessarie al corretto funzionamento

5. 5
dell’applicativo
● 7) creazione e spiegazione delle parti fondamentali del progetto
● 8) installazione e visualizzazione del progetto con esempi visivi
● 9) conclusioni
2. Presentazione delle richieste
Il committente del progetto ha richiesto un aggiornamento dell’applicativo utilizzato per
la gestione del database tramite il web. Il suddetto applicativo permette di non dover
utilizzare applicazioni esterne e quindi di poter modificare, cancellare e aggiornare
records sul database da ogni computer che, ha diritti di accesso all’applicativo.
Le richieste in sintesi sono le seguenti:
● aggiornamento della WebPart affinché sia compatibile con SharePoint 2010
● verifica della compatibilità anche con SharePoint 2013
● aggiornamento affinché sia compatibile con SharePoint 2013
● aggiornamento dell’applicazione affinché sia utilizzabile con qualunque database

6. 6
3.Analisi delle richieste
La realizzazione del progetto richiede uno studio delle strutture dati utilizzate dalla
vecchia applicazione. Le tabelle utilizzate dall’applicativo devono essere create e
riempite secondo criterio ben definito altrimenti l’applicativo potrebbe non funzionare
correttamente.
In secondo luogo sarà importante conoscere le eventuali limitazioni dell’applicativo per
quanto riguarda l’utilizzo di API deprecate ed altre funzionalità cambiate o modificate
con il passaggio da SharePoint 2008 a SharePoint 2010/2013. Lo stesso vale per il
motore database, dove non solo sarà necessario controllare i parametri di connessione
al DBMS, ma anche i relativi permessi fra il database, la WebPart e SharePoint stesso.
4. Strumenti necessari allo sviluppo del Progetto
Il progetto necessità dell’utilizzo del seguente elenco di hardware e software:
(di seguito ne descriveremo le caratteristiche)
4.1 Hardware
4.1.1 PC notebook G73SW
E’ il pc portatile a disposizione del laureando: possiede un processore INTEL CORE i7
QUADCORE con 8GB di RAM DDR3 e una scheda video GTX460M.

7. 7
4.2 Software
4.2.1 SharePoint 2010, SharePoint 2013 e Hyper-V
Sia SharePoint 2010 che SharePoint 2013 necessitano di un ambiente server per
essere installati in maniera corretta così, per non ricorrere ad un partizionamento del
disco fisico, per installare Windows Server si è deciso di utilizzare la tecnologia Hyper-V
fornitaci da Windows 8.
Hyper-V è un server di virtualizzazione rilasciato con Windows Server 2008 per poi
andare a rimpiazzare il classico VirtualPC utilizzabile per i sistemi desktop. Grazie a
questo è possibile installare Windows Server 2008 su di una “macchina virtuale”
facendoci risparmiare tempo, in quanto è possibile, con alcuni accorgimenti, collegare il
software di sviluppo presente nel sistema desktop al sistema virtualizzato senza dover
reinstallarlo anche all’interno della macchina virtuale stessa.
Nel nostro caso poiché SharePoint 2010 non era compatibile con Windows Server
2012, si è scelto di utilizzare due diversi ambienti di sviluppo per poter testare al meglio
la nostra applicazione: Windows Server 2008 R2 con SharePoint 2010 e Windows
Server 2012 con SharePoint 2013.
4.2.2 SQL Server 2008 R2 e SQL Server 2012
Sono i DBMS utilizzati nello sviluppo. Rispettivamente la versione di MS SQL Server
2008 R2 viene utilizzata con Windows Server 2008 R2 e SQL Server 2012 utilizzata
con Windows Server 2012.
4.2.3 Microsoft Visual Studio 2008 e 2012
Due versioni dello stesso ambiente di sviluppo, installate per essere ognuna compatibile
con il sistema operativo su cui si deve lavorare coerentemente con le versioni di SQL
Server e SharePoint.
4.2.4 Linguaggio C#
Il C# è un linguaggio di programmazione orientato agli oggetti e sviluppato da Microsoft
all'interno dell'iniziativa .NET. Linguaggio utilizzato per lo sviluppo dell’intera
applicazione.

8. 8
5 Setup Ambiente di sviluppo
5.1 Configurazione framework .NET
Per la creazione del progetto la prima cosa da fare è selezionare che versione di
framework utilizzare.
E’ possibile specificare il framework anche successivamente, ma è consigliabile
indicare la versione sulla quale si lavorerà prima di compilare i vari progetti, per non
incappare in possibili problemi di compatibilità con le dipendenze.
5.2 Connessione con ambiente SharePoint
Per poter modificare un progetto SharePoint, l’ambiente di sviluppo vi chiederà di
indicare l’indirizzo del server SharePoint su cui caricare l’applicazione.
Questo è necessario perché per poter testare il funzionamento di quest’ultima, servirà
caricare la WebPart all’interno del server. Inoltre è possibile specificare come sarà
caricato il progetto: “sandboxed solution” quindi in maniera temporanea monitorata e
con accesso limitato alla web farm, o come “farm solution” e quindi installata come
versione finale.
5.3 PFX e Strong Names Signature
5.3.1 PFX
La firma di un assembly, chiamata anche firma con nome sicuro, fornisce un'identità
univoca ad un'applicazione o ad un componente, che può essere utilizzata da un'altra
funzionalità software per identificare e fare riferimento esplicitamente all'applicazione o
al componente. Un nome sicuro è composto dal nome in testo semplice, dal numero di
versione, dalle informazioni sulle impostazioni cultura (se fornite) e da una coppia di
chiavi pubblica/privata dell'assembly. Queste informazioni vengono archiviate in un file
di chiave, che può essere un file PFX (Personal Information Exchange) o un certificato
dell'archivio certificati di Windows dell'utente corrente.
5.3.2 Strong-Name Signature
Un nome sicuro è costituito dall'identità dell'assembly, corrispondente al nome semplice
in formato testo, al numero di versione e alle informazioni sulle impostazioni cultura
eventualmente disponibili, nonché da una chiave pubblica e da una firma digitale. Viene
generato da un file dell'assembly (quello che contiene il manifesto, che a sua volta

9. 9
contiene i nomi e gli hash di tutti i file che costituiscono l'assembly), utilizzando la chiave
privata corrispondente. Visual Studio può assegnare nomi sicuri a un assembly. Due
assembly che hanno lo stesso nome sicuro vengono considerati uguali.
È possibile assicurarsi che il nome assegnato a un assembly sia univoco firmando
l'assembly con un nome sicuro. In particolare, i nomi sicuri soddisfano i seguenti
requisiti:
● Garantiscono l'univocità dei nomi perché sono basati su coppie di chiavi
univoche. Nessun altro può generare lo stesso nome per un assembly diverso,
perché un assembly generato con una determinata chiave privata avrà
necessariamente un nome diverso da quello di un assembly generato con una
chiave privata diversa.
● Garantiscono la discendenza di versione di un assembly. L'utilizzo di un nome
sicuro garantisce che nessun altro possa produrre una versione successiva del
proprio assembly. Gli utenti possono essere certi che la nuova versione
dell'assembly che si apprestano a utilizzare è stata prodotta dalla stessa fonte
che ha creato la versione con cui è stata compilata l'applicazione.
● Consentono un approfondito controllo dell'integrità. Il superamento dei controlli di
sicurezza di .NET Framework garantisce che il contenuto dell'assembly non sia
stato modificato successivamente alla compilazione. Si noti comunque che i
nomi sicuri in sé non garantiscono un livello di attendibilità, come quello fornito
invece, ad esempio, da una firma digitale e dal supporto dei certificati.
Quando si fa riferimento ad un assembly con nome sicuro, si conta di ottenere
determinate garanzie, quali il controllo delle versioni e la protezione dei nomi. Se
l'assembly con nome sicuro a cui si fa riferimento fa a sua volta riferimento a un
assembly con nome semplice, che non presenta i vantaggi descritti, si perdono i
benefici che derivano dall'uso di un assembly con nome sicuro e si rigenera il problema
dei conflitti tra DLL. Gli assembly con nome sicuro possono pertanto fare riferimento
solo ad altri assembly con nome sicuro.

10. 10
6. Analisi del Progetto
6.1 Analisi delle Tabelle
Perché la WebPart funzioni in maniera corretta è necessario che il database in
questione presenti alcune caratteristiche che permetteranno al software di leggere,
creare e cancellare record in ogni tabella si voglia.
Abbiamo quindi bisogno di 3 tabelle che agiranno come “tabelle di sistema”.
Sappiamo infatti che nei database relazionali il database stesso crea più tabelle definite
appunto “tabelle di sistema” create esattamente come le tabelle dell'utente. Queste
tabelle servono al DBMS affinché sia in grado di sapere come sono fatte tutte le tabelle
all'interno, i tipi di dato che contengono, primary-key e foreign-key, insieme ad altre
informazioni definite automaticamente dal sistema.
Poiché per ottenere accesso a queste tabelle bisogna utilizzare gli strumenti di gestione
del motore database stesso, come ad esempio SQL MANAGEMENT STUDIO, in
ambiente remoto sarebbe improponibile, oltre al fatto che non sono modificabili
dall'utente.
Si è quindi deciso di adottare lo stesso sistema ideato da CODD, di modo da poter
interrogare il database è ottenere tutte le informazioni necessarie sulle altre tabelle.
Ecco appunto che grazie a queste nostre 3 tabelle possiamo utilizzare l'applicazione per
modificare, aggiungere o eliminare record da tutte le tabelle del nostro database.
Inoltre l'utilizzo di queste, ha risolto anche il problema delle relazioni “molti a molti”.
Infatti benché nelle relazioni “1 a 1” o “1 a molti” basterebbe una “vista” o più “viste”,
nelle relazioni “molti a molti” creare un'interfaccia utilizzabile senza l'utilizzo delle tabelle
create appositamente ogni volta che si modifica il database, sarebbe molto complicato.
Vediamo quindi con maggiore dettaglio le 3 tabelle in questione:
1. TblAssociateTable
2. TblForeignKey
3. TblFieldsForForeignKey
La prima deve avere la seguente struttura:

11. 11
Figura 1 Struttura della AssociateTable
Il significato dei campi è il seguente:
1. TableName: nome della tabella nel Database
2. TableNamePresentation: nome che si desidera associare alla tabella e da
visualizzare nella WebPart.
3. Permission: questo campo dev’essere valorizzato con “Admin” se si desidera che
la tabella sia abilitata solamente all’utente amministrazione, ed è possibile
valorizzare con “All” se la tabella non presenta restrizioni
Ecco quindi un esempio di ciò che la prima tabella potrebbe contenere:
Figura 2 Esempio contenuto TblAssociateTable
La seconda tabella avrà la seguente struttura:

12. 12
Figura 3 Struttura TblForeignKey
ed un esempio di dati in essa contenuti:
Figura 4 Dati di esempio per la tabella TblForeignKey
Il significato dei campi è il seguente:
1. TableSource: nome della tabella sorgente (quella che contiene il campo con la
chiave esterna)
2. TableDestination: nome della tabella di destinazione (alla quale è collegata la
chiave esterna)
3. FieldTableSource: il nome del campo nella tabella sorgente
4. FieldTableDestination: il nome del campo nella tabella di destinazione
5. Fields: il nome dei campi che saranno visualizzati al posto del valore della chiave
esterna
La terza tabella non prevede nessuna funzionalità per l’applicazione ma va comunque
implementata all’interno del DB per compatibilità con alcuni metodi del programma.
La struttura è la seguente:

13. 13
Figura 5 Struttura della tabella TblFieldsForForeignKey
Non è indispensabile inserire alcun dato.
Questa tabella ha lo scopo di specificare, nel caso la foreign-key fosse composta da più
campi, quale si vuole utilizzare. Poiché la foreign-key è composta da un campo e
corrisponde solo ad un campo contenente una primary-key di un’altra tabella, questa
tabella non viene utilizzata, ma nel caso servisse essa è già implementata
nell'applicazione.
La presenza di queste 3 tabelle è quindi fondamentale per il corretto funzionamento
della WebPart.
Va considerato inoltre che la WebPart considera alcune variabili con nomi standard
integrate nel codice: prime fra tutte le primary-key e le foreign-key devono essere
obbligatoriamente nel formato “PK_nome” e “FK_nome” esattamente come le genera
automaticamente SQL server.
Vediamo un esempio creato utilizzando il “tool” da riga di comando:
USE AdventureWorks2012;
GO
ALTER TABLE Production.TransactionHistoryArchive
ADD CONSTRAINT PK_TransactionHistoryArchive_TransactionID PRIMARY KEY
CLUSTERED (TransactionID);
GO
Un nome diverso da quello standard potrebbe provocare un malfunzionamento
dell’applicazione per le tabelle che hanno chiavi primarie senza suffisso standard.
Un ulteriore limitazione è data dai “types” che la WebPart permette di modificare: ma al
momento sono supportati solo i campi di tipo float, int, money, datetime, bit, varchar,
char, nvarchar e nchar. Tutti i campi diversi da questi verranno visualizzati nelle tabelle,
ma non saranno modificabili in quanto non riconosciuti.

14. 14
6.2 Analisi della Compatibilità
Benché non ci siano grosse differenze sostanziali, va da notare che un’unica soluzione
compatibile con entrambe le piattaforme non è stata possibile.
Infatti pur non essendo vincolato da SharePoint stesso, il quale comporta comunque
svariate modifiche a livello di API e metodi deprecati, non era possibile avere la
versione compilata per SharePoint 2010 utilizzabile su SharePoint 2013 e neppure
viceversa.
Per svincolarci da SharePoint in maniera quasi netta, si è dovuto utilizzare in maniera
più diretta il framework .Net, permettendoci quindi di avere due versioni del compilato
con codice identico ma con dipendenze diverse.
Nel primo caso infatti si fa riferimento alla versione del 3.5 del framework .Net, mentre
nel secondo caso si fa riferimento alla versione 4.5.
Nonostante questo, anche se abbiamo utilizzato la maggior parte della API fornitoci dal
framework, la WebPart è una componente supportata da SharePoint e quindi non è
possibile svincolarsi in maniera completa. Si suppone però che grazie a questo massivo
utilizzo del framework, nel caso ci sia bisogno di un futuro aggiornamento ad un
versione di SharePoint aggiornata, basterà ricompilare il programma utilizzando il
framework aggiornato.

15. 15
7 Struttura del progetto

16. 16
7.1 DbConnector
7.1.1 DbConnection.cs
I metodi definiti in questa classe definiscono i parametri di connessione della WebPart
al database:
class DbConnection
{
#region Fields
IDbConnection _conn;
private string _catalog;
private string _userId;
private string _passwordId;
private string _dataSource;
private bool _security;
#endregion
#region Property
public string Catalog
{
get { return _catalog; }
set { _catalog = value; }
}
public string UserId
{
get { return _userId; }
set { _userId = value; }
}
public string PasswordId
{
get { return _passwordId; }
set { _passwordId = value; }
}
public string DataSource
{
get { return _dataSource; }
set { _dataSource = value; }
}

17. 17
public bool Security
{
get { return _security; }
set { _security = value; }
}
#endregion
…
Inoltre vengono anche specificati alcuni metodi base per aggiornare, inserire e
cancellare records.
7.1.2 QueryRunner.cs
I metodi definiti in questa classe servono oltre che a richiamare il DbConnection
passandogli i parametri di connessione, anche a generare le Query da fare che
verranno fatte al database:
public class QueryRunner
{
#region Fields
private DbConnection _conn = null;
private string _dataSource;
private string _catalog;
private string _user;
private string _password;
private bool _security;
#endregion
#region Property
public string DataSource
{
get { return _dataSource; }
set { _dataSource = value; }
}
public string Catalog
{
get { return _catalog; }
set { _catalog = value; }
}
public string UserId
{

18. 18
get { return _user; }
set { _user = value; }
}
public string PasswordId
{
get { return _password; }
set { _password = value; }
}
public bool Security
{
get { return _security; }
set { _security = value; }
}
#endregion
…
7.2 DbSource
Qui di seguito saranno elencati i principali metodi della classe DbSource, la quale serve
a leggere la struttura delle tabelle e i suoi records.
7.2.1 DataTypeField.cs
public class DataTypeField
{
private string _dataType;
private int? _length;
public string DataType
{
get { return _dataType; }
set { _dataType = value; }
}
public int? Length
{
get { return _length; }
set { _length = value; }
}
public DataTypeField()

19. 19
{
}
public DataTypeField(string pDataType, int pLength)
{
DataType = pDataType;
Length = pLength;
}
}
7.2.1 DBField.cs
public class DBField
{
#region Private Field
private string _table_Catalog;
private string _table_Schema;
private string _table_Name;
private string _column_Name;
private string _ordinal_Position;
private string _column_Default;
private string _is_Nullable;
private string _data_Type;
private string _character_Maximun_Lenght;
private string _character_Octet_Lenght;
private string _numeric_Precision;
private string _numeric_Precision_Radix;
private string _numeric_Scale;
private string _datetime_Precision;
private string _character_Set_Name;
private string _collation_Name;
#endregion
#region Property
public string Table_Catalog
{
get { return _table_Catalog; }
set { _table_Catalog = value; }
}
public string Table_Schema

20. 20
{
get { return _table_Schema; }
set { _table_Schema = value; }
}
public string Table_Name
{
get { return _table_Name; }
set { _table_Name = value; }
}
public string Column_Name
{
get { return _column_Name; }
set { _column_Name = value; }
}
public string Ordinal_Position
{
get { return _ordinal_Position; }
set { _ordinal_Position = value; }
}
public string Column_Default
{
get { return _column_Default; }
set { _column_Default = value; }
}
public string Is_Nullable
{
get { return _is_Nullable; }
set { _is_Nullable = value; }
}
public string Data_Type
{
get { return _data_Type; }
set { _data_Type = value; }
}
public string Character_Maximun_Lenght
{
get { return _character_Maximun_Lenght; }
set { _character_Maximun_Lenght = value; }
}

21. 21
public string Character_Octet_Lenght
{
get { return _character_Octet_Lenght; }
set { _character_Octet_Lenght = value; }
}
public string Numeric_Precision
{
get { return _numeric_Precision; }
set { _numeric_Precision = value; }
}
public string Numeric_Precision_Radix
{
get { return _numeric_Precision_Radix; }
set { _numeric_Precision_Radix = value; }
}
public string Numeric_Scale
{
get { return _numeric_Scale; }
set { _numeric_Scale = value; }
}
public string Datetime_Precision
{
get { return _datetime_Precision; }
set { _datetime_Precision = value; }
}
public string Character_Set_Name
{
get { return _character_Set_Name; }
set { _character_Set_Name = value; }
}
public string Collation_Name
{
get { return _collation_Name; }
set { _collation_Name = value; }
}
…

22. 22
7.2.2 DbSource.cs
public class DBSource
{
#region Fields
private QueryRunner _qr = null;
private Dictionary<string, DBTable> tableDictionary = null;
private Dictionary<string, ForeignKey> fkDictionary = null;
private Dictionary<string, KeyCollection> keyDictionary =
null;
private Dictionary<string, string> fieldForForeignKey = null;
private Dictionary<string, ForeignKeyBis> fkDictionaryBis =
null;
private int _defaultWidthComboBox;
private int _defaultWidthTextBox;
private int _defaultWidthTextArea;
private int _multiLineTextArea;
private string _connectedUser;
private bool _checkIfConnectedUser;
private string _adminUser;
#endregion
#region Property
public QueryRunner QR
{
get { return _qr; }
set { _qr = value; }
}
public int DefaultWidthComboBox
{
get { return _defaultWidthComboBox; }
set { _defaultWidthComboBox = value; }
}
public int DefaultWidthTextBox
{
get { return _defaultWidthTextBox; }
set { _defaultWidthTextBox = value; }
}

23. 23
public int DefaultWidthTextArea
{
get { return _defaultWidthTextArea; }
set { _defaultWidthTextArea = value; }
}
public int MultiLineTextArea
{
get { return _multiLineTextArea; }
set { _multiLineTextArea = value; }
}
public string ConnectedUser
{
get { return _connectedUser; }
set { _connectedUser = value; }
}
public bool CheckIfConnectedUser
{
get { return _checkIfConnectedUser; }
set { _checkIfConnectedUser = value; }
}
public string AdminUser
{
get { return _adminUser; }
set { _adminUser = value; }
}
#endregion
…
7.2.3 DBTable.cs
public class DBTable
{
#region Fields
private string _table_Catalog;
private string _table_Schema;
private string _table_Name;
private TableType _table_Type;

24. 24
private Dictionary<string, DBField> fieldDictionary = null;
#endregion
#region Public Fields
public enum TableType
{
TABLE = 1,
VIEW = 2
}
#endregion
#region Property
public string Table_Catalog
{
get { return _table_Catalog; }
set { _table_Catalog = value; }
}
public string Table_Schema
{
get { return _table_Schema; }
set { _table_Schema = value; }
}
public string Table_Name
{
get { return _table_Name; }
set { _table_Name = value; }
}
public TableType Table_Type
{
get { return _table_Type; }
set { _table_Type = value; }
}
…

25. 25
7.3 GestioneDB
In questa sezione abbiamo la vera e propria WebPart che è composta da due file.
7.3.1 MAL.cs
In questa classe ci sono tutti i metodi che servono per recuperare le informazioni da
SharePoint, quali l’utente connesso, il sito su cui è attiva la WebPart ecc.
public class MAL
{
private SPSite spSite = null;
private SPWeb webSite = null;
private string _urlSite = string.Empty;
…
7.3.2 WebPartDB.cs
In questa classe vi sono tutti i metodi e le proprietà della WebPart stessa, quali colori
css, informazioni di connessione ecc.
public class WebPartDB : WebPart, IPostBackEventHandler
{
#region Fields
private bool _error;
private QueryRunner _qr;
private DBSource _source;
private MAL _mal;
private string _dataSource;
private string _user;
private string _password;
private string _catalog;
private string _selectedTable;
private bool _detailsView;
private bool _addNewRecord;
private string _cssFirstRow;
private string _cssTable;
private string _cssHeaderRow;

26. 26
private string _cssEvenNumberRow;
private string _cssOddNumberRow;
private string _cssBtnDetailsButton;
private string _cssBtnViewTableButton;
private string _cssBtnAddNewRecordButton;
private string _cssBtnCommandUpdateDelete;
private string _cssTextBox;
private string _cssComboBox;
private string _cssTextArea;
private string _cssCheckBox;
private string _cssSuggestLabel;
private int _defaultWidthComboBox;
private int _defaultWidthTextBox;
private int _defaultWidthTextArea;
private int _defaultLineInMultiline;
private bool _viewSQLStatement;
private bool _viewStackTrace;
private bool _useSpecificPathForWSSUser;
private string _specificPathForWSSUser;
private bool _viewUserAndPathInformation;
private bool _controlUserAccess;
private string _adminUser;
private bool _authToggle;
private string _prefixControlForm;
private List<string> _pkVal;
#endregion
…

27. 27
8.Installazione e visualizzazione
8.1 Installazione
Una volta installata la versione di SharePoint che ci serve, dopo aver anche installato
un SQL server e, creato il nostro database con le opportune tabelle necessarie alla
WebPart procediamo con l’installazione della stessa.
Per prima cosa estraiamo i file di installazione dal file zip.
Figura 6 Contenuto file zip d'installazione
Come vediamo all’interno ci sono 6 files che vanno estratti sul server dove si vuole
installare la WebPart.
Per evitare problemi di permessi è auspicabile estrarli in una cartella in C:/. (Es. C:/WP
Aprire una finestra DOS con privilegi di Amministratore (run as Admin).
Editare il deploy.bat e modificare il nome del sito (e la porta se vi sono più istanze di
SP) su cui fare il deploy.
Esempio. http://nomeserver:(porta)
Lanciare il deploy.bat. Attenzione a due particolarità:
1. Potrebbe verificarsi un problema (errore nell’esecuzione del batch). Per qualche
recondito motivo c’era nella folder del SP (C:Program FilesCommon
FilesMicrosoft SharedWeb Server Extensions14TEMPLATEFEATURES ) un
file di nome Feature
2. L’addsolution della WebPart sul sito basta farlo la prima volta (prima riga del file
bat - stsadm.exe -o addsolution -filename .GestioneDB.wsp). Una volta fatta e
se il file non cambia, per fare il deploy sugli altri siti, basta commentare la prima
riga del file bat (con REM).

28. 28
Verificare che sia tutto in ordine, entrando nel sito di amministrazione di SP sul server:
“System settings” e “Manage farm solutions”. Verificare che la WebPart sia in stato di
“deployed”. Si trova anche l’indicazione su quali siti essa è stata “deployed”.
Figura 7 Schermata di deploy delle soluzioni
E che sia presente nelle WebPart:

29. 29
Figura 8 Schermata di raccolta delle WebParts
A questo punto tutto è pronto per la configurazione della WebPart. Aprire una pagina
bianca ed Inserire la WebPart (comando New page Insert WebPart. Configurare la
WebPart lasciando i valori di default fatta eccezione per le CustomProperty dove
compare il percorso per il DB:

30. 30
Figura 9 Interfaccia per la connessione al DB
Rispettivamente abbiamo:
Data source: dove trovo il database nel formato “HOST/ISTANZASQL”
User: utente che può accedere al database (N.B. Se “Authentication System” è attivo,
non sarà necessario specificare user e password del database, ma verrà utilizzato lo
stesso di SharePoint, a patto che il database lo permetta).
Password: password dell’utente per accedere dal database.
Catalog: nome del database.
Naturalmente per funzionare bisogna seguire le istruzioni per la predisposizione del
Data Base che deve contenere le tabelle di sistema per la WebPart: TblAssociateTable,
TblFieldsForForeignKey e TblForeignKey.

31. 31
8.2 Disinstallazione della WebPart
Stessa cosa da fare con il file remove.bat nel caso si volesse rimuovere la soluzione.
Procedere al contrario rispetto all’installazione.
Rimuovere la WebPart dal (dai) siti di interesse, usando il browser del singolo sito come
le seguenti due azioni:
site settings – Site Collection Feature – deactivate
WebParts – edit – delete
Passare sul server e lanciare il file bat remove.bat. Si può anche rimuovere la WebPart
direttamente dall’interfaccia del browser di amministrazione del SP.8.3 Esempi di
installazione
Vediamo quindi alcune implementazione della WebPart su 3 database opportunamente
modificati.
8.3.1 AdventureWorks
Parametri di configurazione:
Figura 10 Configurazione connessione per database AdventureWorks
Visualizzazione:

32. 32
Figura 11 Schermata principale di AdventureWorks tabella indirizzo
Edit:
Figura 12 Schermata di modifica di un indirizzo

33. 33
8.3.2 Nanotech
Parametri di configurazione:
Figura 13 Configurazione connessione per il database Nanotech
Visualizzazione tabella:

34. 34
Figura 14 Schermata principale di Nanotech tabella dipartimenti
Edit:
Figura 15 Schermata di modifica di un dipartimento

35. 35
8.3.3 Gestione Ambiente e Territorio
Figura 16 Configurazione e schermata principale del database Gestione Ambiente e Territorio

36. 36
9.Conclusioni
Non sono state scritte un gran numero di righe di codice, in quanto le modifiche seppur
sostanziali non hanno incrementato il peso del programma e, grazie ad un lungo e
continuo debug si è riusciti a rendere la nostra applicazione funzionante sia su
SharePoint 2010 che SharePoint 2013.
La WebPart ovviamente su SharePoint adesso è compatibile con qualunque database a
condizione che sia installato MS SQL Server e che abbia delle caratteristiche
necessarie al funzionamento specificate all’interno di questo documento.
Durante lo sviluppo del progetto sono sorti alcuni problemi non solo dati
dall’applicazione ma anche dall’ambiente di test.
Infatti, all’inizio del progetto SharePoint 2013 era disponibile solamente nella versione
“Preview” che si è scoperto non essere esente da bugs: in un primo momento non era
possibile ottenere una versione funzionante, ma era necessario utilizzare svariati
“Workaround” non sempre stabili per ottenere un ambiente su cui fosse possibile
testare l’applicazione.
In secondo luogo prima dell’introduzione della versione del Framework 4.5.1 e di Visual
Studio 2013, effettuare un debug sufficientemente dettagliato su un applicativo installato
su SharePoint non era semplice oltre al fatto che solo con l’ultima versione del
Framework si poteva modificare il codice durante l’utilizzo invece che ricompilare e
rilanciare la modalità di debug.
Si può dire quindi che nonostante la potenza della macchina, l’utilizzo e il debug della
nostra applicazione non è stato sempre sufficientemente veloce da permettere uno
sviluppo fluido.
Nonostante ciò grazie a questa nuova feature supportata anche per l’applicazione 64bit
con Visual Studio 2013 si è potuto negli ultimi mesi velocizzare lo sviluppo, risolvendo
quindi in maniera rapida alcuni bug che hanno reso la WebPart compatibile con un
maggior numero di database.
Non mi possibile quantificare con esattezza il numero complessivo di ore che ci sono
volute per completare il progetto. Non è stato infatti uno sviluppo continuato, ma a varie
riprese. Si può comunque dire che il progetto è stato molto stimolante in quanto mi ha
permesso di apprendere un linguaggio di programmazione versatile come C#, molto
simile a Java che avevo studiato nel percorso di studio. In secondo luogo, ho potuto
approfondire le mie conoscenze in ambito SQL e toccare con mano le meccaniche che
legano un database ad un ambiente web.

37. 37
Posso comunque dire che dopo una quarantina di ore utilizzate per imparare ad
utilizzare l'ambiente di sviluppo, installare un doppio ambiente di test e apprendere i
fondamenti del linguaggio di programmazione, il tempo impiegato nel debug e nello
studiare una soluzione per aggiornare l'applicazione affidatami non può essere stimato
meno di 200 ore.
La WebPart quindi si può definire completa, anche se resta comunque possibile un
ulteriore sviluppo:
- Possibilità di avere la primary-key e foreign-key con qualsiasi nome senza
nessun vincolo.
- Supporto nella modifica e inserimento dei dati anche per gli altri “types” che
fornisce SQL.
- Nuova interfaccia grafica.

38. 38
Bibliografia
PFX
http://msdn.microsoft.com
Strong-Name signature
http://msdn.microsoft.com
Linguaggio C#
http://msdn.microsoft.com/it-it/library/67ef8sbd.aspx
Risorse online per gli sviluppatori di SQL Server
http://msdn.microsoft.com/it-it/sqlserver/aa336270.aspx