Oracle EBS - mechanizmy dostosowywania i rozszerzania systemu

Barbara Reimschűssel-WąsSoftbank S.A.

e–mail: b.was@softbank.pl

Abstrakt. 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.

1. WprowadzenieWiadomo 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:

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.

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 Oracle EBS. Pozwalają one na:

Deklaratywne dodawanie pól definiowanych przez użytkownika.

Zmiany procesów biznesowych.

Tworzenie nowych reguł.

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 specjalnie 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 samą aplikację), dzięki czemu koszty utrzymania systemu mogą być mniejsze.

W artykule tym omówione zostaną niektóre mechanizmy, wykorzystywane w Oracle EBS przy dostosowywaniu, modyfikowaniu i rozszerzaniu 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. Będą one jednak jedynie skrótowo zasygnalizowane 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 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ą 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 mogą zobaczyć czytelnicy/słuchacze.

2. Rzut oka na architekturę systemuZanim przejdziemy do sposobów modyfikowania zachowań systemu, konieczne jest pokazanie z jakich elementów składa się jego architektura.

Oracle EBS oparty jest o trójwarstwową architekturę, w której na każdej z warstw wykorzystywane są komponenty Oracle.

Rys. 1 Architektura systemu Oracle E-Business Suite

2.1. Warstwa przeglądarki

Interfejs użytkownika realizowany jest poprzez dynamicznie generowany przez strony JSP HTML i JavaScript dla nowszych modułów (dawniej zwanymi modułami Self Service) oraz aplety Javy generowane przez Forms Server dla modułów starszych. Aplety 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 przy pierwszym uruchomieniu systemu.

Chociaż przy każdym wydaniu systemu zwiększana jest liczba modułów opartych o HTML (obecnie 60), to nadal kluczowe moduły takie jak: Księga Główna, Należności, Zobowiązania zaimplementowane są w systemie przy pomocy technologii Oracle Forms. Taki dualizm oznacza, że oba rodzaje modułów dostosowuje się inaczej.

2.2. Warstwa aplikacji

Warstwą pośrednią systemu zarządza serwer aplikacji 9iAS (1.0.2.2.2). Obsługuje on zarówno komunikację pomiędzy warstwami, jak i jest miejscem przetwarzania logiki biznesowej aplikacji.

Jednym ze 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 systemu 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, stanowiący część Oracle Developera 6i. Definicje raportów – RDF, tworzone są przy użyciu Reports Builder 6i i to samo narzędzie służy także do tworzenia nowych lub modyfikacji istniejących raportów Oracle Reports.

Rys. 3 Obsługa żądania wykonania raportu Oracle Reports.

2.3. Warstwa bazy danych

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ł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

Prefix nazw obiektów bazy

Biblioteka obiektów aplikacji

FND APPLSYS, APPS

FND

