Część druga, to opis platform i systemów z obszaru przetwarzania danych, budowy aplikacji i raportowania. Będzie o HANA, XS(A), SAP BW, Cloud Platform i pokrewnych rozwiązaniach, oraz ich wzajemnych zależnościach.
Spis treści:
- SAP HANA Cloud Platform (HCP) vs. SAP Cloud Platform
- Środowiska i narzędzia deweloperskie (/administracyjne)
- Cloud czy on-premise
- SAP HANA Studio/Eclipse
- Rodzina narzędzi typu Web IDE
- SAP Web IDE
- SAP HANA Web-based Development Workbench
- SAP Web IDE for HANA
- SAP Web IDE Full-stack
- SAP Design Studio (oraz SAP Lumira, SAP Lumira Discovery, SAP Lumira Designer)
- Źródła
- HANA vs. HANA DB vs. HANA Platform
- Źródła
- XS vs. XSA/HDI
- Wstęp
- Extended Application Services Classic (XS lub XSC)
- Extended Application Services Advanced (XSA) + HDI
- HDI (HANA Deployment Infrastucture)
- Cloud Foundry
- Źródła
- S/4HANA, C/4HANA, BW/4HANA (x/4HANA)
- SAP BW
- Źródła
- BW on HANA, BW powered by HANA, BW/4HANA
- Źródła (i auto-źródła)
- Embedded BW
- Źródła
- S/4HANA Embedded Analytics
- Virtual Data Model (VDM)
- HANA Native Views (HANA Views, HANA Information Views)
- Attribute View
- Analytic View
- Calculation View
- SAP HANA Live
- SAP HANA Live Browser
- Źródła
- Core Data Services (CDS)
- Wstęp
- ABAP CDS vs. HANA CDS
- Źródła
5. HANA vs. HANA DB vs. HANA Platform
Używając nazwy HANA trzeba uważać, czy jasno wynika z kontekstu, o co chodzi. Jest HANA DB (database services), czyli baza danych in-memory, oraz nieco szersze pojęcie – HANA Platform (application & analytic services, database services, integration services), czyli HANA DB + otoczka różnych dodatków dokoła. HANA Platform ma być produktem samowystarczalnym, który zapewnia większość potrzebnych usług do działania aplikacji biznesowych i nie tylko. Jest też HANA Appliance, termin ten odnosi się do części sprzętowej, na której HANA jest uruchomiona.
5.1. Źródła
- Is HANA database or platform (or both)? https://archive.sap.com/discussions/thread/3719459
- What is in SAP HANA Platform Today? https://blogs.saphana.com/2015/04/28/sap-hana-platform-today/
- SAP HANA Platform Overview https://www.sap.com/documents/2016/08/9c45fc75-847c-0010-82c7-eda71af511fa.html
- Feature Scope Description for SAP HANA https://help.sap.com/viewer/de855a01ee2248dfb139088793f8802a/2.0.03/en-US
6. XS vs. XSA/HDI
6.1. Wstęp
Extended Application Services jest rozszerzeniem platformy HANA o możliwość tworzenia i uruchamiania aplikacji typu full-stack (UI, server-side logic, database services) – w konfrontacji z możliwościami samej bazy danych, gdzie część aplikacyjna musiałaby być tworzona i hostowana z wykorzystaniem oddzielnego serwera. Wiąże się to z implementacją/obsługą w obrębie platformy serwera aplikacyjnego/webowego, który procesowałby logikę i komunikował się z użytkownikami oraz bazą. Dzięki temu, możliwe jest tworzenie tzw. natywnych aplikacji HANA – w całości obsługiwanych w obrębie jednej platformy.
6.2. Extended Application Services Classic (XS lub XSC)
Jest to rozszerzenie architektury HANA Platform o serwer aplikacyjno-webowy, umożliwiający obsługę skryptów server-side w języku JavaScript, procesowanych przez XS Engine. Architektura XS pojawiła się wraz z HANA 1.0 SPS05, od wersji HANA 1.0 SPS11 współistnieje z XSA, natomiast od wersji SAP HANA 2.0 SPS02 jest oznaczona jako deprecated (niezalecana/przestarzała) na rzecz XSA.
Poniżej kilka schematów dotyczących XS:
6.3. Extended Application Services Advanced (XSA) + HDI
(Poniższa treść w dużej mierze czerpie z artykułu.)
Architektura XSA/HDI pojawiła się w wersji SAP HANA 1.0 SPS11 (on-premise). XSA przyświeca kilka celów:
- unifikacja architektury środowisk on-premise i cloud
- adaptacja koncepcji Cloud Foundry, czyli:
- elastyczne podejście do tworzenia aplikacji
- większy (rozszerzalny) wybór środowisk uruchomieniowych i deweloperskich
- skalowalność
XSA (on-premise) jest implementacją kluczowych konceptów i funkcji Cloud Foundry.
For the on premise delivery of SAP HANA, we felt that delivering the complete Cloud Foundry technical stack was too much. Therefore we have created our own implementation of the Cloud Foundry APIs as XS Advanced in the on premise HANA delivery in SPS 11. This means that the core concepts of Cloud Foundry will be present in both SAP HANA on premise and in SAP HANA Cloud Platform. (link)
Wraz z XSA pojawia się kilka dodatkowych możliwości, jeżeli chodzi o aplikacje serwerowe. Poza środowiskiem JavaScript, uruchamianym na XS Engine (XSJS), pojawiła się opcja korzystania z Node.js. Pojawiła się również możliwość implementacji rozwiązań bazujących na:
- Apache TomEE Java
- Google V8 JavaScript/Node.js
oraz aplikacji C++ (zastosowania wewnętrzne SAP oraz limitowany dostęp dla partnerów).
Jednym z głównych benefitów korzystania z XSA, na rzecz XS jest możliwość operowania w architekturze mikrousług (microservices).
W XS działa pojedynczy proces systemowy nazywany XSEngine. W ramach tego procesu, tworzona jest pula maszyn wirtualnych JavaScript (JS VM), które są klonami tej samej wersji bazowej. Nie ma możliwości kontroli wersji JS, na której aplikacja działa, ani konfiguracji parametrów (np. pamięci) dla każdej z osobna. Dodatkowo, w związku z tym, iż wszystkie maszyny wirtualne działają w obrębie tego samego procesu systemu operacyjnego (XSEngine), jest między nimi duża zależność i podatność na awarię.
W architekturze XSA, bazującej na Cloud Foundry, (mikro)usługa uruchamiana na platformie, wraz z właściwym środowiskiem uruchomieniowym (możliwe różne wersje działające równolegle) stanowią „izolowany byt”. Każda z usług to oddzielny proces systemowy, skalowalny pod kątem wykorzystywanych zasobów. Dzięki tym zabiegom, osiągnięto większą elastyczność, stabilność i niezawodność.
Co więcej, w XSA nastąpiło znacznie rozluźnienie powiązania pomiędzy aplikacją a bazą HANA. W XS obiekty typu design-time przetrzymywane są bezpośrednio w HANA Repository, czyli skojarzone z konkretną, jedną instancją HANA, na której też są deployowane (do obiektów run-time). W XS obiekty design-time przechowywane są w pakietach i subpakietach repozytorium HANA. W XSA projekt i jego obiekty design-time są przechowywane niezależnie od bazy HANA w centralnym repozytorium, np. git. Dopiero w momencie deploymentu trafia do środowiska docelowego, do kontenera HDI.
6.4. HDI (HANA Deployment Infrastucture)
W XSA pojawia się termin HDI, czyli HANA Deployment Infrastructure oraz związany z nią kontener HDI. An HDI container is a database schema of the SAP HANA database for HDI objects (link). W HDI istnieją 2 światy: design-time oraz run-time. Bazując na definicjach design-time (a konkretnie tych z modułu HDB w projekcie XSA), w kontenerze HDI generowane są wszystkie obiekty bazodanowe run-time. Zaletą tego podejścia jest lifecycle management (tworzenie, aktualizacja, usuwanie) obiektów w kontenerze przez HDI. Dzięki temu, że robi to system, obiekty są spójne i optymalnie skonstruowane do pracy na bazie HANA. Kontener HDI posiada dedykowanego użytkownika technicznego, który komunikuje się z bazą. Dzięki izolacji za pomocą kontenerów HDI, możliwy jest wielokrotny deployment tej samej aplikacji.
XSA może być instalowane na innym hoście niż baza HANA. Daje to możliwość niezależnego skalowania obu rozwiązań, na przykład poprzez implementację wielu node’ów XSA na słabszej (tańszej) architekturze, w stosunku do bardziej wymagającego hosta HANA.
6.5. Cloud Foundry
Cloud Foundry jest standardem open source, wspieranym m.in. przez Cisco, Google, IBM, Microsoft, Pivotal, SAP, SUSE. Jest to architektura implementacji rozwiązań w chmurze, mająca na celu zapewnienie elastyczności na wielu płaszczyznach oraz skalowalności. Dzięki CF możliwe jest tworzenie i uruchamianie aplikacji (np. prototypów) w szybki sposób, bez konieczności ponoszenia kosztu budowy i utrzymania całego stosu technologicznego (serwerów, sieci, etc.), a następnie przeskalowania ich według potrzeb.
6.6. Źródła
- openSAP: Introduction to Software Development on SAP HANA (Repeat) https://open.sap.com/courses/hana1-1/items/W3MITTiLjhj7JVgrHwTZ6
- SAP HANA Extended Application Services (XS, SPS05) https://blogs.sap.com/2012/11/29/sap-hana-extended-application-services/
- SAP HANA Extended Application Services (XS) https://archive.sap.com/documents/docs/DOC-60322
- SAP HANA Developer Guide https://help.sap.com/doc/PRODUCTION/fbb802faa34440b39a5b6e3814c6d3b5/2.0.00/en-US/SAP_HANA_Developer_Guide_for_SAP_HANA_Studio_en.pdf
- SAP HANA SPS 11: New Developer Features; XS Advanced https://blogs.sap.com/2015/12/08/sap-hana-sps-11-new-developer-features-xs-advanced/
- General Availability of the XS Advanced Programming Model with Cloud Foundry on SAP Cloud Platform https://blogs.sap.com/2017/05/16/general-availability-of-the-xs-advanced-programming-model-with-cloud-foundry-on-sap-cloud-platform/
- HANA 2.0 SPS02 Deprecated Features https://help.sap.com/viewer/42668af650f84f9384a3337bcd373692/2.0.02/en-US/6c63b22412d04b5d9fbe46ab39b7939d.html
- SAP Cloud Platform – A positive-sum game https://blogs.sap.com/2017/05/16/sap-cloud-platform-a-positive-sum-game/
- Cloud Foundry https://docs.cloudfoundry.org/concepts/overview.html
- HDB modeling in WebIDE – and why we are staying in HANA Studio for the time being https://blogs.sap.com/2018/06/15/hdb-modeling-in-webide-and-why-we-are-staying-in-hana-studio-for-the-time-being/
- SAP HANA SPS 12: New Developer Features; Database Development http://www.sapspot.com/sap-hana-sps-12-new-developer-features-database-development/
7. S/4HANA, C/4HANA, BW/4HANA (x/4HANA)
Nazwy x/4HANA wskazują na systemy nowej generacji, które zostały zoptymalizowane do pracy na HANA DB i mogą operować jedynie na tej bazie.
8. SAP BW
Business Warehouse (BW), czyli wersja hurtowni danych (data warehouse) według SAP.
Można patrzeć na BW jak na system, który realizuje dwie główne funkcje:
- Baza danych – przechowywanie danych operacyjnych przedsiębiorstwa (i nie tylko – również innych danych, które niosą ze sobą wartościowe dla firmy informacje), zarówno obecnych jak i historycznych
- Zarządzanie danymi
- Zarządzanie procesem pozyskiwania i transformacji danych – narzędzia ETL
- Data Lifecycle Management, czyli zarządzanie procesem „starzenia się” danych. Dla przykładu, jest to ustalenie wieku, po przekroczeniu którego dane przestają być istotne i mogą zostać usunięte z systemu (1 rok, 5 lat, 10 lat, etc.) lub przesunięte do bazy o mniejszej wydajności i koszcie.
- Harmonizacja, konsolidacja i zapewnianie spójności danych – wszystko w celu zbudowania „jednego źródła danych” (single source of truth). Powyższe terminy, których znaczenia przenikają się, wiążą się z potrzebą zapewnienia jednoznaczności informacji. Dane, które trafiają do hurtowni danych często są bardzo różnej jakości (wprowadzają je użytkownicy lub generowane są automatycznie), pochodzą z różnych systemów (mają różne formaty), regionów (o różnych charakterystykach prawno-gospodarczych), czy też obszarów działalności firmy. Dlatego niezbędne jest czyszczenie danych wejściowych (data cleansing), np. uzupełnienia brakujących informacji. Może być to także transformacja cech i miarek do formatów, dzięki którym możliwe będzie dalsze ich przetwarzanie wraz z analogicznymi danymi ale z innego źródła – i wykorzystanie ich w raportach.
- Modelowanie i udostępnianie danych do celów raportowych. W zasadzie – jest to główny cel hurtowni danych. Dzięki odpowiedniemu przygotowaniu, dane dostarczają informacji o stanie przedsiębiorstwa, zagrożeniach i perspektywach rozwoju, pozwalając na podejmowanie odpowiednich decyzji.
W skrócie: hurtownia danych = ETL + baza danych + aplikacyjna nakładka do zarządzania danymi
Warto podkreślić różnicę pomiędzy systemem transakcyjnym a hurtownią danych. Ten pierwszy jest zoptymalizowany pod kątem „codziennej pracy” – jednostkowych operacji na danych, takich jak wprowadzanie czy modyfikacje. Struktura danych jest wysoce znormalizowana, w celu minimalizacji redundancji (powtarzania się informacji), zmniejszenia objętości danych oraz szybszej realizacji wspomnianych operacji. Przykładem normalizacji jest przechowywanie adresu klienta w osobnej tabeli (1) niż tabela z zamówieniami (2). Dzięki temu informacja klient-adres przechowywana jest tylko raz w tabeli (1) i nie pojawia się wielokrotnie w tabeli (2). Ma to swoje zalety, ale ma również wady – odbudowanie całej struktury informacji (połączenie wszystkich powiązanych tabel) jest czasochłonne. Dlatego w hurtowni dane są zdenormalizowane. Raportowanie jest znacznie szybsze, ponieważ wymaga połączenia ze sobą znacznie mniejszej liczby tabel.
SAP BW historycznie przemierzał liczne ścieżki, obecnie kierunkiem rozwoju jest pełna integracja i wykorzystanie potencjału HANA.
8.1. Źródła
- SAP Business Warehouse https://help.sap.com/viewer/d767e6e0080e488e8800d631c64096dc/7.4.19/en-US/468c635be4c70ad3e10000000a11466f.html
9. BW on HANA, BW powered by HANA, BW/4HANA
BW on HANA i BW powered by HANA to nazwy tego samego systemu (starsza i nowsza), czyli hurtowni danych stojącej na bazie HANA. Pierwsza wersja BW on HANA to BW 7.3, od tego czasu integracja zwiększała się, a kierunek wyklarował – powstał nowy system BW/4HANA. Wersje BW 7.3-7.5 to wzbogacanie istniejącego już wiele lat systemu BW, natomiast BW/4HANA to kompletnie nowy produkt, który jest HANA-optimized i pracuje tylko z tą bazą. Dodatkowo jest dużo lżejszy, dzięki pozbyciu się licznych fragmentów zapewniających wsteczną kompatybilność.
9.1. Źródła (i auto-źródła):
- The SAP BW Evolution https://blogs.saphana.com/2015/02/24/sap-bw-evolution/
- Overview of SAP History and BW-BI Evolution https://wiki.scn.sap.com/wiki/display/BI/Overview+of+SAP+History+and+BW-BI+Evolution
- BW/4HANA – nowa hurtownia danych SAP łączy ewolucję z rewolucją https://sii.pl/blog/bw-4hana-nowa-hurtownia-danych-sap-laczy-ewolucje-z-rewolucja/
- BW/4HANA – ciąg dalszy (r)ewolucji https://sii.pl/blog/bw-4hana-ciag-dalszy-rewolucji/
10. Embedded BW
Jest to wersja BW, wbudowana w SAP Business Suite (od wersji SAP NetWeaver 7.0 ) i S/4HANA. Głównym zastosowaniem Embedded BW jest wsparcie konkretnych procesów biznesowych, np. planistycznych: Integrated Business Planning for Finance, BPC.
SAP rekomenduje wykorzystanie Embedded BW do standardowych scenariuszy, np. dostarczanych z Business Content.
Embedded BW nie jest zalecane do operowania w pełnym zakresie, w roli EDW. Objętość obsługiwanych danych nie powinna przekraczać 20% całkowitej objętości danych z systemu ERP.
10.1. Źródła
11. S/4HANA Embedded Analytics
Jest to VDM w systemie SAP S/4HANA zbudowany na tabelach danych transakcyjnych z wykorzystaniem ABAP CDS. Embedded Analytics dostarcza gotowe rozwiązania raportowe i narzędzia do przeglądania/wyszukiwania modeli oraz analizy danych z wielu obszarów biznesowych, np. finansów czy zakupów. Jest analogicznym rozwiązaniem do SAP HANA Live, stworzonym jednak w innej technologii.
Zostaw komentarz