Oracle EBS mechanizmy dostosowywania i rozszerzania systemu

XI Konferencja PLOUG Kościelisko Październik 2005 Oracle EBS mechanizmy dostosowywania i rozszerzania systemu Barbara Reimschűssel-Wąs Softbank S.A. e mail: b.was@softbank.pl Streszczenie Sesja ma na celu zaprezentowanie tych cech systemu Oracle E-Business Suite, które decydują o jego otwartości i łatwości modyfikacji, a następnie, w oparciu o przedstawione własności, omówienie podstawowych mechanizmów wykorzystywanych przy dostosowywaniu oraz modyfikowaniu systemu. Na początku przypomniane zostaną pokrótce komponenty architektury systemu, ze wskazaniem komponentów umożliwiających jego rozszerzalność. Następnie omówione zostaną poszczególne metody dostosowywania systemu, poczynając od podstawowych, nie wymagających zmian w kodzie, po programistyczne. Będą to: 1. Definicje zestawów wartości. a. Sposoby kontrolowania wartości w zestawie. b. Definicje zestawów wartości zależnych od siebie. 2. Profile osobiste i systemowe. a. Wykorzystanie zestawów wartości w definicji profilu. 3.Wzorce kluczowe. a. Wzorzec konta. 4. Wzorce opisowe. 5. Definiowanie nowych zleceń współbieżnych, ze szczególnym uwzględnieniem raportów. 6. Dostosowywanie menu, dodawanie nowych elementów menu. 7. Dopasowywanie ekranów poprzez mechanizm folderów. 8. Dostosowywanie ekranów poprzez bibliotekę CUSTOM.PLL. 9. Dodawanie nowych, od nowa napisanych modułów. Niektóre z tych mechanizmów są wykorzystywane również w standardzie systemu (zestawy wartości, profile, wzorce, standardowe raporty) i dla nich prezentacja zostanie zilustrowana przykładem zastosowania w standardzie. Dla każdego z mechanizmów pokazane też zostanie, jak go wykorzystywać we własnych rozszerzeniach i modyfikacjach. Informacja o autorze Autorka pracuje w firmach wykorzystujących produkty firmy Oracle od 1998 r., w tym od 1999 r. w firmie Softbank S.A. Wraz z firmą Softbank S. A. zajmowała się m.in. wdrożeniami systemu Oracle EBS, pełniąc funkcję kierownika zespołu technicznego, projektującego oraz implementującego rozszerzenia i modyfikacje. Posiada certyfikaty firm Microsoft i Sun.

Oracle EBS mechanizmy dostosowywania i rozszerzania systemu 259 1. Wprowadzenie Wiadomo powszechnie, że wdrożenie tak rozbudowanego systemu klasy ERP, jakim jest Oracle e-business Suite1 (Oracle EBS), to proces trwający niekiedy nawet kilkanaście miesięcy. Obejmuje on nie tylko to, co potocznie rozumiemy przez parametryzację, czyli nadanie konkretnych wartości pewnemu ustalonemu zbiorowi parametrów, decydujących o sposobie działania i funkcjonalności systemu. Jak wielki bowiem nie byłby taki zbiór, a w przypadku Oracle EBS składa się on z tysięcy elementów, parametry w nim zawarte nie wystarczają na taki poziom dostosowania systemu do potrzeb firmy, jaki jest wymagany. Istotne są tu zwłaszcza dwa obszary takiego dostosowania: Uwzględnienie w systemie standardów firmowych w prezentacji czyli wyglądu jak i zawartości informacyjnej interfejsu użytkownika. Adaptacja obejmuje tu zazwyczaj wygląd ekranów i raportów. Zmiany samej logiki biznesowej, w tym zmiany procesów biznesowych, uwzględnienie nowych danych, które muszą być przechowywane przez system, a nie zostały przewidziane w standardzie, wprowadzenie nowych reguł biznesowych. Wszystko to jest możliwe przy pomocy mechanizmów dostarczanych przez Oracle EBS. Pozwalają one na: Deklaratywne dodawanie pól definiowanych przez użytkownika. Zmiany procesów biznesowych. Tworzenie nowych reguł biznesowych. Daleko idące zmiany wyglądu i działania ekranów. Oczywiście jeśli to nie wystarcza, jest możliwe także rozszerzanie systemu poprzez tworzenie nowego kodu oraz zmianę kodu istniejącego. W przeciwieństwie do innych znanych systemów ERP, Oracle EBS pozwala to zrobić przy użyciu standardowych narzędzi programistycznych Oracle, bez konieczności używania specjalnego języka, wymyślonego wyłącznie na potrzeby systemu. Udostępnia też klientom dużą część kodu systemu, w tym cały kod sterujący interfejsem użytkownika oraz po stronie bazy danych. Rozszerzenia to jednak ostateczność. Ich konsekwencją są na ogół trudności z utrzymywaniem i podnoszeniem wersji systemu w przyszłości. Dlatego też wymienione wyżej mechanizmy dostosowywania są rozwijane z wersji na wersję. To, co jeszcze w wersji 11.5.9 wymagało tworzenia kodu, w wersji 11.5.10 może być już zrealizowane w sposób deklaratywny (czyli poprzez zmiany wprowadzane w samej aplikacji), dzięki czemu koszty utrzymania systemu mogą być mniejsze. W artykule tym omówione zostaną niektóre mechanizmy, wykorzystywane w Oracle EBS przy dostosowywaniu systemu. Będą to głównie mechanizmy podstawowe, wykorzystywane jeszcze w wersji 11.5.9. Jak zostało wcześniej wspomniane, wersja 11.5.10 wprowadza kilka nowych, niekiedy bardzo istotnych metod, nie będą one jednak przedmiotem szczegółowych rozważań ze względu na brak doświadczeń w pracy z nimi w rzeczywistym projekcie. Ponieważ nie jest celem artykułu, ani też nie byłoby to możliwe w zakładanym czasie, omówienie podstawowych pojęć związanych z systemem Oracle EBS, takich jak nawigacja, autoryzacja (moduł), czy też funkcja menu, musiało zostać przyjęte założenie, że czytelnikowi/słuchaczowi 1 W dokumentacji oraz potocznie używa się zamiennie nazw Oracle Applications oraz Oracle ebusiness Suite, przy czym można zauważyć tendencję do coraz częstszego posługiwania się drugą z nich. Dlatego też w niniejszym artykule używane będzie wyłącznie: pełna nazwa Oracle ebusiness Suite oraz skrót Oracle EBS.

260 Barbara Reimschűssel-Wąs choć trochę są te pojęcia znajome, choćby w wyniku zapoznania się z innymi materiałami konferencyjnymi. Ponieważ najczęściej jedyną dostępną instancją systemu, na której czytelnicy/słuchacze mogliby wypróbować prezentowane mechanizmy, jest instancja bazy demonstracyjnej Vision, a nie ma ona na ogół zainstalowanych innych języków niż amerykański angielski, wszelkie nazwy obiektów Oracle EBS będą w artykule podawane w języku angielskim, aby były one zgodne z tym co można zobaczyć. 2. Rzut oka na architekturę systemu Zanim przejdziemy do sposobów dostosowywania zachowań systemu, konieczne jest zapoznanie się z jego budową. Oracle EBS oparty jest o trójwarstwową architekturę, w której na każdej z warstw wykorzystywane są komponenty dostarczane przez Oracle. 2.1. Warstwa prezentacji Rys. 1. Architektura systemu Oracle E-Business Suite Interfejs użytkownika realizowany jest, w przypadku nowszych modułów (dawniej zwanymi modułami Self Service), przez dynamicznie generowane strony zawierające HTML i JavaScript. Dla modułów starszych rolę tę pełnią aplety Javy, generowane przez Forms Server na podstawie formularzy Oracle Forms Builder a.. Aplety te wykonują się we własnej, dostarczonej przez Oracle maszynie wirtualnej Jinitiator (w 11.5.10 jest to wersja 1.3.1.18, zgodna z JDK 1.3), instalowanej automatycznie przy pierwszym uruchomieniu systemu. Taki dualizm implementacji oznacza, że choć niektóre mechanizmy są wspólne, to istnieją również różnice w dostosowywaniu obu rodzajów modułów. Chociaż przy każdym wydaniu systemu zwiększana jest liczba modułów opartych o HTML (obecnie około 60), to nadal kluczowe moduły takie jak: Księga Główna, Należności, Zobowiąza-

