Transakcja to pojedynczy plik aspx odpowiadający jednej akcji użytkownika - na przykład dopisaniu dokumentu albo wyświetleniu zestawienia. Zawiera kod serwerowy C# i kod kliencki jQuery, a jego położenie w folderze roli decyduje o tym, kto ma do niego dostęp.
Czym jest transakcja
Platforma StudioSystem została zbudowana w oparciu o technologię ASP.NET, a jej podstawową jednostką funkcjonalną jest transakcja. Pod tą nazwą kryje się pojedynczy plik aspx reprezentujący jedną konkretną czynność dostępną dla użytkownika: dopisanie dokumentu przyjęcia, wyświetlenie stanu magazynowego, wygenerowanie wydruku czy zatwierdzenie awizacji.
Takie podejście różni się od aplikacji monolitycznej, w której jeden duży moduł obsługuje wiele powiązanych funkcji. Tutaj każda akcja jest osobnym, samodzielnym plikiem. W praktyce oznacza to kilka konkretnych konsekwencji:
- Rozbudowa nie narusza istniejących funkcji - dodanie nowej transakcji to dodanie pliku, a nie przebudowa modułu.
- Uprawnienia są czytelne - dostęp wynika z tego, w którym folderze leży plik.
- Diagnostyka jest prostsza - błąd dotyczy jednej transakcji, a nie całego obszaru aplikacji.
- Wdrożenia są mniejsze - zmiana obejmuje pojedyncze pliki, nie całą aplikację.
- Ten sam mechanizm obsługuje wiele modułów - transakcja uniwersalna działa w WMS, YMS i RMA jednocześnie.
Budowa pojedynczej transakcji
Na jedną transakcję składają się zwykle trzy współpracujące pliki. Ich rozdzielenie odpowiada podziałowi na to, co dzieje się na serwerze, i to, co widzi użytkownik w przeglądarce.
| Plik | Gdzie się wykonuje | Za co odpowiada |
|---|---|---|
nazwa.aspx | Serwer - warstwa widoku | Struktura strony i rozmieszczenie kontrolek formularza lub zestawienia |
nazwa.aspx.cs | Serwer - kod C# | Logika biznesowa, walidacja i komunikacja z bazą danych SQL Server |
nazwa.js | Przeglądarka - jQuery | Dynamika interfejsu, obsługa zdarzeń i wywołania do serwera bez przeładowania strony |
Podział ten ma znaczenie praktyczne przy modyfikacjach. Zmiana sposobu prezentacji danych - kolejności pól czy zachowania formularza po wpisaniu wartości - najczęściej dotyczy wyłącznie pliku JavaScript. Zmiana reguły biznesowej, na przykład warunku blokującego wydanie towaru, oznacza ingerencję w kod C#. Dzięki temu dwa różne rodzaje zmian nie wchodzą sobie w drogę.
Podział na foldery ról
Kilkaset plików transakcji wymaga porządku. W StudioSystem porządek ten opiera się na folderach odpowiadających rolom systemowym - a jednocześnie stanowi warstwę kontroli dostępu. Użytkownik widzi wyłącznie transakcje z folderów przypisanych do jego roli.
| Folder | Rola | Zakres transakcji |
|---|---|---|
\role_sys\ | Systemowa | Transakcje uniwersalne wspólne dla wszystkich modułów oraz funkcje administracyjne |
\role_adm\ | Administrator | Parametry, skorowidze, numeracja i dane podstawowe |
\role_wms\ | Magazyn (WMS) | Przyjęcia, wydania, inwentaryzacja i raportowanie magazynowe |
\role_maw\ | Awizacje (YMS) | Rezerwacja okien czasowych, obsługa bram i zarządzanie placem |
\role_nar\ | Narzędziownia (TCS) | Gospodarka narzędziowa i kontrola wydań narzędzi pracownikom |
\role_rek\ | Reklamacje (RMA) | Rejestracja zgłoszeń reklamacyjnych, napraw i zwrotów |
\role_pal\ | Palety (PAL) | Rejestr aktywności produkcyjnej i gospodarka paletowa |
Warto zwrócić uwagę na nazewnictwo historyczne: folder \role_maw\ obsługuje dziś moduł awizacyjny opisywany jako YMS, a \role_nar\ - narzędziownię, czyli Studio TCS.net. Skrót w nazwie katalogu nie zawsze odpowiada obecnej nazwie handlowej modułu, co bywa źródłem nieporozumień przy pierwszym kontakcie ze strukturą plików.
Panel startowy i wybór roli
Podział na role jest widoczny dla użytkownika od pierwszego ekranu po zalogowaniu. Panel startowy SuperVisor prezentuje dostępne role w formie kolorowych kafli, gdzie kolor grupuje pozycje należące do tego samego obszaru systemu.
Jeden ekran, wiele obszarów systemu
Kafle takie jak WMS, MAW, NAR, PAL czy REK odpowiadają folderom transakcji opisanym wyżej. Wybór kafla ustawia rolę systemową i decyduje o tym, jakie pozycje menu zobaczy użytkownik.
Na panelu widać też, że jedna rola może mieć kilka wariantów dopasowanych do stanowiska pracy. Obszar awizacyjny udostępnia osobne wejścia dla bramy i ochrony, magazynu, dostawcy, spedytora oraz agencji celnej, a obszar magazynowy - wejścia dla magazynu wysokiego składowania, aplikacji na terminal z systemem Android i roli klienta. Każdy z tych wariantów korzysta z tego samego zestawu transakcji, ale pokazuje inny ich wycinek.
Transakcje uniwersalne i dedykowane
Transakcje dzielą się na dwie grupy, których nie należy mylić przy planowaniu wdrożenia.
Transakcje uniwersalne znajdują się w folderze \role_sys\ i działają w wielu modułach naraz. Ich zachowanie zmienia się nie przez modyfikację kodu, lecz przez parametry wywołania oraz konfigurację. Ta sama transakcja obsługuje więc listę kontrahentów w module CRM i listę dokumentów magazynowych w WMS - różnicę robi konfiguracja widoku i przekazane parametry. Do najczęściej wykorzystywanych należą:
j_insert_update.aspx- uniwersalny formularz dopisania i edycji rekordu.j_grid.aspx- konfigurowalne zestawienie danych w formie tabeli.import_xls.aspx- import danych z plików XLS, XLSX i CSV według zdefiniowanych schematów.szukaj.aspx- uniwersalna wyszukiwarka po zbiorach danych.j_zalaczniki.aspx- obsługa załączników dołączanych do dokumentów.raporty.aspx- uruchamianie raportów przygotowanych w Reporting Services.x_mail.aspx- wysyłka wiadomości e-mail z poziomu dokumentu.
Sterowanie odbywa się przez parametry doklejane do adresu wywołania. Wywołanie w postaci j_insert_update.aspx?kodtransakcji=EWI_INS_KNKON&mail=1 uruchamia ten sam uniwersalny formularz, ale z inną definicją pól i z włączoną wysyłką powiadomienia. Kod transakcji wskazuje konfigurację zapisaną w bazie, a kolejne parametry włączają lub wyłączają zachowania oraz przekazują wartości domyślne. Dzięki temu jeden plik obsługuje dziesiątki różnych formularzy, a rozbudowa sprowadza się do dodania nowej definicji, nie nowego kodu.
Transakcje dedykowane obsługują jeden konkretny proces biznesowy i leżą w folderze właściwej roli. Przykładem są transakcje przyjęcia towaru czy wydania z magazynu w \role_wms\ albo obsługi zdarzeń awizacyjnych w \role_maw\. Nazwy plików odzwierciedlają obsługiwany dokument, na przykład dpmag_insert_pw.aspx dla przyjęcia wewnętrznego.
Przy wdrożeniu warto zaczynać od pytania, czy dana potrzeba nie jest już pokryta transakcją uniwersalną skonfigurowaną inaczej. W wielu przypadkach nowy proces udaje się obsłużyć bez pisania kodu - wystarczy nowy widok danych, opisany w materiale o bazie danych i konfigurowalnych widokach SQL, oraz odpowiednia pozycja menu.
Moduły zbudowane na transakcjach
Na wspólnej warstwie transakcji działają cztery systemy SoftwareStudio. Każdy z nich korzysta z tego samego mechanizmu, różniąc się zestawem transakcji dedykowanych:
- Transakcje WMS - magazyn wysokiego składowania: kartoteki miejsc adresowych, stany bieżące, rezerwacje i inwentaryzacja.
- Transakcje YMS - awizacje i zarządzanie placem: okna czasowe, obsługa bram, parkowanie i transport wewnętrzny.
- Transakcje TCS - narzędziownia: wydania narzędzi pracownikom, zwroty, legalizacje i przeglądy.
- Transakcje RMA - reklamacje: rejestracja zgłoszeń, obsługa napraw i zwrotów oraz komunikacja z klientem.
Wspólna warstwa oznacza w praktyce, że poprawka w transakcji uniwersalnej działa od razu we wszystkich czterech modułach, a użytkownik przechodzący między obszarami systemu pracuje z tym samym typem formularza i tym samym sposobem obsługi zestawień.
Powiązania z resztą platformy
Transakcja rzadko działa w izolacji. Listy wyboru wypełniane są ze skorowidzy, czyli słowników definiowanych przez administratora, a parametry sterujące zachowaniem transakcji ustawia się w module administratora. To, które transakcje trafią do menu użytkownika i jaki pasek poleceń pojawi się nad tabelą, definiuje z kolei moduł Konfigurator - również bez zmian w kodzie.
Dane odczytywane i zapisywane przez transakcje trafiają do bazy SQL Server, a wymianę z systemami zewnętrznymi, w tym z ERP SAP, obsługuje WebAPI w architekturze REST. Ten sam kanał wykorzystują aplikacje mobilne na Androida, dzięki czemu operacja wykonana na terminalu magazynowym trafia do tej samej tabeli, co operacja wykonana w przeglądarce.
Podsumowanie
Architektura oparta na transakcjach sprowadza się do prostej zasady: jedna akcja to jeden plik aspx z kodem serwerowym C# i klienckim jQuery, umieszczony w folderze odpowiadającym roli użytkownika. Ta zasada daje modularność, czytelne uprawnienia i możliwość rozbudowy bez naruszania działających funkcji.
Transakcje uniwersalne z folderu \role_sys\ stanowią wspólny fundament wszystkich modułów, a transakcje dedykowane obsługują procesy specyficzne dla magazynu, awizacji, narzędziowni i reklamacji. Dla osoby wdrażającej system oznacza to, że dużą część potrzeb da się pokryć konfiguracją istniejących mechanizmów, zanim pojawi się potrzeba pisania nowego kodu.