W systemie Comarch ERP Enterprise dokumenty są generowane za pośrednictwem Semiramis Output Manager (SOM) przy użyciu raportów. Istnieją raporty do generowania dokumentów transakcyjnych oraz raporty do generowania dokumentów sprawozdawczych. Zakres parametrów, sposób pozyskiwania danych oraz układ wydruku są definiowane przez pliki raportów. Pliki raportów mogą być tworzone i modyfikowane za pomocą Crystal Reports.
Wraz z wprowadzeniem Comarch ERP Enterprise w wersji 4.0, znacząco wzrósł zakres danych i uprawnień, które muszą być uwzględnione podczas projektowania raportów. Możliwości, jakie otwierają wielofirmowość, kontekst wyszukiwania i wirtualne tabele, nie mogą być już w pełni pokryte przez dane w plikach raportów ani przez metadane w obiekcie deweloperskim typu Raport. Aby sprostać temu wyzwaniu, wprowadzono specjalne zastosowanie Dokument raportu dla aplikacji dialogowych. Aplikacje z tym specjalnym zastosowaniem nazywane są Aplikacjami raportowymi. Aplikacje raportowe mogą korzystać z obszaru klas, który umożliwia realizację złożonych pól zapytań i związanych z nimi walidacji. Ten obszar zapewnia w szczególności wsparcie w kontekście wykorzystania tabel wirtualnych.
Fakt, że aplikacje raportowe są oddzielnymi aplikacjami, przynosi kilka korzyści w porównaniu do używania raportów w aplikacji Raport: Dokumenty raportów:
- Przyznawanie uprawnień odbywa się wyłącznie na poziomie aplikacji
- Widoczność aplikacji może być kontrolowana na podstawie licencjonowania, konfiguracji, aktywnych baz danych oraz organizacji przypisanych do użytkownika.
- Funkcje związane z aplikacją, takie jak uprawnienia do elementów interfejsu, działają poprawnie
- Bezpośrednia pomoc i pomoc online są tworzone jako normalna dokumentacja aplikacji
Z tego powodu, począwszy od wersji 4.2 Comarch ERP Enterprise, aplikacje raportowe są standardowym sposobem udostępniania raportów.
Niniejszy artykuł opisuje, jak tworzyć aplikacje raportowe.
Grupa docelowa
- Programiści
- Konsultanci techniczni
Definicje terminów
- Dokument końcowy — utworzenie dokumentu końcowego następuje poprzez wysłanie potwierdzenia na urządzenie wyjściowe, takie jak drukarka, lub do pliku. Dokument taki można zarchiwizować lub przesłać do partnera, przykładowo za pomocą maila.
- Raport — raport pozwala na przejrzyste przedstawienie danych zgromadzonych w systemie Comarch ERP Enterprise. Raport można generować dowolną ilość razy, zawsze na podstawie aktualnych danych. Raporty dzieli się na dokumenty raportowe oraz dokumenty końcowe. Dokumenty raportowe mogą być tworzone na podstawie dowolnych danych z Comarch ERP Enterprise. Zazwyczaj mają formę listy i można je generować w aplikacji Raport: Dokumenty raportów. Dokumenty końcowe można generować w odpowiednich aplikacjach branżowych, w których są tworzone. Zazwyczaj zawierają dane dotyczące tylko jednego potwierdzenia. Raporty można tworzyć jako obiekty systemowe lub obiekty rozwojowe. Raport jako obiekt deweloperski ma tę zaletę, że można go zmieniać w systemie deweloperskim, zapisywać w wersji i przenosić do innych systemów w ramach aktualizacji oprogramowania. Aby umożliwić tworzenie i modyfikowanie raportów również w systemach niebędących systemami deweloperskimi, aplikacja Raporty oferuje możliwość tworzenia ich jako obiektów systemowych. Obiekty systemowe nie mogą być przenoszone do innych systemów. Raporty zawierają jeden lub więcej plików raportów, które określają ich układ.
- Dokument raportu — utworzenie dokumentu raportu lub dokumentu końcowego następuje poprzez wysłanie raportu na urządzenie wyjściowe, takie jak drukarka, lub do pliku. Dokument raportu zawiera listę obiektów, na przykład listę adresów. Dokument końcowy zawsze obejmuje jeden obiekt, na przykład zamówienie sprzedaży. Dokumenty można archiwizować lub przesyłać do partnera, na przykład faksem lub pocztą e-mail.
Warunki wstępne
Aby móc tworzyć aplikacje raportowe, wymagana jest znajomość tworzenia raportów za pomocą programu Crystal Reports.
Tworzenie aplikacji raportowych
Ten rozdział opisuje, w jaki sposób tworzone są nowe aplikacje raportowe.
Aplikacja raportowa to aplikacja dialogowa ze specjalnym zastosowaniem Dokumentu raportu, która korzysta z opisanych poniżej interfejsów. Tworzenie aplikacji raportowej składa się z sześciu kroków:
- Rejestracja obiektu deweloperskiego raportu
- Dla aplikacji raportowej musi istnieć przynajmniej jeden raport. Raport musi być utworzony w przestrzeni nazw rpt. Nazwa jednostki biznesowej powinna być zawarta w raporcie. Nazwa raportu to nazwa jednostki biznesowej w liczbie mnogiej.
Jednostka biznesowa:
- Nazwa: com.cisag.sys.configuration.obj.UserGroup
- Oznaczenie: Grupa użytkowników
Raport:
- Nazwa: com.cisag.sys.configuration.rpt.UserGroup
- Oznaczenie: Grupy użytkowników
Raporty dla aplikacji raportowych mają typ dokumentu Dokument aplikacji. Atrybut wyświetlania musi mieć wartość Nie, ponieważ raporty te nigdy nie są wyświetlane w aplikacji Raport: Dokumenty raportów.
- Rejestracja obiektu deweloperskiego klasy Java
- Rejestracja obiektu deweloperskiego aplikacji
- Tworzenie aplikacji raportowej
- Testowanie aplikacji raportowej
- Dokumentowanie aplikacji raportowej
Poszczególne kroki zostały opisane w kolejnych rozdziałach.
Rejestracja obiektu deweloperskiego raportu
Dla aplikacji raportowej musi istnieć przynajmniej jeden raport. Raport musi być utworzony w przestrzeni nazw rpt. Nazwa jednostki biznesowej powinna być zawarta w raporcie. Nazwa raportu to nazwa jednostki biznesowej w liczbie mnogiej.
Jednostka biznesowa:
- Nazwa: com.cisag.sys.configuration.obj.UserGroup
- Oznaczenie: Grupa użytkowników
Raport:
- Nazwa: com.cisag.sys.configuration.rpt.UserGroup
- Oznaczenie: Grupy użytkowników
Raporty dla aplikacji raportowych mają typ dokumentu Dokument aplikacji. Atrybut wyświetlania musi mieć wartość Nie, ponieważ raporty te nigdy nie są wyświetlane w aplikacji Raport: Dokumenty raportów.
Rejestracja obiektu deweloperskiego klasy Java
Aby stworzyć aplikację raportową, potrzebna jest klasa Java. Klasa ta musi znajdować się w obszarze nazw, która kończy się na ui. Jej nazwa powinna być taka sama jak nazwa aplikacji. Nazwa aplikacji powinna zawierać nazwę raportu, bez obszaru nazw, i kończyć się na ReportOutput. Z nazwy powinien być rozpoznawalny obiekt biznesowy.
Rejestracja obiektu deweloperskiego aplikacji
Aplikacja raportowa to aplikacja dialogowa. W związku z tym musi być zarejestrowana w obszarze nazw ui. Nazwa aplikacji zawiera nazwę jednostki biznesowej lub raportu, który jest generowany, i kończy się na ReportOutput.
Raport: Aplikacja:
Aplikacje raportowe są typu Dialog ze specjalnym przeznaczeniem Dokument raportu. Ustawienie wyświetlania i utrzymania musi być ustawione na Wyświetlanie, Utrzymanie, aby aplikacja raportowa była widoczna w nawigatorze. Tryb uprawnień powinien być ustawiony na przeprowadzanie weryfikacji. Należy również poprawnie ustawić wymaganą aktywną bazę danych. Zazwyczaj jest to baza danych OLTP. W przypadku raportów, które wykorzystują obiekty biznesowe w bazie danych OLAP, baza danych OLAP jest również wymaganą aktywną bazą danych.
Tworzenie aplikacji raportowej
Podczas tworzenia aplikacji raportowej istnieją różne scenariusze. W prostym przypadku najpierw można stworzyć raport, a następnie aplikację raportową. W bardziej złożonych scenariuszach raport, aplikacja i wirtualna tabela muszą być tworzone równolegle. Jest również możliwe, że ta sama aplikacja raportowa, w zależności od parametrów zapytania lub konfiguracji, automatycznie wybiera konkretny raport. Wszystkie raporty, które mogą być generowane przez aplikację raportową, muszą mieć te same parametry raportu. Przykładem jest aplikacja Raport: Dzienniki zmian.
Interfejs, który jest dostępny dla aplikacji raportowej, znajduje się w obszarze nazw com.cisag.pgm.services.output. Najważniejszą klasą jest ReportOutputApplication. Wszystkie aplikacje raportowe muszą być podklasami klasy Java ReportOutputApplication. Klasy Java tego interfejsu to:
- Klasa Java ReportOutputApplication — klasa bazowa dla wszystkich aplikacji raportowych
- Klasa Java ReportOutputData — kontener danych dla wartości parametrów
- Klasa Java ReportOutputParameterData — struktura pomocnicza do tworzenia pól zapytania dla parametrów raportu
Klasa Java ReportOutputParameterData
Klasa ReportOutputParameterData zawiera metadane dla parametru raportu, tzn. dane, które są zapisane w raporcie lub pliku raportu dla tych parametrów. Klasa nie jest finalna, ale nie może być dziedziczona. W większości przypadków dla parametru raportu tworzone jest dokładnie jedno pole zapytania w aplikacji raportowej. Jest ona używana w opisanej poniżej metodzie createParameterField(ReportOutputParameterData parameterData).
- Metoda createParameterData(String name,String fieldGuid,String fieldPath,boolean selectionMode) — tworzy nową instancję danych parametru. Za pomocą tej instancji w ReportOutputApplication można utworzyć pole GUI. Nie używa się tej metody bezpośrednio, jest ona używana tylko przez klasę bazową ReportOutputApplication.
- Metoda getName() — zwraca nazwę parametru raportu, dla którego ma zostać utworzone pole GUI
- Metoda getFieldGuid() — zwraca GUID, za pomocą którego ma zostać utworzone pole GUI
- Metoda getFieldPath() — zwraca ścieżkę do opisu danych logicznego typu danych, za pomocą którego ma zostać utworzone pole GUI. W przypadku pól GUI tworzonych automatycznie, logiczny typ danych wraz z trybem selekcji określa, jakie pole GUI zostanie utworzone.
- Metoda isSelectionMode() — określa, czy pole GUI jest tworzone w trybie selekcji, czy też nie
Klasa Java ReportOutputData
Klasa ReportOutputApplication to kontener danych z wartościami parametrów do wygenerowania raportu. Kontener danych jest poprawnie inicjowany przez klasę ReportOutputApplication, gdy podczas inicjalizacji raport zostanie pomyślnie ustawiony przez wywołanie metody initReport(String reportName). Dla każdego parametru raportu musi zostać zarejestrowana ścieżka do opisu danych dla logicznego typu danych oraz musi zostać zainicjowana wartość. Poniższe metody umożliwiają definiowanie lub pobieranie ścieżek do parametrów:
- Metoda setPath(String parameterName, String absPath) — przypisuje ścieżkę do opisu danych dla parametru. Następnie musi zostać jeszcze ustawiona wartość, zanim parametr będzie mógł zostać wykorzystany.
- Metoda getPath(String parameterName) — zwraca ścieżkę do opisu danych logicznego typu danych, który jest przypisany do parametru. Kontener danych ma metody do ustawiania i pobierania typów danych obsługiwanych przez raporty. Rozróżnia się przy tym wartość konkretną a wybór (…Selection). Parametry dla wirtualnych tabel muszą być w wielu przypadkach przekazywane w formacie neutralnym, tzn. niezmienione i bez walidacji przez Crystal Reports, poprzez raport do sterownika ODBC i wirtualnej tabeli. Te parametry raportu muszą być typu String. W klasie ReportOutputData istnieją ponadto specjalne metody get…FromString lub set…AsString.
Klasa Java ReportOutputApplication
Klasa Java ReportOutputApplication jest klasą bazową dla wszystkich aplikacji raportowych. Umożliwia ona realizację różnych poziomów złożoności podczas projektowania aplikacji raportowych. W najprostszym przypadku aplikacja raportowa zachowuje się jak aplikacja Raport: Dokumenty raportów. Wygląd i zachowanie aplikacji są w pełni zdefiniowane przez raport i mogą być zmieniane poprzez modyfikację raportu. Dzięki używaniu wartości domyślnych, wprowadzaniu walidacji dla parametrów raportu i nowych pól GUI, aż po wprowadzanie parametrów aplikacji, które osadzają aplikację raportową w menu kontekstowym jednostek biznesowych, zakres funkcji aplikacji raportowej może być stopniowo dostosowywany do wymagań dla zwykłej aplikacji dialogowej, opisanych w podręczniku stylu.
Należy przy tym każdorazowo rozważyć, jakie modyfikacje w pliku raportu aplikacja raportowa powinna być w stanie automatycznie rozpoznawać i obsługiwać. Nakład pracy na stworzenie drugiej aplikacji raportowej z nowym raportem dla nowych wymagań jest na ogół mniejszy niż nakład pracy na dostosowanie aplikacji raportowej do wszystkich ewentualności modyfikacji w pliku raportu (np. nowe parametry, usunięte parametry, zmienione typy danych). Jeśli aplikacja pozwala na dostosowania parametrów raportu, powinno to być wyraźnie ujęte w dokumentacji aplikacji.
Proste aplikacje raportowe
W tej sekcji opisano sześć przykładów tworzenia aplikacji raportowej:
- Prosta aplikacja raportowa
- Ustawianie wartości domyślnych dla parametrów raportu
- Dodatkowe walidacje dla parametrów raportu
- Aplikacja raportowa z własnymi polami GUI
- Parametry raportu jako parametry aplikacji
- Parametry raportu jako parametry aplikacji
Aby obsługiwać parametry aplikacji, w obiekcie deweloperskim należy zarejestrować i stypizować parametry aplikacji. Pola GUI muszą być zarejestrowane w SelectionGroup pod nazwą parametru aplikacji. Ponieważ pola GUI są standardowo już zarejestrowane pod nazwą parametru raportu, najpierw należy je usunąć, a następnie zarejestrować pod nową nazwą. Ten przykład rozszerza przykład aplikacji raportowej o własne pola GUI i dlatego wymaga tylko jednej dodatkowej metody:
- Metoda prepareParameterFields()
protected void prepareParameterFields() {
getSelectionGroup().remove(„Number”);
getSelectionGroup().add(„PurchaseItem”, itemField);
}
- Dynamiczne określanie raportu — przykłady można również ze sobą łączyć. Nazwy stałych są w przykładach podane w formie Number. W rzeczywistych aplikacjach raportowych dla nazw parametrów aplikacji lub parametrów raportu należy zadeklarować stałe. Po przykładach następuje lista metod.
Złożone aplikacje raportowe
Przedstawione przykłady używają kontenera danych ReportOutputData bezpośrednio do przechowywania wartości z pól zapytania. Jest to wystarczające w większości prostych przypadków. Jednakże, kontener danych ReportOutputData jest zaprojektowany do bezpośredniego przekazywania wartości do raportu lub do wirtualnych tabel i zazwyczaj używa typu String do reprezentacji wartości.
W bardziej złożonych przypadkach warto używać w aplikacji raportowej własnych kontenerów danych, aby za ich pomocą zrealizować metody dataFromUi(), dataToUi() oraz walidacje danych wejściowych, np. GUID-ów kluczy obcych i uprawnień związanych z treścią. W takich przypadkach obliczanie raportu, a także inicjowanie i wypełnianie kontenera danych ReportOutputData odbywa się dopiero bezpośrednio przed właściwym wygenerowaniem, po pomyślnym zakończeniu walidacji na konkretnym kontenerze danych. Przykładem tego typu aplikacji raportowej jest aplikacja Raport: Dzienniki zmian (com.cisag.app.system.modificationjournal.ui.ModificationJournalReportOutput).
W niniejszym artykule nie zostały również opisane ogólne możliwości ograniczania widoczności aplikacji raportowych za pomocą funkcji, konfiguracji lub przypisań organizacyjnych. W tym celu dla aplikacji raportowych można wykorzystać te same możliwości, co dla wszystkich innych aplikacji dialogowych, np. rejestrację w klasie Java com.cisag.app.multiorg.log.ApplicationRegistry.
Prosta aplikacja raportowa
Prosta aplikacja raportowa charakteryzuje się tym, że należy jej tylko przypisać raport:
- Metoda initModel() — raport musi zostać przypisany poprzez wywołanie metody initReport(String
reportName)
initReport(„com.cisag.app.purchasing.rpt.PurchaseItem”);
}
Ustawienie wartości domyślnych dla parametrów raportu
Aplikacja raportowa, która uzupełnia wartości domyślne w zależności od kontekstu, musi zaimplementować następujące metody:
- Metoda initModel() — raport musi zostać przypisany poprzez wywołanie metody initReport(String
reportName) - Metoda applyDefaults() — w ReportOuputData ustawiane są wartości domyślne dla parametrów raportu
getReportOutputData().setStringSelection(„Number”, „A*”);
}
Dodatkowe walidacje dla parametrów raportu
- Metoda initModel() — raport musi zostać przypisany poprzez wywołanie metody initReport(String
reportName) - Metoda initUserInterface() — po wywołaniu metody super.initUserInterface() należy zarejestrować MessageIds w polach GUI.
super.initUserInterface();
itemField.registerMessage(1);
}
- Metoda createParameterField(ReportOutputParameterData parameterData) — pole GUI jest tworzone przez wywołanie metody super.createParameterField(parameterData). Jeśli jest to pole GUI, dla którego ma zostać przeprowadzona dodatkowa walidacja, jest ono przypisywane do zmiennej.
parameterData) {
Field result = super.createParameterField(parameterData);
if (parameterData.getName().equals(„Number”)){
itemField = result;
}
return result;
}
- Metoda validateReportParameters() — dodatkowe walidacje są tworzone w tej metodzie
boolean result = true;
ReportOutputData data = getReportOutputData();
if (!data.getStringSelection(„Number”).startsWith(„A”)) {
result = false;
mm.setProgramMessageId(1);
mm.sendMessage…
}
return result;
}
Aplikacja raportowa z własnymi polami GUI
Jeśli ma być używane inne pole GUI niż pole GUI ze standardowej implementacji, należy zaimplementować następujące metody:
- Metoda initModel() — należy przypisać raport poprzez wywołanie metody initReport(String
reportName) - Metoda applyDefaults() — w ReportOuputData ustawiane są wartości domyślne dla parametrów raportu
getReportOutputData().setStringSelection(„Number”, „A*”);
}
- Metoda createParameterField(ReportOutputParameterData parameterData) — dla jednostki biznesowej tworzone jest własne pole GUI. Samodzielnie utworzone pole jest przypisywane do zmiennej. Wszystkie inne pola GUI są tworzone przez wywołanie metody super.createParameterField(parameterData).
parameterData) {
Field result =null;
if (parameterData.getName().equals(„Number”)){
itemField = new ItemField( parameterData.getFieldGuid(),
parameterData.getFieldPath() );
itemField.setSelectionMode(parameterData.isSelectionMode());
}
else {
result = super.createParameterField(parameterData);
}
return result;
}
- Metoda dataFromUi() — wartość z pól GUI musi zostać skopiowana do kontenera danych
- Metoda dataToUi() — wartość z kontenera danych musi zostać skopiowana do pól GUI
Parametry raportu jako parametry aplikacji
Aby obsługiwać parametry aplikacji, w obiekcie deweloperskim należy zarejestrować i stypizować parametry aplikacji. Pola GUI muszą być zarejestrowane w SelectionGroup pod nazwą parametru aplikacji. Ponieważ pola GUI są standardowo już zarejestrowane pod nazwą parametru raportu, najpierw należy je usunąć, a następnie zarejestrować pod nową nazwą. Ten przykład rozszerza przykład aplikacji raportowej o własne pola GUI, dlatego wymaga tylko jednej dodatkowej metody:
- Metoda prepareParameterFields()
protected void prepareParameterFields() {
getSelectionGroup().remove(„Number”);
getSelectionGroup().add(„PurchaseItem”, itemField);
}
Dynamiczne określanie raportu
Ten przykład opisuje, jak należy stworzyć aplikację raportową, która określa raport dopiero na podstawie danych wprowadzonych przez użytkownika. Wszystkie używane raporty mają przy tym te same parametry.
- Metoda initModel() — w ReportOutputData parametry muszą być zdefiniowane przez wywołanie metody setPath(String parameterName, String absPath). Alternatywnie, wyróżniony raport może być ustawiony jako reprezentant poprzez wywołanie metody initReport(String reportName).
- Metoda applyDefaults() — przypisywanie wartości domyślnych
- Metoda dataFromUi() — wartość z pola GUI musi zostać skopiowana do kontenera danych
- Metoda dataToUi() — wartość z kontenera danych musi zostać skopiowana do pola GUI
- Metoda validateReportParameters() — należy ustawić raport, który faktycznie ma zostać wykonany. Dodatkowo trzeba zdefiniować relacje między polami GUI a parametrem raportu. Do tego celu dostępne są metody initReport(String reportName) i registerFieldMessages(String reportParameterName, VisualElement element).
Metody klasy Java ReportOutputApplication
Poniżej znajduje się alfabetyczna lista metod i ich znaczenia.
Metoda applyDefaults()
Służy do inicjalizacji wartości parametrów. Wartości muszą być ustawiane w kontenerze danych, a nie w polach GUI. Dostęp do standardowego kontenera danych można uzyskać za pomocą metody getReportOutputData(). Jeśli używany jest własny kontener danych, wartości należy ustawić w nim, a następnie skopiować je do standardowego kontenera danych w metodzie validateReportParameters().
Metoda createParameterField(ReportOutputParameterData parameterData)
Jest wywoływana przez metodę initUserInterface() w celu utworzenia pól GUI. Jeśli dla danego parametru ma zostać utworzone inne pole GUI, można nadpisać tę metodę. Dla wszystkich pól GUI, które są tworzone przez standardową implementację, kontener danych jest inicjalizowany. Do tworzenia pól GUI można wziąć pod uwagę GUID, opis danych logicznego typu danych oraz przełącznik trybu selekcji z obiektu ReportOutputParameterData, aby aplikacja automatycznie dostosowywała się do modyfikacji raportu. Jeśli tworzone są własne pola GUI, powinny one posiadać statyczne GUID-y w kodzie źródłowym Java, ponieważ pozostaną one niezmienne podczas dostosowywania raportu, a tym samym np. już zarejestrowane poprawki elementów interfejsu będą nadal działać. Pole GUI jest polem obowiązkowym, jeśli parametr raportu jest parametrem obowiązkowym lub pole GUI jest oznaczone jako pole obowiązkowe.
Metoda createReportTitleField()
Jeśli nie są używane standardowe mechanizmy do tworzenia pól GUI, za pomocą tej metody można utworzyć pole GUI dla tytułu. Pole GUI jest automatycznie inicjowane.
Metoda dataFromUi()
Służy do kopiowania danych wprowadzonych przez użytkownika z pól GUI do kontenera danych.
Metoda dataToUi()
Ustawia wartości z kontenera danych w polach GUI.
Metoda getReportOutputData()
Metoda dostępu do kontenera danych, który zawiera parametry raportu i ich wartości.
Metoda getReportParametersView()
Metoda dostępu do View, w którym dodawane są wszystkie pola GUI. View ma jednokolumnowy StandardLayout.
Metoda initModel()
Podczas inicjalizacji aplikacji można ustawić raport poprzez nadpisanie tej metody. Jeśli raport zostanie ustawiony przez wywołanie metody initReport(String reportName), w metodzie initUserInterface() pola GUI są automatycznie tworzone.
Metoda initReport(String reportName)
Poprzez wywołanie tej metody, raport jest przypisywany do wykonania. Istnieją dwa momenty, w których raport może zostać przypisany. Pierwszym momentem jest inicjalizacja aplikacji i można na nią wpłynąć poprzez nadpisanie metody initModel(). Najpóźniej po pomyślnym sprawdzeniu wartości w metodzie validateReportParameters() raport musi zostać przypisany, a następnie wartości muszą zostać ustawione w kontenerze danych ReportOutputData.
Metoda initUserInterface()
Ta metoda jest wywoływana w celu utworzenia graficznego interfejsu użytkownika. Standardowa implementacja tworzy pola GUI dla wszystkich parametrów raportu, który został przypisany w metodzie initModel(). Pola GUI są tworzone w kolejności parametrów raportu. Tworzenie odbywa się w trzech krokach. Najpierw wszystkie pola GUI są tworzone przez wywołanie metody createParameterField(ReportOutputParameterData parameterData). Wszystkie utworzone pola GUI są dodawane do SelectionGroup aplikacji, pod nazwą parametru raportu. Dodatkowo dla każdego pola GUI wywoływana jest metoda registerFieldMessages(StringreportParameterName, VisualElement element). W drugim kroku wywoływana jest metoda prepareParameterFields() w celu zainicjowania pól GUI. Następnie pola GUI są dodawane do View.
Do tej metody można również dodawać własne akcje do standardowego paska narzędzi. Istniejące akcje na standardowym pasku narzędzi nie mogą być zmieniane przez podklasy.
Metoda performActionInternal(Action action)
Ta metoda jest wywoływana, gdy metoda perfomAction(Action action) została wywołana dla akcji, która nie jest obsługiwana w klasach bazowych. Są to na przykład własne akcje w standardowym pasku narzędzi.
Metoda prepareParameterFields()
Poprzez nadpisanie tej metody można dokonać inicjalizacji pól GUI przed ich dodaniem do View. Można np. powiązać ze sobą pola GUI dla typu zlecenia i numeru zlecenia. Dodatkowo można zmienić rejestrację pola GUI w SelectionGroup.
Metoda registerFieldMessages(StringreportParameterName, VisualElement element)
W tej metodzie parametr raportu jest powiązany z polem interfejsu graficznego (GUI). Do tego pola GUI dołączane są komunikaty o błędach podczas walidacji parametrów raportu w metodzie validateReportParameters(). Używane przez kontrole parametrów raportu MessageIds pól GUI zaczynają się od 4200.
Metoda setReportParameters(CisParameterList pl)
Ta metoda jest wywoływana podczas otwierania aplikacji raportowej, jeśli aplikacja została uruchomiona z parametrami. Poprzez nadpisanie tej metody można na przykład przenieść wartości z listy parametrów do specyficznych pól GUI aplikacji. Po wywołaniu metody setReportParameters() wywoływana jest metoda dataFromUi(). Standardowa implementacja ustawia wartości parametrów za pomocą SelectionGroup. Jeśli metoda jest nadpisana, należy upewnić się, że wszystkie wartości parametrów są kopiowane do odpowiednich pól GUI.
Metoda validateReportParameters()
W tej metodzie można sprawdzić dane wprowadzone przez użytkownika. Jeśli w metodzie initModel() nie przypisano raportu, należy to zrobić w validateReportParameters(). Dodatkowo, trzeba określić, w którym polu interfejsu graficznego mają być wyświetlane komunikaty o błędach dla parametrów raportu. Odbywa się to poprzez wywołanie metody registerFieldMessages(StringreportParameterName, VisualElement element).
Testowanie aplikacji raportu
Aby przetestować aplikację raportową, można ją otworzyć tak jak każdą inną aplikację dialogową, z poziomu nawigatora lub z aplikacji Obiekty deweloperskie. Należy pamiętać, że jeśli istnieje dostosowany raport typu Obiekt systemowy, zostanie on użyty w czasie działania zamiast przekazanego raportu. Informacja o tym, który raport faktycznie został otwarty, jest zwracana przez metodę initReport(String) w formie komunikatu informacyjnego.
Dokumentowanie aplikacji raportu
Aby udokumentować aplikację raportową, należy utworzyć obiekt deweloperski typu Obiekt pomocy. Obiekt pomocy powinien mieć taką samą nazwę jak aplikacja raportowa. Aplikacja raportowa musi być przypisana do obiektu pomocy na zakładce Obiekty deweloperskie z wagą Standard.
