Real World SQL Azure: il case study di Microsoft Corporate su Web Signage

Dopo una lunga intervista telefonica ed una rapida revisione che ha coinvolto il team di prodotto SQL Azure, lo scorso 22 novembre è stato pubblicato da Microsoft il case study sull’esperienza di Edisonweb con Windows Azure e SQL Azure.

Partendo dall’erogazione del servizio Web Signage, in questo documento vengono evidenziati i vantaggi tecnologici, strategici ed economici derivanti dall’adozione delle tecnologie di cloud computing. In particolar modo si evidenziano due aspetti che potrebbero essere di sicuro interesse per chi vuole avvicinarsi al cloud: i vantaggi economici derivanti dalla smaterializzazione dell’infrastruttura IT e dal modello pay-per-use e i vantaggi strategici che facilitano l’espansione sui mercati internazionali.

Il passaggio da una struttura on premises ad una cloud based permette di abbattere radicalmente i costi di gestione e di mantenimento dell’infrastruttura necessaria all’erogazione dei servizi. In particolare, oltre ai costi relativi all’acquisto di hardware e di licenze, vengono rimossi tutti quegli oneri ricorrenti legati all’utilizzo dei datacenter (power, cooling, supervisione sistemistica, affitto rack space ecc..) a tutto vantaggio della competitività sul mercato.

Per l’erogazione efficiente di servizi su scala mondiale, è necessaria l’identificazione di datacenter in diversi Stati e la creazione di accordi con le Telco locali. Il risultato è una infrastruttura distribuita, difficile da gestire e poco unitaria. Windows Azure permette di definire l’affinità dei servizi ad una regione geografica e, attraverso la Content Delivery Network, consente la distribuzione di contenuti su scala mondiale in modo semplice e performante. In un periodo in cui l’espansione sui mercati internazionali è sempre più importante (se non vitale), il supporto tecnologico fornito dai servizi Microsoft è una autentica manna dal cielo.

Sul sito Microsoft Case Studies è possibile leggere l’abstract o scaricare l’intero documento del case study in formato Word, mentre sul blog MSDN SQL Azure Team Blog è disponibile un estratto dell’intervista.

Buona lettura!

Annunci
Pubblicato in Cloud computing | Contrassegnato , , , , , , , , , | Lascia un commento

Windows Azure: Web Signage tra i case study italiani allo SMAU 2010

Durante lo SMAU 2010, Microsoft ha organizzato la sua presenza in grande stile organizzando degli eventi tematici trasmessi in streaming su Internet. Lo studio televisivo, realizzato con pareti trasparenti e con monitor esterni, permette ai visitatori della fiera di assistere alle discussioni durante le riprese. Tra i quattro eventi previsti, nella mattina di venerdì 22 ottobre, si è tenuto quello su Windows Azure presentato da Riccardo Sponza e Mario Fontana. L’agenda dell’evento ha previsto una serie di interessanti interventi di che hanno spaziato da argomenti tecnici e hands-on-labs a considerazioni commerciali e strategiche sulle opportunità di business derivanti dall’adozione di una piattaforma cloud.

I benefici e le opportunità che scaturiscono dall’adozione di Windows Azure sono stati testimoniati dalla presentazione di quattro case study tutti italiani: Web Signage di Edisonweb, CV Manager di SoftJam, aKite di Bedin Shop Systems e Amanuens di Threeplicate. Le applicazioni presentate sono state create per segmenti di mercato molto differenti, sono state migrate sul cloud o progettate sin dall’inizio per essere utilizzate su Windows Azure e utilizzano le tecnologie disponibili in modo differente. Nel loro insieme rappresentano quattro prospettive tanto diverse quanto interessanti sui vantaggi e le opportunità nate dall’uso dei cloud services di Microsoft.

Come CTO di Edisonweb sono stato invitato a condividere la nostra esperienza con Windows Azure e SQL Azure nell’erogazione del servizio Web Signage per la gestione di reti di digital signage e della comunicazione di prossimità in generale. Il mercato del digital signage è abbastanza giovane, soprattutto in Italia, le reti sono tipicamente in espansione, continua e veloce, e puntano a coprire le aree con maggiore frequentazione. Tra queste anche le località turistiche montane e balneari, con attività stagionale. Web Signage è offerto come servizio ed il modello di pricing prevede un canone mensile per ogni computer che esegue i contenuti (player). Il numero di player attivi può essere variato liberamente nel corso dell’anno e le spese relative ai canoni possono seguire l’andamento del business. Per erogare in modo ottimale i propri servizi, a fronte di un investimento iniziale significativo, Edisonweb si è dotata di una infrastruttura tecnologica in datacenter. Inoltre, l’infrastruttura richiede una supervisione e manutenzione continua, generando costi ricorrenti e utilizzando risorse umane altrimenti disponibili per il core business: lo sviluppo di software.

L’adozione di Windows Azure ha comportato molteplici vantaggi:

  • I costi infrastrutturali, privi di una componente iniziale di investimento, sono commisurati all’utilizzo effettivo e, di conseguenza, seguono in modo preciso le fluttuazioni generate dal modello flessibile di licensing.
  • I costi di Windows Azure e di SQL Azure sono molto più bassi rispetto a quelli ricorrenti dell’infrastruttura on premises.
  • L’erogazione del servizio sui mercati internazionali non richiede accordi con le TELCO locali o l’identificazione di datacenter adeguati. Utilizzando l’affinità dei servizi ed i nodi della Content Delivery Network è possibile distribuire il servizio in modo ottimale, indipendentemente dalla distribuzione geografica dei player.

Riassumendo, l’adozione dei servizi della piattaforma Windows Azure permette una più facile aggressione dei mercati internazionali, una maggiore competitività e una migliore produttività.

Per chi fosse interessato a riascoltare il mio intervento, è disponibile la registrazione su You Tube:

Chi parteciperà al TechDaysWPC 2010 potrà avere il modo di approfondire l’argomento con me di persona: sono stato invitato da Mario Fontana a presentare in modo un po più articolato Web Signage durante lo speech “Architecting Windows Azure Solutions:Italian Scenarios”, martedì 23 Novembre, sala Blu.

Pubblicato in Cloud computing | Contrassegnato , , , , | 2 commenti

Scrum: tempi e costi

Adottando la metodologia di sviluppo SCRUM gli obiettivi di progetto vengono raccolti nel Product Backlog, continuamente aggiornato e alimentato da tutti gli stakeholder. L’obiettivo generale del progetto è definito ma i dettagli possono cambiare al mutare delle condizioni di mercato e delle strategie del cliente per ottenere il massimo del valore.
Si pongono quindi due problemi:

  • come definire e rispettare una data di rilascio condivisa con il cliente?
  • come definire una strategia di controllo dei costi a fronte della variabilità delle specifiche?

