Powiadomienia w systemie ERP - mechanizm wysyłki e-mail i SMS

Powiadomienia w systemie ERP - co opisuje HermesSQL

System ERP HermesSQL, oferowany przez firmę Humansoft, umożliwia wysyłanie powiadomień e-mail i SMS oraz okien pop-up o istotnych zdarzeniach w firmie. Użytkownik nie musi stale przeglądać programu, by dowiedzieć się o zmianie statusu zamówienia albo postępie produkcji. Ta część artykułu streszcza to, co potwierdza opis producenta; szerszy kontekst wsparcia produkcji zawiera tekst o usprawnieniu produkcji dzięki oprogramowaniu ERP.

Dalsze sekcje omawiają ogólny mechanizm, na którym opiera się każde powiadomienie w systemie ERP. Jest to opis techniczny, a nie specyfikacja modułu HermesSQL ani żadnego innego produktu.

Kanały i zdarzenia

Powiadomienia obejmują zmiany w zamówieniach klientów i dostawców oraz statusy dostaw i produkcji. Firma może tworzyć własne reguły i scenariusze komunikacji, określać warunki wysyłania, korzystać z szablonów wiadomości i grupować odbiorców. Zarządza się też częstotliwością komunikatów, a użytkownik wybiera preferowany kanał spośród dostępnych.

Raporty cykliczne i komunikaty dla klientów

Cykliczne raporty w formacie PDF lub XLS trafiają do pracowników, którzy nie korzystają bezpośrednio z ERP, na przykład z informacją o stanach magazynowych i poziomie zapasów. System może wysyłać je o określonych porach dnia albo w wybranych odstępach czasu. Automatyczne powiadomienia o stanach magazynowych i terminach ważności wymienia także tekst o raportowaniu w HermesSQL.

Powiadomienia mogą też kierować się do klientów, z informacją o statusie zamówienia albo o innym etapie współpracy. Zewnętrzny odbiorca oznacza jednak inne wymagania niż pracownik: inny zakres danych w treści i inny sposób zapisania zgody na kontakt.

Reguła: treść powiadomienia nie może zawierać danych, do których odbiorca nie miałby dostępu po zalogowaniu do systemu.

Od zdarzenia w bazie do reguły

Każde powiadomienie zaczyna się od zdarzenia, czyli zmiany, którą system potrafi wykryć: nowy status dokumentu, przekroczenie progu albo upływ terminu. Powiadomienie nie jest wysyłane w momencie zdarzenia. W tej chwili zapisuje się tylko wiersz zdarzenia, a dalszą obróbkę przejmuje osobny proces.

Skąd bierze się zdarzenie

Istnieją dwa sposoby wykrycia zdarzenia w bazie SQL Server. Pierwszy to wyzwalacz (trigger) na tabeli dokumentów, który zapisuje zdarzenie natychmiast po zmianie. Drugi to zadanie SQL Agent uruchamiane cyklicznie, które sprawdza warunki, na przykład stan poniżej minimum albo termin ważności bliżej niż zadana liczba dni. Wyzwalacz nadaje się do zmian statusu, zadanie okresowe do progów i terminów.

CREATE TRIGGER dbo.trg_PrzykladZamowienie_Status
ON dbo.PrzykladZamowienie
AFTER UPDATE
AS
BEGIN
    SET NOCOUNT ON;
    INSERT INTO dbo.PrzykladZdarzenie (Typ, IdObiektu, Dane, DataZdarzenia)
    SELECT 'ZAMOWIENIE_STATUS', i.IdZamowienia,
           CONCAT(d.Status, ' na ', i.Status), SYSDATETIME()
    FROM inserted AS i
    JOIN deleted AS d ON d.IdZamowienia = i.IdZamowienia
    WHERE ISNULL(d.Status, '') <> ISNULL(i.Status, '');
END;