Oracle EBS mechanizmy dostosowywania i rozszerzania systemu 261 nia zaimplementowane są przy pomocy technologii Oracle Forms. Dlatego też w pierwszej kolejności prezentowane będą metody dotyczące tych części systemu. 2.2. Warstwa aplikacji Warstwą pośrednią systemu zarządza serwer aplikacji Oracle 9iAS (1.0.2.2.2). Obsługuje on zarówno komunikację pomiędzy warstwami, jak i jest miejscem przetwarzania logiki biznesowej aplikacji. Jednym z istotnych dla sposobu funkcjonowania systemu składników serwera aplikacji jest Concurrent Processing Server, który zarządza procesami uruchamianymi z Oracle EBS w tle, w trybie asynchronicznym, tzw. zleceniami współbieżnymi. Mogą być one uruchamiane ad-hoc lub automatycznie, według zadanego harmonogramu, a użytkownik może w tym samym czasie kontynuować pracę w trybie interaktywnym. Poprzez zlecenia współbieżne realizowana jest główna część raportowania w systemie, mechanizm zleceń jest więc siłą rzeczy często wykorzystywany w trakcie dostosowywania i rozszerzania systemu. Rys. 2. Okno przeglądu zleceń współbieżnych w Oracle EBS Raporty wykonywane są w większości przez Reports Server, uruchamiany na platformie Oracle 9iAS. Definicje raportów pliki rdf, tworzone są przy użyciu Oracle Reports Builder 6i (część Developera 6i) tym więc narzędziem muszą być modyfikowane raporty dostarczane z systemem. Również nowe raporty tworzy się najczęściej w ten sam sposób, choć w wersji 11.5.10 istnieje również możliwość wykorzystania w tym celu Oracle XML Publisher a, o którym nieco więcej poniżej.

262 Barbara Reimschűssel-Wąs 2.3. Warstwa bazy danych Rys. 3. Obsługa żądania wykonania raportu Oracle Reports. Wszystkie dane biznesowe dla Oracle EBS zarządzane są przez bazę Oracle 9i Release 2. W wydaniu 11.5.10 wykorzystywanych jest do tego ok. 270 000 obiektów bazy danych (dla instancji demonstracyjnej Vision). Model bazy danych udokumentowany jest przy pomocy dostępnego on-line repozytorium e-trm. Rys. 4. Widok stron etrm udostępniających informacje modelu danych Oracle EBS 2.3.1. Podstawowe cechy modelu bazy danych Jedna instancja bazy danych może przechowywać dane tylko dla jednej instalacji Oracle EBS. Generalnie dane te są zorganizowane zgodnie z zasadą, że dla każdego osobnego produktu (modu-

Oracle EBS mechanizmy dostosowywania i rozszerzania systemu 263 łu) właścicielem obiektów danych jest osobny schemat związany z tym produktem, tak jak to pokazano na przykładach poniżej. Moduł Kod aplikacji Nazwa schematu Biblioteka obiektów FND APPLSYS, aplikacji APPS Administracja SYSADMIN APPLSYS AD Prefix nazw obiektów bazy FND Księga główna SQLGL GL GL, JE, JG Należności AR AR AR, HZ, RA Zobowiązania SQLAP AP AP, JE, JG Tabela 1. Przykłady schematów dla niektórych modułów Oracle EBS. Wszystkie te dane są również widoczne poprzez synonimy przez schemat APPS. Tam też powinien znajdować się cały kod aplikacji (a także widoki), zasada ta nie jest jednak przestrzegana w 100%. APPS jest głównym schematem, do którego loguje się aplikacja, dlatego też każdy nowo dodawany (na przykład w wyniku rozszerzenia) obiekt musi mieć również utworzone synonimy dla APPS. Wskazane też jest, aby zawsze, we wszystkich konstrukcjach SQL stosować synonimy APPS, a nie tabele z innych schematów. Zdarza się bowiem, że chociaż dany synonim nazywa się dokładnie tak samo jak jakaś tabela, to jednak odwołuje się on nie do tej tabeli, a do widoku opartym o zupełnie inne obiekty. 2.3.2. Dane inne niż biznesowe Oprócz danych biznesowych, w bazie danych przechowywane są również, jako osobne moduły, dane systemowe, wykorzystywane przez wewnętrzne komponenty samego systemu, wspólne dla wszystkich modułów Oracle EBS, takie jak: DBA Aplikacji Oracle (moduł AD), Narzędzia do administrowania i zarządzania systemem. Biblioteka Obiektów Aplikacji (FND), Są to podstawowe obiekty repozytorium metadanych systemu. To tu są między innymi informacje o produktach wchodzących w skład systemu, użytkownikach, autoryzacjach, programach i zleceniach. Oracle Workflow (FND), Grupa obiektów, w których przechowywane są informacje o narzędziu Oracle Workflow, zintegrowanym z Oracle EBS. W wielu przypadkach jest ono preferowanym sposobem wprowadzania zmian do logiki biznesowej systemu. Oracle Alert (ALR), Dane aplikacji służącej do definiowania i zarządzania alertami, dzięki którym można monitorować zdarzenia biznesowe oraz systemowe w Oracle EBS. Oracle Alert umożliwia także definiowanie akcji, które mają być wykonywane po zaistnieniu każdego zdarzenia. Mogą to być powiadomienia pocztowe, SMS-y lub wykonanie różnych operacji w samych aplikacjach. Oracle Applications Framework (FND)

264 Barbara Reimschűssel-Wąs W bazie danych znajduje się repozytorium MDS, opisujące wygląd i sposób zachowania modułów opartych o Oracle Applications Framework (czyli modułów HTML, dawniej zwanych Self Service). Oracle XML Publisher (XDO) Oracle XML Publisher to nowe narzędzie Oracle, służące do tworzenia raportów w oparciu o dane XML. Format raportu jest w nim definiowany w postaci XSL:FO, standardu XML, służącego do opisu formatu dokumentu. Więcej szczegółów na temat Oracle XML Publisher w [OXPUG05]. Wszystkie metody dostosowywania i rozszerzania systemu omawiane w artykule są oczywiście tworzone w powiązaniu z odpowiednimi zmianami w bazie danych. Będą nas jednak interesowały głównie takie sposoby zmian, które mogą być wprowadzane poprzez warstwę aplikacji, a nie poprzez manipulacje na bazie danych. 3. Różne typy dostosowywania i rozszerzania systemu W swoich dokumentach (na przykład w [OAFPG05]) Oracle wyróżnia 4 kategorie zmian dostosowujących system: 3.1. Personalizacja Personalizacja polega na wykorzystaniu takich wbudowanych mechanizmów, które pozwalają zmienić wygląd systemu oraz interfejs użytkownika, tak aby spełniał on standardy i wymagania firmy. W Oracle EBS można to uzyskać wykorzystując: Profile, Foldery, W wersji 11.5.10 mechanizm personalizacji formularzy, Możliwości personalizacji w modułach opartych o Oracle Applications Framework (szczegóły w [OAFPG05]). W artykule zostaną przedstawione bliżej Profile i Foldery. 3.2. Zmiany konfiguracji Tego typu dostosowywanie polega tak naprawdę na wykorzystywaniu mechanizmów stanowiących część parametryzacji. Są to jednak mechanizmy na tyle zaawansowane, że pozwalają w sposób deklaratywny wprowadzić do systemu funkcjonalność dodatkową, specyficzną dla danego wdrożenia. W Oracle EBS tego typu dostosowanie można uzyskać wykorzystując między innymi: Tworzenie nowych autoryzacji, opcji menu i całych menu, Profile (Profiles), w szczególności tworzenie nowych profili, Wzorce opisowe (Descriptive Flexfields) i kluczowe (Key Flexfields). Jedną z najbardziej charakterystycznych cech Oracle EBS jest właśnie wykorzystanie wzorców, dlatego właśnie im zostanie poświęcone sporo miejsca i czasu. 3.3. Rozszerzenia funkcjonalności W przypadku, gdy konieczne są dalej idące zmiany logiki biznesowej systemu, wymagające użycia narzędzi programistycznych, mówimy o rozszerzeniach systemu (extensibility). W syste-