Un primo passo è quello di definire un piano iniziale con una data di rilascio condivisa. Questo piano verrà aggiornato con il susseguirsi degli Sprint, ma permette di definire una scadenza sulla base dei requisiti iniziali. Questi vengono raccolti e, se necessario, discussi con il cliente al fine di comprendere al meglio i benefici di business correlati alle richieste ricevute.

I requisiti (User Story) vengono inseriti, ordinati per priorità, nel Product Backlog e sottoposti ad un processo di stima. La stima non viene effettuata sulla base di una valutazione del tempo e delle modalità di implementazione, ma per confronti successivi rispetto ad un requisito di riferimento. In questa fase, infatti, non è stata ancora effettuata un’analisi.
Tra le User story nel Product Backlog ne viene selezionata una minore, ma non la più piccola, e viene attribuito un valore Story Point di tre. Questo valore è un numero puro, senza nessun riferimento al numero di ore di lavoro necessarie. Fissato questo punto di riferimento, il team attribuisce il valore degli Story Point alle altre attività. In questo modo un’attività con una complessità doppia rispetto a quella di riferimento avrà un valore pari a 6 o una, davvero molto complessa, un valore pari a 100.
La valutazione del numero di Story Point non sempre è immediata e pertanto esistono varie metodologie per agevolare la stima. Una tra queste è il cosiddetto Planning Poker.

Completata la stima degli Story Points è necessario valutare la “capacità produttiva” del team di sviluppo. E’ necessario misurare la cosiddetta Velocity, ovvero il numero di Story point che il team può completare in un singolo Sprint. E’ chiaro che, conoscendo questo valore, è possibile conoscere il tempo necessario per realizzare tutte le User Story nel Product Backlog: Tempo di completamento = Totale Story Point/Velocity * Durata Sprint. Non si tratta di una stima ma di una misura.
Studi dimostrano che per avere una misura del valore di Velocity di un team è tipicamente necessaria l’esecuzione di tre Sprint. Il valore di Velocity è costante se vengono mantenute invariate le tecnologie, l’ambiente di lavoro e la composizione del team. E’ quindi possibile che si disponga già di questo valore. In caso contrario, per un progetto di sufficienti dimensioni, potrebbe essere addirittura conveniente realizzare tre Sprint da una settimana per avere una misura di questo valore.

A questo punto abbiamo una indicazione del tempo di realizzazione, condivisibile con il cliente. Ma i cambiamenti in corsa avranno un impatto sul tempo di completamento del progetto? Le variazioni ai requisiti iniziali come incideranno sui costi? A queste domande risponde il contratto sottoscritto con il cliente. Esistono, infatti delle tipologie di contratto che permettono una gestione chiara dei costi, anche in contesti caratterizzati da variabilità come quelli in cui vengono applicate metodologie agili di sviluppo. A titolo di esempio ne citerò alcuni:

Per tempo e materiali
E’ un classico. Il cliente paga per il tempo di sviluppo richiesto e, di conseguenza si assume anche il rischio di eventuali scelte errate che aumentano la durata del lavoro. L’ambito del progetto non è definito a priori e il progetto viene chiuso appena il cliente raggiunge i suoi obiettivi o decide di non voler spendere di più.

Per tempo e materiali con tetto di spesa
E’ simile al precedente, ma un tetto di spesa limita il rischio finanziario per il cliente. Ovviamente, essendoci un limite di budget, è fondamentale che ci sia una collaborazione tra fornitore e cliente affinché quest’ultimo ottenga il massimo del valore per il suo business rispettando il limite di budget.

Profitto fisso
Permette di condividere il rischio: se il progetto viene chiuso in anticipo il cliente paga di meno ed il fornitore ottiene il profitto per quel periodo, se il progetto supera la data di consegna prevista o se viene superato il budget massimo concordato, il fornitore lavora a prezzo di costo.

“Money for Nothing, Changes for Free”
Il modello di base è per tempo e materiali, con una data di rilascio prevista. Durante il processo di sviluppo, vengono realizzate le funzionalità in ordine di valore per il cliente. Ad un certo punto quest’ultimo può valutare sufficiente il valore ottenuto e decidere di non proseguire con lo sviluppo. In questo caso il cliente deve versare una fee di cancellazione pari al profitto mancante per il fornitore (money for nothing). Le funzionalità non implementate possono essere sostituite con altre con un numero di story point uguale (changes for free). Le funzionalità aggiuntive comportano costi aggiuntivi.

Pubblicato in Project management | Contrassegnato , , , , , | 2 commenti

Sviluppo agile con Scrum

Che caos!
Rileggendo il mio post precedente sul confronto tra l’approccio a cascata e le metodologie di sviluppo agile, mi è sembrato che possa dare una percezione caotica di queste ultime. In realtà, e lo dico per esperienza personale, ci vuole un po’ per comprendere e abbracciare una filosofia che vede il cambiamento non solo come positivo, ma addirittura come fulcro per la creazione di valore. Dopotutto, storicamente, i cambiamenti alle specifiche di un progetto, se possibile, sono stati sempre evitati. Non è vero?

Gestire il cambiamento
E’ possibile imbrigliare il cambiamento in una serie di processi concettualmente semplici e, utilizzando un approccio ciclico, produrre valore ed informazioni utili al continuo miglioramento dei processi stessi. La parola magica per ottenere tutto questo è Scrum, un modello iterativo ed incrementale per lo sviluppo di progetti, prodotti o applicazioni.
Le richieste provenienti dai clienti, dagli utilizzatori, dal team di sviluppo e, in generale, da tutti gli stakeholder, vengono raccolte e viene redatta una lista ordinata per priorità di caratteristiche per il prodotto (Product Backlog).

La produzione è strutturata in cicli di sviluppo chiamati Sprint di durata costante (tipicamente tra una e quattro settimane) che si susseguono senza soluzione di continuità. Il prodotto dello Sprint è una porzione completa del prodotto finale, una porzione potenzialmente rilasciabile.
All’inizio di ogni Sprint (attraverso lo Sprint Planning Meeting) il team seleziona i task dal Product Backlog e si impegna a completarli all’interno del tempo concesso. Non è possibile allungare lo Sprint per permettere il completamento di un task e a Sprint avviato i task non possono essere più modificati. Se i task dovessero essere completati in anticipo (mostrando un errore di pianificazione), se ne possono selezionare degli altri per occupare il tempo altrimenti inutilizzato.
Durante lo Sprint, ogni mattina il team si incontra (Daily Scrum Meeting) per verificare come procedono i lavori e se ci sono impedimenti. Si tratta di un incontro informale, in piedi, magari accanto alla macchina del caffè, della durata massima di 15 minuti.