Administracja SYSADMIN APPLSYS AD

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 (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 obiekt (na przykład w wyniku rozszerzenia) musi mieć też utworzone synonimy dla APPS. Wskazane też jest, aby zawsze, gdy sprawdza się cokolwiek w bazie danych, robić to przy pomocy synonimów APPS, a nie tabel z innych schematów. Zdarza się bowiem, że chociaż dany synonim nazywa się dokładnie tak jak jakaś tabela, to jednak odwołuje się nie do tej tabeli, a do widoku o zupełnie innej nazwie.

2.3.2. Dane inne niż biznesowe

Oprócz danych biznesowych w bazie danych przechowywane są również, także jako moduły, dane wykorzystywane przez różne komponenty samego systemu, wspólne dla wszystkich produktów Oracle EBS, takie jak:

DBA Aplikacji Oracle,

Narzędzia do administrowania i zarządzania systemem.

Biblioteka Obiektów Aplikacji,

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,

Grupa obiektów, w których przechowywane są informacje o narzędziu Oracle Workflow, które jest zintegrowane z Oracle EBS i jest, w wielu przypadkach, preferowanym sposobem wprowadzania zmian do logiki przetwarzania systemu.

Oracle Alert,

Dane aplikacji służącej do definiowania i zarządzania alertami, dzięki którym można monitorować i 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 akcji w samych aplikacjach.

Oracle Applications Framework

W bazie danych znajduje się repozytorium MDS, opisujące wygląd i sposób zachowania modułów opartych o Oracle Applications Framework (tzw. modułów Self Service).

Oracle XML Publisher

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, w którym możliwe jest zdefiniowanie formatu dokumentu.

Wszystkie metody dostosowywania i rozszerzania systemu omawiane w artykule są tworzone w powiązaniu z odpowiednimi zmianami w bazie danych. Zmiany te jednak będą, zgodnie z zaleceniem Oracle, umieszczanym na początku każdego z dokumentów dokumentacji systemu, wprowadzane wyłącznie poprzez warstwę aplikacji.

3. Różne typy dostosowywania i rozszerzania systemuWśród różnego typu dostosowywania systemu wyróżnić można, podobnie jak czyni to w swoich dokumentach Oracle, 4 kategorie:

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. 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.

W artykule zostaną przedstawione bliżej Profile i Foldery.

3.2. Zmiany konfiguracji

Tego typu dostosowywanie systemu polega na wykorzystywaniu zaawansowanych, wbudowanych mechanizmów, pozwalających w sposób deklaratywny zmienić funkcjonalność systemu tak, aby spełniał nie przewidziane w nim wcześniej wymagania biznesowe. W Oracle EBS tego typu dostosowanie można uzyskać wykorzystując między innymi:

Tworzenie nowych autoryzacji, opcji menu i całych menu,

Profile,

Wzorce opisowe i kluczowe.

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 systemie 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 Developer

Ważną, wspomnianą już wyżej, cechą systemu jest to, że udostępnia on dużą część kodu aplikacji. Rozszerzenia mogą więc wykorzystywać istniejące formularze, raporty oraz procesy Workflow.

Dodatkowym narzędziem jest biblioteka CUSTOM.pll, która jest dostarczana razem z systemem. Pozwala ona zmieniać funkcjonalność i wygląd formularzy w systemie, nie zmieniając ich kodu. Jest ona o tyle istotna, że Oracle gwarantuje zachowywanie zmian dokonanych poprzez CUSTOM.pll przy podnoszeniu wersji systemu.

Biblioteka CUSTOM.pll 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 zewnętrznymi systemami lub narzędziami, na przykład takimi jak:

Katalogi LDAP (w tym także katalog Oracle – OID),

Platformy EAI,

Inne systemy w firmie.

Oracle EBS posiada wiele, rozbudowane mechanizmó 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 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 to specjalny blok w formularzu zbudowanym w Oracle Forms, tak oprogramowany, że umożliwia zmianę sposobu oraz zakresu wyświetlanych danych przez użytkownika. Foldery zostały wprowadzone już w wersji klient – serwer systemu, czyli wersji 10. Mechanizm ten był w następnych wydaniach stopniowo rozszerzany. W wydaniu 11.5.10 nadal pełni istotną rolę, choć w tej wersji istnieją też inne sposoby personalizacji formularzy.

W całym systemie jest na stałe określona dla danej wersji liczba folderów (dla 11.5.10 - 222).typów folderów (typ folderu, niekiedy nazywany w systemie zbiorem folderów, wiąże się z konkretnym blokiem formularza). Nie można bez zmiany kodu systemu zmienić ekranu w folder, ponieważ aby formularz został folderem, musi zostać w tym celu specjalnie oprogramowany, przy użyciu dedykowanej biblioteki.

Foldery 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.

Folder umożliwia: Wyświetlanie tylko pewnych danych, poprzez wprowadzenie ograniczającego warunku.

Warunek ten tworzony jest automatycznie poprzez zapamiętanie warunku z zapytania zadanego przy ostatnim wyszukaniu rekordów.

Wyświetlenie danych posortowanych w określony sposób. Można określić sortowanie i jego sposób na 3 pierwszych kolumnach folderu.

Uwidocznianie lub ukrywanie niektórych pól na ekranie (nie wszystkich, dla niektórych, przy próbie ich ukrycia otrzymujemy komunikat „Tego 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 rysunku Rys. 6 lub wybrać odpowiednią opcję z menu Folder.

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ą filtrowane zgodnie z zapamiętanym zapytaniem. Opcja „Ask each time” oznacza, że za każdym razem gdy folder będzie otwierany, będzie zadawane pytanie czy filtrować dane.

Open as Default – oznacza, że folder staje się domyślnie otwieranym dla:

tworzącego go użytkownika, o ile nie jest zaznaczone „Public”,

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”), 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. W autoryzacji Administratora Systemu, 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

Jeśli skorzystamy z wyszukiwania jak na rysunku, to możemy jedynie zmienić niektóre opcje wyszukanego folderu (właściciela, to czy jest publiczny, czy związane jest z nim autozapytanie) oraz, po naciśnięciu przycisku „Default Assignments”, zobaczyć, w trybie tylko do odczytu, jego domyślne przypisania.

Rys. 10 Szczegóły folderu.

Rys. 11 Domyślne przypisania folderu – tylko do odczytu.

Jeśli natomiast wybierzemy na ekranie z rysunku Rys. 9 przeglądanie według przypisań do autoryzacji lub użytkownika, możemy zrobić więcej, bo zmienić przypisanie do użytkownika lub do autoryzacji:

Rys. 12 Przypisanie folderu do autoryzacji.

5. Zestawy wartości – narzędzie, bez którego nie można się obejśćZestawy wartości nie są same w sobie osobnym sposobem dostosowania systemu, nie sposób jednak prawidłowo wykorzystywać innych mechanizmów takich jak profile czy też wzorce, bez ich stosowania.

Zestaw wartości to po prostu 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 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 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ą wiązać jako nadrzędne i zależne. Wtedy sposób walidacji wartości z zestawu zależnego 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, na przykład przez dodanie do formularza nowego pola, bez zmiany kodu. Na ogół chcemy, aby do pola tego wprowadzać określone dane, choćby 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 (patrz str. 3).

W standardowej instalacji systemu tworzenie zestawów wartości dostępne jest z autoryzacji System Administrator oraz Application Developer w menu Application:Validation.

Rys. 13 Wykorzystanie zestawu wartości przy wprowadzaniu wartości parametru zlecenia

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

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 godzina2. 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 defnicji 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’

Rys. 15. Użycie zestawów wartości bez weryfikacji.

Użyte w powyższym przykładzie zestawy to:

30 Characters,

2 Digits,

3 Digits

Typ zatwierdzania determinuje dodatkowo 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 jest możliwe o ile używa się specyficznej, dość mocno rozbudowanej składni, której przedstawienie wykracza poza ramy tego artykułu.

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. W takim przypadku system Oracle EBS umożliwia zarówno definiowanie obu potrzebnych zestawów wartości, jak i obsługę danych czyli samych 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 nigdzie indziej 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 MeganPASS Passanger FF Ford FokusPASS Passanger DF DefaultLR Lorry MAN MANLR Lorry VL VolvoLR Lorry DF DefaultRC Racine RF1 Renault Formula 1RC Racine FR1 Ferrari Formula 1RC Racine DF Default

Nadrzędny zestaw tworzymy wybierając typ zatwierdzania Independent.

Następnie tworzymy odpowiadający mu zestaw zależny wybierając dla niego typ zatwierdzania Dependent. Dodatkowo, po naciśnięciu przycisku Edit Information, należy podać, jaka z wartości zestawu ma być 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.

Rys. 16 Definiowanie zestawu zależnego

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 mechanizmów zabezpieczeń dostępu do wartości (zagadnienia zabezpieczeń zestawów wartości są omawiane w [OraAFG05]), nie można ich też używać przy definiowaniu wzorca konta.

5.3. Zestawy kontrolowane przy pomocy tabeli

Zestawy takie umożliwiają zdefiniowanie w systemie powszechnie stosowanej listy, wartości której pochodzą z dowolnej tabeli bazy danych dostępnej w systemie, a nawet dodanej do systemu w ramach kastomizacji. Ogólnie rzecz biorąc takiej 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 przeinstalowanych 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, w tym oczywiście o tabeli i jej polach.

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.

Rys. 18 Szczegóły definicji zestawu walidowanego tabelą

Jeżeli poda się aplikację, z której pochodzi tabela i tabela ta jest zarejestrowana w aplikacji (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żyć 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.

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 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:

:$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ść drugiego 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).

Przykładem wykorzystania tej konstrukcji może być zależność parametrów programu zlecenia Completed Concurrent Requests Reports:

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 = ( SelectApplication_Short_Name from fnd_application A whereA.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.

Rys. 19 Efekt wykorzystania zmiennej związanej :$FLEX$

Zmienna :$PROFILES$ oznacza odwołanie się do wartości profilu w niej podanego. 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 zmienną :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. Profili jest w systemie ponad 5000. Stanowią one część konfiguracji, ale poprzez 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.

Profil może też posiadać wartość na kilku poziomach, ułożonych w 3 hierarchie. Domyślną hierarchią (zresztą 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 stopniu4, to:

Serwera (Server),

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 tylko w hierarchii bezpieczeństwa), to system przyjmuje, że najwyższy priorytet ma wartość na poziomie 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 poziomu wyższego.

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, a drugi dla administratorów. Na ekranie dla użytkowników widoczne są oczywiście tylko te profile, które może widzieć użytkownik. Administrator systemu może widzieć wszystkie profile,

4 Dla wersji 11.5.9 istniał tylko 1 profil na poziomie Serwera i nie było żadnego na poziomie organizacji.

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.

Nadawanie wartości wszystkim profilom, które są modyfikowalne, nie tylko dla własnego użytkownika, ale również dla innych oraz na wszystkich innych przewidzianych poziomach jest możliwe z autoryzacji System administrator.

Rys. 20 Nadawanie wartości profilom przez administratora

Na pokazanym przykładzie pokazany 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, do czego wykorzystywane są w definicji profilu omawiane wcześniej Zestawy wartości (Value sets).

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ą 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.

Rys. 21 Nadawanie wartości profilom użytkownika

6.2. Definiowanie profili

Wielką zaletą 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. Pozwala to tak kastomizować system, by w przyszłości zminimalizować konieczność jakichkolwiek zmian kodu.

Nowe profile definiuje się w autoryzacji Application Developer.

Rys. 22 Formularz definiowania folderów

W polu Name znajduje się identyfikator profilu, który jest wykorzystywany w kodzie oraz przez wszystkie funkcje Application Object Library, czyli także przy tworzeniu zestawów wartości.

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), a faktyczna wartość profilu w :PROFILE_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 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. 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).

