Wyślij zapytanie Dołącz do Sii

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.

Ryc. 2 Warstwy architektury LSA++
Ryc. 2 Warstwy architektury LSA++

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


5/5 ( głosy: 6)
Ocena:
5/5 ( głosy: 6)
Autor
Avatar
Łukasz Moroz

Swoja przygodę z analizą i przetwarzaniem danych rozpoczął w 2014 podczas wykonywania zadań w ramach systemów CCN&B oraz Peoplesoft. Po zakończeniu procesu migracji danych do SAP w 2016 związał się z modułem z SAP PM. Przypadkowo trafił na szkolenie z modelowania danych w HANA i od razu wiedział, że ta tematyka jest właściwą ścieżką kariery. Od 2018 pracuje jako konsultant SAP BW/BI. Interesuje się podróżami i wszelkiego rodzaju aktywnością fizyczną.

Zostaw komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *

Może Cię również zainteresować

Pokaż więcej artykułów

Bądź na bieżąco

Zasubskrybuj naszego bloga i otrzymuj informacje o najnowszych wpisach.

Otrzymaj ofertę

Jeśli chcesz dowiedzieć się więcej na temat oferty Sii, skontaktuj się z nami.

Wyślij zapytanie Wyślij zapytanie

Natalia Competency Center Director

Get an offer

Dołącz do Sii

Znajdź idealną pracę – zapoznaj się z naszą ofertą rekrutacyjną i aplikuj.

Aplikuj Aplikuj

Paweł Process Owner

Join Sii

ZATWIERDŹ

This content is available only in one language version.
You will be redirected to home page.

Are you sure you want to leave this page?