Guida all'architettura push aziendale

  • Articolo

Al giorno d'oggi, le aziende stanno gradualmente passando alla creazione di applicazioni per dispositivi mobili sia per gli utenti finali (esterni) che per i dipendenti (interni). Le aziende dispongono di sistemi back-end già esistenti, ovvero mainframe o applicazioni LoB che è necessario integrare nell'architettura delle applicazioni per dispositivi mobili. In questa Guida verrà illustrato come eseguire questa integrazione nel modo migliore possibile, fornendo possibili soluzioni per scenari comuni.

Una richiesta frequente riguarda l'invio di notifiche push agli utenti tramite l'applicazione per dispositivi mobili in uso quando si verifica un evento di interesse nei sistemi back-end. Ad esempio, un cliente bancario che dispone dell'app bancaria della banca su un i Telefono vuole ricevere una notifica quando viene effettuato un addebito al di sopra di un determinato importo del conto o uno scenario Intranet in cui un dipendente del reparto finanziario che ha un'app di approvazione del budget in un windows Telefono vuole ricevere una notifica quando viene ricevuta la richiesta di approvazione.

È probabile che l'elaborazione del conto o dell'approvazione venga eseguita in un qualche sistema back-end che deve avviare un'operazione push verso l'utente. È possibile che siano presenti diversi sistemi back-end che devono eseguire la stessa tipologia di logica per eseguire un push quando un evento attiva una notifica. In questo caso la complessità è dovuta alla necessità di integrare numerosi back-end con un singolo sistema di push, dove gli utenti finali possono aver eseguito la sottoscrizione a diverse notifiche e dove possono essere usate più applicazioni mobili. Ad esempio, applicazioni per dispositivi mobili intranet che possono ricevere notifiche da diversi sistemi back-end. I sistemi back-end non conoscono o non hanno necessità di conoscere la semantica e/o la tecnologia di push. Per questo motivo, una soluzione comunemente usata fino ad ora consiste nell'introdurre un componente che esegue il polling dei sistemi back-end per qualsiasi evento di interesse ed è responsabile dell'invio di messaggi push al client.

Una soluzione migliore consiste nell'uso del modello Bus di servizio di Azure - Argomento/Sottoscrizione. Tale modello, infatti, riduce la complessità della soluzione e la rende scalabile.

Di seguito è descritta l'architettura generale della soluzione, descritta con numerose app per dispositivi mobili ma ugualmente applicabile nel caso in cui ne venga usata una soltanto.

Architettura

Diagram of the enterprise architecture showing the flow through Events, Subscriptions, and Push Messages.