Na ekranie powyżej pole SQL Validation wypełnione jest następująco:

SQL="SELECT MEANING \"Folders: Allow Customization\", LOOKUP_CODEINTO :VISIBLE_OPTION_VALUE, :PROFILE_OPTION_VALUEFROM FND_LOOKUPSWHERE 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 tej definicji.

7. Wzorce. Własne pola do zdefiniowania.Wzorce (Flexfields) są podstawowym narzędziem dostosowywania systemu Oracle EBS. Wykorzystują one 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 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, to 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 lista5. 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ę.

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).

5 Możliwe jest tworzenie nowych wzorców w nowo pisanych modułach.

Wzorzec kodu pozycji magazynowej w module Inventory (Magazyn).

Wzorzec roli zawodowej (Job) w module Kadry (Human Resources).

Każdy wzorzec kluczowy posiada szereg cech z nim związanych, wynikających ze sposobu w jaki został oprogramowany, które określają jego zachowanie. 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, kolumny której zawierają poszczególne segmenty wzorca. To, który segment z związany 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.

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.

Dynamiczne dodawanie kombinacji. Jest to cecha samego wzorca, którą w przypadku gdy jest możliwe dodawanie, można jeszcze dodatkowo skonfigurować 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, 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).

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, dynamiczne wstawianie kombinacji.

