For the complete documentation index, see llms.txt. This page is also available as Markdown.

Sterowanie dostępnością wniosku

Mechanizm czasowej blokady pozwala sterować dostępnością wniosku na podstawie parametrów konfiguracji biznesowej. Może być stosowany z przyczyn biznesowych lub technicznych. W przypadku aktywnej blokady użytkownik nie może rozpocząć składania wniosku i zostaje przekierowany na stronę z komunikatem o niedostępności.

Przykłady zastosowania:

  • Awarie i krytyczne błędy - wyłączenie wniosku w przypadku znalezienia błędu. Dzięki temu klienci nie korzystają z wadliwego procesu, a deweloperzy mają czas na analizę i wdrożenie poprawki przed jego ponownym uruchomieniem.

  • Przerwy techniczne i serwisowe - czasowe wyłączanie wniosku ze względu na zaplanowaną niedostępność systemów wewnętrznych lub zewnętrznych, od których zależy działanie wniosku (np. przerwa techniczna usług w dniu 12.08 w godzinach 21:00–00:00).

  • Okresowa dostępność - ograniczenie możliwości składania wniosku wyłącznie do ściśle określonych ram czasowych (np. czasowo limitowane lokaty, wnioski rządowe).

Parametry sterujące dostępnością wniosku można definiować i edytować w zakładce Konfiguracja w widoku aplikacji w Eximee Designer. Szczegóły: Konfiguracja z poziomu Low-code.

Aby zmienić wartości parametrów w dowolnym momencie, bez konieczności wydawania nowej wersji aplikacji, można nadpisać je w zakładce Konfiguracja aplikacji w Eximee Dashboard. Operacja jest dostępna dla użytkowników posiadających odpowiednie uprawnienia. Więcej informacji: Modyfikacja (runtime) konfiguracji biznesowych.

Przykładowa struktura Konfiguracji

Konfiguracja podzielona została na trzy logiczne bloki, dotyczące typu niedostępności wniosku:

  • status globalny - związany z nastąpieniem nagłej awarii,

  • przerwa techniczna - dotycząca planowanej, określonej w ramach czasowych blokady procesu,

  • harmonogram - dostępność według określonych dat (i godzin).

# --- 1. STATUS GLOBALNY (AWARIA) ---
form.globalStatus.isOutage=false
form.globalStatus.textContent=formUnavailabilityFailure-*

# --- 2. PRZERWA TECHNICZNA (MAINTENANCE) ---
form.maintenance.isScheduled=true
form.maintenance.startDate=2026-07-22T13:00:00
form.maintenance.endDate=2026-07-22T15:00:00
form.maintenance.textContent=formUnavailabilityMaintenance-*

# --- 3. HARMONOGRAM (SCHEDULE) ---
# Wartości: ALWAYS_AVAILABLE, EXACT_DATE_TIME, YEARLY_RECURRING
form.schedule.ruleType=YEARLY_RECURRING
form.schedule.textContent=formUnavailabilityScheduled-*

# Dla reguły: EXACT_DATE_TIME
form.schedule.exact.startDateTime=2026-01-01T08:00:00
form.schedule.exact.endDateTime=2026-12-31T23:59:59

# Dla reguły: YEARLY_RECURRING (Format MM-DD)
form.schedule.recurring.startMonthDay=07-01
form.schedule.recurring.endMonthDay=11-30

Zasady i priorytety walidacji

Mechanizm działa w oparciu o architekturę kaskadową. Sprawdza warunki od najbardziej krytycznych do najbardziej ogólnych. Spełnienie warunku blokującego powoduje przerwanie obsługi formularza i wyświetlenie użytkownikowi odpowiedniego komunikatu o niedostępności.

Parametr
Format / Wartości
Opis

form.globalStatus.isOutage

true / false

Priorytet 1: Natychmiastowa blokada wniosku, ignoruje pozostałe ustawienia.

form.maintenance.isScheduled

true / false

Priorytet 2: Blokada wniosku w zdefiniowanym oknie czasowym przerwy technicznej.

form.schedule.ruleType

ALWAYS_AVAILABLE EXACT_DATE_TIME YEARLY_RECURRING

Priorytet 3: Reguła harmonogramu sprawdzana, gdy nie ma awarii ani przerwy technicznej.

form.*.textContent

nazwa artefaktu (w formacie nazwaArtefaktu-wersja)

Treść odpowiedniego komunikatu błędu wyświetlanego użytkownikowi. Zapis nazwaArtefaktu-* oznacza najnowszą dostępną wersję artefaktu o podanej nazwie.

form.maintenance.startDate / endDate

data i godzina (w formacie YYYY-MM-DDTHH:MM:SS)

Początek i koniec planowanej przerwy technicznej.

form.schedule.exact.startDateTime / endDateTime

data i godzina (w formacie YYYY-MM-DDTHH:MM:SS)

Początek i koniec ścisłego, jednorazowego harmonogramu działania wniosku.

form.schedule.recurring.startMonthDay / endMonthDay

data (w formacie MM-DD)

Miesiąc i dzień początku oraz końca cyklicznego działania wniosku.

Jeśli żaden warunek nie zostanie spełniony, skrypt kończy działanie bez błędu, co system interpretuje jako pełną dostępność wniosku.

Konfiguracja dla poszczególnych środowisk

