Podręcznik referencyjny: Konfiguracja

W ramach Konfiguracji funkcje są aktywowane lub dezaktywowane w odniesieniu do systemu, typu organizacji, organizacji lub typu bazy danych, a także ustawiane są parametry specyficzne dla funkcji. Ten artykuł opisuje działanie i wykorzystanie interfejsów systemowych do danych, które można wprowadzić w aplikacji Konfiguracja.

Grupa docelowa

• Programiści
• Konsultanci techniczni

Definicje terminów

• Konfiguracja — przed uruchomieniem systemu Comarch ERP Enterprise jego funkcjonalności muszą zostać dostosowane do specyficznych wymagań biznesowych przedsiębiorstwa. Proces ten nazywa się konfiguracją i odbywa się w systemie konfiguracyjnym klienta.
• Dane konfiguracyjne — w ramach konfiguracji ustawienia i wartości funkcji są zmieniane lub wprowadzane po raz pierwszy. Dane te nazywane są danymi konfiguracyjnymi i mogą mieć wpływ na aplikacje. Niektóre aplikacje odczytują dane konfiguracji jednej lub kilku funkcji i zmieniają swoje zachowanie lub wygląd w zależności od wprowadzonych wartości w danych konfiguracyjnych.
• Dodatkowe dane konfiguracyjne — jeśli dla danej funkcji mają być przechowywane złożone dane, których nie da się odwzorować w jednym obiekcie (np. dane w formie tabeli), edytor konfiguracji może zapisać te tak zwane dodatkowe dane konfiguracyjne w osobnych obiektach biznesowych. Edycja danych odbywa się w tym przypadku zintegrowanie w aplikacji Konfiguracja. Dostęp do danych nie odbywa się za pośrednictwem standardowych interfejsów PGM, lecz musi być udostępniony w postaci oddzielnych klas.
• Edytor konfiguracji — edytor konfiguracji to klasa Java, która dziedziczy po klasie com.cisag.pgm.base.CisCustomizingEditor i jest przypisana do sparametryzowanej funkcji jako edytor
• Funkcja — funkcja w systemie Comarch ERP Enterprise to zestaw funkcjonalności, które są udostępniane użytkownikom (lub nie) za pomocą ustawień w aplikacji Konfiguracja. Funkcja może być zatem aktywna lub nieaktywna w danym systemie. Nie wszystkie funkcje można dezaktywować, niektóre są zawsze dostępne. To, czy funkcja może zostać aktywowana, może dodatkowo zależeć od posiadanych licencji. Niektóre funkcje można sparametryzować. Dzięki temu możliwe jest wprowadzenie ustawień na poziomie całego systemu lub specyficznych dla danego typu organizacji.
• Funkcja sterowana zewnętrznie — funkcja sterowana zewnętrznie to funkcja, która nie jest bezpośrednio wyświetlana w aplikacji Konfiguracja i której wskaźnik Aktywna jest sterowany przez edytor konfiguracji innej funkcji. Funkcje sterowane zewnętrznie są niewidocznymi, dezaktywowalnymi i niesparametryzowanymi funkcjami. Dzięki ich użyciu możliwe jest na przykład zaimplementowanie dezaktywacji aplikacji na podstawie złożonych obliczeń w ramach istniejącego edytora konfiguracji.
• Organizacje — organizacja to typ partnera, za pomocą którego rejestrowane są na przykład przedsiębiorstwa, oddziały, działy itp. Do rejestrowania osób istnieje osobny typ partnera.
  Organizacja może być częścią struktury organizacyjnej w obszarach zadań: Zakup, Logistyka magazynowa, Rachunkowość lub Sprzedaż. Jako element takiej struktury organizacyjnej, organizacja jest również nazywana organizacją zakupową, logistyczną, sprzedażową lub firmą, w zależności od obszaru zadań.
• Struktury organizacyjne — struktura organizacyjna odzwierciedla w zasadzie organizację procesów w grupie przedsiębiorstw. Częściowo odwzorowuje również strukturę. Do korzystania z uprawnień związanych z treścią i do odwzorowywania procesów biznesowych grupy przedsiębiorstw potrzebne są struktury organizacyjne, które można tworzyć dla następujących typów: Zakup, Logistyka magazynowa, Rachunkowość lub Sprzedaż.

Konwencje

Hierarchie