2. Zdecydować czy wzorzec ma zachowywać reguły wzajemnej walidacji segmentów (Cross Validation Rules), poprzez zaznaczenie odpowiedniego pola. Jeśli zostanie zdecydowane, że tak, będzie można wprowadzić reguły, dla jakich wartości jednego segmentu mają być możliwe wartości innego/innych segmentów (na przykład wartość MPK inna niż oznaczająca brak, tylko dla kosztowych wartości konta właściwego).

3. Utworzyć dla każdego planowanego segmentu (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) odpowiadający mu zestaw wartości niezależny.

4. Zdefiniować segmenty i określić ich podstawowe cechy czyli: nazwę, etykietę która będzie wyświetlana w oknie edycji (promet), 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. System będzie pokazywał 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 segmentu 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 poprzez przypisanie segmentowi odpowiedniego kwalifikatora.

Rys. 23 Definiowanie podstawowych cech segmentów8. 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).

9. Po zakończeniu pracy należy zaznaczyć pole Freeze Flexfield Definition, 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 struktura kolumn będzie odpowiadała 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 naciśnięciu znaku listy przy polu SEGMENTS, otrzymamy ekran do wprowadzania danych do wzorca. Pola, dla których wcześniej zostały wpisane wartości domyślne, zostaną wyświetlone z tymi wartościami.

Rys. 24 Testowanie nowoutworzonej struktury wzorca kluczowego.

7.2. Wzorce opisowe

