Przejdź do treści

Szybki start

Głównym założeniem dla środowiska deweloperskiego jest prostota uruchomienia, dlatego podstawowa konfiguracja opiera się o zasadę zero-conf, czyli deweloper nie musi nic konfigurować, a mechanizmy będą działać w konfiguracji domyślnej. Dla EDA oznacza to uruchomienie wraz z neosem instancji serwera bazodanowego Postgres i szyny wymiany komunikatów in-memory.

Uwaga!

W celu wykorzystania EDA w środowiskach produkcyjnych zalecamy zapoznanie się z zaawansowaną konfiguracją.

Uwaga!

Domyślna konfiguracja warstwy persystencji EDA nie jest zalecana dla środowisk produkcyjnych. Więcej o poprawnej i bezpiecznej konfiguracji środowiska produkcyjnego znajdziesz tutaj.

Uruchomienie krok po kroku

  1. Pobieramy wyemitowane pliki binarne serwera Neos w wersji min. 5.4 (X:\DBR\release\neos).
  2. Konfigurujemy plik smd zgodnie z potrzebami (ścieżka bazy esystem, porty usług, itp.).
  3. Uruchamiamy serwer.
  4. W logach przy starcie serwera powinien pojawić się wpis informujący o uruchomieniu wbudowanej bazy danych dla mechanizmów EDA: Embedded PostgreSQL instance is running on: {Host}:{Port}.

Pierwsza komenda

  1. W edytorze kodu Neos Experta wybieramy z menu, w kontekście interfejsu, akcję EDA > Dodaj komendę (command)

Nowa komenda

  1. Zostanie utworzony szablon kodu komendy.

Definicja komendy

W treści komendy definiujemy własności, które będą niosły dodatkowe informacje do wykorzystania przez metodę obsługującą.

public class ExampleCommand : NeosCommand
{
   public string Message
   {
      get;
      set;
   }
}

Obsługa reakcji na komendę

  1. W edytorze kodu Neos Experta wybieramy z menu, w kontekście logiki biznesowej, akcję EDA > Dodaj metodę obsługującą komendę (command)

Handler komendy

  1. Pojawi się okno, w którym należy wybrać typ komendy na jaki ma reagować tworzony handler i opcjonalnie zmienić sugerowaną nazwę.

wybór obsługiwanej komendy

  1. Zostanie utworzony szablon metody handlera. Na razie nic tutaj nie zmieniamy, metoda będzie tylko odbierać komendy, ale nie będzie wykonywać żadnych operacji poza zgłoszeniem, że komunikat został przetworzony.
public HandlerResult ExampleCommandHandler(ConsumeContext<EDACONF.ExampleCommand> context)
{
  return HandlerResult.Handled;
}

Zgłoszenie komendy do wykonania

Tip

Pełną nazwę handlera można zastąpić z pomocą mechanizmu konektorów.

  1. Aby zobaczyć czy mechanizm działa musimy wysłać zdefiniowaną komendę do przetworzenia.
  2. Dla przykładu tworzymy metodę statyczną RunExample
  3. Powołujemy instancję obiektu komendy ExampleCommand i uzupełniamy jej własności.
  4. Wysyłamy tak utworzoną komendę do przetworzenia za pomocą metody API EDA.SendCommand, której oprócz komendy podajemy nazwę handlera, który ma odpowiadać za jej przetworzenie. Nazwa składa się z nazwy projektu, nazwy obiektu i nazwy metody obsługującej.
public static void RunExample()
{
  var command = new ExampleCommand()
  {
    Message = "Hello World"
  };

  EDA.SendCommand("EDACONF.EXAMPLE.ExampleCommandHandler", command);
}
  1. Po uruchomieniu metody możemy zweryfikować działanie mechanizmu EDA.

Monitorowanie

  1. Z menu Administracja uruchamiamy Monitor EDA.
  2. Jeśli poprawnie wysłaliśmy wcześniej utworzoną komendę to pojawi się o tym informacja w głównym oknie monitora.

Monitor EDA

  1. Podwójne kliknięcie pozwala na otworzenie szczegółów dialogu, którego częścią był wybrany komunikat. Pozwala to na prześledzenie kontekstu w jakim komunikaty były przetwarzane, tzn. co zapoczątkowało dany proces, jakie komendy i zdarzenia się pojawiały.

Lista zdarzeń

Pierwsze zdarzenie

  1. Podobnie jak przy tworzeniu komendy, ale tym razem wybieramy akcję Dodaj zdarzenie (event)

Nowe zdarzenie

  1. Powstanie tym razem szablon dla zdarzenia.

Definicja zdarzenia

Podobnie jak wcześniej deklarujemy własności do przechowania dodatkowych informacji dla handlera.

public class ExampleEvent : NeosEvent
{
   public string Message
   {
      get;
      set;
   }
}

Obsługa reakcji na zdarzenie

Analogicznie jak obsługa reakcji na komendę.

Zgłoszenie zdarzenia w systemie

Uwaga!

Zdarzenia można zgłaszać podobnie jak komendy, bezkontekstowo, za pomocą metody EDA.RaiseEvent jednak jest to niezalecane i powinny być wywoływane z kontekstem jak w przykładzie poniżej.

  1. W celu wywołania zdarzenia zmodyfikujemy metodę handlera utworzoną wcześniej. Symuluje to sytuację, gdzie zdarzenie powstało w wyniku przetwarzania komendy. Do zgłoszenia zdarzenia używamy metody API EDA.RaiseEvent, której przekazujemy nasz aktualny kontekst przetwarzania w celu zachowania informacji o dialogu, w którym biorą udział zgłaszane komunikaty.
public HandlerResult ExampleCommandHandler(ConsumeContext<EDACONF.ExampleCommand> context)
{
  var receivedCommand = new ExampleEvent()
  {
    Message = "Otrzymano komunikat: " + context.Message.Message
  };

  EDA.RaiseEvent(receivedCommand, context);

  return HandlerResult.Handled;
}
  1. Działanie możemy zweryfikować przez uruchomienie metody ExampleRun bez dodatkowych modyfikacji.
  2. Oczekujemy, że wywołanie metody utworzy komendę, w wyniku przetworzenia której zostanie wygenerowane zdarzenie o treści Otrzymano komunikat: Hello World.
  3. W weryfikacji pomoże nam szczegółowy widok zdarzeń Monitora EDA

Otrzymano zdarzenie

  1. Jeśli wszystko się zgadza to znaczy, że mechanizm EDA jest w pełni sprawy.

Pliki

  • Projekt przykładowy dostępny jest tutaj