Pierwsze kroki w nAxiom, wersja nAxiom 1.14 i nowsze

Przeczytasz w 81 min.

Spis treści

1. Krótkie wprowadzenie do platformy nAxiom
   1. Logowanie do nAxiom
   2. AdminSPA
   3. Czynności administracyjne
      1. Deklarowanie aplikacji
      2. Definiowanie roli
      3. Definiowanie użytkownika
2. Pierwsza aplikacja w 15 minut
   1. Model prostego procesu: rejestracja reklamacji
   2. Definiowanie tabeli
   3. Generowanie elementów aplikacji
   4. Widok listy
   5. Menu użytkownika
   6. Nadawanie uprawnień do funkcjonalności
   7. Uruchomienie aplikacji
3. Wstęp do modelowania procesów
   1. Workflow, czyli model procesu
   2. Obsługa reklamacji 2.0 — założenia
   3. Definiowanie statusów
   4. Definiowanie ról i użytkowników
   5. Tworzenie workflow
   6. Testowanie aplikacji
   7. Modyfikowanie widoku formularza
   8. Koniec

Streszczenie

Ta publikacja jest przeznaczona dla konsultantów, czyli użytkowników, którzy będą budować aplikacje na platformie nAxiom. Jej celem jest wstępne zaznajomienie użytkownika z platformą oraz przedstawienie podstawowych kroków w procesie tworzenia aplikacji. Aby zmaksymalizować szanse realizacji założonego celu, opisano w niej konkretny przykład uproszczonej aplikacji, który może stanowić pierwsze ćwiczenie praktyczne dla użytkownika.

---

Krótkie wprowadzenie do platformy nAxiom

nAxiom to zintegrowane środowisko pozwalające na budowanie modeli procesów biznesowych w formie aplikacji biznesowych oraz na obsługę procesów biznesowych za pomocą tych aplikacji.

W dużym uproszczeniu praca konsultanta w nAxiom polega na budowaniu elementów funkcjonalności wokół definicji dokumentów. Najważniejszymi elementami funkcjonalności są model danych (reprezentowany przez tabelę bazy danych), widok listy, formularz i diagram procesu. Funkcjonalności są przypisywane do swego rodzaju kontenerów, które zapewniają ich przenośność, są to aplikacje i moduły aplikacji.

Taka architektura pozwala nie tylko określać uprawnienia użytkowników na poziomie aplikacji, modułu i funkcjonalności, ale także wykorzystywać poszczególne funkcjonalności w różnych modułach i aplikacjach.

Tworzenie funkcjonalności obejmuje kilka kroków, które zwykle mogą być wykonywane w różnej kolejności. Najważniejsze z nich to:

• zdefiniowanie modelu danych i utworzenie tabel bazy danych, w których będą przechowywane dane przetwarzane w ramach procesu biznesowego,

• zdefiniowanie diagramu procesu (workflow), czyli powiązanie ze sobą czynności wykonywanych w procesie oraz statusów danych przetwarzanych w procesie i przejść między tymi statusami,

• zdefiniowanie menu użytkownika, za pomocą którego użytkownik końcowy będzie wywoływał funkcjonalności.

Ponadto w przypadku bardziej złożonych procesów konieczne będzie zdefiniowanie szablonów wydruków, wywołań usług używanych w ramach obsługi procesu (usługi REST/SQL), słowników itp.

Gotową funkcjonalność udostępnia się użytkownikom końcowym, włączając dostęp do funkcjonalności w uprawnieniach roli danego użytkownika. Koncepcję platformy przedstawiono na poniższej ilustracji.

Logowanie do nAxiom

Od strony technicznej platforma nAxiom to uruchamiana w przeglądarce aplikacja, która składa się z kilku komponentów. Do budowy aplikacji służy serwis AdminSPA, w którym buduje się aplikacje biznesowe. Z kolei w serwisie FrontSPA użytkownicy końcowi — klienci — korzystają z tych aplikacji do obsługi procesów biznesowych w ramach swojej codziennej pracy.

W przypadku instalacji lokalnej standardowy adres witryny nAxiom to https://localhost (informacje o rzeczywistym adresie można uzyskać od administratora). Po wpisaniu w przeglądarce adresu platformy nAxiom w danej organizacji zostanie wyświetlona strona logowania. Jeśli użytkownik loguje się, używając profilu z przypisaną systemową rolą Konsultant, nastąpi automatyczne przekierowanie do AdminSPA, to jest https://localhost/admin. Użytkownicy z przypisaną rolą systemową Klient będą z kolei kierowani do FrontSPA (https://localhost/front).

W tym artykule do przygotowania ilustracji użyto instalacji lokalnej, której adres to https://fsteps.naxiom.local:3131.

AdminSPA

Aby zalogować się do AdminSPA, należy użyć systemowego profilu użytkownika z rolą systemową Konsultant: nazwa logowania: consultant, hasło: !Q2w3e4r. Po pomyślnym zalogowaniu w przeglądarce wyświetlana jest strona główna aplikacji AdminSPA, na której można wyróżnić następujące obszary:

Pasek nagłówka:

Zawiera następujące elementy:

• Oznaczenie rodzaju środowiska (tekst i kolor). Rodzaj środowiska wybiera się podczas instalacji, dostępne wartości to Deweloperskie (kolor niebieski), Testowe (kolor żółty) i Produkcyjne (brak opisu tekstowego, pasek w kolorze czarnym).
• Lista rozwijana do wyboru aplikacji. W AdminSPA można jednocześnie pracować nad wieloma aplikacjami. Wybór konkretnej aplikacji pozwala ograniczyć listy wyświetlanych obiektów.
• Lista rozwijana do przełączania kontekstu środowiska, to jest wartości zmiennych i akcji zdefiniowanych dla określonego rodzaju środowiska (np. w środowisku deweloperskim można włączyć zmienne i akcje zdefiniowane dla środowiska testowego). Przełączanie kontekstu środowiska nie jest dostępne w środowisku produkcyjnym.
• Imię i nazwisko zalogowanego użytkownika. Kliknięcie wyświetla menu zawierające polecenie Wyloguj.

Poniżej nagłówka znajduje się pasek, na którym po lewej jest wyświetlana ścieżka do bieżącej strony, a po prawej ikona logów, to jest rejestru komunikatów zapisanych podczas działania nAxiom, oraz ikona odświeżania bieżącej zawartości kokpitu, czyli głównego obszaru strony AdminSPA.

Więcej informacji na temat aplikacji i środowisk zawiera Leksykon nAxiom.

Menu główne:

Lista elementów do budowania aplikacji podzielona na osiem sekcji menu:

• ULUBIONE
• DANE
• PROCESY BIZNESOWE
• INTERFEJS UŻYTKOWNIKA
• NARZĘDZIA
• INTEGRACJE
• ADMINISTRACJA
• POMOC

Menu główne można schować (ikona z trzema kreskami poziomymi u góry, lub ikona < u dołu), aby zwiększyć obszar roboczy.

Kokpit:

Obszar roboczy, w którym definiuje się elementy aplikacji zgodnie z wyborem dokonanym w menu głównym.

nAxiom — serwis AdminSPA

Czynności administracyjne

