Temat: Najlepsze praktyki

To może zacznę :) Prawdopodobnie od rzeczy, które są dla większości osób oczywiste (choć na podstawie doświadczeń z pewną firmą wdrożeniową mogę podejrzewać, że dla niektórych powinny takie być, a nie są):
1. Designer:
Wykorzystanie mappletów, jeśli tylko szereg czynności powtarza się więcej, niż 2 razy. Dla początkujących: mapplety można potraktować, jak funkcje składowane. Mają parametry wejściowe i wyjściowe. A zawierają po prostu kilka-kilkanaście obiektów (lookupów, filtrów, agregacji, wyrażeń, itp.), połączonych ze sobą przepływami. Przedstawiają jakiś reużywalny algorytm - np. dobór sztucznego klucza (SK) kontrahenta na podstawie jego ID z sys. źródłowego i daty, na jaką chcemy znaleźć wersję rekordu w tabeli wymiarów. Ja używam do tego celu aż mappletu, ponieważ jeśli nie znajdę danych kontrahenta na jakąś datę, szukam najwcześniejszej wersji, itd... i te kilka obiektów, wrzucanych za każdym razem do mappingu wolę zaszyć w mapplecie i wtedy do mappingu dołączam zamiast nich tylko ten jeden obiekt - mapplet. To również gwarantuje spójność algorytmu wyboru SK kontrahenta.
Warto przed przystąpieniem do tworzenia mappingów przeanalizować ilość takich powtarzających się czynności i zaprojektować szereg mappletów. To spowoduje, że mappingi będą bardziej przejrzyste, a jeśli będzie konieczna zmiana algorytmu wyboru SK kontrahenta (np. zamiast pierwszej wersji zdecydujemy sie na ostatnią) - wystarczy to zmienić w jednym miejscu.
2. Designer:
Ograniczanie liczby mappingów. Jeśli mamy 2-3 tabele do wypełnienia i są one powiązane tematycznie (np kontrahenci, ich adresy, ich dowody toższamości), które muszą zostać wypełnione jedna po drugiej, albo jedną tablę, do której najpierw insertujemy, a potem wykonujemy na niej update, zróbmy jeden mapping, a w nim kilka ścieżek. Potem wykorzystajmy target load plan do określenia kolejności wykonywania tych ścieżek (zapełniania tabel docelowych - targetów). Przy 100 tabelach w hurtowni siatka połączeń pomiędy mappingami (zwłaszcza 150-cioma, bo osobne są na update'y) wygląda makabrycznie.
3. Designer:
Wykorzystanie opcji "Dynamic lookup cache" w lookupie - pozwala sprawdzić, czy rekord o danym PK został załadowany do targetu w bieżącym ładowaniu, czyli bierze pod uwagę jeszcze niescommitowane dane. W standardzie, czyli bez zaznaczenia tej opcji lookup pobiera tylko rekordy, które znajdowały się już w tabeli przed uruchomieniem mappingu. To się bardzo przydaje, kiedy mamy w hurtowni update'owane fakty. Bo i tak bywa.
4. Ustalenie konwencji nazewniczej. Sprawa dla części zapewne bez znaczenia, ale dla mnie ma znaczenie ogromne. Często nie muszę zaglądać do jakiegoś obiektu w mappingu, bo nazwa mówi mi na jego temat wszystko. Łatwo się również wyszukuje transformacje i mapplety na liście, jeśli są ponazywane w sposób uporządkowany.
5. Designer:
Ograniczanie pól w lookupie do niezbędnego minimum, a nie pozostawianie tam wszystkich pól z tabeli, do której sięgamy. Bo Informatica też do niej sięga i ładuje zawartość wszystkich określonych w lookupie pól do cache'a. Czyli w najgorszym przypadku - całą tabelę.

To na razie tyle.
Miłego dnia :)Izabela Korzińska edytował(a) ten post dnia 17.11.11 o godzinie 14:01

Temat: Najlepsze praktyki