Al completamento dello Sprint c’è un incontro (Sprint Review) che coinvolge tutte le figure interessate allo sviluppo del progetto (può partecipare anche il cliente) e mette in atto l’idea chiave in Scrum: “inspect and adapt“. Viene mostrato il lavoro eseguito, che viene approvato secondo criteri condivisi, e discussa l’esecuzione dello Sprint. Tutti sono liberi di porre domande e dare dei suggerimenti innescando un colloquio che permette di trarre benefici dall’esperienza appena conclusa.
Successivamente alla Sprint Review viene avviata la Sprint Retrospective che estende l’applicazione della filosofia di ispezione e adattamento dal prodotto all’intero processo e coinvolge un gruppo più ristretto di persone. E’ una riunione di importanza strategica, che permette di capire cosa sta andando come previsto o cosa necessita di adattamento, nell’intero processo di produzione governato dalla metodologia Scrum. Con quest’ultima riunione lo Sprint è definitivamente concluso e il ciclo si ripete fino al completamento del prodotto.

I ruoli previsti
Scrum prevede tre ruoli:

Il Product Owner
Il Product Owner è responsabile della massimizzazione del ROI del progetto attraverso la gestione del Product Backlog, la lista di feature per il prodotto ordinata secondo una priorità dettata dal valore. Il concetto di valore è preso in senso lato, può essere dettato dalla necessità di soddisfare un cliente importante, realizzare degli obiettivi strategici o mettere in atto dei miglioramenti.
Le metodologie agili incentivano lo scambio diretto di informazioni, riducendo il numero di intermediari. E’ provato, infatti, che al crescere del numero di “handoff” il livello di qualità delle informazioni scambiate si abbassa. Questa è una delle motivazioni per cui i ruoli sono così pochi. Si ha così che, nel caso di un prodotto commerciale, il ruolo del Product Owner assomiglia a quello del classico Product Marketing Manager, con la differenza che esso interagisce direttamente con il Team, proponendo gli obiettivi. Il Team avrà così una percezione precisa, “di prima mano” dei risultati da perseguire. Il Product Owner, infine, ha la possibilità di accettare o rifiutare il risultato del lavoro del Team, sulla base di una “Definition of done” condivisa da tutti.

Il Team
Il Team, formato da 5-7 persone, è multi-funzionale (nel senso che contiene in se tutte le competenze necessarie per completare il lavoro) e in grado di autogestirsi. Sceglie i task da completare in uno Sprint insieme al Product Owner e decide in autonomia come procedere per rispettare l’impegno in modo puntuale e preciso. Il Team, oltre a occuparsi dello sviluppo, fornisce dei suggerimenti al Product Owner su come rendere il prodotto migliore alimentando il Product Backlog.

Lo ScrumMaster
Lo ScrumMaster aiuta il gruppo ad applicare Scrum, realizzare valore e garantire il successo. Scrum è in grado di evidenziare i pericoli e gli impedimenti e lo ScrumMaster si prodiga alla risoluzione delle problematiche che possono interferire con la capacità lavorativa e la produttività del team. Incentiva la cooperazione tra tutti i ruoli e le funzioni coinvolte, rimuovendo impedimenti e proteggendo il team da interferenze esterne. Si assicura, infine, che il processo sia seguito secondo la metodologia, invitando ai meeting.

Perchè mi piace Scrum?
Lascia il Team libero di poter esprimere le sue potenzialità
Lasciare il team libero di gestire il progetto, di prendere iniziative, di proporre soluzioni, anche al di fuori del contesto puramente tecnico, è un modo per lasciare esprimere al meglio le potenzialità dei talenti. Lo sperimento ogni giorno. Scrum permette tutto questo, ponendo allo stesso tempo degli obiettivi precisi, che coincidono con tutte le richieste che producono valore, e richiedendo dei risultati verificabili che migliorano la qualità del prodotto.

E’ efficace
Avere un breve percorso lineare che parte dalle specifiche e arriva a dei prodotti parziali potenzialmente rilasciabili permette di garantire una costante progressione, che si parli di un prodotto commerciale o di una soluzione ad-hoc. Il modello dello Sprint obbliga a creare la qualità nel corso della produzione del prodotto, imponendo test continui.

E’ mosso dalla logica “inspect and adapt”
Scrum permette di evidenziare e risolvere problemi e migliorare, non solo il prodotto, ma anche l’intero processo di produzione. Il risultato è che dopo una fase iniziale di resistenza e una di “caos”, in cui i processi usuali si riorganizzano per adattarsi alla metodologia, si ha un incremento continuo della produttività e della qualità.

Incentiva i feedback
Tutti sono coinvolti. Sono previste occasioni di incontro e di discussione che incentivano i feedback da parte di tutti gli stakeholder, permettendo di contribuire alla realizzazione di un prodotto migliore e al successo dell’organizzazione.

Scrum sta diventando un po la “buzz word” nell’ambito della gestione dei progetti software e sta riscuotendo molto successo. E’ un approccio agile efficace e ridotto all’essenziale e, quindi, è il più semplice da implementare. Se questo post ha suscitato la vostra curiosità, vi invito a fare il passo successivo, approfondendo la conoscenza di questa metodologia. Sono certo che resterete affascinati come me dalla semplicità concettuale e dalle potenzialità.

Pubblicato in Project management | Contrassegnato , , , , , , , , | Lascia un commento

Database Mail on SQL Azure

As requested by some people, here is the English version of my previous post on Database Mail in Italian.

Among the SQL Server 2008 features not available in SQL Azure, as shown in the MSDN, there is the absence of all those related to SQL Agent.
Database Mail, which lets you send emails from the database engine using some stored procedures in msdb, is one of these.
Creating a mechanism to queue e-mail messages in a SQL Azure database and send them through a worker role is easy, but I would like to go further, making the existing code using Database Mail compatibile with SQL Azure.
In this post we will see how we can change the system stored procedures to make them run on SQL Azure. We will consider only the most common stored procedures. All others, if necessary, may be ported in the same way.

Obtaining the original SQL Server 2008 scripts
Obtain the original code of the stored procedure is quite simple. Just open the msdb database with SSMS, left click on the object you want to change and choose Modify on the context menu. For almost all items it was possible to obtain the code to be modified this way, except for the dbo.get_principal_id and dbo.get_principal_sid functions and the xp_sysmail_format_query extended procedure. The first two have been easily rewritten, while for the extended procedure xp_sysmail_format_query, given the purpose of the post, it was decided to not to proceed. This procedure is used to append to the body or attach a file with the result of a query. If you really need it, you will need to write the code that formats the output of a query as a string representing the output table.

