Task Scheduler w backendzie aplikacji AppMaster, jak w klasycznym przypadku backendu, tworzy powtarzające się scenariusze. Na przykład wtedy, gdy trzeba wykonać określoną czynność zgodnie z harmonogramem. Klasycznym przykładem takich zadań jest przykład czyszczenia plików tymczasowych na serwerze, cotygodniowe tworzenie kopii zapasowych, generowanie raportów według określonego algorytmu itp.
Rozważmy przykład wykorzystania harmonogramu zadań w backendzie aplikacji AppMaster. Załóżmy, że chcesz zbudować proces, który codziennie rano o godzinie 9.00 będzie wysyłał użytkownikowi pogodę na jego numer telefonu komórkowego.
Zadanie jest więc podzielone na kilka logicznych etapów:
- Zainstalowanie i skonfigurowanie modułu do wysyłania wiadomości na telefony komórkowe
- Stworzenie i skonfigurowanie procesu API z zewnętrznym żądaniem
- Skonfigurowanie schedulera w backendzie aplikacji.
1. Instalacja i konfiguracja modułu do wysyłania wiadomości mobilnych.Moduł Nexmo pozwala na zintegrowanie z aplikacją AppMaster możliwości wysyłania wiadomości SMS na wybrany numer.
- API Key - klucz API, który można uzyskać na koncie Nexmo(https://dashboard.nexmo.com/settings);
- API Secret - klucz prywatny, który w połączeniu z kluczem API służy do identyfikacji użytkownika. Możesz go również uzyskać w swoim koncie Nexmo(https://dashboard.nexmo.com/settings);
- Z numeru - numer podany podczas rejestracji w koncie Nexmo.
Wraz z instalacją modułu automatycznie instalowane są następujące procesy biznesowe:
- Nexmo.Wyślij SMS - umożliwia wysyłanie wiadomości na podany numer poprzez.
moduł Nexmo:
- Phone [telefon] - numer telefonu, na który zostanie wysłana wiadomość;
- Treść [string] - wiadomość tekstowa;
2. Jako źródło danych pogodowych wykorzystany zostanie darmowy zasób internetowy OpenWeather API(https://openweathermap.org/api).Pierwszym krokiem jest stworzenie zewnętrznego szablonu API request. Szablony żądań API są prezentowane w sekcji Business Process na karcie External API Requests. Aby utworzyć nowy szablon, kliknij przycisk Create API request.
Typ żądania: GET
Adres żądania: https://api.openweathermap.org/data/2.5/weather
Query Params:
- Lat [string] - szerokość geograficzna
- Lon [string] - długość geograficzna
- Appid [string] - klucz API OpenWeather
W ramach tego zadania interesuje nas tylko kilka pól ciała odpowiedzi w main(https://openweathermap.org/api/one-call-3).
- Temp [float] - temperatura
- Temp_min [float] - temperatura min.
- Temp_max [float] - temperatura maksymalna
- Ciśnienie [float] - ciśnienie
- Humidity [float] - wilgotność
3. Przed skonfigurowaniem harmonogramu zadań należy stworzyć Business Process, który będzie odbierał informacje o pogodzie poprzez API. Proces biznesowy wygląda następująco:
- Make Weather Query Model In - tworzy wirtualny model parametrów żądania. Lon, lat - współrzędne żądanej lokalizacji, appid - klucz API serwisu OpenWeather;
- API Request: Weather - proces biznesowy odpowiedzialny za interakcję z API OpenWeather
- Expand Weather: Body Model Out - potrzebny do wdrożenia modelu odpowiedzi Body
- Expand Weather: Body Model Out_main - rozszerza główny model ciała odpowiedzi Body w celu uzyskania temperatury (temp).
- To String - konwertuje wartość pola temp na typ string;
- Nexmo: Send SMS - wysyła wiadomość z informacją o temperaturze (Content) na wskazany numer telefonu (Phone)
Ustawienie harmonogramu w sekcji procesu biznesowego w zakładce Scheduler.
Ustawienia harmonogramów w zakładce Harmonogram różnią się w zależności od ich typu.
Przeanalizujmy szczegółowo każdy z nich
1. Dzienny - umożliwia konfigurację harmonogramów dziennych
- Godzina - definiuje godzinę w UTC+0, o której harmonogram będzie uruchamiał wybrany BP;
- Dni tygodnia - definiuje dni tygodnia, w których ma pracować scheduler;
- Automatycznie rozpoczynaj - jeśli ustawione na True, nowy BP nie zostanie rozpoczęty, jeśli poprzedni nie został zakończony. Wartość domyślna: False.
- Automatically retry - automatycznie wznawia proces, jeśli został on przerwany/nie został pomyślnie rozpoczęty.
Retry failed items processing - liczba prób ponownego uruchomienia procesu;
Wait before each retry attempt - czas opóźnienia przed każdym strzałem do ponownego uruchomienia procesu;
- Force quit - wymuszaj zakończenie procesu, jeśli nie zostanie zakończony w ciągu kilku sekund. True - domyślnie. Liczba sekund do zakończenia wynosi 3 sekundy, domyślnie.
2. Monthly - planer miesięczny
- Time - określa godzinę w UTC+0, o której scheduler rozpocznie wybrany BP;
- Dni tygodnia - składają się z dwóch ustawień:
Częstotliwość powtarzania:
- Co pierwszy
- Co drugi
- Co trzeci
- Co czwarty
- Ten dzień
Dzień tygodnia - określa dzień tygodnia
- Month - określany jest miesiąc
- Auto Start - Jeśli ustawione na True, nowy PSU nie będzie uruchamiany jeśli nie zostanie ukończony wkrótce. Wartość domyślna: False.
- Automatycznie ponawiaj próbę - automatycznie wznawia proces jeśli został przerwany/nie uruchomiony
Retry processing failed items - liczba ponownych uruchomień procesu;
Wait before each retry - czas opóźnienia przed każdą próbą ponownego uruchomienia procesu;
- Force Quit - kończy proces, jeśli nie zostanie zakończony w ciągu kilku sekund. Domyślnie True. Liczba sekund do zakończenia wynosi domyślnie 3 sekundy.
3. Periodically - pozwala na elastyczne skonfigurowanie częstotliwości działania schedulera
- Every - możliwość ustawienia powtarzalności co N sekund/minut/godzin/dni. Domyślnie: co 1 godzinę.
- Automatycznie rozpoczynaj - jeśli ustawione na True, nowy BP nie rozpocznie się, jeśli poprzedni nie został zakończony. Wartość domyślna: False.
- Automatically retry - automatycznie wznawia proces, jeśli został przerwany/nie został uruchomiony pomyślnie
Retry failed items processing - liczba prób ponownego uruchomienia procesu;
Wait before each retry attempt - czas opóźnienia przed każdym strzałem do ponownego uruchomienia procesu;
- Force quit - wymuszaj zakończenie procesu, jeśli nie zostanie zakończony w ciągu kilku sekund. True - domyślnie. Liczba sekund do zakończenia wynosi 3 sekundy, domyślnie.
4. Po uruchomieniu aplikacji - planista zadań jednorazowych.
- Delay - definiuje opóźnienie pomiędzy startem aplikacji a uruchomieniem. Domyślnie - 0 sek.
- Automatically retry - automatyczne ponowne uruchomienie procesu, jeśli został on przerwany/nie został pomyślnie uruchomiony
Retry failed items processing - liczba prób ponownego uruchomienia procesu;
Wait before each retry attempt - czas opóźnienia przed każdym strzałem do ponownego uruchomienia procesu;
- Force quit - wymuszaj zakończenie procesu, jeśli nie zostanie zakończony w ciągu kilku sekund. True - domyślnie. Liczba sekund do zakończenia wynosi 3 sekundy, domyślnie.
5. Przed zakończeniem aplikacji - uruchamiaj scheduler za każdym razem, gdy aplikacja się kończy
- Automatically retry - automatycznie wznawia proces, jeśli został on przerwany/nie został uruchomiony pomyślnie
Retry failed items processing - liczba prób ponownego uruchomienia procesu;
Wait before each retry attempt - czas opóźnienia przed każdą próbą ponownego uruchomienia procesu;
- Force quit - wymuszaj zakończenie procesu, jeśli nie zostanie zakończony w ciągu kilku sekund. True - domyślnie. Liczba sekund do zakończenia wynosi 3 sekundy, domyślnie.
W zakładce Params w ustawieniach schedulera można również przekazać parametry do wejścia BP, gdy jest ono uruchamiane przez scheduler:
W naszym przykładzie ustawienia schedulera wyglądają następująco:
- Wiadomości będą wysyłane codziennie o 9 rano UTC+0
- Automatycznie próbuje ponownie uruchomić proces 3 razy z opóźnieniem 10 minut między próbami, jeśli proces nie rozpoczął się natychmiast;
- Siłowo kończy proces, jeśli nie został zakończony w ciągu trzech sekund.
Nasza aplikacja żyje i działa w backendzie, więc aby działała, wystarczy ją opublikować.
