Skip to main content

Jak dziala wysylanie maili w AMODIT

Aktualizacja

Artykuł zweryfikowany dla linii 251231.

Wprowadzenie

Ten artykuł jest dla administratora i partnera wdrożeniowego, który chce zrozumieć, jak AMODIT doprowadza wiadomość od zdarzenia w systemie do realnej wysyłki. Po lekturze powinno być jasne, dlaczego problem z mailem wychodzącym nie zawsze oznacza problem z serwerem pocztowym i w jakiej kolejności warto szukać przyczyny.

Skąd biorą się maile wychodzące

AMODIT wysyła maile z kilku różnych powodów:

  • informuje użytkowników o nowej pracy albo zmianach w sprawach,
  • wysyła przypomnienia i eskalacje związane z terminami,
  • wysyła wiadomości uruchamiane przez reguły, akcje albo funkcje systemowe,
  • obsługuje wiadomości kierowane do odbiorców wewnętrznych i zewnętrznych.

To rozróżnienie jest ważne, bo dwa maile mogą wyglądać podobnie dla odbiorcy, a mimo to powstać w zupełnie innym scenariuszu i przejść inną drogę, zanim zostaną wysłane.

Co dzieje się z mailem po jego wygenerowaniu

Najprostszy model obiegu wiadomości wygląda tak:

  1. W systemie pojawia się zdarzenie albo akcja, która ma skutkować mailem.
  2. AMODIT przygotowuje treść, odbiorcę, nadawcę, załączniki i nagłówki.
  3. Wiadomość trafia albo od razu do zwykłej kolejki wysyłkowej, albo najpierw do toru grupowania i opóźniania.
  4. Zadanie odpowiedzialne za transport wysyła mail przez wybrany mechanizm.

W praktyce oznacza to, że sama konfiguracja poczty wychodzącej jest dopiero końcowym odcinkiem całego obiegu.

Jakie tory prowadzą do wysyłki

Zwykłe powiadomienia

To scenariusz, w którym system ma poinformować użytkownika o nowej pracy albo zmianie w sprawie. Część takich komunikatów może zostać skierowana od razu do zwykłej wysyłki.

Powiadomienia zbiorcze

Nie wszystkie powiadomienia muszą wyjść od razu. System potrafi najpierw odłożyć wpisy dla użytkownika, a potem złożyć je w jedną wiadomość zbiorczą.

Krótki przykład: jeśli w ciągu dnia w jednej sprawie pojawia się kilka zmian, użytkownik nie musi dostać kilku osobnych maili. Przy odpowiednich preferencjach może dostać jedno podsumowanie.

Przypomnienia i eskalacje

Powiadomienia związane z terminami to osobny tor. Ich celem nie jest informowanie o zwykłej zmianie w sprawie, tylko przypomnienie o terminie albo sygnalizacja przekroczenia.

Wiadomości wysyłane z funkcji i automatyzacji

AMODIT potrafi też wysyłać maile jako wynik konkretnej reguły, funkcji albo akcji w procesie. Taki mail nie musi podlegać tej samej logice co zwykłe powiadomienie dla użytkownika.

Jaką rolę pełnią zadania systemowe

Notifications

To zadanie odpowiada za techniczną wysyłkę z kolejki wychodzącej. Tu spotykają się różne scenariusze, które chcą dostarczyć gotową wiadomość do odbiorcy.

UserNotifications

To zadanie nie jest serwerem wysyłki. Jego rola polega na zebraniu odłożonych wpisów dla użytkownika, ułożeniu ich w sensowne podsumowanie i przekazaniu do dalszej wysyłki.

Reminders

To zadanie obsługuje przypomnienia i eskalacje związane z terminami. Dla diagnostyki ma to duże znaczenie, bo mail terminowy nie musi przechodzić dokładnie tej samej drogi co zwykłe powiadomienie o zmianie.

Co wpływa na moment wysyłki

Na czas dostarczenia wiadomości wpływają co najmniej cztery rzeczy:

  • rodzaj scenariusza, który wygenerował mail,
  • preferencje użytkownika dotyczące częstotliwości powiadomień,
  • harmonogram zadań odpowiedzialnych za grupowanie i wysyłkę,
  • dostępność i poprawna konfiguracja mechanizmu transportu.

To dlatego sama informacja, że wiadomość nie dotarła od razu, nie wystarcza jeszcze do diagnozy. Trzeba ustalić, czy dany typ wiadomości miał wyjść natychmiast, zbiorczo czy jako przypomnienie.

Jak rozdzielić problem logiki od problemu transportu

W praktyce warto zadać sobie cztery pytania:

  1. Czy w ogóle wystąpiło zdarzenie, które powinno wygenerować mail?
  2. Czy ten typ wiadomości powinien wyjść od razu, czy dopiero po grupowaniu?
  3. Czy proces, etap albo preferencje użytkownika nie ograniczają takiej wysyłki?
  4. Czy końcowy mechanizm wysyłki jest poprawnie skonfigurowany i działa?

Takie podejście porządkuje diagnostykę. Najpierw ustalasz, czy system chciał wysłać mail, potem którym torem miał on przejść, a dopiero na końcu sprawdzasz sam transport.

Gdzie najczęściej pojawiają się nieporozumienia

Najczęstsze pomyłki w tym obszarze wynikają z mieszania kilku tematów:

  • utożsamiania wszystkich maili wychodzących z powiadomieniami,
  • redukowania całego problemu do ustawień serwera SMTP,
  • zakładania, że zadanie Notifications wyjaśnia cały obieg wiadomości,
  • traktowania przypomnień jako zwykłego wariantu tego samego powiadomienia,
  • pomijania różnicy między mailem wygenerowanym przez proces a mailem z funkcji lub automatyzacji.

Jeśli administrator nie rozdzieli tych warstw, łatwo dojść do mylnego wniosku, że każda nieprawidłowość ma jedno źródło.

Gdzie szukać dalej

Najszerszy kontekst całej serii daje artykuł Obsługa poczty w AMODIT.

Jeśli chcesz osadzić ten materiał w obszarze wychodzącej, przejdź do Poczta wychodząca w AMODIT.

Jeśli analizujesz przede wszystkim scenariusz informowania użytkowników o nowej pracy i zmianach w sprawach, zobacz też Powiadomienia w AMODIT.

Jeśli chcesz uporządkować warstwę administracyjną, przejdź do artykułu Konfiguracja poczty wychodzącej w AMODIT.

Jeśli pracujesz konkretnie z wariantem SMTP, przejdź do artykułu Konfiguracja wysyłki przez SMTP.

Jeżeli diagnozujesz wysyłkę przez Exchange, przejdź do artykułu Konfiguracja wysyłki przez EWS.

Jeżeli diagnozujesz albo konfigurujesz wysyłkę przez Microsoft 365 z użyciem Microsoft Graph, przejdź do artykułu Konfiguracja wysyłki przez MS Graph.

Szczegółowy materiał dla RestAPI jest w przygotowaniu.

Powiązane artykuły