Wyzwalacz wstawia zdarzenie tylko wtedy, gdy status faktycznie się zmienił, a nie przy każdej aktualizacji wiersza. Zapisuje wyłącznie krótki rekord i nie wywołuje żadnej sieciowej usługi, ponieważ czekanie na SMTP wewnątrz transakcji dokumentu zablokowałoby użytkownika.

Reguła powiadomienia i jej składniki

Reguła łączy typ zdarzenia z warunkiem oraz z odbiorcami, a także z kanałem i szablonem treści. Silnik reguł czyta nowe zdarzenia i sprawdza warunki, a dla każdego pasującego odbiorcy tworzy wpis w kolejce wysyłki. Ta warstwa pozwala firmie tworzyć własne scenariusze bez zmian w kodzie aplikacji.

Zdarzenia o dużej częstotliwości, takie jak seria zmian statusu w jednym zamówieniu, agreguje się jeszcze przed regułą. Silnik pobiera je w oknie czasowym i łączy w jedno, żeby odbiorca dostał wiadomość o stanie końcowym, a nie o każdym kroku pośrednim.

Kolejka wysyłki i mechanizmy niezawodności

Kolejka rozdziela dwa światy o różnym czasie reakcji: transakcje bazy, które trwają milisekundy, oraz serwery pocztowe i bramki SMS, które bywają niedostępne. Dzięki niej wiadomość może poczekać, a dokument w ERP zapisuje się bez opóźnienia. Podobną ideę kolejek zadań stosuje się w magazynie, co pokazuje tekst o kolejkach zadań dyspozytora magazynowego.

Tabela kolejki i pobieranie wpisów

Kolejką jest zwykła tabela ze statusem wpisu (nowa, wysyłana, wysłana, błędna), liczbą prób i terminem następnej próby. Kilka procesów wysyłających może pracować równolegle, jeśli każdy pobiera wpisy atomowo. Pomagają w tym podpowiedzi blokad UPDLOCK i READPAST oraz klauzula OUTPUT, opisana w dokumentacji Microsoft Learn o klauzuli OUTPUT.

WITH nastepna AS (
    SELECT TOP (10) *
    FROM dbo.PrzykladKolejkaPowiadomien WITH (ROWLOCK, UPDLOCK, READPAST)
    WHERE Status = 'Nowa' AND NastepnaProba <= SYSDATETIME()
    ORDER BY IdKolejki
)
UPDATE nastepna
SET Status = 'Wysylana', LiczbaProb = LiczbaProb + 1
OUTPUT inserted.IdKolejki, inserted.Kanal, inserted.Adres, inserted.Temat, inserted.Tresc;

Podpowiedź READPAST pomija wiersze zablokowane przez inny proces, więc dwa procesy nie pobiorą tego samego wpisu. Po wysłaniu proces ustawia status na wysłaną albo błędną, zależnie od odpowiedzi serwera.

Ponawianie i deduplikacja

Ponawianie obsługuje błędy przejściowe: serwer pocztowy chwilowo nie odpowiada, bramka odrzuca żądanie z powodu limitu. Wpis wraca do kolejki z rosnącym odstępem, na przykład po minucie, potem po pięciu minutach, a na końcu po kwadransie. Po wyczerpaniu prób dostaje status błędnej, a administrator widzi go na liście do przeglądu.

Deduplikacja chroni przed wysłaniem dwóch takich samych wiadomości. Każdy wpis niesie klucz zbudowany z typu reguły oraz identyfikatora obiektu, a także okna czasowego, a unikalny indeks filtrowany, opisany w dokumentacji indeksów filtrowanych, odrzuca duplikat aktywnego wpisu.

CREATE UNIQUE INDEX UX_Kolejka_Dedup
ON dbo.PrzykladKolejkaPowiadomien (KluczDedup)
WHERE Status IN ('Nowa', 'Wysylana');

Reguła: ponowienie wysyłki nie tworzy nowego wpisu, tylko zmienia termin i licznik prób istniejącego, bo nowy wpis wygenerowałby duplikat u odbiorcy.

