This was an SAP webcast. How to consume BW through HANA Enterprise Cloud and Cloud Lifecycle Management, combining three topics into one session
Figure 1:
Need to replicate data
The SAP Speaker read from the slides so no additional notes from me on this
Figure 2: Source: SAP
HANA Enterprise Cloud is a virtual private cloud with single tenancy infrastructure – it is not public – it is virtual
It is an extension of your corporate network
Three components on the left of Figure 2
Core services are described in roles & responsibilities document
Core services are a technical operation service
Infrastructure and core services are subscription based
IT planning, RDS, application services can be complemented; can be optional on a subscription basis
A technical assessment service is provided (plan, build, run) – how much data BW should have, expected growth, kinds of systems connected
System provisioning is through cloud lifecycle management tool
Core services keeps BW running through SLA’s
Plan depends on customer scenario. Two use cases – customer relocate BW services or net-new installed BW
Figure 3: Source: SAP
Figure 3 refers to “build phase”
Two flavors of HEC – one flavor is Cloud Start and other is Cloud Productive
They different in SLA and commercial framework
It is up to customer which environment to begin with; depends on contracts signed
Cloud start lasts up to 1 year, weekly subscription
Cloud productive is up to 5 years with monthly subscription
Systems in cloud start have 95% availability; these are for non-productive systems
Systems can shift from cloud start to cloud productive after the contract is signed with higher SLA’s (for POC’s)
Figure 4: Source: SAP
Switching service starts to Cloud Start to Cloud Productive
Cloud Productive is managed by SAP Core Services
Customers run their BW, leveraged on BW on HANA
Productive system remains your EDW
Service levels in cloud productive – clearly defined infrastructure activities (in roles & responsibilities document)
Availability is 99.5%, 24 x 7 support, defined windows for patching, etc.
Activity reports, remediation, dedicated personal contact, customer engagement manager, technical landscape manager – have customer specific data
recovery architecture
Figure 5: Source: SAP
Cloud lifecycle management tools support two ways – new installation and solution relocation
Simplest is the new installation
Relocation of existing BW solution to HEC- hybrid cloud scenario to connect ERP to BW or other data centers
SAP BW extractors are used to stage extractions
Aspects of WAN connected to ERP are covered during the planning phase
Figure 6: Source: SAP
You can get an empty SAP BW system – SAP BI content is not pre-activated; customer decides which BI content is activated
From pre-assembled RDS packages you can get SAP BW semi-activated BI content
Source system dependent objects would need to be reactivated after you connect to BW
There is an option for a full active BI content RDS; example data is imported for analytic scenarios
Figure 7: Source: SAP
SAP BW solution is relocated; hardware remains in your data centers
Two options – 1 is a system copy to HEC with the database migrated
Use the software provision manager for the system copy
It includes a stack split and Unicode conversion (SUM includes update and database migration)
Figure 8: Source: SAP
Figure 8 shows relocating SAP BW to HEC and uses SUM to and in EC
Relocate SAP solutions to HEC – there is no need to make a copy of on-premise system in the cloud
The original system is using the database migration option (DMO)
The Import phase runs in HEC
Figure 9: Source: SAP
There are two downtimes – less than 48 hours or greater than 48 hours
Managing of downtimes depends on the methods of SAP BW relocation
Copy & SUM in HEC scenario – system downtime can vary
1:1 copy can be performed in different ways – back up and restore or another tool
First scenario – only downtime for the export phase – SAP BW use case – is used to set up sandbox systems. Consider the integration aspects of extraction from ERP – stop batch jobs, relocate BW system, and after export you can restart the extractions to BW system on premise
Second scenario – takes into account business integrity – should be used for productive solutions
Downtime of export to import could be over 48 hours; if BW is big you may require more than 48 hours
As an example, the speaker said 30TB compressed data from non SAP database, moved using MPLS connectivity, accomplished in 1 weekend
Third scenario copy and update for optimizing downtime – set up in ERP systems – delta queue cloning – logical delta queue – achieve 2 short business downtimes
Figure 10: Source: SAP
Solution relocation or new installation, could use SAP RDS and SAP BW to SAP HANA RDS is coming
Question & Answer
Q: Will get details on transfer of data to cloud?
A: No difference to on premise scenario
HEC extends network of customer; no additional tools
Q: How many customers are in HEC who are live?
A: Can’t give detailed numbers. Most customers are existing BW customers and SAP manages the relocation as described.
UPDATE: I asked Steve Lucas yesterday on a SAP Chat for customers using BW on HANA in HEC and he said "Bosch, Siemens, 99c stores+++ all using BW on HANA in HEC"
Q: How would users run BEx or BI reports with this hybrid architecture?
A: for the BEX you need BI Java component (?) in HEC
BusinessObjects scenario – have customers run next to BW in HEC or if on premise can run in hybrid mode
Have both scenarios running productively in HEC
Q: For an existing customer what will be the impact of having BW fully activated? BI content fully activated
A: It is not assumed to provide fully activated BI content for a relocation scenario. Relocation is system copy or migration to HEC
Q: Would full data reload work the same as on premise architecture?
A: in SAP BW it remains the same
Typically in planning phase you evaluate volume
Q: Is BI Content for all industries supported?
A: new type of BI content model – EDW/Analytical data model, takes into the account LSA++
Industries - refer to the BI content documentation
Q: Does that mean the data models would have to be redefined from relocation of on-premise system?
A: No the data models stay as-is with the relocation – you can consume BW same and once on HANA DB to take advantage of HANA DB
“relocation without disruption”