Wewnętrzne organizacje, które należą do struktury organizacyjnej, mogą być w ramach tej struktury uporządkowane w hierarchiczną strukturę o dowolnej głębokości zagnieżdżenia. Wyjątek stanowi struktura organizacyjna Rachunkowość, w której wszystkie uczestniczące organizacje są bezpośrednio podrzędne wobec klienta albo są samym klientem.

Struktura organizacyjna jednego typu nie musi być identyczna ze strukturą organizacyjną innego typu. Organizacja A może być nadrzędna wobec Organizacji B w logistyce magazynowej, podczas gdy w sprzedaży może być dokładnie odwrotnie.

Możliwe wartości dla typów struktur organizacyjnych można znaleźć w klasie com.cisag.pgm.base.OrganizationHierarchyType. Lista wszystkich organizacji w bazie danych OLTP jest udostępniana silnikowi systemowemu przez klasę com.cisag.app.multiorg.logOrganizationInfoProvider w postaci listy obiektów klasy com.cisag.pgm.base.OrganizationInfo. W instancji tej klasy zawarta jest informacja, do jakich typów struktur organizacyjnych należy dana organizacja. Jest całkowicie możliwe, że jedna organizacja należy do kilku typów struktur organizacyjnych.

Wszystkie organizacje, które znajdują się na liście instancji CisOrganizationInfo, będą później wyświetlane w aplikacji Konfiguracja w liście wyboru organizacji. W tym przypadku dane dla funkcji i organizacji mogą być wprowadzone tylko wtedy, gdy obie zawierają te same typy struktur organizacyjnych. Przykładowo, jeśli funkcja jest istotna dla logistyki magazynowej i zakupu, pola wprowadzania będą aktywne tylko dla tych organizacji, które posiadają typ logistyki magazynowej lub zakupu.

Hierarchia organizacji w aplikacji Konfiguracja różni się od hierarchii ustalonych w strukturach organizacyjnych. W aplikacji Konfiguracja każda organizacja ma klienta jako organizację nadrzędną lub jest samym klientem. Rozwiązanie odbywa się więc dwupoziomowo. Dla funkcji specyficznych dla organizacji najpierw sprawdzane jest, czy istnieją dane dla wskazanej organizacji. Jeśli nie, używane są dane klienta (organizacji głównej).

Działanie aplikacji Konfiguracja

W aplikacji Konfiguracja tak zwane funkcje są aktywowane lub dezaktywowane w odniesieniu do systemu lub organizacji, a także ustawiane są parametry specyficzne dla funkcji. W przeciwieństwie do innych aplikacji, poszczególne obiekty (tutaj: funkcje) nie są wybierane w nagłówku, a następnie ładowane, lecz wybiera się je z listy w nagłówku. Inną istotną różnicą jest to, że zawsze wszystkie obiekty są zapisywane jednocześnie. Oznacza to, że można zmodyfikować kilka obiektów, a następnie zapisać wszystkie zmiany jednocześnie, naciskając przycisk [Zapisz] na standardowym pasku narzędzi.

Aplikacje lub obszary, które można dezaktywować za pomocą funkcji

Zarówno w obiekcie deweloperskim Framework, jak i w obiekcie deweloperskim Application, można wprowadzić funkcję. Jeśli ta funkcja jest dezaktywowana w aplikacji Konfiguracja lub brakuje licencji niezbędnej dla tej funkcji dla zarejestrowanego klucza licencyjnego, odpowiednia aplikacja lub obszar zostaje dezaktywowany, co oznacza, że przestaje być widoczny. Jeśli obszar nie jest dezaktywowany, ale wszystkie znajdujące się w nim aplikacje są dezaktywowane, obszar również przestaje być widoczny.

Aplikacje, które można parametryzować za pomocą funkcji

Funkcje mogą posiadać parametry, które można odpytywać w aplikacjach. Dzięki temu zachowanie aplikacji lub liczba widocznych i aktywnych elementów może być sterowana za pomocą parametrów zapisanych w funkcjach w formie ustawień i wartości lub poprzez aktywację i dezaktywację samej funkcji.

Obiekt deweloperski Function

Szczegółowy opis obiektu deweloperskiego Function można znaleźć w artykule Obiekty deweloperskie. W tym artykule przedstawiono jedynie najważniejsze właściwości dotyczące tworzenia nowych funkcji w aplikacji Konfiguracja. W aplikacji Obiekty deweloperskie rejestrowane są obiekty typu Funkcja. Poszczególne pola obiektu są następujące:

• Oznaczenie — w pełni kwalifikowana nazwa funkcji
• Poziom –poziom funkcji definiuje jednostkę, dla której można ustawić wartości konfiguracji dla danej funkcji.
  • Funkcja systemowa — wartości konfiguracji dla funkcji mogą być ustawione raz dla całego systemu Comarch ERP Enterprise. Odpytywanie o wartości może odbywać się niezależnie od aktywnej bazy danych OLTP.
  • Funkcja OLTP — wartości konfiguracji dla funkcji mogą być różne dla każdej bazy danych OLTP. Podczas kopiowania bazy danych OLTP, wartości konfiguracji są również kopiowane. Aby odpytać o wartości, baza danych OLTP musi być aktywna.
• Widok — określa, czy funkcja jest wyświetlana w specyficznej dla aplikacji zakładce aplikacji Konfiguracja. Zazwyczaj funkcje są wyświetlane, gdy są sparametryzowane lub dezaktywowalne, jednak istnieją sytuacje, w których nie jest to pożądane (np. gdy funkcja służy jedynie do łączenia różnych kluczy licencyjnych, więcej informacji znajduje się w rozdziale Specjalne scenariusze i ich rozwiązania).
• Możliwa dezaktywacja — jeśli funkcja jest dezaktywowalna, można ją ręcznie aktywować i dezaktywować w aplikacji Konfiguracja. Funkcje niedezaktywowalne są zawsze aktywne. Jeśli funkcja zostanie później ustawiona jako dezaktywowalna, w wyniku aktualizacji danych wskaźnik Aktywna musi zostać ustawiony na żądaną wartość we wszystkich bazach danych.
• Sparametryzowany — jeśli funkcja jest sparametryzowana, oprócz wskaźnika Aktywna, można również zapisywać wartości w aplikacji Konfiguracja. Do wprowadzania i zmiany tych wartości potrzebna jest klasa Java, która realizuje edytor i powiązane z nim walidacje. Jeśli funkcja ma parametry, należy wybrać wartość Tak.
• Klucz licencyjny — klucz licencyjny, który udostępnia funkcje. Jeśli klucz licencyjny jest określony, funkcja nie może być używana w aplikacji Konfiguracja, jeśli klucz licencyjny nie jest licencjonowany. Jeśli klucz licencyjny nie jest określony, licencjonowanie nie ma bezpośredniego wpływu na to, czy funkcja Konfiguracja może być używana.
• Wymagana funkcja — funkcja logicznie nadrzędna wobec danej funkcji. W aplikacji Konfiguracja funkcja jest wyświetlana hierarchicznie pod funkcją wymaganą. Jeśli funkcja wymagana jest dezaktywowana lub nie może być używana z powodu braku licencji, wszystkie podrzędne funkcje również są dezaktywowane lub nie mogą być używane.
• Klasa Java — klasa, która realizuje edytor sparametryzowanych funkcji. Klasa Java musi dziedziczyć z klasy com.cisag.pgm.base.CisCustomizingEditor. W przypadku funkcji niesparametryzowanych to pole nie ma znaczenia.

Aplikacja Konfiguracja

Szczegółowy opis aplikacji Konfiguracja znajduje się w artykule Konfiguracja. Poniżej opisano jedynie szczegóły techniczne, których znajomość jest niezbędna w procesie tworzenia oprogramowania.

Nagłówek

W nagłówku aplikacji znajdują się następujące pola:

• Funkcja — jest to nazwa wyświetlana wybranej funkcji. Nazwa ta jest ustalana podczas tworzenia obiektu deweloperskiego Function. Wartość w aplikacji Konfiguracja jest tylko do odczytu i nie można jej zmienić.
• Istotny dla — oznacza typy organizacji, dla których możliwe jest utrzymanie danych konfiguracyjnych. Możliwe wartości to: System, OLTP lub Klient, Rachunkowość, Zakup, Logistyka magazynowa, Sprzedaż (możliwe jest jednoczesne zaznaczenie kilku z nich). Wartości te są ustawiane w obiekcie deweloperskim Function. W aplikacji Konfiguracja są tylko do odczytu i nie można ich zmienić.
• Zastosuj dane firmy głównej — ten przełącznik pozwala określić, że dla danej organizacji nie należy przechowywać oddzielnych danych, różniących się od danych organizacji głównej (jest to wartość standardowa). Po pierwszym wyłączeniu przełącznika dane konfiguracyjne organizacji głównej są kopiowane dla danej organizacji i można je dostosować oraz zapisać. Tę wartość można zmienić w aplikacji Konfiguracja.
• Aktywne — wskaźnik do aktywacji funkcji konfiguracyjnej. Włącza lub wyłącza funkcję. Tę wartość można zmienić nie we wszystkich funkcjach, ponieważ istnieją funkcje, bez których system nie może działać. To, czy funkcja jest dezaktywowalna, czy nie, jest definiowane w powiązanym obiekcie deweloperskim.

Obszar roboczy

Obszar roboczy jest podzielony na dwie zakładki:

• Ustawienia
• Informacje

Zakładka Ustawienia zawiera pola wprowadzania parametrów funkcji, która jest aktualnie edytowana. Zakładka Informacje zawiera ogólne, niezmienialne dane o funkcji. Zawartość zakładek oraz pól zostanie szczegółowo opisana poniżej.

Zakładka Ustawienia

Pola na zakładce Ustawienia są specyficzne dla każdej funkcji i są definiowane za pomocą specjalnego obiektu deweloperskiego Part oraz specyficznego edytora konfiguracji, który dziedziczy po klasie com.cisag.pgm.base.CisCustomizingEditor. W szczególnych przypadkach mogą pojawić się dodatkowe dane konfiguracyjne, których nie da się przedstawić w obiekcie Part.

Zakładka Informacje

Poniższe pola są dostępne na zakładce Informacje:

• Obiekt deweloperski — w pełni kwalifikowalna nazwa funkcji (tylko do odczytu)
• Klucz licencyjny — klucz licencyjny, od którego funkcja jest bezpośrednio zależna. Funkcja może być jednak zależna od innych kluczy licencyjnych, jeśli logicznie nadrzędna funkcja również zależy od kluczy licencyjnych.
• Zmienione przez — użytkownik, który wprowadził ostatnie zmiany w danych funkcji dla aktualnie wybranej organizacji
• Zmienione dnia — data ostatniej zmiany
• Pomoc kontekstowa — bezpośrednia pomoc na podstawie obiektu deweloperskiego funkcji.

Te informacje są dostępne dla każdej funkcji i w aplikacji Konfiguracja są nieedytowalne.

Uprawnienia

Dla aplikacji Konfiguracja istotne są uprawnienia związane z aplikacją. Ponadto, następujący obiekt biznesowy jest istotny dla określania uprawnień do aplikacji Konfiguracja:

com.cisag.sys.kernel.obj.FunctionConfiguration

Nie istnieją żadne specjalne uprawnienia ani uprawnienia związane z konkretnymi funkcjami dla aplikacji Konfiguracja.

Rozwój

Ten rozdział opisuje tworzenie i włączanie nowych funkcji do aplikacji Konfiguracja.

Aby dodać nową funkcję do aplikacji Konfiguracja, należy wykonać cztery kroki:

• Zarejestrować obiekt deweloperski typu Function
• Zarejestrować obiekt deweloperski typu Part
• Zarejestrować i zaimplementować obiekt deweloperski typu Klasa Java dla edytora konfiguracji

Kroki Zarejestrować obiekt deweloperski typu Part oraz Utworzyć edytor konfiguracji można pominąć, jeśli funkcja nie jest sparametryzowana. Poszczególne kroki zostaną szczegółowo opisane w kolejnych rozdziałach.

Rejestracja obiektu deweloperskiego typu Function

Podstawowym warunkiem nowej funkcji jest obiekt rozwojowy Function. Musi on zostać utworzony jako pierwszy.

Rejestracja obiektu deweloperskiego typu Part

Jeśli funkcja ma być sparametryzowana, należy utworzyć obiekt Part, który będzie mógł przechowywać parametry. Jest to konieczne również wtedy, gdy wszystkie dane mają być przechowywane jako dodatkowe dane konfiguracyjne.

Dla generycznej kontroli usuwania, czyli sprawdzania, czy dany obiekt jest nadal używany w danych konfiguracyjnych, relacje w obiekcie Part muszą być poprawnie określone.

Tworzenie edytora konfiguracji

