Wskazówki dotyczące architektury powiadomień wypychanych w przedsiębiorstwie

  • Artykuł

Obecnie przedsiębiorstwa stopniowo przechodzą w kierunku tworzenia aplikacji mobilnych dla użytkowników końcowych (zewnętrznych) lub pracowników (wewnętrznych). Mają istniejące systemy zaplecza, czyli komputery mainframe lub niektóre aplikacje loB, które muszą zostać zintegrowane z architekturą aplikacji mobilnych. W tym przewodniku omówiono, jak najlepiej wykonać tę integrację, zalecając możliwe rozwiązanie typowych scenariuszy.

Częstym wymaganiem jest wysyłanie powiadomień wypychanych do użytkowników za pośrednictwem aplikacji mobilnej, gdy w systemach zaplecza występuje zdarzenie zainteresowania. Na przykład klient bankowy, który ma aplikację bankową na urządzeniu i Telefon chce zostać powiadomiony, gdy zapłata jest wyższa niż określona kwota z konta lub intranetowego scenariusza, w którym pracownik działu finansowego, który ma aplikację zatwierdzania budżetu w systemie Windows Telefon chce zostać powiadomiony, gdy żądanie zatwierdzenia zostanie odebrane.

Przetwarzanie konta bankowego lub zatwierdzania prawdopodobnie zostanie przeprowadzone w niektórych systemach zaplecza, co wymaga zainicjowania wypychania do użytkownika. Może istnieć wiele takich systemów zaplecza, które muszą utworzyć ten sam rodzaj logiki, aby wypchnąć, gdy zdarzenie wyzwoli powiadomienie. Złożoność polega na zintegrowaniu kilku systemów zaplecza z jednym systemem wypychania, w którym użytkownicy końcowi mogli subskrybować różne powiadomienia, a nawet wiele aplikacji mobilnych. Na przykład intranetowe aplikacje mobilne, w których jedna aplikacja mobilna może chcieć otrzymywać powiadomienia z wielu takich systemów zaplecza. Systemy zaplecza nie wiedzą ani nie muszą wiedzieć o semantyce wypychania/technologii, więc typowym rozwiązaniem w tym miejscu tradycyjnie było wprowadzenie składnika, który sonduje systemy zaplecza pod kątem jakichkolwiek interesujących zdarzeń i jest odpowiedzialny za wysyłanie komunikatów wypychanych do klienta.

Lepszym rozwiązaniem jest użycie usługi Azure Service Bus — model tematu/subskrypcji, co zmniejsza złożoność przy jednoczesnym dokonaniu skalowalności rozwiązania.

Oto ogólna architektura rozwiązania (uogólniona z wieloma aplikacjami mobilnymi, ale równie odpowiednia, gdy istnieje tylko jedna aplikacja mobilna)

Architektura

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

Kluczowym elementem tego diagramu architektury jest usługa Azure Service Bus, która udostępnia model programowania tematów/subskrypcji (więcej informacji na ten temat można znaleźć w temacie Service Bus Pub/Sub programming). Odbiornik, który w tym przypadku, jest zapleczem mobilnym (zazwyczaj Azure Mobile Service, który inicjuje wypychanie do aplikacji mobilnych) nie odbiera komunikatów bezpośrednio z systemów zaplecza, ale zamiast tego pośredniej warstwy abstrakcji zapewnianej przez usługę Azure Service Bus, która umożliwia zapleczu mobilnemu odbieranie komunikatów z co najmniej jednego systemu zaplecza. Temat usługi Service Bus należy utworzyć dla każdego z systemów zaplecza, na przykład Account, HR, Finance, który jest w zasadzie "tematem" zainteresowania, co inicjuje wysyłanie komunikatów jako powiadomienie wypychane. Systemy zaplecza wysyłają komunikaty do tych tematów. Zaplecze mobilne może subskrybować co najmniej jeden z takich tematów, tworząc subskrypcję usługi Service Bus. Umożliwia ona zapleczu mobilnemu odbieranie powiadomienia z odpowiedniego systemu zaplecza. Zaplecze mobilne nadal nasłuchuje komunikatów w swoich subskrypcjach i gdy tylko pojawi się komunikat, cofa się i wysyła je jako powiadomienie do centrum powiadomień. Następnie centra powiadomień ostatecznie dostarczają komunikat do aplikacji mobilnej. Oto lista kluczowych składników:

  1. Systemy zaplecza (systemy LoB/Legacy)
    • Tworzy temat usługi Service Bus
    • Wysyła wiadomość
  2. Zaplecze mobilne
    • Tworzy subskrypcję usługi
    • Odbiera komunikat (z systemu zaplecza)
    • Wysyła powiadomienia do klientów (za pośrednictwem usługi Azure Notification Hub)
  3. Aplikacja mobilna
    • Odbiera i wyświetla powiadomienie

Świadczenia

  1. Rozdzielenie między odbiornikiem (aplikacją mobilną/usługą za pośrednictwem centrum powiadomień) i nadawcą (systemami zaplecza) umożliwia zintegrowanie dodatkowych systemów zaplecza z minimalną zmianą.
  2. Dzięki temu scenariusz wielu aplikacji mobilnych może odbierać zdarzenia z co najmniej jednego systemu zaplecza.