Wzorców opisowych (Descriptive Flexfields) jest w systemie znacznie więcej niż kluczowych. 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, 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 ATTRIBUTE1, ATTRIBUTE2, …, ATTRIBUTEn, CONTEXT, GLOBAL_ATTRIBUTE1, …, GLOBAL_ATTRIBUTEn. W formularzu związanym z taką tabelą jest 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 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 dane. W tym rozważanym przypadku mogą to być na przykład: firma, wariant ubezpieczenia i miesięczna składka. Można nawet zażądać aby takie były obowiązkowo wypełniane. A co w takim razie z tymi osobami, które nie są ubezpieczone? 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ść kontekstu będzie rozstrzygać czy dana osoba jest ubezpieczona, a można będzie resztę pól sparametryzować, by wyświetlała się tylko w przypadku odpowiedzi „Tak”.

Każdy wzorzec opisowy posiada, podobnie jak wzorce kluczowe, jednoznacznie mu przypisaną nazwę wewnętrzną oraz tytuł, który jest jednocześnie tytułem okna, w którym będą się wyświetlały dane wzorca.

Wzorzec z powyższego przykładu ma tytuł Additional Personal Details, a jego moduł to Human Resources. Informacje o tym jaka jest jego wewnętrzna nazwa, w jakiej tabeli przechowywane są dane (będzie to ta sama tabela, w której przechowywane są w systemie informacje o osobach) i jakie kolumny są dostępne dla dodatkowych danych wzorca, można znaleźć w funkcji Flexfields:Register dostępnej w autoryzacji Application Developer.

Rys. 25 Informacje o wzorcu dostępne z autoryzacji Application Developer

Pole Structure Column zawiera informację, w jakiej kolumnie znajduje się wartość określająca kontekst wzorca. W przytoczonym przykładzie może to być na przykład jedna z dwóch wartości ‘Ubezpieczony/Nie ubezpieczony’.

Po naciśnięciu przycisku Columns można zobaczyć także jakie kolumny tabeli są związane z tym wzorcem.

Rys. 26 Kolumny dostępne dla danych definiowanych we wzorcu PER_PEOPLE

O tym czy dana kolumna będzie dostępna decyduje pole wyboru Enabled. Jak widać na powyższym przykładzie, są to kolumny ATTRIBUTE1, …, ATTRIBUTE30, ale można to zmienić. Nie jest jednak zalecane, aby jako pola wzorca udostępniać inne pola tabeli niż domyślne.

Do parametryzacji wzorców opisowych służy funkcja Flexfields:Descriptive:Segments, dostępna z autoryzacji System Administrator oraz Application Developer. Zmiany należy wprowadzać uważnie, ponieważ raz wprowadzonych pól nie można kasować, można je tylko zaznaczyć jako niedostępne.

7.2.1. Segmenty niezależne od kontekstu (globalne)

W każdym wzorcu opisowym występuje grupa pól, które nie są zależne od kontekstu. Są one nazywane „globalnymi”. Na formularzu Flexfields:Descriptive:Segments, dane niezależne od kontekstu widoczne są jako Global Data Elements.

Na rysunku [Rys. 27] widoczna jest definicja pól niezależnych od kontekstu, czyli Globar Data Elements dla wzorca dodatkowych danych osobowych. Jak widać większość ze zdefiniowanych pól ma odznaczone pole wyboru Enabled, dlatego nie są one brane pod uwagę.

Rys. 27 Pola niezależne od kontekstu dla wzorca Additioal Personal Details

Dla każdego pola należy wprowadzić: Etykietę wyświetlaną na ekranie (Window Prompt),

Kolumnę, w której dane będą przechowywane,

Zestaw wartości, który będzie związany z tym polem,

To, czy ma być wyświetlane. Pola niewyświetlane często stosuje się wtedy gdy są one wypełniane poprzez jakieś wartości domyślne.

Dalsze szczegóły wprowadza się na ekranie dostępnym po naciśnięciu przycisku Open.

Rys. 28 Szczegóły pola globalnego (nie kontekstowego) ‘Interest In Sports’

Niektóre z pól na tym formularzu zawiera te same dane co na poprzednim ekranie. Dwie grupy informacji są nowe:

Wartość domyślna pola. W zależności od typu wartości domyślnej, można tu podać stałą (jak na tym przykładzie), ale możliwe są też inne typy: pole (pole formularza, na którym wyświetla się wzorzec, należy go podać w formacie :block.field), segment (jeden z wcześniejszych segmentów), profil, a nawet instrukcja SQL (oczywiście taka, która zwraca pojedynczą wartość).