Klasa CisCustomizingEditor

Aby rejestrować dane dla funkcji konfiguracyjnej, należy utworzyć edytor konfiguracji, dla którego istnieje dedykowana klasa bazowa com.cisag.pgm.base.CisCustomizingEditor. Aby utrzymać małą liczbę instancji tej klasy i ograniczyć czas uruchamiania aplikacji, aplikacja Konfiguracja zarządza wszystkimi danymi wewnętrznie. Edytor konfiguracji służy wyłącznie do walidacji i wyświetlania danych dla danej funkcji i organizacji. Edytor konfiguracji jest bezstanowy, co oznacza, że ta sama instancja może być wywoływana kolejno dla różnych organizacji. Z tego powodu tymczasowe przechowywanie danych między wywołaniami metod edytora konfiguracji w zmiennych instancji nie jest możliwe i może prowadzić do niespójności danych. Wszystkie dane muszą być przechowywane w obiekcie Part lub ewentualnie w dodatkowych danych konfiguracyjnych. Edytor konfiguracji może być tworzony w dwóch wariantach:

• Zarządzanie danymi obiektu Part
• Zarządzanie dodatkowymi danymi konfiguracyjnymi

Wszystkie wywołania metod edytora konfiguracji z poziomu aplikacji Konfiguracja odbywają się w ramach prawidłowej transakcji. Transakcja ta jest finalizowana za pomocą commit lub rollback, w zależności od działania użytkownika i wyniku walidacji.

Tworzenie edytora konfiguracji

Aby zaimplementować edytor konfiguracji, zazwyczaj nadpisuje się następujące metody klasy bazowej:

• init
• initUserInterface
• dataToUi
• dataFromUi
• validate
• validateDeactivate

Metoda init

Metoda init służy do ogólnej inicjalizacji. Zazwyczaj w metodzie init powinny być tworzone obiekty logiczne i walidacyjne, których edytor konfiguracji potrzebuje. Po inicjalizacji edytora konfiguracji musi mieć możliwość wywołania metod validate i validateDeactivate.

Metoda initUserInterface

Elementy interfejsu edytora konfiguracji w aplikacji Konfiguracja są inicjowane przez wywołanie metody initUserInterface tylko w razie potrzeby, w szczególności tylko wtedy, gdy edytor konfiguracji musi wyświetlić dane. Dzięki temu możliwe jest, że kontrole danych konfiguracyjnych są dostępne również w przypadku dostępu, który następuje poza logowaniami dialogowymi, np. podczas aktualizacji danych lub w programach aktualizujących. Dlatego podczas implementacji należy wziąć pod uwagę, że elementy interfejsu mogły nie zostać utworzone. W tej metodzie tworzone są wszystkie elementy interfejsu i przechowywane jako referencje w zmiennych instancji. Wymagany kontener można pobrać za pomocą View view = getView();. Standardowo ustawiony jest dwukolumnowy układ standardowy. Zazwyczaj ustawia się również wcięcia za pomocą view.setDefaultMargin(VisualElementContainer.INSETS_ALL);. Pola GUI są dodawane do View po ich utworzeniu za pomocą metody add. Następnie ustawiane są identyfikatory komunikatów dla komunikatów o błędach walidacji. Podobnie jak w innych aplikacjach, odbywa się to poprzez wywołanie registerMessage(…) na polach GUI.

Metoda dataToUi

Ta metoda jest wywoływana przez aplikację Konfiguracja, gdy dane muszą zostać przeniesione do elementów interfejsu. Jeśli wywołanie metody isEnabled() zwraca wartość false, pola GUI muszą zostać wyczyszczone. We wszystkich innych przypadkach wartości mogą być wyświetlane w polach GUI. Kontener danych z danymi do przeniesienia można uzyskać przez wywołanie <Part>Mutable part = (Mutable) getData();. Po wypełnieniu danymi, pola GUI muszą być jeszcze ustawione na aktywne/nieaktywne (enabled) oraz edytowalne/nieedytowalne (editable), w zależności od wyniku wywołania metod isEnabled i isEditable. Najprościej można to zrobić za pomocą wywołania setVisualElementProperties(VisualElement[]);,  gdzie przekazywana jest tablica wszystkich pól GUI.

Metoda dataFromUi

W tej metodzie należy odczytać wartości z pól GUI i umieścić je w obiekcie Part.