Samo zbudowanie przykładowej aplikacji nie wymaga zbyt wiele czasu. Jednak w przypadku pierwszej aplikacji, konieczne jest także „organizacyjne” przygotowanie środowiska, w którym aplikacja będzie uruchamiana. Minimalne elementy tego środowiska to: rola biznesowa (w odróżnieniu od ról systemowych) i użytkownik, któremu rola zostanie przypisana. W tym rozdziale zamieszczono krótkie opisy niezbędnych czynności administracyjnych. Użytkownik może wykonać je teraz, aby potem skupić się na samym procesie budowania aplikacji, albo od razu przejść do części 2. Tam, przed opisem kolejnych kroków zamieszczono informację o wymaganych czynnościach pomocniczych oraz odnośnik do odpowiedniego fragmentu w tym rozdziale.

Deklarowanie aplikacji

Aplikacja to w nAxiom kontener, który grupuje obiekty składające się na różne funkcjonalności. Ponieważ platforma umożliwia tworzenie rozbudowanych aplikacji, tych obiektów nie przypisuje się bezpośrednio do aplikacji, ale do jej modułów. Kluczową rolą aplikacji i modułów jest możliwość ich eksportowania i importowania wraz z przypisanymi im obiektami.

Kliknij polecenie Lista aplikacji z sekcji ADMINISTRACJA w menu głównym. W kokpicie zostanie wyświetlona lista aplikacji. Platforma nAxiom ma predefiniowaną deklarację aplikacji BaseApp z modułem BaseModule. Na potrzeby realizacji przykładu opisanego w tym artykule można wykorzystać tę aplikację albo zdefiniować nową.

Lista aplikacji

Kliknij przycisk Dodaj definicję, wpisz rklApp w pole Kod, Reklamacje w pole Nazwa i dowolny opis w pole Opis. Aby zapisać definicję, kliknij przycisk Zapisz i zamknij.

Nowa definicja aplikacji

Tworzenie aplikacji (funkcjonalności, a nie definicji) wymaga posiadania odpowiednich uprawnień (uprawnień PBA). Takie uprawnienia można nadać dopiero po utworzeniu definicji. Dlatego w kolejnym kroku przejdź do edycji definicji aplikacji i kliknij kartę Uprawnienia. Nastepnie kliknij kartę Użytkownicy, kliknij dane swojego profilu i zaznacz co najmniej pola wyboru Dostęp do definicji aplikacji i Aktualizacja definicji aplikacji oraz jej obiektów/modułów. Kliknij przycisk Zapisz.

Uprawnienia do aplikacji

Zmienione uprawnienia zaczynają obowiązywać dopiero po ponownym zalogowaniu się (aby sie wylogować, kliknij imię i nazwisko na pasku nagłówka i wybierz polecenie Wyloguj).

Ponownie wejdź w edycję definicji aplikacji, aby dodać moduł aplikacji. W tym celu przejdź na kartę Moduły, kliknij przycisk Dodaj moduł i wypełnij pola Nazwa i Opis. Kliknij ikonę dyskietki z prawej strony.

Nowy moduł aplikacji

Na karcie Zmienne można definiować wspomniane wcześniej zmienne, które mogą przyjmować różne wartości, zależnie od środowiska, w jakim będzie uruchamiana aplikacja. W tym przewodniku nie będą one potrzebne.

Karta zmienne

Utworzoną definicję aplikację można usunąć, pod warunkiem posiadania odpowiednich uprawnień i o ile nie przypisano do niej żadnych obiektów.

Definiowanie roli

Rola to atrybut przypisywany użytkownikowi, który określa między innymi jego uprawnienia do korzystania z funkcjonalności udostępnianych w ramach aplikacji. Chociaż w nAxiom rola jest przypisana do konkretnego modułu aplikacji, w ramach roli można przyznać dostęp do funkcjonalności definiowanych w innych modułach i aplikacjach.

Aby utworzyć nową rolę, kliknij pozycję Role biznesowe w sekcji ADMINISTRACJA w menu głównym. Zostanie wyświetlona lista ról zdefiniowanych dla poszczególnych aplikacji. Początkowo na tej liście znajdują się tylko predefiniowane role nAxiom.

Lista ról

Można przyjąć, że obsługa reklamacji jest jednym z zadań działu kontroli jakości, dlatego utwórzmy dla aplikacji Reklamacje rolę Kontroler jakości. Kliknij przycisk Dodaj rolę, w wyświetlonym oknie wybierz z listy aplikację i moduł, wpisz kod i nazwę roli. Kliknij przycisk Zapisz

Nowa rola

Definiowanie użytkownika

Wymaganie wstępne

Do wykonania tego kroku potrzebna rola biznesowa,
patrz sekcja Definiowanie roli.

Zarządzanie użytkownikami odbywa się we FrontSPA i wymaga posiadania roli biznesowej Administrator. W nAxiom jest systemowy profil użytkownik z tą rolą: nazwa logowania admin, hasło domyślne !Q2w3e4r.

1. Zaloguj się do FrontSPA.

2. Kliknij polecenie Lista użytkowników w sekcji USTAWIENIA SYSTEMOWE menu głównym.

3. W wyświetlonym oknie Lista użytkowników kliknij jasnozielony przycisk Dodaj użytkownika.

4. W pola Nazwa użytkownika, Email, Imię i Nazwisko wpisz odpowiednie dane.

5. Wybierz rolę systemową Klient z listy Rola systemowa

6. Kliknij w polu Rola biznesowa, aby wyświetlić listę dostępnych ról, i wybierz rolę Kontroler jakości.

7. W polach Hasło i Potwierdź hasło ustaw hasło dla nowego użytkownika.

8. W polu Domyślna aplikacja użytkownika wybierz aplikację, której menu będą dostępne dla danego użytkownika po włączeniu tzw. trybu pojedynczej aplikacji. Jeśli nie wybierzesz żadnej aplikacji, zostanie ustawiona aplikacja wybrana w ustawieniach systemu.

   

   Nowy użytkownik

9. Kliknij przycisk Zapisz.

Nowy użytkownik został dodany do listy użytkowników. Po zbudowaniu przykładowej aplikacji można będzie ją przetestować, używając tego konta użytkownika.

Przełącznik Aktywny służy do dezaktywowania profilu użytkownika. Jeśli profil będzie nieaktywny, nie będzie można użyć danych z profilu do zalogowania się w witrynie nAxiom. Jednocześnie użytkownik nieaktywny nie jest uwzględniany podczas sprawdzania liczby licencji dla danej roli systemowej.

Korzystanie z aplikacji zdefiniowanych w nAxiom wymaga posiadania specjalnego uprawnienia (PBA). Domyślnie użytkownik admin jest także administratorem tych uprawnień. Kliknij polecenie Uprawnienia w sekcji USTAWIENIA SYSTEMOWE, wybierz rolę na panelu z lewej strony i zaznacz pole wyboru Używanie wszystkich aplikacji.

Uprawnienie do używania aplikacji

Pierwsza aplikacja w 15 minut