Informacje o sposobie wyświetlania – rozmiar, rozmiar opisu, oraz rozmiar opisu jeśli wyświetlane są segmenty w jednym ciągu, oddzielone separatorem.

7.2.2. Definiowanie pola kontekstu

Jeśli wymagane jest, aby dany wzorzec miał pola kontekstowe, należy najpierw określić pole kontekstu. Pole to definiuje się na głównym formularzu definicji wzorca, widocznym na Rys. 27, w regionie Context Field.

Najważniejszym pytaniem na które trzeba sobie odpowiedzieć jest, to czy ma nasz kontekst (w tym przypadku fakt ubezpieczenia) będzie na pewno jedynym. Każdy wzorzec opisowy ma tylko jedno pole kontekstu, jeśli więc ma ono zawierać kody tak naprawdę różnych kontekstów, jego etykieta musi być tak naprawdę mało znacząca. Jeśli więc jedynymi informacjami zależnymi od kontekstu będą dane o ubezpieczeniu, kontekst może mieć etykietę ‘Czy ubezpieczony?’ i wartości ‘Tak’, ‘Nie’. Ale jeśli miałyby tam być też informacje o numerze prawa jazdy zależne od tego czy dana osoba jest kierowcą, to jedynym rozwiązaniem jest nadanie etykiety ‘Kontekst’

(tutaj ‘Context Value’) i zaprojektowanie kodów dla pola kontekstu w rodzaju: ‘UBEZP’, ‘KIER’ itp..

W omawianym przypadku dla wzorca istnieją już inne segmenty zależne od kontekstu, więc po prostu należy dodać dodatkowy kod możliwy do wprowadzenia do pola kontekstowego (INSR).

7.2.3. Definiowanie segmentów zależnych od kontekstu

Segmenty kontekstowe tworzy się podobnie jak segmenty globalne. W naszym przypadku mogą to być pola jak na ekranie poniżej.

Rys. 29 Segmenty zależne od kontekstu (context sensitive)

7.2.4. Zamrażanie wzorca i kompilacja

Po zdefiniowaniu wszystkich segmentów, podobnie jak to było w przypadku wzorców kluczowych, należy „zamrozić” definicję wzorca, poprzez zaznaczenie pola wyboru Freeze Flexfield Definition. Po zamrożeniu należy skompilować wzorzec (przycisk Compile), co spowoduje to uruchomienie zlecenia kompilacji. Jeśli kompilacja zakończy się sukcesem, zostanie utworzony widok wzorca – w omawianym przykładzie PER_ALL_PEOPLE_F_DFV i wzorzec będzie gotowy do użycia.

Rys. 30 Okno wzorca po wybraniu wartości kontekstowej ‘Insurance’

Rys. 31To samo okno wzorca po wybraniu innej wartości kontekstowej.

8. Biblioteka CUSTOM.pll. Zmienianie działania formularzy bez zmiany ich kodu.

Jeżeli dostosowanie systemu do wymagań biznesowych wymaga więcej niż jest możliwe do zrobienia poprzez wzorce, profile, czy też foldery, z pomocą może przyjść biblioteka CUSTOM.pll (w wersji 11.5.9 można też część problemów rozwiązać przy pomocy personalizacji formularzy).

Jest to biblioteka PL/SQL dla Oracle Forms (Oracle EBS używa Oracle Forms 6i), dostarczana razem z systemem Oracle EBS. Każdy formularz, który jest częścią składową systemu i każdy formularz dodany do systemu w wyniku jego rozszerzenia, ale budowany zgodnie z regułami opisanymi w [OraADG01] odwołuje się wewnętrznie do tej biblioteki, wywołując dla swoich zdarzeń jej wyzwalacze.

Biblioteka jest umieszczona standardowo w podkatalogu resorce głównego katalogu aplikacji (wskazanego przez wartość $AU_TOP, dokładniejsze informacje o katalogach Oracle EBS można znaleźć w [OraAC05]). System używa w trakcie pracy skompilowanej wersji biblioteki (plx), która musi być także dostępna we wspomnianym katalogu.

8.1. Zdarzenia, dla których system wywołuje CUSTOM.pll WHEN-FORM_NAVIGATE – zdarzenie związane ze zmianą pozycji myszy na

formularzu,

WHEN-NEW-FORM-INSTANCE - zdarzenie wywoływane przy przechodzeniu do formularza,

WHEN-NEW-BLOCK-INSTANCE – zdarzenie przy przechodzeniu do nowego bloku formularza,

