Giugno 2016

Volume 31 Numero 6

Il presente articolo è stato tradotto automaticamente.

Servizi app di Azure - Utilizzo di Servizi app di Azure per convertire una pagina Web in formato PDF

Da Benjamin Perkins

Conversione aWeb pagina in un file PDF è nuovo, ma il mio obiettivo, inserire un collegamento sul mio sito Web che ha dato ai visitatori un modo semplice per convertire una pagina specifica in un documento PDF in tempo reale, rivelato complicata. Esistono numerosi siti Web e file binari di origine aperto che consente di eseguire questa operazione, ma è stato mai in grado di connettere tutti i punti e ottenere l'output desiderati in modo che desidero.

Il miglior, o almeno il convertitore Preferiti, pagina Web in formato PDF è il programma di origine aperto chiamato wkhtmltopdf (wkhtmltopdf.org), che utilizza la riga di comando, come illustrato nella Figura 1.

Figura 1 in esecuzione il convertitore wkhtmltopdf dalla Console

Tuttavia, l'esecuzione di un programma dalla riga di comando è molto dalla conversione in tempo reale con un pulsante in una pagina Web.

Ho lavorato su parti diverse di questa soluzione negli ultimi mesi, ma l'esecuzione del processo di wkhtmltopdf parallelizzate impedito me conseguire l'obiettivo. È stata la domanda che sono rimasti senza risposta: "Come è possibile ottenere Microsoft Azure applicazione servizio Web App per generare la procedura per creare il file PDF?" Sito Web viene eseguito in una sandbox e sapevo dall'inizio che non riuscivo a tal fine, si è verificato zero possibilità che una richiesta inviata da un client di avvio ed esecuzione di un processo nel server del computer. Lavorando nel team di supporto di IIS per molti anni, sapevo che vengano anche in una versione autonoma di IIS richiede la sospensione di perdere le configurazioni che renderebbero gli analisti della sicurezza. Ho quindi pensato di processi Web.

I processi Web vengono eseguiti per esattamente questa situazione perché eseguono eseguibili in modo continuo o quando viene attivata da un'origine esterna. ad esempio, manualmente da Azure SDK o utilizzando un'utilità di pianificazione di Azure, CRON o l'API di processo Web Azure (bit.ly/1SD9gVJ). E, per la quale, durante la risposta. Potrei chiamo il programma wkhtmltopdf dal mio del servizio Web App tramite l'API di processo Web. Gli altri componenti della soluzione già lavorati in caso contrario. È stato infine l'ultima parte del puzzle, come Figura 2 Mostra.

Figura 2, la soluzione completa

Nell'esempio di codice contiene un sito Web ASP.NET con una pagina di indice che consente agli utenti di immettere un URL, inviare tale pagina Web vengono convertiti in un file PDF e quindi scaricare il PDF in un dispositivo client. Richiede il minimo sforzo per impostare questo URL alla pagina corrente ed è il pulsante Invia la pagina per l'API di processo Web per la conversione e scaricare dinamicamente. Le prossime sezioni di questo articolo illustrano le tecnologie utilizzate per creare la soluzione e viene illustrato come compilare e utilizzarli.

Panoramica di convertitore HTML in PDF

Ho utilizzato numerose tecnologie per creare la soluzione di App Web HTML in PDF App Service in tempo reale. La tabella in Figura 3 presenta una breve descrizione di queste tecnologie e li descriverò in dettaglio nelle sezioni che seguono.

Figura 3 tecnologie utilizzate nella soluzione

Ogni sezione include una descrizione funzionale e tecnica di una tecnologia, nonché i dettagli dei requisiti di codifica e la configurazione. Sono ordinate le diverse parti della soluzione come averle create, ma questa operazione può essere eseguita utilizzando un numero di sequenze diverse. L'obiettivo tecnico è per passare un URL per l'App del servizio Web App e ottengono un PDF. che ci permetterà di assistere a un round trip completo dal server al client. Iniziamo.

App Web servizio App di Azure