L'elemento chiave di questo diagramma dell'architettura è il bus di servizio di Azure, che fornisce un modello di programmazione di tipo argomenti/sottoscrizioni. Per altre informazioni su tale modello, vedere Come usare gli argomenti e le sottoscrizioni del bus di servizio. Il ricevitore, in questo caso il back-end per dispositivi mobili (in genere Servizi mobili di Azure, che avvia un'operazione push alle app per dispositivi mobili), non riceve messaggi direttamente dai sistemi back-end. È disponibile invece un livello di astrazione intermedio fornito dal bus di servizio di Azure che consente al back-end per dispositivi mobili di ricevere messaggi da uno o più sistemi back-end. È necessario creare un argomento del bus di servizio per ciascuno dei sistemi back-end, ad esempio Contabilità, Risorse umane e Finanza. Si tratta fondamentalmente di "argomenti" rilevanti che danno luogo a messaggi da inviare come notifiche push. I sistemi back-end inviano messaggi a questi argomenti. Un back-end Mobile può sottoscrivere uno o più di tali argomenti creando una sottoscrizione del bus di servizio. Questo autorizza il back-end Mobile a ricevere una notifica dal sistema back-end corrispondente. Il back-end Mobile continua a rimanere in ascolto per rilevare i messaggi inviati alla sottoscrizione e, non appena ne arriva uno, lo invia come notifica all'hub di notifica. L'hub di notifica invia infine il messaggio all'app per dispositivi mobili. Ecco l'elenco dei componenti principali:

  1. Sistemi back-end (sistemi loB/legacy)
    • Crea un argomento del bus di servizio
    • Invia un messaggio
  2. Back-end per dispositivi mobili
    • Crea una sottoscrizione al servizio
    • Riceve un messaggio (dal sistema back-end)
    • Invia la notifica al client (tramite Hub di notifica di Azure)
  3. Applicazione per dispositivi mobili
    • Riceve e visualizza la notifica

Vantaggi

  1. Il disaccoppiamento tra il ricevitore (app/servizio per dispositivi mobili tramite Hub di notifica) e il mittente(sistemi back-end) consente l'integrazione di sistemi back-end aggiuntivi con modifiche minime.
  2. Questo consente di ricevere eventi da uno o più sistemi back-end anche nello scenario con più app per dispositivi mobili.

Esempio

Prerequisiti

Completare le seguenti esercitazioni per acquisire familiarità con i concetti e con i comuni passaggi di creazione e configurazione:

  1. Come usare gli argomenti e le sottoscrizioni del bus di servizio: questa esercitazione illustra nei dettagli l'utilizzo di argomenti/sottoscrizioni del bus di servizio. Viene inoltre mostrato come creare uno spazio dei nomi per contenere argomenti/sottoscrizioni e come inviare e ricevere messaggi da questi ultimi.
  2. Introduzione ad Hub di notifica : questa esercitazione illustra come configurare un'app di Windows Store e usare Hub di notifica per registrare e quindi ricevere le notifiche.

Codice di esempio

Il codice completo è disponibile nella pagina relativa agli esempi di Hub di notifica. Il codice è suddiviso in tre componenti:

  1. EnterprisePushBackendSystem

    a. Questo progetto usa il pacchetto NuGet Azure.Messaging.ServiceBus ed è basato su bus di servizio programmazione Pub/Sub.

    b. Questa applicazione è una app console C# per simulare un sistema LoB che avvia il messaggio da recapitare all'app per dispositivi mobili.

    static async Task Main(string[] args)
{
    string connectionString =
        ConfigurationManager.AppSettings.Get("Azure.ServiceBus.ConnectionString");

    // Create the topic
    await CreateTopicAsync(connectionString);

    // Send message
    await SendMessageAsync(connectionString);
}

    c. CreateTopicAsync viene usato per creare un argomento del bus di servizio.

    public static async Task CreateTopicAsync(string connectionString)
{
    // Create the topic if it does not exist already
    ServiceBusAdministrationClient client = new ServiceBusAdministrationClient(connectionString);

    if (!await client.TopicExistsAsync(topicName))
    {
        await client.CreateTopicAsync(topicName);
    }
}

    d. SendMessageAsync viene usato per inviare i messaggi a questo argomento del bus di servizio. Questo codice invia semplicemente, a cadenza periodica, un insieme di messaggi casuali all'argomento. Nella realtà, è presente un sistema back-end che invia i messaggi quando si verifica un evento.

    public static sync Task SendMessageAsync(string connectionString)
{
    await using var client = new ServiceBusClient(connectionString);
    ServiceBusSender sender = client.CreateSender(topicName);

    // Sends random messages every 10 seconds to the topic
    string[] messages =
    {
        "Employee Id '{0}' has joined.",
        "Employee Id '{0}' has left.",
        "Employee Id '{0}' has switched to a different team."
    };

    while (true)
    {
        Random rnd = new Random();
        string employeeId = rnd.Next(10000, 99999).ToString();
        string notification = String.Format(messages[rnd.Next(0,messages.Length)], employeeId);

        // Send Notification
        ServiceBusMessage message = new ServiceBusMessage(notification);
        await sender.SendMessageAsync(message);

        Console.WriteLine("{0} Message sent - '{1}'", DateTime.Now, notification);

        System.Threading.Thread.Sleep(new TimeSpan(0, 0, 10));
    }
}

  2. ReceiveAndSendNotification

    a. Questo progetto usa i pacchetti NuGet Azure.Messaging.ServiceBus e Microsoft.Web.WebJobs.Publish ed è basato su bus di servizio programmazione Pub/Sub.

    b. L'app console seguente viene eseguita come processo Web di Azure. Questa app deve infatti essere eseguita continuamente per ascoltare i messaggi dei sistemi LOB/back-end. Questa applicazione fa parte del back-end per dispositivi mobili.

    static async Task Main(string[] args)
{
    string connectionString =
             ConfigurationManager.AppSettings.Get("Azure.ServiceBus.ConnectionString");

    // Create the subscription that receives messages
    await CreateSubscriptionAsync(connectionString);

    // Receive message
    await ReceiveMessageAndSendNotificationAsync(connectionString);
}

    c. CreateSubscriptionAsync viene usato per creare una sottoscrizione del bus di servizio per l'argomento in cui il sistema back-end invia i messaggi. A seconda dello scenario aziendale, questo argomento crea una o più sottoscrizioni agli argomenti corrispondenti. Può, ad esempio, ricevere messaggi dal sistema Risorse umane, dal sistema Finanza e così via.

    static async Task CreateSubscriptionAsync(string connectionString)
{
    // Create the subscription if it does not exist already
    ServiceBusAdministrationClient client = new ServiceBusAdministrationClient(connectionString);

    if (!await client.SubscriptionExistsAsync(topicName, subscriptionName))
    {
        await client.CreateSubscriptionAsync(topicName, subscriptionName);
    }
}

    d. ReceiveMessageAndSendNotificationAsync viene usato per leggere il messaggio inviato dall'argomento usando la relativa sottoscrizione. Se l'operazione di lettura ha esito positivo, viene creata una notifica (nello scenario di esempio una notifica di tipo avviso popup nativo di Windows) da inviare all'applicazione per dispositivi mobili usando Hub di notifica di Azure.

    static async Task ReceiveMessageAndSendNotificationAsync(string connectionString)
{
    // Initialize the Notification Hub
    string hubConnectionString = ConfigurationManager.AppSettings.Get
            ("Microsoft.NotificationHub.ConnectionString");
    hub = NotificationHubClient.CreateClientFromConnectionString
            (hubConnectionString, "enterprisepushservicehub");

    ServiceBusClient Client = new ServiceBusClient(connectionString);
    ServiceBusReceiver receiver = Client.CreateReceiver(topicName, subscriptionName);

    // Continuously process messages received from the subscription
    while (true)
    {
        ServiceBusReceivedMessage message = await receiver.ReceiveMessageAsync();
        var toastMessage = @"<toast><visual><binding template=""ToastText01""><text id=""1"">{messagepayload}</text></binding></visual></toast>";

        if (message != null)
        {
            try
            {
                Console.WriteLine(message.MessageId);
                Console.WriteLine(message.SequenceNumber);
                string messageBody = message.Body.ToString();
                Console.WriteLine("Body: " + messageBody + "\n");

                toastMessage = toastMessage.Replace("{messagepayload}", messageBody);
                SendNotificationAsync(toastMessage);

                // Remove message from subscription
                await receiver.CompleteMessageAsync(message);
            }
            catch (Exception)
            {
                // Indicate a problem, unlock message in subscription
                await receiver.AbandonMessageAsync(message);
            }
        }
    }
}
static async void SendNotificationAsync(string message)
{
    await hub.SendWindowsNativeNotificationAsync(message);
}

    e. Per pubblicare quest'app come processo Web, in Visual Studio fare clic con il pulsante destro del mouse sulla soluzione e selezionare Pubblica come processo Web di Azure

    Screenshot of the right-click options being displayed with Publish as Azure WebJob outlined in red.

    f. Selezionare il proprio profilo di pubblicazione e, se non è già presente, creare un nuovo sito Web di Azure che ospita questo processo Web, quindi fare clic su Pubblica.

    Screenshot showing the workflow to create a site on Azure.

    g. Configurare il processo per l'esecuzione continua, in modo che, quando si accede al portale di Azure, venga visualizzata una schermata simile alla seguente:

    Screenshot of the Azure Portal with the enterprise push backend webjobs displayed and the Name, Schedule, and Logs values outlined in red.

  3. EnterprisePushMobileApp

    a. Questa applicazione è un'applicazione Windows Store che riceve notifiche di tipo avviso popup dal processo Web in esecuzione come parte del back-end Mobile e le visualizza. Questo codice si basa su quanto riportato in Introduzione ad Hub di notifica - Esercitazione per Windows Universal.

    b. Verificare che l'applicazione sia abilitata alla ricezione di notifiche di tipo avviso popup.

    c. Assicurarsi che all'avvio dell'app, dopo aver sostituito HubName e DefaultListenSharedAccessSignature, venga chiamato il seguente codice di registrazione di Hub di notifica:

    private async void InitNotificationsAsync()
{
    var channel = await PushNotificationChannelManager.CreatePushNotificationChannelForApplicationAsync();

    var hub = new NotificationHub("[HubName]", "[DefaultListenSharedAccessSignature]");
    var result = await hub.RegisterNativeAsync(channel.Uri);

    // Displays the registration ID so you know it was successful
    if (result.RegistrationId != null)
    {
        var dialog = new MessageDialog("Registration successful: " + result.RegistrationId);
        dialog.Commands.Add(new UICommand("OK"));
        await dialog.ShowAsync();
    }
}

Esecuzione dell'esempio

  1. Assicurarsi che il processo Web venga eseguito correttamente e che sia pianificato per l'esecuzione continua.

  2. Eseguire EnterprisePushMobileApp, che avvia l'app di Windows Store.

  3. Eseguire l'applicazione console EnterprisePushBackendSystem che simula il back-end LOB e avvia l'invio di messaggi. Verranno visualizzate notifiche di tipo avviso popup simili all'immagine seguente:

    Screenshot of a console running the Enterprise Push Backend System app and the message that is sent by the app.

  4. All'inizio i messaggi sono stati inviati ad argomenti del bus di servizio, operazione monitorata da sottoscrizioni del bus di servizio nel processo Web. Una volta ricevuto un messaggio, è stata creata una notifica che è stata inviata all'app per dispositivi mobili. Per confermare l'elaborazione, è possibile esaminare i log del processo Web quando si accede al collegamento Log relativo al processo Web nel portale di Azure:

    Screenshot of the Continuous WebJob Details dialog box with the message that is sent outlined in red.