Przykład

Wymagania wstępne

Wykonaj poniższe samouczki, aby zapoznać się z pojęciami, a także typowymi krokami tworzenia i konfiguracji:

  1. Programowanie pub/sub usługi Service Bus — w tym samouczku wyjaśniono szczegóły pracy z tematami/subskrypcjami usługi Service Bus, jak utworzyć przestrzeń nazw zawierającą tematy/subskrypcje, jak wysyłać i odbierać komunikaty z nich.
  2. Usługa Notification Hubs — samouczek uniwersalny systemu Windows — w tym samouczku wyjaśniono, jak skonfigurować aplikację ze Sklepu Windows i używać usługi Notification Hubs do rejestrowania, a następnie odbierania powiadomień.

Przykładowy kod

Pełny przykładowy kod jest dostępny w sekcji Przykłady usługi Notification Hub. Jest on podzielony na trzy składniki:

  1. EnterprisePushBackendSystem

    a. Ten projekt używa pakietu NuGet Azure.Messaging.ServiceBus i jest oparty na programowaniu Pub/Sub usługi Service Bus.

    b. Ta aplikacja to prosta aplikacja konsolowa w języku C#, która symuluje system LoB, który inicjuje komunikat, który ma zostać dostarczony do aplikacji mobilnej.

    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 Służy do tworzenia tematu usługi Service Bus.

    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 służy do wysyłania komunikatów do tego tematu usługi Service Bus. Ten kod po prostu wysyła zestaw losowych komunikatów do tematu okresowo na potrzeby przykładu. Zwykle istnieje system zaplecza, który wysyła komunikaty po wystąpieniu zdarzenia.

    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. Ten projekt używa pakietów NuGet Azure.Messaging.ServiceBus i Microsoft.Web.WebJobs.Publish i jest oparty na programowaniu Pub/Sub usługi Service Bus.

    b. Następująca aplikacja konsolowa jest uruchamiana jako zadanie WebJob platformy Azure, ponieważ musi ona stale nasłuchiwać komunikatów z systemów loB/zaplecza. Ta aplikacja jest częścią zaplecza mobilnego.

    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 Służy do tworzenia subskrypcji usługi Service Bus dla tematu, w którym system zaplecza wysyła komunikaty. W zależności od scenariusza biznesowego ten składnik tworzy co najmniej jedną subskrypcję do odpowiednich tematów (na przykład niektóre mogą odbierać komunikaty z systemu kadr, niektóre z systemu finansowego itd.)

    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 Służy do odczytywania komunikatu z tematu przy użyciu jego subskrypcji, a jeśli odczyt zakończy się pomyślnie, utwórz powiadomienie (w przykładowym scenariuszu powiadomienie wyskakujące systemu Windows natywne powiadomienie) do wysłania do aplikacji mobilnej przy użyciu usługi Azure Notification Hubs.

    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. Aby opublikować tę aplikację jako zadania WebJob, kliknij prawym przyciskiem myszy rozwiązanie w programie Visual Studio i wybierz polecenie Publikuj jako zadania WebJob

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

    f. Wybierz profil publikowania i utwórz nową witrynę Azure WebSite, jeśli jeszcze nie istnieje, która hostuje to polecenie WebJob, a następnie po utworzeniu witryny WebSite opublikuj.

    Screenshot showing the workflow to create a site on Azure.

    g. Skonfiguruj zadanie tak, aby było uruchamiane w sposób ciągły, aby po zalogowaniu się do witryny Azure Portal zobaczyć coś podobnego do następującego:

    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. Ta aplikacja jest aplikacją ze Sklepu Windows, która odbiera wyskakujące powiadomienia z zadania WebJob uruchomionego w ramach zaplecza mobilnego i wyświetla je. Ten kod jest oparty na usłudze Notification Hubs — uniwersalny samouczek systemu Windows.

    b. Upewnij się, że aplikacja jest włączona do odbierania wyskakujących powiadomień.

    c. Upewnij się, że następujący kod rejestracji usługi Notification Hubs jest wywoływany podczas uruchamiania aplikacji (po zastąpieniu HubName wartości i DefaultListenSharedAccessSignature :

    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();
    }
}

Uruchamianie przykładowej aplikacji

  1. Upewnij się, że zadanie WebJob jest uruchomione pomyślnie i zaplanowane do ciągłego uruchamiania.

  2. Uruchom aplikację EnterprisePushMobileApp, która uruchamia aplikację ze Sklepu Windows.

  3. Uruchom aplikację konsolową EnterprisePushBackendSystem , która symuluje zaplecze loB i rozpoczyna wysyłanie komunikatów, a powiadomienia wyskakujące powinny być wyświetlane jak na poniższej ilustracji:

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

  4. Komunikaty zostały pierwotnie wysłane do tematów usługi Service Bus, które były monitorowane przez subskrypcje usługi Service Bus w zadaniu sieci Web. Po odebraniu wiadomości powiadomienie zostało utworzone i wysłane do aplikacji mobilnej. Możesz przejrzeć dzienniki zadania WebJob, aby potwierdzić przetwarzanie po przejściu do linku Dzienniki w witrynie Azure Portal dla zadania internetowego:

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