Servizi App di Azure consente di lavorare con diversi tipi di applicazioni: Web, mobili, logica (anteprima) e API. Tutti i servizi App nello stesso modo nel back-end, con funzione ognuno dei quali dispone di ulteriori funzionalità configurabili in front-end. Dal back-end si intende eseguire servizi di applicazione nei piani di servizio diverso (gratuito, condiviso, Basic, Standard e Premium) e dimensioni delle istanze (F1-P4); vedere bit.ly/1CVtRec per ulteriori dettagli. I piani offrono funzionalità quali gli slot di distribuzione, i limiti di spazio su disco, il ridimensionamento automatico e il massimo numero di istanze e così via, e le dimensioni di istanza vengono descritti il numero di CPU dedicate, nonché la memoria per ogni applicazione del servizio prevede (ASP), che equivale a una macchina virtuale (VM). E per il front-end, le funzionalità per un determinato servizio App forniscono le funzionalità appositamente progettate per un determinato tipo di servizio App per le proprie applicazioni distribuite, configurato e in esecuzione nel minor tempo.

Per il convertitore di HTML in PDF, si utilizzerà un'App Web S2 Azure App servizio perché non sono necessarie tutte le funzionalità fornite da altri tipi di servizio App.

Per iniziare, creare l'App Web nel portale di Azure, selezionare nuovo | Web e dispositivi mobili | App Web, quindi fornire il nome dell'App, sottoscrizione, i gruppi di risorse e piano di servizio App e fare clic sul pulsante Crea. Dopo aver creato l'app, utilizzare questo indirizzo per distribuire il codice sorgente nella soluzione Visual Studio 2015 scaricabile, convertHTMLtoPDF. Vengono fornite informazioni dettagliate di distribuzione alla fine dell'articolo; è necessario apportare alcune modifiche per ottenere il codice per lavorare con l'applicazione Web e processo Web specifico.

App Web, App per dispositivi mobili e App per le API includono una funzionalità basate sull'identità federata per l'impostazione di autenticazione e autorizzazione con Azure Active Directory e altri provider di identità come Facebook, Microsoft Live, Twitter e così via, come descritto nella sezione successiva.

Autorizzazione e autenticazione del servizio app

Ho deciso di configurare l'autenticazione del servizio App / funzionalità di autorizzazione per l'applicazione Web perché può essere inserito lo schema di SignalR, in cui è preferibile un nome visualizzato o l'identità del client. SignalR crea un ID di connessione per ogni client, ma è più semplice e più personale per utilizzare il nome reale di un visitatore durante l'invio o la registrazione di messaggi. Questa operazione può essere eseguita l'acquisizione, il callback della funzionalità di autenticazione e quindi visualizzando usando il codice di SignalR. Come ho implementato il provider di identità (IDP) di Account Microsoft, viene restituito il nome del visitatore autenticato nell'intestazione della richiesta X-MS-CLIENT-nome dell'entità. È accessibile dalla proprietà System.Security.Principle.IPrinciple.Identity.Name anche il nome dell'identità.

Ottenere l'autenticazione / per usare funzionalità di autorizzazione non richiede alcuna modifica di codice nel back-end di app che è semplicemente possibile seguire le istruzioni fornite in bit.ly/1MQZZdF. L'implementazione solo, è necessario abilitare l'autenticazione del servizio App, accessibile dal pannello impostazioni per il servizio App specificato e configurare una o più dei provider di autenticazione, come illustrato nella Figura 4.

Figura 4 l'autenticazione del servizio App / funzionalità di autorizzazione

La funzionalità offre numerose opzioni per una "azione da intraprendere quando richiesta non è autorizzata". Ad esempio, per accedere all'app Web HTML in PDF, è necessario avere un Account Microsoft e da autenticare presso il provider di identità; Nessun codice di app Web viene eseguito prima che venga eseguita l'autenticazione del provider di identità. In questo caso, pre-autenticazione è obbligatoria perché è stato selezionato "Log in con Microsoft Account" dall'elenco a discesa. Tutte le risorse del servizio App richiedono tale autenticazione, una volta che viene applicata un'azione. È possibile configurare la funzionalità di autenticazione in modo che i visitatori possono accedere a una pagina di accesso o altri endpoint del servizio App ospitato in Azure, che è possibile selezionare l'elemento di richiesta (alcuna azione) Consenti nell'elenco a discesa. Tuttavia, quindi sarebbe fino al codice dell'applicazione per limitare l'accesso a pagine protette. Questo approccio più granulare avviene in genere controllando il valore booleano Context.User.Identity.IsAuthenticated prima di eseguire il codice all'interno della pagina.