Oracle EBS mechanizmy dostosowywania i rozszerzania systemu 265 mie Oracle EBS, w zależności od potrzeb i obszaru, który należy rozszerzyć, wykorzystuje się następujące narzędzia: Oracle Developer 6i (Forms Builder i Reports Builder) Oracle Workflow Builder, Oracle JDeveloper Ważną, wspomnianą już wyżej, cechą systemu jest to, że udostępnia on dużą część kodu aplikacji. Nowe rozszerzenia mogą więc wykorzystywać istniejące formularze, raporty oraz procesy Workflow. Dodatkowym, charakterystycznym narzędziem jest biblioteka CUSTOM.pll, która jest dostarczana razem z systemem. Pozwala ona zmieniać funkcjonalność i wygląd formularzy w systemie, poza tymi formularzami, bez zmian ich kodu. Jest to na tyle istotne, że Oracle gwarantuje zachowywanie zmian dokonanych poprzez CUSTOM.pll przy podnoszeniu wersji systemu. Biblioteka CUSTOM.pll również zostanie omówiona nieco dokładniej w dalszej części artykułu. 3.4. Integracja Do tej kategorii można przypisać wszystkie rozszerzenia, których celem jest zintegrowanie systemu z innymi, zewnętrznymi systemami lub narzędziami, takimi na przykład jak: Katalogi LDAP (w tym także katalog Oracle OID), Platformy EAI, Inne systemy w firmie. Oracle EBS posiada wiele, rozbudowanych mechanizmów otwartych interfejsów, jednak nie są one przedmiotem tego artykułu. Oczywiście granice między poszczególnymi kategoriami mogą być nieostre. Na przykład personalizacja formularzy mimo, że deklaratywna, umożliwia także wprowadzenie kodu, który ma się wykonać w reakcji na zdarzenie i pozwala czasem w dużym stopniu zmienić nie tylko wygląd, ale także i funkcjonalność ekranu opartego o formularz. 4. Foldery jeden z mechanizmów personalizacji wyglądu ekranów Folder polega na takim oprogramowaniu bloku w formularzu zbudowanym w Oracle Forms, że umożliwia to zmianę przez użytkownika sposobu prezentacji oraz zakresu wyświetlanych danych. Foldery są dość starym i prostym w użytkowaniu mechanizmem, dlatego zostaną omówione jako pierwsze. Zostały wprowadzone już w wersji klient serwer systemu, czyli wersji 10. W następnych wydaniach ich funkcjonalność była stopniowo rozszerzana, umożliwiono zarządzanie folderami przez administratora, a w wydaniu 11.5.10, choć przestały być jedynym sposobem zmiany wyglądu formularzy, nadal pełni istotną rolę, czego dowodem są pewne wewnętrzne usprawnienia ich działania, w tym poprawiona wydajność. W całym systemie jest na stałe określona dla danej wersji liczba (dla 11.5.10-222) typów folderów (Folder Set), niekiedy nazywanych zbiorami folderów. Z jednym konkretnym blokiem formularza jest związany jeden typ folderu. Nie można, bez zmiany kodu systemu, zmienić zwykłego ekranu w folder, ponieważ wymaga to specjalnego oprogramowania danego formularza z użyciem dedykowanej folderom biblioteki.

266 Barbara Reimschűssel-Wąs To, że dany ekran jest folderem można rozpoznać po aktywnej ikonie narzędzi folderów na pasku narzędzi, aktywnym menu Foldery oraz po ikonie symbolizującej folder w lewej górnej części ekranu. Rys. 5. Aktywna ikona narzędzi folderów na pasku narzędzi Rys. 6. Przybornik narzędzi folderów, otwarty po naciśnięciu ikony folderów. Rys. 7. Blok folderu Faktury w Zobowiązaniach.

Oracle EBS mechanizmy dostosowywania i rozszerzania systemu 267 Folder umożliwia: Wyświetlanie tylko pewnych danych, poprzez wprowadzenie ograniczającego warunku WHERE do zapytania danego bloku. Warunek ten tworzony jest automatycznie poprzez zapamiętanie warunku z ostatniego przed zapisaniem folderu wyszukiwania rekordów w bloku. Wyświetlenie danych posortowanych w określony sposób. Można określić sposób sortowania na 3 pierwszych kolumnach folderu. Uwidocznianie lub ukrywanie niektórych pól na ekranie (nie wszystkich, dla niektórych, pól przy próbie ich ukrycia otrzymujemy komunikat, że pola nie można usunąć). Można uwidocznić takie pola, które zostały utworzone na formularzu, ale domyślnie były niewidoczne. Ich lista dostępna jest po wybraniu przycisku Zmiany szerokości pól. Zmiany kolejności pól. Zmiany nagłówków pól. Aby utworzyć nowy folder należy nacisnąć przycisk z zielonym plusem z przybornika na Błąd! Nie można odnaleźć źródła odsyłacza. lub wybrać odpowiednią opcję z menu Folder, co spowoduje wyświetlenie ekranu do tworzenia folderu. Rys. 8. Tworzenie nowego folderu. Opcje przy tworzeniu folderu mają następujące znaczenie: Folder nazwa folderu, AutoQuery zaznaczenie Always oznacza, że przy otwieraniu folderu zawsze dane będą od razu wyświetlane zgodnie z zapamiętanym warunkiem (domyślnie formularze na ogół nie wyświetlają danych od razu po otwarciu). Opcja Ask each time oznacza, że za każdym razem gdy folder będzie otwierany, będzie zadawane pytanie czy stosować warunek. Open as Default oznacza, że folder staje się domyślnie otwieranym dla tworzącego go użytkownika, o ile nie jest zaznaczone Public oraz dla wszystkich użytkowników, o ile Public jest zaznaczone. Include Query jeśli jest zaznaczone, definicja folderu będzie przechowywała warunek, który został wprowadzony w bloku w momencie tworzenia folderu. Jeśli jednocześnie zostanie zaznaczone AutoQuery, warunek taki zostanie automatycznie zastosowany przy otwieraniu folderu, czyli dla folderów domyślnych ( Open as Default ),

268 Barbara Reimschűssel-Wąs przy otwieraniu danego bloku formularza. Warunek można usunąć poprzez opcję z menu Folder Reset Query. Po nadaniu nazwy i utworzeniu, folder można zapamiętać naciskając ikonę z dyskietką. Zostaną zapisane wszystkie ustawienia pól i danych w bloku z momentu zapisywania folderu. Ponieważ każdy z folderów został osobno oprogramowany na formularzu Oracle Forms, choć przy użyciu tej samej biblioteki, ich zachowanie może się różnić między sobą. Na przykład dla niektórych folderów nie jest możliwe przechowywanie warunków. 1.1. Administrowanie folderami. Przydzielanie folderów. Foldery można przydzielać nie tylko jako domyślne dla wszystkich lub dla konkretnego użytkownika, który folder stworzył. Można je również przypisywać do autoryzacji (autoryzacja - Responsibility, to pojedynczy zestaw funkcji systemu, który może być przypisany użytkownikowi). W autoryzacji System Administrator, podmenu Application znajduje się pozycja menu dotycząca administrowania folderami Administer Folders. Po jej wybraniu, otwiera się okno wyszukania utworzonego wcześniej folderu: Rys. 9. Okno wyszukiwania folderów Każda z powyższych opcji okna wyszukiwania umożliwia wykonanie innych zadań. Jeśli skorzystamy z wyszukiwania z zaznaczeniem opcji Folders, jak na rysunku, możemy zmienić niektóre właściwości znalezionego folderu (właściciela, to czy jest publiczny, czy związane jest z nim autozapytanie).

