9,99 €
Mehr erfahren.
- Herausgeber: Espresso Tutorials
- Kategorie: Wissenschaft und neue Technologien
- Sprache: Englisch
- Veröffentlichungsjahr: 2019
In this book written for SAP BI, big data, and IT architects, the authors expertly provide clear recommendations for building modern analytics architectures running on SAP HANA technologies. Explore integration with big data frameworks and predictive analytics components. Obtain the tools you need to assess possible architecture scenarios and get guidelines for choosing the best option for your organization. Know your options for on-premise, in the cloud, and hybrid solutions. Readers will be guided through SAP BW/4HANA and SAP HANA native data warehouse scenarios, as well as field-tested integration options with big data platforms. Explore migration options and architecture best practices. Consider organizational and procedural changes resulting from the move to a new, up-to-date analytics architecture that supports your data-driven or data-informed organization. By using practical examples, tips, and screenshots, this book explores:
- SAP HANA and SAP BW/4HANA architecture concepts
- Predictive Analytics and Big Data component integration
- Recommendations for a sustainable, future-proof analytics solutions
- Organizational impact and change management
Das E-Book können Sie in Legimi-Apps oder einer beliebigen App lesen, die das folgende Format unterstützen:
Seitenzahl: 306
Ähnliche
Dominique AlfermannStefan Hartmann
Practical Guide to SAP® HANA and Big Data Analytics
Dominique Alfermann, Stefan HartmannPractical Guide to SAP® HANA and Big Data Analytics
ISBN:978-3-96012-864-9 (E-Pub)
Editor:Karen Schoch
Cover Design:Philip Esch
Cover Photo:belov1409, #103708329 — stock.adobe.com
Interior Book Design:Johann-Christian Hanke
All rights reserved.
1st Edition 2018, Gleichen
© 2018 by Espresso Tutorials GmbH
URL: www.espresso-tutorials.com
All rights reserved. Neither this publication nor any part of it may be copied or reproduced in any form or by any means or translated into another language without the prior consent of Espresso Tutorials GmbH, Bahnhofstr. 2, 37130 Gleichen, Germany.
Espresso Tutorials makes no warranties or representations with respect to the content hereof and specifically disclaims any implied warranties of merchantability or fitness for any particular purpose. Espresso Tutorials assumes no responsibility for any errors that may appear in this publication.
FeedbackWe greatly appreciate any kind of feedback you have concerning this book. Please mail us at [email protected].
Table of Contents
Thank you for purchasing this book from Espresso Tutorials!
Like a cup of espresso coffee, Espresso Tutorials SAP books are concise and effective. We know that your time is valuable and we deliver information in a succinct and straightforward manner. It only takes our readers a short amount of time to consume SAP concepts. Our books are well recognized in the industry for leveraging tutorial-style instruction and videos to show you step by step how to successfully work with SAP.
Check out our YouTube channel to watch our videos at https://www.youtube.com/user/EspressoTutorials.
If you are interested in SAP Finance and Controlling, join us at http://www.fico-forum.com/forum2/ to get your SAP questions answered and contribute to discussions.
Related titles from Espresso Tutorials:
Rob Frye, Joe Darlak, Dr. Bjarne Berg:
The SAP
®
BW to HANA Migration Handbook
Dominique Alfermann, Stefan Hartmann, Benedikt Engel:
SAP
®
HANA Advanced Modeling
Christian Savelli:
SAP
®
BW on SAP HANA
Deepa Rawat:
Practical Guide to Advanced DSOs in SAP
®
Frank Riesner, Klaus-Peter Sauer:
SAP
®
BW/4HANA and BW on HANA
Bert Vanstechelman:
The SAP
®
HANA Implementation Guide
Foreword
In today’s world, technologies are evolving at an extraordinary pace and new market opportunities are developing just as quickly. Companies face the challenge of adapting to unfamiliar technologies and markets with different rules and key players. While businesses adapt, IT departments face similar struggles with constantly changing business requirements and new technologies. In these hectic times, it is essential to have a good business intelligence foundation in order to keep track of both new and existing business.
SAP is one of the big players in business software and is currently developing new products and promoting new product suites at a speed previously unknown to most customers. Additionally, traditional SAP-based companies now need to combine their SAP systems with non-SAP-based software more than ever before, e.g. in the context of Big Data. New possibilities to maintain and provide company software, such as cloud platforms make architecture decisions more complicated, but also enable new business scenarios. The complexity lies in understanding the different architecture possibilities and deciding on the best option for your company.
This book aims to deliver clear recommendations for building a solid architecture based on the latest SAP HANA technologies; with an additional focus on the combination with Big Data platforms. We provide a detailed assessment of several possible architecture scenarios, a guideline on how to decide on one option or another, principles for processes, and the organization around such an architecture.
The target audience of this book is mainly SAP BI and Big Data architects, as well as IT architects. However, we welcome anyone else to dive with us into the wide world of SAP HANA BI opportunities. Readers should have a fundamental understanding of how a data warehouse functions, and the associated technologies, as well as a familiarity with Big Data environments.
Personal dedication
This book is the result of a great deal of encouragement, support and contribution from friends, families, and colleagues. Their numerous ideas, hints, and discussions helped us to greatly enrich each chapter. We would specifically like to mention Bikas Panigrahi who provided valuable input during the course of writing this book.
Last but not least, we want to say thank you to the Espresso Tutorials team, especially to Alice Adams, who patiently advised us in formalizing and completing the book.
We have added a few icons to highlight important information. These include:
Tip
Tips highlight information that provides more details about the subject being described and/or additional background information.
Example
Examples help illustrate a topic better by relating it to real world scenarios.
Attention
Attention notices highlight information that you should be aware of when you go through the examples in this book on your own.
Finally, a note concerning the copyright: all screenshots printed in this book are the copyright of SAP SE. All rights are reserved by SAP SE. Copyright pertains to all SAP images in this publication. For the sake of simplicity, we do not mention this specifically underneath every screenshot.
1 Introduction
In this chapter, we highlight the reasons for writing this book and we explain the scope and content. We conclude the chapter by defining frequently used terms.
1.1 Intention
A key element for successful company management is a solid Business Intelligence (BI) solution, including a constant, up-to-date and holistic view of all business processes. A comprehensive BI platform provides decision makers at all levels of management with crucial reports and analyses for evaluating the current state of their organization, specifically the area they are responsible for. The underlying data basis has changed significantly in recent years. At the beginning, intra-company data was loaded via batch processing on a nightly basis. Now, BI (according to the definition in this book) includes external data, the processing of data in real-time, on-the-fly calculation of statistical models, and quick, user-friendly, well-defined reports; all with only a few clicks.
This evolution stems mostly from technical capabilities created by large-scale, in-memory computing, volume and velocity provided by distributed computing clusters, scalability, and advancements in UI out-of-the-box solutions. These technological developments have led to completely new business models, such as social media platforms, and cloud providers, and also to new technical solutions such as Big Data platforms, sensor analytics and real-time reporting. With these technical developments, you have the possibility for a much more elaborate business process analysis, also taking external information into account.
Suddenly, companies have the ability to tap into large social networks, delivering product opinions and trends on a scale never seen before. Weather data can be constantly evaluated in order to calculate better transport routes in logistics, or take storms and earthquakes into account for business and risk calculations.
However, in order to fully benefit from these new BI opportunities, you need a solid technical foundation together with a pervasive organizational change management within the company. Several questions need to be answered and decisions have to be made:
Which technologies are best used within my company in order to reap all the described benefits?
How do these technologies integrate in a consistent manner?
What architectural principles should be followed during implementation, especially with a combination of technologies?
How do I have to adapt my organization to fully leverage the capabilities of these new technologies?
These are just some examples of the fundamental questions that you need to address. Today, many vendors supply tools for comprehensive BI reporting and analysis, as well as for Big Data and in-memory computing. One of the vendors providing a consistent, integrated BI solution is SAP. Their portfolio, originally only simple SAP BW technology, has been significantly expanded over recent years. You now find new and improved products for reporting (e.g. SAP Lumira, Analysis for Office, SAP Design Studios etc.), for in-memory computing (e.g. SAP HANA), for predictive analytics (e.g. SAP Predictive Analytics suite), and for data warehousing and Extraction, Transformation and Load (ETL) operations (e.g. SAP BW, SAP Data Services etc.). In addition, connectors to Big Data environments have been continuously enhanced.
In this book, we provide a clear view of the latest technology trends in the SAP-based BI area, especially in conjunction with non-SAP Big Data technologies. Building on our project and lab experience, we give answers and recommendations on how various technological components can be combined in the most efficient and architecturally sound way in order to fulfill your company’s analytics needs.
1.2 Objective
Our goal in this book is to provide clear recommendations for building a solid architecture based on the latest SAP HANA technologies; combination with Big Data platforms included. We provide a detailed assessment of several possible architecture scenarios, a guideline on how to decide on one or the other, principles for processes, and the organization around such architecture.
1.3 Target audience
This book is aimed at SAP BI and Big Data architects, as well as IT personnel responsible for future-proof analytics solutions; but anyone is welcome to dive with us into the wide world of SAP HANA BI opportunities. Readers should have a fundamental understanding of how a data warehouse functions, and its associated technologies, as well as the technologies related to Big Data environments.
1.4 In scope/out of scope
This publication aims to establish a solid decision basis for your company’s SAP HANA-based BI architecture by providing recommendations and best practices following the latest SAP product and technology trends. These recommendations include:
general architecture scenarios consisting of an SAP HANA native data warehouse, an SAP BW/4HANA data warehouse (including SAP S/4HANA Embedded Analytics), a Big Data platform with a focus on SAP integrative use cases, an Advanced Analytics solution, and mixed scenarios;
individual architecture scenarios with a mix of the above-mentioned solution components;
a decision matrix to assist in selecting the best architecture components and how to reach this decision, and
structuring your organization and its processes in order to facilitate the breadth and complexity of your technical architecture with the different components.
The recommendations for the defined scope result from project experience, lab sessions, and the authors’ extensive work with these technologies.
This book does not cover non-SAP-based data warehouse solutions (excluding Big Data-based solutions), or detailed front-end integration evaluation. We focus purely on the latest SAP technologies and specifically exclude outdated SAP BW objects (such as InfoCube), SAP HANA 1.0 attribute and analytical views, and SAP ERP/Suite on HANA with SAP HANA Live.
1.5 Content
This book is organized in a logical sequence to help you explore the various architecture options, associated technologies and organizational principles related to SAP HANA BI architectures. We begin with an overview of relevant architectural elements and technologies in SAP HANA BI and Big Data platforms (in conjunction with SAP HANA). Next, we build on these elements by combining them with possible architectural scenarios and options. This includes a decision matrix of how to find the right scenario for your individual needs. Finally, based on the new technologies and architectures relevant for your individual needs, we look at the impact on your organization itself, and the related processes. We close with an overall summary and an overview of further topics resulting from the points covered in this book.
Let us have a brief look at the chapter content.
Chapter 2 looks at the latest technologies used within an SAP-based BI Architecture. As the core element of any current SAP data warehouse architecture is SAP HANA, we named the chapter accordingly. It contains core SAP HANA features and introduces the reader to the latest Big Data technologies and to the current SAP HANA-based integration possibilities with Big Data environments. We continue by explaining possible cloud scenarios and service models before we switch over to the possible front-end tools that operate with SAP and Big Data platforms. The last part of this chapter looks at the various solutions available for ETL in its different forms for Big Data platforms, as well as for data warehouses.
Chapter 3 combines the components presented in Chapter 2 and merges them into solid architectural scenarios. Determining which scenario best fits your individual needs depends on your previously identified requirements. The first section of this chapter discusses details of an SAP BW/4HANA-based architecture scenario. We continue with an SAP HANA native scenario, describing the advantages and challenges when implementing an SAP HANA native data warehouse. These two sections lead to a detailed discussion on how SAP HANA can most efficiently be merged with a Big Data platform. In addition, we focus on predictive analytics platforms utilizing the SAP HANA database and cloud implementations for all scenarios. We finish with best practices for a migration and a decision matrix, as well as best practices for deciding on the right architecture scenario.
Chapter 4 continues with organizational and procedural changes resulting from the move to a new BI architecture. We introduce the topic of landscape enablement, which includes subjects such as sizing, BI roadmap visioning, interfaces, and components. The next section moves into the area of governance, especially Data Governance with its required roles, responsibilities, and processes. Next, we discuss parallel development in a highly integrated environment, end-to-end testing, and debugging. We conclude with recommendations for security, authorization, and change processes, including training approaches for your existing team.
Chapter 5 provides a summary of the previous chapters and takes a look at further topics that should be investigated. We also outline what we see next on the horizon for SAP HANA BI eco systems. This chapter specifically refers to the latest SAP developments; e.g. SAP Leonardo and SAP Data Hub.
1.6 Definition of terms
Most of our technological terms are explained in Chapter 2, but there are additional, fundamental terms that we outline here.
Let us start with Business Intelligence (BI). Within the context of this book, BI is defined as all methods for gathering, analyzing, evaluating and reporting data. Furthermore, we view Big Data platforms, used for data analysis, as part of Business Intelligence. For the purposes of this book, the term Business Intelligence includes all technologies related to data gathering, analysis and evaluation.
As part of BI, data warehouses are data storage platforms, optimized for the analysis of structured data which has been gathered from several sources. They usually combine data in order to fulfill individual reporting needs.
The term Extraction, Transformation and Loading (ETL) describes processes used for gathering data from several sources and writing them into a platform optimized for reporting. As the term implies, data is extracted from a source system, transformed and enriched with additional information, and then loaded into the target system. In recent years, especially with in-memory and Big Data platforms becoming more popular, the term has been slightly changed to ELT (Extract, Load, Transform). This involves the same processes, but in a different order, resulting in a better use of power in in-memory and Big Data environments for the execution of transformations with massive amounts of data.
Finally, the most important explanations in this book are for the terms BI architecture and architecture scenarios. We define architecture as an overall framework, which provides standards and policies to structure BI tools and associated developments, thereby helping to define the mainstays of your future BI ecosystem. We specifically exclude infrastructure requirements from this term, as it is not the focus of this book. We define architectural options for SAP HANA BI-related scenarios as individual options for fulfilling your specific reporting needs. In doing so, we introduce solid architectures while combining selected tools and technologies. In the best case, a described scenario can cover all your reporting or analysis requirements without requiring further tools and technologies.
2 Building blocks of an SAP HANA architecture
This chapter introduces you to the specific building blocks of the architecture scenarios that we explore and use for our architectural discussions throughout this book. We present you with SAP-specific technology and tools, as well as non-SAP tools that we believe fit well into a modern overall BI architecture. Each section provides an explanation of the tools, recommendations for their usage and further information.
Overview of SAP HANA related tools
Below, we provide an overview of the tools we discuss in this chapter, and give links to information on technologies that are relevant for architectural (SAP HANA) designs.
SAP HANA core features
SAP HANA server-side components
The components of an SAP HANA server such as index, name, statistic server, etc.
See SAP HANA Advanced Modeling
SAP HANA engines
Similar functionalities are bundled into engines
See Section 2.1.2
SAP HANA rules framework
Business rules can be defined by the end user
https://blogs.sap.com/2016/12/19/hana-rules-framework-hrf-blog-of-blogs
Extended applications services advanced (XSA)
The XSA engine sustains several SAP HANA internal applications and also builds the basis for web apps
See Section 2.1.3
SAP HANA deployment infrastructure
HDI uses containers to package functionality into one single application
See Section 2.1.4
SAP HANA Views
SAP HANA views are used to combine data for reporting
See Section 2.1.5
Libraries (PAL, BFL, AFL, etc.)
Libraries represent standard functionality that can be reused within SAP HANA
See Section 2.1.6
Building your SAP HANA BI architecture
Big Data technologies
Tools for managing and running a Big Data platform
See Section 2.7
Predictive analytics tools
Tools used for finding patterns in, and making predictions on, the data
See Section 2.4
SAP BO/HANA in the cloud
Using cloud computing for running SAP HANA and SAP BusinessObjects
See Section 2.8
Front-end tools
Tools for the visualization and reporting of data (e.g. SAP Lumira)
See Section 2.6
Data provisioning tools
Tools for the provisioning of data (e.g. SAP Data Services, Kafka, etc.)
See Section 2.4
SAP BW/4HANA
SAP data warehousing component running only on SAP HANA
See Section 2.3
Around SAP HANA BI architectures
SAP S/4HANA
New operational system for different Lines of Business optimized for SAP HANA
See Section 2.2
SAPS/4HANA Embedded Analytics
Operational reporting component for S/4HANA modules only
See Section 2.2
SAP HANA dynamic tiering
Support of the data temperature concept including storage via Big Data
https://blogs.sap.com/2018/04/18/whats-new-sap-hana-dynamic-tiering-2.0-sp-03
SAP Edge Services
Internet of Things (IoT) data collection at the point of creation instead of at a central SAP HANA server
https://www.sap.com/products/edge-services.html
SAP HANA Data Warehousing Foundation
Manage data and memory efficiently across the application landscape
https://blogs.sap.com/2015/03/04/sap-hana-data-warehousing-foundation/
SAP HANA real-time replication
Real-time replication based on the SAP Landscape Transformation Replication Server (SLT)
https://blogs.sap.com/2017/02/01/sap-hana-2.0-editions-and-options-by-the-sap-hana-academy/
SAP Business Suite on HANA
SAP modules running on SAP HANA, not yet on S/4HANA
https://blogs.saphana.com/2014/08/29/the-benefits-of-the-business-suite-on-hana/
Change and Transport System (CTS+) and SAP HANA Transport for ABAP (HTA)
Transport of SAP HANA and ABAP managed objects
A useful guide for these tools can be found here:
https://blogs.sap.com/2015/06/11/cts-or-hta/
Intelligent Enterprise
SAP HANA Analytics plays an essential role, achieving an effective use of data throughout the enterprise
https://www.sap.com/products/intelligent-enterprise.html
Before looking into each component, we will first introduce a high-level view of our reference architecture that is further detailed in Chapter 3. Following this layer architecture, we will look at the essential building blocks of an SAP-centric BI landscape in today’s world (Figure 2.1).
Figure 2.1: Reference layers of a BI landscape
Data generation is the sourcing layer of all data we plan to process in our BI landscape. Looking at the SAP world, SAP S/4HANA is a good example of this. In the data digestion and storage layer, data is processed, pre-calculated and stored for further use. SAP BW/4HANA, SAP HANA native or Big Data technologies provide significant features to implement this layer. Last, but not least, data consumption gives access to the data processed in the previous layers.
2.1 SAP HANA functionalities
This section introduces the SAP HANA related add-ons and features that are the most relevant for designing an SAP HANA-based BI architecture. This specifically excludes data provisioning tools, analytical tools and frontends, which are discussed separately in the following sections.
2.1.1 SAP HANA 2.0
In December 2016, SAP released SAP HANA 2.0—the digital foundation to build the next-generation of analytics applications. In the following section, we highlight selected innovations and new features of this version.
First, let’s start with the migration path. With SAP HANA 1.0 SPS 10 or higher, an upgrade to SAP HANA 2.0 SPS 00 can be performed directly. When migrating from SPS 12, you can test SAP HANA 2.0 SPS 00 with the capture and replay function before migrating. If you run SAP HANA 1.0 SPS 9 or older, you need to upgrade to SAP HANA 1.0 SPS 12 first.
One of the new features in SAP HANA 2.0 is the Active/Active (read-enabled) option, where a secondary SAP HANA system (which is synchronized with the primary through logs) is utilized to take over read-intensive processes. Whereas read and write operations are executed only on the primary SAP HANA system, the second one acts autonomously in answering queries (read operations).
Active/Active (read-enabled) option—SAP S/4HANA case
A good example of an SAP S/4HANA system (see Section 2.2.1) which uses the Active / Active read-enabled option can be found at: https://blogs.sap.com/2017/06/22/making-use-of-an-activeactive-read-only-hana-database-in-s4-hana/
Furthermore, and especially against the background of General Data Protection Regulation (GDPR) in Europe, data security and authorization management (e.g. on LDAP groups) has improved. New encryption features have been released (e.g. full native data at rest encryption, enhanced encryption key management).
Workload management helps SAP HANA 2.0 to better avoid system-overload situations. Requests can be automatically rejected from the database when a threshold is exceeded.
With regard to data integration features, the Smart data integration (SDI), Smart data quality, and Smart data access components have been enhanced. For instance, SDI now allows virtual procedures (e.g. via BAPI) to perform read/write operations with ABAP-based systems.
In the streaming area, messages are now guaranteed via REST interface. In a real-time analysis scenario, data delivery is now ensured. New adaptors like oDATA and JSON enable greater flexibility.
Regarding administration, SAP HANA Cockpit has been re-architected and now also supports on-premise and cloud implementations. Database management has been unified.
There are many other changes and features available with SAP HANA SPS 00; for example, new solutions, improvements, and component reforms relating to Workload Capture and Replay, Backup and Recovery, SAP Enterprise Architecture Designer (Edition for SAP HANA), Dynamic Tiering, Predictive Analytics Library, High Availability and the SAP HANA Extended Application Services (see also Section 2.1.3).
SAP HANA 2.0 features
The following blog offers a good starting point to identify the major changes, which come with SAP HANA 2.0 SPS 00: https://blogs.sap.com/2016/12/01/whats-new-with-sap-hana-2.0-sps-00-by-the-sap-hana-academy/.
New support packages and stacks (SPS) for SAP HANA 2.0 are released twice a year, and the latest information and updates are available at: https://www.sap.com/products/hana/features/whats-new.html.
2.1.2 SAP HANA engines
The engines within SAP HANA build the foundation for any application running on the SAP HANA platform. The development of the SAP HANA engines started with the first SAP HANA revision and continuously evolved during further revisions. SAP HANA started out with the following engines: join, calculation, SQL, Online Analytical Processing (OLAP), row, column and XS. The importance of these engines, as well as the engines themselves, has gradually changed. From a definition perspective, it is hard to say what exactly constitutes an engine. When reading different lists of the SAP HANA platform features, further engines are mentioned. These include the spatial, the graph, and the planning engines; and depending on the definition of “engine”, we could even say there is a “predictive” engine. We will take a closer look at the SQL engine in the following section. Further detail about the predictive and spatial options can be found in Section 2.4.
The SAP HANA engines
For detailed information on the SAP HANA engines, we recommend reading our book SAP HANA Advanced Modeling.
Important functionalities of SAP HANA are the modeling of views, the execution of SQL statements within the database for checking results, and the ability to write more complex programming logic. In these cases, the SQL engine is utilized.
First, we need to take a step back and have a quick look at SAP HANA views. SAP started out by distinguishing attribute, analytical and calculation views in the first Service Packs. In the last two years, we have noticed a clear movement towards using only calculation and scripted SQL views. In addition, SAP has not only been promoting the use of Core Data Services (CDS) views to the customer, but has also been promising to build future extractors and embedded analytics for S/4HANA based on CDS views.
CDS views, like calculation views, are based on SQL. Due to this development, we believe that the SQL engine should be explained in more detail here.
So how does the SQL engine work? The SQL engine does not simply take SQL code and query the referenced objects within it. It combines the statements and optimizes them so that, at the end, one large query is run which has ideally been compiled into a high-performing statement. This enables the author of SQL statements to design easily readable code or views while not having to constantly think about performance. However, be aware that this will not always work, and testing with PlanViz (Plan Visualization) is a mandatory task you need to perform.
PlanViz is an SAP HANA-based tool for analyzing and visualizing the performance and execution structure of queries.
SQL Engine
You can usually rely on an SQL engine to optimize code, and it offers good support for programmers. However, be aware that complex coding requires you to do the optimization yourself because, in these cases, the engine will not always be able to handle the code on its own.
2.1.3 SAP HANA Extended Application Services Advanced (XSA)
The previously-mentioned XS engine has undergone a change with Service Pack 11 and is now known as the XSA engine. The “A” in the XSA stands for “advanced”, and means that the XS engine has now completely switched its code basis and also changed ownership within SAP. Previously, the XS engine only supported JavaScript coding and oData (a data exchange protocol developed by Microsoft). The XS engine could therefore be seen as a lightweight webserver. With the switch to XSA, node.js, Java and C++ coding are now also supported. In this way, the SAP HANA platform has been enhanced and has made the XSA engine a more heavyweight webserver.
SAP HANA 2 BYOL
With SAP HANA 2, the XSA engine now includes the option to Bring Your Own Language (BYOL), which essentially means that any coding is supported. So far, we have not seen that in action, so further testing is required.
Figure 2.2 depicts the XSA engine and its surrounding components. As the figure shows, the main components necessary to build a web application are as follows:
A
database
is needed to store data and to execute changes to the data as requested by the application.
The
web application
itself needs to be coded. This can be done in any language supplied by the XSA engine. Another possibility involves connecting a different webserver and using HANA only as the database.
The third and final component is the
presentation logic
. The borders between control flow and presentation can be very fluid; for example, if you decide to build the web page using traditional client-side JavaScript (XSJS) and SAPUI5, then the code is executed on the client side and only the data exchange between client and server is handled via oData services. A second option consists of only using input from the client side, creating the webpage in HTML5 code, and implementing the more complex application logic on the server side.
Figure 2.2: The SAP HANA XSA architecture foundation
More than just a webserver, the XSA engine is also responsible for rendering the SAP HANA Web modeling workbench. Not only are web-modeling environments for SDI or SAP HANA views run on the XSA engine, but the XSA engine also serves as an interface. It serves as the communication between the actual code execution on the database and the reports generated by the SAP HANA XS scheduler or in the web-based workbench.
Overall, the XSA engine offers a broad range of functionalities to the end user and can be seen as the main platform for any future generation developments by SAP for web-based applications. It is a comprehensive tool for building any SAP-based web applications for your company. The main language used for coding is JavaScript, although other languages are also supported. Two SAP front-end tools use SAPUI5 as a basis for implementing reports or transactions, namely SAP Fiori and SAP Design Studio. In turn, SAPUI5 is based on JavaScript and HTML5 libraries, which then deliver all the necessary functions in order to easily use charts, or form elements (e.g. input fields, tables etc.).
The XSA engine relies very heavily on JavaScript, which is one of its biggest weaknesses. JavaScript was originally designed as a lightweight alternative to Java and could be easily used for client-side code execution and simple functionalities. This included operations such as OnClick (when you click on a text or a picture) or OnMouseOver (when you move your mouse over an element), but it was initially not intended for use in complex logic. This changed over time and now there is a large community supporting node.js as an alternative to Java as a web language. From our perspective, however, the language is still not ready for large-scale web applications.
It is our belief that for large web applications popular web languages such as Java and PHP remain better-suited for server-side code development.
Use of the XSA engine
We recommend using the XSA engine in custom developments for small web sites, such as input forms or small web reports.
We also recommend it for smaller internal reporting sites you might want to build because SAPUI5, together with the XSA engine, clearly represents the foundation for all future SAP developments.
2.1.4 SAP HANA deployment infrastructure
With SAP HANA SP 11, the SAP HANA deployment infrastructure (HDI) has been introduced in a beta version, and was only recommended for productive application development starting with Service Pack 12. It essentially changes the whole development approach in SAP HANA and bases everything on the cloud foundry approach, an industry standard for cloud applications. This means that any application developed in SAP HANA is now also portable to the cloud, with minimal effort. Of course, there is a wide range of features that have to be provided by a platform in order to comply with the cloud foundry framework. Most of these features are delivered directly with the SAP HANA platform; however, some need to be customized by the development team responsible for an application.
One of these features is the concept of the SAP HANA deployment infrastructure. The SAP HANA deployment infrastructure provides containers which need to be used in order to develop an application; however, this only applies to database objects. Any client-side JavaScript code and oData service is still activated in the usual way. A significant change is that, within this container, all SAP HANA objects required to run an application are now created with container-specific schemas. Information that used to be shared across developments is now specifically stored within the schemas of a container (e.g. metadata for views or stored procedures).
This has two main impacts:
Security impacts:
Security is much better than in previous applications because the applications are separate from one another (at least if the containers are used as intended). This is due to a strict segregation of applications resulting in separate access to applications. This also means that, across applications, privileges cannot be reused as easily as before.
Decentralization:
Because applications are now segregated, some metadata is now in decentralized storage. On one hand, this can be helpful because administrators might not have to search through endless lines in tables to find specific objects. On the other hand, this can have a negative effect if administrators need to search longer for root causes, especially when the root cause is due to the parallel actions of two applications.
Furthermore, the containers can separate design time and runtime. The design-time container lets the user define which database object types (e.g. procedures, tables, etc.), in which database version (e.g. Service Pack 11), should be included in a deployment scenario. The defined database version is backward compatible, meaning that if objects were developed in a later Service Pack, they could still be deployed in the Service Pack 11 environment, but not the other way around.
The runtime container lets the developer specify the syntax for naming the runtime objects created.
Example of a runtime naming convention
An application is named ExampleApp, the procedure file is called ExProc and the subfolder in which this application is stored is named ProcFolder. The namespace file can then define whether the runtime object will be generated as: ExampleApp.ProcFolder::ExProc or as ExampleApp::ExProc
All in all, it makes sense to use containers in structuring new developments. This has been a trend in other recent development environments. In addition, it makes the deployment of applications easier. However, any issues in design objects can lead to problems in deployment. This can be particularly problematic if several developers are working in parallel on one container.
HANA deployment infrastructure
The HANA deployment infrastructure makes SAP HANA database applications much more secure. Therefore, we recommend using HDI for any future developments. For a very good example of HDI works, please visit the following webpage: https://blogs.sap.com/2015/12/08/sap-hana-sps-11-new-developer-features-hdi/
2.1.5 SAP HANA views
SAP HANA views are one of the many innovations that come with the platform. They deliver an easy way to merge data from several tables and to perform operations on this data. They mainly rely on drag and drop modeling, especially with calculation views. So, let’s look first at the history and development of these views.
The construct foundation of SAP HANA views has changed dramatically with the SAP HANA platform developments over the last few years. SAP started out with attribute, analytical and calculation views. In our previous book SAP HANA Advanced Modeling, we recommended only using calculation views, but this endorsement of calculation views has changed with the latest releases.
SAP S/4HANA has been the more recent focus of SAP’s development with regard to ERP and operations. Due to the new strategic orientation, changes can be found in the way SAP HANA views should be modeled and used going forward. One of these changes is the predicted removal of attribute and analytical views from SAP’s modeling environment with the HANA deployment infrastructure (see Section 2.1.4). More surprising is the elimination of scripted calculation views, which have now been replaced with SQLScript functions. In itself, this does not represent any functionality change, but it does show the general orientation of SAP towards a more SQL-based modeling in the entire SAP HANA database.
Furthermore, with SAP S/4HANA, SAP pushes the use of CDS views, and HDI itself only leverages CDS built table structures; this again underlines the move towards a more code-oriented infrastructure
Figure 2.3 shows the change in the modeling of SAP HANA views from earlier versions to the latest releases.
Figure 2.3: Change in SAP HANA modeling
This change in optimal modeling highlights the difficulties for SAP customers when deciding on the correct path for future applications. However, for agile developments and an easy combination of data for testing purposes, we still believe that SAP HANA views are the best option.
Calculation views in particular currently offer a vast range of out-of-the-box functionalities for an effective realization of business value. The drag and drop interface lets a developer quickly assemble all necessary data in order to achieve the desired output. Among the functionality offered for structuring and merging data, these views offer aggregations, projections, filters, rankings, unions, and many other common functions.