L'ultimo componente della soluzione di conversione in tempo reale, senza codice HTML in PDF è la creazione e la configurazione dell'account di archiviazione di Azure e contenitore.

Archiviazione di Azure

Il contenitore di archiviazione di Azure è il percorso in cui è archiviato il file PDF per il download. Se il contenitore di archiviazione è reso pubblico, chiunque può accedere ai file ospitati nel contenitore che fa riferimento il nome del file tramite un URL, ad esempio https://{storage-account}.blob.core.windows.net/{container-name}/{filename.pdf}. Inserimento, aggiornamento o rimozione dei file dal contenitore richiede una chiave di accesso quando eseguite dal codice. In questo modo tramite il portale di gestione o da Visual Studio può essere limitato tramite il controllo di accesso basato sui ruoli (RBAC) o semplicemente impedendo l'accesso utente alla sottoscrizione di Azure.

Per creare l'account di archiviazione, selezionare nuovo | Dati + archiviazione e l'account di archiviazione. L'attributo Name diventa l'account di archiviazione in cui viene creato il contenitore e la prima parte dell'URL: https//{storage-account}.blob.core.windows.net. L'attributo del modello di distribuzione consente di scegliere Gestione risorse o classica. A meno che non si dispone di applicazioni distribuite in una rete virtuale classica (VNET), è consigliabile che utilizzare Gestione risorse di tutte le nuove attività di sviluppo. Azure Resource Manager (ARM) è un approccio più dichiarativo che utilizza modelli e script. Al contrario, l'interfaccia con il modello classico, noto come Azure Service Manager (ASM), in genere viene eseguita tramite codice e le librerie.

Quando si decide di scegliere Standard o Premium prestazioni, è opportuno prendere in considerazione la velocità effettiva e costo. Standard è la più conveniente e ottimale per le applicazioni che archiviano dati di massa si accede raramente. Archiviazione Premium è supportata da unità SSD (SSD) che offrono prestazioni ottimali per le macchine virtuali con requisiti dei / o intensivo.

L'attributo di replica è disponibili numerose opzioni, ovvero locale, area, globali e accesso in lettura globale, ciascuno dei quali fornisce un livello maggiore di redundency e l'accessibilità. Ho utilizzate le impostazioni predefinite per la soluzione di HTML in PDF e selezionato la stessa sottoscrizione, gruppo di risorse e il percorso per l'applicazione Web creata in precedenza.

Infine, dopo la creazione dell'account di archiviazione, selezionare servizi BLOB pannello generale dell'account di archiviazione e quindi aggiungere il contenitore.

Il tipo di accesso nel nuovo pannello contenitore può essere privato (è necessaria per tutte le operazioni di una chiave di accesso), (consente l'accesso in lettura pubblico) Blob o contenitore (consente l'accesso in lettura ed elenco pubblico).

Questo è tutto, che è la configurazione Azure necessaria per questa soluzione. È consigliabile passare in codice c# ora per scoprire come ottenere la conversione da HTML in PDF in tempo reale a funzionare.

Processo Web Azure

La funzionalità di processo Web Azure supporta l'esecuzione di un file di script o eseguibile in modo continuo, trigger o pianificato (bit.ly/1Og9P95). Non confondere con un servizio Windows. considerare invece come processo batch o attività che deve essere eseguito in determinati momenti o quando si verifica un determinato evento. In questo caso, tramite i trigger di strumento di conversione HTML in PDF in tempo reale il processo Web tramite l'API. In alternativa, i processi Web possono essere avviati manualmente tramite Visual Studio o utilizzando la funzionalità di raccolte di processi dell'utilità di pianificazione di Azure.