Managing profiles
Messages are sent using profiles, which contain all the account information and the SMTP server address. They also allow for a redundancy mechanism that ensures that your message is sent, no matter if a SMTP is down or your account has expired. Typical operations for the creation of profiles are:

— Creating a Database Mail account
EXECUTE msdb.dbo.sysmail_add_account_sp
@account_name = ‘AdventureWorks2008R2 Public Account’,
@description = ‘Mail account for use by all database users.’,
@email_address = ‘db_users@Adventure-Works.com’,
@replyto_address = ‘danw@Adventure-Works.com’,
@display_name = ‘AdventureWorks2008R2 Automated Mailer’,
@mailserver_name = ‘smtp.Adventure-Works.com’ ;

— Creating a Database Mail profile
EXECUTE msdb.dbo.sysmail_add_profile_sp
@profile_name = ‘AdventureWorks2008R2 Public Profile’,
@description = ‘Profile used for administrative mail.’ ;

— Adding an account to profile
EXECUTE msdb.dbo.sysmail_add_profileaccount_sp
@profile_name = ‘AdventureWorks2008R2 Public Profile’,
@account_name = ‘AdventureWorks2008R2 Public Account’,
@sequence_number =1 ;

— Granting profile access to users
EXECUTE msdb.dbo.sysmail_add_principalprofile_sp
@profile_name = ‘AdventureWorks2008R2 Public Profile’,
@principal_name = ‘public’,
@is_default = 1 ;

Stored procedures involved, along with their dependencies are:

  • sysmail_verify_accountparams_sp
  • sysmail_verify_profile_sp
  • sysmail_verify_account_sp
  • sysmail_verify_principal_sp
  • sysmail_add_profile_sp
  • sysmail_add_profileaccount_sp
  • sysmail_add_principalprofile_sp
  • sysmail_add_account_sp
  • sysmail_create_user_credential_sp

These stored procedures can be created in SQL Azure starting from SQL Server 2008 scripts. In general, for stored procedures not involved in the creation of credentials (sysmail_create_user_credential_sp and sysmail_add_account_sp) requires no changes other than the removal of any explicit reference to the msdb database.
The sysmail_add_account_sp stored procedure stores the username and password as a credential. This mechanism, since is not possible to retrieve the credential secret, it should be changed to allow a worker role to get the password for SMTP authentication.
An easy way is to create a new table for storing the SMTP username and password and change the sysmail_create_user_credential_sp stored procedure in order to use that table instead of server credentials.
The password field needs to be adequately protected, but because of SQL Azure current limitations we can not use the EncryptBy * statements. For sake of simplicity we will store passwords in clear text (The password field has the name “ciphertext” so we don’t forget to protect it).

CREATE TABLE sysmail_account_credential(
credential_id int IDENTITY(1,1) NOT NULL,
username nvarchar(256) NULL,
cyphertext nvarchar(256) NULL,
CONSTRAINT [SYSMAIL_ACCOUNT_CREDENTIALIDMustBeUnique] PRIMARY KEY CLUSTERED
(
credential_id ASC
)
WITH (STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF))

CREATE PROCEDURE [dbo].[sysmail_create_user_credential_sp]
@username nvarchar(128),
@password nvarchar(128),
@credential_id int OUTPUT
AS
— Le porzioni commentate fanno riferimento al codice originale

SET NOCOUNT ON
–DECLARE @rc int
–DECLARE @credential_name UNIQUEIDENTIFIER
DECLARE @credential_name_as_str varchar(40)
–DECLARE @sql NVARCHAR(max)

—- create a GUID as the name for the credential
–SET @credential_name = newid()
SET @credential_name_as_str = convert(varchar(40), @username) –@credential_name)
–SET @sql = N’CREATE CREDENTIAL [‘ + @credential_name_as_str
— + N’] WITH IDENTITY = ‘ + QUOTENAME(@username, ””)
— + N’, SECRET = ‘ + QUOTENAME(ISNULL(@password, N”), ””)

–EXEC @rc = sp_executesql @statement = @sql
–IF(@rc 0)
— RETURN @rc

INSERT INTO dbo.sysmail_account_credential (username,cyphertext) VALUES (@username, @password)

–SELECT @credential_id = credential_id
–FROM sys.credentials
–WHERE name = convert(sysname, @credential_name)

SELECT @credential_id = credential_id FROM dbo.sysmail_account_credential WHERE credential_id = @@IDENTITY

IF(@credential_id IS NULL)
BEGIN
RAISERROR(14616, -1, -1, @credential_name_as_str)
RETURN 1
END

RETURN(0)
GO

The following tables are used by the stored procedures:

  • sysmail_account
  • sysmail_server
  • sysmail_servertype
  • sysmail_profile
  • sysmail_profileaccount
  • sysmail_principalprofile

Again the tables can be created using the scripts generated by SSMS connected to SQL Server 2008. To fix some incompatibilities with SQL Azure we need to remove all references to filegroups and the ALLOW_PAGE_LOCKS = ON, ALLOW_ROW_LOCKS = ON and PAD_INDEX = OFF options from the scripts.
You can use the stored procedures on SQL Azure as usual, with the exception that they do not reside in the msdb system database but on our user database.

The sp_send_dbmail stored procedure
The stored procedure sp_send_dbmail enqueues a mail message for sending. The message can be either in plain text or HTML and have files in attachment. The body of the message or the attachment may also contain the result of a query.

A glance at the stored procedures’s source code reveals that some changes are needed to make it run on SQL Azure. Firstly it is necessary to comment out the code that checks for the service broker and the ExternalMailQueue queue:

–Check if SSB is enabled in this database
–IF (ISNULL(DATABASEPROPERTYEX(DB_NAME(), N’IsBrokerEnabled’), 0) 1)
–BEGIN
— RAISERROR(14650, 16, 1)
— RETURN 1
–END

–Report error if the mail queue has been stopped.
–sysmail_stop_sp/sysmail_start_sp changes the receive status of the SSB queue
–IF NOT EXISTS (SELECT * FROM sys.service_queues WHERE name = N’ExternalMailQueue’ AND is_receive_enabled = 1)
–BEGIN
— RAISERROR(14641, 16, 1)
— RETURN 1
–END

we also need to remove the call to sp_SendMailQueues

— Create the primary SSB xml maessage
–SET @sendmailxml = ”
— + CONVERT(NVARCHAR(20), @mailitem_id) + N”

— Send the send request on queue.
–EXEC @rc = sp_SendMailQueues @sendmailxml
–IF @rc 0
–BEGIN
— RAISERROR(14627, 16, 1, @rc, ‘send mail’)
— GOTO ErrorHandler;
–END

and, of course, all references to the msdb database.