Kanały wysyłki - SMTP i bramka SMS

Ostatnie ogniwo łańcucha zależy od kanału. E-mail wysyła się protokołem SMTP przez serwer poczty, a SMS przez bramkę operatora lub pośrednika.

Wysyłka e-mail przez SMTP

Aplikacja łączy się z serwerem SMTP (na przykład Exchange albo wewnętrznym przekaźnikiem), uwierzytelnia się i przekazuje wiadomość. Protokół opisuje specyfikacja RFC 5321. Serwery ograniczają liczbę wiadomości na minutę, więc proces wysyłający dostosowuje tempo do limitu, a nie wysyła całej kolejki naraz. Alternatywą jest funkcja Database Mail w SQL Server z procedurą sp_send_dbmail, opisana w dokumentacji Database Mail.

Połączenie z serwerem szyfruje się protokołem TLS, w wariancie STARTTLS na porcie 587 albo z szyfrowaniem od początku sesji na porcie 465. Konto do wysyłki jest kontem usługowym z minimalnymi uprawnieniami, a jego hasło trzyma się w magazynie poświadczeń, a nie jawnym tekstem w tabeli konfiguracji.

Adres nadawcy powinien należeć do domeny firmy i mieć skonfigurowane rekordy SPF oraz DKIM, w przeciwnym razie serwery odbiorców klasyfikują powiadomienia jako spam.

Bramka SMS

Bramka SMS udostępnia zwykle interfejs HTTP: aplikacja wysyła żądanie z numerem i treścią, a bramka zwraca identyfikator wiadomości. Status doręczenia dociera później, przez wywołanie zwrotne albo odpytywanie. Poniższy fragment C# jest ogólnym przykładem, bez wskazania konkretnego operatora.

using var http = new HttpClient();
http.DefaultRequestHeaders.Authorization =
    new AuthenticationHeaderValue("Bearer", token);

var tresc = new StringContent(
    JsonSerializer.Serialize(new { to = numer, text = tekst }),
    Encoding.UTF8, "application/json");

var odpowiedz = await http.PostAsync("https://bramka.example.com/api/sms", tresc);
if (!odpowiedz.IsSuccessStatusCode)
{
    // zapis błędu w dzienniku, ponowienie według harmonogramu kolejki
}

Polskie znaki diakrytyczne nie należą do podstawowego alfabetu GSM 7-bit, więc wiadomość z nimi jest kodowana w UCS-2 i mieści 70 znaków w jednym segmencie zamiast 160. Treść SMS-a pisze się więc krótko, a szczegóły zostawia w e-mailu albo w programie.

Uprawnienia odbiorców i dziennik wysyłek

Powiadomienia przenoszą dane poza system, więc podlegają tym samym zasadom dostępu co ekrany programu. Kontrola dotyczy zarówno wyboru odbiorców, jak i treści.

Kto może dostać jaką informację

Odbiorców wskazuje się przez rolę albo grupę, a nie przez stały adres. Gdy planista zmienia stanowisko, reguła sama przestaje do niego docierać, bez edycji szablonów. Rozwiązywanie odbiorców w chwili wysyłki uwzględnia też uprawnienia: użytkownik bez dostępu do cen nie dostaje w powiadomieniu wartości zamówienia.

W wiadomościach kierowanych do klientów i kontrahentów zakres danych ogranicza się do minimum potrzebnego do reakcji. Odbiorca zewnętrzny musi też mieć możliwość rezygnacji z wiadomości, a zgoda na kontakt jest zapisana w systemie.

Dziennik wysyłek

Dziennik odpowiada na pytanie, które pada najczęściej: dlaczego nie dostałem wiadomości. Każda próba zostawia w nim ślad, dzięki czemu administrator sprawdza przyczynę bez zaglądania do serwera poczty.