Parametry konfiguracji mogą przyjmować różne wartości w zależności od środowiska. Jest to przydatne na przykład wtedy, gdy wniosek powinien zostać zablokowany na środowisku produkcyjnym, ale nadal ma być dostępny na środowiskach deweloperskich i testowych, aby umożliwić jego uruchamianie i weryfikację przez deweloperów low-code oraz testerów.

Przykładowo parametr globalnej blokady może mieć wartość true wyłącznie na środowisku produkcyjnym:

Wartości parametrów sterujących dostępnością należy przypisać do odpowiednich środowisk. Sposób oznaczania środowiska w kluczu konfiguracji oraz zasady wyboru wartości opisano na stronie: Konfiguracja z poziomu Low-code.

Przykład skryptu sterującego dostępnością wniosku

Skrypt weryfikuje, czy klient może otworzyć formularz wniosku, na podstawie zadeklarowanej konfiguracji. Walidacja opiera się na strukturze kaskadowej (priorytetowej), gdzie spełnienie jednego z warunków blokujących natychmiastowo przerywa procesowanie i wyświetla odpowiedni ekran błędu.

Do pobierania parametrów konfiguracji użyto metody getOrDefault(). Jeśli wskazany klucz nie istnieje, metoda zwraca określoną w skrypcie wartość domyślną.

Dobrą praktyką jest używanie metody .msg przy wywołaniu błędu biznesowego. Należy przekazywać w niej czytelny komunikat biznesowy - np. .msg("Wniosek niedostępny"). Zdefiniowany komunikat zostanie wypisany w logach, co ułatwi analizę i identyfikację błędów. Więcej informacji o błędach biznesowych: Strony błędów.

W celu zapewnienia poprawności działania mechanizmu, opisywany skrypt należy podpiąć na wniosek jako EntryService (zakładka Właściwości).

Ilustracja 1. Podpięcie skryptu jako Serwis wejścia na wniosek

Przykłady użycia (Scenariusze biznesowe)

Sytuacja biznesowa
Konfiguracja
Rezultat

Nagły błąd bazy danych

  • form.globalStatus.isOutage=true

  • Pozostałe parametry bez zmian

Wniosek staje się natychmiast niedostępny.

Wdrożenie nowej wersji zaplanowane na weekend

  • form.maintenance.isScheduled=true

  • form.maintenance.startDate=2026-07-22T13:00:00

  • form.maintenance.endDate=2026-07-22T15:00:00

Wniosek będzie niedostępny we wskazanym przedziale, a po jego zakończeniu zostanie automatycznie ponownie udostępniony.

Cykliczna dostępność programu “Dobry Start” (300+)

  • form.schedule.ruleType=YEARLY_RECURRING

  • form.schedule.recurring.startMonthDay=07-01

  • form.schedule.recurring.endMonthDay=11-30

Wniosek będzie dostępny co roku we wskazanym okresie.

Standardowy wniosek bez ograniczeń czasowych

  • form.schedule.ruleType=ALWAYS_AVAILABLE

  • form.globalStatus.isOutage=false

  • form.maintenance.isScheduled=false

Wniosek dostępny bez ograniczeń.

Przykłady komunikatów o niedostępności

W bankowości elektronicznej i mobilnej dobór słów w komunikatach (tzw. UX writing) bezpośrednio wpływa na poczucie bezpieczeństwa oraz zaufanie klienta. W Eximee Designer, treść wyświetlanego komunikatu jest definiowana w artefakcie Treść formatowana (TextContent) wskazanym w konfiguracji odpowiedniego rodzaju blokady.

Dostępność wniosku co roku w określonym terminie

Komunikat powinien informować użytkownika, w jakim okresie wniosek jest dostępny, oraz zachęcać do ponownego skorzystania z niego w tym terminie.

  • Tytuł: Wniosek będzie dostępny od 1 lipca

  • Treść: Ten wniosek możesz złożyć od 1 lipca do 30 listopada. Zapraszamy do powrotu w tym terminie.

Ilustracja 2. Przykład komunikatu o harmonogramowej niedostępności wniosku

Awaria („Pracujemy nad tym”)

Komunikat powinien krótko wyjaśniać sytuację, informować o trwających pracach nad rozwiązaniem problemu oraz wskazywać użytkownikowi dalsze postępowanie. Nie należy umieszczać w nim szczegółów technicznych ani kodów błędów.

  • Tytuł: Wniosek jest chwilowo niedostępny

  • Treść: Przepraszamy, występują trudności techniczne. Złożenie wniosku jest obecnie niemożliwe. Wiemy o problemie i pracujemy nad jego rozwiązaniem. Spróbuj ponownie za jakiś czas.

Ilustracja 3. Przykład komunikatu o niedostępności wniosku z powodu awarii

Przerwa techniczna

Treść komunikatu w trakcie trwania przerwy technicznej powinna jasno przedstawiać, w jakim terminie wniosek będzie ponownie dostępny.

  • Tytuł: Trwają prace serwisowe

  • Treść: Ten wniosek jest niedostępny z powodu zaplanowanych prac technicznych. Prace potrwają do godziny 16:00. Przepraszamy za utrudnienia i zapraszamy ponownie po tej godzinie.

Ilustracja 4. Przykład komunikatu o niedostępności wniosku z powodu przerwy technicznej

Aplikacja demo: demoFormUnavailability_app

Pobierz plik i zaimportuj go w Eximee Designer, aby uruchomić aplikację na swoim środowisku.

Ostatnia aktualizacja

Czy to było pomocne?