The original stored procedure calls dbo.sp_validate_user. This stored procedure is used to identify, if not specified, the default profile and checks if the user has rights to use it. At first it, this process is carried out using the information stored in sysmail_principalprofile. If the default profile is not identified, the stored procedure tries a profile lookup based on Windows Group membership. Of course, since we only have SQL authentication, this does not makes sense in SQL Azure and we have to comment out the few lines related.

The security check makes use of the functions dbo.get_principal_id and dbo.get_principal_sid, not present on SQL Azure. The function code is not available, but you can easily write it:

CREATE FUNCTION dbo.get_principal_id (@sid varbinary(85))
RETURNS int
AS
BEGIN
DECLARE @id int
SELECT @id = principal_id FROM sys.database_principals WHERE sid=@sid
RETURN @id
END
GO

CREATE FUNCTION dbo.get_principal_sid (@id int)
RETURNS varbinary(85)
AS
BEGIN
DECLARE @sid varbinary(85)
SELECT @sid = sid FROM sys.database_principals WHERE principal_id=@id
RETURN @sid
END

GO

Through the parameter @file_attachments of sp_send_dbmail you can specify a list of files to be attached to the message. The attachments are specified as a semicolon separated list of absolute file paths. The stored procedure sp_GetAttachmentData, using the extended procedure xp_sysmail_attachment_load, stores the file content in sysmail_attachments_transfer. This mechanism cannot work in SQL Azure, so you must remove the code.
Since the attachment names are stored in sysmail_mailitems they can be used for sending. Of course the files will be on the cloud storage and consequently the file path will be an absolute URL or the container/file name pair of a known storage account.

Also, the stored procedure sp_send_dbmail allows to append to the message body (or as file in attachment) the result of a query. This feature relies on the xp_sysmail_format_query extended procedure, which is called by sp_RunMailQuery. xp_sysmail_format_query deals with query and builds the string that represents the output in tabular format. For sake of simplicity this feature is removed. You can port it to SQL Azure by adding to sp_RunMailQuery the code required to execute the query and format the output table as a string.

The original definition of the stored procedures uses an impersonation as dbo (CREATE PROCEDURE [dbo]. [Sp_send_dbmail] … WITH EXECUTE AS ‘dbo’). SQL Azure does not allow the use of SNAME_SUSER() in impersonation contexts, and since it is used in the code and as a default field value, the WITH EXECUTE AS clause is removed.

Sending an e-mail
The stored procedure sp_send_dbmail relies for its operation on the sysmail_mailitems table. The sent_account_id field is set to the account id of the actually used profile, the sent_status value indicates the message status (1 sent, 2 sending failed, 3 not sent) and sent_date is set to the date and time of message sending.
With a join between sysmail_mailitems, sysmail_profile, sysmail_profileaccount, sysmail_account, sysmail_server and sysmail_account_credential you can retrieve all information needed for sending:

SELECT sysmail_mailitems.recipients, sysmail_mailitems.copy_recipients, sysmail_mailitems.blind_copy_recipients, sysmail_mailitems.subject, sysmail_mailitems.body,
sysmail_mailitems.body_format, sysmail_mailitems.importance, sysmail_mailitems.sensitivity, sysmail_mailitems.file_attachments, sysmail_mailitems.sent_status,
sysmail_account.email_address, sysmail_account.display_name, sysmail_account.replyto_address, sysmail_server.servername, sysmail_server.port,
sysmail_server.username, sysmail_profileaccount.sequence_number, sysmail_account_credential.cyphertext AS [Password]
FROM sysmail_profileaccount INNER JOIN
sysmail_account ON sysmail_profileaccount.account_id = sysmail_account.account_id INNER JOIN
sysmail_mailitems INNER JOIN
sysmail_profile ON sysmail_mailitems.profile_id = sysmail_profile.profile_id ON sysmail_profileaccount.profile_id = sysmail_profile.profile_id INNER JOIN
sysmail_server ON sysmail_account.account_id = sysmail_server.account_id LEFT OUTER JOIN
sysmail_account_credential ON sysmail_server.credential_id = sysmail_account_credential.credential_id
WHERE (sysmail_mailitems.sent_status = 0)
ORDER BY sysmail_profileaccount.sequence_number

The complete script for creating tables and stored procedures can be downloaded here . Of course, before you use this code in a production environment, you should test it thoroughly and add tighter security checks.

To create a worker role for sending messages, you can refer to the excellent MSDN blog posts I Miss You SQL Server Agent: Part 1 and I Miss You SQL Server Agent: Part 2.
The worker role needs to check if there are messages waiting on queue (sent_status = 0) and send them using an SMTP Client, trying with several accounts if needed. After sending the message, it should update the sysmail_mailitems table setting the fields sent_status, sent_date, from_address and reply_to. The values for the latter two are from the actually used account.
As mentioned earlier, the attachment file should be stored on the cloud storage, the worker role transfers it on local storage and instructs the SMTP client accordingly.

I hope I’ve provided some guidance to ease the porting process of your solution on SQL Azure, limiting the need for changes. If you need clarification, you can also contact me directly using the form on “Contatti”.

Pubblicato in Programmazione, Windows Azure Tutorial | Contrassegnato , , , , , , , | 9 commenti

Replicare le funzionalità di Database Mail su SQL Azure

As requested by some people, I published an english version of this post.

Tra le funzionalità di SQL Server 2008 non presenti in SQL Azure, dando un’occhiata all’MSDN, spicca l’assenza delle funzionalità legate a SQL Agent. Tra queste c’è Database Mail, che permette di gestire l’invio di messaggi di posta elettronica direttamente dal database engine, eseguendo una serie di stored procedure in msdb.
Realizzare un meccanismo che accodi i messaggi all’interno di un database SQL Azure e li invii attraverso un worker role è abbastanza semplice, ma vorrei andare oltre, realizzando la compatibilità con il codice già scritto per Database Mail, trasferendo su Azure le sue funzionalità.
In questo post vedremo come è possibile adattare le stored procedure di sistema in modo da farle eseguire su SQL Azure. Considereremo solo le stored procedure più comuni. Le altre, se necessario, potranno essere adattate in modo analogo.

Ricavare il codice originale
Ricavare il codice originale delle stored procedure è piuttosto semplice. Basta andare con SSMS sull’oggetto interessato nel database msdb e scegliere di modificarlo. Per quasi tutti gli oggetti è stato possibile procedere alla modifica del codice in questo modo. Le function dbo.get_principal_id e dbo.get_principal_sid sono state riscritte (ma sono banali), mentre per l’extended procedure xp_sysmail_format_query si è deciso, viste le finalità del post, di non procedere alla replicazione della funzione che permette di allegare o accodare al corpo del messaggio il risultato di una query. Se questa funzionalità è per voi strategica sarà necessario scrivere il codice che formatta l’output di una query in una stringa rappresentante la tabella di output.

