Najlepsze praktyki projektowania raportów

W tym temacie opisano kluczowe czynniki, które należy wziąć pod uwagę w przypadku użycia Application Studio do pisania raportów na kostkach OLAP.

Uwagi dotyczące frontonu

Poniższa tabela pokazuje kluczowe kwestie związane z projektowaniem raportów na frontonie:

Kwestia Opis
Czy raporty zawierają zagnieżdżone hiperbloki? Raportowanie na podstawie wycinka, w którym hiperblok jest filtrowany, np. w celu wykluczenia wartości null, działa lepiej. Istnieje krzywa uczenia się powiązana z korzystaniem z wycinków i brakuje niektórych potrzebnych funkcji, ale dostępne funkcje zaspokajają potrzeby 80% przypadków użycia.
Czy raporty wymagają pionowego przewijania? Jeśli tak, włącz rozszerzenie sieci Web widoku stron w stopce raportu. Zwiększa to komfort użytkownika i wydajność.
Czy raporty korzystają z formatowania warunkowego? Formatowanie warunkowe to zaawansowana funkcja, ale należy jej używać oszczędnie ze względu na wpływ na wydajność podczas oceny warunków. Należy unikać formatowania warunkowego przy korzystaniu z formatu liczbowego i poleganiu na formatach liczbowych zdefiniowanych w bazie danych. Application Studio tworzy klastry żądań danych z formuł, które są wysłane do bazy danych OLAP. Wynikiem jest jedna ogólna kwerenda zamiast wielu kwerend dla pojedynczych komórek. Klastrowane kwerendy są szybsze niż dostęp do pojedynczych komórek. Formuły odczytu danych w formatowaniach warunkowych i skokach raportów nie mogą być klastrowane i jako zapytanie do pojedynczej komórki zawsze są tworzone kwerendy.
Czy raporty arkuszy stylów są zbyt rozbudowane? Pomyśl o prostocie podczas opracowywania nowych arkuszy stylów i w miarę możliwości nie dodawaj zawartości do istniejących arkuszy stylów. Liczba stylów zwiększa rozmiar raportu.
Czy określono zaznaczenie początkowe dla jednostek raportu? Raporty ładują się szybciej, jeśli ostatnia wizualizowana przez użytkownika jednostka jest przechowywana. Jeśli na przykład raport jest ładowany na poziomie wszystkich jednostek, to znacznie więcej danych musi zostać pobranych, a ładowanie raportu zajmuje więcej czasu.
Czy używasz formantów bezstanowych, takich jak obiekty typu wyszukiwanie, a nie formantów opartych na widokach list? Formanty oparte na widokach list, takie jak pola kombi, pobierają listy elementów, gdy raport jest ładowany. Formanty bezstanowe nie pobierają list elementów, dzięki czemu ładują się szybciej.
Czy dokładnie testujesz raporty? Można tworzyć raporty, które łączą ciągi w celu uzyskania ID elementów, ale jeśli wyślesz żądanie do serwera OLAP dla elementów, które nie istnieją, ryzykujesz wystąpienie błędów i przekroczenie limitu czasu. Testowanie powinno zawsze uwzględniać ustawienia zabezpieczeń użytkownika końcowego.
Filtry listy Niektóre typy filtrów są wolniejsze od innych, na przykład filtry atrybutów są wolniejsze niż filtry wartości. Filtry ogólne są wolniejsze niż wybory struktury. Unikaj dużych obszarów danych w filtrach. Im więcej elementów zostanie wybranych na wymiar, tym filtr będzie działał wolniej.
Akcje globalne Rozważ użycie akcji globalnych, aby zmniejszyć czas potrzebny na obliczenia pojedynczych raportów. Akcje globalne są uruchamiane podczas logowania użytkownika, po utworzeniu modelu repozytorium i przed utworzeniem jakiegokolwiek silnika. Zmienne globalne są już ustawione przed rozpoczęciem ładowania jakiegokolwiek raportu.
Zmienna raportu Unikaj dużych ciągów w zmiennych.

Uwagi dotyczące usług wewnętrznych, środowiska i kwestii interpersonalnych

W udanym projekcie istnieje pętla sprzężenia zwrotnego między programistami raportów a autorami kostek. Zły projekt kostki jest prawdopodobnie największym czynnikiem słabej wydajności. W tabeli pokazano ważne czynniki, które należy wziąć pod uwagę:

