57
Podstawy architektury E-Business Suite cz. 1 Łódź, 20 czerwca 2004

Szkolenie z Podstaw Architektury EBS Cz1

Embed Size (px)

Citation preview

Page 1: Szkolenie z Podstaw Architektury EBS Cz1

Podstawy architektury E-Business Suite cz. 1

Łódź, 20 czerwca 2004

Page 2: Szkolenie z Podstaw Architektury EBS Cz1

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

Page 3: Szkolenie z Podstaw Architektury EBS Cz1

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.

Page 4: Szkolenie z Podstaw Architektury EBS Cz1

4Dotyczy: Podstawy architektury EBS

Rozdział

Architektura systemu EBS

Rozdział I

Page 5: Szkolenie z Podstaw Architektury EBS Cz1

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

Page 6: Szkolenie z Podstaw Architektury EBS Cz1

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)

Page 7: Szkolenie z Podstaw Architektury EBS Cz1

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

Page 8: Szkolenie z Podstaw Architektury EBS Cz1

8Dotyczy: Podstawy architektury EBS

Architektura trójwarstwowa – klient c.d.

● Kłopoty z certyfikatami● Sprawdzenie aktualnych certyfikatów

Page 9: Szkolenie z Podstaw Architektury EBS Cz1

9Dotyczy: Podstawy architektury EBS

Architektura trójwarstwowa – klient c.d.

● Kłopoty z certyfikatami c.d.● Objawy braku prawidłowego certyfikatu aplikacji (appltop)

Page 10: Szkolenie z Podstaw Architektury EBS Cz1

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

Page 11: Szkolenie z Podstaw Architektury EBS Cz1

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.

Page 12: Szkolenie z Podstaw Architektury EBS Cz1

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

Page 13: Szkolenie z Podstaw Architektury EBS Cz1

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)

Page 14: Szkolenie z Podstaw Architektury EBS Cz1

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

Page 15: Szkolenie z Podstaw Architektury EBS Cz1

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.

Page 16: Szkolenie z Podstaw Architektury EBS Cz1

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

Page 17: Szkolenie z Podstaw Architektury EBS Cz1

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)

Page 18: Szkolenie z Podstaw Architektury EBS Cz1

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

Page 19: Szkolenie z Podstaw Architektury EBS Cz1

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

Page 20: Szkolenie z Podstaw Architektury EBS Cz1

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.

Page 21: Szkolenie z Podstaw Architektury EBS Cz1

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.

Page 22: Szkolenie z Podstaw Architektury EBS Cz1

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.

Page 23: Szkolenie z Podstaw Architektury EBS Cz1

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.

Page 24: Szkolenie z Podstaw Architektury EBS Cz1

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.

Page 25: Szkolenie z Podstaw Architektury EBS Cz1

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.

Page 26: Szkolenie z Podstaw Architektury EBS Cz1

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?

Page 27: Szkolenie z Podstaw Architektury EBS Cz1

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

Page 28: Szkolenie z Podstaw Architektury EBS Cz1

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

Page 29: Szkolenie z Podstaw Architektury EBS Cz1

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

Page 30: Szkolenie z Podstaw Architektury EBS Cz1

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

Page 31: Szkolenie z Podstaw Architektury EBS Cz1

31Dotyczy: Podstawy architektury EBS

Rozdział

Dokumentacja systemu

Rozdział 2

Page 32: Szkolenie z Podstaw Architektury EBS Cz1

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

Page 33: Szkolenie z Podstaw Architektury EBS Cz1

33Dotyczy: Podstawy architektury EBS

Dokumentacja systemu c. d.

Prezentacja

Page 34: Szkolenie z Podstaw Architektury EBS Cz1

34Dotyczy: Podstawy architektury EBS

Rozdział

Zestawy wartości

Rozdział 3

Page 35: Szkolenie z Podstaw Architektury EBS Cz1

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)

Page 36: Szkolenie z Podstaw Architektury EBS Cz1

36Dotyczy: Podstawy architektury EBS

Zestawy wartości - rodzaje

Page 37: Szkolenie z Podstaw Architektury EBS Cz1

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

Page 38: Szkolenie z Podstaw Architektury EBS Cz1

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.

Page 39: Szkolenie z Podstaw Architektury EBS Cz1

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

Page 40: Szkolenie z Podstaw Architektury EBS Cz1

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

Page 41: Szkolenie z Podstaw Architektury EBS Cz1

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

Page 42: Szkolenie z Podstaw Architektury EBS Cz1

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

Page 43: Szkolenie z Podstaw Architektury EBS Cz1

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.

Page 44: Szkolenie z Podstaw Architektury EBS Cz1

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.

Page 45: Szkolenie z Podstaw Architektury EBS Cz1

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)

Page 46: Szkolenie z Podstaw Architektury EBS Cz1

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’

Page 47: Szkolenie z Podstaw Architektury EBS Cz1

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

Page 48: Szkolenie z Podstaw Architektury EBS Cz1

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.

Page 49: Szkolenie z Podstaw Architektury EBS Cz1

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.

Page 50: Szkolenie z Podstaw Architektury EBS Cz1

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

Page 51: Szkolenie z Podstaw Architektury EBS Cz1

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.

Page 52: Szkolenie z Podstaw Architektury EBS Cz1

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.

Page 53: Szkolenie z Podstaw Architektury EBS Cz1

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.

Page 54: Szkolenie z Podstaw Architektury EBS Cz1

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.

Page 55: Szkolenie z Podstaw Architektury EBS Cz1

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

Page 56: Szkolenie z Podstaw Architektury EBS Cz1

56Dotyczy: Podstawy architektury EBS

DziękujemyDziękujemy

Page 57: Szkolenie z Podstaw Architektury EBS Cz1

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: [email protected]