W tej części opisano czynności, które należy wykonać w celu zbudowania aplikacji do obsługi prostego, jednoetapowego procesu oraz udostępnienia tej aplikacji w witrynie nAxiom. Wszystkie czynności wykonuje użytkownik zalogowany do aplikacji AdminSPA z rolą systemową Konsultant.

Model prostego procesu: rejestracja reklamacji

Celem tego artykułu jest wprowadzenie użytkownika w podstawy budowania aplikacji w systemie nAxiom. Dlatego opisany przykład nie ma wysokiej wartości użytkowej, ale uwzględni podstawowy element niemal każdego procesu biznesowego, jakim jest rejestracja danych. Opisano preces budowania najprostszej aplikacji, która umożliwi rejestrowanie reklamacji. Z biznesowego punktu widzenia będzie to skrajne uproszczenie procesu obsługi reklamacji do jednego kroku — zarejestrowania jej.

Pierwszy krok to określenie danych, które trzeba zarejestrować, i stworzenie odpowiedniej tabeli w bazie danych, w której dane będą przechowywane.

Definiowanie tabeli

Tabela, a zwykle zestaw tabel, to kluczowy element każdej aplikacji budowanej na platformie nAxiom. W prezentowanym przykładzie w tabeli będą przechowywane dane procesu biznesowego, do obsługi którego ma służyć aplikacja. Zestaw tabel pozwala modelować relacje między danymi.

W nAxiom tabele projektuje się przy użyciu narzędzia Kreator modeli danych. Aby je uruchomić, wybierz pozycję Kreator modeli danych z sekcji DANE w menu głównym.

Kreator modeli danych

Wyświetlone w kokpicie okno Kreator modeli danych zawiera panel ze zwiniętymi listami zdefiniowanych wcześniej modeli danych i innych obiektów bazodanowych z lewej strony oraz główny obszar, w którym pracuje się z definicją wybranej tabeli.

Aby utworzyć nową tabelę, kliknij przyciskiem myszy przycisk Nowy model danych.

Tworzenie modelu danych

W wyświetlonym okienku pozostaw domyślnie wybrany schemat (dbo) i wpisz nazwę tworzonej tabeli RejestrReklamacji (nazwa powinna zawierać tylko małe i wielkie litery alfabetu łacińskiego, cyfry i znaki podkreślenia). Nie zmieniaj także domyślnie zaznaczonej opcji w grupie Rodzaj modelu danych. Następnie kliknij przycisk Utwórz.

Edycja modelu

System utworzył nową tabelę i wyświetlił ją w trybie edycji. Aby jednak ta tabela była przydatna do postawionego celu, trzeba zmodyfikować jej definicję, dodając do niej pola (kolumny).

Aby zwiększyć obszar roboczy, zwiń menu boczne, klikając przycisk < z lewej strony u dołu.

W obszarze roboczym kreatora została wyświetlona „pusta” definicja tabeli w formie… tabeli. (Tak naprawdę definicja zawiera kilka pól systemowych, które można wyświetlić przełącznikiem Pokaż pola systemowe). W celu zdefiniowania pól tabeli kliknij ikonę z symbolem +. Wypełnij pola w wyświetlonym oknie dialogowym jak na ilustracji poniżej.

Dodawanie pola tabeli

Oprócz nazwy pola i typu danych można określić następujące atrybuty:

• Zakres: maksymalny rozmiar danych w polu.
• Wartość domyślna: wartość domyślna ustawiana w tym polu.
• Wymagane: określa czy dane pole może zawierać wartości null; domyślnie pole wyboru jest zaznaczone, co oznacza, że podanie wartości w tym polu jest wymagane.
• Dane wrażliwe: pozwala oznaczyć dane zapisywane w tej kolumnie jako dane wymagające szczególnego przetwarzania, np. jako dane osobowe podlegające ochronie w ramach rozporządzenia RODO.
• Wyszukiwanie: zaznaczenie tego pola wyboru spowoduje dodanie wartości z tej kolumny do indeksu wyszukiwania pełnotekstowego.
• Przypisany słownik: ten atrybut jest dostępny tylko dla danych typu Liczby całkowite i pozwala powiązać wartość w danej kolumnie ze zdefiniowanym osobno słownikiem.

Dodaj do tabeli pola EmailKlienta i TekstReklamacji i wybierz dla nich typ Tekst varchar. Dla pola EmailKlienta zmień długość ze 100 znaków na 50 (bezpośrednio edytując liczbę), a dla pola TekstReklamacji na 500, aby umożliwić zarejestrowanie dłuższego opisu zgłoszenia. W obu przypadkach zaznacz pole wyboru Wymagane.

Definicja tabeli

Tabela jest gotowa i można od razu wypróbować automatycznego kreatora dokumentu procesu biznesowego.

Generowanie elementów aplikacji

Platforma nAxiom oferuje automat, który generuje szereg elementów aplikacji na podstawie utworzonej tabeli dla standardowego modelu danych, a taki właśnie typ tabeli został wybrany podczas tworzenia tabeli w tym przykładzie. Generowanie obejmuje elementy niezbędne do prawidłowego działania tworzonej funkcjonalności, takie jak:

• definicja dokumentu,
• typ dokumentu,
• licznik autonumeracji,
• domyślny diagram procesu,
• widok formularza,
• widok listy.

Aby uruchomić generator, w widoku edycji modelu danych kliknij przycisk Generuj elementy aplikacji.

Zostanie wyświetlone okno generowania elementów aplikacji.

Okno Generowanie nowego flow

Generowany model procesu musi być przypisany do aplikacji. Możesz użyć predefiniowanej aplikacji BaseApp lub zadeklarowanej samodzielnie, patrz sekcja Deklarowanie aplikacji w części 3.

Wybierz nazwę aplikacji i modułu z list Powiąż elementy z definicją aplikacji i Powiąż elementy z definicją modułu, a w pole Prefix dla generowanych elementów wpisz przedrostek (co najmniej 3 znaki), którym zostaną poprzedzone nazwy tworzonych elementów. W przykładzie użyto dwuczłonowego przedrostka rklRjs, w którym pierwszy człon to skrót od słowa „reklamacja”, a drugi — od słowa „rejestr”.

Oprócz wymienionych pól okno zawiera listę elementów oraz przełączniki, którymi można wyłączać tworzenie poszczególnych elementów. Standardowo wszystkie elementy są potrzebne do poprawnego działania funkcjonalności, dlatego wszystkie przełączniki są domyślnie włączone.

Kliknij przycisk Rozpocznij. Po krótkiej chwili generator potwierdzi pomyślne wygenerowanie wszystkich elementów. Kliknięcie przycisku Podsumowanie spowoduje wyświetlenie komunikatu o pomyślnym wygenerowaniu elementów wraz z ich nazwami.

Informacje o wygenerowanych elementach

Efekty działania generatora, czyli utworzone elementy modelu procesu biznesowego można znaleźć w pozycjach menu głównego, np. Listy, czy Formularze, a także w pozycjach sekcji PROCESY BIZNESOWE. W następnej sekcji opisano widok listy, a opisy pozostałych elementów oraz podstawowe wiadomości na temat ich modyfikacji zamieszczono w trzeciej części tego artykułu.

Widok listy