Kwestia Opis
Tworzenie i testowanie raportów z realistycznymi zestawami danymi Raporty, w których wymiary zawierają do 30 elementów, a kostki zawierają kilkaset punktów danych, mogą osiągać dobre wyniki, ale są trudne w zarządzaniu ze względu na duży zestaw danych. Ważne jest, aby przeprowadzać testy przy użyciu realistycznych zestawów danych.
Tworzenie poprawnie działających reguł OLAP. Przykład źle napisanej reguły: [Przychód] = [Cena] * [Ilość] lub [Konto1] = [Konto2] + [Konto3] + [Konto4] Zapoznaj się z najlepszymi praktykami dotyczącymi pisania reguł OLAP. Poszukaj wskazówek w dokumentacji online.
Wymiary o złej strukturze Rozważ wymiar produktu z pierwszym elementem Wszystkie produkty, ale 10 000 elementów podrzędnych. W pewnym momencie użytkownik prawdopodobnie wyzwala żądanie do serwera OLAP, które wymaga, aby wszystkie elementy były pobierane i potencjalnie wyświetlane. Poziomy pośrednie sprawiają, że raport oparty na hierarchii jest bardziej wydajny.
Duża liczba użytkowników Unikaj zmiany wymiarów w godzinach pracy, gdy największa liczba użytkowników jest online.
Brakujące elementy nadrzędne w wymiarach, na przykład element sumy rocznej Raport, który pobiera dzienne dane w ukrytych kolumnach, aby je zsumować i wyświetlić jako sumę roczną, jest znacznie wolniejszy niż taki, w którym suma jest obliczana w bazie danych OLAP.
Niewłaściwe użycie atrybutów Atrybuty mogą być dowolnie definiowane i używane do filtrowania raportów, ale filtrowane raporty działają gorzej niż hierarchia, która grupuje elementy według potencjalnych wartości atrybutów.
Wystarczająca ilość pamięci RAM serwera OLAP OLAP to baza danych w pamięci. Źle napisane kwerendy mogą zużywać znaczną ilość pamięci RAM. Jeśli na serwerze OLAP odbywa się stronicowanie, można spodziewać się niskiej wydajności.
Unikanie umieszczania danych transakcyjnych w kostkach Infor OLAP zoptymalizowano pod kątem raportowania na poziomie bilansu. Można zbudować niewydajny raport bez przeszkód ze strony aplikacji. Na przykład można zbudować szczegółową kostkę na podstawie pliku wierszy zamówienia zakupu, ale prawdopodobnie nie będzie ona wydajna.
Napisanie złego raportu jako krótkoterminowej poprawki Nie ulegaj presji projektu, robiąc coś, co utworzy niewydajny raport. Zapisz swoje obawy i zasugeruj alternatywne rozwiązania.
Unikanie przechowywania zer w kostce Zero jest liczbą, która musi być przechowywana w pamięci OLAP i obliczana w regułach w przeciwieństwie do alternatywy w postaci wartości null. Można utworzyć procesy Application Engine, które mogą zamieniać zera w kostce na wartości null.
Najlepsze miejsce do wykonania obliczeń Zależy to od wielu czynników, w tym od tego, jak często wymagane są wartości obliczeniowe. Przykładowe opcje miejsca wykonywania obliczeń, w kolejności wg preferencji:
  • W systemie źródłowym
  • W ramach procesu ładowania danych
  • Obliczone i przechowywane w OLAP przez Application Engine
  • W OLAP przy użyciu reguł dynamicznych
  • Jako obliczenie (element sesji) w repozytorium
  • W Application Studio jako część raportu
Ustawienie elementów domyślnych Jeśli nie zostaną wybrane określone elementy domyślne wymiarów hierarchicznych, pierwszy element zostanie wybrany jako domyślny. Wymaga to więcej czasu na resetowanie elementów domyślnych. Bieżące elementy domyślne są ustawione w rozszerzonych właściwościach wymiaru.
Użycie interfejsu XML jest wolniejsze niż komunikacja poprzez wbudowany interfejs w wersji 11 Aby przyspieszyć komunikację, zalecamy, aby nie odczytywać wartości za pomocą żądań pojedynczych komórek, ale umieścić je w jednym lub kilku żądaniach do OLAP. Można to zrobić za pomocą żądania odczytu kostki, dodając wiele znaczników CellCoordinate.
Użycie widoku stron po stronie serwera, aby utworzyć raport, który zapyta tylko o widoczne wartości Widok stron w hiperblokach znajduje się po stronie klienta. Wszystkie komórki są zwracane z serwera, ale rysowana jest tylko strona.

W listach OLAP użyj funkcji podzbioru do widoku stron po stronie serwera.

W listach relacyjnych użyj zaawansowanych metod w kwerendzie, aby tworzyć podzbiory.
Filtrowanie kwerend, aby nie obejmowały wszystkich elementów z danego wymiaru Użyj pomijania wartości null, aby pokazać tylko wypełnione komórki, pokaż wszystkie elementy pod określonym elementem nadrzędnym zamiast całego wymiaru. Zmniejsz początkowy poziom rozwinięcia w wycinkach i listach.
Unikanie umieszczania dużej liczby wymiarów na osi Optymalna liczba to trzy wymiary na oś wierszy, jeden wymiar na oś kolumn.