• Umożliwiają administratorowi biblioteki tworzenie dowolnych własnych wyników na podstawie danych przechowywanych w bazie danych.
• Częścią szablonu jest SQL do bezpośredniego odczytu danych – dane nie są wstępnie przygotowane w Tritiu, jak ma to miejsce w przypadku podstawowych (prostych) wyników.
• Szablon jest sparametryzowany, tzn. po wybraniu szablonu przed samym eksportem wyświetla się okno dialogowe z parametrami, które są następnie przekazywane do szablonu.
• Zaawansowane wyniki znajdują się w tabeli report_template i mają report_type=ADVANCED.
• Przykładowy szablon jest częścią danych wyjściowych Tritia z id = -39.

Ładowanie danych

• Dostęp do tak zdefiniowanych pól można uzyskać poprzez standardowy zapis $F{název_pole}
  • pr. $F{work_type_name}

Więcej selektów w jednym szablonie bez użycia podraportu

• Należy utworzyć subDataset, który można następnie wywołać w komponencie chart, crosstab, table lub list.
• W tej komponencie należy użyć datasetRun, który przekazuje parametry wejściowe do subDataset, zawierającego sam SQL.
• SubDataset może mieć parametr, pole, zmienną i grupę, podobnie jak sam raport. Każdy subDataset ma własne zapytanie, a raport może mieć nieograniczoną liczbę subDataset.
• jr:listContents jest analogiczny do elementu detail band, można więc umieścić w nim inne elementy.
• DatasetRun jest w rzeczywistości podobny do elementu subreport. Może zawierać dataSourceExpression lub connectionExpression, które zmieniają źródło pochodzenia danych.
• Ten sam subDataset może być użyty dla wielu datasetRun, dzięki czemu można łatwo użyć tego samego zapytania z różnymi parametrami.

Przykład zastosowania na liście:

 <subDataset name="dataset1" uuid="9fbfd1be-cb5a-476e-940a-afd2e2eb9b1e">
        <parameter name="parametr1" class="java.lang.String"/>
         <queryString>
             <![CDATA[SELECT work FROM item WHERE id=$P!{parametr1}]]>
         </queryString>
        <field name="work" class="java.lang.String"/>
 </subDataset>

   <componentElement>
                <reportElement x="1" y="76" width="553" height="50" uuid="2968c67b-f548-4c8a-bef3-0df29219b17e"/>
                <jr:list xmlns:jr="http://jasperreports.sourceforge.net/jasperreports/components" xsi:schemaLocation="http://jasperreports.sourceforge.net/jasperreports/components http://jasperreports.sourceforge.net/xsd/components.xsd" printOrder="Vertical">
                    <datasetRun subDataset="dataset1" uuid="abd17d55-84c6-4e37-9426-cb9f5f59c1a6">
                        <datasetParameter name="parametr1">
                            <datasetParameterExpression><![CDATA["66407"]]></datasetParameterExpression>
                        </datasetParameter>
                    </datasetRun>
                    <jr:listContents height="50" width="553">
                        <textField>
                            <reportElement x="167" y="16" width="219" height="20" uuid="79972cb3-82ff-4ae5-be0a-89250b9243b5"/>
                            <textElement verticalAlignment="Middle">
                                <font fontName="DejaVu Sans" size="11"/>
                            </textElement>
                            <textFieldExpression><![CDATA[$F{work}]]></textFieldExpression>
                        </textField>
                    </jr:listContents>
                </jr:list>
            </componentElement>

• W rezultacie pole tekstowe w arkuszu wyświetla identyfikator pracy zapisany w polu pracy dla identyfikatora elementu przesłanego przez subDataset za pomocą parametru „parametr1”, który zapisał wartość w polu pracy.

Przekazanie wartości ze zmiennej subDataset do głównego raportu można wykonać, dodając:

<returnValue fromVariable="promenna_subdataset" toVariable="promenna_reportu"/>

• Aby parametr/zmienna subDataset miały takie same wartości jak parametr/zmienna głównego raportu, można wykonać następujące czynności:

Parametry wyjściowe