Oracle EBS mechanizmy dostosowywania i rozszerzania systemu 269 Rys. 10. Szczegóły folderu. Po naciśnięciu przycisku Default Assignments można zobaczyć, w trybie tylko do odczytu, do kogo i do jakiej autoryzacji folder jest przypisany (tzn. kto będzie przy otwieraniu danego formularza od razu domyślnie otwierał go z zastosowaniem danego folderu). Rys. 11. Domyślne przypisania folderu tylko do odczytu.

270 Barbara Reimschűssel-Wąs Jeśli natomiast wybierzemy na ekranie z rysunku Rys. 9 przeglądanie według przypisań do autoryzacji lub użytkownika, możemy przypisać folder do nowej autoryzacji/użytkownika lub usunąć istniejące przypisanie: Rys. 12. Przypisanie folderu do autoryzacji. Przypisywanie folderu do autoryzacji może być wykorzystywane w ten sposób, że tworzy się pewne nowe autoryzacje, dla których ekran, na którym są możliwe foldery, obsługiwany jest wyłącznie poprzez konkretny folder. Na przykład jeśli chcemy, by ktoś obsługiwał wyłącznie walutowe faktury zakupu, możemy utworzyć odpowiedni folder i przypisać go do specjalnie utworzonej w tym celu autoryzacji. Po wybraniu tej autoryzacji, użytkownikowi zawsze automatycznie zostaną wyświetlone właśnie takie faktury. 5. Zestawy wartości narzędzie, bez którego nie można się obejść Zestawy wartości (Value Sets) nie są same w sobie osobnym sposobem dostosowania systemu, nie sposób jednak prawidłowo wykorzystywać innych mechanizmów takich jak tworzenie nowych zleceń czy też definiowanie wzorców, bez ich stosowania. Dlatego też konieczne jest poświęcenie im trochę miejsca i uwagi. Zestaw wartości to po prostu formalnie zarejestrowany w systemie opis sposobu sprawdzania poprawności wprowadzanych przez użytkownika danych. Określa on, że każda wartość z danego zestawu będzie miała pewien, określony format oraz sposób kontroli przynależności do tego zestawu. Po zdefiniowaniu zestawu wartości, można więc, posługując się nim, sprawdzać format i zakres danych wprowadzanych przez użytkownika. Zestaw wartości można utworzyć jako definicję pewnej skończonej listy, czyli będzie on wtedy pełnił rolę słownika, z którym wprowadzane pole musi być zgodne. Może to też być po prostu zadeklarowany format danych wpisywanych z ręki. Co więcej zestawy wartości można ze sobą

Oracle EBS mechanizmy dostosowywania i rozszerzania systemu 271 wiązać jako nadrzędne i zależne. Wtedy sposób walidacji wartości z jednego zestawu będzie zależał od tego jaka wartość została wybrana wcześniej z zestawu nadrzędnego. Tam, gdzie system wie, bo jest to zapisane w kodzie, jak trzeba walidować wprowadzane dane, nie ma potrzeby wprowadzania takich mechanizmów jak zestawy wartości. Inaczej jest w miejscach, gdzie chcemy rozszerzyć funkcjonalność systemu bez zmiany kodu, na przykład przez dodanie do formularza nowego pola. Na ogół chcemy, aby do pola tego wprowadzać określone dane, na przykład tylko liczby. Musi więc w systemie istnieć jakiś sposób na powiązanie z takim nowym polem pewnej recepty na to, jak kontrolować jego edycję. Tę rolę pełnią właśnie w Oracle EBS zestawy wartości i system narzuca obowiązek ich stosowania dla wzorców, zarówno kluczowych jak i opisowych (będzie o nich mowa później) oraz przy deklarowaniu parametrów zleceń współbieżnych. Rys. 13. Wykorzystanie zestawu wartości przy wprowadzaniu wartości parametru zlecenia

272 Barbara Reimschűssel-Wąs Dla powyższej listy odpowiadający jej zestaw wartości to: Rys. 14. Definicja zestawu wartości umożliwiającego walidację parametru Sortowanie wg, z Rys. 13 W standardowej instalacji systemu tworzenie zestawów wartości dostępne jest z autoryzacji System Administrator oraz Application Developer w menu Application:Validation. 5.1. Rodzaje zestawów wartości Zestawy wartości różnią się typem formatu, rodzajem zabezpieczenia i typem zatwierdzania. Typ formatu określa czy wartości mają być numeryczne, znakowe, typu data lub typu data i godzina 2. Wybranie określonego typu wymusi odpowiednią weryfikację w momencie wprowadzania danych. Na przykład użycie w definicji parametru zlecenia zestawu wartości o formacie Standardowa data zapewni nam sprawdzenie przez system, że wprowadzona wartość jest zgodna z przyjętym formatem daty. Podobnie jest dla wartości znakowych i liczbowych. W Oracle EBS istnieje wiele predefiniowanych zestawów wartości instalowanych razem z całą aplikacją, na przykład dla liczb są to m. in.: FND_NUMBER, FND_NUMBER15, FND_NUMBER15_REQUIRED, I wiele, wiele innych, ponieważ instalują się wszystkie zestawy wartości używane w definicji zleceń instalowanych razem z aplikacją (a jest takich zleceń 7764 dla demonstracyjnej instancji Vision). 2 Faktycznie są po dwa typy formatów dla dat i dat z czasem: Standardowa data oraz Standardowa data i godzina oraz zachowane wyłącznie dla kompatybilności wstecznej Data i Data i godzina

Oracle EBS mechanizmy dostosowywania i rozszerzania systemu 273 Rys. 15. Użycie zestawów wartości bez weryfikacji. Na Rys. 15 pokazana jest weryfikacja formatu przy wprowadzaniu parametrów zlecenia. Użyte w tym celu zestawy to: 30 Characters, 2 Digits, 3 Digits Typ zatwierdzania dodatkowo determinuje mechanizm wykorzystywany przy walidacji wartości. Można na przykład chcieć by jakieś pole było wypełniane nie tylko danymi zgodnymi z formatem daty, ale by były to wyłącznie daty z podanego wprost zbioru lub z wskazanej tabeli bazy danych. Wartości mogą być więc zatwierdzane za pomocą: Tabeli, Przy pomocy zestawu nadrzędnego (Dependent Independent Validation) lub zestawu nadrzędnego z dostępnymi wersjami językowymi (Translatable Dependent Independent), W sposób specjalny (Special validation lub Pair validation) specjalne mechanizmy walidacji dla wzorców kluczowych, których efektem jest wyświetlenie wielosegmentowego kodu w postaci osobnych pól na każdy segment, Nie zatwierdzane wcale. Poniżej nieco więcej o zatwierdzaniu za pomocą zestawu nadrzędnego oraz przy pomocy tabeli. Zatwierdzanie specjalne, choć dość ważne w systemie, jest bowiem wykorzystywane przy wyświetlaniu danych z wzorców kluczowych, to wymaga używania specyficznej, dość mocno rozbudowanej składni, której przedstawienie wykracza poza ramy tego artykułu.