W tym rozdziale opisano podstawowe zagadnienia dotyczące konfigurowania widoku listy. Jednak wykonanie opisanych tu czynności nie jest niezbędne, jeśli chodzi o podstawowy proces budowania aplikacji. Można go na razie pominąć i przejść od razu do następnego rozdziału. Trzeba tylko pamiętać, że na prezentowanych w dalszej części ilustracjach lista będzie wyglądać nieco inaczej niż na komputerze czytelnika.

Generator utworzył elementy potrzebne do działania aplikacji. Jednym z nich jest widok listy, który w opisywanym przykładzie będzie interfejsem użytkownika tworzonej aplikacji. W widoku listy można dodawać dane do tabeli, przeglądać je i modyfikować.

Kliknij polecenie Listy w sekcji INTERFEJS UŻYTKOWNIKA w menu głównym. Zostanie wyświetlone okno Listy.

Listy

Kliknij przycisk Edytuj w wierszu obok listy utworzonej przez generator. Zostanie wyświetlone okno Kreator listy....

Kreator listy

W górnej części okna kreatora znajduje się podgląd listy. Gdyby tabela źródłowa zawierała jakieś dane, byłyby one widoczne pod nagłówkami odpowiednich kolumn. Na podglądzie widoczny jest przycisk Nowy dokument, który w widoku listy wyświetlanym we FrontSPA powoduje wyświetlenie pustego formularza w celu zdefiniowania nowego dokumentu.

Poniżej podglądu z lewej strony okna kreatora znajduje się lista elementów, z których zbudowana jest lista, tj. przycisków i kolumn.

W centralnej części okna kreatora znajduje się szereg kart z ustawieniami definiującymi wygląd i działanie listy. Ich szczegółowy opis znajdzie użytkownik w Leksykonie nAxiom.

Domyślnie widok listy zawiera wszystkie kolumny tabeli źródłowej, w tym kolumny systemowe. Taka lista nie jest zbyt przejrzysta. Z perspektywy tworzonej aplikacji listę kolumn można ograniczyć do następujących:

• Akcje (kolumna, w której wyświetlane są przyciski; domyślnie zawiera przycisk edycji, który wyświetla dany rekord w widoku formularza)
• Id (numer kolejny reklamacji)
• Code (generowany automatycznie numer reklamacji)
• CreateDate (data utworzenia wpisu)
• EmailKlienta (adres e-mail klienta)
• TekstReklamacji (treść reklamacji)
• UserName (nazwa użytkownika, który wprowadził/zmodyfikował wpis)
• Status (status reklamacji - ta kolumna będzie przydatna podczas rozbudowy tej aplikacji opisanej w części 3)

Pozostałe kolumny nie są potrzebne i można je usunąć. W tym celu kliknij prawym przyciskiem myszy nazwę kolumny, którą chcesz usunąć i wybierz polecenie Usuń element z menu kontekstowego. Usuń wszystkie kolumny, które nie będą potrzebne na liście.

Używając poleceń Przenieś do góry/Przenieś w dół również z menu kontekstowego (lub drag&drop), możemy zmieniać kolejność kolumn na liście. Warto przy tym zwrócić uwagę, że wprowadzone zmiany są od razu uwzględniane na podglądzie, jednak trzeba pamiętać, aby te zmiany zapisać — klikając przycisk Zapisz.

Można jeszcze zmodyfikować tekst wyświetlany w nagłówkach kolumn listy, aby był czytelny dla przyszłych użytkowników. W tym celu kliknij nazwę kolumny na liście w kreatorze, aby wyświetlić jej ustawienia, i wpisz nazwę w polu Nazwa. Zapisz zmiany. Na ilustracji przedstawiono widok listy, który będzie używany w dalszej części tego przewodnika.

Zmodyfikowany widok listy

Menu użytkownika

Aplikacje tworzone na platformie nAxiom są udostępniane użytkownikom końcowym w aplikacji FrontSPA — z lewej strony okna przeglądarki jest wyświetlane menu główne, podzielone na sekcje. W sekcjach znajdują się pozycje, które uruchamiają odpowiednie widoki formularza lub listy. W tym kroku opisano definiowanie takiego menu dla zmodyfikowanego przed chwilą widoku listy.

Planowana struktura menu wygląda następująco:

# sekcja menu
Reklamacje

# pozycja sekcji menu
  - Rejestr reklamacji

Kliknij pozycję Menu użytkownika w sekcji INTERFEJS UŻYTKOWNIKA w menu głównym. Zostanie wyświetlona lista sekcji menu głównego. W przypadku nowej instalacji platformy nAxiom lista jest pusta. Sekcje są logicznymi elementami struktury menu, które służą do grupowania poszczególnych pozycji według określonych kryteriów.

Kliknij zielony przycisk Dodaj sekcję menu, aby dodać sekcję do menu głównego. Wpisz wartości w pola Kod i Nazwa, wybierz aplikację i moduł, a następnie kliknij przycisk Zapisz.

Nowa sekcja menu

Zostanie wyświetlone okno Edycja sekcji menu, w którym trzeba dodać pozycję menu. Kliknij przycisk Dodaj pozycje menu i wypełnij kolejno pola, jak na ilustracji poniżej. W celu wyboru ikony kliknij przycisk z symbolem lupy i znajdź odpowiednią ikonę.

Definicja pozycji menu

Pole Kod formatki ma zawierać odnośnik do formularza lub listy, którą będzie wywoływać definiowana pozycja menu. Domyślnie po kliknięciu przycisku Utwórz jest wyświetlana lista zdefiniowanych formularzy. Aby wyświetlić zdefiniowane listy, włącz przełącznik Wybieraj wśród zdefiniowanych list.

Tworzenie kodu formatki — listy

Wybierz listę i ponownie kliknij Utwórz, aby zatwierdzić wybór. W polu zostanie wpisany kod listy. Kliknij Zapisz, aby zapisać pozycję menu. Po udostępnieniu aplikacji, kliknięcie pozycji Rejestr reklamacji spowoduje wyświetlenie listy, w której można będzie obsługiwać uproszczone zgłoszenia reklamacyjne.

Jeszcze raz kliknij przycisk Zapisz, aby zapisać ostateczny kształt sekcji menu.

Nadawanie uprawnień do funkcjonalności

Wymaganie wstępne

Do wykonania tego kroku potrzebna jest zdefiniowana rola biznesowa, patrz sekcja Definiowanie roli we wprowadzeniu.

Jak wspomniano na wstępie, aby użytkownik miał dostęp do aplikacji, musi mieć przypisaną rolę, która ma prawo dostępu do tej aplikacji.

1. Kliknij pozycję Role biznesowe w sekcji ADMINISTRACJA w menu głównym. Zostanie wyświetlona lista ról zdefiniowanych dla poszczególnych aplikacji.

   

   Zarządzanie rolami

2. Kliknij przycisk Uprawnienia w wierszu roli, której chcesz nadać uprawnienia do utworzonej funkcjonalności (w tym przykładzie Kontroler jakości). Zostanie wyświetlona lista Edycja uprawnień roli z sekcjami i pozycjami menu, które można udostępnić dla danej roli. Na liście znajdują się tylko zdefiniowane przed chwilą sekcja i pozycja menu.