La piattaforma servizio App di Azure determina se il processo Web è attivata o continua in base al percorso di archiviazione in cui il processo Web. Se il processo Web sta per essere attivata, devono essere distribuito nel nome d:\home\site\wwwroot\app_data\jobs\triggered\{job} directory; Se è in continuo, è sufficiente sostituire il percorso della directory attivate con continua. Per distribuire il processo Web, aggiungere la directory app_data\jobs\triggered\ {nome processo} a un progetto di sito Web in Visual Studio, aggiungere lo script o eseguibile su di esso, simile a quanto descritto in bit.ly/1Uczf8L, e pubblicarlo per la piattaforma servizio App di Azure.

Il processo Web che è stato creato esegue due attività, la conversione della pagina in un determinato indirizzo Web in un file PDF e il caricamento di file PDF di un contenitore di archiviazione di Azure. Potrei chiamato wkhtmltopdf.exe direttamente tramite l'API di processo Web, ma sarebbe necessario effettuare una chiamata API secondo quindi caricare il file di archiviazione e che sarebbe stato coinvolto molte complessità nella gestione di file e l'invio di risultati al client. Pertanto, ho creato un'applicazione console denominata convertToPdf (che è possibile visualizzare l'origine) che esegue queste due attività, uno dopo l'altro e restituisce il percorso del file PDF per il client che ha effettuato la richiesta.

Per avviare wkhtmltopdf.exe e passare i due parametri obbligatori, ovvero l'indirizzo Web e il nome del file PDF, ho utilizzato System.Diagnostics.ProcessStartInfo, come illustrato nella Figura 5.

Figura 5 avvio wkhtmltopdf.exe

static void Main(string[] args)
{
  var URL = args[0];
  var filename = args[1];
  try
  { 
    using (var p = new System.Diagnostics.Process())
    {
      var startInfo = new System.Diagnostics.ProcessStartInfo
      {
        FileName = "wkhtmltopdf.exe",
        Arguments = URL + " " + filename,
        UseShellExecute = false
      };
      p.StartInfo = startInfo;
      p.Start();
      p.WaitForExit();
      p.Close();
    }
  }
  catch (Exception ex) { WriteLine($"Something Happened: {ex.Message}"); }
}

Il codice crea un'istanza della classe ProcessStartInfo e imposta il nome del file, gli argomenti e altre proprietà della classe. Il metodo quindi avvia il processo identificato dalla proprietà FileName, attende il completamento dell'operazione e chiude il processo. Per impostazione predefinita, quando il processo Web viene caricato nell'ambiente del servizio App di Azure, viene copiato dalla piattaforma in una directory temporanea locale, ovvero D:\local\temp\jobs\triggered\ {nome processo} \ * \, dove * è un nome di directory generato dinamicamente. Questo è il file PDF posizione fisica prima di caricare il contenitore di archiviazione di Azure. Poiché il file è solo locale, non è persistente o accessibili a qualsiasi altra istanza di Azure App servizio Web App. Se si esegue più istanze, che potrebbe essere visualizzato nella directory locale, ma il contenitore di archiviazione di Azure è accessibile a livello globale.

Dopo aver creato il file PDF, deve essere caricato nel contenitore di archiviazione di Azure. Si noterà un'ottima esercitazione che descrive in dettaglio come eseguire questa operazione in bit.ly/1OAXIQ0. In sintesi, la possibilità di creare, leggere, aggiornare ed eliminare contenuti in un contenitore è controllata da due pacchetti NuGet, la libreria di Gestione configurazione di Microsoft Azure per .NET e Microsoft Azure Storage Client library per .NET. Entrambi i pacchetti fanno riferimento convertToPdf applicazione console processo Web. Per installarli, fare clic sul progetto di applicazione console e quindi Gestisci pacchetti NuGet. Quindi cercare e installare le librerie.

GetSetting, che fa parte della libreria di Microsoft Azure Configuration Manager, utilizzato per recuperare i valori di stringa di connessione di archiviazione per la connessione al contenitore di archiviazione di Azure. I valori sono AccountName, che corrisponde all'Account di archiviazione di Azure dei nomi (in questo caso converthtmltopdf), non il nome del contenitore e il valore AccountKey, che viene recuperato dal pannello Account di archiviazione facendo clic su impostazioni | Chiavi di accesso. Figura 6 viene illustrato come caricare il file PDF per il contenitore di archiviazione di Azure creato in precedenza.