274 Barbara Reimschűssel-Wąs 5.2. Zatwierdzanie typu nadrzędny podrzędny Taki typ zatwierdzania odpowiada sytuacji, gdy na jednym polu ekranu wybieramy wartość z pewnego, z góry zadanego zbioru i wartość ta ma zawężać zbiór możliwych do wprowadzenia wartości na innym polu. Przykład takiej zależności został przedstawiony w Tabela 2. W takim przypadku system Oracle EBS umożliwia zarówno definiowanie obu potrzebnych zestawów wartości, jak i obsługę samych danych czyli wartości zestawów. Oznacza to, że tego typu walidacji należy używać wtedy, gdy chcemy wprowadzić wartości za pomocą listy elementów wykorzystywanych wyłącznie w tym celu i nie występujących już wcześniej w systemie. Tabela 2. Zależność między zestawem niezależnym i zależnym Wartość niezależna Opis wartości niezależnej Wartość zależna Opis wartości zależnej PASS Passanger RM Renault Megan PASS Passanger FF Ford Fokus PASS Passanger DF Default LR Lorry MAN MAN LR Lorry VL Volvo LR Lorry DF Default RC Racine RF1 Renault Formula 1 RC Racine FR1 Ferrari Formula 1 RC Racine DF Default Nadrzędny zestaw tworzymy wybierając typ zatwierdzania Independent. Rys. 16. Definiowanie zestawu zależnego

Oracle EBS mechanizmy dostosowywania i rozszerzania systemu 275 Następnie tworzymy odpowiadający mu zestaw zależny wybierając dla niego typ zatwierdzania Dependent. Należy wtedy dodatkowo, po naciśnięciu przycisku Edit Information, podać, jaka z wartości zestawu ma być jego wartością domyślną. Jest to konieczne, ponieważ system zakłada, że każdej wartości z zestawu nadrzędnego musi być przypisana choć jedna wartość z zestawu podrzędnego. Jeśli nie zrobi się tego wprost, system przypisze sam wartość podaną jako domyślna. Po utworzeniu obu zestawów można zacząć wprowadzać ich wartości. Służy do tego funkcja dostępna w autoryzacji System Administrator, w menu Application:Validation:Values. Należy zacząć od wprowadzenia wartości zestawu nadrzędnego (w podanym przykładzie PO_PDOI_DOCUMENT_SUBTYPES), a następnie wprowadzić wartości podrzędne. Dla każdej wartości nadrzędnej system dodatkowo utworzy i przypisze jej rekord z wartością wskazaną w definicji jako domyślna. Rys. 17. Wprowadzanie wartości dla zestawu zależnego Jak będzie można zobaczyć dalej, podobną zależność nadrzędny podrzędny między zestawami wartości można uzyskać także dla zestawów weryfikowanych z użyciem tabeli. Trzeba do tego użyć specyficznej składni dostępnej w systemie. Zatwierdzanie przy pomocy zestawu nadrzędnego, z dostępnymi wersjami językowymi (Tranlatable Dependent, Translatable Independent) w zasadzie nie różni się od przedstawionego powyżej, poza tym, że system przechowuje ich wartości w różnych wersjach językowych. Jest to przydatne, ale niestety tego typu zestawy posiadają kilka ograniczeń. Nie można stosować dla nich nie omawianych tu mechanizmów zabezpieczeń dostępu do wartości (zagadnienia zabezpieczeń zestawów wartości są przedstawione w [OraAFG05]), nie można ich też używać przy definiowaniu wzorca konta księgowego. 5.3. Zestawy kontrolowane przy pomocy tabeli Zestawy takie umożliwiają zdefiniowanie w systemie powszechnie stosowanej listy wartości, której elementy pochodzą z dowolnej tabeli bazy danych dostępnej w systemie, a nawet dodanej

276 Barbara Reimschűssel-Wąs do systemu w ramach jego rozszerzania. Ogólnie rzecz biorąc, tego typu walidacji należy używać wtedy, gdy chcemy aby wprowadzane wartości pochodziły z danych obecnych już i wykorzystywanych gdzie indziej w systemie, choć ta reguła nie zawsze jest stosowana, nawet dla preinstalowanych standardowo zestawów. 3 Aby utworzyć zestaw wartości weryfikowany tabelą, należy na ekranie tworzenia zestawu (autoryzacja System Administrator, menu Application:Validation:Set) wybrać z listy sposób walidacji Table. Uaktywni się wówczas przycisk Edit Information i po jego naciśnięciu będzie można wprowadzić dalsze, wymagane informacje o tabeli i jej polach. Rys. 18. Szczegóły definicji zestawu walidowanego tabelą Ekran Validation Table Information zawiera pola, w które należy wpisać tabelę i aplikację tabeli. Każda tabela zarejestrowana w Oracle EBS, jest powiązana z modułem (aplikacją). Jeżeli poda się aplikację, z której pochodzi tabela i rzeczywiście dana tabela jest zarejestrowana (nowe tabele, dodawane do systemu przy jego rozszerzaniu, też powinny być rejestrowane), można jej nazwę wybrać z listy. Jeśli nie jest zarejestrowana, można nazwę wpisać z ręki, mimo, że nie ma jej na liście. Jako tabelę można też podać dowolny widok, lub listę tabel, dla których warunek złączenia będzie później określony w polu Where/Order by. Można też używać aliasów. Po podaniu tabeli, o ile została wybrana ona z listy, przy wypełnianiu pól Value, Meaning i ID będzie dostępna lista jej pól. W pozostałych przypadkach pola należy wprowadzać z ręki. 3 Istnieje tabela FND_LOOKUP_VALUES, w module Application Objects Library, której przeznaczeniem jest przechowywanie danych słownikowych, przy czym nie jest to ta sama tabela, w której przechowywane są wartości zestawów niezależnych i zależnych. Można więc wprowadzić żądane wartości do FND_LOOKUP_VALUES i utworzyć zestaw walidowany tabelą, a nie niezależny, nawet wtedy, gdy te wartości służą wyłącznie do walidacji zestawu.

Oracle EBS mechanizmy dostosowywania i rozszerzania systemu 277 Pola Value, Meaning i ID odpowiadają kolumnom listy wartości, z której będą wprowadzane wartości. Jeśli pole ID jest puste, to do edytowanego, z użyciem tworzonego właśnie zestawu wartości, pola zostaną wstawione dane z kolumny podanej jako Value i będą one widoczne na wyświetlanej liście. Jeśli chce się, aby wartości wprowadzane nie były widoczne, bo są to, dajmy na to, wewnętrzne identyfikatory, należy wypełnić pole ID. Wtedy wyświetlane będą dane z Value, a faktycznie wprowadzane z ID. Dodatkowo wyświetlana będzie też kolumna podana w Meaning, o ile to pole zostanie wypełnione. Pole Where/Order by służy do określania dodatkowych ograniczeń na dane lub porządku wyświetlania. Możliwe jest tu użycie wszelkiej składni zgodnej z klauzulami WHERE i ORDER BY z SQL. Klauzule należy podawać razem z odpowiednimi słowami kluczowymi (WHERE, ORDER BY). Istnieje też kilka dodatkowych, bardzo przydatnych i często wykorzystywanych konstrukcji, które mogą być tu użyte. Są to zmienne związane specjalnego znaczenia: :$FLEX$.NazwaZestawuWartości, :blok.pole :$PROFILES$.NazwaProfilu Przy pomocy zmiennej :$FLEX$.NazwaZestawuWartości można uzyskać zależność jednego zestawu wartości od innego, podobnie jak dla zestawów niezależnych i zależnych. Jeśli na przykład wprowadzamy parametry zlecenia i znana jest już wartość wcześniej wypełnianego parametru, to można uzależnić w ten sposób warunek WHERE od tego parametru używając zmiennej związanej z nazwą zestawu wartości dla tego parametru (jak już było wspomniane, każdy parametr musi mieć podany odpowiadający mu zestaw wartości). Aby pokazać na przykładzie działanie takiej zależności spróbujemy uruchomić zlecenie, którego parametry zostały w ten sposób zdefiniowane. Przykładem może być zależność parametrów programu zlecenia Completed Concurrent Requests Reports Uruchamiamy zlecenie albo z górnego menu View, opcja Requests (dla każdej autoryzacji jest taka opcja, ale to zlecenie może być uruchomione z autoryzacji System Administrator), albo z menu nawigatora. Pierwszym parametrem tego zlecenia jest nazwa modułu systemu Program Application Name, a jego zestaw wartości to Application_Name_to_Shortname. Zestaw wartości dla drugiego parametru to CONC-Program Name, walidowany z tabeli, a tak naprawdę widoku FND_CONCURRENT_PROGRAMS_VL. Klauzula WHERE dla tego zestawu ma postać: WHERE :$FLEX$.Application_Name_to_Shortname = ( Select Application_Short_Name from fnd_application A where A.Application_ID = FND_CONCURRENT_PROGRAMS_VL.Application_ID ) gdzie :$FLEX$.Application_Name_to_Shortname odwołuje się do wartości pierwszego parametru. W efekcie przy uruchamianiu zlecenia, po wprowadzeniu pierwszego parametru, lista dopuszczalnych wartości drugiego zostanie zawężona do zleceń należących do wybranego modułu.