Metoda validate

Metoda validate służy do sprawdzania spójności danych. Jest ona wywoływana dla każdej kombinacji funkcji i organizacji, dla której mogą istnieć dane i która jest aktywna. Grupa komunikatów używana do walidacji musi być określona z klasy bazowej poprzez wywołanie metody getMessageGroup(), aby pozycjonowanie błędu działało poprawnie. Jeśli walidacja zależności nie jest konieczna, walidacja dla danych odziedziczonych z organizacji głównej może zostać pominięta. To, czy dane pochodzą wyłącznie z dziedziczenia od organizacji głównej, można sprawdzić, wywołując metodę isDataInherited(). Poprawność danych zależy od obecności komunikatów o błędach.

Metoda validateDeactivate

Ta walidacja jest wywoływana, gdy funkcja dla odpowiedniej organizacji ma zostać dezaktywowana lub jest już dezaktywowana. Jeśli funkcja w danym kontekście nie może lub nie powinna być już dezaktywowana, w tej metodzie należy wysłać odpowiedni komunikat o błędzie.

Edytor konfiguracji z dodatkowymi danymi konfiguracji

Jeśli edytor konfiguracji potrzebuje więcej danych, niż można przechowywać w obiekcie Part, można to zrealizować za pomocą dodatkowych danych konfiguracyjnych. Te dane mogą zawierać informacje o stanie lub dane z innych tabel.

Jeśli edytor konfiguracji ma pracować z dodatkowymi danymi konfiguracyjnymi, zazwyczaj nadpisuje się dodatkowo następujące metody klasy CisCustomizingEditor:

• Metoda loadAdditionalData —  metoda jest wywoływana podczas ładowania danych dla każdej możliwej kombinacji. Jeśli na przykład funkcja jest zarejestrowana dla wszystkich organizacji typu struktury organizacyjnej Logistyka magazynowa, metoda zostanie wywołana dla każdej z nich. Jeśli dodatkowe dane konfiguracyjne są potrzebne dla danej kombinacji, należy wywołać metodę setAdditionalData. Rejestruje ona kontener danych i jego kopię zapasową. Tylko po wywołaniu setAdditionalData inne metody dla dodatkowych danych konfiguracyjnych zostaną wywołane w dalszej kolejności.
• Metoda duplicateAdditionalData — metoda jest wywoływana, gdy po raz pierwszy dezaktywowany jest parametr Zastosuj dane firmy głównej. Dane firmy głównej są przekazywane jako szablon.
• Metoda clearAdditionalData — edytor konfiguracji musi przywrócić dodatkowe dane konfiguracyjne do stanu początkowego
• Metoda isAdditionalDataChanged — pozwala aplikacji Konfiguracja na określenie, czy dodatkowe dane konfiguracyjne zostały zmienione. Zapisywane są tylko zmienione dane.
• Metoda updateAdditionalData —  w tej metodzie można zapisać dodatkowe dane konfiguracyjne
• Metoda deleteAdditionalData — jeśli funkcja jest dezaktywowana, zawartość dodatkowych danych konfiguracyjnych w bazie danych musi zostać usunięta. W tej metodzie należy zaimplementować to usunięcie.
• Metoda boolean isSupportedOrganization(CisOrganizationInfoinfo) –metoda zwraca wartość true, jeśli wybrana organizacja ma typ struktury organizacyjnej, który jest dostępny dla danej funkcji. Jeśli typ struktury organizacyjnej nie jest dostępny dla danej funkcji, danych dla tej funkcji nie można wprowadzić dla wybranej organizacji. Jeśli istnieją inne lub bardziej złożone kryteria niż typ struktury organizacyjnej, odpowiednią logikę można zaimplementować tutaj.
• Metoda boolean isDataInherited(CisOrganizationInfo ouInfo) — jeśli dodatkowe dane dla firmy głównej są zmieniane, muszą one być replikowane dla wszystkich organizacji, które dziedziczą swoje dodatkowe dane z organizacji głównej. Ta metoda umożliwia sprawdzenie, czy dana organizacja dziedziczy swoje dane konfiguracyjne, czy też nie.

Rejestrowanie powiązania z organizacją