• Zdarzenie i reguła - identyfikatory zdarzenia oraz reguły, która wygenerowała wpis.
• Odbiorca i kanał - adres lub numer, do którego wysłano wiadomość, oraz użyty kanał.
• Status i kod błędu - wynik każdej próby wraz z odpowiedzią serwera SMTP albo bramki.
• Czas i identyfikator zewnętrzny - moment wysłania oraz numer wiadomości nadany przez bramkę.

Dziennik ma też okres przechowywania, po którym stare wpisy przenosi się do archiwum, aby tabela nie spowalniała kolejki. Na jego podstawie prowadzi się raporty operacyjne, na przykład liczbę wiadomości błędnych w tygodniu.

Progi alarmowe i unikanie zalewu wiadomości

Największym zagrożeniem dla systemu powiadomień nie jest awaria, tylko nadmiar. Odbiorca, który dostaje kilkadziesiąt wiadomości dziennie, przestaje je czytać, a wtedy pilny alert ginie wśród informacyjnych.

Progi alarmowe z histerezą

Próg alarmowy, na przykład stan poniżej minimum, generuje alert w chwili przekroczenia. Bez histerezy stan oscylujący wokół wartości granicznej wysyła alert kilka razy dziennie. Rozwiązaniem jest osobny próg powrotu: alert wraca dopiero wtedy, gdy stan najpierw przekroczy minimum powiększone o zapas, a potem znowu spadnie poniżej niego. O logice stanów i brakach towaru pisze artykuł o bilansie zamówień i rezerwacji, a o terminach ważności tekst o zarządzaniu terminami ważności.

Zbiorcze zestawienia zamiast pojedynczych wiadomości

Zdarzenia o niskim priorytecie zbiera się w zestawienie wysyłane raz na zmianę albo raz dziennie. Jedna wiadomość z tabelą dwudziestu pozycji jest czytelniejsza niż dwadzieścia osobnych. Wysyłkę ogranicza też limit na odbiorcę w oknie czasowym oraz godziny ciszy, w których zdarzenia czekają na rano, o ile nie mają najwyższej pilności.

Tryb testowy i monitorowanie kolejki

Kopia bazy produkcyjnej uruchomiona w środowisku testowym potrafi wysłać prawdziwe powiadomienia do prawdziwych klientów. Środowisko testowe przekierowuje więc całą pocztę na jeden adres kontrolny, a bramka SMS jest w nim wyłączona albo skierowana na numer testowy.

Samą kolejkę też się monitoruje. Alarm o wpisie starszym niż ustalony czas informuje administratora, że wysyłka stanęła, zanim poskarży się na to użytkownik. Wystarczą cztery wskaźniki.

• Wiek najstarszego wpisu - czas, przez jaki wpis o statusie nowej czeka na pobranie przez proces wysyłający.
• Liczba wpisów błędnych - wpisy, które wyczerpały próby i wymagają decyzji administratora.
• Czas od zdarzenia do wysyłki - opóźnienie całego potoku, mierzone od zapisu zdarzenia do przyjęcia wiadomości przez serwer.
• Odsetek odrzuceń - udział odpowiedzi błędnych serwera SMTP lub bramki w ostatniej godzinie.

Rzeczywiste zapotrzebowanie na powiadomienia ustala się razem z użytkownikami w analizie wdrożeniowej, a same reguły sprawdza w testach akceptacyjnych, zanim ruszą na produkcji; taki przebieg opisuje tekst o wdrożeniu systemu ERP. Wzorzec kolejek i asynchronicznej wymiany, podobny do opisanego tutaj, pokazuje materiał o integracji WMS z ERP przez REST i kolejki, a przykład zdarzeń serwisowych z wyprzedzeniem - tekst o aplikacji do utrzymania ruchu.

Jeśli firma potrzebuje reguł, których standardowy system nie obsługuje, rozszerza się je osobnym modułem; takie prace realizuje dział oprogramowania na zamówienie SoftwareStudio.