278 Barbara Reimschűssel-Wąs Rys. 19. Efekt wykorzystania zmiennej związanej :$FLEX$ Następną zmienną związaną jest zmienna :$PROFILES$. Oznacza ona odwołanie się do wartości profilu podanego dalej po kropce. Profile zostaną omówione w dalszej części artykułu. Możliwe jest także odwołanie się w warunku WHERE do wartości pola na formularzu, na którym zestaw będzie wykorzystany poprzez użycie zmiennej :blok.pole. Jest to bardzo przydatna możliwość, ale należy z niej korzystać bardzo ostrożnie ponieważ: W dokumentacji podawane jest zastrzeżenie, że jest to opcja zachowywana wyłącznie dla zgodności ze starszymi wersjami systemu i może przestać być wspierana. Trzeba się zabezpieczyć przed możliwością wykorzystania tego samego zestawu na kilku różnych formularzach, co doprowadziłoby do błędów. 6. Profile. Dodatkowe parametry w systemie, które można samemu tworzyć Profile to mechanizm, który pozwala na łatwe definiowanie dodatkowych, zmiennych opcji systemu, nadawanie im wartości oraz późniejsze ich wykorzystywanie. Predefiniowanych profili jest w systemie ponad 5000. Stanowią one część konfiguracji i każdy ma dla systemu pewne, ściśle określone znaczenie. Poprzez jednak fakt, że można definiować i potem wykorzystywać w systemie nowe profile, mechanizm ten może być, jest i powinien być wykorzystywany we wszystkich typach dostosowywania systemu, łącznie z rozszerzeniami czysto programistycznymi. Każdy profil posiada dwie nazwy przez które jest identyfikowany nazwę wewnętrzną, czyli identyfikator oraz nazwę dla użytkownika. Niestety w różnych kontekstach wymagana jest raz jedna, raz druga z tych nazw.

Oracle EBS mechanizmy dostosowywania i rozszerzania systemu 279 Profil może posiadać wartość na kilku poziomach, ułożonych w 3 hierarchie. Domyślną hierarchią (do niedawna jedyną, zresztą nadal jedyną z więcej niż 1 poziomem), obowiązującą dla prawie wszystkich profili jest hierarchia bezpieczeństwa (Security) i dla niej zdefiniowane zostały następujące poziomy wartości profili: Lokalizacji (Site), Modułu (Application), Autoryzacji (Responsibility), Użytkownika (User). Pozostałe dwie hierarchie, obie jednopoziomowe, wprowadzone dopiero od wersji 11.5.9 i na razie wykorzystywane w niewielkim stopniu 4, to: Hierarchia serwera (Server), Hierarchia organizacji (Oranization). Nie wszystkim profilom można nadawać wartości na wszystkich poziomach. Jeśli jednak możliwe jest przypisanie wartości do profilu na więcej niż jednym poziomie (możliwe jest to oczywiście tylko w hierarchii bezpieczeństwa), to system przyjmuje, że najwyższy priorytet ma wartość na poziomie najniższym czyli danego użytkownika, potem autoryzacji, modułu i na końcu lokalizacji. I odwrotnie, jeśli profil nie ma nadanej wartości na poziomie użytkownika, to system odczytując wartość takiego profilu pobierze ją z najniższego poziomu wyższego, na którym wartość została nadana. Nie wszystkie profile są widoczne dla użytkownika, a i te widoczne nie wszystkie są możliwe do modyfikacji. Wszystko to zależy od sposobu zdefiniowania danego profilu. 6.1. Nadawanie wartości profilom W systemie istnieją dwa interfejsy zmiany wartości profili jeden dla użytkowników systemu, drugi dla administratorów. Na ekranie dla użytkowników widoczne są oczywiście tylko te profile, które może widzieć użytkownik na poziomie użytkownika. Administrator systemu może widzieć wszystkie profile, na wszystkich poziomach, ale nie każdy z nich może modyfikować (niektóre profile otrzymują wartość wyłącznie przy instalacji systemu). Okno zmiany profili użytkownika dostępne jest z każdej autoryzacji systemu, z menu nawigatora (funkcja Profile:Personal)oraz dodatkowo z menu górnego, z grupy opcji Tools. Okno administratora jest dostępne z autoryzacji System administrator menu Profile:System. 4 Dla wersji 11.5.9 istniał tylko 1 profil na poziomie Serwera i nie było żadnego na poziomie organizacji.

280 Barbara Reimschűssel-Wąs Rys. 20. Nadawanie wartości profilom przez administratora Na pokazanym przykładzie widoczny jest profil Folders: Allow Customization, który może przybierać jedną z 2 wartości Yes lub No i w zależności od tej wartości, albo pozwala na tworzenie nowych i zmiany istniejących folderów przez użytkownika (Yes), albo nie pozwala (No). Warto przy tym zauważyć, że wartości wprowadzane są za pomocą listy. Jak zdefiniować profil, aby umożliwiał takie wprowadzanie, zostanie pokazane później. Inne przykłady profili to: GL Set of Books Name profil określający jaki zestaw ksiąg ma być użyty dla danego użytkownika. Hide Diagnostics menu entry profil decydujący o tym, czy ma być dostępne menu Diagnostics w grupie menu Help. Ponieważ opcje tego menu dają dostęp do wielu informacji o systemie i umożliwiają nawet niekontrolowane zmiany, zalecane jest, aby było ono niedostępne dla zwykłych użytkowników. Printer określa domyślną drukarkę. Można przy jego pomocy określić różne drukarki dla różnych autoryzacji i użytkowników. FND: Override directory profil, który można wykorzystać w procesie wgrywania modyfikowanych formularzy na środowisko produkcyjne. Jeśli jako wartość tego profilu poda się katalog na serwerze aplikacji, system będzie najpierw szukał każdego otwieranego formularza w tym katalogu, a dopiero potem we właściwym mu katalogu w strukturze katalogowej aplikacji (opis te struktury można znaleźć w [OraAC05]). Umożliwia to wybranym użytkownikom pracę z nowymi wersjami formularzy, podczas gdy cała reszta użytkowników pracuje na wersjach poprzednich. Jak wynika z powyższego, profil ten powinien być nadawany tylko na poziomie użytkownika, choć jest on widoczny i modyfikowalny na każdym poziomie z hierarchii Security. Opis wszystkich profili modułu Biblioteka Obiektów Aplikacji (FND) można znaleźć w [OraSGM05].

Oracle EBS mechanizmy dostosowywania i rozszerzania systemu 281 6.2. Definiowanie profili Rys. 21. Nadawanie wartości profilom użytkownika Wielką zaletą tego mechanizmu jest to, że można do systemu dodawać zupełnie nowe profile. Oznacza to, że można w systemie dość łatwo utworzyć miejsce, gdzie użytkownik lub administrator będzie mógł wprowadzić jakiś kod lub inną wartość, wykorzystany później w dowolnym miejscu systemu, również programistycznie (istnieje specjalne API obsługujące profile). Pozwala to tak rozszerzać system, by w przyszłości zminimalizować konieczność jakichkolwiek zmian kodu. Nowe profile definiuje się w autoryzacji Application Developer.