Figura 6 caricando il formato PDF in un contenitore di archiviazione di Azure

static void Main(string[] args)
{
  try
  {
    CloudStorageAccount storageAccount =
      CloudStorageAccount.Parse(
      CloudConfigurationManager.GetSetting("StorageConnectionString"));
    CloudBlobClient blobClient = storageAccount.CreateCloudBlobClient();
    CloudBlobContainer container =
      blobClient.GetContainerReference("pdf");
    CloudBlockBlob blockBlob = container.GetBlockBlobReference(filename);
    using (var fileStream = System.IO.File.OpenRead(filename))
    {
      blockBlob.UploadFromStream(fileStream);
    }
  }
  catch (StorageException ex) { WriteLine($"StorageException: {ex.Message}"); }
  catch (Exception ex) { WriteLine($"Exception: {ex.Message}"); }
}

Le informazioni di configurazione viene utilizzate come input per la classe CloudStorageAccount, che fa parte di Microsoft Azure Storage Client library. Come alternativa a CloudConfigurationManager per recuperare il StorageConnectionString dal file app. config, è possibile utilizzare System.Configuration.ConfigurationManager.AppSettings["StorageConnectionString"].

Utilizzare un'istanza della classe CloudStorageAccount per creare un CloudBlobClient, quindi utilizzare il blobClient per ottenere un riferimento al contenitore di archiviazione di Azure con il metodo GetContainerReference. Quindi, è utilizzando il metodo GetBlockBlobReference della classe CloudBlobContainer, creare un oggetto CloudBlockBlob contenente il nome del file da caricare. Entrambi i file eseguibili, come evidenziati in precedenza, si trovano nella directory D:\local\temp\jobs\triggered\convertToPdf\***\, ovvero la stessa posizione in cui è archiviato e a cui fa riferimento nel file PDF. Ecco perché nessun percorso per il nome del file è obbligatorio, poiché il file viene creato nella stessa directory temporanea come i file eseguibili. Infine, passa un'istanza di System.IO.FileStream utilizzando il metodo System.IO.File.OpenRead e caricarlo al contenitore mediante il metodo UploadFromStream della classe CloudBlockBlock.

Una volta il codice è stato completato e viene compilato, aggiungere wkhtmltopdf.exe sia il convertToPdf.exe alla directory \app_data\jobs\triggered\convertToPdf della soluzione Visual Studio che verrà pubblicata il servizio Web App di Azure. È anche possibile pubblicare solo i file di processo Web utilizzando uno strumento FTP, trasferire il codice direttamente al sito Web.

Ora che il processo Web che crea e archivia il file PDF convertToPdf è completo, esaminiamo come chiamare il processo Web da codice c# utilizzando il HttpClient. In seguito, che rimane consiste nel creare un front-end basato su SignalR App del servizio Web App per consentire un visitatore per l'invio di un URL per il processo Web e ottenere nuovamente l'URL per il formato PDF per il download.

API di processo Web Azure

Ho scritto un articolo sull'API di processo Web Azure (bit.ly/1SD9gVJ) in cui è illustrata la procedura per chiamare l'API che attiva il processo Web. In pratica, l'API di processo Web è un'interfaccia Web che esegue uno script o eseguibile utilizzando gli argomenti passati nell'URL.

Prima di creare il SignalR Hub che attiva l'API di processo Web, ho creato un consumer di applicazione console semplice, illustrato nella Figura 7, che chiama l'API di processo Web. È incluso nella soluzione scaricabile e viene chiamato convertToPDF-consumer. Questa applicazione console semplificato la codifica, la risoluzione dei problemi e test, come la funzionalità di SignalR è stato rimosso dallo scenario.

Figura 7, il Consumer di applicazione Console semplice