3. Zaznacz pola wyboru obok sekcji i kliknij przycisk Zapisz.

   

   Edycja uprawnień roli

Teraz każdy użytkownik z przypisaną rolą Kontroler jakości będzie mógł wyświetlać listę, wybierając pozycję Rejestr reklamacji z sekcji Reklamacje w menu głównym.

Uruchomienie aplikacji

Wymaganie wstępne

Do wykonania tego kroku potrzebne jest konto użytkownika z przypisaną rolą Kontroler jakości, patrz sekcja Definiowanie użytkownika we wprowadzeniu. Tam też opisano przypisanie roli użytkownikowi.

Zaloguj się do swojej witryny nAxiom, używając danych logowania użytkownika z przypisaną rolą Kontroler jakości (w przykładzie profil jtester). Po zalogowaniu nastąpi przekierowanie do FrontSPA i zostanie wyświetlone okno zbudowanej aplikacji z pustym kokpitem i menu głównym.

Strona główna aplikacji

Po kliknięciu pozycji menu Rejestr reklamacji zostanie wyświetlona pusta lista.

Lista rejestru reklamacji

Z lewej strony u góry listy znajduje się przycisk Nowy dokument. Kliknij go, aby dodać nowy wpis. Zostanie wyświetlony formularz, który został automatycznie wygenerowany poleceniem Generuj elementy aplikacji. Formularz składa się z następujących sekcji:

• Nagłówek (przyciski Zapisz i Anuluj)
• Sekcja pól systemowych
• Sekcja pól użytkownika
• Sekcja komentarzy
• Sekcja załączników

Oprócz możliwości zapisywania danych, formularz oferuje możliwość komentowania wpisów oraz dołączania załączników (wymagana osobna konfiguracja).

Formularz reklamacji

Pole Type1 nie jest oznaczone jako wymagane, wiec może pozostać puste. Wpisz wartości w pola EmailKlienta i TekstReklamacji (etykiety tych pól będzie można zmienić, aby poprawić czytelność). Na koniec kliknij przycisk Zapisz.

Zapisanie danych

Po kliknięciu pozycji menu Rejestr reklamacji zostanie ponownie wyświetlona widok listy z zarejestrowaną reklamacją.

Zarejestrowana reklamacja w widoku listy

Tak w zarysie wygląda proces tworzenia i udostępniania aplikacji na platformie nAxiom. Aby zachować przejrzystość, w opisywanym przykładzie pominięto wiele ważnych zagadnień. Niektóre z nich zostaną przybliżone w następnej części.

Możesz zmienić domyślne nazwy/opisy wygenerowanych elementów aplikacji, aby zwiększyć czytelność i przejrzystość interfejsu, zarówno po stronie AdminSPA, jak i FrontSPA. Na przykład opis definicji dokumentu biznesowego jest używany jako nazwa konkretnego dokumentu tworzonego w ramach tej definicji, dlatego znacznie bardziej zrozumiały będzie tekst Zgłoszenie reklamacji, zamiast Dokument biznesowy dla tabeli dbo.RejestrReklamacji. Podobnie można zmienić nazwę listy na Lista zgłoszeń reklamacji, a formularza na Formularz zgłoszenia reklamacji. Takie nazwy będą widoczne na ilustracjach w następnej części.

Wstęp do modelowania procesów

Workflow, czyli model procesu

W poprzedniej części tego dokumentu opisano proces tworzenia prostej aplikacji, która umożliwia uproszczone rejestrowanie zgłoszeń reklamacyjnych. W tej części chcielibyśmy pokazać, jak rozbudować tę aplikację, aby umożliwiła obsługę procesu składającego się z kliku kroków i angażującego do obsługi zgłoszenia użytkowników z innymi rolami. Należy od razu zaznaczyć, że niektóre aspekty „biznesowe” zostały tu świadomie pominięte lub uwzględnione w sposób symboliczny.

Głównym elementem definicji aplikacji, a właściwie funkcjonalności aplikacji (bo na platformie nAxiom aplikacja jest kontenerem gromadzącym funkcjonalności), jest definicja dokumentu. Taką definicję tworzy się automatycznie poleceniem Generuj elementy aplikacji dostępnym w module Kreator modeli danych, co opisano w sekcji Generowanie elementów aplikacji, w części 2.

Oprócz poznanych już obiektów tworzonych wraz z definicją dokumentu, jak widok listy i widok formularza, są też inne, które stanowią zalążek logiki budowanej aplikacji. Obiekty te zgrupowano w sekcji PROCESY BIZNESOWE w menu głównym AdminSPA. W tej sekcji użytkownik ma dostęp do definicji dokumentów, typów dokumentów, liczników autonumeracji, definicji statusów i diagramów procesów.

Kliknij pozycję Diagramy procesów. Zostanie wyświetlona lista diagramów dla par [definicja dokumentu; tabela] (dla tabeli można utworzyć kilka definicji dokumentu, a tym samym kilka diagramów procesu). W prezentowanym przykładzie jest tylko jeden diagram wygenerowany automatycznie podczas generowania elementów aplikacji.

Diagramy procesów

Kliknij przycisk Edytuj w wierszu tej definicji, aby zobaczyć, jak ona wygląda. Spowoduje to uruchomienie w nowej karcie aplikacji WorkflowSPA. Jest to graficzny edytor procesów, w którym model procesu jest wyświetlany w formie diagramu.

Workflow nAxiom — edytor diagramów procesów

Okno edytora składa się z kilku głównych obszarów:

1. Przybornik (z lewej strony) — zawiera bloki, których można używać do tworzenia diagramu procesu.
2. Obszar roboczy (w środku) — obszar, w którym definiuje się diagram procesu.
3. Pasek narzędzi ( u góry) — zawiera kontrolki do zarządzania diagramem i jego wyglądem. Są to (od lewej):
   • Zapisz zmiany: zapisuje zmiany diagramu
   • Cofnij: cofa ostatnią zmianę
   • Przywróć: przywraca cofniętą zmianę
   • Usuń: czyści obszar roboczy ze wszystkich elementów
   • Eksport SVG: eksportuje zawartość obszaru roboczego do pliku SVG
   • Eksport PNG: eksportuje zawartość obszaru roboczego do pliku PNG
   • Drukuj: otwiera okno ustawień drukowania obszaru roboczego
   • Pełny ekran: włącza/wyłącza tryb pełnoekranowy
   • Na wierzch: przenosi dany element na pierwszy plan w przypadku nakładających się elementów (aby ułatwić manipulowanie)
   • Pod spód: przenosi dany element „pod spód” w przypadku nakładających się elementów (aby ułatwić manipulowanie)
   • Uporządkuj: automatycznie rozmieszcza elementy w obszarze roboczym
   • Wypełnij: automatycznie dostosowuje powiększenie obszaru roboczego
   • Powiększenie: umożliwia ustawienie dowolnego powiększenia obszaru roboczego
   • Rozmiar siatki: określa gęstość pomocniczej siatki punktów przyciągania na obszarze roboczym; bloki na obszarze roboczym są przyciągane do najbliższego punktu
   • Linie wyrównywania: włącza/wyłącza wyświetlanie pomocniczych linii służących do wyrównywania położenia elementów względem siebie
   • Nazwy przejść bez przycisków: włącza/wyłącza wyświetlanie na diagramie nazw przejść, które nie mają przycisków (np. przejście z bloku Start do bloku Utworzony)
   • Pomoc: wyświetla okno z tekstem pomocy
   • Tłumaczenia i pomoc: wyświetla listę z tłumaczeniami nazw elementów diagramu; w tym oknie można także wpisać tekst pomocy dla poszczególnych statusów.