Dla funkcji, które mają mieć edytora konfiguracji lub są sparametryzowane, należy zarejestrować powiązania z organizacją w sekcji Powiązanie z organizacją. Jeśli funkcja ma dotyczyć tylko całej bazy danych OLTP, nie ma potrzeby rejestrowania powiązania z organizacją, ponieważ taka funkcja domyślnie dotyczy całej bazy danych OLTP.

Funkcje sterowane zewnętrznie

Edytor konfiguracji ma możliwość sterowania wskaźnikiem aktywności innych funkcji. Te funkcje sterowane zewnętrznie nie mogą być sparametryzowane, muszą być dezaktywowalne, nie mogą być wyświetlane, muszą obsługiwać te same typy struktur organizacyjnych co funkcja edytora konfiguracji i nie mogą być sterowane zewnętrznie przez żadną inną funkcję.

Wartości wskaźnika Aktywne funkcji sterowanej zewnętrznie edytor konfiguracji nie może zapisywać samodzielnie, w szczególności nie może jej przechowywać w swoim obiekcie Part.

• Metoda String [] getManagedFunctionNames() — metoda musi zostać nadpisana, jeśli edytor konfiguracji ma przejąć kontrolę nad innymi funkcjami. Nazwy funkcji są pobierane przez aplikację Konfiguracja podczas inicjalizacji. Należy zwrócić w pełni kwalifikowane nazwy funkcji, którymi ma zarządzać.
• Metoda boolean isManagedFunctionActivated( String name ) — metoda zwraca true, jeśli funkcja o podanej nazwie jest aktywna. Ta metoda jest zazwyczaj wywoływana w metodzie dataToUi.
• Metoda setManagedFunctionActivated( String name, boolean activated) — metoda ustawia status odpowiedniej funkcji na wartość parametru activated. Ta metoda jest zazwyczaj wywoływana w metodzie dataFromUi().

Pobieranie danych konfiguracyjnych

W niektórych aplikacjach należy sprawdzić istnienie określonych funkcji, zanim pewne działania w aplikacji będą możliwe lub dozwolone. Do pobierania funkcji systemowych i funkcji OLTP dostępne są metody w trzech interfejsach PGM. Ponadto, do dostępu do interfejsu PGM com.cisag.pgm.appserver.CisSystemManager istnieje klasa com.cisag.app.customizing.Customizing, która udostępnia bezpośrednie metody dostępu dla większości funkcji, aby uprościć dostęp.

Interfejsy PGM

• com.cisag.pgm.appserver.CisSystemManager — dla dostępu z poziomu zwykłych aplikacji i klas logicznych
• com.cisag.pgm.base.CisUpdateBase — w przypadku, gdy klasa aktualizacyjna dla obiektu biznesowego musi odpytać o dane konfiguracyjne, metody muszą być wywoływane bezpośrednio na klasie com.cisag.pgm.base.CisUpdateBase. Klasy aktualizacyjne rozszerzają klasę CisUpdateBase specyficznie dla danego obiektu biznesowego.
• com.cisag.pgm.base.UpdateApplication — w przypadku, gdy aktualizacja danych musi odpytać o dane konfiguracyjne aplikacji Konfiguracja, metody muszą być wywoływane bezpośrednio na klasie com.cisag.pgm.base.UpdateApplication. Aktualizacje danych rozszerzają klasę UpdateApplication.

W ogólnym przypadku aplikacji (działającej w tle lub dialogowej) metody należy wywoływać na klasie CisSystemManager. Instancję interfejsu CisSystemManager można uzyskać poprzez wywołanie: CisEnvironment.getInstance().getSystemManager();.

Dla konkretnej funkcji można odpytać o dwie rzeczy. Po pierwsze, czy żądana funkcja w ogóle jest dostępna, poprzez wywołanie isAvailable(), a po drugie, powiązany obiekt konfiguracyjny poprzez wywołanie metody getConfiguredValues().

W zależności od poziomu funkcji (System, OLTP lub Organizacja) przy wywoływaniu metod należy podać organizację jako drugi parametr w przypadku utrzymania specyficznego dla organizacji, lub pominąć go w przypadku funkcji na poziomie systemu lub bazy danych OLTP. Jeśli podana zostanie GUID organizacji, mimo że funkcja jest zarządzana na poziomie systemu (lub OLTP), zostanie zgłoszony wyjątek. Podobnie, jeśli nie zostanie podana GUID, mimo że funkcja jest zarządzana na poziomie organizacji, również zostanie zgłoszony wyjątek.