WHEN-NEW-ITEM-INSTANCE – zdarzenie przy przejściu do nowego pola,

WHEN-NEW-RECORD-INSTANCE – przy przejściu do nowego rekordu,

WHEN_VALIDATE-RECORD – przy zatwierdzaniu rekordu,

KEY-Fn (n może być od 1 do 8) – po naciśnięciu odpowiedniego klawisza funkcyjnego,

SPECIALn (n może być od 1 do 45) – przy aktywowaniu menu SPECIALn,

ZOOM – kiedy użytkownik wybierze Zoom z menu View->Zoom,

EXPORT – gdy użytkownik wykorzystuje możliwość eksportu danych z formularza do Excela,

Różne zdarzenia specyficzne dla produktu. Takie zdarzenia istnieją dla modułu Human Resouces (Kadry).

Zdarzenia Application Object Library: WHEN-LOGIN-CHANGED, WHEN-RESPONSIBILITY-CHANGED, WHEN-PASSWORD-CHANGED.

Niestety nie ma na tej liście zdarzenia WHEN-VALIDATE-ITEM, które jest jednym z częściej wykorzystywanych zdarzeń w formularzach.

Niestety nie ma też jednej reguły mówiącej o tym, w którym miejscu kodu danego zdarzenia na formularzu pierwotnym, wywoływana jest CUSTOM.pll. Dla niektórych zdarzeń (WHEN-FORM-NAVIGATE, WHEN-NEW-BLOCK-INSTANCE, WHEN-NEW-RECORD-INSTANCE, WHEN-NEW-ITEM-INSTANCE) będzie to na końcu obsługi zdarzenia, po wykonaniu się całego kodu zdarzenia pierwotnego. Dla SPECIALn będzie to przed istniejącym kodem wyzwalacza SPECIALn na pierwotnym formularzu (o ile taki kod istnieje). Dla pozostałych nie można powiedzieć nic pewnego, ponieważ zostało to różnie oprogramowane dla poszczególnych formularzy.

8.2. Przykład użycia

Przy pomocy CUSTOM.pll można w dość łatwy sposób zmienić właściwości obiektów na formularzu. W ten sposób można na przykład uniemożliwić uruchomienie pewnej funkcjonalności, dostępnej po naciśnięciu przycisku, poprzez ukrycie tego przycisku.

Poniższy przykład pokazuje ukrycie przycisku na formularzu Zamówienia Zakupu (Purchase Order POXPOEPO).

IF event_name = 'WHEN-NEW -FORM-INSTANCE' THEN-- Wyłacza przycisk rezerwacjiIF form_name = 'POXPOEPO'AND block_name = 'PO_APPROVE' THENSET_ITEM_PROPERTY('PO_APPROVE.UNRESERVE',DISPLAYED,PROPERTY_FALSE);SET_ITEM_PROPERTY('PO_APPROVE.UNRESERVE_DATE',DISPLAYED,PROPERTY_FALSE);END IF;END IF;

8.3. Ograniczenia CUSTOM.pll

Pewnych rzeczy nie wolno używać w CUSTOM.pll: Instrukcji SQL. Jeśli jest to konieczne, można używać procedur składowanych, które

wykonują żądane manipulacje na bazie danych.

Nie można wykorzystywać podstawowej biblioteki używanej przez wszystkie formularze APPCORE.pll. Jest tak dlatego, że to właśnie poprzez APPCORE.pll biblioteka CUSTOM.pll jest wywoływana. W zamian można wykorzystywać specjalnie w tym celu stworzoną APPCORE2.pll, która zawiera wiele podobnych procedur.

Przy pomocy CUSTOM.pll można zmieniać wyłącznie funkcjonalność zaimplementowaną przy pomocy Oracle Forms. Nie jest oczywiście możliwe jej użycie z Oracle Applications Framework.

8.4. Zalecenia dotyczące używania

Tam, gdzie nie jest konieczne użycie skomplikowanej logiki do zaprogramowania w PL-SQL, należy używać personalizacji formularzy zamiast CUSTOM.pll

Ponieważ CUSTOM.pll jest jedna, często kłopoty sprawia grupowa praca z tą biblioteką. Dlatego też kod wszystkich zdarzeń, przekraczający 1 linię, powinien być wywoływany z innych dołączanych bibliotek. Dołączanie nowych bibliotek jest jak najbardziej możliwe w CUSTOM.pll. Umożliwi to równoległą pracę z tymi bibliotekami.