4. USTAWIENIA ELEMENTU (z prawej strony u góry) — sekcja, w której określa się właściwości elementu zaznaczonego na diagramie.
5. MINIMAPA (z prawej strony u dołu) — ułatwia orientację w przypadku bardziej rozbudowanych diagramów.

Bloki na diagramie symbolizują statusy, jakie może przyjmować zestaw danych przetwarzanych w danym procesie, a łącząca je linia wskazuje kolejność wykonywania czynności w procesie.

Kliknięcie bloku na diagramie powoduje wyświetlenie wokół niego ramki z elementami sterującymi (rozmiar, obrót, usuwanie, łączenie z innymi blokami i usuwanie połączeń) oraz jego właściwości w obszarze USTAWIENIA ELEMENTU z prawej strony. W przypadku bloku kończącego jedynym parametrem, który można ustawić jest reprezentowany przezeń status.

Właściwości bloku w edytorze diagramów

Diagram widoczny na ilustracji to zalążek do dalszej rozbudowy. Zaczyna się, jak wszystkie diagramy, od bloku Start i kończy blokiem oznaczającym zadanie ręczne, który domyślnie wskazuje status Utworzony. Należy to zinterpretować w ten sposób, że wprowadzenie i zapisanie danych zgłoszenia reklamacyjnego powoduje nadanie mu statusu Utworzony. Ten model jest zgodny z przyjętymi założeniami. Celem pierwszej aplikacji miało być rejestrowanie zgłoszeń reklamacyjnych.

Jak wspomniano, bloki na diagramie wskazują statusy, natomiast łączące je linie to przejścia, które reprezentują czynności wykonywane „pomiędzy” kolejnymi statusami. Po kliknięciu przejścia na diagramie w sekcji USTAWIENIA ELEMENTU wyświetlanych jest kilka parametrów, które zostaną pokrótce opisane w dalszej części.

Właściwości przejścia w edytorze diagramów

Oprócz dwóch wymienionych, w przyborniku edytora z lewej strony znajdują się inne bloki, które mają nieco inne funkcje. Ich szczegółowy opis zawiera Leksykon nAxiom.

Obsługa reklamacji 2.0 — założenia

Teraz można rozbudować proces rejestrowania reklamacji o dodatkowe kroki. Zgłoszenie trzeba będzie potwierdzić w dziale technicznym, a opinia z tego działu będzie podstawą do podjęcia decyzji o uwzględnieniu reklamacji (i np. przyznaniu upustu w abonamencie) lub jej odrzuceniu. Tę decyzję podejmie osoba z rolą kierowniczą. Decyzja trafi do pracownika, który zgłoszenie zarejestrował, a ten, po przekazaniu informacji klientowi, zamknie zgłoszenie. Schemat procesu przedstawiono poniżej w notacji UML. Zadaniem użytkownika będzie odtworzenie go w edytorze workflow. Resztę zrobi nAxiom!

Na podstawie powyższego diagramu można przedstawić opisowo przebieg procesu. Czarna kropka oznacza start procesu.

1. Po zapisaniu zgłoszenia przez pracownika kontroli jakości ma ono status Utworzono. Po utworzeniu zgłoszenia pracownik klika przycisk Potwierdź w DT, co powoduje zmianę stanu na Czeka na opinię.
2. Zgłoszenia w stanie Czeka na opinię wymagają, aby pracownik działu technicznego na podstawie dzienników pracy systemu ocenił, czy zgłaszane problemy miały miejsce po stronie dostawcy usług. Po wpisaniu uwag w komentarzu do zgłoszenia pracownik klika przycisk Prześlij do rozpatrzenia, co powoduje zmianę stanu na Czeka na rozpatrzenie.
3. Zgłoszenia ze stanem Czeka na rozpatrzenie są rozpatrywane przez kierownika działu kontroli jakości, który na podstawie przekazanej opinii może je uwzględnić i np. przyznać bonifikatę w opłacie abonamentowej lub odrzucić jako niezasadne. Swoją decyzję kierownik wpisuje w komentarzu i klika przycisk Uwzględnij lub Odrzuć, zmieniając stan zgłoszenia odpowiednio na Uwzględniono lub Odrzucono.
4. Zgłoszenia w stanie Uwzględniono i Odrzucono „trafiają” z powrotem do pracownika kontroli jakości, który ma obowiązek przekazać decyzję klientowi, np. e-mailem i zamknąć sprawę przyciskiem Zamknij sprawę, powodując zmianę statusu na odpowiednio Zamknięto (uwzględniono) lub Zamknięto (odrzucono).

W porównaniu z pierwszym scenariuszem, ten jest znacznie bardziej rozbudowany.

Definiowanie statusów

Podobnie jak w poprzedniej części, także i teraz konieczne będzie określenie elementów aplikacji, które są niezbędne do jej działania, to jest ról i statusów. Zacznijmy od tych ostatnich. Budowana aplikacja implementuje model procesu, w którym zdefiniowano pięć stanów:

• Utworzono
• Czeka na opinię
• Czeka na rozpatrzenie
• Uwzględniono
• Odrzucono
• Zamknięto (uwzględniono)
• Zamknięto (odrzucono)

Na razie zdefiniowano tylko pierwszy z nich (tak naprawdę zdefiniowany status to Utworzony, ale nazwę można łatwo zmienić), pozostałe trzeba zdefiniować. Można to zrobić, używając polecenia Definicje statusów w sekcji PROCESY BIZNESOWE w menu głównym, które pozwala definiować nowe statusy dla poszczególnych definicji dokumentu biznesowego. Można także skorzystać z wygodnej możliwości definiowania nowych statusów bezpośrednio na diagramie podczas dodawania kolejnych bloków.

Jeśli chcesz najpierw zdefiniować statusy, kliknij polecenie Definicje statusów, a następnie przycisk Nowy status, wpisz kod i opis w pola okna Tworzenie statusu, oraz wybierz definicję dokumentu biznesowego z listy rozwijanej jak na poniższej ilustracji. Pamiętaj, aby za każdym razem kliknąć przycisk Zapisz. Wpisując kod, warto zachować spójność z kodem istniejącego statusu, tj. [kodDokumentuBiznesowego]_[opisStatusu]. Nie jest to wymagane, ale ułatwi orientację, kiedy na platformie będzie wiele definicji dokumentów i każdy będzie mieć swoje statusy. Powtórz te czynności dla pozostałych statusów.

Aby zmienić nazwę istniejącego statusu (forma Utworzono będzie „uniwersalna”), kliknij przycisk Edytuj z prawej strony tego statusu, popraw tekst w polu Opis i kliknij przycisk Zapisz.

Tworzenie statusu

