Come scritto nel post precedente, stò dando all'utente finale la possibilità di gestirsi gli snapshot direttamente dall'applicazione, ed ora tocca alla fase di creazione di uno snapshot.

Come ben sapete (e come ho scritto in questo post) gli snapshot vengono creati utilizzando i valori di default dei parametri.
Reporting Services fornisce la possibilità di forzare la creazione di uno snapshot tramite il metodo CreateReportHistorySnapshot, che si comporta esattamente come il pulsante presente nel sito di sharepoint di Reporting, che crea lo snapshot utilizzando i valori dei parametri in quel preciso istante (quindi facendo uso dei valori di default).

Ma se volessimo eseguire uno snapshot che abbia diversi parametri?
E' il caso in cui il report abbia le date o dei filtri calcolati in automatico, magari perchè deve venire eseguito con i dati della settimana precedente, o del mese precedente. Però Il cliente potrebbe avere la necessità di rigenerare il report riferito ad un perioso diverso (magari di 2 settimane prima).
In questo caso si può intervenire andando a modificare da codice i valori di default dei parametri del report, e dopo aver eseguito lo snapshot, ripristinarli ai valori normali.

Ecco qui il codice da qui potete prendere spunto:

   1: using (ReportingService2005SoapClient rs = this.CreateReportingService2005SoapClient())

   2: {

   3:     string batchID = string.Empty;

   4:     ServerInfoHeader infoHeader = rs.CreateBatch(out batchID);

   5:     BatchHeader bh = new BatchHeader()

   6:     {

   7:         BatchID = batchID,

   8:         AnyAttr = infoHeader.AnyAttr

   9:     };

  10:     CatalogItem[] items = null;

  11:     rs.ListChildren(reportFolder, true, out items);

  12:  

  13:     foreach (var item in items)

  14:         if (string.Compare(item.ID, reportId.ToString(), true) == 0)

  15:         {

  16:             // recupero gli attuali parametri e mi tengo una copia degli originali

  17:             ReportParameter[] defaultParameters = null;

  18:             ReportParameter[] parameters = null;

  19:             rs.GetReportParameters(item.Path, null, false, null, null, out defaultParameters);

  20:             rs.GetReportParameters(item.Path, null, false, null, null, out parameters);

  21:  

  22:  

  23:             foreach (ReportParameter parameter in parameters)

  24:             {

  25:                 //modifico i valori dei parametri che voglio cambiare

  26:                 if (string.Compare(parameter.Name, "dateStart", true) == 0)

  27:                     parameter.DefaultValues = new string[] { string.Format("{0:s}", startDate) };

  28:                 else if (string.Compare(parameter.Name, "dateEnd", true) == 0)

  29:                     parameter.DefaultValues = new string[] { string.Format("{0:s}", endDate) };

  30:             }

  31:             // setto i parametri modificati nel report

  32:             rs.SetReportParameters(bh, item.Path, parameters);

  33:             string historyId = string.Empty;

  34:             Warning[] warnings = null;

  35:             // creo lo snapshot

  36:             rs.CreateReportHistorySnapshot(bh, item.Path, out historyId, out warnings);

  37:             // setto i parametri originali

  38:             rs.SetReportParameters(bh, item.Path, defaultParameters);

  39:             // eseguo il tutto sotto un'unica transazione

  40:             rs.ExecuteBatch(bh);

  41:             return;

  42:         }

  43: }

Faccio notare che il tutto viene eseuito sotto un'unica transazione al comando rs.ExecuteBatch(bh), e in caso di errori, il report continuerebbe ad avere i suoi normali valori di default e non i valori da noi modificati.

Può capitare di voler dare la possibilità all'utente di cancellare uno snapshot di un determinato report, e dargli la possibilità di farlo direttamente dall'applicazione che abbiamo realizzato.

