Anatomia bota

W poprzednim wpisie pokazałem jak wygląda utworzenie naszego pierwszego bota. Poznałeś, że nie jest on taki mądry jakby się mogło wydawać. Ale zanim tchniemy w niego choć trochę inteligencji, musimy poznać co siedzi „pod maską”. Przejdźmy więc do anatomii naszego bota.
W solution explorerze mamy 3 foldery:

• App_Start
• Controllers
• Dialogs.

App_Start

Pierwszy z wymienionych na nawę mówiącą sama za siebie. Klasa z tego folderu zawierają konfigurację bota a jej metoda odpalana jest na początku działania naszej aplikacji. Nazwa tej klasy WebApiConfig mówi nam jakiego typu jest to projekt. Bo bot to nic innego jak Web API w trochę zmodyfikowanej formie. Mamy tutaj konfigurację serializatora do JSONów, oraz co ważniejsze takie linijki:

// Web API routes
config.MapHttpAttributeRoutes();

config.Routes.MapHttpRoute(
     name: "DefaultApi",
     routeTemplate: "api/{controller}/{id}",
     defaults: new { id = RouteParameter.Optional }
     );

Jeżeli pracowałeś kiedykolwiek z projektem Web API to pewnie są Ci znajome. Definiują one ścieżkę dostępu do poszczególnych kontrolerów naszej aplikacji (w tym przypadku bota). To właśnie dzięki temu zapisowi, bot wiedział gdzie zapukać gdy pisaliśmy wiadomości na adres: http://localhost:/api/messages. Ale gdzie to jest w kodzie?

Controllers

Tutaj wchodzi do gry MessagesController. Do niego trafiają wszystkie wiadomości wysyłane do naszego bota. A dokładniej trafiają do metody Post. Tutaj małe wyjaśnienie. Wszystkie wiadomości wysłane do bota są właśnie typu HTTP POST. Z tego wyłania się obraz, że Microsoft Bot Framework to nic innego jak tylko nakładka na zwykłe Web API.
W metodzie Post wykrywane jest czy wiadomość jest „zwykłą” wiadomością1 czy Aktywnością2 systemową. Aktywności systemowe obsługiwane są przez metodę HandleSystemMessage. Na nich jednak nie będziemy się dzisiaj skupiać. To kiedy występują jest dosyć dobrze wytłumaczone komentarzami.

Metoda:

await Conversation.SendAsync(activity, () => new Dialogs.RootDialog());

przekazuje wiadomość odebraną przez bota do RootDialog-a, do którego przejdziemy zaraz.
Ostatnia rzecz, która dzieje się w tej metodzie, to zgłoszenie poprawnego odebrania wiadomości poprzez wysłanie kodu 200 – HTTP OK.

Dialogi

Przechodząc do Dialog-ów, czyli folderu Dialogs. Mamy w nim jedną klasę: RootDialog zawierającą dwie metody. Pierwsza z nich StartAsync czeka na wysłanie wiadomości przez użytkownika i przekazuje ją do metody MessageReceivedAsync. Wszystko co zostało nam zwrócone zadziało się w tym miejscu. Przechodząc więc po kolei. activity jest to wiadomość wysłana przez użytkownika. Zmienna length zawiera długość wpisanego przez użytkownika tekstu 3. Jeżeli zapis w tej linii wydaje Ci się dziwny odsyłam do MSDNa. To co ciekawsze w kontekście bota to wysyłanie wiadomości zwrotnej do użytkownika. Za to odpowiada linijka:

await context.PostAsync($"You sent {activity.Text} which was {length} characters");

Wysyła ona wiadomość asynchronicznie do użytkownika. Następnie metoda czeka na następną wiadomość od użytkownika za sprawą:

context.Wait(MessageReceivedAsync);

To tyle. Okazuje się, że boty to wcale nie tak skomplikowany temat (przynajmniej na tym etapie). Zachęcam do własnego eksperymentowania z tą technologią. A już od następnego wpisu pokażę jak tchnąć trochę inteligencji w naszego bota. Sam nie mogę się doczekać, więc stay tuned!