Gestione dei profili
I messaggi sono inviati utilizzando i profili, che contengono tutte le informazioni sull’account ed il server SMTP da utilizzare per l’operazione e permettono di realizzare un meccanismo di ridondanza che garantisce l’invio del messaggio. Le operazioni tipiche per la creazione dei profili sono:

— Creazione di un account Database Mail
EXECUTE msdb.dbo.sysmail_add_account_sp
@account_name = ‘AdventureWorks2008R2 Public Account’,
@description = ‘Mail account for use by all database users.’,
@email_address = ‘db_users@Adventure-Works.com’,
@replyto_address = ‘danw@Adventure-Works.com’,
@display_name = ‘AdventureWorks2008R2 Automated Mailer’,
@mailserver_name = ‘smtp.Adventure-Works.com’ ;

— Creazione di un profilo Database Mail
EXECUTE msdb.dbo.sysmail_add_profile_sp
@profile_name = ‘AdventureWorks2008R2 Public Profile’,
@description = ‘Profile used for administrative mail.’ ;

— Aggiunta dell’account nel profilo
EXECUTE msdb.dbo.sysmail_add_profileaccount_sp
@profile_name = ‘AdventureWorks2008R2 Public Profile’,
@account_name = ‘AdventureWorks2008R2 Public Account’,
@sequence_number =1 ;

— Concessione agli utenti dell’accesso al profilo
EXECUTE msdb.dbo.sysmail_add_principalprofile_sp
@profile_name = ‘AdventureWorks2008R2 Public Profile’,
@principal_name = ‘public’,
@is_default = 1 ;

Le stored procedure coinvolte, con le relative dipendenze sono:

  • sysmail_verify_accountparams_sp
  • sysmail_verify_profile_sp
  • sysmail_verify_account_sp
  • sysmail_verify_principal_sp
  • sysmail_add_profile_sp
  • sysmail_add_profileaccount_sp
  • sysmail_add_principalprofile_sp
  • sysmail_add_account_sp
  • sysmail_create_user_credential_sp

Queste stored procedure possono essere create in SQL Azure facilmente, utilizzando degli script estratti dal proprio server SQL 2008. In generale, per le stored procedure non utilizzate nella creazione dell’account e delle relative credenziali (sysmail_create_user_credential_sp e sysmail_add_account_sp), non sono necessarie particolari modifiche, eccettuata la rimozione di qualche riferimento esplicito al database msdb.

La stored procedure sysmail_add_account_sp memorizza la username e la password dell’account come credenziale all’interno del server. Questo meccanismo, non essendo possibile recuperare in un secondo momento il secret della credenziale, va modificato al fine di permettere ad un worker role di ottenere la password per l’autenticazione SMTP.
Il modo più semplice è quello di creare una nuova tabella per la memorizzazione delle credenziali e modificare in modo opportuno la stored procedure sysmail_create_user_credential_sp. Ovviamente le password andranno protette in modo adeguato, ma a causa delle attuali limitazioni di SQL Azure non è possibile utilizzare gli statement EncryptBy*. Per semplicità memorizzeremo le password in chiaro (non rabbrividite, vi prego! Il campo per la password ha come nome “cyphertext” per ricordarvi di proteggerlo.).

CREATE TABLE sysmail_account_credential(
credential_id int IDENTITY(1,1) NOT NULL,
username nvarchar(256) NULL,
cyphertext nvarchar(256) NULL,
CONSTRAINT [SYSMAIL_ACCOUNT_CREDENTIALIDMustBeUnique] PRIMARY KEY CLUSTERED
(
credential_id ASC
)
WITH (STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF))

CREATE PROCEDURE [dbo].[sysmail_create_user_credential_sp]
@username nvarchar(128),
@password nvarchar(128),
@credential_id int OUTPUT
AS
— Le porzioni commentate fanno riferimento al codice originale

SET NOCOUNT ON
–DECLARE @rc int
–DECLARE @credential_name UNIQUEIDENTIFIER
DECLARE @credential_name_as_str varchar(40)
–DECLARE @sql NVARCHAR(max)

—- create a GUID as the name for the credential
–SET @credential_name = newid()
SET @credential_name_as_str = convert(varchar(40), @username) –@credential_name)
–SET @sql = N’CREATE CREDENTIAL [‘ + @credential_name_as_str
— + N’] WITH IDENTITY = ‘ + QUOTENAME(@username, ””)
— + N’, SECRET = ‘ + QUOTENAME(ISNULL(@password, N”), ””)

–EXEC @rc = sp_executesql @statement = @sql
–IF(@rc 0)
— RETURN @rc

INSERT INTO dbo.sysmail_account_credential (username,cyphertext) VALUES (@username, @password)

–SELECT @credential_id = credential_id
–FROM sys.credentials
–WHERE name = convert(sysname, @credential_name)

SELECT @credential_id = credential_id FROM dbo.sysmail_account_credential WHERE credential_id = @@IDENTITY

IF(@credential_id IS NULL)
BEGIN
RAISERROR(14616, -1, -1, @credential_name_as_str)
RETURN 1
END

RETURN(0)
GO

Le stored procedure, a loro volta dipendono dall’esistenza delle seguenti tabelle:

  • sysmail_account
  • sysmail_server
  • sysmail_servertype
  • sysmail_profile
  • sysmail_profileaccount
  • sysmail_principalprofile

Anche in questo caso le tabelle possono essere create utilizzando gli script generati con SSMS connesso al server SQL 2008. Gli script prodotti, per risolvere delle incompatibilità con SQL Azure, vanno modificati rimuovendo i riferimenti ai filegroup e le opzioni ALLOW_PAGE_LOCKS = ON, ALLOW_ROW_LOCKS = ON, PAD_INDEX = OFF.
Fatto questo è possibile utilizzare le stored procedure in modo usuale, con l’unica eccezione che queste non risiederanno nel database di sistema msdb ma sul nostro database utente.

La stored procedure sp_send_dbmail
La stored procedure sp_send_dbmail permette di accodare un messaggio di posta elettronica per l’invio. Il messaggio può essere in formato plain text o HTML e avere dei file in allegato. Il corpo del messaggio o l’allegato può contenere anche il risultato dell’esecuzione di una query.

Scorrendo il sorgente della stored procedure sp_send_dbmail appare evidente che necessita di alcune modifiche per poter essere utilizzata su SQL Azure. Innanzi tutto è necessario commentare il codice relativo alla verifica dello stato del service broker e della coda ExternalMailQueue:

–Check if SSB is enabled in this database
–IF (ISNULL(DATABASEPROPERTYEX(DB_NAME(), N’IsBrokerEnabled’), 0) 1)
–BEGIN
— RAISERROR(14650, 16, 1)
— RETURN 1
–END

