Reporting Services to warstwa raportowa platformy StudioSystem oparta na silniku Microsoft SQL Server Reporting Services. Szablony RDL i RDLC uruchamiane są przez dwie transakcje - uniwersalną raporty.aspx oraz wyspecjalizowaną wydruk_refno.aspx - które potrafią zwrócić podgląd, plik PDF lub XLS, dogenerować kod kreskowy, wysłać dokument e-mailem i zapisać kopię w archiwum.
Dwie transakcje, jeden silnik
Za każdym wydrukiem w StudioSystem stoi ten sam silnik raportowy, ale do jego uruchomienia prowadzą dwie różne drogi. Rozróżnienie to często umyka na pierwszy rzut oka, bo obie transakcje generują ten sam rodzaj wyniku - podgląd, plik PDF albo arkusz Excel - różnią się jednak sposobem wskazania, który raport ma zostać wykonany.
Pierwsza droga to transakcja raporty.aspx, która uruchamia dowolny szablon RDL przechowywany na serwerze raportów - wystarczy podać jego ścieżkę. Druga to transakcja wydruk_refno.aspx, zaprojektowana wąsko: drukuje jeden konkretny dokument na podstawie jego numeru referencyjnego, korzystając z lokalnego szablonu RDLC dołączonego do aplikacji.
| Cecha | raporty.aspx | wydruk_refno.aspx |
|---|---|---|
| Typ szablonu | RDL (serwer raportów) | RDLC (lokalnie, w aplikacji) |
| Parametr wskazujący raport | raport - pełna ścieżka | typdok - nazwa pliku |
| Parametr wymagany dodatkowo | brak | refno - numer dokumentu |
| Typowe zastosowanie | dowolny raport z katalogu | wydruk jednego dokumentu |
| Kody kreskowe | tak, parametr ean | tak, parametr ean + zapis w dpean |
| Wysyłka e-mail | nie | tak, parametr email |
W praktyce wdrożeniowej to rozróżnienie ma znaczenie przy projektowaniu nowego wydruku. Jeśli potrzebne jest zestawienie analityczne albo raport bez jednego, oczywistego dokumentu źródłowego, naturalnym wyborem jest raporty.aspx. Jeśli natomiast chodzi o wydruk konkretnej faktury, dokumentu magazynowego czy etykiety powiązanej z jednym rekordem w bazie danych, celem jest wydruk_refno.aspx.
Raporty.aspx - podgląd raportu
Uruchomienie transakcji wymaga podania parametru raport, wskazującego ścieżkę i nazwę pliku szablonu. Przykładowo wartość raport=/Firma_SoftwareStudio/dokumenty_wz oznacza uruchomienie pliku dokumenty_wz.rdl z folderu Firma_SoftwareStudio, zdefiniowanego w bazie danych SQL Reporting Services.
Domyślnym zachowaniem jest podgląd wyniku na stronie, ale opcjonalny parametr save pozwala wskazać format pliku wynikowego - save=pdf lub save=xls. Wszystkie parametry, które nie należą do listy nazw zastrzeżonych, przekazywane są wprost jako wartości parametrów raportu przygotowanego w Report Builder, co pozwala filtrować dane bez modyfikacji samego szablonu.
Przy każdym uruchomieniu do raportu trafia też komplet zmiennych sesyjnych, odczytanych z tabeli zalogowanego użytkownika:
| Zmienna | Zawartość |
|---|---|
@KTO | identyfikator zalogowanego użytkownika |
@LOGIN | login użytkownika |
@MAIL | adres e-mail przypisany do konta |
@ROLASYS | rola systemowa użytkownika |
@MPK | miejsce powstawania kosztów |
@MAGAZYN | przypisany magazyn |
@ODDZIAL | oddział firmy |
@DATA | bieżąca data uruchomienia |
Dzięki temu ten sam szablon RDL może zwracać inny wynik w zależności od tego, kto go uruchamia - operator z jednego oddziału widzi wyłącznie swoje dane, bez konieczności utrzymywania osobnej kopii raportu dla każdej lokalizacji.
wydruk_refno.aspx - wydruk po REFNO
Domyślnie transakcja generuje wydruk na podstawie dwóch parametrów wymaganych: typdok, określającego nazwę pliku raportu RDLC, oraz refno, czyli numeru referencyjnego dokumentu przekazywanego dalej do szablonu jako @REFNO. Skąd bierze się sam numer referencyjny, opisuje osobny materiał o numeracji dokumentów.
Przykładowe wywołanie wygląda następująco:
wydruk_refno.aspx?typdok=faktura_vat&refno=12345&save=pdfEfektem jest plik 12345.pdf zapisany w folderze App_Pdf. Parametr save decyduje o tym, że plik trafia najpierw na serwer, a użytkownik pobiera go na żądanie - alternatywą jest parametr export, który od razu wymusza pobranie pliku w przeglądarce, bez pośredniego zapisu.
Nazwę pliku można zbudować dynamicznie parametrem regexp, podstawiając w szablonie nazwy takie wartości jak DATE, DATETIME, NAME czy NAME2. Osobny parametr delete porządkuje foldery tymczasowe, usuwając z App_Pdf lub App_Xls pliki starsze niż z bieżącego dnia - przydatne tam, gdzie wydruki generowane są masowo i w dużej liczbie w ciągu dnia roboczego.
Kody kreskowe na wydrukach
Obie transakcje potrafią przed przygotowaniem wydruku dogenerować kod kreskowy - wystarczy dodać parametr ean ze wskazaniem grupy definicji zapisanej w skorowidzu EANG. System sam odczytuje z bazy, którą kolumnę i z jakiej tabeli zakodować, a wygenerowany kod może zostać umieszczony bezpośrednio na dokumencie, na przykład etykiecie miejsca składowania opisanej przy okazji transakcji x_run.aspx.
Biblioteka obsługuje kilka standardów kodowania, dobieranych automatycznie na podstawie konfiguracji skorowidza:
- EAN8 i EAN13 - standardowe kody produktowe o stałej długości.
- CODE128 wraz z wariantami A, B i C - najczęściej wykorzystywany w dokumentach magazynowych i logistycznych.
- CODE39 - prosty kod alfanumeryczny, popularny w starszych integracjach.
- ITF14 - kod stosowany na opakowaniach zbiorczych i paletach.
- 2OF5 - kod numeryczny wykorzystywany w zastosowaniach magazynowych.
Dla transakcji wydruk_refno.aspx wygenerowany kod zapisywany jest dodatkowo w tabeli dpean, co pozwala odtworzyć historię wydruków etykiet niezależnie od tego, czy plik PDF nadal istnieje na dysku serwera.
Wysyłka e-mail i archiwizacja
Parametr email zmienia sposób udostępnienia gotowego pliku - zamiast czekać na pobranie przez użytkownika, dokument trafia jako załącznik bezpośrednio do adresata. Wartością parametru jest kod pozycji skorowidza EML, który wskazuje zarówno skrzynkę nadawczą, jak i szablon treści wiadomości z polami takimi jak temat, treść oraz zapytanie SQL wyszukujące adres odbiorcy. System zapisuje wtedy zadanie w tabelach _task i _send, a samą wysyłkę realizuje w tle usługa ssJOB.
Osobnym mechanizmem jest archiwizacja. Parametr archiwum pozwala skopiować każdy wygenerowany plik do wskazanej ścieżki, na przykład App_Zal\@REFNO\, gdzie @REFNO zamieniane jest na rzeczywisty numer dokumentu. Dzięki temu każdy kolejny wydruk tego samego dokumentu odkłada się jako kolejna kopia, a fakt przeniesienia pliku odnotowywany jest w tabeli historii wraz z informacją, kto i kiedy tego dokonał. Parametr dpzal=1 idzie o krok dalej i dodatkowo zapisuje wpis o załączniku w tabeli dpzal, co pozwala listować powiązane pliki zwykłym zapytaniem SQL.
Dynamiczne linki do raportu
Wartości parametrów raportu nie muszą być zapisane na sztywno w adresie transakcji. Dowolny parametr URL rozpoczynający się od symbolu @ zostaje przekazany wprost do zmiennej raportu o identycznej nazwie - wywołanie z fragmentem @ADRES=0 podstawi wartość zero pod parametr @ADRES zdefiniowany w szablonie, na przykład przy masowym drukowaniu etykiet miejsc składowania.
W praktyce wydruk rzadko jest uruchamiany ręcznym wpisaniem adresu - najczęściej kryje się pod przyciskiem w interfejsie. Przypisanie transakcji do takiego przycisku odbywa się w konfiguratorze menu, gdzie dla wybranej pozycji ustawia się transakcję do uruchomienia wraz z gotowym zestawem parametrów. Tam, gdzie wartość parametru ma zależeć od wyboru dokonanego przez użytkownika, zamiast stałego adresu wykorzystuje się transakcję x_run.aspx ze skorowidzem RUN, która buduje wywołanie w locie na podstawie zaznaczonego rekordu.
Gdzie w interfejsie spotkasz wydruki
Poniższe zrzuty ekranu pokazują dwa miejsca w panelu administracyjnym, które bezpośrednio zasilają mechanizm raportowy opisany wyżej.
Przycisk zamiast wpisywanego adresu
Administrator ustawia transakcję i parametry raz, w formularzu pozycji menu. Użytkownik końcowy widzi już tylko zwykły przycisk uruchamiający wydruk.
Numer referencyjny przekazywany do wydruku nie powstaje przypadkowo - nadaje go moduł numeracji dokumentów, dostępny z poziomu panelu administratora.
Jedno źródło numeru referencyjnego
Numer nadany przy zapisie dokumentu towarzyszy mu już do końca - od zestawienia w tabeli, przez wydruk, aż po ewentualną wysyłkę e-mailem.
Podsumowanie
Reporting Services w StudioSystem to nie jedna transakcja, lecz dwie uzupełniające się ścieżki oparte na wspólnym silniku SQL Server Reporting Services. Raporty.aspx sprawdza się przy dowolnych zestawieniach opartych na szablonie RDL z serwera raportów, a wydruk_refno.aspx - przy wydruku konkretnego dokumentu na podstawie jego numeru referencyjnego, z lokalnym szablonem RDLC.
Obie potrafią dogenerować kod kreskowy, zapisać wynik w formacie PDF lub XLS, wysłać go e-mailem i odłożyć kopię w archiwum - a całość spina się w interfejsie bez pisania kodu, poprzez zwykłą pozycję menu skonfigurowaną w konfiguratorze.