static async Task<string> ConvertToPDFWebJobAPIAsync(string Url)
{
  try
  {
    using (var client = new HttpClient())
    {
      client.BaseAddress = new Uri(
        "https://converthtmltopdf.scm.azurewebsites.net/");
      client.DefaultRequestHeaders.Accept.Clear();
      var userName = "your userName";
      var password = "your userPWD ";
      var encoding = new ASCIIEncoding();
      var authHeader =
        new AuthenticationHeaderValue("Basic",
          Convert.ToBase64String(
          encoding.GetBytes(string.Format($"{userName}:{password}"))));
      client.DefaultRequestHeaders.Authorization = authHeader;
      var content = new System.Net.Http.StringContent("");
      string filename = Guid.NewGuid().ToString("N").Substring(0, 8) + ".pdf";
      HttpResponseMessage response =
        await client.PostAsync(
        $"api/triggeredwebjobs/convertToPDF/run?arguments={Url} 
          {filename}", content);
      if (!response.IsSuccessStatusCode)
      {
        return $"Conversion for {Url} {filename} failed: " +
          DateTime.Now.ToString();
      }
      return $"{response.StatusCode.ToString()}:
        your PDF can be downloaded from here:";
    }
  }
  catch (Exception ex)  {  return ex.Message;  } }

Utilizzare il metodo HttpClient della classe System.Net.Http.HttpClient per effettuare la richiesta. Usare quindi basato su server di gestione di controllo origine Azure App Service URL dell'App Web come proprietà BaseAddress per la richiesta. Come sapete, ogni servizio Web App di Azure include un URL di Gestione controllo servizi (noto anche come console KUDU) che è accessibile tramite https://{appname}.scm.azurewebsites.net ed è l'URL utilizzato per chiamare l'API di processo Web. Aggiunta di /basicAuth alla fine dell'URL consente al client chiamante per l'autenticazione tramite un handshake challenge-response base. Il nome utente e password sono le credenziali del profilo di pubblicazione, sono scaricabili dal portale di gestione di Azure passando a Azure App servizio Web App e selezionando Get del profilo di pubblicazione. All'interno di scaricato *. File di impostazioni di pubblicazione che sono disponibili il nome utente e userPWD da utilizzare nel codice. Per semplicità, ho hardcoded il nome utente e la password nell'applicazione, ma per reale questi dovrebbe essere inseriti in un luogo sicuro e recuperati dal codice, pertanto può essere modificati se lo si desidera, selezionare il profilo di pubblicazione Reimposta nel portale di gestione di Azure. Non si desidera distribuire codice aggiornato ogni volta che vengono apportate modifiche.

L'autenticazione di base, è necessario associare una stringa ASCII con codifica Base64 del nome utente e della password all'intestazione di base in questo formato: Nomeutente: password base. Dopo aver creato il valore dell'intestazione utilizzando il metodo ASCIIEncoding della classe System.TextASCIIEncoding, insieme al metodo ToBase64String della classe System. Convert, aggiungerlo a una nuova istanza della classe System.Net.Http.Headers.AuthenticationHeaderValue insieme al nome dell'intestazione di base. Utilizzare l'istanza della classe System.Net.Http.HttpClient creata nel usando istruzione per aggiungere il AuthenticationHeaderValue alla proprietà della classe System.Net.Http.Headers.HttpRequestHeaders DefaultRequestHeaders.Authorization.

Per il nome del file è stato usato otto caratteri di un GUID utilizzando il metodo della classe String, Substring, rimuovere i trattini dal GUID. Il GUID è stato creato utilizzando il metodo NewGuid della classe System. GUID, passando un parametro "N" per il metodo ToString della classe Guid. Infine, in modo asincrono inserite all'API di processo Web utilizzando il metodo PostAsync della classe System.Net.Http.HttpClient, passando l'URL e nome file come argomenti del processo Web e in attesa del relativo completamento. Quando il processo è stato completato, viene visualizzato l'URL per il contenitore di archiviazione di Azure con il nome del file concatenato alla console, in caso contrario, viene inviata una notifica che la creazione di PDF non è riuscito.

Per visualizzare lo stato del processo Web, passare al portale di gestione di Azure, passare all'App Azure applicazione servizio Web in esecuzione il processo Web, quindi selezionare impostazioni | Processi Web. Il pannello processi Web contiene nome, tipo, stato e un collegamento molto utile per i log di esecuzione processo Web. Fare clic sul collegamento per accedere alla console KUDU processo Web specifico per visualizzare le esecuzioni processo recenti, lo stato e un collegamento per l'output del log effettivo del processo Web, come illustrato nella Figura 8. Ad esempio, se il processo Web è un'applicazione console, quando si utilizza il metodo System.Console.WriteLine per scrivere lo stato dell'esecuzione nella finestra di output della console, queste informazioni viene scritto anche nel log di processo Web e visualizzabile tramite il collegamento dal portale di gestione di Azure.

Figura 8 Output processo Web Azure Log

Una volta questa parte è stata funziona come previsto, tutto ciò che è rimasto è sufficiente un semplice copiare e incollare nella soluzione di SignalR, discussa più avanti.

ASP.NET SignalR

ASP.NET SignalR è una libreria open source per gli sviluppatori ASP.NET facilitare l'invio di notifiche in tempo reale basato su browser, dispositivi mobili o le applicazioni client .NET. Il server client remote procedure call (RPC) viene utilizzato una API che chiama le funzioni JavaScript sul client dal codice .NET sul lato server. Prima l'esistenza di questa tecnologia, un approccio comune per ottenere una soluzione simile utilizzava un controllo UpdatePanel di ASP.NET che sarebbe frequente aggiornamento effettuando una richiesta al server per verificare se è stata apportata qualsiasi modifica nello stato dei dati. Questo è molto più un approccio PULL, in cui il client ha attivato la richiesta al server anziché dal server push di dati in tempo reale per il client non appena è diventato disponibile.

Il codice JavaScript lato client crea un'istanza di un proxy Hub, espone i metodi che il server può attivare e identifica il metodo sul lato server per la chiamata (trasmissione) quando un evento click generato:

var pdf = $.connection.pDFHub;
pdf.client.broadcastMessage = function (userId, message) {};
pdf.client.individualMessage = function (userId, message) {};
$('#sendmessage').click(function () {
  pdf.server.send($('#displayname').val(), $('#message').val());
});

Il nome del proxy Hub in JavaScript sul lato client è il nome dell'Hub creato per l'esecuzione sul lato server. In questo esempio, l'Hub è denominato PDFHub e eredita dalla classe Microsoft.AspNet.SignalR.Hub. I due metodi esposti dal client sono broadcastMessage e individualMessage; ognuno ha una funzione con parametri che corrisponde al modello del metodo Send sul lato server, userId e messaggio. Il metodo di invio viene chiamato nel server quando si fa clic sul pulsante Invia un visitatore nel sito Web. Il metodo ConvertToPDFWebJobAsync è una Taglia e Incolla di applicazione console creata nella sezione precedente che chiama l'API di processo Web Azure per convertire la pagina Web fornita in un file PDF e caricarla in un contenitore di archiviazione di Azure. Infine, il metodo Send sul lato server viene utilizzata un'istanza della proprietà Microsoft.AspNet.SignalR.Hub.Clients, che implementa l'interfaccia IHubCallerConnectionContext. La proprietà client è collegata ai due metodi sul lato client e fornisce le informazioni inviate dal server ai client appropriato (vedere Figura 9).

Figura 9 la classe PDFHub

public class PDFHub : Hub
{
  public void Send(string userId, string message)
  {
    string name = Context.User.Identity.Name;
    string convertMessage = "no message yet";           
    Task.Run(async () =>
    {
      convertMessage = await ConvertToPDFWebJobAPIAsync(message);
    }).Wait();
    Clients.All.broadcastMessage(userId, "just converted: " + message +
      " to a pdf");
    Clients.Client(Context.ConnectionId).individualMessage(
      name, convertMessage);
  }
}

È lecito chiedersi perché si è scelto di utilizzare l'API di processo Web Azure anziché solo una semplice applicazione di ASP.NET Web Form o Web MVC ASP.NET SignalR. È vero, esistono diversi modi per utilizzare un'API. Ad esempio, il codice scaricabile per questa soluzione contiene un'applicazione console che utilizza l'API di processo Web Azure, quindi, perché si utilizza SignalR?

Per rispondere a questa domanda, si noti che nel Figura 9 che, quando il server dispone di un messaggio per i client connessi, vengono richiamati due metodi sul lato client. In primo luogo, il metodo broadcastMessage notifica a tutti i client connessi che una persona specifica convertito un URL specifico in un file PDF, ma non fornisce il collegamento per il contenitore di archiviazione di Azure e il file PDF per il download. Il secondo metodo sul lato client è individualMessage, che invia lo stato del linguaggio HTML per la conversione in PDF e il collegamento al contenitore di archiviazione di Azure con il nome del file PDF concatenati. Il motivo per l'utilizzo di SignalR è per i client consumer un'idea di interazione tramite social networking, fornendo tutti i client connessi informazioni su ciò che avviene nel sito Web di servizio App di Azure.

Tenere presente che in precedenza è indicata la System.Security.Principle.IPrinciple.Identity.Name e indicato come rendere l'app Web molto più semplice perché potrebbe rendere il nome del visitatore al client anziché, ad esempio, un ID di connessione univoco ma generico. La proprietà Identity.Name viene utilizzata per impostare il nome del visitatore, convalidato dal proprio Account Microsoft, che aggiunge il social altrettanto del client.

Ora tutto ciò che deve verificarsi consiste nel distribuire il codice (codice client, il codice lato server e processo Web Azure) per la piattaforma Azure del servizio App Web tramite Visual Studio o un'applicazione FTP e testarlo. Istruzioni dettagliate su come distribuire un servizio Web App di Azure sono reperibile in bit.ly/1nXnhmB.

SaaS (Software as a Service)

Durante la scrittura di questo articolo ho iniziato a pensare Software come servizio (SaaS) e se il convertitore HTML in PDF in tempo reale è una soluzione SaaS o semplicemente un'app API accessibili in esecuzione nel cloud. Ho deciso che l'esposizione di API di processo Web di Azure, in base al nome stesso, rende un'API e non SaaS. Per la soluzione, l'API di processo Web viene esposto tramite un URL e protette dall'autenticazione di base. L'API è disponibile per altri consumer per compilare su di essa o per aggiungere funzionalità alle applicazioni, che costituisce la definizione di un'API. Tuttavia, non appena si verifica un consumer per l'API, vengono aggiunte funzionalità aggiuntive per l'API utilizzata che può essere utilizzato da più utenti in linea, in modo che corrisponda la definizione di SaaS. Pertanto, l'API di processo Web Azure da solo è semplicemente un'API, mentre il client di ASP.NET SignalR in esecuzione sulla piattaforma Azure applicazione servizio Web App è una soluzione SaaS. Che non è OneDrive, Office 365, Dynamics CRM Online o Hotmail, ma se è necessario convertire un sito Web in un file PDF molto rapido, si sa dove a venire.

Conclusioni

In questo articolo sono stati illustrati tre funzionalità di Azure: un'App Web di Azure App Service; Autenticazione e autorizzazione, servizio di Azure e un account di archiviazione di Azure e contenitore. Queste funzionalità sono la piattaforma che supporta il processo Web Azure, esporre l'API di processo Web Azure e ospitare il consumer di ASP.NET SignalR basati su browser. Ho parlato di ognuna delle funzionalità e i passaggi necessari per configurarli. Descritto anche il codice per il processo Web Azure, il codice per chiamare l'API di processo Web Azure e il client di ASP.NET SignalR.

Benjamin Perkinsè un'escalation engineer presso Microsoft e autore di quattro libri su c#, IIS, NHibernate e Microsoft Azure. È coautore di recente inizio c# 6 programmazione con Visual Studio 2015 (John Wiley & Sons). Contattarlo all'indirizzo benperk@microsoft.com.

Grazie all'esperto tecnico Microsoft seguente per la revisione di questo articolo: Richard Marr
Richard Marr è un Senior Escalation Engineer presso Microsoft. Ha lavorato in organizzazioni di supporto Microsoft per 16 anni, supporto di IIS, ASP.Net e attualmente con servizi App di Azure.