Drogi czytelniku, jeżeli nie miałeś wcześniej do czynienia z SAP-ową hurtownią danych BW4/HANA, to przed przeczytaniem tego artykułu zapoznaj się proszę z dwoma artykułami Bartka Kurowskiego, w których zostały opisane kluczowe fakty dotyczące zagadnienia: BW/4HANA – nowa hurtownia danych SAP łączy ewolucję z rewolucją oraz BW/4HANA – ciąg dalszy (r)ewolucji.
W ten sposób będzie Ci łatwiej zinterpretować poniższy artykuł, skupiający się na tym:
- czym jest aDSO,
- jakie są możliwe scenariusze,
- z jakich tabel następuje ekstrakcja danych oraz raportowanie.
Zacznijmy od podstaw – czym jest aDSO?
Advanced DataStore Object (aDSO) jest centralnym obiektem, który fizycznie przechowuje dane transakcyjne w systemie BW. Może składać się z InfoObiektów lub pól. Jeżeli chcemy szybko stworzyć model danych, to istnieje możliwość wykorzystania pól. Natomiast jeżeli chcielibyśmy skorzystać z właściwości InfoObiektów (atrybutów, tekstów, hierarchii, wskaźników, danych zależnych od czasu), wtedy warto wybrać właśnie InfoObiekty.
W BW4/HANA, w porównaniu do klasycznego BW, aDSO zastępuje 4 obiekty. Są to:
- InfoCube,
- DataStore Object,
- Hybrid Provider,
- PSA Table.
Tabele w aDSO
Advanced DSO składa się z 3 głównych tabel, które zostają wygenerowane podczas tworzenia i aktywacji aDSO. Są one wykorzystywane zależnie od wybranego szablonu.
- Inbound table – na początku dane są ładowane do tej tabeli.
- Nazwa techniczna: /BIC/ A<ADSO technical name>1.
- Struktura: Request ID (REQUSN), Data Package (DATAPAKID), Record number (RECORD), Record mode (RECORDMODE), Key Field 1, Key Field n, Field 1, Field n…
- Active table – do tej tabeli trafiają dane po aktywacji. Modeler musi ustalić klucz, po którym dane będą się aktywowały, co oznacza, że jeśli będzie więcej niż jeden rekord z tym samym kluczem, to duplikaty zostaną usunięte lub nadpisane.
- Nazwa techniczna: /BIC/ A<ADSO technical name>2.
- Struktura: Key Field 1, Key Field n, Record mode (RECORDMODE), Field 1, Field n…
- Change log – w tej tabeli przechowywane są wszelkie zmiany zachodzące podczas aktywacji – znajduje się tutaj cała historia zmian. Tabela jest pomocna np. przy sprawdzeniu, jak dane zmienią się podczas ładowania i aktywacji.
- Nazwa techniczna: /BIC/ A<ADSO technical name>3.
- Struktura: Request ID (REQUSN), Data Package (DATAPAKID), Record number (RECORD), Record mode (RECORDMODE), Key Field 1, Key Field n, Field 1, Field n…
W związku z tym, że aDSO zastępuje w BW4/HANA cztery inne obiekty (w porównaniu do klasycznego podejścia BW), podczas tworzenia mamy do wyboru kilka różnych szablonów. Wybieramy je w zależności od naszych potrzeb i warstwy architektury LSA++, w której mają znaleźć się dane.
Data Acquisition Layer (uwzględniając Corporate Memory)
Jak widzimy na poniższej grafice, requesty będą ładowane do Inbound Table, podobnie jak ekstrakcja danych. W tym wypadku dane nie są agregowane, w związku z czym ten typ aDSO nie nadaje się do bezpośredniego raportowania. Warto zauważyć, że mapowania powinny odbywać się 1:1 – tak jak przychodzą z DataSource, bez żadnych transformacji. Kluczem technicznym jest Request number, Datapackage and Record.
Corporate memory – compression capabilities
W tym wypadku dane będą ładowane do Inbound Table. Requesty o wysokim poziomie szczegółowości mogą zostać skompresowane, a aktywacja nastąpi po kluczu do Active Table. Requesty z Inbound Table są usuwane. Raportowanie dokonuje się na poziomie Active Table. Ekstrakcja do wyższych warstw odbywa się z Active Table (full, initial) i Inbound Table (full, initial, delta).
Corporate memory – reporting capabilities
W tym wypadku dane po aktywacji nie są usuwane z Inbound Table. Aktywacja następuje na podstawie zdefiniowanego klucza. Raportowanie odbywa się na poziomie Active Table, natomiast sama ekstrakcja na poziomie Inbound Table.
Propagation Layer
W tej warstwie mamy standardowe DSO. Dane są ładowane do Inbound Table. Po aktywacji lądują zarówno w Active Table, jak i w Change Logu. Ekstrakcja następuje z Active Table (full, initial) i Change loga (delta). W tym typie aDSO możliwe jest usuwanie requestów nawet po aktywacji danych. Spójności danych pilnuje Change Log.
Reporting Layer
Dane zostają załadowane do Inbound Table. Wszystkie pola są kluczem, w związku z czym inna wartość na dowolnym polu spowoduje dodanie rekordu do Active Table podczas aktywacji. Raportowanie odbywa się na podstawie Uniona z Active i Inbound Table. Ekstrakcja następuje z Active Table (full) i Inbound Table (full, delta).
Planning (BW 7.5 only)
Jest to jedyne aDSO, do którego dane są od razu ładowane do Active Table przez DTP-y lub API. Raportowanie i ekstrakcja odbywają się na poziomie Active Table.
Cechy aDSO
Na koniec chciałbym przedstawić kilka kilka kluczowych cech aDSO:
- Advanced DSO jest obiektem, który fizycznie przechowuje dane transakcyjne.
- Może być modelowane za pomocą pól, infoobiektów, a także w sposób mieszany.
- aDSO jest modelowane w Eclipse-based SAP BW Modelling Tools.
- Może zawierać maksymalnie 120 pól kluczowych (zarówno pól jak i infoobiektów).
- aDSO jest fizyczną warstwą dla Open ODS View.
- Wspiera partycjonowanie oraz indeksy tam, gdzie występują problemy z wydajnością.
- Umożliwia wygenerowanie SAP HANA View.
Podsumowanie
aDSO w systemie BW4/HANA przejęło funkcjonalność 4 innych, różniących się od siebie obiektów, zaczynając od prostej tabeli i kończąc na schemacie gwiazdy. Owszem – można zbudować model całkowicie wirtualny, ale bardzo często potrzeby raportowe wymuszają materializację danych właśnie w takich obiektach jak aDSO, zwłaszcza gdy mamy do czynienia z dużą liczbą danych transakcyjnych.
***
Jeśli chcesz dowiedzieć się więcej o SAP-ie, polecamy inne artykuły naszych ekspertów np.:
- Route train w SAP EWM,
- Custom code migration to S4HANA – consolidated information about ABAP’er role,
- Programista SAP – jak zacząć karierę Developera?,
- Metody oraz najlepsze praktyki integracji SAP z systemami zewnętrznymi.
Zostaw komentarz