Download presentation
Presentation is loading. Please wait.
1
SAP on Azure Technical Overview
2
Agenda Customer challenges Azure helps address
SAP application evolution Key SAP products supported on Azure SAP Business Suites on AnyDB (SQL, Oracle, DB2 etc) BW or Suites on HANA, S4/HANA Technical deployment for HA DR Migration path to BW/4HANA, S/4HANA
3
Customer challenges Challenges
Traditional server/storage/ network hardware with backup/HA solutions can be costly Dev/Test/QA busy during implementation, go idle after go-live, except QA for trouble shooting Choices of datacenter locations are limited in spite of global user access Challenges Sizing is often difficult and customers realize hardware/hosting vendors oversized after rollout People to run SAP on-premises without automation solutions is the biggest cost factor SAP customers cannot afford having a second datacenter for disaster recovery and tend to rely on old-style tape backup Other technologies are needed when SAP doesn’t meet customer’s analytics/BPM/UX/EAI requirements Azure services for SAP help customers address their challenges they face on a daily basis. SAP landscape is general big including hundreds of servers from DEV, TST, Prod support, and production etc. Also SAP production workload is mission critical to most enterprises who run it, standing up and keeping a DR environment is costly. Azure public cloud become a cost effective and agile solution for these scenarios. Plus people don’t just run SAP but they use other business and productivity solutions like , data analytics etc. Azure has these services to complement the SAP operational data rested in the SAP databases.
4
SAP Application Evolution
S4 HANA ERP NW R/3 R/2 SAP has been around for about 50 years now. Starting its online real time data processing products SAP on R/2. ‘R/2” denotes the two tier architecture running on IBM mainframe with fixed function termals connected to the application/database layer. As computing evolved into client/server distributed computing, SAP architecture advanced into a 3-tiers architecture: database, application, and presentation. With R/3, SAP business application and the technical (SAP Basis) modules are delivered in one collection. Products release become too interdepent that slow innovations. In 2004, SAP split out the technical ‘Basis’ and introduced SAP Netweaver being the platform to run SAP business applications and the integration platform offering web/SOA capabilities on top of others (RFC, SMTP etc). The latest innovation from SAP is the HANA in-memory database with supporting a suites of SAP business functions like Finance, logistics plus other data analytics capabilities including IoT, Mobile etc. 1979 Mainframe 1992 Client/Server 2004 Web/SOA 2015 IoT/API/Mobile
5
SAP NetWeaver Diagram sourced from help.sap.com The application platform for the SAP Business Suite of applications. Superseding SAP's earlier BASIS platform and launched with mySAP ERP 2005, Technical Integration platform with no business logic/functionality
6
SAP Business Suite A family of enterprise applications from SAP that form the core business offerings of the company. Formerly known as the mySAP Business Suite, the primary applications cover Enterprise resource planning (ERP) [Finance, logistics , IS (industry solutions) etc] Customer relationship management (CRM) Product life cycle management (PLM) Supply chain management (SCM) Supplier relationship management (SRM) Reference :
7
Azure infra. for a sample HA SAP system
Azure VNET SIOS DataKeeper for WSFC without need of clustered shared disks SAP App Server – ABAP/Java dual or single stack. Preferred smaller VMs SAP Web Dispatcher installed on Azure VM, performs HTTP(S) load balancing SQL DB with AlwaysOn Availability Group Need to deploy in 3-tiers for HA DR Av. Set 3, WSFC SAP Cen. Serv. Node 1 Azure ILB SAP SCS Cluster VNN SAP Cen.. Serv. Node 2 Av. Set 2 Domain Controller SAP App Server SAP App Server Av. Set Azure VM SAP Web Dispatcher Av. Set 1, WSFC SQL AG A highly available SAP system typically has the above layout min remaining The SCS is protected with Window Server Failover Cluster. The SIOS DataKeeper (3rd party solution) enable the creation of a cluster on Azure without shared disks. SAP Application servers are protected by virtue of multiplicity. The HTTP(S) load balancing is handled by the SAP Web Dispatcher built on an Azure VM. The SAP Logon load balancing is handled by the SCS message server. The DB layer, for SQL Server DB, we use AlwaysOn Availability Group (AG) built on a WSFC leveraging node majority with a file share witness quorum. Sync Commit Azure ILB AG Listener SAP SQL DB WSFC node 1 SAP SQL DB WSFC node 2
8
SAP on Microsoft Azure Microsoft Azure is certified for the following SAP products, with full support from Microsoft and SAP. SAP Product Guest OS RDBMS Azure Offerings SAP Business Suite Windows, SLES, RHEL, Oracle Linux SQL Server, Oracle (Win), DB2, SAP ASE A5-9, D11-D14, DS11-15, DS11-14V2, GS1-5 SAP Business All-in-One SAP NetWeaver App Server SAP HANA Base, Platform, Entr. Editions SLES, RHEL N/A GS5, S72-72m, S m Key SAP certifications listed only. See SAP note for full list and supported OS/DB combo On May 19, 2015, Microsoft and SAP announced the full support of the SAP products list on the right Only NetWeaver 7.00 and later SAP releases of NetWeaver are supported for deployment in Azure Customers can try SAP HANA Developer Edition on Azure using the SAP Cloud Appliance Library. (including the HANA Client software comprised of SQLDBC, ODBO (Windows only), ODBC, AND JDBC drivers), HANA Studio, and HANA Database Oracle Database 11g R2 Patchset 3 ( ), Single Instance SAP Adaptive Server Enterprise 16 On May 17, 2016 at SAPphire Orlando, SAP/Microsoft jointly announced the SAP HANA (Base, Enterprise, and Platform editions) certification on Azure
9
What is SAP HANA? SAP HANA is a modern, in-memory database and platform that is deployable on-premises or in the cloud The SAP HANA platform is a flexible data-source-agnostic in-memory data platform that allows customers to analyze data in real-time It is a development platform The ‘SAP HANA platform’ is the foundation of various SAP HANA editions, like the SAP HANA Platform Edition and and the SAP HANA Enterprise Edition The SAP HANA platform is a flexible data source agnostic in-memory data platform that allows customers to analyze large volumes of data in real-time. It is also a development platform, providing an infrastructure and tools for building high-performance applications based on SAP HANA Extended Application Services (SAP HANA XS). It is the foundation of various SAP HANA editions, like the SAP HANA Platform Edition, providing core database technology, and the SAP HANA Enterprise Edition, bundling additional components for data provisioning. The SAP HANA Platform Edition integrates a number of SAP components, including the SAP HANA database, SAP HANA studio, and SAP HANA clients
10
Diagram sourced from “HANA, ‘the why’ Henry Cook, Jan 2016”
Let’s just recap the history of ERP. Originally SAP ran on the mainframe and ran a single application. Access was via online terminals (a major innovation at that time) and everything was done in real-time. At the time SAP was serving mid-sized German companies. But then they sold to bigger companies, and those companies grew, they needed to deal with “the multi’s”; multi-company, multi-language, multi-currency, multi-application (remember with the mainframe terminals were tied to applications, multiple apps meant multiple terminals) This exceeded the capacity of the mainframe, so SAP made a big leap, with SAP R/3, to a three tier Client Server architecture, splitting the Client Interface, the application logic and the database access across different servers, thus spreading the load. At the same time we now have the newly available PC front ends to access multiple back end applications, instead of having to have one mainframe terminal for each application we needed. In the third step we see how this expanded as new applications were added, some of which SAP wanted to be able to sell on their own without necessarily having the ERP core, and at the same time we could mix and match servers to tune for performance and also to make operations easier. At the top of the diagram we see the appearance of separate management information systems, data marts and ‘spreadmarts’ the proliferation of spreadsheets that are actually being used as operational data marts in the organisation. These were used by organisations to make SAP data available for querying and reporting. Note that where these different applications were sold with ERP –as was usually the case –a subset of the ERP data was replicated within the applications and there would be feedback processes that fed back to ERP too. In the 4th step we see the addition of a dedicated server for the Business Warehouse, to make management information available from SAP applications, but often this didn’t kill off the separate management information systems, in fact many organization used BW as a mechanism to populate separate management information systems. There might also be a separate generic Data Warehouse added, to combine SAP data to non-SAP data at the time it was easier to do this by extracting the SAP data and taking it elsewhere rather than bringing the non-SAP data in (we’ll see that this has changed). More servers are added, more data marts and more redundant copies of data –however remember that by going this route we were able to scale the systems and to optimisefor individual applications, and, at the time there was no alternative given the technology that was available.
11
Innovation Through Simplication
SAP 7-8 years ago Impeded by complexity, large, complex suite of applications 15 month release cycles, SAP was surrounded by increasingly nimble competitors, Dependent upon others for data management, Incurring large development costs SAP’s strategy to get ahead and stay ahead through massive simplification This simplification is what we now know as S/4HANA and BW/4HANA 7-8 years ago SAP found itself in a bit of a bind. The ERP applications were large and complex with 15 month release cycles. SAP was surrounded by competition, many of them increasingly more nimble than us. SAP was dependent on others for data management, some of them major competitors, and all of this complexity incurred great cost. The only way SAP could see out of this would be if they could radically simplify what we did, and this was the objective of the research project that eventually produced HANA. This entailed hundreds of developers working around the clock for 6-7 years –to get to where it is now.
12
SAP HANA then and now Diagram sourced from “HANA, ‘the why’ Henry Cook, Jan 2016”
13
SAP HANA Use-Cases SAP HANA as Primary Persistence for SAP NetWeaver Based Applications SAP HANA as Data Mart SAP HANA-Based Accelerators SAP HANA Data Provisioning SAP HANA as Application and Development Platform SAP HANA Smart Data Access SAP liveCache on SAP HANA 20 min remainig SAP NetWeaver has two distinct aspects, ABAP and Java. Many applications built on SAP NetWeaver’s ABAP and/or Java application servers are able to run “on” SAP HANA, where SAP HANA serves as the sole database in the architecture. With SAP HANA, operational data marts offer real-time analytics and reporting on data replicated from a transactional system’s database. The raw tables themselves are copied (structure and data) from the transactional system’s database into SAP HANA. The SAP Landscape Transformation Replication Server (SLT) is an SAP NetWeaver ABAP-based tool that provides real-time data replication. In addition, a log-based SAP Replication Server (SRS) can also be used to provide real-time data replication SAP HANA-based accelerators are types of applications or scenarios that extend the capabilities of business processes in SAP Business Suite systems by leveraging the performance and scalability advantages that SAP HANA provides. The typical approach for accelerators involves replicating data for data-intensive operations that are often bottlenecks for the given operation in an SAP HANA table. A type of “switch” is then set in the SAP Business Suite application to indicate that whenever these specified tables are read, the read operation will take place in SAP HANA using a secondary database connection SAP HANA is also used as an in-memory data proxy for many source systems leveraging data integration capability of SAP HANA for Data Provisioning SAP HANA provides the basis for an application development platform, where many different types of applications can be built on, and run on, SAP HANA SAP HANA smart data access enables remote data to be accessed as if they were local tables in SAP HANA, without copying the data into SAP HANA SAP liveCache is an in-memory object store technology that is used to speed up material planning scenarios in SAP Supply Chain Management (SCM). It is available as an add-on for SAP HANA
14
SAP HANA Deploy/Operations Models
On-premises (and IaaS) SAP HANA Appliance Tailored Datecenter Integration (TDI) – MSFT offers this model in the Azure brand with Azure Large Instances for SAP HANA In the cloud SAP HANA is offered as a comprehensive infrastructure combined with managed services SAP HANA Cloud Platform (HCP) SAP HANA Enterprise Cloud (HEC) SAP HANA One – MSFT Azure supports this product on VM (DS14_V2) SAP HANA using the appliance delivery model, meaning preconfigured software and hardware bundled by an SAP hardware partner. This approach offers you well-defined hardware designed for the performance needs of an in-memory solution out of the box. The appliance delivery is the first choice if you are looking for a preconfigured hardware set-up and a preinstalled software package for a fast implementation done by your chosen hardware partner and fully supported by both, the partner and SAP. The installation of the SAP HANA appliance software is performed by the SAP hardware partner. External software is software that was not delivered by SAP or by your SAP HANA appliance hardware partner. SAP permits the installation and operation of external software that is required but customers need to pre-arrange such agreement with SAP SAP HANA tailored data center integration approach, which allows you more flexibility when integrating your SAP HANA system with your existing infrastructure, for example, network or storage solutions. TDI has special hardware specs. The server must be certified and is listed in the hardware directory; all storage devices must have successfully passed the hardware certification for SAP HANA; the install person needs to be certified as SAP Certified Technology Specialist – SAP HANA Installation” (E_HANAINS) HCP includes: SAP HANA Infrastructure Services (High-performance cloud infrastructure), SAP HANA DB Services (Fully-featured SAP HANA hosted in the public cloud), and SAP HANA App Services (SAP HANA Platform-as-a-Service (PaaS) in the cloud) HEC includes: Enterprise-class SAP HANA managed cloud offering SAP HANA One: Fully-featured SAP HANA hosted in the public cloud, generally used for smaller companies
15
SAP HANA Appliance vs. TDI
Diagram sourced from SAP Teched Sept 2016 handouts Microsoft Azure large instances for SAP HANA are certified to meet the TDI specs. With Azure large instances for SAP HANA, Microsoft deploys the physical server, the SLES or RHEL OS with the required logical volumes for an SI to install the SAP HANA DB and applications that run on top of it. All management of the HDB and apps are responsibility of the SI or the customers SAP HANA appliance model: SAP HANA software pre-installed by certified hardware partners on validated hardware running a specific operating system SAP coordinates all support requests for all components of the system, including hardware, with the responsible partners SAP is the main point of contact for all issues; SAP works with the hardware partner as needed SAP HANA TDI model: Customer is responsible for software installation; the customer is also responsible for defining support agreements with the various partners and for managing support with all the involved partners Customers work with hardware partners on hardware support requirements Supportability tool called the HW Configuration Check Tool for SAP HANA * (documentation attached to SAP Note ) allows customers to check if the hardware is optimally configured to meet the requirements of SAP HANA Customers are also responsible for on-going system maintenance and support, including: – initial software installation – updating – patching the OS and SAP HANA DBMS software
16
SAP HANA certifications
SAP Solution Supported OS Azure Offerings SAP HANA Developer Edition (including the HANA client software comprised of SQLODBC, ODBO-Windows only, ODBC, JDBC drivers), HANA studio, and HANA database)1 SUSE Linux Enterprise Server (SLES), Redhat Enterprise Linux (RHEL) A5-A11, D11-D14, DS11-DS14, GS1-GS5 SAP HANA One SLES, RHEL DS14_v2 SAP S/4HANA Controlled Availability for GS52 SAP HANA on Azure (Large Instances) SAP Business Suite on HANA (OLTP) SAP HANA Platform or Enterprise Edition for SAP BW (OLAP) GS5; SAP HANA on Azure (Large Instances) 1 Customers can try SAP HANA Developer Edition on Azure using the SAP Cloud Appliance Library. 2 Contact your Microsoft or SAP account manager for more information.
17
SAP on Azure (HANA) 448 GB 1-2 TB 0.76-2 TB 4 TB 60 TB 448 GB
*2 448 GB 1-2 TB OLAP Single node / Virtual Machine *4 *3 TB 4 TB 60 TB SAP on Azure (HANA) Single node / Purpose Built Hardware Multi-node / Purpose Built Hardware *1 *2 448 GB TB OLAP : Business Warehouse (BW on HANA, BW/4HANA), Side Car, HANA Enterprise DWH OLTP : S/4HANA, Business Suite on HANA, NetWeaver Single node / Virtual Machine OLTP *4 *3 Azure can run all kinds of HANA applications / and support both HANA scenarios / – OLAP and OLTP. OLAP means Business Warehouse, / BW on HANA, BW/4HANA, HANA Side Car, HANA enterprise DWH / and data mart and so on. OLTP includes / S/4HANA, Business Suite on HANA and SAP NetWeaver / such as Portal, XI, PI or EAI, Solution Manager. HANA database sizes that we can cover today / are the numbers that you can see in white in this slide. For OLAP we can run HANA database / up to 448GB on Azure Virtual Machines / one GS5 VM, / and up to 4TB / on Large Instances one blade, / and up to 60TB / on Large Instances 15-node scale out. The numbers in red are what we’re going to release / and get SAP certification / by the end of this calendar year. We will be able to run / up to 2TB on Azure M Series VM / by the end of CY17. As for OLTP / it’s up to 448GB with VM / for S/4HANA / and up to 20TB with HANA Large Instances scale up – one node / as of today. By the end of this CY / it will be up to 3.8TB with M Series VM. Please note that Azure is now offering market’s best scalability / that many on-prem HANA hardware manufacturers cannot provide. We are still hearing / classic cloud vs. on-prem argument / such as / large production HANA stays on-prem / and only small non-prod goes to cloud. This is not true any more. TB TB Single node / Purpose Built Hardware 24 TB *1 : Controlled availability for S/4HANA *2 : M Series will be available at East US2, West US2, West Europe, UK South, Australia East, Australia Southeast, Japan East, Japan West in CY17 *3 : HANA on Azure Large Instances are available at East US, West US, West Europe, North Europe, Australia East, Australia Southeast, Japan East and Japan West in CY17 Multi-node / Purpose Built Hardware (S/4HANA)
18
What is SAP HANA on Azure Large Instances ?
SAP TDI (Tailor Datacenter Integration) certified purpose built HANA hardware infrastructure hosted in Azure HANA server blade Storage hardware (persistent, 4 x RAM) Snapshot backup capability Storage replication capability in paired datacenter Volume encryption capability Network devices including backend ExpressRoute to connect to Azure VNET (10Gbps) Supported HANA scenarios OLAP : BW, BPC, Enterprise Edition, DWH, Side Car Scale Out to 60TB OLTP : Business Suite on HANA, S/4HANA, NetWeaver Scale Up to 20TB SKU # # CPU threads RAM (GB) HANA NFS Storage (GB) (persistent) Supported HANA scenarios SAP Certification + GA (* subject to change) HANA on Azure Large Instances Intel® Xeon® Processor E v3 (Haswell) SR72 72 768 3,072 OLAP/OLTP Certified SR72m 1,536 6,144 OLTP SR192 192 2,048 8,192 SR192m 4,096 16,384 HANA on Azure Very Large Instances Intel® Xeon® Processor E v4 (Broadwell) SR384 384 SR384m 18,432 SR384xm 22,528 SR576m 576 12,288 28,672 SR768m 36,864 SR960m 960 20,480 47,104 And what is SAP HANA on Azure Large Instances offering ? This is not regular Azure VM/, but SAP certified purpose built / HANA hardware infrastructure hosted in Azure. We’re using Equinix colocation datacenter / to host these hardware / which sit behind Azure IaaS/VNET. HANA database hardware in colo / and SAP application server VMs in regular Azure VNET / are tightly connected thru / backend ExpressRoute / and network latency between colo and Azure / is kept within 2 ms. HANA Large Instances offering includes / certified HANA server blade, / storage hardware with built-in capabilities of / snapshot backup, storage replication and volume encryption etc / and network devices including / backend ExpressRoute / to connect to Azure VNET which is 10Gbps. Based on customer’s application scenario – OLAP or OLTP, / and how much memory is needed for HANA database, / you can pick Large Instances SKUs for HANA database/ while application servers can be hosted in Azure VM / as needed.
19
M-Series Virtual Machines Massive memory, CPU, storage, and scale
Hyper-Threaded support Premium Storage support Based on Intel® Xeon® Processor E v3 High Performance DDR4 memory Support Nested Virtualization with Windows Server 2016 SAP Certified for Netweaver on AnyDB HANA certification soon Key talking points: The M-series is the largest instance size with up to 128 virtual cpu’s (VCPUs). These instances support premium storage for low latency workloads and are designed for the largest enterprise workloads. These have huge RAM sizes from 1.75TB to 4.0TB of RAM! VM size vCPU’s Memory: TB Local SSD: TB Persistent Data Disks Max Network Bandwidth Availability M64s 64 1.0 2 Extremely high GA in US M64ms 1.75 M128s 128 2.0 4 M128ms 4.0 Launching soon
20
SAP HANA Scale-up Single-node physical/virtual server with expansion capacity Massive parallelism for query execution with maximal exploitation of available hardware The challenge is NUMA effect on large multi-socket systems Pros No inter-node communication overhead Less administrative overhead than for scale out deployments Doesn’t require deep knowledge of application, data, and hardware for scaling Cons Limited scalability by hardware resources in one server Potentially higher initial cost
21
SAP HANA Scale-out Shared nothing, multiple nodes acting together
One logical system but physically distributed database Pros: High scalability: Distributed systems can overcome hardware limitations of one single server by distributing load between multiple servers Scale-out has wider range of scalability Cons: Inter-node communication overhead Higher administrative overhead (as compared to scale up systems)
22
SAP HANA Business Continuity
Diagram sourced from SAP Teched Sept 2016 handouts Host Auto Failover System Replication Storage Replication Cluster like solution Shadow DB like Solution Common DR Solution SAP HANA Host Auto-Failover for SAP HANA Scale-out: One node will fail (data-set is not complete anymore), Stand-by node will take over data and log files of failed node and will replace it (data-set is complete again). SQL query can again retrieve data from all nodes in parallel. Multiple stand-by nodes are allowed but not common. One stand-by node is serving as fail-over target for any of the worker nodes – no data preloading possible SAP HANA System Replication for SAP HANA Single-node Each SAP HANA node represents running instance. Only active node is having own data and log files. There are no data and log files on standby node. Data is written only to active node. SQL query will retrieve data from active node
23
Tools For HANA Migration & Migration Paths
Now that we learn about the HDB possible configurations, what is the migration path? What tools do people use for the migration?
24
SW Update Mgr. w Data Migr. Option
Diagram sourced from Benefit of Database Migration Option (DMO) of Software Update Manager (SUM): - Only one maintenance phase (not several) Reduces business downtime (TCO), less regression tests - In-place migration keeps application server and SAP System ID stable Low impact on system landscape and interfaces: only database server is changed - Original database is kept, can be reactivated as fallback Reduces risk, no restore required, more time for testing before cutover - Lower prerequisites for SAP and DB start releases Reduces effort (total cost of implementation), no additional licenses for traditional database update
25
SAP Landscape Trans. – Repl. Server
Diagram sourced from SAP TechEd Sep 2016 session handout ‘DMM213 –A Holistic View on Transforming a Landscape to SAP S/4HANA’ 10 min remaining The SAP Landscape Transformation (SAP LT) Replication Server is the SAP technology that allows you to load and replicate data in real-time from ABAP source systems and non- ABAP source systems to an SAP HANA environment. The SAP LT Replication Server uses a trigger-based replication approach to pass data from the source system to the target system. The SAP LT Replication Server can be installed either as a separate SAP system, or if the technical prerequisites permit, on an ABAP source system. You use a configuration to load and replicate data from one source system to one target database schema of a HANA system (1:1), or from multiple source systems to one target database schema of an SAP HANA system (N:1). Furthermore, it is possible to load and replicate data from one source system to multiple (up to 4) target database schemas of one or more HANA systems (1:N). You can also specify the type of data load and replication - either in real-time, or scheduled by time or by interval. For new Implementation: data from ABAP or non-ABAP systems can be selectively migrated to a HANA DB For System Conversion: SLT can also be used for converting an existing SAP system (business suite like ECC for example) to SAP HANA DB For Landscape Transformation: selected data from one or multiple sources can be migrated to one or more SAP HANA targets. Also used to migrate part of the application from a classic ERP system.
26
Path to BW/4HANA New Install - New to SAP or Ready for a Fresh Start
System Conversion - Convert your existing system Landscape Transformation Bring data from your old system to SAP BW/4HANA with SAP integrated data management and quality tools If your current SAP landscape is over five years old, consider a fresh start Leverages a modern data warehouse, no modifications or work-arounds of the past Complete conversion of an existing SAP BW system to SAP BW/4HANA If your current SAP landscape has been highly maintained (SAP BW, powered by SAP HANA), you most likely can convert to SAP BW/4HANA in just a few steps Ideal for large enterprises with many instances of SAP and non-SAP BW systems Consolidation into one global SAP BW/4HANA system or selective data migrations BW4HANA see details info here ; Also see New Installation: Also referred to as “greenfield approach”, this path start by installing a brand new SAP BW/4HANA system. You begin from scratch, connect any data sources – that could be a legacy data warehouse or any other data source available in your enterprise – and start modeling you data warehouse. If you run already a SAP Business Warehouse (BW) system today and want a fresh start, you can get a head start by transporting certain configuration and data models from your existing landscape to SAP BW/4HANA. Please note that this is only supported for the initial system setup, not for continuously updating the new landscape. And, of course, it’s only supported for objects that are fully compatible with SAP BW/4HANA. System Conversion:, your intermediate target is to get to SAP BW powered by SAP HANA and transition to data models that are fully optimized for SAP HANA. SAP is working on a so called “Transfer Tool”. The tool is currently available as part of the SAP BW, edition for SAP HANA add-on (which installs in on your SAP BW 7.5 powered by SAP HANA system). This transfer tool allows you to create SAP HANA-optimized objects for all your standard SAP BW data models. Landscape Transfromation: The third and final option is to optimize more complex data warehousing landscapes resulting in a single, global SAP BW/4HANA system.
27
Path to S/4HANA New Install - New to SAP or Ready for a Fresh Start
System Conversion - Convert your existing system Landscape Transformation Installation SAP NetWeaver Application Server ABAP 7.5 based on SAP HANA Installation of SAP S/4HANA Installation SAP Fiori for SAP S/4HANA Update to SAP NW App Server ABAP 7.5 Migrating the db to SAP HANA (in case the SAP Business Suite system is not yet on SAP HANA) Install SAP S/4HANA Install SAP Fiori for SAP S/4HANA Migrate data from the old data structures to the new simplified data structures Possibly a new installation of a SAP S/4HANA Possibly converting a system to SAP S/4HANA Additional migration steps that are based on SAP Landscape Transformation combined with SAP Landscape Optimization services New Install - Focused on net-new customers (coming from any legacy system) or SAP Business Suite customers that start for different reasons with a new installation. Benefit with this path is the re-engineering and process simplification based on ready-to-run business processes and reference solution delivered with the solution; new implementation of industry-leading Business Suite; pre-defined migration objects & Best Practices available in a guided process System Conversion - This scenario is focused on existing SAP Business Suite customers that want to change their current system into a SAP S/4HANA. Benefit include migration without reimplementation; no disruption for existing business processes; re-evaluation of customization and existing process flows Landscape Transformation - This scenario is focused on existing SAP Business Suite customers that want to change their current system or system landscape into a SAP S/4HANA. Benefit include staying with current business processes and move gradually to SAP S/4HANA innovations; harmonized business processes and shared master data through consolidation; carve out of single entities of the company to SAP S/4HANA and leverage process simplification
28
SAP HANA Admin tools
29
SAP HANA Administrative Tools
Native Tools for SAP HANA Database Administration SAP HANA Cockpit SAP DB Control Center SAP HANA Studio Use for: Core administration and detailed monitoring of a single SAP HANA database • Web-based SAP Fiori launchpad • Runs on SAP HANA XS Classic Use for: Administration and monitoring of the entire SAP HANA database landscape • Web-based SAP Fiori launchpad • Runs on SAP HANA XS Classic Use for: SAP HANA basic administration tasks and development including modeled views • Eclipse-based IDE • No longer in feature development Native tools for SAP HANA administration: SAP HANA Cockpit is used for Core administration and detailed monitoring of a single SAP HANA database. It is a Web-based SAP Fiori Launchpad and runs on SAP HANA XS Classic SAP DB Control Center is used Administration and monitoring of the entire SAP HANA database landscape, It is a Web-based SAP Fiori Launchpad Runs on SAP HANA XS Classic SAP HANA Studio is used for SAP HANA basic administration tasks and development including modeled views. It is Eclipse-based IDE. This tool is depreciated and no longer in feature development but there are customers still using it. The next generation of development tool is SAP Web IDE for SAP HANA that runs on XS Advanced providing SAP HANA Dev & Modelling, SAPUI5 & Node.js Dev Tools
31
Appendix
32
SAP NetWeaver App Server Architecture
Diagram sourced from Dual-stack (ABAP & Java) Only a few applications on dual-stack Single stack servers are more common Key pieces in App Server: SCS (Message, Enqueue) Work Processes Dispatcher Internet Comm. Mgr.
33
SAP Applications run on SAP HANA
SAP Business Warehouse Classic SAP BW – Netweaver based BW on HANA referred to as BW powered by HANA or BW on HANA BW/4HANA – Next-gen version of BW that is completely optimized and tailored to SAP HANA SAP Business Suites Classic ERP applications – ECC, SCM, CRM etc. marketed as Suites on HANA or ‘Powered by HANA’ S/4HANA – New generation of ‘simplified’ data schema style of applications like Enterprise Management, LoB Products BW/4HANA is an evolution of BW that is completely optimized and tailored to SAP HANA. The BW/4HANA code can only run on SAP HANA as it is interwoven with SAP HANA engines and libraries. For more details see The SAP S/4HANA family is fully built on the in-memory platform SAP HANA. Using the advanced potential of SAP HANA, SAP S/4HANA is designed for your digital business and provides an instant insight by using a single source of truth, real-time processes, dynamic planning and analysis. With SAP Fiori user experience and less complex data model it is designed to run simple, and in parallel reduces the data footprint SAP S/4HANA Enterprise Management is designed for enterprises across industries that need a deep and broad level of functionality combined with a high degree of flexibility in customization. It includes functions like Asset Management, Finance, Human Resources, Manufacturing, R&D Engineering, Sales, Sourcing and Procurement, and Supply Chain etc. SAP S/4HANA LoB and industry Products enhance core functions of SAP S/4HANA Enterprise Management to provide additional business benefit for your line of business (LoB). Includes functions like: Asset Management for Environment, Health, and Safety, Commerce Management, Finance, Contract Accounting, Master Data Management etc. These products designed and configured for specific industries: Automotive, Banking, Insurance, Oil & Gas, and Professional Services.
Similar presentations
© 2025 SlidePlayer.com Inc.
All rights reserved.