Zanim dane konfiguracyjne dla funkcji zostaną odpytane, zawsze należy sprawdzić, czy funkcja w ogóle jest dostępna. Jeśli funkcja jest dezaktywowana, nieposiadająca licencji lub nieskonfigurowana, zostanie zgłoszony wyjątek, jeśli mimo to nastąpi próba odpytania o dane.

Do odpytywania o dane konfiguracyjne służą następujące metody w każdej z wymienionych wyżej klas:

• isAvailable(String function) — zapytanie o dostępność dla funkcji systemowej lub funkcji OLTP niezależnej od organizacji
• isAvailable(String function, byte[]organizationGuid) — zapytanie o dostępność dla funkcji OLTP zależnej od organizacji
• getConfiguredValues(String function) — zapytanie o dane konfiguracyjne dla funkcji systemowej lub funkcji OLTP niezależnej od organizacji
• getConfiguredValues(String function, byte[]organizationGuid) — zapytanie o dane konfiguracyjne dla funkcji OLTP zależnej od organizacji

Klasa Customizing

Klasa com.cisag.app.customizing.Customizing to zbiór metod, które hermetyzują dostęp do interfejsów PGM opisanych w poprzedniej sekcji, przeznaczonych dla poszczególnych funkcji.

Korzyści z używania tej klasy to:

• Uproszczenie użycia dzięki konkretnie stypizowanym interfejsom dla każdej funkcji
• Mniejsza podatność na błędy podczas użytkowania dzięki kontrolom w czasie kompilacji. Nazwy funkcji znajdują się tylko w jednym miejscu w kodzie źródłowym Java.
• Pośredni dowód użycia funkcji, oparty na wykorzystaniu metod dostępu

Dlatego też, w kodzie aplikacji zaleca się preferencyjne używanie tej klasy do uzyskiwania dostępu do danych konfiguracyjnych.

Poniżej znajduje się fragment implementacji tej klasy:

/**

* Returns the configured value of <tt>com.cisag.app.General.</tt>

*

* @return The value, not <code>null</code>

/*

public static com.cisag.app.customizing.obj.GeneralMutable

getGeneral() {

return (com.cisag.app.customizing.obj.GeneralMutable)

getConfiguredValues(„com.cisag.app.General”);
}

/**

* Returns whether or not <tt>com.cisag.app.Sales</tt>

* is available for specified sales organization.

*

* @return <code>true</true> if the function is available.

 */
public static boolean isSalesAvailable(byte[] salesOrganization) {

return isAvailable(„com.cisag.app.Sales”,

maintainingSales(salesOrganization));

}

Specjalne scenariusze i ich rozwiązania

Aplikacje z wieloma kluczami licencyjnymi i funkcjami

Istnieją aplikacje, które mają zależeć od dostępności kilku kluczy licencyjnych. Jeśli aplikacja jest aktywowana (lub dezaktywowana) za pomocą funkcji jeden, można podać tylko jeden klucz licencyjny. Aby zamodelować zależność od kolejnego klucza licencyjnego, definiuje się zależność funkcji jeden od innej funkcji dwa. Funkcja dwa jest wtedy zależna od drugiego klucza licencyjnego. Obie funkcje są zdefiniowane jako niewidoczne, niesparametryzowane i niedezaktywowalne. Dzięki temu aplikacja jest automatycznie aktywowana tylko wtedy, gdy oba klucze licencyjne są włączone w licencji.

Złożone warunki dla logiki dostępności funkcji

Istnieją aplikacje, w których kryterium ich dostępności nie zależy jedynie od istnienia innych funkcji lub kluczy licencyjnych. Jeśli logika, kiedy aplikacja ma być dostępna, jest bardziej złożona, niż można to odwzorować za pomocą metadanych, należy użyć funkcji sterowanej zewnętrznie. Funkcja jeden ma edytor konfiguracji, w którym wprowadzane są wszystkie istotne dane, niezbędne do podjęcia decyzji o dostępności. Funkcja dwa jest funkcją sterowaną zewnętrznie, której parametr Aktywne jest kontrolowany przez edytor konfiguracji funkcji jeden. Dla samej aplikacji funkcja dwa jest następnie wprowadzana jako wymagana. Z perspektywy użytkownika aplikacji Konfiguracja funkcja dwa jest niewidoczna.