Baza_sql to raport RDL z rodziny raportów diagnostycznych StudioSystem, eksportujący zawartość tabeli _code_sql - centralnego rejestru zapytań SQL wywoływanych przez aplikację webową i mobilną wyłącznie za pomocą identyfikatora UID, bez ujawniania treści zapytania w kodzie klienckim.
Czym jest raport Baza_sql
Podobnie jak pozostałe raporty diagnostyczne platformy, Baza_sql to plik w formacie XML z rozszerzeniem RDL, edytowalny w narzędziu Microsoft Report Builder w wersji 3.x. W odróżnieniu od raportów biznesowych - faktur, zestawień magazynowych - jego odbiorcą nie jest użytkownik końcowy, tylko osoba wdrażająca lub utrzymująca system: integrator, administrator albo programista wprowadzający zmiany.
Zadaniem raportu jest zebranie w jednym miejscu tego, co normalnie trzeba by sprawdzać zapytaniem SQL bezpośrednio do bazy danych - pełnej listy zapytań zarejestrowanych w tabeli _code_sql, wraz z ich identyfikatorami i parametrami. Dla osoby bez dostępu administracyjnego do serwera SQL jest to jedyny wygodny sposób przejrzenia tej warstwy systemu.
Mechanizm tabeli _code_sql
Tabela _code_sql rozwiązuje konkretny problem bezpieczeństwa: jak pozwolić aplikacji webowej i mobilnej wykonywać zapytania do bazy danych, nie ujawniając przy tym treści tych zapytań w kodzie strony ani w ruchu sieciowym. Rozwiązaniem przyjętym w StudioSystem jest przeniesienie logiki biznesowej wyłącznie na stronę serwera i posługiwanie się po stronie klienta unikalnymi identyfikatorami UID zamiast surowego SQL.
W praktyce wygląda to tak: formularz w aplikacji Android czy w przeglądarce wywołuje zapisany wcześniej identyfikator, na przykład 0CA64E62-8722-4235-BC66-86FF5D7F0EA3. Serwer odnajduje pod tym identyfikatorem właściwe zapytanie w tabeli _code_sql i je wykonuje. Nawet pełny podgląd ruchu sieciowego między aplikacją a serwerem nie ujawnia więc ani struktury tabel, ani logiki zapytania - widoczny jest wyłącznie ciąg znaków identyfikatora.
Rejestracja nowego zapytania wygląda z perspektywy programisty następująco: najpierw powstaje procedura składowana albo zapytanie SQL po stronie bazy danych, następnie dopisywany jest wiersz w _code_sql z nowym identyfikatorem UID, tytułem porządkującym wpis oraz listą parametrów, jakie transakcja będzie przekazywać. Dopiero ten identyfikator trafia do kodu formularza - nigdy treść samego zapytania. Zmiana logiki po wdrożeniu nie wymaga więc publikowania nowej wersji aplikacji mobilnej ani przeglądarkowej - wystarczy zmodyfikować zapytanie pod tym samym UID po stronie serwera.
Jedno miejsce, wiele ról
Zarówno skorowidze, jak i wpisy _code_sql konfiguruje się z tego samego miejsca w panelu administratora, niezależnie od tego, której roli dotyczą.
Struktura pojedynczego wpisu
Każdy wiersz eksportowany przez raport Baza_sql opisuje jedno zapytanie zarejestrowane w systemie. Na przykładzie rzeczywistego wpisu z roli WMS struktura wygląda następująco:
| Pole | Przykładowa wartość |
|---|---|
| UID | 0CA64E62-8722-4235-BC66-86FF5D7F0EA3 |
| Rodzaj kontrolki | ANDROID INSERT/UPDATE |
| Tytuł | Skorowidz DrawIo PRX=DRAW |
| Zapytanie | EXEC [dbo].[sp__ws_wms_zapisz_pz_pozycja] @TRANSAKCJA,@REFNODOKUMENTU,... |
| Parametry | @TRANSAKCJA, @REFNODOKUMENTU, @NRIDASN, @ILOSC, @LOKALIZACJA, @USERNAME... |
Widać tu od razu praktyczną konsekwencję tego podejścia: sama nazwa procedury sp__ws_wms_zapisz_pz_pozycja mówi więcej o działaniu zapytania niż jego zaszyfrowany identyfikator UID - a mimo to aplikacja mobilna zna wyłącznie ten drugi. Kolumna „Rodzaj kontrolki” dodatkowo porządkuje wpisy według miejsca ich wywołania, co przy przeglądaniu długiej listy pozwala szybko odfiltrować zapytania dotyczące konkretnie aplikacji Android od tych wywoływanych z przeglądarki.
Zapytania rozbite według ról
Ze względu na liczbę zarejestrowanych zapytań, dokumentację tabeli _code_sql rozbito na osobne strony według roli licencyjnej, zamiast publikować jedno bardzo długie zestawienie. Osobno opisano między innymi zapytania dla ról WMS, NAR (narzędziownia) oraz VSS - każda strona koncentruje się wyłącznie na zapytaniach istotnych dla danego obszaru, co znacząco ułatwia wyszukiwanie konkretnego wpisu.
Raport Baza_sql, w przeciwieństwie do tych stron, nie rozróżnia ról - eksportuje całą tabelę _code_sql naraz. Sprawdza się to w sytuacjach, gdy potrzebny jest pełny obraz systemu, na przykład przy audycie bezpieczeństwa obejmującym całe wdrożenie, a nie tylko jeden moduł.
Wybór między raportem zbiorczym a stroną poświęconą jednej roli zależy od pytania, na jakie akurat trzeba odpowiedzieć. Gdy problem dotyczy konkretnej transakcji w znanym module, szybciej jest otworzyć dedykowaną stronę roli i użyć wyszukiwarki przeglądarki po nazwie procedury. Gdy natomiast pytanie brzmi „ile w ogóle mamy zapytań w systemie i czy któreś się powtarza między rolami”, jedynym praktycznym narzędziem pozostaje pełny eksport z raportu Baza_sql, otwarty następnie w arkuszu kalkulacyjnym.
Jak uruchomić raport
Baza_sql uruchamia się tak samo jak każdy inny raport RDL na platformie - transakcją raporty.aspx z parametrem raport wskazującym ścieżkę pliku na serwerze raportów, na przykład raport=/Firma_SoftwareStudio/Baza_sql. Domyślnie wynikiem jest podgląd na stronie, ale opcjonalny parametr save pozwala wskazać format wyjściowy - pdf do archiwizacji albo xls, jeśli lista ma zostać dalej przetworzona w arkuszu kalkulacyjnym.
Mechanizm raportów, wspólne parametry i zmienne sesyjne przekazywane do każdego uruchomienia opisano szerzej w materiale o Reporting Services w StudioSystem.
Dlaczego to zwiększa bezpieczeństwo
Wykorzystywanie unikalnych identyfikatorów UID po stronie klienta i przeniesienie logiki biznesowej na stronę serwera to obecnie jedno z prostszych i skuteczniejszych rozwiązań ograniczających ryzyko po stronie aplikacji webowej i mobilnej. Konsekwencje tego podejścia są konkretne:
- Brak ekspozycji struktury bazy - nazwy tabel i kolumn nie pojawiają się w kodzie źródłowym aplikacji klienckiej.
- Niezmienność logiki po stronie klienta - nawet przy pełnej kontroli nad ruchem sieciowym nie da się podmienić treści wykonywanego zapytania, można co najwyżej podać inny istniejący UID.
- Centralne miejsce audytu - każda zmiana logiki zapytania to jedna edycja wiersza w
_code_sql, a nie zmiana w wielu miejscach kodu aplikacji. - Spójność między platformami - to samo zapytanie pod tym samym UID może być wywoływane zarówno z przeglądarki, jak i z aplikacji Android.
Jest to podejście spójne z resztą platformy - podobnie ograniczony dostęp do bazy danych opisano przy okazji uwierzytelniania wywołań WebAPI, gdzie integrator również nie otrzymuje bezpośredniego dostępu do serwera SQL.
Praktyczne zastosowania
Najczęstszym powodem sięgnięcia po raport Baza_sql jest potrzeba szybkiego zrozumienia, co dokładnie robi dane wdrożenie, bez konieczności przeszukiwania kodu transakcji jedna po drugiej. Sprawdza się to w kilku typowych sytuacjach:
- Przejęcie utrzymania systemu - nowy programista dostaje jeden dokument zamiast przeszukiwania dziesiątek plików transakcji w poszukiwaniu logiki zapisu.
- Audyt bezpieczeństwa - zewnętrzny audytor może zweryfikować, jakie zapytania są rzeczywiście wykonywane, bez potrzeby uzyskiwania dostępu do serwera bazy danych.
- Migracja między środowiskami - porównanie eksportu z bazy danych testowej i produkcyjnej pozwala szybko wychwycić rozbieżności w konfiguracji zapytań.
- Dokumentacja własnych modyfikacji - firma rozwijająca własne moduły na bazie platformy zyskuje gotowy punkt odniesienia przy opisywaniu zmian.
Warto przy tym pamiętać, że sam eksport nie zastępuje przeglądu kodu procedur składowanych - pokazuje, jakie zapytanie kryje się pod danym identyfikatorem i jakich parametrów oczekuje, ale nie tłumaczy logiki biznesowej zaszytej wewnątrz samej procedury SQL. Do pełnego zrozumienia działania danej funkcji nadal potrzebny jest dostęp do definicji procedury po stronie serwera bazy danych - raport skraca jednak drogę do znalezienia właściwej procedury, zamiast przeszukiwać ręcznie każdy plik transakcji.
Podsumowanie
Raport Baza_sql eksportuje pełną zawartość tabeli _code_sql - centralnego rejestru zapytań SQL, do których aplikacja kliencka odwołuje się wyłącznie przez identyfikator UID, nigdy przez treść samego zapytania. To rozwiązanie chroni strukturę bazy danych przed ujawnieniem w kodzie klienckim i daje jedno miejsce do audytu logiki zapisu.
Uruchamia się go tak samo jak każdy inny raport platformy - transakcją raporty.aspx - a szczegółową dokumentację zapytań według ról znajdziesz na stronach poświęconych poszczególnym modułom, poczynając od _CODE_SQL dla roli WMS.
Dla większości wdrożeń wystarczy sięgnąć po ten raport raz - przy przejmowaniu utrzymania systemu albo przy planowaniu większej zmiany - a nie utrzymywać go jako element codziennej pracy. Sam mechanizm _code_sql działa przecież w tle bez udziału administratora, a raport jest wyłącznie oknem podglądu na tę warstwę, gdy zajdzie taka potrzeba.