• Wyniki mogą być parametryzowane, tzn. czytelnik może ograniczyć dane, które mają być ładowane.
• Na przykład ładowanie wypożyczeń konkretnego czytelnika w danym okresie.
• Parametry te należy zdefiniować w szablonie
• Dodanie parametru w iReport:
  • Kliknij prawym przyciskiem myszy Parameters -> Add Parameter
  • Nadaj parametrowi odpowiednią nazwę i ustaw jego typ danych

Definicja w szablonie

• Parametr można następnie używać w szablonie, wpisując $P{nazwa_parametru}
• Parametr można używać bezpośrednio w SQL do ładowania danych.

  <parameter name="l1" class="java.lang.Long"/>
  <queryString language="SQL">
      <![CDATA[
          SELECT [name] AS work_type_name
          FROM [work_type]
          WHERE [id] = $P{l1}
      ]]>
  </queryString>
  <field name="work_type_name" class="java.lang.String"/>

   

• W ten sposób można jednak wstawić parametr tylko bez żadnych dodatkowych modyfikacji.
  • Działa dla ciągów znaków, liczb.
  • Nie działa dla daty i zaawansowanych struktur Tritia.
• Jeśli parametr wymaga jakiejś obróbki, nie jest to możliwe w części z SQL (ograniczenie JasperReports).
• Konieczne jest utworzenie nowego parametru, ustawienie dla niego żądanej wartości, a dopiero potem użycie go w szablonie.
• Do tak utworzonego parametru należy uzyskać dostęp poprzez $P!{nazwa_parametru} (dodatkowy wykrzyknik).
• Do utworzenia wartości parametru można użyć składania wartości, tak jak w Javie.
   
• Przykład:

• Dla daty 1.2.2015 10:00:00 w parametrze d1_sql_condition zostanie ustawiona wartość „[work_type].[date_created] > »2015-02-01 10:00:00« ”, co odpowiada zapisowi SQL

Parametry obowiązkowe i nieobowiązkowe

• Jeśli parametr jest obowiązkowy, nie ma potrzeby go obsługiwać.
• Parametr nieobowiązkowy może pojawić się w szablonie jako NULL – należy zapewnić utworzenie prawidłowego kodu SQL.
• W tym celu stosuje się wstępne przetwarzanie parametru, patrz wyżej.
• Wykorzystanie operatora trójargumentowego
  • Jeśli parametr różni się od null, użyj wartości A, w przeciwnym razie użyj wartości B.
• Warunek 1=1 – nie ogranicza wyników.
• Przykład:

• Jeśli parametr ma wartość NULL, stosuje się warunek 1=1 (pobierane są wszystkie rekordy). W przeciwnym razie stosuje się standardowy warunek SQL dla podanej wartości.

Definicja w GUI

• 
  
  • Powyższe rozwiązuje kwestię przetwarzania parametrów pochodzących z Tritia w szablonie.
  • Konieczne jest jednak zdefiniowanie, że wprowadzenie tych parametrów ma być oferowane w Tritiu.
  • Zdefiniowane w report_template w kolumnie param2.
  • Każdy parametr jest określony:
  • unikalną nazwą – pod tą nazwą jest następnie przetwarzany w szablonie, musi być taka sama, typem danych – aby w Tritiu wyświetlał się odpowiedni komponent do wprowadzenia danych, kluczem do tłumaczenia opisu, określeniem, czy parametr jest opcjonalny.

Typy danych

• 
  
  • ciąg znaków - s
  • wartość całkowita - n
  • wartość dziesiętna - double
  • data wraz z godziną - d
  • data początku dnia (bez składowej czasowej) - ds
  • data końca dnia (bez składowej czasowej) - de
  • wartość logiczna - b
  • użytkownik - u
  • biblioteka - l
  • definicja internetowa - w
  • obiekty bazy danych - wprowadza się jako nazwę klasy UJO (np. Work, Item, ...)
    • wyświetlane są w polu kombi
       
• Unikalna nazwa - składa się z typu danych uzupełnionego o numer
  • np. d1, u2, Work3
     