282 Barbara Reimschűssel-Wąs Rys. 22. Formularz definiowania folderów Na ekranie Rys. 22 przedstawiony jest ekran, na którym definiuje się profile. Pole Name przeznaczone jest na identyfikator profilu, który jest wykorzystywany w kodzie oraz przez wszystkie funkcje Application Object Library, czyli także przy tworzeniu zestawów wartości (przy użyciu omawianej wcześniej zmiennej :$PROFILES$). Pole User Profile Name zawiera nazwę dostępną dla użytkownika i administratora, którą należy się posługiwać przy wyszukiwaniu profili i ich modyfikacji. Pole Hierarchy Type określa, jakiej hierarchii ma używać profil. Tak jak było wspomniane wcześniej, prawie wszystkie predefiniowane profile używają hierarchii Security. Niżej definiuje się, na jakich poziomach profil ma być widoczny i modyfikowalnych dla użytkowników oraz osobno dla kodu, poprzez API. W pokazanym przypadku wartość profilu będzie widoczna i możliwa do zmiany wyłącznie na poziomie użytkownika. Jeśli profil ma umożliwiać wybór dostępnych wartości z listy, należy wypełnić także pole SQL Validation. Obowiązkowo w polu tym muszą się pojawić: SQL= instrukcja SQL COLUMN= kolumna1(rozmiar), kolumna2(rozmiar),. Po słowie kluczowym SQL podaje się w cudzysłowie instrukcję SELECT z klauzulą INTO do zmiennych związanych :VISIBLE_OPTION_VALUE (wartość wyświetlana) i PROFI- LE_OPTION_VALUE (wartość wstawiana do profilu). Może tu występować WHERE, ORDER BY, a także HAVING, GROUP BY i podzapytania, ale już nie UNION i CONNECT BY. Tak jak w normalnym SELECT można używać aliasów i będą one wtedy wyświetlane jako nazwy

Oracle EBS mechanizmy dostosowywania i rozszerzania systemu 283 kolumn listy wyboru. Dla aliasów ze spacjami, otaczające je cudzysłowy muszą być poprzedzone znakiem backslash ( \ ). Linia rozpoczynająca się od COLUMN definiuje nazwy i szerokości kolumn widocznych (nazwy te stają ważniejsze niż wspomniane wcześniej aliasy). Podanie szerokości jest obowiązkowe, ale wpisanie * oznacza szerokość dynamiczną, zależną od faktycznej szerokości tekstu. Dodatkowo w następnych liniach pod COLUMN można też opcjonalnie podać TITLE, który będzie wyświetlany jako tytuł okienka z listą wyboru oraz HEADING umożliwiający określenie nagłówków kolumn wymienionych w COLUMN. Więcej informacji o składni wymaganej przy definiowaniu profili znajduje się w [OraADG01] (niestety podręcznik ten nie został zaktualizowany dla wersji 11.5.10). W przykładzie powyżej, pole SQL Validation wypełnione jest następująco: SQL="SELECT MEANING \"Folders: Allow Customization\", LOOKUP_CODE INTO :VISIBLE_OPTION_VALUE, :PROFILE_OPTION_VALUE FROM FND_LOOKUPS WHERE LOOKUP_TYPE='YES_NO'" COLUMN="\"Folders: Allow Customization\"(*)" Oznacza to, że zostanie wyświetlona lista wartości z kolumny MEANINIG tabeli FND_LOOKUPS, a kolumna ta będzie miała nagłówek Folders: Allow Customization i szerokość zależną od faktycznej szerokości wyświetlanych wartości. Na Rys. 20 widać efekt działania właśnie tej definicji. 7. Wzorce. Własne pola do zdefiniowania Wzorce (Flexfields) są podstawowym narzędziem dostosowywania systemu Oracle EBS. Wykorzystują one różne inne, omówione wcześniej mechanizmy, takie jak zestawy wartości i profile, przy czym użycie zestawów wartości jest konieczne przy ich definiowaniu. Najprościej rzecz biorąc, wzorce to takie obszary danych dodatkowych lub niezbędnych dla systemu, dla których możemy sami zdefiniować ich strukturę, zawartość oraz sposób wprowadzania i prezentacji. Wzorce dzieli się na kluczowe (Key Flexfields) i opisowe (Description Flexfield). Wzorzec kluczowy to wielosegmentowy klucz, dla którego można samemu definiować segmenty, włączając w to ich liczbę i zawartość. Słowo kluczowy, choć określa, że dane w takim wzorcu tworzą klucz, na przykład: WA/457A/2005/3, dobrze pasuje też do innej jego cechy wszystkie wzorce kluczowe pełnią kluczową rolę w poszczególnych modułach systemu, ich zdefiniowanie jest obligatoryjne i stanowi istotną część każdego wdrożenia. Wzorce opisowe są z założenia przeznaczone do rozszerzania zakresu obsługi w systemie o informacje wcześniej w nim nie przewidziane. Pozwalają one na zdefiniowanie na ekranach dodatkowych pól, dla których możemy określić wygląd, źródło danych, format wprowadzania danych i sposób ich walidacji. Wzorców opisowych jest w systemie o wiele więcej niż kluczowych, ale jest to także znana, skończona lista i każdy wzorzec jest w systemie identyfikowalny 5. Aby bowiem można było z wzorca korzystać na ekranie, dany formularz musi być odpowiednio oprogramowany, a tabela, z której korzysta musi mieć odpowiednią strukturę. 5 Możliwe jest tworzenie nowych wzorców w nowo pisanych modułach.

