Introduzione
Tante sono state le innovazioni di SQL Server 2005 rispetto alla versione precedente. Ma il database engine non è il solo ad essere stato migliorato. Gli strumenti ETL di Microsoft, fino ad oggi conosciuti come DTS (sin da SQL Server 7), sono stati interamente riscritti per consentire l’utilizzo di molte delle funzionalità fornite dal .Net Framework. Sono stati chiamati
SSIS, SQL Server Integration Services e sono decisamente più SMART e completi rispetto ai primi. Non solo, le prestazioni sono state notevolmente migliorate.
Ma diamo un’occhiata più da vicino..
SSIS è una piattaforma utile a sviluppare soluzioni rivolte all’integrazione di dati fra sistemi, ma è anche sinonimo di ETL. Un ETL (Extraction, Transformation and Loading) non è altro che un’applicazione finalizzata a caricare e trasformare dati da più piattaforme per elaborarli in base alle specifiche che l’analisi finale richiede. Oltre a rappresentare un potente strumento di questo tipo, SSIS ha ulteriori funzionalità, rivolte ad esempio alla manutenzione dei server, al richiamo di web services, al trasferimento di file FTP e via discorrendo. Insomma, un SSIS, o pacchetto, o package che dir si voglia, è un’applicazione che consente di gestire tutte queste operazioni(e non solo), in maniera grafica, intuitiva e veloce.
Cosa porta ad utilizzare SSIS ?
1) La necessità di unire dati provenienti da archivi eterogenei
Sicuramente, la prima applicazione di SSIS riguarda l’estrazione e la trasformazione dei dati provenienti da più archivi (con i più disparati sistemi di archiviazione) verso un singolo set di dati.
2) Pulitura e standardizzazione dei dati
Qualunque sia la natura dei dati in “arrivo”, SSIS deve mantenere per essi una congruenza sostanziale e formale ovvero l’integrità di ogni record che vi passa all’interno. Quindi deve fornirci strumenti per pulire e rendere standard i dati prima di ogni caricamento.
Possiamo associare espressioni ad una colonna (come un campo calcolato), convertirne il tipo, ricercarne relazioni su altre tabelle.
3) Integrazione con la Business Intelligence
Le analisi strategiche aziendali sono ormai all’ordine del giorno.
In alcuni casi può essere utile ripetere determinate logiche al variare di determinati valori. Oppure potrebbe emergere la necessità di eseguire particolari attività su dati in base al cambiamento di altri. SSIS espone un set di task che consentono le iterazioni e le attività da eseguire.
4) Automatizzazione funzioni di amministrazione
SSIS espone dei task molto comodi per l’automatizzazione delle operazioni sistemistiche di manutenzione, come ad esempio, strumenti di backup e ripristino di database, copia database, copia oggetti tra i SQL Server.
Per capire meglio, proviamo ad illustrare con un esempio come si scrive un SSIS e quali sono gli strumenti utili alla sua realizzazione.
La piattaforma – BIDS Come si sviluppa un SSIS ?
Business Intelligence Development Studio (BIDS) è una piattaforma di sviluppo fornita con l'installazione di SQL Server (alcune features però sono comprese solo a partire dalla Standard Edition). Si presenta esattamente come Visual Studio 2005 e permette anche di creare progetti su SQL Server Integration Services. L'interfaccia si presenta con le seguenti finestre di default (le più importanti):
A destra- Solution Explorer: è la rappresentazione della soluzione. Permette di gestire i file appartenenti al progetto ed alla soluzione Visual Studio.
- Properties: è la finestra delle proprietà, siano esse di progetto, di file o di oggetti del designer.
A sinistra- Toolbox: è l'insieme dei task/container da aggiungere nel package.
- Variables: è l'insieme delle variabili del package, con tanto di tipo dati e scope di ognuna di esse.
In basso- Output window: è la finestra dei messaggi restituiti dal SSIS a runtime.
- Errors: è l'elenco degli errori restituiti dal SSIS (errori di validazione, di connessione e/o quant'altro costituisca le caratteristiche di ognuno degli oggetti del package).
In linea di massima queste sono le window più utilizzate, anche se, soprattutto a runtime, saranno di grande utilità la
Watch e la
Locals.
Insomma, ci si muove come in un normale progetto di Visual Studio .NET
Le Variables, come abbiamo visto, sono a sinistra e quindi in un'area un po' ristretta. Siccome può essere utile visualizzare il loro valore, è meglio portare la finestra in basso, in modo da avere ampio spazio di manovra. Si perde il numero delle variabili visualizzabili, ma il loro valore è sempre facilmente visibile.
Il designer è stato suddiviso in più parti:
- Control flow ovvero lo stage su cui disegnare il flusso della logica del pacchetto
- Data Flow ovvero lo spazio riservato alla trasformazione di dati
- Event Handler ovvero il gestore degli eventi generati dai task
- Package Explorer ovvero un visualizzatore di oggetti presenti nel package.
- Connection Manager Area ovvero l’area su cui “appoggiare” l’elenco dei provider di sorgenti dati di vario tipo (OLEDB, Excel, ACCESS, File di texto, XML, …).
Control Flow ed Event Handler hanno lo stesso insieme di task nella toolbox. Data flow possiede un elenco di attività proprietario, non utilizzabile in altre aree del designer. Infatti quest’ultimo è suddiviso in tre grandi sezioni, le
Sorgenti, le
Trasformazioni e le
Destinazioni.
La filosofia di aggiunta di task è completamente incentrata sul Drag & Drop. Quindi, per aggiungere un task, basta trascinarlo dalla toolbox all’area di lavoro desiderata (Control Flow, Data Flow, Event Handler).
Di conseguenza un SSIS viene realizzato seguendo il seguente “scheletro”:
- Il flusso logico e fisico delle attività, espressa nel Control Flow
- Le sorgenti dati nell’area Connection Manager
- Le trasformazioni dei dati a partire da sorgenti per arrivare a destinazioni, nel Data Flow
- Eventuali eventi gestiti, nell’Event Handler
Il primo SSIS
Seguiamo ora una semplice procedura guidata per scrivere un SSIS dall’inzio.
Creazione del progettoAprire Business Intelligence Development Studio dal menu Start/Programmi/Microsoft SQL Server 2005.
Selezionare
Nuovo Progetto e indicare come tipologia
Progetto Integration Services. Chiamiamolo “AdventureWorksSSIS”.
Automaticamente, insieme al progetto, Visual Studio costruirà le strutture, compreso un nuovo SSIS (chiamato Package.dtsx) su cui lavorare. Per rinominarlo, spostarsi sul solution explorer e premere il destro del mouse sul suddetto file selezionando la voce “Rinomina”. Alla richiesta di conferma, premere OK.
Chiamiamo il SSIS
SalesOrderDetails.dtsx.
Scopo
Si vuole ottenere un package che controlli il numero delle vendite mensili per prodotto sul database di esempio di
Microsoft AdventureWorks, e che scriva in una tabella di output (che chiameremo Sales.ProductAlarms) un’indicatore. Se il prodotto è stato venduto 0 volte, l’indicatore sarà 0,
assente, se da 1 a 10, 1,
scarso, da 11 a 20, 2,
nella norma, da 21 a 50, 3,
medio, da 51 a 200, 4,
buono, da 201 in poi, 5,
ottimo. Si utilizzeranno le tabelle Sales.SalesOrderHeader (gli ordini di vendita), Sales.SalesOrderDetail (Le righe di ogni ordine) e Production.Product (i prodotti). Inoltre verrà prodotto un log su sql server tramite la creazione di una tabella dbo.LogProductAlarms.
La soluzione di questo semplice problema può essere affrontato tranquillamente con semplici statement SQL. Tuttavia lo utilizzeremo per fornire un primo esempio di Integration Services.
Il Connection Manager
Ogni qual volta dobbiamo connetterci ad un database o ad una sorgente dati, è necessario specificare un gestore della connessione, ovvero un oggetto che s’interfaccia alla sorgente per estrarre le informazioni.
Nel designer, in basso, vi è un tab che contiene i cosiddetti
connection managers. Possono essere di vario tipo, e qui di seguito ne abbiamo un breve elenco (solo i principali).
I connection manager possono essere sia
condivisi, e quindi creati nella solution all'interno dell'area
Data Sources (tasto destro sulla cartella Data Sources nella solution --> New Data Source..), che appartenenti solo al pacchetto, e quindi
locali, che non prendono valori da nessun connection manager condiviso.
La differenza tra i due sta nel fatto che i primi, a runtime, ereditano le configurazioni del DataSource dal quale derivano, mentre i secondi, essendo locali nel package, utilizzano le ultime impostazioni definite al loro interno.
Per ricavare una connessione da un data source condiviso (precedentemente creato) premere il tasto destro nell'area dei connection managers e selezionare il comando
"New Connection From data source..", selezionare la sorgente desiderata e il gioco è fatto.
Per avere una connessione non derivata da sorgenti condivise selezionare un comando diverso da quest'ultimo e configurare la connessione come meglio si crede.
Ecco come appaiono i diversi tipi di connection managers:
In un gestore di connessioni vi sono alcune proprietà da considerare per la connessione:
- DataSourceID, l’id del connection manager
- ConnectionString, la vera e propria stringa di connessione alla sorgente dati
- DelayValidation, se impostata a true, indica che i controlli di validazione sul connection manager non devono essere effettuati fino a che non viene eseguito il task.
- InitialCatalog, è il database su cui ci si deve connettere (opzionale)
- Name, è il nome del connection manager
- Password- ServerName- UserNameAggiungiamo una connessione OLEDB al database
AdventureWorks (samples di SQL server 2005) ed impostiamolo come segue:
Premendo Ok e vedremo nella linguetta
"Gestione Connessioni" il nostro nuovo
Connection Manager.
Le Variabili
Nel primo esempio di SSIS, non è così semplice capire quali variabili effettivamente ci servono, quindi mi limito ad elencarle, per avere più chiarezza su come saranno utilizzate. Alcune di loro hanno scope di oggetti che ancora non sono stati creati. Durante la spiegazione appariranno e sarà più chiaro capirne il significato.
La prima variabile è
oDate, di tipo object. Conterrà il resultset degli Anni/mesi da scandire.
Poi vi sono
Anno e
Mese, di tipo Int32, inizializzate a 0, che cambieranno all’interno di un contenitore ciclo for each. Sono il mapping delle colonne del resultset sopra indicato. In poche parole, una variabile conterrà il risultato di una query e per ogni riga, le altre due variabili saranno i campi.
Per ora aggiungiamo la variabile oDate, procedendo come di seguito:
Spostarsi sulla finestra delle Variabili..
..Premere il tasto “Nuova Variabile” e rinominare la var appena aggiunta, definendone il tipo “Object”.
Aggiunta dei task nel control flow
Aggiungiamo ora i seguenti Task, trascinandoli dalla Toolbox. Facciamo attenzione ad essere posizionati sul Control Flow (Flusso di controllo):
- Quattro Execute SQL Task- Un Foreach container- Un Data Flow taskPartiamo col configurare il primo task
Execute SQL. Esso avrà il ruolo di creare le strutture necessarie al pacchetto.
Ecco come configurarlo:
Oltre ad impostare l'SQL statement, cambiano anche le proprietà nome, descrizione e connection. L’ultima è stata valorizzata con il connection manager creato in precedenza (
.\SQL2005.AdventureWorks).
Siccome non ci sono né parametri né resultset di output, non ci sono ulteriori proprietà da impostare.
Chiamiamolo
Crea Strutture.
Le nuove strutture sono le seguenti:
IF NOT EXISTS (SELECT * FROM sys.objects WHERE object_id = OBJECT_ID(N'[dbo].[LogProductAlarms]') AND type in (N'U'))
CREATE TABLE [dbo].[LogProductAlarms](
[id_allarme] [int] IDENTITY(1,1) NOT NULL,
[posizione] [varchar](100) COLLATE Latin1_General_CI_AS NULL,
[datacaricamento] [datetime] NULL DEFAULT (getdate()),
PRIMARY KEY CLUSTERED (
[id_allarme] ASC
)WITH (PAD_INDEX = OFF, IGNORE_DUP_KEY = OFF) ON [PRIMARY]
) ON [PRIMARY]
IF NOT EXISTS (SELECT * FROM sys.objects WHERE object_id = OBJECT_ID(N'[Sales].[ProductAlarms]') AND type in (N'U'))
CREATE TABLE [Sales].[ProductAlarms](
[id_allarme] [int] IDENTITY(1,1) NOT NULL,
[IDProdotto] [int] NULL,
[NomeProdotto] [nvarchar](50) COLLATE Latin1_General_CI_AS NULL,
[mese] [int] NULL,
[anno] [int] NULL,
[stato] [tinyint] NULL,
CONSTRAINT [PK__ProductAlarms__7226EDCC] PRIMARY KEY CLUSTERED (
[id_allarme] ASC
)WITH (PAD_INDEX = OFF, IGNORE_DUP_KEY = OFF) ON [PRIMARY]
) ON [PRIMARY]
Passiamo poi al secondo ExecuteSQL, nominiamolo
Distinct Mesi e configuriamolo come segue:
La maggior parte delle proprietà sono simili al precedente ExecuteSQL. Questa volta, impostiamo la proprietà ResultSet a “Set dei risultati completo” (Full Resultset) in quanto il nostro oggetto di output verrà mappato alla varibile oDate. Il tutto nella sezione
“Set dei risultati”. Aggiungiamo un resultset , indichiamo con 0 il nome del resultset aggiunto in output e selezioniamo la variabile oDate dalla tendna delle variabili apposita.
Otterremo un recordset costituito da due colonne, la prima Anno e la seconda Mese, tutte due int.
Leghiamo il primo task con il secondo, in modo che la direzione sia da
Crea Strutture a
Distinct Mesi.
Trasciniamo sul control flow il
contenitore for each. Colleghiamo i due precedenti ExecuteSQL verso il container appena creato. Creiamo ora le due variabili Anno e Mese, Int32, con scope il ciclo for each (clickare su di esso prima di crearle, in modo da autoimpostare lo scope corretto)
Fare doppio click sul container appena configurato.
Nella sezione “Generals” impostiamo il nome (
“Cicla su date”) ed una descrizione esplicativa.
In “Insieme” (Collections) specifichiamo l’enumeratore e l’oggetto collezione, come segue:
L’enumeratore è ADO, poiché andiamo ad interfacciarci con un oggetto recordtset.
La variabile che utilizziamo come collezione è la oDate, di tipo object, definita all’inizio.
Spostandoci sulla sezione di Mapping aggiungiamo le due variabili Anno e Mese, mappando posizionalmente la colonna del resultset con la variabile, in questo modo:
Il ciclo foreach, scandirà l’oggetto
oDate, e valorizzerà in maniera posizionale le varibili Anno e Mese prendendo i dati dai campi della riga corrente della collezione.
Una volta definito il ciclo, aggiungiamo i due task per il log.
Inizio LOG e
Fine LOG. Sono gli ultimi due ExecuteSQL. Essi lanciano rispettivamente i seguenti statement SQL:
INSERT dbo.LogProductAlarms (posizione)
SELECT 'Inizio log per il mese *** anno ***'
INSERT dbo.LogProductAlarms (posizione)
SELECT 'Fine log per il mese *** anno ***'
Dove negli asterischi troveremo il valore corrente delle due variabili Anno e Mese. L’unico modo per ottenere un SQL dinamico basato su variabili è l’utilizzo delle
Expressions.
I due task, infatti sono configurati come il primo che abbiamo creato all’inizio dell’esempio, ma hanno nella sezione “Espressioni” una particolare configurazione:
Abbiamo utilizzato l’espressione indicata nella parte bassa dell’immagine per valorizzare la proprietà
SqlStatementSource del task. In più abbiamo utilizzato delle funzioni di cast, poiché le nostre variabili sono intere e la proprietà da valorizzare è String. In questo modo, a runtime, i valori correnti delle variabili Anno e Mese consentiranno la creazione di uno statement SQL corretto per l’inserimento nella tabella LogProductAlarms. Nella foto vi è solo Inizio LOG, la stringa cambia per l’altro task, ma le impostazioni sono le stesse.
Inizio LOG e
Fine LOG, devono essere trascinati all’interno del ciclo, se già non lo sono. Slegati fra loro. Semplicemente abbiamo creato due espressioni che vanno a valorizzare una ben precisa proprietà del task, in modo da utilizzare, all’interno del ciclo, il valore corrente di due variabili (Anno e Mese).
Infine aggiungiamo il task DataFlow e lo rinominiamo in
Conta Vendite mese-prodotto. Ricordiamo che per rinominarlo è sufficiente clickare due volte lentamente il sinistro del mouse sull’oggetto, oppure premere F2, come per un file. A questo punto Inizio LOG dovrà essere legato al dataflow che a sua volta avrà una freccia verso Fine LOG.
E qui termina la parte del flusso di lavoro, del control flow. Ed Ecco come appare il nostro SSIS:
Configurazione del DataFlow “Conta Vendte Mese-prodotto”
Ora dobbiamo definire quali sono le trasformazioni per il pacchetto, in modo da ottenere in output ciò che ci serve. Vogliamo controllare il numero delle vendite per mese e quindi, in base a questo, scrivere lo stato su di una tabella, per mese e prodotto. Ma andiamo per punti. Doppio click sul dataflow e..
1) Configurare le sorgentiTrasciniamo la sorgente dati OLEDB sullo stage del dataflow. Rinominamolo in
Mese Corrente. Ecco come appare una sorgente come questa:
In essa dobbiamo indicare il connection manager di riferimento (il nostro “.\SQL2005.AdventureWorks”), il tipo di sorgente (Table, Table from Variable, SQL Command, SQL Command from Varabile) e l’eventuale Comando, variabile, Tabella da cui partire.
In questo caso abbiamo selezionato Comando SQL ed abbiamo indicato la seguente query:
SELECT YEAR(a.OrderDate) AS Anno, MONTH(a.OrderDate) AS Mese, b.ProductID,
CASE
WHEN COUNT(*) = 0 THEN 0
WHEN COUNT(*) > 0 AND COUNT(*) <= 10 THEN 1
WHEN COUNT(*) > 10 AND COUNT(*) <= 20 THEN 2
WHEN COUNT(*) > 20 AND COUNT(*) <= 50 THEN 3
WHEN COUNT(*) > 50 AND COUNT(*) <= 200 THEN 4
WHEN COUNT(*) > 200 THEN 5
END as Vendite
FROM Sales.SalesOrderHeader a
JOIN Sales.SalesOrderDetail b
ON a.SalesOrderID = b.SalesOrderID
WHERE YEAR(a.OrderDate) = ? AND MONTH(a.OrderDate) = ?
GROUP BY YEAR(a.OrderDate), MONTH(a.OrderDate),b.ProductID
ORDER BY Anno,Mese
Da notare i punti di domanda ?, che sono i parametri, da indicare premendo il pulsante apposito:
Si assegnano posizionalmente, il che significa che Anno è il primo ? e Mese è il secondo.
Per ogni Anno/Mese, questo comando tornerà una porzione di dati utile a contare le vendite per quel determinato periodo.
2) Configurare le trasformazioniCon esse si vuole ottenere:
- Il nome del prodotto dalla tabella Producition.Product in base all’ID del prodotto
- L’aggiunta dei nuovi record e l’aggiornamento dei già esistenti in Sales.ProductAlarms
Per tutti e due i punti utilizzeremo i task di
Ricerca (Lookup), che consentono equijoin su una tabella di destinazione per controllare l’esistenza di un record o per ricavare un determinato attributo.
Come prima cosa, nei dataflow, dobbiamo precedere il collegamento dei task alla configurazione. Poiché ogni freccia autoconfigura, sulla base di metadati, il task che va a puntare. Di conseguenza senza di essi, il task di trasformazione non sa da che parte iniziare. Quindi uniamo la sorgente alla Lookup (che chiamiamo
Descrizione Prodotto) ancora prima di impostarla. Proseguiamo come da immagine.
Nella sezione “Tabella di riferimento” impostiamo la query/tabella su cui andremo ad effettuare la ricerca. La struttura del resultset che ci arriva dalla colonna derivata è visibile nella sezione “Colonne”, come tabella di sinistra. Viceversa, quella di destra, è la query che andiamo a definire per la lookup. In questo caso, per ID del prodotto andiamo a ricavare il nome da una vista sulla tabella Production.Product. Tutti i campi selezionati col check sulla tabella di destinazione sono aggiunti al resultset come nuove colonne. Quindi, nel nostro esempio, avremo in uscita la colonna aggiuntiva chiamata ProductName. Tutti i campi collegati con il connettore sono i criteri di join. Nel nostro caso, ProductID.
Dopo di esso, ne configuriamo un altro, stavolta in maniera leggermente diversa. Mentre la prima ricerca era mirata a ricavare un campo attributo ben preciso, questo serve per controllare l’esistenza di record in base alla chiave della tabella di destinazione ed a discriminare se si tratta di inserimento di nuovi record o di aggiornamenti di esistenti. Chiameremo il task
Controllo Esistenti.
Colleghiamo il primo lookup con questo.
Da notare che non abbiamo selezionato nessuna colonna. Dove sta la differenza? Come ogni transformation task, anche la ricerca ha la possibilità di gestire l’errore. Un lookup dà esito positivo (freccia verde) se i dati sono stati trovati (quindi caso aggiornamento), mentre torna errore (freccia rossa) se i dati non sono stati trovati in tabella di destinazione (quella a destra, caso inserimento). Premere sul tasto
“Configura Output Errori..”, in basso sull’editor della ricerca.
Selezionare
Reindirizza riga come gestione dell’errore.
Ora, per concludere, sarà sufficiente utilizzare la freccia verde per terminare nella destinazione (insert), e la freccia rossa per eseguire l’update di aggiornamento.
3) Configurare le destinazioniTrasciniamo la destinazione desiderata (nel nostro esempio, OLEDB) tiriamo la freccia verde da
Controllo Esistenti ad essa e configuriamola come sotto:
Selezioniamo il connection manager, come per la sorgente, la modalità di accesso ai dati (Tabella o vista – caricamento rapido), la tabella di destinazione e l’eventuale valore di righe per ogni batch, indicato per velocizzare le operazioni in caso di tabelle molto grandi. Se non indicato, si sottintende batch unico per tutte le righe elaborate. Poi, nella sezione Mapping andiamo a definire “cosa mettere dentro cosa”. Insomma la copia delle colonne dal resultset ottenuto fino ad ora, alla destinazione. Trattandosi di sole insert, chiamiamo il task
Inserimento Nuovi.
Per quanto riguarda gli aggiornamenti, in realtà, non si usa una destinazione, ma un comando, e quindi un task di trasformazione. Trasciniamo quindi un OledbCommand e colleghiamolo alla freccia rossa del
Controllo Esistenti. Chiamiamolo
Aggiorna Esistenti:
Selezioniamo il connection manager. Il comando da lanciare è:
UPDATE Sales.ProductAlarms
SET Stato = ?
WHERE Anno = ? AND Mese = ? AND IDProdotto = ?
Ed infine, ricordandoci che i ? corrispondono posizionalmente al parametro passato, eseguiamo il mapping rispettivamente di Vendite (=Stato), Anno, Mese e ProductID (=IDProdotto).
Fine della scrittura del pacchetto.
Ecco come apparirà il dataflow:
Esecuzione e debug del SSIS
Nel solution Explorer clickare il tasto destro del mouse e selezionare “Esegui pacchetto” (Execute Package).
La prima esecuzione sarà diversa dalle altre, poiché la tabella di destinazione Sales.ProductAlarms è vuota. Quindi avremo solo inserimenti (constraint errore sul
Controlla Esistenti). In una seconda esecuzione, solo aggiornamenti (poiché ripetiamo la stessa operazione).
A parte il fatto che sono state eseguite solo modifiche (come denota il numero di righe sopra ad
Aggiorna Esistenti) notiamo anche un rallentamento delle operazioni. Questo perché mentre la destinazione esegue inserimenti batch e veloci, l’oledbcommand esegue lo statement indicato RIGA per RIGA. Quindi fate attenzione, perché con grandi moli di dati potrebbe essere un bel problema utilizzarlo in questo modo.
Da notare la comodità di vedere il numero delle righe nella pipeline di esecuzione del flusso di dati. Alla fine vedremo solo l’ultimo ciclo eseguito, ma seguendo in debug il SSIS, noteremo che i valori cambiano per ogni mensilità.
Conclusioni
Abbiamo visto quante sono le potenzialità di questo nuovo prodotto. Tantissimi task, tante origini dati, il tutto corredato da una veste grafica di buona fattura e da strumenti di debug notevoli. Teoricamente è possibile eseguire tutto ciò che si vuole tramite SSIS. Attenzione però, non sempre l’abito fa il monaco. Ricordiamoci che si tratta di un nuovo prodotto, ed, in quanto tale, facciamo attenzione ai limiti e agli eventuali bug che si potrebbero presentare. Inoltre non abusiamo di tutti i task sempre e comunque, si possono ottenere ottime prestazioni anche tramite script, o, addirittura, aggiungendo task scritti da noi.