–Report error if the mail queue has been stopped.
–sysmail_stop_sp/sysmail_start_sp changes the receive status of the SSB queue
–IF NOT EXISTS (SELECT * FROM sys.service_queues WHERE name = N’ExternalMailQueue’ AND is_receive_enabled = 1)
–BEGIN
— RAISERROR(14641, 16, 1)
— RETURN 1
–END

va inoltre commentata la chiamata a sp_SendMailQueues

— Create the primary SSB xml maessage
–SET @sendmailxml = ”
— + CONVERT(NVARCHAR(20), @mailitem_id) + N”

— Send the send request on queue.
–EXEC @rc = sp_SendMailQueues @sendmailxml
–IF @rc 0
–BEGIN
— RAISERROR(14627, 16, 1, @rc, ‘send mail’)
— GOTO ErrorHandler;
–END

e rimossi i riferimenti espliciti al database msdb.

Nel codice della stored procedure originale vengono effettuate delle chiamate a dbo.sp_validate_user. Questa stored procedure viene utilizzata, nel caso in cui questo non viene specificato, per identificare il profilo di default e per verificare se l’utente ha accesso al profilo. Nel caso in cui una verifica su sysmail_principalprofile non abbia dato risultati, la ricerca e la verifica vengono effettuati nel contesto di un gruppo di utenti del sistema operativo o del dominio. Questi controlli, essendo l’autenticazione SQL l’unica disponibile, vanno commentati.

Per la verifica su sysmail_principalprofile vengono utilizzate le function dbo.get_principal_id e dbo.get_principal_sid, non presenti su SQL Azure. Il codice delle funzioni non è disponibile, ma è possibile riscriverle facilmente:

CREATE FUNCTION dbo.get_principal_id (@sid varbinary(85))
RETURNS int
AS
BEGIN
DECLARE @id int
SELECT @id = principal_id FROM sys.database_principals WHERE sid=@sid
RETURN @id
END
GO

CREATE FUNCTION dbo.get_principal_sid (@id int)
RETURNS varbinary(85)
AS
BEGIN
DECLARE @sid varbinary(85)
SELECT @sid = sid FROM sys.database_principals WHERE principal_id=@id
RETURN @sid
END

GO

Attraverso il parametro @file_attachments di sp_send_dbmail è possibile specificare una lista di file da allegare al messaggio. Gli allegati sono specificati indicando il percorso assoluto al file. La stored procedure sp_GetAttachmentData, usando l’extended procedure xp_sysmail_attachment_load, carica il contenuto del file nella tabella sysmail_attachments_transfer. Questo meccanismo non può funzionare nel contesto di SQL Azure, pertanto è necessario rimuovere il codice relativo.
I nomi degli allegati saranno comunque memorizzati nella tabella sysmail_mailitems e potranno essere utilizzati in seguito per l’invio. Ovviamente i file non saranno nel file system locale dell’istanza SQL Azure, ma sul cloud storage e di conseguenza il percorso del file sarà l’URL assoluta o semplicemente la coppia container/nome file all’interno di uno storage noto a priori.

La stored procedure sp_send_dbmail permette anche di accodare al corpo del messaggio o inserire come allegato il risultato dell’esecuzione di una query. Questa funzionalità si basa sull’extended procedure xp_sysmail_format_query richiamata da sp_RunMailQuery. xp_sysmail_format_query si occupa di eseguire la query e di costruire la stringa che rappresenta l’output in formato tabellare. Per semplicità non ci occuperemo di questa funzione, ma è possibile ricostruire questa caratteristica modificando in modo opportuno sp_RunMailQuery.

Nella definizione della stored procedure originale è prevista l’impersonazione come dbo (CREATE PROCEDURE [dbo].[sp_send_dbmail] … WITH EXECUTE AS ‘dbo’). SQL Azure non permette l’utilizzo di SNAME_SUSER() in un contesto di impersonazione e, visto che questa è utilizzata sia esplicitamente nel codice che come valore di default nelle tabelle, la clausola EXECUTE AS è stata rimossa.

Ricavare le informazioni per l’invio
La stored procedure sp_send_dbmail si appoggia per il suo funzionamento sulla tabella sysmail_mailitems. Il campo sent_account_id viene impostato all’id dell’account del profilo utilizzato effettivamente per l’invio, il campo sent_status indica lo stato del messaggio (1 inviato, 2 invio fallito, 3 non inviato), mentre il campo sent_date viene impostato alla data ed ora di invio.
Con una join tra le tabelle sysmail_mailitems, sysmail_profile, sysmail_profileaccount, sysmail_account, sysmail_server e sysmail_account_credential è possibile recuperare tutte le informazioni necessarie per effettuare l’invio:

SELECT sysmail_mailitems.recipients, sysmail_mailitems.copy_recipients, sysmail_mailitems.blind_copy_recipients, sysmail_mailitems.subject, sysmail_mailitems.body,
sysmail_mailitems.body_format, sysmail_mailitems.importance, sysmail_mailitems.sensitivity, sysmail_mailitems.file_attachments, sysmail_mailitems.sent_status,
sysmail_account.email_address, sysmail_account.display_name, sysmail_account.replyto_address, sysmail_server.servername, sysmail_server.port,
sysmail_server.username, sysmail_profileaccount.sequence_number, sysmail_account_credential.cyphertext AS [Password]
FROM sysmail_profileaccount INNER JOIN
sysmail_account ON sysmail_profileaccount.account_id = sysmail_account.account_id INNER JOIN
sysmail_mailitems INNER JOIN
sysmail_profile ON sysmail_mailitems.profile_id = sysmail_profile.profile_id ON sysmail_profileaccount.profile_id = sysmail_profile.profile_id INNER JOIN
sysmail_server ON sysmail_account.account_id = sysmail_server.account_id LEFT OUTER JOIN
sysmail_account_credential ON sysmail_server.credential_id = sysmail_account_credential.credential_id
WHERE (sysmail_mailitems.sent_status = 0)
ORDER BY sysmail_profileaccount.sequence_number

Lo script completo per la creazione delle tabelle e delle stored procedure può essere scaricato da qui.
Ovviamente, prima di utilizzare le stored procedure in un ambiente di produzione è bene testarle a fondo e, se non viene implementato il meccanismo di esecuzione delle query, aggiungere dei controlli più restrittivi.