6. Designer:
Należy też pamiętać, że lookupy, pobierając dane, sortują je. Kolejność jest taka:
..1. wszystkie pola z kolumny "Lookup Table Column" z zakładki "Condition" w kolejności, w jakiej na niej występują
a następnie
..2. wszystkie pola z zakładki "Ports" w kolejności, w jakiej na niej występują i z wyjątkiem pól z zakładki "Condition".

Czyli poziomów sortowania jest tyle, ile pól w lookupie (zaznaczonych, jako lookup). Choćby dlatego warto ograniczać liczbę tych pól.

To sortowanie można podejrzeć dopiero w logu sesji. Nawet poleceniem "Generate SQL" w zakładce "Properties" w pozycji "Lookup SQL Override" nie wygenerujemy kodu z klauzulą order by. Ta klauzula jest dodawana dopiero w momencie wypełniania cache'a. I dlatego podczas generowania SQL-a z klauzulą order by za pomocą polecenia "Lookup SQL Override" należy na końcu kodu dodać dwa myślniki, które zakomentują dalszą dopisaną część linii, czyli całe wieeelkie order by... w przeciwnym wypadku sesja się wywróci na tym lookupie :)Izabela Korzińska edytował(a) ten post dnia 17.11.11 o godzinie 13:59

Temat: Najlepsze praktyki

7. Designer:
"Number of sorted ports" w "Source Qualifier" - trzeba pamiętać, że sortowane są nie te porty, które są na górze listy portów, a te, które mają linki wyjściowe z SQ (w kolejności od górnego wyjścia w dół). Można to łatwo sprawdzić, generując na chwilę zapytanie w "SQL override"
8. Designer:
Sekwencje w Informatice - powinno sie ich unikać, jeśli przenosimy strukturę repozytorium pomiędzy środowiskami (instancjami bazy) z opcją zastępowania wszystkich obiektów (nie da się - albo nie wiem, że się da - za pomocą skryptu np. VB, importującego xml-e określić wybiórczo, jakiego rodzaju obiekty mają być zastępowane, a jakiego np. reużywane). Sekwencja informaticowa zawiera oczywiście informację o swojej ostatniej wartości i tak zostaje przeniesiona na inne środowisko, dzięki czemu w końcu naruszy PK, który zasila.Izabela Korzińska edytował(a) ten post dnia 17.11.11 o godzinie 13:59

Temat: Najlepsze praktyki

9. Workflow Manager:
Nie warto ustawiać Parameter Filename dla każdej sesji workflow-u, jeśli te sesje korzystają z tego samego pliku. Ścieżkę dostępu do tego pliku należy/wystarczy wtedy wpisać w zakładce "Properties" w edycji worklflowu - w pozycji Parameter Filename.
Po dodaniu kolejnych sesji do workflowu nie musimy pamiętać o tym, aby dla nich ustawić wszędzie tę ścieżkę w ich właściwościach :)
Natomiast wtedy trzeba pamiętać o tym, że:
1. do mappingu i tak będziemy musieli przekazać wartość zmiennych/parametrów workflowowych. Trzeba będzie ich wartości przypisać zmiennym/parametrom mappingowym w edycji sesji, w zakładce "Components" w sekcji "Pre-session variable assignment". Typy przypisywanych sobie zmiennych/parametrów muszą być jednakowe (w worflole mamy niestety mniej typów parametrów do wyboru, niż w mappingu).
2. zmienne/parametry workflowowe muszą mieć inne nazwy, niż zmienne/parametry mappingu - jeśli będą miały takie same, informatica zgłosi błąd.
3. w pliku parametrów wpisujemy nazwy zmiennych/parametrów workflowowych.
4. Informatica nie reaguje błędem, jeśli w SQ w mappingu mamy zaszytą zmienną workflowową - i w "Source filter" i w "SQL override". Nie wiem jeszcze, czemu - czy podstawia tam jakieś wartości (typu 0 do zmiennych typu ineteger, lub 1753 rok do daty...), czy korzysta ze zmiennych workflowu? Muszę popsuć jakiś SQ, żeby się przekonać :)Izabela Korzińska edytował(a) ten post dnia 18.11.11 o godzinie 12:21