• Klucz do tłumaczenia - wyświetlany jako opis wejścia
  • wprowadzany w nawiasach kwadratowych
  • np. [User], [Work_id]
     
• Ustawienia obowiązkowe
  • Parametry obowiązkowe należy wypełnić w Tritiu, bez nich nie można utworzyć wyjścia.
  • Parametry są domyślnie obowiązkowe.
  • Można ustawić opcjonalność, dodając znak ? (znak zapytania) przed nazwą parametru.
     
• Przykłady parametrów:
  • n1[Work_id] – obowiązkowy parametr całkowitoliczbowy o nazwie n1 w szablonie i tłumaczeniu Work_id w Tritiu.
  • ?w2[Web_definition] – parametr nieobowiązkowy, wyświetla się lista rozwijana z definicjami stron internetowych, nazwa w szablonie to w2, a opis w Tritiu to tłumaczenie Web_definition.
  • Work3[My_work] – parametr obowiązkowy, oferowany jako lista rozwijana z częściami, w szablonie pod nazwą Work3, opis to tłumaczenie My_work.
  • Każdy szablon może zawierać więcej parametrów – oddzielonych od siebie przecinkiem lub średnikiem.
     
• Przykład:
  • n1[Work_id],?w2[Web_definition] – szablon z 1 parametrem obowiązkowym i jednym opcjonalnym.

Rozdzielczość dla różnych baz danych

• Różne bazy danych używają różnych metod escapowania tabel.
  • Mysql - `work`
  • MSSQL - [work]
• Jeśli tworzony jest szablon dla jednej konkretnej bazy danych, nie ma potrzeby zajmowania się tą kwestią.
• W szablonie dla wielu baz danych konieczne jest rozwiązanie kwestii escapowania – nie są one ze sobą kompatybilne.
• W tym celu stosuje się specjalne tagi parami.
  • SQL umieszcza się wewnątrz tych tagów.
  • Escapowanie dostosowuje się do używanej bazy danych.
  • Konieczne jest escapowanie dla MSSQL. 

<sql>

• Używany w części z głównym szablonem SQL.
• Nie można go używać w parametrach.
• W przypadku SQL należy stosować escapowanie MSSQL.
• Należy go umieścić w części ![CDATA[....]] – nie jest to standardowy tag XML, JasperReports nie byłby w stanie go przetworzyć.
• Przykład:

<queryString language="SQL">
    <![CDATA[
      <sql>
        SELECT [name] AS work_type_name
        FROM [work_type]
      </sql>
    ]]>
</queryString>

<sqlp>

• Używany w części z parametrami.
• Nie można go używać w głównym szablonie SQL.
• SQL musi mieć escapowanie MSSQL.
• Należy go wstawiać do ![CDATA[....]]
• Przykład:​​​​​​​

<parameter name="d1_sql_condition" class="java.lang.String">
    <defaultValueExpression><![CDATA[<sqlp>$P{d1} == null ? "1=1" : ("[work].[date_created] > '" + new SimpleDateFormat("yyyy-MM-dd HH:mm:ss").format($P{d1}) + "'")</sqlp>]]></defaultValueExpression>
</parameter>

Różne SQL dla baz danych

• W przypadku bardziej złożonych zapytań SQL sama zmiana escapowania nie wystarczy, ponieważ każda baza danych używa innej składni poleceń.
• W takim przypadku konieczne jest posiadanie innego SQL dla każdej bazy danych.
• W tym celu stosuje się pary tagów <mysql> i <mssql>.
• Bloki te wprowadzają SQL, który jest używany tylko dla tej konkretnej bazy danych.
• Oznacza to, że jeśli w szablonie znajdują się bloki <mysql> i <mysql>, a pracuję na MSSQL, bloki w części <mysql> są usuwane z szablonu.
• Przykład:​​​​​​​

<queryString language="SQL">
    <![CDATA[
      <mssql>
        SELECT [name] AS work_type_name
        FROM [work_type]
      </mssql>
      <mysql>
        SELECT `name` AS work_type_name
        FROM `work_type`
      </mysql>
    ]]>
</queryString>