Oggi mi sono scontrato con questa problematica, e uscirne non è stato proprio immediato a causa della scarsa documentazione a riguardo. Spero quindi che questo post sia utili a qualcuno.

Nella classe ReportingService2005SoapClient (del proxy generato verso il WebService di Reporting Services) esiste un metodo DeleteReportHistorySnapshot che si occupa per l'appunto di cancellare un preciso snapshot (DeleteReportHistorySnapshot), ma il come utilizzarlo è stato un pò oscuro.

Ecco qui il codice finale, che recupera il path del report, conoscendone l'id (scorrendo i report contenuti in una precisa cartella), e successivamente richiama la cancellazione dello snapshot avente l'historyId conosciuto.

   1: using (ReportingService2005SoapClient rs = this.CreateReportingService2005SoapClient())

   2: {                

   3:     string batchID = string.Empty;

   4:     ServerInfoHeader infoHeader = rs.CreateBatch(out batchID);

   5:     BatchHeader bh = new BatchHeader()

   6:     {

   7:         BatchID = batchID,

   8:         AnyAttr = infoHeader.AnyAttr

   9:     };

  10:  

  11:     CatalogItem[] items = null;

  12:     rs.ListChildren(reportFolder, true, out items);

  13:  

  14:     foreach (var item in items)

  15:         if (string.Compare(item.ID, reportId.ToString(), true) == 0)

  16:         {

  17:             rs.DeleteReportHistorySnapshot(bh, item.Path, historyId);

  18:             rs.ExecuteBatch(bh);

  19:         }

  20: }

La difficoltà è stata nel capire cosa fosse il BachHeader, e il di dover chiamare rs.ExecuteBatch,  che si occupa di lanciare i comandi che sono stati inviati utilizzando lo stesso BatchHeader sotto un'unica transazione. Non avendo mai fatto uso (in passato) di metodi a cui viene passato un oggetto BatchHeader, questa soluzione non mi è venuta proprio spontanea.

Ecco un link a riguardo delle operazioni eseguite in batch in reporting services: Batching Methods

E' da molto che seguo questo progetto, e chi mi segue, sa che ne ho scritto una guida pubblicata su html.it (Guida BlogEngine.NET).
L'ultima release di questo engine risale alla versione 1.5.0 del 13 Aprile 2009 (veramente datata), ma per poter usufruire/conoscere/testare le varie funzionalità aggiunte a BlogEngine.NET, ho sempre tenuto aggiornato questo blog con l'ultima versione di sviluppo, e vi posso assicurare che ha fatto dei notevoli passa avanti.

E' con gran piacere che oggi apprendo (BlogEngine.NET 1.6.0 is Released)  che è stata rilasciata una nuova release, la 1.6.0, con parecchie novità.
Tra le più importanti troviamo l'inserimento di un filtro per i commenti, che di default viene fatto con le Akismet, ma anche con regole custom, e con la possibilità di svilupparsi dei proprio filtri.
Altra novità, che attendevo da molto è la presenza di una pagina per la moderazione/gestione dei commenti, evitando quindi di dover andare nelle pagine dei post.
Ma le novità non si fermano qui, ed ecco la lista completa:

• Centralized Comment Management
• Automated Comment Spam Filtering with ability to plug-in custom Filtering modules
• Multiple Widget Zones
• Referrers data and Blogroll items now stored in Database when using the DB blog provider.
• Unsubscribe Link in Comment Notification Emails
• Referrer Data can be Stored for more than 7 days.
• Blogroll items can now be Ordered.
• Newsletter Widget more Intelligent - Emails sent when a post is going from an Unpublished to Published state.
• Twitter Widget - New options and improvements
• Page Slugs now saved in Database.
• New Logging system to Track events and errors.
• Unhandled Exception Handling
• Fixes to Comment Notification Emails not being sent out correctly in some cases.
• Outgoing Email improvements
• Many other improvements and fixes

Ecco quindi il link per il download di BlogEngine.NET 1.6.0: download