9. Nowy moduł. Gdy zawiodą wszystkie inne metodyNowy moduł w systemie związany jest z zarówno ze zmianami w plikach konfiguracyjnych i środowiskiem po stronie serwera aplikacji, jak i z dodaniem informacji o tym module do Biblioteki Obiektów Aplikacacji (FND), czyli z zarejestrowaniem modułu.

9.1. Katalog modułu

Oracle EBS posiada sztywną strukturę katalogów, w której w osobnych miejscach umieszczone są pliki wykonywalne programów, wchodzących w skład systemu. Struktura ta jest opisana dokładniej w [OraAC05], dla nas w tej chwili istotne jest to, że każdy z modułów systemu posiada w niej swój macierzysty katalog identyfikowany zmienną środowiskową $PROD_TOP. Na przykład niezbędne pliki moduł Payables (Zobowiązania) znajdują się w katalogu wskazanym przez $AP_TOP. Dodając nowy moduł musimy stworzyć katalog tego modułu wraz z całą jego wewnętrzną strukturą, sprawić by zaczął on być wskazywany przez odpowiednią zmienną oraz nadawać wartość tej zmiennej przy starcie systemu.

Wszystkie pliki nowego modułu muszą się znaleźć w odpowiednich katalogach, czyli na przykład skompilowane formularze fmx, w katalogu forms, a raporty w katalogu reports.

Rys. 32 Układ katalogów dla pojedynczego produktu

9.2. Schemat modułu

Wszystkie obiekty bazy danych tworzone na użytek nowego modułu powinny spełniać reguły obowiązujące w całym systemie, a więc:

Ich nazwy powinny zaczynać się od prefixu produktu.

Dane i sekwencje powinny być w osobnym schemacie o nazwie będącą kodem modułu. Dla wszystkich danych powinny być założone synonimy do APPS (chyba, że inaczej zostanie wskazane w Grupie Danych).

Cały kod po stronie bazy danych oraz wszelkie widoki powinny być w schemacie APPS.

9.3. Rejestrowanie modułu w systemie.

Do zarejestrowania w systemie nowego modułu służy funkcja Application:Register dostępna z autoryzacji System Administrator oraz Application Developer.

Rys. 33 Okno rejestracji nowego modułu

Wymaga on by nowemu modułowi (Application) nadać nazwę, krótką nazwę (pełni rolę kodu) oraz podać nazwę zmiennej środowiskowej, która będzie wskazywać na katalog tego produktu.

Po zarejestrowaniu modułu w oknie rejestracji aplikacji, należy go też dodać do grupy danych. Jeśli nie zostanie to zrobione, reszta systemu nie będzie mogła korzystać z danych i programów nowego modułu. Grupa danych to lista modułów, gdzie dla każdego z nich jest podany użytkownik bazodanowy, poprzez którego dany moduł jest dostępny. Nowo zarejestrowany moduł należy dołączyć do takiej grupy danych, jaka będzie używana w autoryzacjach, które mają mieć dostęp do jego funkcjonalności. Najczęściej jest to po prostu grupa Standard, chyba, że jakaś inna grupa jest oznaczona jako domyślna (można to sprawdzić w bazie).

Rys. 34 Dodawanie nowego modułu do grupy danych Standard

10. KonkluzjaOd dawna wiadomo, że system Oracle EBS jest systemem rozszerzalnym przy użyciu standardowych narzędzi programistycznych. Niestety wiadomo też było, że wiele rozszerzeń, które tworzono w trakcie implementacji, bardzo trudno jest potem utrzymywać, a w dodatku bardzo utrudniają one podnoszenie wersji systemu. Dlatego też polityka Oracle idzie w kierunku objęcia jak najszerszego zakresu możliwego dostosowywania metodami deklaratywnego tworzenia rozszerzeń. Mechanizmy takie zostały przedstawione w artykule. Jest ich już w tej chwili na tyle dużo, że można śmiało powiedzieć, że tworzenie rozszerzeń w oparciu o całkiem nowe formularze lub strony i dołączanie całych nowych modułów powinno być stosowane w sytuacjach naprawdę wyjątkowych.

Bibliografia:[OraAC05] Oracle® Applications Concepts. Release 11i (11.5.10.2)

[OraADG01] Oracle® Applications Developer’s Guide

[OraAFG05] Oracle® Applications Flex elds Guide Release 11i

[OraSGM05] Oracle® Applications System Administrator’s Guide – Maintenance Release 11i