284 Barbara Reimschűssel-Wąs 7.1. Wzorce kluczowe W całym systemie są 23 wzorce kluczowe. Najważniejszy z nich to wzorzec konta księgowego (Accounting Flexfield, kod wzorca GL#) w module Księgi Głównej (General Ledger), na przykładzie którego zostanie pokazane tworzenie i obsługa wzorców kluczowych. Pominięte przy tym zostaną różne ograniczenia i specyficzne własności tego wzorca. Ze względu na rolę jaką odgrywa on w całym systemie oraz specyficzne potrzeby, związana jest z nim bowiem pewna liczba wyjątków i specjalnych reguł. Przykładem może być mechanizm hierarchii dla zestawów niezależnych, używany wyłącznie przy definiowaniu konta. Inne istotne wzorce kluczowe to między innymi: Wzorzec kategorii środka trwałego w module Środki Trwałe (Assets). Wzorzec kodu pozycji magazynowej w module Inventory (Magazyn). Wzorzec roli zawodowej (Job) w module Kadry (Human Resources). Każdy wzorzec kluczowy można scharakteryzować za pomocą szeregu cech z nim związanych, wynikających ze sposobu w jaki został oprogramowany, a które określają jego zachowanie lub go identyfikują. Są to: Kod wzorca wewnętrzny kod systemu, który identyfikuje wzorzec w bazie danych. Dla wzorca konta księgowego jest to GL# (nie ma sensu pytać dlaczego). Tabela wzorca, czyli tabela, w której przechowywane są wartości. Każdemu wzorcowi kluczowemu odpowiada jedna taka tabela, a jej kolumny zawierają poszczególne segmenty wzorca. To, który segment z związany jest z którą kolumną należy podać w trakcie parametryzacji wzorca. Cały wiersz tabeli oznacza kombinacje wszystkich segmentów wzorca kluczowego, więc tabelę taką nazywa się często tabelą kombinacji. Dla konta księgowego jest to tabela GL_CODE_COMBINATIONS. Informacje o tym, która tabela odpowiada za każdy wzorzec kluczowy można znaleźć w [OraAFG05]. Liczba kolumn w tabeli wzorca, czyli maksymalna liczba segmentów. Dla wzorca konta księgowego jest to 30, ale dla innych wzorców kluczowych mogą to być inne liczby. Maksymalna liczba znaków w każdej kolumnie, czyli w konsekwencji maksymalna długość segmentu. Dla konta księgowego 25. Struktura, czyli układ segmentów. Niektóre wzorce kluczowe, w tym wzorzec konta zostały tak zbudowane, że dla tego samego wzorca można zdefiniować wiele struktur. Dla konta księgowego wielość struktur jest odpowiednikiem wielu planów kont (Chart of Accounts). Ponieważ Oracle EBS jest systemem, który może obsługiwać wiele zestawów ksiąg (Set of Accounts), do każdego zestawu ksiąg można przypisać inny plan kont a system rozstrzyga, którego z nich użyć odczytując wartość profilu użytkownika GL Set of Books Name. Oznacza to, że wzorzec konta musi mieć możliwość posiadania wielu struktur. Dynamiczne dodawanie kombinacji. Jest to cecha samego wzorca, ale w przypadku gdy jest możliwe dodawanie, można ją jeszcze dodatkowo określić na poziomie struktury. Określa ona czy można wstawiać rekordy do tabeli kombinacji inaczej niż przez związany z tą tabelą formularz. Jeśli nie, będzie to oznaczać, że nie można na przykład generować nowych kombinacji kont w systemie programowo, tylko trzeba wcześniej przewidzieć wszystkie możliwe kombinacje na wszystkich segmentach analitycznych, nawet tych, których możliwe wartości się zmieniają (takim segmentem może być choćby segment Projekt). Reguły wzajemnej walidacji segmentów (Cross Validation Rules). Jeśli wzorzec ma umożliwiać stosowanie takich reguł, będzie można decydować, dla jakich wartości jednego segmentu mają być możliwe pewne przedziały wartości innego/innych seg-

Oracle EBS mechanizmy dostosowywania i rozszerzania systemu 285 mentów (na przykład wartość MPK inna niż oznaczająca brak, tylko dla kosztowych wartości konta właściwego). Separator segmentów znak, który oddziela od siebie poszczególne segmenty. Może to być kropka, myślnik lub inny znak określony w trakcie wdrożenia systemu. Aby dostosować do potrzeb wzorzec kluczowy należy wykonać następujące kroki: 1. Utworzyć strukturę dla danego wzorca kluczowego i określić takie jej cechy jak kod struktury i możliwość dynamicznego wstawiania kombinacji. 2. Zdecydować czy wzorzec ma zachowywać reguły wzajemnej walidacji segmentów, poprzez zaznaczenie odpowiedniego pola. 3. Utworzyć dla każdego planowanego segmentu odpowiadający mu zestaw wartości niezależny. W przypadku wzorca konta księgowego każdy segment musi mieć zestaw wartości, dla innych wzorców kluczowych, jeśli nie ma, to system zakłada, że segment zachowuje się jakby miał zestaw wartości bez walidacji (typ walidacji None) i zawierający wartości znakowe. 4. Zdefiniować segmenty i określić ich podstawowe cechy czyli: nazwę, etykietę która będzie wyświetlana w oknie edycji (prompt), która kolumna z tabeli kombinacji będzie przechowywała wartości tego segmentu, czy segment ma być wyświetlany (dla wzorca konta księgowego muszą być wyświetlane wszystkie segmenty). 5. Przypisać do każdego segmentu utworzony wcześniej dla niego zestaw wartości. Przy przypisywaniu system będzie pokazywał na liście wyboru zestawów wartości tylko te zestawy, które są możliwe do wykorzystania. 6. Można dodatkowo określić dla każdego segmentu jego wartość domyślną. Jeśli segment ma nie być wyświetlany, musi mieć taką wartość domyślną obowiązkowo. 7. Dla wzorca konta księgowego należy jeszcze określić dodatkowo rolę segmentu czyli tzw. kwalifikator. Każdy plan kont musi mieć bowiem segmenty pełniące role konta naturalnego oraz segmentu bilansującego. Ponieważ można segmenty definiować z dowolnymi nazwami i kolumnami, system musi mieć inną możliwość rozpoznania roli segmentu i robi się to właśnie poprzez przypisanie segmentowi odpowiedniego kwalifikatora.

286 Barbara Reimschűssel-Wąs Rys. 23. Definiowanie podstawowych cech segmentów 8. Także tylko dla wzorca konta trzeba zdecydować czy dany segment ma być indeksowany (dla innych wzorców też można zaznaczać to pole wyboru, ale nie ma to żadnego znaczenia, oczywiście zawsze można decydować o indeksach na poziomie samej bazy danych). 9. Po zakończeniu pracy należy zaznaczyć pole Freeze Flexfield Definition, a następnie nacisnąć przycisk Compile, co spowoduje uruchomienie zlecenia kompilacji utworzonej struktury. Przed zamrożeniem definicji, nie jest możliwe użycie utworzonego wzorca w systemie. Zlecenie kompilacji tworzy jednocześnie widok, w którym kolumny odpowiadają utworzonym segmentom. Dla wzorców kluczowych widok taki będzie mieć nazwę taką samą jak tabela kombinacji, z dodaną końcówką KFV (Key Flexfield View). 10. Jeśli chce się sprawdzić jak wygląda okno do wprowadzania danych do gotowego wzorca (po zamrożeniu), można to zrobić z autoryzacji Application Developer, gdzie w menu Flexfield jest funkcja Flexfield Test. Po jej wybraniu należy wpisać dane o aplikacji, nazwie wzorca oraz nowoutworzonej struktury, po czym po naciśnięciu przycisku FLEXFIELD otworzy się okno, w którym po rozwinięciu znaku listy przy polu SEG- MENTS, otrzymamy ekran do wprowadzania danych do wzorca. Pola, dla których wcześniej, w trakcie definiowania wzorca zostały wpisane wartości domyślne, zostaną wyświetlone z tymi wartościami.

Oracle EBS mechanizmy dostosowywania i rozszerzania systemu 287 7.2. Wzorce opisowe Rys. 24. Testowanie nowoutworzonej struktury wzorca kluczowego. Wzorców opisowych (Descriptive Flexfields) jest w systemie znacznie więcej niż kluczowych. Jak już było wspomniane, pełnią one rolę zapasowych miejsc na nieprzewidziane informacje i w przeciwieństwie do wzorców kluczowych nie mają przypisanych specjalnych tabel do przechowywania wyłącznie kombinacji segmentów. W zamian, w zwykłych tabelach systemu, pełniących w systemie jakąś rolę, znajduje się kilkanaście lub kilkadziesiąt dodatkowych kolumn (to zależy od wzorca), do wykorzystania w razie czego. Kolumny te zazwyczaj mają nazwy AT- TRIBUTE1, ATTRIBUTE2,, ATTRIBUTEn, CONTEXT, GLOBAL_ATTRIBUTE1,, GLOBAL_ATTRIBUTEn. W formularzu związanym z taką tabelą znajduje się z kolei charakterystyczny znacznik wzorca w postaci nawiasów kwadratowych [ ] lub, rzadziej, okrągłych ( ). Jeśli dany wzorzec jest sparametryzowany i możliwy do użycia, a jego definicja jest zamrożona, to po kliknięciu na taki znacznik, otworzy się nowe okno (okno wzorca) do wprowadzania wartości. O wyglądzie takiego okna decyduje sposób parametryzacji wzorca oraz różne profile związane z wzorcami. Jeśli na przykład chcemy, by w module Human Resources, oprócz standardowych informacji o osobach, przewidzianych w systemie, gromadzone również były dane o ich ubezpieczeniu grupowym, możemy zaplanować odpowiednie pola wzorca, aby wprowadzać do nich żądane informacje. W tym, rozważanym przypadku, mogą to być na przykład: firma, składka, data przystąpienia i suma ubezpieczenia. Można nawet zażądać aby pola takie były obowiązkowo wypełniane. A co w takim razie z tymi osobami, które nie są ubezpieczone? Czy także trzeba będzie dla nich coś wpisywać? I na to jest rozwiązanie. Wśród pól, które można zdefiniować, jest tzw. pole kontekstowe oraz pola zależne od kontekstu. Wystarczy, że zawartość takiego kontekstu będzie mogła rozstrzygać czy dana osoba jest ubezpieczona, a można będzie resztę pól tak sparametryzować, by wyświetlała się tylko w przypadku pozytywnej odpowiedzi.