Statusy można także definiować i edytować w edytorze diagramów. Po zaznaczeniu bloku na diagramie, w obszarze USTAWIENIA ELEMENTU z prawej strony, obok listy Status są dostępne przyciski Dodaj i Edytuj, które wywołują odpowiednio okna Tworzenie statusu i Edycja statusu. Ponadto po przeciągnięciu bloku z przybornika na diagram jest wyświetlana propozycja zdefiniowania nowego statusu.

Definiowanie ról i użytkowników

Przed przejściem do budowania aplikacji można jeszcze zdefiniować potrzebne role, przypisać im uprawnienia do aplikacji oraz zdefiniować użytkowników, którzy w ramach tych ról będą korzystać z aplikacji. Te czynności opisano w poprzedniej części, w sekcjach Definiowanie roli, Definiowanie użytkownika oraz Nadawanie uprawnień do funkcjonalności. Można zatem pominąć opisy odpowiednich czynności, a jedynie wypunktować zadania do wykonania:

1. Utwórz role:
   • Kierownik KJ
   • Pracownik DT
2. W uprawnieniach utworzonych ról włącz dostęp do polecenia menu Rejestr reklamacji
3. Przypisz rolom uprawnienia do używania wszystkich aplikacji, tak jak dla pierwszego profilu użytkownika. (Zaloguj się jako admin, wybierz z menu polecenie Uprawnienia w sekcji Zarządzanie uprawnieniami, wybierz rolę na panelu z lewej strony i zaznacz pole wyboru Używanie wszystkich aplikacji).
4. Utwórz konta użytkowników dla:
   • Anna Kajot-Kierownik, rola biznesowa Kierownik KJ
   • Sławomir Techniczny, rola biznesowa Pracownik DT

Zanotuj nazwy logowania i hasła przypisane tym użytkownikom. Po wykonaniu tych czynności listy ról i użytkowników wyglądają jak na poniższych ilustracjach.

Lista ról

Lista użytkowników

Tworzenie workflow

Praca w edytorze workflow jest intuicyjna. Wystarczy przeciągnąć odpowiednie bloki z przybornika na obszar roboczy, połączyć je ze sobą przejściami oraz ustawić właściwości wszystkich elementów zgodnie z założeniami. Z przedstawionego wcześniej schematu wynika, że potrzebne będą następujące bloki (w nawiasie podano statusy):

• start
• zadanie ręczne (utworzono)
• zadanie ręczne (czeka na opinię)
• akceptacja (czeka na rozpatrzenie)
• zadanie ręczne (uwzględniono)
• zadanie ręczne (odrzucono)
• koniec (uwzględniono)
• koniec (odrzucono)

Przeciągnij odpowiednie bloki z przybornika i przypisz im odpowiednie statusy, używając listy Status w obszarze USTAWIENIA ELEMENTU z prawej strony, jak na ilustracji poniżej. Jeśli statusy nie zostały utworzone, utwórz je, dodając poszczególne bloki. Po wykonaniu tych czynności zawartość obszaru roboczego powinna przypominać ilustrację poniżej.

Diagram stanów — bloki

Kolejna ilustracja przedstawia właściwości bloku akceptacji, które należy ustawić. Są to: rola, która tę czynność wykonuje, oraz liczba użytkowników akceptujących dokument. Zaznacz ten blok i z listy Akceptacja przez role wybierz pozycję Kierownik KJ, a w polu Ilość wymaganych akceptacji ustaw wartość 1.

Blok akceptacji — właściwości

Kolejna czynność to połączenie bloków. W tym celu trzeba przeciągnąć i upuścić na blok docelowy strzałkę widoczną w prawym dolnym rogu zaznaczonego bloku wyjściowego. Trzeba przy tym zwrócić uwagę, żeby po dociągnięciu linii do obiektu docelowego została wyświetlona pomarańczowa ramka wokół niego. Tylko wtedy oba bloki zostaną połączone przejściem. W przeciwnym razie strzałka będzie wyświetlana linią przerywaną, wskazując na brak połączenia z blokiem docelowym. Każdy blok można łączyć z kilkoma blokami docelowymi, powtarzając te same czynności: zaznacz blok, przeciągnij linię na obiekt docelowy i puść.
Połącz bloki w obszarze roboczym, jak na ilustracji poniżej.

Diagram stanów — przejścia

Przejście dokumentu z jednego statusu do kolejnego wymaga interwencji użytkownika — kliknięcia przycisku. Aby taki przycisk zdefiniować, należy podać jego nazwę w polu Nazwa przycisku we właściwościach przejścia oraz z listy Wyświetl dla ról wybrać rolę, dla której taki przycisk będzie widoczny na formularzu podczas przetwarzania dokumentu. Pozostałe właściwości przejść opisano w Leksykonie nAxiom.

Nadaj przyciskom takie same nazwy, jakimi opisano przejścia na diagramie stanów dla procesu obsługi reklamacji. W przypadku bloku akceptacji konieczne jest dodatkowo wskazanie wyniku akceptacji dla obu przycisków. Służy do tego lista Rezultat akceptacji, z której trzeba wybrać odpowiednią wartość. Dla każdego przycisku ustaw rolę, dla której przycisk ma być widoczny. Po zdefiniowaniu przycisków dla przejść diagram wygląda jak na poniższej ilustracji. W celu poprawienia czytelności zmieniono rozmieszczenie bloków na diagramie, pozostawiając jednak przejścia bez zmian.

Diagram stanów — właściwości przycisku

I to właściwie wszystko! Wystarczy zapisać zmiany i logować się kolejno jako użytkownicy z różnymi rolami, aby sprawdzić działanie aplikacji.

Testowanie aplikacji

Zacznij od pracownika z rolą Kontrola jakości i zarejestruj nowe zgłoszenie. Po wpisaniu danych i kliknięciu przycisku Zapisz aplikacja zapisze dane, nada numer kolejny zgłoszeniu i wyświetli przy nim status Utworzono. Ponadto poniżej pojawi się dodatkowy przycisk Potwierdź w DT, informacja u użytkowniku, który wykonał poprzedni krok, i data przekazania dokumentu (zmiany statusu).

Nowe zgłoszenie reklamacyjne

Kliknij przycisk Potwierdź w DT i po wyświetleniu potwierdzenia sprawdź, czy status zgłoszenia zmienił się na Czeka na opinię. Następnie wyloguj się i zaloguj jako użytkownik z rolą Pracownik DT. Na liście reklamacji kliknij ikonę edycji w wierszu reklamacji ze statusem Czeka na opinię. W polu komentarza u dołu z lewej strony wpisz komentarz. Zatwierdź go przyciskiem ze strzałką i kliknij przycisk Prześlij do rozpatrzenia. Status zgłoszenia zmieni się na Czeka na rozpatrzenie.

Zgłoszenie z opinią DT, które czeka na rozpatrzenie

Ponownie wyloguj się i zaloguj się jako użytkownik z rolą Kierownik KJ. Po zalogowaniu zwróć uwagę, że z prawej strony u góry przy ikonie przedstawiającej wiadomość znajduje się cyferka 1. To powiadomienie o dokumencie oczekującym na akceptację. Kliknij ikonę, kliknij wyświetlone powiadomienie i kliknij link Przejdź do dokumentu, aby wyświetlić dokument do akceptacji.

