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

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

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

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

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

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

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

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

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

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

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

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

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

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

7 Struttura del progetto

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

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

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

{ } 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

{ 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

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

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

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

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

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

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

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 Files\Common

Files\Microsoft Shared\Web Server Extensions\14\TEMPLATE\FEATURES ) 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

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

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

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

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

Figura 11 Schermata principale di AdventureWorks tabella indirizzo

Edit:

Figura 12 Schermata di modifica di un indirizzo

33

8.3.2 Nanotech

Parametri di configurazione:

Figura 13 Configurazione connessione per il database Nanotech

Visualizzazione tabella:

34

Figura 14 Schermata principale di Nanotech tabella dipartimenti

Edit:

Figura 15 Schermata di modifica di un dipartimento

35

8.3.3 Gestione Ambiente e Territorio

Figura 16 Configurazione e schermata principale del database Gestione Ambiente e Territorio

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

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

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