Per la creazione di un worker role per l’invio dei messaggi è possibile fare riferimento agli ottimi post del blog MSDN I Miss You SQL Server Agent: Part 1 e I Miss You SQL Server Agent: Part 2.
Il worker role dovrà controllare se esistono dei messaggi in attesa di invio (sent_status=0) e tentare di trasmetterlo con un SMTP Client, eventualmente riprovando con account differenti. Una volta inviato il messaggio dovrebbe aggiornare, sulla tabella sysmail_mailitems, i campi sent_status e sent_date ed inserire i valori corretti nei campi from_address e reply_to sulla base dell’account utilizzato.
Come detto prima i file degli allegati dovrebbero essere custoditi sul cloud storage, ad esempio su un container predefinito. Quest’ultimo potrebbe essere sia pubblico che privato.
Il worker role si occuperebbe di trasferire i file sul local storage e istruire l’SMTP Client ad allegarne il contenuto.

Spero di avervi fornito delle indicazioni utili al porting della vostra soluzione su SQL Azure limitando la necessità di modifiche. Se doveste avere necessità di chiarimenti, potete anche contattarmi direttamente, utilizzando la pagina Contatti.

Pubblicato in Programmazione, Windows Azure Tutorial | Contrassegnato , , , , , , , | 2 commenti

La migrazione di Web Signage su Windows Azure

Edisonweb, l’azienda per cui lavoro come direttore tecnico, ha come prodotto di punta Web Signage: una soluzione SaaS per il digital signage, la gestione di kiosk interattivi, l’audio diffusione ed il marketing di prossimità. Web Signage è una complessa web application sviluppata utilizzando il framework .NET e progettata in modo da poter scalare liberamente verso l’alto. I dati e le configurazioni sono conservati su un database SQL Server. Su questo sono presenti una serie di stored procedure che permettono di nascondere alla web application la complessità delle operazioni sul data store.

Grazie al fatto che Edisonweb è un Microsoft Gold Certified Partner, ho avuto la possibilità di provare e studiare Windows Azure molto prima del suo rilascio. Il cloud computing ha dei vantaggi enormi per l’attività di un ISV, in particolare per quelli che si occupano di segmenti di mercato molto verticali, di conseguenza abbiamo seriamente valutato l’opportunità di migrare l’applicazione sul cloud. Windows Azure ci avrebbe permesso di abbassare i costi d’infrastruttura e di migliorare la nostra offerta verso i mercati esteri, con notevoli vantaggi in termini di competitività. A questo si univa il fatto che non esisteva nessuna soluzione per il digital signage su Azure: se avessimo battuto la concorrenza nella corsa avremmo aggiunto anche una bella freccia al nostro marketing. L’obiettivo era ormai chiaro: dovevamo migrare Web Signage su Windows Azure battendo sul tempo la concorrenza preservando un progetto unitario e mantenendo tutte le caratteristiche della soluzione on premises.

Compatibilità del database
Il primo passo nel processo di migrazione è stato quello della valutazione di potenziali incompatibilità del codice T-SQL utilizzato nel data store con SQL Azure. Il risultato fu che, a parte alcune porzioni di codice in cui veniva utilizzato il costrutto SELECT INTO e i nomi di colonna nella forma schema.tabella.colonna, tutto il codice delle stored procedure era perfettamente funzionante su SQL Azure. Dopo una attività di revisione del codice incriminato eravamo in grado di attivare una sessione applicativa di Web Signage con l’application on premises e il data store sul cloud.

Compatilità dell’applicazione
Web Signage è stato progettato per poter lavorare in una web farm con una serie di front-end server in bilanciamento di carico. L’applicazione è stateless, di conseguenza il fatto di passare da una batteria di server fisici ad una serie di istanze di Web Role e Worker Role non avrebe avuto un impatto particolare.
Nel processo di migrazione è stato, invece, necessario:

  • Rimuovere codice legacy (DLL COM ed interop)
  • Rivedere le porzioni di codice utilizzanti funzioni GDI+
  • Implementare i meccanismi di utilizzo del cloud storage

Web Signage è un progetto basato su Web Automation: il framework role based per la gestione dell’auditing, delle utenze e dei criteri di manipolazione e condivisione degli oggetti sviluppato da Edisonweb. Quando Web Automation fu sviluppato con il framework .NET 1.1 erano stati importate delle porzioni di codice non gestito come COM Interop. Questo codice, mantenuto solo per garantire la backward compatibility, richiede la registrazione di librerie COM e quindi attività per le quali è necessario avere un profilo di amministrazione sul server.
Piuttosto che attuare dei meccanismi di attivazione side-by-side della libreria, visto che il codice legacy è a tutti gli effetti inutilizzato, si è preferito rimuovere gli interop e sostituire le componenti potenzialmente utilizzate con versioni in codice gestito.

Alcuni componenti (per fortuna pochi) utilizzanti funzioni di manipolazione d’immagine di GDI+, se eseguiti in Windows Azure scatenano invariabilmente un’eccezione OutOfMemoryException. E’ un problema tristemente noto.
Web Signage, per sua natura effettua manipolazioni di file multimediali, ma per fortuna il codice non compatibile è limitato ad alcune funzioni specifiche che sono state sostituite con codice WPF.

Web Signage distribuisce ai display i contenuti multimediali che vengono riprodotti da Web Signage Player. In una installazione on premises questi sono contenuti in una SAN visibile dai front-end server. La migrazione a Windows Azure richiede la sostituzione di questo storage condiviso con il cloud storage.
Tutte le operazioni di manipolazione dei file sono effettuate sul local storage di ogni istanza, era quindi necessario implementare dei meccanismi tali da garantire la robustezza del servizio e l’integrità dei dati, mantenendo al tempo stesso la compatibilità con una installazione on premises. A questo scopo è stata creata una classe in grado di gestire in modo trasparente le operazioni sui contenuti, indipendentemente dalla tipologia di installazione.

Il processo di migrazione è stato completato nei tempi pianificati e l’applicazione finale è, a parte una nota accanto il numero di versione, indistinguibile da quella erogata dall’infrastruttura in IDC. Web Signage è stata la prima soluzione professionale per il digital signage in grado di essere eseguita su Windows Azure e tutt’ora è l’unica soluzione disponibile. I vantaggi della presenza nel cloud si sono evidenziati immediatamente dopo il rilascio, con una maggiore visibilità e competitività sui mercati esteri.

Il processo di migrazione, partendo da applicazioni sviluppate sul framework .NET e con del codice di buona qualità, è relativamente veloce e permette l’accesso a benefici significativi. Il mio consiglio è sicuramente quello di valutare seriamente questa opportunità. Se volete intraprendere questa via e desiderate pormi qualche domanda, non esitate a contattarmi.

Se siete curiosi riguardo Web Signage ed in particolare sulla versione per Windows Azure, troverete tutte le informazioni sul sito websignage.eu/it.

Pubblicato in Cloud computing | Contrassegnato , , , , , , , , | 2 commenti