Powiadomienie o dokumencie oczekującym na akceptację

Na formularzu, zgodnie z projektem, są przyciski Odrzuć i Uwzględnij. Wpisz komentarz o podjętej decyzji i kliknij przycisk Uwzględnij. Status zgłoszenia zmieni się na Uwzględniono.

Uwzględnione zgłoszenie reklamacji

Ostatnim etapem jest zamknięcie zgłoszenia przez pracownika, który zarejestrował zgłoszenie. Ponownie zaloguj się, jako użytkownik z rolą Kontrola jakości i przejdź do edycji zgłoszenia w statusie Uwzględniono. Ze względu na ograniczone ramy tego przykładu, założono, że powiadomienie klienta o decyzji odbywa się poza platformą nAxiom, choć oferuje ona komponenty niezbędne do automatycznej obsługi tego procesu. Są one opisane w Leksykonie nAxiom. Teraz można ograniczyć się do dopisania komentarza i kliknięcia przycisku Zamknij sprawę. Jej status zmieni się na Zamknięto (uwzględniono).

Zamknięcie sprawy

Tak wyglądają podstawy budowania aplikacji w nAxiom. To narzędzie, które rzeczywiście pozwala zmieniać pomysły w gotowe rozwiązania!

Modyfikowanie widoku formularza

W poprzedniej części opisano krótko zasady modyfikowania widoku listy, w tej przedstawiono podstawowe informacja o modyfikowaniu widoku formularza. Listy i formularze to dwa podstawowe składniki interfejsu użytkownika aplikacji budowanych w nAxiom. Od ich projektu zależy ergonomia pracy użytkownika, a także prawidłowe działanie aplikacji.

Aby przejść do modyfikacji formularza, zaloguj się w AdminSPA (https:\\adres_platformy_naxiom\admin) i kliknij menu Formularze w sekcji INTERFEJS UŻYTKOWNIKA w menu głównym. Na wyświetlonej liście jest tylko jeden formularz utworzony automatycznie w procesie generowania dokumentu procesu biznesowego. Kliknij przycisk Edycja, aby przejść do edycji tego formularza.

Kreator formularza

Widok formularza ma dwa tryby edycji. Widoczny na ilustracji powyżej jest podobny do trybu edycji widoku listy. Lista elementów formularza z lewej strony i obszar ustawień z kilkoma kartami w centralnej części. W trybie edycji listy był jeszcze podgląd, którego tu nie ma. Drugi tryb edycji jest wyświetlany po kliknięciu przycisku Designer z prawej strony u góry. W tym trybie z lewej strony znajduje się przybornik z podstawowymi kontrolkami (pole tekstowe, przycisk, lista, pole numeryczne, pole daty, pole wyboru). W centralnej części znajduje się formularz, a z prawej strony hierarchiczna lista Struktura. Kliknięcie dowolnej pozycji na tej liście powoduje zaznaczenie odpowiadającego elementu na formularzu, a zamiast listy z prawej strony zostają wyświetlone właściwości zaznaczonego elementu. Właściwości są wyświetlane również po kliknięciu dowolnego elementu bezpośrednio na formularzu.

Designer formularza — edytor graficzny

Ogólna struktura formularza obejmuje następujące elementy:

• Toolbar — pasek narzędzi z przyciskami (domyślnie Zapisz i Anuluj); na pasku narzędzi jest także wyświetlana nazwa dokumentu, jego numer i status
• Wiersz — „poziomy” kontener najwyższego poziomu układu graficznego formularza
• Kolumna — „pionowy” element układu graficznego formularza
• Sekcja — element logiczny, grupujący kontrolki formularza; kolumna może mieć kilka sekcji, każda z nich jest wówczas wyświetlana jako karta widoczna po kliknięciu odpowiedniej zakładki.

Kliknij sekcję Toolbar, aby wyświetlić jej właściwości. Pole Etykieta służy do określenia tekstu wyświetlanego w nagłówku formularza. Standardowo, po otwarciu pustego formularza jest wyświetlany tekst Nowy Wpis, a po zapisaniu rekordu Dokument {nr}. Te teksty można zmienić, wpisujące je w tym polu. Wskazówki dotyczące składni są wyświetlane po kliknięciu ikony ze znakiem zapytania. Wpisanie ciągu Reklamacja {@Code} || Nowa reklamacja spowoduje, że dla nowego rekordu będzie wyświetlany nagłówek Nowa reklamacja, a po zapisaniu np. Reklamacja 002/2021. Pamiętaj, aby zapisać zmiany formularza.

Zmiana etykiety formularza

Kliknij przycisk Anuluj w sekcji Toolbar i przyjrzyj się jego właściwościom. U dołu listy znajduje się etykieta Akcje, a przy niej przycisk Ustaw. Kliknij go, aby zobaczyć, w jaki sposób określa się działanie przycisków na formularzu. Do przycisku przypisano akcję Zamknij formularz. W wyświetlonym oknie dialogowym kliknij przycisk Wybierz akcję z listy, aby wyświetlić listę dostępnych akcji. Jeśli do tworzenia opisywanego tutaj przykładu użyto pustej bazy danych, dostępne będą tylko akcje systemowe.

Platforma nAxiom oferuje bardzo bogate możliwości definiowania akcji wykorzystujących różne mechanizmy działania. Są to np. akcje e-mail, akcje importu/eksportu, akcje JavaScript, akcje SQL i inne. Opis akcji znajduje się w Leksykonie nAxiom.

Wybór akcji wywoływanej przyciskiem

Przyciskom można przypisywać skróty klawiszowe. Służy do tego lista rozwijana Skrót klawiszowy, z której można wybrać jedną z predefiniowanych kombinacji klawiszy. Tekst wyświetlany na przycisku można zmienić w polu Nazwa, a jego kolor wybrać z palety Kolor poniżej.

W ramach podstawowej indywidualizacji formularza zmień napis na przycisku Anuluj na Zamknij, a jego kolor na szary. Następnie zmień etykiety przy polach tekstowych w sekcji pól użytkownika. Kliknij pole EmailKlienta i w sekcji właściwości wpisz nowy tekst w polu Nazwa. Powtórz tę czynność dla pola TekstReklamacji. Pamiętaj o zapisywaniu zmian przyciskiem Zapisz. Efekty wprowadzonych zmian możesz ocenić po kliknięciu karty Podgląd powyżej paska narzędzi.

Podgląd formularza po wprowadzonych zmianach

Domyślnie wyświetlany jest podgląd pustego formularza, jednak po wpisaniu identyfikatora dokumentu w polu Id rekordu powyżej podglądu i kliknięciu przycisku OK, można wyświetlić podgląd zmodyfikowanego formularza dla dowolnego zapisanego dokumentu. Nagłówek formularza nie jest wyświetlany na podglądzie.

Koniec

Na tym kończy się wprowadzenie do platformy nAxiom. Jeśli czytelnik czuje niedosyt i chęć dogłębniejszego poznania tego wszechstronnego narzędzia, cel tego dokumentu został osiągnięty. Polecamy korzystanie z artykułów przeglądowych oraz obszernego Leksykonu nAxiom.