View
194
Download
7
Category
Preview:
Citation preview
Podstawy architektury E-Business Suite cz. 1
Łódź, 20 czerwca 2004
2Dotyczy: Podstawy architektury EBS
Spis treści
I. Architektura systemu EBS
1. Architektura trójwarstwowa
2. Klient – przeglądarka i JInitiator
a. Baza certyfikatów, zarządzanie certyfikatami
3. Serwer aplikacji i jego wykorzystywane elementy
a. System plików - układ katalogów
b. Katalogi produktów, dostęp do źródeł aplikacji
4. Baza danych
a. Podział na schematy, użytkownicy systemowi
b. Schemat biblioteki obiektów aplikacji
c. Użytkownik aplikacji, synonimy
d. Widoki profilowane organizacją
e. Widoki profilowane identyfikatorem sesji
3Dotyczy: Podstawy architektury EBS
Spis treści
II. Dokumentacja systemu
1. e- TRM - udostępnione repozytorium metadanych systemu
III. Główne mechanizmy składające się na elastyczność systemu
1. Listy wartościa. Pojęcie zestawu wartości
b. Predefiniowane zestawy wartości
c. Zestawy niezależne i zależne – defniowanie.
d. Zabezpieczenia zestawów wartości
e. Zestawy kontrolowane przy pomocy tabeli.
4Dotyczy: Podstawy architektury EBS
Rozdział
Architektura systemu EBS
Rozdział I
5Dotyczy: Podstawy architektury EBS
Architektura
Architektura trójwarstwowa
Przeglądarka Internetowa+ JInitiator
Serwer Aplikacji Oracle 9iAS
Web Server
Forms Services
Report Services
Baza danych Oracle
Serwer bazy danych
Bazadanych
WAN
6Dotyczy: Podstawy architektury EBS
Architektura trójwarstwowa - klient
● EBS są 2 rodzaje klienta:● applet - generowany przez 9iAS Forms Services dla formatek● servlety Javy (JSP) - generowane przez moduł JServ 9iAS Oracle
HTTP Server (Apache) dla aplikacji Self Service.
● Applet jest pakowany w pliki JAR.● Klient oparty jest na własnej VM – JInitiator, która zastępuje
standardowe VM przeglądarek.● Możliwe jest korzystanie z IExplorer wersja >= 5.0 lub Netscape
>=4.73● Zalecane IExplorer 5.5 lub 6.0/6.0 SP1● Dostępne są 2 linie JInitiatora:
● 1.1.8.x – odpowiada to JDK 1.1● 1.3.1.x – odpowiada JDK 1.3
● U nas 1.1.8.16 (dostępne jest 24)
7Dotyczy: Podstawy architektury EBS
Architektura trójwarstwowa – klient c.d.
● Do instalacji JInitiator’a wymagane są uprawnienia użytkowników zaawansowanych (grupa Power Users) lub administratorów!!!
● Wniosek – nie będzie możliwe zainstalowanie sobie samemu poprzez autoinstalację.
● Instalacja IInitiatora oznacza:● Instalację JDK.
● Ściągnięcie certyfikatu, który umożliwia uruchamianie podpisanych pakietów JAR.
● Jak wiadomo aplety Java działają w wyizolowanym środowisku przeglądarki z ograniczonymi możliwościami komunikacji z otoczeniem.
● Mniejsze ograniczenia mają tzw. applety podpisane – pliki JAR są wtedy podpisane i analogiczny podpis jest umieszczony na kliencie.
● Baza z certyfikatami (dla JVM Oracle) identitydb.obj jest w katalogu C:\Program Files\Oracle
8Dotyczy: Podstawy architektury EBS
Architektura trójwarstwowa – klient c.d.
● Kłopoty z certyfikatami● Sprawdzenie aktualnych certyfikatów
9Dotyczy: Podstawy architektury EBS
Architektura trójwarstwowa – klient c.d.
● Kłopoty z certyfikatami c.d.● Objawy braku prawidłowego certyfikatu aplikacji (appltop)
10Dotyczy: Podstawy architektury EBS
Architektura trójwarstwowa – klient c.d.
● Kłopoty z certyfikatami c.d.● Objawy braku prawidłowego certyfikatu oraapps – brak możliwości
kopiowania danych (Ctrl+C, Ctrl+V) w środowisku.
● Rozwiązanie problemu – ściągnięcie prawidłowego certyfikatu z serwera aplikacji i dodanie do bazy certyfikatów.
● Ćwiczenie:● Usunąć certyfikat o nazwie (identity) appltop z bazy certyfikatów
javakey -r appltop
● Spróbować uruchomić aplikacje i zobaczyć co się stanie.● Dodać usunięty certyfikat (rozesłany)
javakey c APPL_CONVACC true
javakey ic APPL_CONVACC appltop.cer
11Dotyczy: Podstawy architektury EBS
Architektura trójwarstwowa – serwer aplikacji
● Serwer aplikacji Oracle 9iAS ● Dopuszczalne (czyli certyfikowane) są wersje:
● 1.0.2.2.2 (Release 1) – dostępna w paczce instalacyjnej.● 10g (9.0.4) może być użyta dodatkowo - dodatkowy, wolnostojący
serwer aplikacji.
● Wersja 9.0.2 (Release 2) – nie jest i nie będzie certyfikowana z aplikacjami.
● Wykorzystywane element● Oracle HTTP Server (Apache) - zawsze,● Forms Sevices - zawsze,● Reports Services – zawsze,● Oracle Internet Directory (LDAP) – częściowo wykorzystywany przy
implementacji Single Sign On - opcjonalnie,● Oracle Portal - opcjonalnie,● Oracle Discoverer 4.1.48 - opcjonalnie,● Oracle Workflow - zawsze.
12Dotyczy: Podstawy architektury EBS
Architektura trójwarstwowa – serwer aplikacji c.d.
● Forms Services ● Może być wiele serwerów
Oracle Forms – możliwy load balancing na tym poziomie (Metrics Server)
Serwer Aplikacji Oracle 9iAS
Web Server
Forms Services
Przetwarzanie logiki
klienta Oracle Forms
13Dotyczy: Podstawy architektury EBS
Architektura trójwarstwowa – system plików
● System plików dzieli się na część bazodanową i serwera aplikacji
● U nas są na osobnych serwerach (domenach)
14Dotyczy: Podstawy architektury EBS
Serwer aplikacji - system plików
● 3 główne katalogi:● inst_nameAPPL● inst_nameORA● inst_nameCOMN
● Są one wskazane przez zmienne środowiskowe:
● APPL_TOP● COMN_TOP
● W $APPL_TOP jest skonsolidowany plik konfiguracyjny APPS<SID>.env, w którym są zdefiniowane zmienne środowiskowe dla aplikacji, HTTP i Oracle (9i i 8).
15Dotyczy: Podstawy architektury EBS
Serwer aplikacji - system plików c. d.
● Katalog <nazwa_instancji>ORA zawiera ORACLE_HOMEs dla serwera aplikacji (składowe serwera aplikacji są klientem Oracle)
● Katalog <nazwa_instancji>COMN zawiera pliki używane wspólnie przez różne składniki 9iAS.
16Dotyczy: Podstawy architektury EBS
Serwer aplikacji - zawartość COMMON_TOP
● html - zawiera pliki HTML, JSP i inne do stron logowania i SS
● java - pliki JAR
● admin - w $COMMON_TOP zawiera domyślnie logi i pliki wynikowe zleceń współbieżnych (można to zmienić w trakcie instalacji aplikacji, tak, aby były w katalogach admin, ale dla poszczególnych produktów - w APPL_TOP).
17Dotyczy: Podstawy architektury EBS
Serwer aplikacji - pliki aplikacji
● Zawartość katalogu $APPL_TOP● <nazwa_instancji>.env – plik konfiguracyjny aplikacji (CONVACC.env lub
CONVDEV.env)● APPS<SID>.env – skonsolidowany plik konfiguracyjny (APPSORA.env)
18Dotyczy: Podstawy architektury EBS
Serwer aplikacji – pliki aplikacji c.d.
● Pozostałe podkatalogi dzielą się na katalogi produktów, katalog bibliotek wspólny dla produktów oraz katalogi wymagane przez narzędzia.
● admin – katalog zawierający pliki i skrypty wykorzystywane przez narzędzie AD.
● ad – katalog zawierający same narzędzia.
● au – katalog zawierający źródła i biblioteki używane przez aplikację. Źródła formularzy w podkatalogu forms
19Dotyczy: Podstawy architektury EBS
Serwer aplikacji – pliki aplikacji - pliki produktów
● Instalują się zawsze pliki dla wszystkich produktów - niezależnie od tego czy dany produkt jest zainstalowany czy nie.
● Katalog produktu jest wskazywany przez zmienną środowiskową <produkt>_TOP np. FND_TOP dla biblioteki obiektów aplikacji.
● Układ katalogu dla każdego produktu:
● admin - zawiera pliki używane przez AutoUpgrade do patchowania
● bin - pliki wykonywalne binarne● forms - tutaj pliki wykonywalne
– fmx● log i out - tu mogą być pliki
wynikowe zleceń i logi dla produktu
20Dotyczy: Podstawy architektury EBS
Serwer aplikacji – pliki aplikacji - pliki produktów - c. d.
● Jeśli instaluje się wersję językową inną niż US, każdy produkt ma osobne katalogi dla każdej wersji językowej.
● Aplikacja najpierw szuka pliku w aktualnej wersji językowej (np. PL), używanej przez użytkownika i jeśli tam nie znajdzie, w drugiej kolejności w US.
21Dotyczy: Podstawy architektury EBS
Architektura trójwarstwowa – serwer aplikacji c.d.
● Środowisko aplikacji● Ustawienia językowe – w
tej wersji (11i) ustawienia językowe każdego użytkownika nie zależą od ustawień środowiska serwera aplikacji, tylko są przechowywane w bazie danych jako profil użytkownika.
● Przy kompilowaniu formularzy (w przypadku zmian), na serwerze aplikacji muszą być skonfigurowane właściwe ustawienia językowe.
22Dotyczy: Podstawy architektury EBS
Architektura trójwarstwowa – baza danych
● Baza danych Oracle 9.2.0.3.0 (u nas)● Certyfikowana jest również: 8.1.7 – do 01.01.2005● Każdy moduł (produkt) EBS posiada swój własny schemat, w którym
przechowywane są:● dane,● indeksy,● sekwencje● tabela FND_APPLICATION zawiera informacje o produktach (wszystkich możliwych)● tabela FND_MODULE_INSTALLATIONS zawiera informacje o tym, które moduły są
zainstalowane, a które nie.● tabela FND_ORACLE_USERID zawiera informacje o schematach Oracle
● Pozostałe obiekty (w tym widoki) i kod (procedury, pakiety) należą do schematu APPS
● Do bazy aplikacja loguje się poprzez użytkownika wskazanego w definicji grupy danych. Generalnie jest to APPS.
● Jedynie użytkownik (schemat) APPS posiada uprawnienia do wszystkich obiektów EBS, więc należy ostrożnie używać logowania na inne schematy – musimy mieć pewność, że po takim zalogowaniu, użytkownik będzie miał dostęp do wszystkich używanych obiektów.
23Dotyczy: Podstawy architektury EBS
Architektura trójwarstwowa – baza danych
● Inne ważne predefiniowane schematy EBS:● APPLSYSPUB – użytkownik, na którego aplikacja loguje się przed
wprowadzeniem danych użytkownika. Użytkownik ten i jego hasło muszą być ogólnodostępne.
● APPLSYS – schemat, który jest właścicielem tzw. obiektów biblioteki aplikacji (AOL), czyli obiektów do zarządzania. Są to te zaczynające się od AD, FND i WF.
● APPS widzi obiekty innych schematów poprzez synonimy.
● Zasady:● Należy używać takich obiektów, które widzi APPS, ponieważ tylko wtedy
mamy pewność, że widzimy to samo co aplikacja.● Przykład:
● RA_CUSTOMERS – taka tabela jest w schemacie AR, ale jest też synonim o tej samej nazwie w schemacie APPS. Synonim jest nie do tabeli, tylko do widoku RA_HCUSTOMERS. Wniosek – aplikacja używa widoku, nie tabeli.
24Dotyczy: Podstawy architektury EBS
Baza danych – synonimy
● Najwygodniej jest pracować na synonimach i jeśli używamy jakiegoś narzędzia, to filtrować je – wszystkich jest za dużo.
● Każdy nowododawany obiekt, musi w skrypcie tworzącym go, mieć również tworzenie potrzebnych synonimów.
25Dotyczy: Podstawy architektury EBS
Baza danych – więzy integralności
● Generalnie w bazie nie ma zdefiniowanych kluczy głównych i kluczy obcych.
● Dla każdej tabeli można znaleźć informacje o kluczach w e-TRM na Metalinku, w widoku projektu (FND), ale nie jest to praktyczne gdy chcemy szybko coś sprawdzić (przy pisaniu SELECT-ów). Lepiej jest sprawdzać indeksy unikalne.
● Należy uważać, żeby zbyt pochopnie nie potraktować kolumn o nazwach z id jako PK.
● Przykład: FND_CONCURRENT_PROGRAMS - kolumna CONCURRENT_PROGRAM_ID nie jest kluczem głównym.
26Dotyczy: Podstawy architektury EBS
Baza danych – widoki, widoki profilowane
● Właścicielem widoków jest APPS (są małe wyjątki – skutki niedbalstwa).
● Widoki profilowane:● Ponieważ EBS może działać w
tzw. trybie multi org - praca wielu firm na jednej bazie, wiele tabel ma na końcu nazwy _ALL, co oznacza, że można je filtrować po organizacji (firmie).
● Do filtrowania służą widoki, o tej samej nazwie (zwykle), ale bez _ALL.
● Niestety jak próbujemy z nich skorzystać... – brak danych
● Przykład AP_INVOICES - jak wygląda definicja?
27Dotyczy: Podstawy architektury EBS
Baza danych – widoki profilowane
● Przyczyną jest dynamiczna definicja widoków, zawierająca odwołanie do USERENV(‘CLIENT_INFO’) – wartość ‘CLIENT_INFO’ nadawana jest w aplikacji – jest to ID organizacji.
● Można temu zaradzić. Wartość USERENV() obowiązuje na czas sesji, więc można sobie to ustawić.
● Istnieje API do ustawiania tej wartości, z którego korzysta aplikacja:
● pakiet FND_CLIENT_INFO● procedura
SET_ORG_CONTEXT(v_org_id) parametr jest typu VARCHAR2
● Ćwiczenie:● Uruchomić skrypt, który sprawi, że
SELECT * FROM AP_INVOICES zwróci jakieś dane, wiedząc, że w TP ORG_ID jest 82
28Dotyczy: Podstawy architektury EBS
Baza danych – widoki profilowane
● Widoki profilowane c.d.● Innym typem profilowanych widoków są widoki uzależnione od
identyfikatora sesji.
● Takie widoki stosowane są m. in. w module kadrowym.
● Korzystanie z nich poza aplikacją jest trudniejsze, bo identyfikator bieżącej sesji należy wstawić do tabeli FND_SESSIONS, co nie jest zalecane.
● Przykład:
PER_ALL_ASSIGNMENTS,
PER_ALL_PEOPLE
29Dotyczy: Podstawy architektury EBS
Baza danych – widoki profilowane cz. 3
● Najczęściej stosowana składnia
WHERE effective_start_date <= (SELECT ss.effective_date FROM fnd_sessions ss WHERE ss.session_id = USERENV ('sessionid')) AND effective_end_date >= (SELECT se.effective_date FROM fnd_sessions se WHERE se.session_id =
USERENV('sessionid'))
● Skrypt umożliwiający korzystanie z takiego widoku spoza aplikacji: insert into fnd_sessions(session_id, effective_date) values(USERENV ('sessionid'), trunc(sysdate));
30Dotyczy: Podstawy architektury EBS
Baza danych – wielojęzykowość
● Dla danych, które muszą być wyświetlane w wielu językach, oprócz tabeli podstawowej istnieje zazwyczaj dodatkowa.
● Nazwa tabel z danymi w danym języku zazwyczaj kończy się na _TL
● Ma klucz CK (klucz kandydujący) złożony z klucza z tabeli podstawowej i kolumny LANGUAGE.
● Przykład:● FND_APPLICATION,● FND_APPLICATION_TL
31Dotyczy: Podstawy architektury EBS
Rozdział
Dokumentacja systemu
Rozdział 2
32Dotyczy: Podstawy architektury EBS
Dokumentacja systemu
● Na Metalinku dostępnym dla klientów posiadających CSI.
● Oficjalne dokumenty opisujące rozwiązania różnych problemów.
● e-TRM – repozytorium systemu w formacie Designer’a
● Definicje obiektów bazy (tabele, widoki) - informacje DBA.
● Krótkie opisy obiektów – tabel, kolumn i ich zastosowania.
● Powiązania i więzy, których nie ma w rzeczywistej bazie - informacje FND.
● Wykorzystanie obiektów po stronie bazy danych (procedury, pakiety, widoki).
33Dotyczy: Podstawy architektury EBS
Dokumentacja systemu c. d.
Prezentacja
34Dotyczy: Podstawy architektury EBS
Rozdział
Zestawy wartości
Rozdział 3
35Dotyczy: Podstawy architektury EBS
Zestawy wartości
● Zdefiniowane w systemie zbiory wartości o takim samym formacie i podobnym zastosowaniu.
● Mogą być skończoną listą (wartości w tabeli lub lista podana wprost) lub tylko określać format wartości wpisywanych „z ręki”.
● Mogą być ze sobą powiązane jako zestawy niezależne i zależne oraz w inny sposób.
● Można dla nich określić:● format● sposób kontroli wartości (walidacji)● sposób zabezpieczeń
● Stosuje się je:● dla wzorców opisowych i kluczowych● dla zleceń współbieżnych (parametry)
36Dotyczy: Podstawy architektury EBS
Zestawy wartości - rodzaje
37Dotyczy: Podstawy architektury EBS
Zestawy wartości - rodzaje
● Rodzaje sposobów kontroli● Brak walidacji● Niezależny zestaw wartości● Zależny zestaw wartości● Tabela● Specjalny● Para
● Rodzaje list:● Zwykła lista wartości (nie
dla SS Apps)● Długa lista wartości –
odpowiada długiej liście w Forms – przykład.
● Lista rozwijana (Pop Lista) – widać w SS Apps
38Dotyczy: Podstawy architektury EBS
Zestawy wartości - definiowanie
● W zdefiniowanym zestawie wartości nie da rady zmienić pewnych informacji: typ walidacji, typ formatu, zmniejszenie maksymalnego rozmiaru.
● Typ zabezpieczeń (Security Type)
● dotyczy zabezpieczeń wzorców, wykorzystujących dany zestaw
● stosuje się tylko do zestawów z walidacją z tabeli, zależnych i niezależnych.
● może być bez zabezpieczeń, zabezpieczenia hierarchiczne, zabezpieczenia nie hierarchiczne.
● Do zabezpieczeń wrócimy po omówieniu zestawów niezależnych i z walidacją z tabeli.
39Dotyczy: Podstawy architektury EBS
Zestawy wartości - predefiniowane
● Razem z aplikacją instaluje się pewna liczba predefiniowanych zestawów wartości do wykorzystywania, m. in.:
● FND_NUMBER,
● FND_NUMBER15,
● FND_NUMBER15_REQUIRED,
● FND_STANDARD_DATE,
● FND_DATE (tylko dla wstecznej kompatybilności, nie zalecany),
● FND_STANDARD_DATETIME
● FND_DATETIME (nie polecane, podobnie jak FND_DATE)
● Oczywiście to nie wszystkie, bo instaluje się mnóstwo zestawów do parametrów wszystkich zleceń instalowanych razem z aplikacją.
40Dotyczy: Podstawy architektury EBS
Zestawy wartości – przykłady użycia i definicji
● Dowolny parametr zlecenia musi być oparty o jakiś zestaw wartości
● Przykład działania:● Zestawy wartości bez
kontroli wartości – raport „Analyze All Index Column Statistics” („Analiza statystyk wszystkich kolumn indeksu”)
● Odpowiadające im definicje● 30 Characters● 2 Digits – format liczby od 0
do 99● FND_STANDARD_DATE
41Dotyczy: Podstawy architektury EBS
Zestawy wartości – przykłady użycia i definicji
● Przykład zestawu wartości bez kontroli wartości, ale z formatowaniem - data – raport „Purge Signon Audit data” („Usuwanie danych kontroli rejestracji”) w autoryzacji Administrator Systemu
● Definicja● FND_STANDARD_DATE –
zestaw standardowy, tworzony przy instalacji systemu
42Dotyczy: Podstawy architektury EBS
Zestawy wartości – zestawy niezależne
● System umożliwia zarówno ich definiowanie jak i obsługę.
● Wartości wprowadzamy w Aplikacja/Zatwierdzanie/Wartości
● Przykład zestawu niezależnego PO_PDOI_DOCUMENT_TYPES
● Inne przykłady uzyskamy wyszukując w oknie definiowania zestawy niezależne przez F11
43Dotyczy: Podstawy architektury EBS
Zestawy wartości – ćwiczenie
● Zdefiniować zestaw wartości QA_CAR_TYPES_n (Rodzaje samochodów)
● niezależny,● typ listy – lista wartości,● bez zabezpieczeń,● znakowy,● 30 znaków max.
● Nie wprowadzamy jeszcze wartości.
44Dotyczy: Podstawy architektury EBS
Zestawy wartości niezależne i zależne
● Definiując zestaw zależny podajemy dla niego jego zestaw nadrzędny oraz wartość domyślną.
● Przy wprowadzaniu wartości nadrzędnych, do każdej automatycznie przypisze się wartość domyślna.
● Przykłady działania:● Zlecenie: Import Price Catalog
(Otwarty interfejs dokumentów Zaopatrzenia)
● Definicje● Zestawy:
PO_PDOI_DOCUMENT_TYPES
PO_PDOI_DOCUMENT_SUBTYPES,
Można zobaczyć jak są wpisane do nich wartości.
45Dotyczy: Podstawy architektury EBS
Zestawy wartości niezależne i zależne – przykłady
● Zestaw wartości związany z segmentem konta właściwego wzorca kluczowego planu kont AKF.
TPSA_AFF_KONTO
Jest to zestaw niezależny, ale z hierarchią - jest to coś innego, choć daje podobny efekt. Takie hierarchie wykorzystywane są głównie we wzorcu AKF do tworzenia kont nadrzędnych.
● QA_HIERARCHY (id=1008543)
46Dotyczy: Podstawy architektury EBS
Zestawy wartości zależne – ćwiczenie
● Zdefiniować zestaw wartości QA_CARS_n.● zależny● jego nadrzędnym zestawem jest QA_CAR_TYPES_n● typ listy - lista wartości● bez zabezpieczeń● znakowy● 30 znaków● wprowadzamy wartość domyślną
● Wprowadzić wartości dla QA_CAR_TYPES_n● ‘Osobowe’● ‘Terenowe’● ‘Ciężarowe’
● Wprowadzić wartości dla QA_CARS_n● ‘Dowolny’, ‘Skoda Fabia’, ‘Ford Focus’, ‘Smart’● ‘Jeep Wrangler’, ‘Mitsubishi Pajero’, ● ‘Scania’, ‘MAN’, ‘Volvo’
47Dotyczy: Podstawy architektury EBS
Zestawy wartości niezależne i zależne – model danych
● Wszystkie zestawy wartości – podstawowa część definicji w APPSYS:
● FND_FLEX_VALUE_SETS
● Wartości dla zestawów niezależnych i zależnych w APPSYS
● FND_FLEX_VALUES● FND_FLEX_VALUES_TL
● Połączenie między wartościami zależnymi i niezależnymi jest po polach
FND_FLEX_VALUES.PARENT_FLEX_VALUE_LOW i
FND_FLEX_VALUES.FLEX_VALUE
48Dotyczy: Podstawy architektury EBS
Zestawy wartości zależne i niezależne – model danych
● Ćwiczenie:● Wyświetlić jako wynik SELECT: nazwę zestawu wartości nadrzędnego
QA_CARS_n, wartość z zestawu nadrzędnego, nazwę zestawu podrzędnego, wartość podrzędną z zestawu podrzędnego.
● Powinno być tyle wierszy, ile wartości podrzędnych.
● Pytanie: Co będzie dla tych wartości nadrzędnych, dla których nie ma żadnej wartości podrzędnej.
● Przykład: Zestawy wartości QA_CATEGORIES i QA_SUBCATEGORIES. W QA_SUBCATEGORIES nie ma żadnych wartości.
● Wyświetlmy sobie tak samo jak poprzednio wartości nadrzędne i podrzędne dla każdej z nadrzędnych. Widać, że dla każdej nadrzędnej została przypisana wartość domyślna.
49Dotyczy: Podstawy architektury EBS
Zlecenia – program do sprawdzania zestawów wartości
● Ćwiczenie ● Rejestracja programu, które
będzie wyłącznie do testowania zestawów wartości i flexów.
● Programy:● QAXXT1
● QAXXT2
● ...
● ...
● Jest plik wykonywalny: „Irek_test_raport_1”, który możemy wykorzystać
● Nie będziemy uruchamiać tego programu.
50Dotyczy: Podstawy architektury EBS
Zlecenia – program do sprawdzania zestawów wartości - dane programu
● Otwieramy formularz „Programy”. Wpisujemy nazwę programu – podaną wyżej nazwę zlecenia.
● Przy nazwie pliku wykonywalnego podajemy jego skrót (‘Irek_TP1’)
● Jako aplikację podajemy Oracle Quality (Zarządzanie Jakością)
● Jako skrót nazwy zlecenia to samo co w nazwie zlecenia
● Przechodzimy do ekranu „Parametry”.
51Dotyczy: Podstawy architektury EBS
Zlecenia – program do sprawdzania zestawów wartości - pierwszy parametr
● Parametry podaje się tylko dla zleceń, które się chce wywoływać z okna uruchomienia zlecenia.
● Mają zaznaczone „Uruchamianie SRS”.
● Należy je dołączyć do grupy zleceń.
● Zlecenie można też wywołać z kodu PL/SQL. Jest do tego odpowiednia procedura.
● Rejestrujemy pierwszy parametr TYP_SAMOCHODU, wpisując mu zestaw wartości, który utworzyliśmy.
● Lp. lepiej nadawać co 10, żeby można było wstawić coś w środek.
52Dotyczy: Podstawy architektury EBS
Zlecenia – program do sprawdzania zestawów wartości - drugi parametr
● Rejestrujemy drugi parametr (Lp. 20) - SAMOCHOD
● Nadajemy mu zestaw zależny, który utworzyliśmy
● Przypisujemy zdefiniowany program do grupy zleceń dla autoryzacji Administrator Systemu (jaka to grupa zleceń?) i do autoryzacji Zarządzanie Jakością (jaka to grupa zleceń?).
● Sprawdzamy jak działają nasze zestawy.
53Dotyczy: Podstawy architektury EBS
Zestawy wartości - zabezpieczanie
● Zabezpieczenia dotyczą reguł dostępu do wartości w zestawach.
● Dla zestawu ustala się tylko czy może on mieć przypisane reguły.
● Reguły polegają na wyłączeniach i włączeniach pewnych zakresów wartości dla danej autoryzacji.
● Zabezpieczenie hierarchiczne● Reguła zdefiniowana dla
wartości rodziców stosuje się dla wartości dzieci.
● Zabezpieczenie nie hierarchiczne
● Reguły dla rodziców i dzieci definiuje się oddzielnie.
54Dotyczy: Podstawy architektury EBS
Zestawy wartości – zabezpieczanie - ćwiczenie
● Sprawdzić czy rzeczywiście do zestawu QA_CAR_TYPES_n nie da się przypisać reguł zabezpieczeń.
● Co należy zmienić w definicji zestawu? Zmienić to.
● Wprowadzić regułę, tak aby użytkownik z autoryzacji Administrator Systemu widać było tylko jeden typ samochodów (osobowe), a z autoryzacji Zarządzanie Jakością wszystkie
● Sprawdzić czy działa zgodnie z oczekiwaniami.
55Dotyczy: Podstawy architektury EBS
Zestawy wartości – hierarchia rodzice, dzieci.
● Funkcjonalność wykorzystywana jedynie w Księdze Głównej i to wyłącznie dla AKF.
● Można ją zdefiniować dla dowolnego zestawu niezależnego, zależnego lub kontrolowanego przy pomocy tabeli (o ile zaznaczymy odpowiedni check box), ale ma to sens tylko dla tego zestawu, który będzie wykorzystywany w AKF.
● Na ekranie definiowania wartości określamy, która wartość jest wartością „rodzicem”. Dla takiej wartości można zdefiniować zakresy jej „dzieci”. EBS informacje o zakresach dzieci przechowuje też w tabeli FND_FLEX_VALUES
56Dotyczy: Podstawy architektury EBS
DziękujemyDziękujemy
57Dotyczy: Podstawy architektury EBS
Prezentacja przygotowana przez:
Imię i Nazwisko: Barbara Reimschussel
Nazwa pionu: Pion Utrzymania Informatyki
Departament: Departament Operacji
Telefon: (0 42) 682 69 52
E-mail: Barbara.Reimschussel@telekomunikacja.pl
Recommended