RobFryeJoeDarlak

Dr.BjarneBerg

TheSAPBWtoHANAMigrationHandbook

ISBN: 978-3-945170-53-3(ePUB)

Editor: AliceAdams

Proofreading: TraceyDuffy

CoverDesign: PhilipEsch,MartinMunzel

CoverPhoto: fotolia#49827738stuporter

InteriorDesign: Johann-ChristianHanke

Allrightsreserved.

1stEdition2015,Gleichen

EspressoTutorialsGmbH

URL:www.espresso-tutorials.com

Allrightsreserved.Neitherthispublicationnoranypartofitmaybecopiedorreproducedin any form or by any means or translated into another language without the priorconsentofEspressoTutorialsGmbH,ZumGelenberg11,37130Gleichen,Germany.

Espresso Tutorials makes no warranties or representations with respects to the contenthereofandspecificallydisclaimsanyimpliedwarrantiesofmerchantabilityorfitnessforany particular purpose. EspressoTutorials assumes no responsibility for any errors thatmayappearinthispublication.

Feedback:Wegreatlyappreciateanykindoffeedbackyouhaveconcerningthisbook.Pleasemailusatinfo@espresso-tutorials.com.

TableofContentsCover

Title

Copyright/Imprint

Preface

1IntroductiontoDMO

1.1StrategiesformigratingtoSAPHANA

1.2BringingitalltogetherwithDMO

1.3Navigatingthisbook

1.4Readingthebook

2Planningthemigration

2.1Businesscase

2.2Staffing

2.3Sizingthemigration

2.4Budgeting

2.5Programmilestones

3Hardware,optimization,andSAPBusinessObjectsintegration

3.1Hardware

3.2Optimization

3.3WhatisBIself-service?

3.4BusinessObjectsintegration,mobilization,andconnection

4BWcleanup

4.1TheBWcleanup12step-program

4.2Minimizingdatabasesize

4.3Housekeepingmadeeasy

4.4Beforeupgradetasklist

5PrerequisitesforDMO

5.1RequiredBWversionandservicepacks

5.2Generalprerequisites

5.3Unicodeconversion

5.4Securityconversion

5.5BExWADtemplates

5.6BWonHANAmigrationchecklist

6TheDMOmigration

6.1Step-by-stepinstructions

6.2Post-migrationtasks

6.3SampleDMOtasklist

7HANAperformancemonitoring

7.1PerformancemonitoringinHANAStudio

7.2PerformancemonitoringinSAPBW

7.3Performancemonitoringdashboard

8Summary

8.1Thingstoremember

8.2Farewellandgoodluck!

AAboutTheAuthors

BDisclaimer

DedicationTomymotherandfather:

Youhavegivenmethegiftofeducationandsharedwithmeyourloveoflearning;nowIendeavortohonoryoubysharingmyknowledgeandlearningswithothers.

J.D.

ToJody,Audrey,Sam,andLayna:

YourconstantloveandsupportgivemethestrengthtodomorethanIeverimaginedwaspossible.Thanksforbeingthebestfamilyamancouldeverwant.

ToBrandon,Brandon,Michael,Michael,Nick,andFernando:

ThankyouallforbeingthebestteamIveeverhadthepleasureofworkingwith.

R.F.

PrefaceOverthepastseveralyears,wehavebeendeeplyinvolvedinSAPHANAmigrationsofalltypes.WehavenotonlydevelopedexperiencemigratingsmallerSAPBWsystemstoHANAusinganin-placemigrationapproach,butwehavealsobledonthecuttingedgebysuccessfullymigratingsomeofthelargestSAPBWsystemsusingadowntime-minimizedapproach.Regardlessof thesystemsizeor theapproachfollowed, theobjectiveofeachmigrationhasbeenalmostunanimous:givethebusiness thecapability todothings theyhaveneverbeenabletodobefore.

Intheworldofenterprisedatawarehousing,SAPHANAistrulyadisruptivetechnologyasithasredefinedtechnicalpossibilities.Byofferingordersofmagnitudeimprovementsin reporting performance while simultaneously reducing data staging and redundancy,HANA largely pays for itself by simply reducing development andmaintenance effort.However, its maximum value will be realized by those who seize the opportunity toleverageitsperformanceinnon-traditionalways.

ThebusinessesthatuseSAPHANAasasteppingstonetoimplementpredictiveanalytics,createfederateddatawarehouses,orenablereal-timereportingwillundoubtedlyreapthegreatestbenefitsfromthistechnology.Thosewithlessloftyambitionswillstillmanagetodo the same things they do today, just with greater efficacy and much improvedperformance.Regardlessofthebusinessobjective,thefirststeptowardsachievingresultsusuallystartswithadecisiontomigratetoSAPHANA.

We wrote this handbook to help guide you, the reader, through the decision-makingprocessandintothemigrationprojectplanning.Thechaptersofthisbookareorganizedtogiveyoutheknowledgeandunderstandingnecessarytomakeinformedchoicesonyourpath toSAPHANA.Ourultimategoal is todeliverourcombinedexperience toyousothatyoucanrunasuccessfulmigration.Goodluckinyourendeavors!

RobFrye,JoeDarlak&Dr.BjarneBerg

Wehaveaddedafewiconstohighlightimportantinformation.Theseinclude:

Tip

Tips highlight information concerning more details about the subjectbeingdescribedand/oradditionalbackgroundinformation.

Attention

Attentionnoticesdrawattentiontoinformationthatyoushouldbeawareofwhenyougothroughtheexamplesfromthisbookonyourown.

Finally, a note concerning the copyright: All screenshots printed in this book are thecopyrightofSAPSE.All rightsare reservedbySAPSE.Copyrightpertains toallSAPimages in this publication. For simplification, we will not mention this specificallyunderneatheveryscreenshot.

1IntroductiontoDMOTodaysbusinessworldrequiresspeed.Fromsmartphoneapplicationstosub-secondInternet searches, users have easy access to a wealth of external information. ITdepartments are being pressed to meet similar expectations to provide super-fastaccess to information from disparate internal and external sources with lessinfrastructure and smaller budgets than ever before. Faster reporting solutions,includingreal-timedataaccess,canenablecompaniestorespondtoanever-changingbusinessclimateinrealtime.Aswithmostotherinnovations,earlyadoptersofnewtechnologywill see thegreatestgains fromtheability toquicklyrespond to suchachallengingandfast-pacedbusinessenvironment.

EnterSAPHANA,whichreplaces the traditionalrelationaldatabasewithan in-memorysolution that has revolutionized thewaywe storedata and architect reporting solutions.SAPHANA is the right solution for every companybecause it provides the agility andprocessing power needed to turn a company with solid performance into an industryleader.ThebusinesscaseforSAPHANAiscoveredat lengthinSection2.1.First, letscoverthestrategiesandtacticsformovinganexistingSAPBWsystemonanydatabasetoSAPHANA.Wewill explore the differences between theDMO process and the otheroptionsthatareavailable.

1.1StrategiesformigratingtoSAPHANA

Therearemanyways tomoveanexistingSAPBWsystemona traditionaldatabase toSAPBWonHANA,buttherearereallyonlytwomajorstrategieswhichmostcompaniesconsider:

Newimplementation(greenfield)Databasemigration

Withineachstrategy, therearedifferentapproachesand tacticswhichcanbeemployed.Letsdivealittledeeperintothebenefits,approaches,andtacticsofbothstrategies.

1.1.1Newimplementation(greenfield)strategy

Inanew implementation,orgreenfield strategy, a consciousdecisionhas beenmade toinstall an entirely new SAP BW on HANA environment. Content (i.e., data models,applications, and reports) from the originalSAPBWsystemwill be redeveloped in theSAPBWonHANAsystem.ThisgreenfieldsystemwillruninparallelwiththeexistingBW environment for the duration of time it takes to redesign the entire enterprise datawarehouse(EDW)tofullyleveragethebenefitsoftheSAPHANAplatform.

Whenthenewsystemisready,historicaldatacanbemigratedfromtheoldenvironmenttothegreenfieldsystem.Asreportingcapabilitiesarerolledout,oneormoreproductioncutovers canbe scheduled to transition thebusiness to thenew system, thus enabling aflexibledeploymentapproach.

Thebiggestdeterrenttothegreenfieldapproachisthecostofimplementationandthelostinvestment in theoriginalsystem.Dependingon thesizeandcomplexityof theoriginalSAPBWsystem,agreenfieldapproachcouldtakemultipleyearstocompletelyredesignand rebuild, thus requiring a dual landscape (twice the infrastructure and twice thesupport)duringthat time.Forsystemswithseveredesignissuesorminimalcontent, theeffort of rebuilding from scratchmay be well worth it considering the benefits of thisstrategy.

The biggest benefit of the greenfield strategy is that it provides an opportunity tocompletelydiscardand/orreplaceold,outdated,andoverlycomplexdatamodels.Inmanycases,datamodelsanddataflowsdesignedforreportingefficiencyintraditionalSAPBWimplementationscanbesimplifiedinSAPHANA.Inothercases,flaweddatamodelsordataflowscanbediscardedandreplacedwithabetterdesign.

This strategy also allows for a less stressful migration, since the old system remainsoperational with no disruptions while the new system is being implemented. In ourexperience,thegreenfieldapproachhasbeenusedinapproximatelyonethirdofSAPBWonHANAimplementations.

1.1.2Databasemigrationstrategy

Inmost cases, a significant investment has beenmade in the original system.The dataflowsalignwithalayeredscalablearchitecture(LSA)andthedatamodelsadheretobestpracticemodelingguidelines.Thequeriesandreportsbasedontheoriginalsystemdelivertherightresults.Manyyearsofrequirementsgathering,design,development,andtestingeffort havebeen spentbuilding the system, and there isno reason todiscardor replacewhathasalreadybeenbuilt.

Thebeststrategyfor these typesofsystems is tomigrate thedatabasefromtheoriginaldatabase to SAP HANA. Depending on the size of the system, there are two basicapproacheswhichcanbefollowed:

In-placemigrationDowntime-minimizedmigration

Forsmallerdatabases,usuallylessthan10TB,thein-placemigrationisthesimplest,mostefficient,andmosteconomicalapproach.Letslearnmoreaboutin-placemigration.

In-placemigrationapproach

An in-place migration is exactly what its name suggests: start with SAP BW on anydatabaseandmigrateitdirectlytoSAPHANA.

In-place migrations require flexibility to schedule a system outage during which thedatabasewill bemigrated.When themigration is complete, the outage is over and theoriginalsystemisnowrunningonSAPHANA.Thisapproachisonlyrecommendedforsmaller systems because the migration takes longer for larger systems. Generallyspeaking,systemslessthan10TBcanbemigratedoverathree-dayweekend.

Theindividualsystemswithinasystemlandscapewillbemigratedonebyone,andthereislimitedcapabilitytoturnbackonceyouvestarted.Inathree-systemlandscapewithadevelopment, acceptance, and production system, eachwould bemigrated in sequence.Returningthelandscapetotheoriginaldatabasewouldrequirerestoringeachsystemfrombackup, meaning any new development would be lost. Therefore, a development andtransport freeze is highly recommended until all systems are on the same database andSAPBWversion(incaseanupgradeisplannedwiththemigration).

For larger systems, those with limited flexibility to schedule long outages, or whereongoingprojectsorotherdevelopmentimpacttheabilitytointroduceatransportfreeze,adowntime-minimizedapproachprovides themost riskmitigationand least impact to theexistinglandscape.

Downtime-minimizedmigrationapproach

In the downtime-minimized approach, a database copy of the system to bemigrated is

restored on interim hardware. It is the copy which is migrated to SAP HANA, thusminimizingtheneedforanoutageintheoriginalsystem.

Tokeepdataloadsinsyncwiththeoriginalsystem,alldeltaqueuesareclonedusingtheSAP post-copy automation (PCA) tool, which is available with SAP LandscapeVirtualizationManagement (LVM).Syncpointsaresetbefore thedatabasecopyso thatdata can be extracted from the cloned delta queues after themigration.When the dataloads are caught up, users are then transitioned from the original system to the newsystem.

The downtime-minimized approach results in two parallel landscapes; the originallandscape can only be decommissioned after all systems have been migrated to SAPHANAandallusershavebeentransitionedtothenewsystems.

Asaresultoftheparallellandscape,theneedforinteriminfrastructure,andtheadditionalsteps required to copy the database and clone delta queues, this approach is the mostexpensivemigrationoption.However,thecostsaremorethanoffsetbytheriskmitigationand limited impact on development activities and productive operations in the originallandscape.

Regardless ofwhich approach is selected, different tactics are used depending onwhatotheractivitiesneedtobeaccomplished.Inmostmigrationscenarios,anupgradeofSAPBWisoneof those activities.Other scenariosmay includeaUnicodeconversionor anextra-largedatabasesuchasonegreaterthan40TB.ThenextsectiontakesacloserlookatthedifferenttacticsformigratingtoSAPHANA.

1.1.3Databasemigrationtactics

With a migration approach selected, it is time to dive into the detailed migrationprocedures available. The specific tactics employed to migrate an existing database toSAPHANAwilldependontheotheractivitieswhicharepartoftheobjective.

Extra-largemigration(legacydatabase>50TB)UpgradetoSAPBW7.40Unicodeconversion

Ifthelegacydatabaseislargerthan50TB,thenanXXLmigrationservicefromSAPmaybeworthconsideration.TheXXLmigrationserviceisacustomer-specificprocesstailoredbySAPprofessionalsforeachcustomersneeds.

TooperateSAPBWonHANA,theminimumversionrequiredisversion7.30SP05.ThelatestversionofSAPBWis7.40SP10.Ifthereisnoneedtoperformanupgradeaspartofthemigration,thenaclassicOS/DBmigrationistheappropriatetactic.

However, if an upgrade to SAPBW 7.40 is also required or desired and/or aUnicode

conversionisrequired,thenamigrationusingDMOforSUMisthebesttactic.

Inthenextthreesections,wecovereachofthesetacticsinmoredetail.

Extra-largemigrationusingXXLservice

Ifthelegacydatabaseislargerthan50TBuncompressed,thenthemigrationphasealonecould exceed four days at an average throughput of 0.5 TB per hourplease note thisdoesnottakeintoaccountallthepre-migrationandpost-migrationtasks,whichcouldaddaweekormoretothetotalduration.Adurationofthismagnitudecouldposeariskwhencatchingupdataloadsfromthecloneddeltaqueues.

TheXXLmigrationprocessisaHANA-specificbinaryexport/importwhichistailoredforyoursystemandisdeliveredandexecutedbySAPprofessionals.Itisascalableapproachusing added hardware (in addition to any interim hardware for the database copy) forextremedowntimereduction.

Thistacticisthemostexpensiveoption,butshouldbeconsideredifthesizeofthesystemandthedurationof themigrationconstituteanunmitigatedrisk.However,upgradesandUnicodeconversionsmustbeexecutedseparately.

ClassicOS/DBmigrationusingSWPM

Using the Software ProvisioningManager (SWPM) is the right tactic if no upgrade orUnicodeconversionisrequired.Thisoptionallowsforthetraditionalexportandimportofa database for a heterogeneousmigration from any database to any database, includingHANA.Theexportandimportcanbeperformedsequentiallyorinparalleldependingonthehardwareavailable.

This tactic is not suitable for upgrades or Unicode conversions, because each of theseadditionaltaskswouldhavetobeexecutedseparately.

UpgradeandmigrationusingDMOforSUM

IfanupgradeorUnicodeconversionisrequired,andanXXLmigrationistoocostly,thenusingtheDatabaseMigrationOption(DMO)isthebestchoice.DMOworkswiththeSAPUpgradeManager (SUM) todeliverasystemupgrade,Unicodeconversion,andHANAmigrationinonestep.

In order to understand the benefits of DMO, you first need to understand the othermigrationoptionsabove,whichrequireseparateactivities toperformupgrades,Unicodeconversion,anddatabasemigrations.

For example, in a downtime-minimized approach, the delta queues are cloned, then thelegacy database is copied and restored, then the Unicode conversion would require anexport/importofthedatabase,thentheupgrade,andthentheHANAmigration.Theresultistoomanystepsandtheprocesslacksefficiency.

Therefore,thebenefitofusingDMOforSUMisclear:amoreefficientwaytomigratetoSAPHANAwhilealsoexecutinganSAPBW7.40upgradeandaUnicodeconversion(ifrequired).Thissimplificationreducestheoverallmigrationduration,evenforextra-largesystems.Inaddition,withasimplifiedandcontrolledprocessusingSUM,thereislessriskofunexpectedissuesduringthemigration.

1.1.4Additionalmigrationconsiderations

Before an existing SAPBW system can bemigrated to SAPHANA, the old reportingauthorizationsmustbemigratedto7.xanalysisauthorizations.Thisisaprerequisitestepwhichmust be included in allmigration projects, unless, of course, it has alreadybeencompleted.

Before upgrading to SAP BW 7.40, all BEx 3.x queries and web templates must bemigrated to BEx 7.x. With SAP BW 7.40, BEx 3.x objects are no longer supported.Failuretomigratetheseobjectscanresultinqueryorreporterrorswhichcannot,orwillnot,beresolvedbySAPsupport.

After the migration to SAP HANA, existing data flows adhering to LSA should beoptimized for HANA using LSA++. While a data volume optimization effort is notrequired to realize the performance benefitsHANA offers, it will serve to improve thereturnstheinvestmentinHANAwillgenerate.

1.1.5Migrationwithoutoptimization

Themostcommonchoiceforcompanies thatwant toeliminatedependencies fromtheirmigrationproject is tonotconsideroptimizationaspartof theirprojectobjectives.ThisoptionleavesthesamefunctionalBWsysteminplaceandmerelymovesallofthecontentto theHANAplatform.While this is the fastest option forperformingaBW toHANAmigration,ithasthedownsideofbeingtiedtotheoldLSAarchitecture.Therewillstillbesignificant performance increases due to the speed of the HANA in-memory columnararchitecture, but this option does not fully implement the simplified landscape that isavailablewithSAPHANA.

1.1.6Migrationwithoptimization

Thisoptionincludesbothatechnicalandfunctionalupgradeinoneproject.Thisprojecttakeslongertoimplementasthereismuchmoredevelopmentandtestingrequired,butitprovides additional performance benefits by moving to the new LSA++ architecture.When this option is chosen, the longer project time is used for optimization of all dataflows and data models. Because of HANAs flattened architecture, complex relationalmodelsarereplacedwithsemanticviewswhichallowforbetterqueryperformanceandasimplifieddevelopmentprocess.

1.2BringingitalltogetherwithDMO

TheoptionsformigratingSAPBWtoHANAbeforeDMOhadmanymanualstepsand,therefore,multiplepointsoffailure.InordertomigratetoHANA,acomplicatedsequenceof tasks,eachofwhichcouldbea singleproject in itsown right,was required.First, aUnicode migration would require an export and import of the database. Second, anupgrade to SAP BW 7.40 would be necessary to meet the technical requirements forHANA functionality.Third, themigration toHANAwould complete the sequence.TheDMOprocesscombinesallthesedisparatetasksintooneprojectwithameasureofcontrolandsupportbySAP.ThesimplificationofthemigrationpathusingDMOisillustratedinFigure1.1.

Figure1.1:UpgradeoptionsforSAPBWonHANA

WithDMO,anynecessaryupgrades,Unicodeconversion,anddatabasemigrationcanbecompleted in one stepwith theSAPUpgradeManager.There is no longer any need toexecuteeachtaskinthemigrationmanuallyasaseparatetask.

TheDMOprocessalsoimprovesontheoldmigrationprocessesbyrequiringlessbusinessdowntime. Only having one project allows the final cutover to take place in less timeinsteadofrequiringoutagesatseveraldifferenttimesthroughouttheyearaseachportionoftheprojectwascompleted.

1.3Navigatingthisbook

Chapter 2 provides proven techniques for planning a successful SAP BW on HANAmigrationusingDMO.SeveralkeybenefitsofDMOandHANAareprovidedtohelpyoubuild a business case for your migration project. We provide sample staffing plans,examine tools for hardware sizing and planning, and consider items to rememberwhenbudgetingforamigrationprojectusingtheDMOprocess.Chapter2endswithasamplemilestoneplantohelpyouplanyourownproject.

Chapter3expandson thecontentsofChapter2.Weexamine theprocessofoptimizingSAPBW for SAPHANA, explain the concept of BI self-service, and provide tips forintegratingSAPBW7.40onHANAwiththeSAPBusinessObjects4.1Platform.Chapter3 endswithguidanceon leveraging theSAPBusinessObjectsplatform tools formobilereporting.

InChapter 4, we outline the process for cleansing the BW system prior to migration.Cleansing thesystemprior tomigrationallowsyourcompanytoreduce thecostsforanSAP BW on HANA implementation. This chapter explains the process for removingobsoletedatafromtheexistingSAPBWsystemsothat theHANAmigrationwillmovelessdataandrequirelessspaceandwill,therefore,bemoreefficient.

Columnararchitecturesprovidea7-9xcompressionfactor

TheSAPHANAdatabaseusescolumnararchitecturewhichstoresdatamuchmoreefficiently thana traditionalRDBMS.Thedatavolumeondiskincolumnstoretablesisusually7-9xcompressedcomparedtorowstore. When loaded into memory, SAP HANA needs twice as much

spacefortemporarycomputations,sotypicalcompressionratiosforHANAare3-4xwhentakingbothcolumnararchitectureandmemoryrequirementsintoaccount.

Chapter5providesyouwiththeprerequisitesneededtousetheDMOprocess.Weoutlinerequired service packs and enhancement packages, explain Unicode conversions andsecurity conversions, discuss the impact of the migration on BEx Web ApplicationDeveloper templates, and examine theBWonHANAMigrationCockpit in detail. ThemigrationcockpitisthepreferredtoolforpreparingforaDMOmigration,andthereforethistoolisexaminedindetailaspartofChapter5.

Chapter 6 contains priceless information on how to complete an actual SAP BW onHANAmigrationusingDMO.Step-by-stepinstructionsareprovidedbasedontheworldslargestDMOmigrationprojects.WealsoprovideasampleDMOrunbook,alongwithadetailedlistofmorethan600separatetaskswhichareintegralpartsofaDMOmigration.Chapter6wrapsupwithpost-processingstepsthatneedtobecompletedaftertheactualmigrationofthedatabasetoSAPHANA.

Chapter7presentsyouwithkeytechniquesformonitoringthehealthofyourSAPHANA

implementation, including techniques for monitoring the system health in both theDBACOCKPITandHANAStudio.YouwillalsogainhelpfulinsightintoleveragingthepowerofDesignStudio tocreateadashboard formonitoring thehealthofyourHANAenvironment.

Chapter8distills theknowledgeyouhavegained in thepreviouschapters into themostimportantthingstoremember.Ifyoutakenothingelseawayfromthebook,makesuretoreadChapter8carefully,becausetheitemslistedtherearetheonesyouabsolutelycannotskipifyouwantyourSAPBWonHANAmigrationprojecttosucceed.

1.4Readingthebook

This book is a fast-paced examination of the DMO process and howDMO is used toimprovetheSAPBWonHANAmigrationprocess.Assuch,donottrytolearneverythinginonesitting.Theexamplesincludedinthebookaretakenfromactualprojects,andtheyare quite detailed, so trying to understand everything in one sitting may be somewhatsimilartotryingtodrinkfromafirehose.

Also,astheoldsayinggoes,Dontreinventthewheel.YoushouldunderstandthatthetoolsyouaregaininginthishandbookwillprovideasolidframeworkforcompletingyourownDMOproject.Whilenoplancananticipateeverypossibleissuethatmayarise, theadviceandexamplesinthisbookshouldprovideyouwiththestrategiesyouneedtohelpyourprojectsucceed.

2PlanningthemigrationIntheintroduction,wediscussedthebenefitsoftheDMOprocessoverotheroptionsformigratingtoSAPHANA.Inthischapter,youwilllearnmoreaboutthebusinesscaseformigratingtoSAPHANA,aswellastheitemsthatyoumustconsiderwhenplanningfortheDMOapproach.

InChapter1,weexaminedthehistoryofdatamigrationsandbegantobuildthecaseforchoosing the DMO option for your companys migration from BW to HANA. In thischapter,wewill lookat severalbenefitsyoucanuse inbuildingyourbusiness case forSAP HANA. We will also look at some sample staffing plans, hardware sizing andplanningexamples,budgeting,andmilestones.ThisinformationisprovidedasabaselinetoassistyouinplanningforyourcompanysDMOprocess.

2.1Businesscase

ThereareseveralreasonsformigratingyourSAPBWsystemtoSAPHANA.Themostimportant reasons are those that provide the greatest advantage to your business. Thereasonsthatprovidethemostimpactinclude:

SuperiorperformancewithasmallerdatabasefootprintMoreagiledevelopmentandsimplermaintenanceLandscapesimplificationandreal-timereporting

Thesebenefitsdrivealowertotalcostofownership(TCO),andtheycanbeachievedbymigratingwithoutreimplementationordisruptiontoyourexistinglandscapeorreportingscenarios.KeepreadingtotakeacloserlookatthereasonsforchoosingSAPHANA.

2.1.1Superiorperformancewithasmallerdatabasefootprint

Just by migrating your existing system to SAP HANA you will achieve superior dataloading and query performance. On average, BW queries are at least nine times fastercomparedtothesamequeriesinanSAPBWsystemnotrunningonHANA.

SAPHANAisfast

Basedondatagatheredfromourprojectstodate,SAPHANAexecutesqueries9-23timesfaster(16timesonaverage)thanotherdatabases.Sotheminimumexpectedperformanceimprovement isaroundnine timesfasterforqueriesinHANA.

Theincreasedspeedofdataaccessfromexternal tools isalsoimproved.Forexample,adatabase with 1.2 billion rows of data returned aggregated results in BO Explorer inaround 4.5 seconds. One study published by SAP found that Web Intelligence reportsloadedapproximately12timesfaster.

SAPproductavailabilitymatrix

For a complete list of version requirements for SAP BW on HANA,checktheSAPproductavailabilitymatrix(PAM)foreachtooltoensureconnectivity for existing data sources. http://scn.sap.com/docs/DOC-8693

Itcanbedifficulttoquantifythisspeedimprovementintermsoffinancialsavings.Letslookatasimpleexample.

Lets assume that there are 2,000 query executions per day and the average time is 20

secondsinthelegacydatabase.Thetotaltimespentwaitingforqueryresultsisover11.1hoursperday.WithSAPHANA,thewaittimeis1.2hoursperday,whichisasavingof9.9hoursperday,or2,376hoursperyear!

EvendataloadsintotraditionalInfoCubesandDSOsarearoundtwiceasfast(atleast)asloadingdataintoa traditionalBWsystem.ThismeansyoucanloaddatatwiceasmanytimesperdayasyoudidbeforemigratingtoSAPHANAandstillhavemoresparetimeinyourloadwindow!

The database size for BW on HANA is significantly smaller than the size required intraditionalBWandBWAsystems.Thespeedof the in-memorySAPHANAcalculationengineallowssuper-fastaggregationofdataandfasteraccesstorawdata,sothereisnoneed to pre-calculate aggregates or invest in obsolete hardware for theBWAccelerator(BWA).SAPHANAisalsoacolumnardatabasewhichallowsforsignificantcompressioncomparedtorelationaldatabases.Generally,acompressionfactorof3-5timesisexpectedformosttablescomparedtoOracle,forexample.ThespeedoftheSAPHANAdatabasealsoeliminatestheneedtobuildInfoCubesinSAPBWandhence,eliminatesadditionaldata.This allows your company to spend less on licensing and lowers the total cost ofowninganSAPBWonHANAsystem.

SAPHANAlicensing

SAPHANA licensing is paid only on the production database, whichsavescostsifyouhavemanynon-productionsystemsinyourlandscape.

2.1.2Moreagiledevelopmentandsimplermaintenance

BeforeSAPHANA,SAPBWsystemsreliedontheLayeredScalableArchitecture(LSA)to provide acceptable performance for data loading and query executions. LSA definedbestpracticesformovingdatathroughseveralstagingorpersisteddatawarehouselayersbeforemaking thedata available for reporting in the enterprisedatawarehouse (EDW).SeeFigure2.1foranexampleofLSAinatraditionalBWsystem.

Figure2.1:LSAexample

LSA isa robust andvaluabledesign,but it canbeexpensive todesign, implement, andmaintain,bothfromadevelopmentperspectiveandfromadatabasevolumeperspective.In addition, the fact that there are multiple data staging layers introduces latency inmovingdatafromtheacquisitionlayertothereportandvisualizationlayers,thusdelayingconsumptionofdatabyendusers.

With SAP BW 7.4 on HANA, the LSA architecture is replaced with LSA++.Recommended for SAP HANA only, LSA++ is an updated design and architecturestandardwhich can be used to simplify your EDW architecture. See Figure 2.2 for anexampleoftheLSA++architecture.

Figure2.2:LSA++example

Since the superior performance of HANA does not require traditional data modelingdesigns,suchasstarschemasormultidimensionalmodels,reportingcanbedonedirectlyofftheDSOsintheEDWlayerofthewarehouse.ThisrendersInfoCubes,withredundantcopiesofdata,obsolete.

LSA++ relies heavily on virtual objects instead of copying data between the variouslayers. This reduces the number of objects in each data flow and provides a smallerdatabasevolume,whiledeliveringsuperiorreportingperformance.

InLSA++,thesourcedataisstoredintheOpenODSlayerasrawdataineitherDSOsorinHANA tables.Data inHANA tables can be accessed through calculation views, andDSOsmaybequerieddirectly.

InthecoreEDWlayer,datacanbeconsolidated,cleaned,andtransformed,andthedatacanbestoredincoreDSOsforusebydatamartsinthevirtualizationlayer.

In the virtualization layer, HANA views can be combinedwith data from all the otherlayers.HANAviewsarethevirtualstructuresusedbyqueriesforreporting.

EndofanInfoCubeera

Dont worry! If you have InfoCubes, you can still use them aftermigrating yourSAPBWsystem toSAPHANA.Eventually, youmaychoosetophaseoutyourexistingInfoCubesaspartofanoptimizationproject,butinthemeantime,youcanstillusethem.

InfoCubesarenot theonlyobjectswhichare renderedobsolete inSAPBW7.40,asallmodelingobjectsforstagingdata,fromDSOstoInfoCubes,arereplacedwithadvancedDSOs,andallvirtualmodelingobjects,suchasInfoSetsandMultiProviders,arereplacedwith CompositeProviders. The simplification of modeling choices provides increasedflexibility in design by enabling concepts like field-based modeling and making non-cumulativecalculationsavailabletoalldatamodels.

ItisimportanttoreiterateherethatSAPHANAisanenablingplatform,andmigrationtoitdoesnotrequireacompletereimplementationofyourexistingdatawarehouse.Instead,smalloptimizationprojects targetedatsimplifyingdata flowscanbeundertakenatyourleisure andaccording toyourbudgetarypriorities after the technicaldatabasemigrationhasbeencompleted.

ThereductioninthenumberofobjectsandredundancyofdatavolumesduetoLSA++inconjunctionwiththesimplifieddatamodellandscapecanandwillhaveasignificantcostreduction impactondevelopmentandmaintenanceactivities,onceadopted,byreducingthe duration of each development cycle.While this contributes to the smaller databasefootprint mentioned in 2.1.1, this also means that reports can be developed on yourcompanydatamorequicklythaninSAPBWsystemsadheringtoLSAonotherdatabases.Theshorterdevelopmentlifecyclesignificantlyshortensthetimebetweenareportrequestanddeliveryofthatreporttoyourusers.

2.1.3Landscapesimplificationandreal-timereporting

WithSAPHANAasyourSAPBWdatabase,youcandeveloporconsolidateyournon-BW data warehousing applications in the same database as SAP BW. SAP BW 7.40enables the cross-consumption of non-BW data in BW via Open ODS Views andCompositeProviders. It enables consumption of BW data in native HANA byautomatically generating modeling views on all BW objects. These views can also beaccessed directly from SAP BusinessObjects (BOBJ) tools such as Analysis, DesignStudio, BOExplorer, and Lumira.Web Intelligence andDashboards still require eitherBEx queries from InfoProviders built from calculation views, or the construction ofuniversesthroughtheInformationDesignTool.

SAP BW on HANA provides your company with the tools needed to respond to the

changing business environment at a moments notice. With SAP LandscapeTransformation (SLT), data can be loaded to your companysBWonHANA system inreal time. SLT allows for reporting on your business needs as soon as transactions arecompleted in the system.There is no longer any need towait for nightly data loads tounderstandthebusinessofthepreviousday.

With Smart Data Access (SDA), smaller data volumes can be read directly in HANAmodeling viewsorCompositeProviderswithout ever persisting it inSAPBWor nativeHANA.This functionalityenablesyourSAPBWonHANAtobecomeafederateddatawarehouse,thuseliminatingtheneedtopersistalldatadirectlyinHANA.Withtheadventofdynamictiering,non-essentialdatacanbepersistedincheaperstorage(suchasSybaseIQ)andreadintoHANAondemand(likeSAPNLSforBW).

2.2Staffing

Staffing needs for the DMOmigration will depend on the size of the project. Severalscenariosarepossibleandexamplesaregivenbasedonstaffingneedsdeterminedduringreal projects. DMO projects will generally fall into one of three categories: small,medium,andlarge/verylarge.

2.2.1Smallprojects

Migrations of less than approximately 5 TB of data (beforemigration) and ofmediumcomplexity are considered small projects. For small projects, the work is best dividedbetweenthecoreteamandthetestteam.Thecoreteamforasmallprojectshouldconsistof the project manager, a BW Basis support person, a HANA Basis support person, aHANAdeveloper formodellingandoptimization,andaHANAtest lead.The test teamshouldconsistofafunctionaltesterforeachbusinessareaincludedinthemigration.

Figure2.2:AsmallDMOprojectteam

For this project, the total project time was 14 weeks. The company was using a four-system landscapewith sandbox, development, acceptance, andproduction environmentsand had an additional system on hot standby providing disaster recovery. During theproject,thecompanytransitionedfromBWA7.0toHANAaspartofthemigration.ThishadtheaddedbenefitofallowingthecompanytoretirethelicenseforBWAforalowertotalcostofownership.

During the project referenced inFigure 2.2, the test teamwas assignedduring the nineweeksofthemigrationtotheQAandproductionenvironments.Thetestteamconsistedofexperiencedusers for theBWsystemwhoneededvery little training toexecute the testplans for themigration.Also, only the InfoCubes from SDwere optimized during thismigration.

2.2.2Mediumprojects

Migrationsoflessthan10TB(beforemigration)withmediumcomplexityareconsideredmediumprojects.Mediumprojectteamsmustconsistofthecoreteamplusonetestteamfor eachmajor business area.A separate test team should be staffed to provide generaltestingnotspecifictoamajorbusinessarea.Projectsofmediumsizeorlargershouldalso

staff a project advisor with experience in large-scalemigrations to assist with problemresolutionduringtheproject,althoughthispositionisusuallynotafull-timeresource(seeFigure2.3).

Figure2.3:AmediumDMOprojectteam

Thetotalprojectdurationinthisexamplewas18weeks.Thiscompanyhadafour-systemlandscapewithmore than400DSOsandmore than600 InfoCubes.Businesspersonneltested the query performance of theBOBJ reports,while technical testers executed testplansfordatareconciliationandprocesschains.

2.2.3Largeandextra-largeprojects

BWmigrationswithmore than 10TBof datawith high complexity are categorized aslarge(orevenextra-large)projects.Thesameprinciplesappliedinmediumprojectsapplyto large projects. The differences lie in the project duration, size, and number of testteams.

Again,eachbusinessareaneedstohaveadedicatedtestteam.Thesetestteamsforlargeprojects usually consist of two functional testers, aswell as a test lead forHANA andanotherfortheBWsystem.

ThestaffingexampleinFigure2.4wasusedinamigrationofa38TBBWsystemwithhighcomplexity.Inthisproject,morethan1,300datastores,morethan1,700InfoCubes,andmorethan2,600querieswereincludedinthemigration.Verylittleoptimizationwasperformedaspartoftheproject.

Figure2.4:AlargeDMOprojectteam

2.3Sizingthemigration

ThereareseveralmethodsavailableforestimatingtherequiredsizeofaHANAsystem.ThemostcommonmethodsincludetheT-shirtmodel,therule-of-thumbapproach,andtheSAPBWonHANAautomatedsizingtool.

ImportantnoteontheSAPQuickSizer

The SAP Quick Sizer provides another method for estimating therequired hardware sizes in HANA, but the Quick Sizer is onlyappropriate for use when estimating the size of a greenfield BW onHANAimplementation,sothismethodisnotexaminedindetailinthis

book.

2.3.1T-shirtsizingmodel

TheT-shirtsizingmodelismeanttoprovideaveryroughideaofthehardwarethatwillberequiredforaBWonHANAmigration,sothismethodisonlyappropriateforprovidingabasicideaofthehardwareneedsinaproject.AfterdecidingtomoveforwardwithaDMOmigration, theSAPBWonHANAautomated sizing tool shouldbeused toprovide themostaccurateestimateofyourcurrentandfuturehardwareneeds.Figure2.5providestheT-shirt model for those who want basic information about their hardware needs whenmigratingtoHANA.

Figure2.5:T-shirtsizingmodel

Theearlywatchreport

Thenumberofactiveconcurrentusersandnamedusers is theprimaryfactor to considerwhen determining the number of processors neededforBWonHANA,soitisveryimportanttohaveaccurateinformationwhenmakingthisdecision.TheearlywatchreportfromthecurrentBW

implementationwillprovidetheinformationneededtomakethisdecision.

2.3.2Rule-of-thumbsizing

Therule-of-thumbapproachtoBWonHANAsizingprovidesasimplesetofguidelinesfordeterminingthehardwareneededfortheDMOmigration.Itisimportanttorememberthat thisapproachtosizingisstillnotasaccurateas theSAPBWonHANAautomatedsizing tool, but the rule-of-thumb method will provide a more accurate assessment ofsystemneedsthantheT-shirtmethod.

Memory

To enable you to estimate the amount of memory needed in a BW on HANAimplementation,SAPNote1637145providesaprogramcalledget_size.zip.Thisprogramshouldbeextractedandexecutedagainst theexistingBWimplementation.Theprogramwillprovidethecurrentrowandcolumnstoresizesforyourexistingsystem.ThesesizesarethenusedintheequationinFigure2.6.

Figure2.6:Rule-of-thumbformemoryestimation

In this equation, 50 GB is allocated for HANA services and caches. The row storefootprintisdividedby1.5astheexpectedcompressionforrowstoretables.Thecolumnstorefootprintismultipliedby2toallowspaceforruntimeobjectsandtemporaryresultsetsinHANA.Thecolumnstorefootprintisdividedby4astheexpectedcompressionforcolumn store tables. The existing database compression variable represents anycompressionappliedtothecurrentBWsystem.Ifnocompressionexists,justenteravalueof1fortheexistingdatabasecompressionvariable.

Diskspace

DiskspacecanbeestimatedwiththeequationinFigure2.7.

Figure2.7:Rule-of-thumbfordiskspaceestimation

To estimate the disk space needed for the persistence layer, multiply the result of thememorycalculation inFigure2.6by4.The log fileswill also requireapproximatelyasmuchspaceastheoverallsystemmemory,soaddthisvaluetotheresultcalculatedinthepersistence layer to estimate the total overall disk space needed for theBWonHANAsystem.

Thepersistencelayeristhediskthatprovidessystemsecurityandredundancyintheeventof memory failures. For this reason, the size of the persistence layer must not beunderestimated,especiallyconsideringthecomparativelylowcostofdiskspace.

CPU

ThenumberofCPUsrequiredcanbeestimatedusingtheequationinFigure2.8.

Figure2.8:Rule-of-thumbforestimatingthenumberofCPUs

The number of CPUs determines the number of cores needed for the BW on HANAimplementation.Tocalculate this, find themaximumnumberof active concurrentusersfromtheearlywatchreportandmultiplythatnumberby0.2.

2.3.3SAPBWonHANAautomatedsizingtool

The SAP BW on HANA automated sizing tool is part of the SAP NetWeaver BWMigration Cockpit for SAP HANA. SAP Note 1909597 contains instructions and theABAPcoderequiredforinstallingthemigrationcockpit.Themigrationcockpitmustbeinstalled and activated using theSE38 transaction code in theSAP front end.Once themigrationcockpithasbeeninstalledandactivated,executingtheprogramfromtheABAPeditorwillopenthecockpitasshowninFigure2.9.

Figure2.9:SAPNetWeaverBWMigrationCockpitforSAPHANA

From themigration cockpit, click the tab labelledSIZE, and then click the SIZING TOOLbutton.ThiswillopentheSAPBWonHANAautomatedsizingtoolasshowninFigure2.10.

Figure2.10:Sizingtooloptions

Picktherighttool!

TheSAPBWonHANAautomatedsizingtoolisthepreferredtoolforcalculating the correct hardware for the DMO migration. The t-shirtmethodand therule-of-thumbapproachareonlyappropriate for initialhardwareestimates.

Whentheoptionsforthesizingtoolareopen,theoutputfilenameshouldbechangedtosomethingthatiseasytoremember.Thesizingtoolconsiderstheexistingdatabasetypeaswellasotherparameters,suchas table types. Itevenconsiders the impactofnon-activedatawhenperformingcalculations inorder toprovide themostaccurateresults.Severaloptionsmaybeadjustedtoallowthetooltoreturnresultsthatareasaccurateasrequiredin themost efficientmanner possible. For example, choosing to suppress tables of lessthan1MBwillincreasethespeedofthecalculations.

Longruntimes!

Remember that choosing the highest precision will cause thecalculations to take much longer. For example, runtimes of 30-60minutes, or even several hours, are not uncommon with a 10 TBdatabaseand12parallelprocessors. Inmostcases, the lowormedium

precisionoptionsaregoodenough.

2.4Budgeting

WhenbudgetingforaDMOproject,youhavetoconsidernumerousfactors.Infrastructureandlicensingmayseemobvious,butdonotoverlooktheneedforinterimhardwareandlicensing for the PCA tool if you plan based on a downtime-minimized migrationapproach.Inaddition,increasedsupportcostsinrelationtoanyparallelrunofproductionshouldbeincludedinthebudgeting.

Sufficientfundsmustalsobeallocatedtoallowfortrainingboththeprojectteamandthesupport team. The project team must be trained before the project starts, and thesustainmentteammustbetrainedandavailableforintegrationandtestingduringtheQAandproductionmigrations.Finally,thesalaryandtrainingcostsforthesustainmentteamafterthemigrationmustbeconsidered.

2.4.1Training

TrainingfortheBWandHANABasissupportteammembersshouldbecompletedbeforethe project starts. Often, training for these teammembers will be completed while thehardwareisbeinginstalledduringthefinalmonthsbeforethemigrationprojectofficiallybegins.TheprojectmanagershouldscheduletimeduringthehardwareinstallationphaseoftheprojectfortrainingtheBasispersonnel.

Picktherightpeople!

Toomanyprojectsfailbecausethecompanychoosesthepeoplethatareavailableinsteadofchoosingthebestpeopleforthejob.Remembertoplanfarenoughinadvancethattherightteammemberscanbeallocatedastheyrollofftheircurrentprojects.

In general, companies can expect to spend $3,000 to $6,000 for official SAP trainingcoursesforeachteammember.Someofthesecoursescanbetakenonline,butforcoursesthatarenotavailablethrougharemoteconnection,thecostsoftravelandexpensestothetrainingsitesshouldalsobeincludedinthebudget.Moreinformationontrainingcanbefoundathttp://training.sap.com.

2.4.2Continuedsupport

ThecostofcontinuingsupportforSAPBWonHANAshouldbeapproximatelythesameas the support costs for a traditional BW system because the administration tasks areconceptuallysimilar.However,theadministrativetasksarealsogenerallyfasterinHANAbecausetheyleveragethespeedoftheHANAenvironmentfortheirexecution.

OneBasispersonwillbeneededforsystemadministrationandmonitoringforeveryfouror five environments. In addition, onepart-time resource is required for security access

and role administration, with the level of effort dependent upon the number of activeconcurrentusersandnamedusers.

Thefollowingtasksmustbedelegatedandassignedtothesupportpersonnel:

UserandrolemaintenanceSecuritymaintenanceBackupanddisasterrecoverymonitoringandcomplianceLoadbalancing,monitoring,andhardwaremaintenanceSoftwarepatchesandnotesforHANA,BW,andothersoftwarecomponentsCleanupofnear-linestorage,archiving,andlogfilesTransports,tablecopies,systemcopies,anddatacopiesPeriodicsystemupgrades

2.5Programmilestones

ThegeneralstepsforanSAPBWonHANAmigrationprogramare:

1. Definethemigrationstrategy,approach,andtactics2. Chooseandprocurehardware3. Preparelandscape(PCA,securityconversion,etc.)4. Executethemigrationapproach5. Transitiontosupport6. OptimizeexistingarchitecturetoLSA++(optional)7. Implementadditionalservices(SLT,BODS,etc.)8. UseLSA++techniquesinfuturemodelling

Amoredetailedmilestoneplanforadowntime-minimizedDMOmigrationprojectis:

1. Procurelicensing(HANA+LVM)2. Provisionhardware(HANAlandscape+interimhardware)3. Providesystemaccesstoprojectteam4. PreparesourceBW5. PrepareforUnicodeconversion6. InstallPCAonallSAPsystems7. PrepareforPCAexecution8. Cloneandsynchronizesourcesystemdeltaqueues9. ConducthomogenousDBcopytointerimsystem10. Executepost-copyautomationtasks11. Conducthousekeeping/cleansingininterimsystem12. Prepareformigration13. Prepareforupgrade14. UpgradewithDMO15. Executepost-migrationtasks16. Cutoverusersandinterfaces17. ProvideHyperCare18. Transitiontosupport

AsamplemilestoneplanfromanexistingprojectisshowninFigure2.11.

Figure2.11:SampleDMOprojectplan

The DMO project milestones can be broken down into several major categories. Theproject time assigned to each category will be determined based on the size andcomplexityofthemigration.

Contingencyplanning!

Itisabsolutelycriticalthattheprojectplancontainsacontingencytimeplan. No project manager has the ability to foresee every possibleproblemthatcanarise,andbuildingafewdaysofcontingencytimeintoeachphaseof theprojectwill allow theproject team time toadjust to

theseunforeseenproblems.

2.5.1Onboardingandsetup

DuringthefirsttwotofourweeksofaDMOproject,theprojectplanmustbewrittenby

theprojectmanagerwithsupportfromthestakeholdersandprojectsponsor.Theleadersofeachprojectteammustalsodevelopdetailedworkplansforeachphaseoftheproject.Once the project plan is finalized and milestones are established for each phase, anychangethatwillimpacttheprojectbudgetormilestonewillrequireachangerequestandapprovalfromtheprojectsponsor.Thetestteamleadsshouldalsodeveloptheirtestplansduring this phase of the project, with the understanding that further test plans may berequiredbasedontheresultsoftheinitialunittests.

Projectrisk!

Themost likely point of failure in anyHANAmigration is caused byfailing to adequately plan for hardware procurement and delivery,infrastructure setup, and data center preparation. Currently, hardwareprocurementusually requires six toeightweeks, so selectandprocure

thehardwarebeforetheprojectbegins.

By this time, theBasis team shouldhaveverified that the environments to bemigratedmeet theprerequisites for aDMOmigration. If enhancementpackagesor servicepacksareneeded,thesemustbeappliedandthesystemmustbestabilizedbeforethemigration.

The final piece of the onboarding process involves personnel allocation. Consultantsshould travel to theproject locationand team-buildingactivities shouldbe scheduled toacquaint themembersof thevarious teamswitheachother.Thevalueof team-buildingactivitieswill becomeobvious later in theprojectwhenproblemsarise.Teammemberswill rely upon the rapport established at the beginning of the project to focus on theproblemathand,insteadofinterpersonalissues.

2.5.2BW7.4testing

Inparallelwiththeonboardingandsetupphase,theBasisteamcaninstallBW7.4onthesandboxappliancewithoutHANAintegration.ThisallowstheBasisteamtoidentifyanypotentialproblemswhichmayariseintheupgradefrompriorversionsofBWtoBW7.4without HANA integration adding complexity to the problems. Any problems that areidentifiedduringthisphasecanberesolvedpriortothemigrationprocess.

During the testingphase, theBasis team should alsobegin creating a runbookwith thespecific, detailed steps required for each step of the BW 7.4 upgrade processes. Thisrunbookwill be extended and refinedwithmore details andworkarounds through eachstepintheDMOprocess.

Samplerunbook!

SeeChapter6forasamplerunbookcreatedandcompiledbytheprojectteamsfromseveralreal-worldDMOprojects.

2.5.3Training

Trainingmustbecompletedfor theproject teamduring thefirst two to fourweeksofaprojectandbeforetheBWtoHANAmigrationbegins.ItiscriticalthatallDMOprojectteammembershavetherequiredtrainingfortheirareasofresponsibilitybeforetheactualmigrationstarts.Withouttraining,thesuccessofanyprojectisatasevereriskoffailure.

Rememberthatthesupportstafffortheprojectmustbetrainedbeforethemigrationinthequality assurance (QA) environment begins. This allows the support staff to gainexperiencewith theirprocesses in theQAenvironmentwithoutbeingexpected toapplywhattheyknowtotheliveproductionsystem.Bytrainingthesupportstaffearly,therisksoferrorsintheproductionsystemaregreatlyreduced.Earlytrainingofthesupportstaffalsoeasesthetransitionofsystemresponsibilityfromtheprojectteamtothesupportstaff.

2.5.4Developmentenvironment

The migration of the development environment (Dev) will typically be completed asquicklyaspossibletominimizethetransportfreezeandreducethemigrationwindow.Theamount of time needed will vary based on the project requirements. The runbookdevelopedduringthesandboxmigrationwillbeusedandfurtherrefinedduringthisphaseof the project. The project team can further develop the runbook to document everyproblem and every resolution discovered along the way to use in the business-criticalmigrationoftheproductionenvironment.

Again, the runbook must be updated with every step of the process no matter howordinary. For this reason, themost detail-oriented person from the core team should betaskedwithcreatingtherunbook.Therunbookwillbecomethesavinggraceoftheprojectduringthepushtoproduction.Bythetimeoftheproductionmigration,everyconceivableproblem should have been documented and resolved.The time needed for this upgradeandmigrationwilldependonthesizeofthedatabaseandthenetworkinfrastructure.Forexample, themigrationof theDevenvironment in a typicalmid-sizedprojectmay taketwotofourweeks.

Assoonasthemigrationandupgradearecomplete,unittestsshouldbegin.Thetestteammustexecutetheirtestplansandreporttheresultstothecoreteam.Thecoreteammustthenmakeanyadjustmentsneededbasedon theseverityof the issues identified.Again,eachissuemustbedocumentedintherunbookalongwiththestepsnecessarytoresolvetheissue.

At the end of this phase, a few days should be allowed to update plans and apply thelessons learned to the planning for the next phase of the project. If critical issues have

beenidentifiedwhichwillimpactlatermilestones,achangerequestmustbesubmittedtoaddress the issues. If contingency time has been properly allocated in the project plan,thereshouldbelittleriskofaproblemwhichwillrequireachangerequest.However,noteveryprojectgoesaccording toplan,sodonotneglect thischeckpoint toevaluatewhathasbeenlearnedandapplythatexperiencetotherestoftheproject.

Production-sizedmigrationtestneeded!

Beforeyoucanbegintheproductionmigration,youneedtomakesurethatyoucompleteamigrationofanenvironmentthatisthesamesizeasyourproductionenvironment.ThiscanbecompletedinthesandboxorQAenvironments,oryoucanevencompleteadryrunintheproduction

environmentusingthedowntime-minimizedapproach.

2.5.5QAenvironment

In many ways, this phase of the project is a dress rehearsal for the final push toproduction.Migrationandupgradeof theQAenvironmentshouldbethelongestoverallphaseoftheDMOprojectandwilltypicallytakesixtotwelveweeks.TheQAmigrationisthelongestbecauseat least twomigrationandtestcyclesshouldbeplannedasthisisthefinalstepbeforethemigrationtoproduction.Assuch,thisisthelastchancetoidentifyandresolveissueswiththeupgradetoBW7.4andthemigrationtoHANA,soextracaremustbetakentomitigateeverypossibleriskbeforemovingtoproduction.

TheDMOrunbookdevelopedduringtheDevupgradeandmigrationmustbeappliedtothismigration,andeveryeffortmustbemadetorefineandexpandtherunbook.

Runbook,runbook,runbook!

Bythispoint, the importanceof the runbookshouldbeobvious,but itbears repeating that the runbook canmakeor break theproject. If therunbookisnotsufficientlydetailedsoastoincludeeverypossibleissue,how will the core team remember the solutions they discovered in

earlierpartsoftheproject?

AftertheupgradetoBW7.4andmigrationtoHANA,thefirstfunctionaltestcyclemustbecompletedandtheresultsmustbepresentedtothecoreteam.Thecoreteamwillthenresolve the issues reported, and a new test cyclewill begin.After the second round oftesting has been completed, if there are no issues, the push to production can begin.However, if serious issues are still present, theymust be resolved and those resolutionsvalidatedbyexecutinganotherfulltestcycle.

Dontrush!

Remember, this is the last chance to resolve problems before theyimpactthebusiness,sodonotrushthisportionoftheproject!Thisistheperfect opportunity to use the contingency time built into the projectplantoaddtestcycles,butdoNOTrushthepushtoproduction.

2.5.6Productionenvironment

Ifthepreviousenvironmentupgradeswerecompletedproperly,theupgradeandmigrationof the production environment should be reasonably easy. This portion of the projectshouldonlybeginwhentheQAenvironmentupgradeandmigrationhasbeencompletedsuccessfully and the project team has approved the push to production in the finalcheckpoint.

Beforetheupgradeandmigrationoftheproductionenvironment,verifythatanaccurateand current copy of the production environment is saved to the companys disasterrecoverysolution.Thisistheprojectlifelineincasethingsgowrongduringthemigrationandupgradeofproduction,soDONOTskipthisstep.

Themigrationandupgradeofproductionshouldgenerallytakeplaceoveralongweekend(such as Labor Day in the United States). A specific and detailed timeline must bedevelopedbeforethisphasebegins.Thetimelineshouldincludecheckpointsevery12to24hours,duringwhichtheprojectmanagerandprojectsponsormustdecidewhetherornottomoveforwardwiththeprocess,ortorestorefrombackup.

Checkpointsneeded!

Do not forget to plan GO/NO-GO checkpoints during the productionupgradeandmigration.

Immediately after the production environment has been migrated and upgraded, thestabilization and production phase of the project begins. When the productionenvironmenthasbeencertifiedasstable,andonlyAFTERtheenvironmentisstable,donot forget to replicate thenewversionof theproduction environment to the companysdisasterrecoverysolution!

2.5.7Stabilizationandoptimization

Assoonastheupgradeandmigrationofproductionhasbeencompleted,stabilizationandoptimizationbegin.Duringthisphaseoftheproject,thecoreteamisonclosestandbyandis ready to respond toany issuesassoonaspossible.Thisphaseof theproject lasts forapproximately three to sixweeks.During this phase,when they are not busy resolving

issues, the core team can use this time to performance-tune anyABAP transformationsandaddressanyfinalperformanceproblems.

2.5.8Projectcloseandhand-off

Usuallyaroundsixweeksafterasuccessfulpushtoproduction,theprojectmanagerandprojectsponsorwillmeettodiscusstheproject.Thisisthetimetodocumentthelessonslearned so that they can be applied to future projects. This is also the time for a frankdiscussionabout the things thatwentrightduringtheproject,aswellas toevaluateanyopportunitiesforimprovement.

3Hardware,optimization,andSAPBusinessObjectsintegrationInChapter2,webegantheprocessofplanningyourSAPBWonHANAmigrationbydiscussingthebusinesscaseforHANA,staffing,sizing,budgeting,anddevelopingtheprojectplan. InChapter3,wewill consider thehardware that is available foryour SAPBWonHANA systems aswe continue the process of planning for yourcompanysmigrationtoSAPBWonHANA.

3.1Hardware

SAPHANAisanapplianceforin-memoryprocessing.ThismeansthatboththehardwareandthesoftwareforSAPHANAaresoldasacompletesystem.HANAsystemsrequirethepurchaseofathree-yearmaintenancelicense,andonlyhardwarevendorsorcertifiedSAP partners should install SAP HANA and its components on the system hardware.Approvedvendors forHANAhardware solutions includeSiliconGraphics,Cisco/EMC,Dell,Hitachi,Huawei,Fujitsu,NEC,IBM,andHewlett-Packard.

Thesummerof2014wasnoteworthybecausethenewIntelXeonE7CPUsfirstbecameavailable. TheXeonE7CPUs are known as the IvyBridge chipset and they aremuchfaster than the previous generation of hardware. Ivy Bridge processors have 15 coresinsteadof the10coresthatwereavailableinpreviousversionsof theE7processor,andthey also have faster clock speeds. While several processor variants are available,includingthe2880/90,4880/90,andthe8880/90,onlythe4880/90and8880/90areinuseincertifiedSAPHANAappliancesatthetimeofwritingthisbook.

When planning for your implementation of SAP BW on HANA, you must considerwhethertodesignthesystemtoscaleuporscaleout.Scalingupmeansincreasingthesizeofeachnode(i.e.,from1TBto2TB).Scalingoutmeansincreasingthenumberofnodesinthesystem(i.e.,from4x1TBnodesto8x1TBnodes).

3.1.1Scaleup

A scale-up implementation has the benefit of requiring the purchase of a single nodesystem,withalowerinvestmentinhardware,datacenterspace,andpowerconsumption.WediscussedproperlysizingyourBWonHANAsysteminSection2.3,soyoucanusethechartinFigure3.1toselectaconfigurationthatmeetsyourneeds.

Figure3.1:Scale-upsolutionsforSAPBWonHANA

3.1.2Scaleout

Scale-out systems are created by linking several nodes together over at least a 10 GBnetwork. The primary benefit of scale-out systems is that by linking several nodestogether, you can create large SAP HANA systems with hundreds of CPU cores, vastamountsofRAMforthein-memorydatabase,andtensofthousandsofusers.

BWrequirementsonscale-outsystems

IfyouaremigratingyourSAPBWsystemtoascale-outsystem,SAPrecommendsamasternodewithaminimumof1TBandat least twoslave nodes and a standby node for a four-node appliance. See SAPNotes 1855041 (Sizing Recommendation forMaster Node in BW-on-

HANA) and1702409 (HANADB:Optimal number of scale-out nodes for BW onHANA).

There are numerous possible configurations and approaches for scale-out systems, somakesureyoucheckthePAManddiscussscale-outoptionswithyourhardwarevendorswhenpreparingtopurchaseyournewsystem.

Shoparound!

It is important to obtain quotes from at least two different hardwarevendors when procuring your HANA hardware and to inform thevendors that other vendors are involved in the bidding process.Whenvendorscompetetogainyourbusiness,yourcompanywillbenefitfrom

betterprices.

3.2Optimization

WhenplanningamigrationofSAPBWtoHANA,youshouldplanforasecondphaseoftheproject,theoptimization,orfunctionalmigration,oftheBWsystem.Duringthisphaseof themigration,youwillmodify thedatastructures to fully leverage theadvantagesofSAPHANA.

Recommended,notrequired

IfyoudecidenottooptimizeyourBWsystem,yourdatabasewillbeonSAP HANA, but your queries, links to near-line storage, data loads,interfaces, and querieswill be functionally the same. These processeswill be fundamentally faster because of the speed of the SAPHANA

calculationengine,butafunctionalmigrationisstill recommendedtooptimizeyoursystemtofullyleveragethepowerofHANA.

The steps required to optimize your SAP BW on HANA system may include acombinationofthefollowingsteps:

InfoCubeoptimizationTransitioningtotheLSA++architectureABAPcodeoptimizationDataflowconversionInfoCubefacttablecompression

Letstakeacloserlookatsomeoftheoptimizationsteps.

3.2.1OptimizingInfoCubes

While standard InfoCubes can still be used with SAP BW on HANA, we recommendconverting them to HANA-optimized InfoCubes. With optimized InfoCubes, assigningcharacteristics and key figures to dimensions does not cause the system to create anydimension tables besides the package dimension. Before optimization, InfoCubes werestructuredasshowninFigure3.2.

Figure3.2:InfoCubemodelbeforeHANAoptimization

Instead,masterdata identifiers, commonlyknownasSIDs, arewritten to the fact table,and dimensional keys are not used. This flattened InfoCube structure yields faster datareadsanddataloads.Inessence,dimensiontablesbecomesemantic,logicalunitsinsteadofseparatetables.ThesesemanticunitssimplifythetaskofcreatingqueriesthroughBExQueryDesigner.HANA-optimizedInfoCubesarestructuredasshowninFigure3.3.

Figure3.3:HANA-optimizedInfoCubemodel

InfoCubes can be optimized through the BWAdministratorWorkbench, or through anSAP-delivered program, RSDRI_CONVERT_CUBE_TO_INMEMORY. If you use theAdministratorWorkbench,youwillhave toconverteach InfoCubemanually,but ifyouuse the RSDRI_CONVERT_CUBE_TO_INMEMORY program, you can select all theInfoCubes you want to convert. The program is quite fast and will usually finish the

conversionswithin10-20minutes,evenforvery largeInfoCubeswithmillionsof rows.UserscancontinuetoquerytheInfoCubesduringconversion,butanydataloadswillneedtobesuspendedwhiletheconversionisinprogress.

Bewareofcustomprograms!

SincethestarschemaofanoptimizedInfoCubeisdifferentfromitspre-conversion format, any custom program that has been developed todirectly access the original InfoCube must be rewritten. Only a fewcompanies have custom-developed programs to directly access

InfoCubes,but ifyourcompanydoeshavesuchprograms,youwillhave tomodifythemtoworkwithHANA-optimizedInfoCubes.

OptimizedInfoCubesareassignedalogicalindexandaremaintainedinacolumnstoreoftheHANAdatabase.AnyInfoCubesthatwerestoredinanSAPBWAccelerator(BWA)systemwillbesettoinactiveaspartoftheconversion.Theywillneedtobereactivatedandloadedwithdatabeforetheyareusedforreporting.

DoInfoCubeshaveafuture?

While the futureof InfoCubes is in somedoubt, ascanbe seen in thespiriteddebatesinonlineforumsandblogs,theyarestillneededinSAPBWonHANA.Transactional InfoCubes play a key role in integratedplanningandwrite-backoptions,aswellasforstorageandmanagement

ofnon-cumulativekeyfigures.Theyarealsoneededbecausecustomersneedthemtoavoid having to rewrite application logic,MultiProviders, data transformations, andqueriesthatwerebuiltinpreviousversionsofSAPBW.Movingforward,InfoCubeswill likely fall outofuse innewdevelopment, asSAPHANArenders theneed forrelationaldatabases,andthecomplicatedstructureofInfoCubes,unnecessary.

3.2.2TransitioningtotheLSA++architecture

WediscussedLSA++inSection2.1.2of thisbook,sowewillnotcover thebenefitsofLSA++indetailhere.JustbeawarethatthenewarchitecturetakesadvantageofthespeedofHANAtorenderthesplittingupoftablesanddatastagingoftheolderLSAarchitectureunnecessary.Theoldarchitecturewillstillwork,butthelevelofeffortyourcompanyiswillingtoexertshoulddependonhowquicklythemigrationmustbecompletedandthenumberofpersonnelthatareavailabletohelpinthelandscapeoptimization.

3.2.3ABAPcodeoptimization

Withoutoptimization,somesinglerecordlookupsindata transformationsmayrunmoreslowlywhileloadingdataintoSAPBWonHANA.Youarenotrequiredtooptimizethe

codeforthesetransformations,butSAPhasrealizedthatitismostlikelyagoodideatodoso. To help identify transformations with suboptimal coding, SAP provides the ABAPRoutineAnalyzer program as part of the SAPBWMigrationCockpit for SAPHANA.This program will identify transformations with potential problems and also providessuggestionsforhowtooptimizethecode.

3.2.4Dataflowconversion

SAPhasprovidedadataflowconversiontoolaspartoftheSAPBWMigrationCockpitforSAPHANA.Aspartofthedataflowconversion,thetoolcreatesacopyoftheolderBW 3.x data flows, and then converts the copy. This means that your old data flowsremain intact while you test the migration, and they can be deleted once the testingprocessiscomplete.

3.2.5InfoCubefacttablecompression

While you can no longer partition InfoCube fact tables after they have been converted,fourpartitionswillstillexistbehind thescenes.One isusedforuncompressedrequests,and another is used for compressed requests. The third partition is used for referencepoints for inventory data, and the fourth is used for historical data about inventorymovements.The thirdandfourthpartitionswillbeempty ifnon-cumulativekey figuresarenotused,butthefirsttwopartitionswillneedcompressionperiodicallytodecreasetheamount of space they require and increase their load times. This compression shouldrequire very little time, even for very large InfoCubes, because the compression isperformedasastoredprocedureinHANA.

3.3WhatisBIself-service?

Overthelast15to20years,datawarehousesandBIhavebeenrolledouttoendusersandpower users inmany companies. The problem is that long delivery times for IT reportdevelopment have caused end users and power users to create their own reportingsolutions, often in Excel. BI self-service uses the BOBJ tools to empower users toeffectively move their reporting efforts into the official SAP BOBJ tools. The latestversionsofBI4.1 toolshavebeensimplifiedandstreamlined toallowpowerusersandenduserstodeveloptheirownreports.Thisresultsinamuchshorterdevelopmentcycleandincreasesyourcompanysabilitytoadapttoitsever-changingbusinessneeds.

SAP interviewed users from various roles in organizations using SAP to discover howtheyweremanagingreportingwhilewaitingforITtodevelopofficialreports.Theyfoundthat the users were spending around 80% of their time manually combining data,transformingitasneeded,andevendoingcalculationswhichhadtobeverifiedrepeatedlybeforemeetingtheiradhocreportingneeds.

In order to streamline this process, SAP developed BO Explorer for managers. VisualIntelligence, renamed as Lumira in the latest versions, was developed as a simplifiedsolution for analysts. You can expect these tools to become better integrated, withimprovedcapabilities,overthenextcoupleofyears.

3.4BusinessObjectsintegration,mobilization,andconnection

Inorder tobe successful inyour companysmigration toSAPBW7.4onHANA, it isimportant to plan for integration with the BI 4.1 reporting platform and the SAPBusinessObjectstoolset.

3.4.1BusinessObjectsintegration

Figure 3.4 shows the SAP BusinessObjects toolset, as well as the target users, targetdevelopers,andcapabilitiesofeachofthetools.

Figure3.4:BOBJtoolsandpreferredcapabilities

When implementingaBI self-service solution foryour company,you should rememberthatfewcompaniesrolloutthecompletetoolsettotheirusersallatonce.Instead,mostcompaniesimplementasolutiongraduallybyrollingouttwoorthreetoolstotheirusersbasedonwhichtoolismostappropriatetomeettheirneeds.Youshouldalsorealizethatprovidingaccesstothetoolsisonlypartoftheimplementation.Trainingforthesupportteamandendusers isat leastas importantasdeploying the toolsandallowingusers toaccessthem.

Whendecidingwhich tools to implement first, considerhowyourcompany iscurrentlymeeting their reporting needs. Then, decide which BOBJ tool is the closest fit for thecurrentwayofdoingthings,whilefullymeetingthegrowingneedsof thebusiness.SeeFigure3.5forhelpdecidingwhichtoolsbestmeettheneedsofyourbusiness.

Figure3.5:Self-servicetoolselector

SAPBusinessObjectsDashboards

SAPBusinessObjectsDashboardshasbeenrenamedseveraltimesaseachnewiterationofthe toolhasbeen released, soyoumayalsohearDashboards referred toasXcelsius,orSAPCrystalDashboards.Dashboards facilitates interactiveanalysisofdatausingmaps,charts, graphs, slider bars for what-if projections, and other custom objects. WhileDashboardsiscommonlyusedasatoolforinteractivedataanalysis,duetotheflexibilityand power of SAPDesign Studio, Dashboards will likely losemarket share to DesignStudiointhenearfuture.AsampledashboardisshowninFigure3.6.

UserscanconnecttoyourcompanysSAPBWusingtheBusinessIntelligenceConsumerServices (BICS)connections, throughuniversescreated in the InformationDesignTool,and even throughWebServiceswith aQuery as aWebService (QAAWS) connection.SAPHANAenhancesthepowerofDashboardsbydisplayinglargevolumesofdatamorequicklythaneverbefore.

Figure3.6:Asampledashboard

SAPBusinessObjectsWebIntelligence(WEBI)

SAPBusinessObjectsWeb Intelligence is in commonuse as a tool for adhoc analysis.WithWebIntelligence,businessuserscanaddfilters,charts,tables,andcustomvariablesto develop their own reports in the BI self-service model. Web Intelligence can beaccessed througha locally installed richclient, through theBILaunchpadusinga Java-basedclient,orthroughanHTMLwebclientbyopeninganexistingreport.

TheadhocnatureofWeb Intelligenceallowsusers tobuild reports that are focusedonexactlythebusinessareastheyneed.Otheruserscanthenchoosetoeitherusethereportasoriginallydesigned,ormodifythereporttodrilldowntoexactlythedatatheyneedfortheirparticularbusinessareas.Thesemodificationscanthenbesavedasthedefaultviewfor that report,orusers canexport their reports toExcel,CSV files,or even images.AsampleWEBIreportisshowninFigure3.7.

Figure3.7:AsampleWEBIreport

SAP HANA extends the capabilities of Web Intelligence by delivering faster queryperformance,whichgreatlydecreasesthetimeneededtopopulateareportwithdata.Withfaster reports, theneed topre-run reports isalleviated.Reportscanalsobecreatedwithmore user prompts (and greater drilldown capacity) without worrying about theperformancedegradationcommontoreportsthathavealargenumberofpromptswithoutthesupportofSAPHANA.

SAPBusinessObjectsExplorer

Explorerisapowerfultoolforuserswhoperformunstructuredanalysisofdata.Thetooluses information spaces that are built from existing views through a simpleweb-basedinterface. No defined queries are needed, since Explorer makes a best-guess effort todisplay the data in each information space in a usable format. Explorer, by default,provides tables that can be filtered and graphics that can be customized for easyconsumption.

AlthoughExplorerisnotafull-featuredreportingtool,thesimplicityofthetoolmakesitgreatforseniormanagers,powerusers,andexecutives.ExplorercanbeusedonaBWAsystem,butSAPHANA is the idealplatform.WhenusedonHANA,Exploreruses theDatabaseStructuredQueryLanguage(DBSQL)foraccesstodatainBWonHANA.

Incrediblespeed!

In a HANA system with 1.22 billion rows of data, BO Explorerpopulateddatafromallrowsin4.3milliseconds.Whendrillingdownto400millionrows,datawaspopulatedinExplorerin2.4seconds.

SAPBusinessObjectsAnalysis

SAPBusinessObjectsAnalysisallowsuserstoconductinteractiveanalysisofdatathroughits online analytical processing (OLAP) engine. Analysis can be used through twointerfaces.TheMicrosofteditionof the interface isaplug-inforExcelandPowerPoint,whileawebinterfaceisavailablethroughtheBILaunchpadwhichrequiresnoinstallationandwillworkthroughanyPCwhichhasJavaandaccesstoyourcompanyswebportal.AsampleofAnalysisforOLAPisshowninFigure3.8.

Figure3.8:AnalysisforOLAP

Analysisistherighttoolforpoweruserswhoneedtoanalyzedata.EachusercansaveapersonalizedAnalysisviewwhichwillperiodicallyupdatewithnewdata as it becomesavailable. In order to effectively use the power of theOLAP engine, your power usersmusthaveagoodunderstandingofthedatathat isavailable,aswellasthefilteringandnavigationoptionsthatareavailableinthedataset.

SAPHANAcombinedwithAnalysispresentsyouruserswiththeperfectcombinationofin-memoryOLAPcalculationsandreal-timedataretrieval.AnalysiscombinedwithBWonHANAallowsyourusers toaddcalculations,drilldown todetails, andanalyzedatafasterthaneverbefore.

SAPCrystalReports

SAPCrystal reports is a very common reporting tool that grants developers control ofeverypixelandotherformattingelementsoneachreport.TwoversionsofCrystalReportsexist,SAPCrystalReports2013andSAPCrystalReportsEnterprise.Oftheseversions,SAP Crystal Reports Enterprise is capable of connecting to SAP HANA through JavaDatabase Connectivity (JDBC), Open Database Connectivity (ODBC), and throughuniversesontopofSAPHANAviews.

TheEnterpriseversionofCrystalReportsoffersmorethan40availablecharts,aswellasotherfeaturessuchasfilters,flashobjects,images,andcross-tabs.BecauseofthehighlygranularformattingoptionsinCrystalReports,thetoolisusedprimarilyforfixed-formatreports.

3.4.2BusinessObjectsmobilization

While SAP BusinessObjects Web Intelligence and SAP BusinessObjects Dashboardsallowusers to leveragesomemobilecapabilities, themostpowerfulBOBJmobilizationtoolbyfarisSAPBusinessObjectsDesignStudio.

SAPBusinessObjectsDesignStudio

SAP BusinessObjects Design Studio is a full-featured integrated developmentenvironmentwhichcanbeusedbyapplicationdeveloperstocreateweb-basedandmobiledashboards, aswell asother applicationsbasedonyourdata inSAPBWonHANA.AdashboardcreatedwithDesignStudioisshowninFigure3.9.

Figure3.9:HANAPerformanceDashboardcreatedwithDesignStudio

DesignStudioreplacesBExWebApplicationDesigner(WAD).DesignStudioisamorepowerful development tool thanDashboards, and for that reason, IT developers are theintendedaudienceforthistool.

Sourceconnections

The latest release of Design Studio allows direct connection to SAPHANA analytic views and calculation views, as well as SAP BWanalysisviewsandqueryviews.

SAPLumira

SAPLumiraisatoolthatisusedforvisualinterpretationoflargevolumesofdata.Lumiraallows you to build your own graphical interpretations of data and then organize thevisuals into dashboards completewith navigation controls.Amobile visualization builtwithLumiraisshowninFigure3.10.

Figure3.10:ALumiravisualization

Intermsoffunctionality,LumiraisverysimilartoBOExplorerbecauselittleITtrainingis needed to use it. And, unlike many of the other BI tools, Lumira is optimized forsharingreportsonmobiledevices,webpages,andtheBILaunchpad.

3.4.3BusinessObjectsconnection

AseachoftheSAPBusinessObjectstoolswasdevelopedbydifferentteams,eachtoolhasdifferent requirements and options for connecting to data on an SAP BW on HANAimplementation.TheavailablemethodsforconnectingtoBWonHANAincludeuniversesbuilt on JDBC and ODBC connections, connections to information models such asanalytic and calculation views, andBEx queries. Since connections to views allow theuser to fully leverage the power of the HANA calculation engine for calculations andaggregations, connection to information models should be used whenever possible.However,sincethecurrentversionsofWebIntelligenceandDashboardsdonothavethe

abilitytoconnectdirectlytoHANAviews,youwillsometimesneedtocreateuniversesontopofHANAviewsusingtheInformationDesignTool.

4BWcleanupBycleaningupyourexistingSAPBWsystempriortomigration,yourcompanycanspendlessonitsnewHANAsystem.Inthischapter,youwilllearnabouttheprocessfor cleaning up your BW system prior to migration, including a 12-step plan tocompletetheprocess.

AnSAPBusinessWarehouseisacomplexsystemwithdatareplicatedinseverallocationsthat can be removed. Staging areas, summary tables, log files, and temporary storagelocations for data that is beingmoved to higher-levelmodels can all be cleaned beforebeginning the migration. This will significantly reduce the system size needed for themigration,andwillalsoreducetheamountofworkrequiredduringthedatamigration.

Databasesizereductions

Pre-migration cleanup of an existingBW system can often reduce thesizeofanSAPBWsystemby20-30%,orevenmore.

InSAPBW7.4 onHANA, themaster node is used for storage ofmanyof the systemtables and master data. Because of this, it is important to keep the system tables andmasterdataas small aspossible. Inorder tohelp thisprocess,youshoulduse the stepsbelowasaguidelineforminimizingthesizeofthesystemtablesandmasterdata.

4.1TheBWcleanup12step-program

4.1.1CleanupthePSA

Data that has alreadybeen loaded toDSOs canbe removed from thepersistent stagingarea(PSA).SincethePSAisnolongerneededinanSAPBWonHANAsystem,thereisnoneedtomigratedatafromthePSAtothenewsystem.

4.1.2Deleteaggregates

Since theHANAcalculationenginecancalculateaggregateson thefly,summary tablesare no longer necessary. Delete the aggregation tables which were required to provideenhanced report performance in BW systems which used the older layered scalablearchitecture(LSA).AggregatetablesarenolongernecessaryinLSA++.

4.1.3CompressEandFtables

TheEandFtablesarethefacttablesforyourInfoCubes.TheFtablestoresuncompresseddata,while theE table stores compresseddata.Aspart of the compressionprocess, therequestIDsarenotstoredintheEfacttable.AspartoftheBWcleanupbeforeaDMOmigration,theEandFfacttablesshouldbecompressedinallInfoCubestoreducethesizeoftheInfoCubesandtheoverallmigration.

4.1.4Removestatisticalcubedata

Your BW system saves statistics data so that it can be used for performance tuning.Statisticalcubedata isstored in tableswith technicalnamesbeginningwith0CTC_xxx.Since the statistics data from your old relational database will be inaccurate when themigrationtoSAPHANAiscompleted,toreducethesizeofthemigration,youcanpurgethestatisticalcubedataaspartoftheBWcleanupprocessbeforebeginningthemigration.

Statisticaldatacleanup

You can use transaction code RSDDSTAT, or programRSDDSTAT_DATA_DELETE,todeletethestatisticalcubedata.

4.1.5Removeunnecessaryobjects

TakeacarefullookattheBWsystemusingtransactioncodeRSZDELETE.TheselectionscreenforRSZDELETEisshowninFigure4.1.

Figure4.1:TheRSZDELETEselectionscreen

WhentransactioncodeRSZDELETEisused,ascreenwillopenpromptingyoutoenterselectioncriteria.Fromthisscreen,youwillwanttolookatbookmarks,logfiles,unusedBExqueries,andtemplates.AsampleresultsetisshowninFigure4.2.

Figure4.2:ResultsfromRSZDELETE

Youshouldfocuson theLASTUSEDONcategory tohelp identifyoldobjectswhichhavenotbeenusedrecently.Removetheseoldandunusedobjects todecreasethesizeof themigration.

4.1.6RemoveunnecessaryDTPobjects

Data ismoved between persistent objects using an object called a data transfer process(DTP).Therearenumerouslogfilesandtemporarystorageobjectsthatarecreatedaspartof the data transfer process. As part of the BW cleanup, you should clean up anyunnecessarytemporarystorageobjects,DTPerrorlogs,andDTPdatabaseobjects.

Checkthenotes!

SAPNotes1139396and1106393containusefulinformationaboutDTPobjects,aswellasprogramstohelpwithDTPcleanup.

4.1.7Removedatainwrite-optimizedDSOs

Write-optimizedDSOsareusedtomovedataintoreportableDSOs.Sincedatainwrite-optimizedDSOswillbe readilyavailable inHANA tables andcanbeaccessed through

HANA views and converted InfoCubes, the data in these write-optimized DSOs isredundantandcanberemoved.

HANA-optimizedDSOs?

AspartofaHANAmigration,SAPoriginallyrecommendedconvertingwrite-optimizedDSOstoHANA-optimizedDSOs,buttheofficialSAPguidanceonthissubjectchangedinFebruary2014.Sincethattime,SAPhasrecommendedthatyoudoNOToptimizeanyDSOsforHANA,and

theyfurtheradvisethatDSOsthatwereoptimizedforHANAbeconvertedbacktotheoldformat.SeeSAPNote1849498formoreinformation.

4.1.8MigrateolddatatoNLS

Asthedatainyoursystemages,youwillfindthatolderdataisneededlessfrequently.Forthisreason,olderdatacanbemigratedtonear-linestorage(NLS)onasmallerserversothatthefewusersthatneedaccesscanstillreachthedata.ThedataonNLScanstillbequeriedinSAPBWonHANA,butthelackofhighdemandmeansthatthedatadoesnotneedtobestoredin-memory.

4.1.9RemovedatainunusedDSOs,InfoCubes,andstaging

You should remove data in unused InfoCubes,DSOs, and files used for staging in thisstep. You should also consider reorganizing attributes and master data text usingtransaction code RSPC. The table RSBATCHDATA can also become very large if notproperlymanaged, soyou should removeunusedbackground information stored in thistable.

4.1.10ArchiveIDocs,cleantRFCqueues,andbackgroundinformation

Aremotefunctioncall(RFC)extendstheCALLFUNCTIONoftheABAPlanguagetoadistributed environment by adding a destination to the statement. A transaction remotefunctioncall(tRFC)canrunasabackgroundtask,andthereceivingsystemdoesnothavetobeavailablewhenatRFCisexecuted.Instead,ifthereceivingsystemisnotavailable,thetRFCwillremaininalocalqueueandwaitforthesystemtobecomeavailable.

An IntermediateDocument (IDoc) is an electronic message that contains data about abusiness transaction in one system and carries that information to another system. Tofurther limit the sizeof theSAPHANAsystem,clean the transactional remote functioncall(tRFC)queuesandarchivetheIDocs.

4.1.11Deleteunwantedmasterdata

Anymasterdatathatisnotneededcanbedeletedinthisstep.AnySAPBWsystemafterservicepack23ofBW7.0allowsdirectdeletionofunwantedmasterdata.

Checkthenotes!

SAPNote1370848containsmore informationaboutbestpractices fordeletingunwantedmasterdata.

4.1.12DeleteunuseddimensionentriesinInfoCubes

UseRSDDCVER_DIM_UNUSEDtocleanyourInfoCubesofunuseddimensionentries.This will help to reduce the size of your BW on HANA system and will reduce thedowntimeneededtocompletethemigration.

4.2Minimizingdatabasesize

YoucanminimizetheamountofspacerequiredforyourHANAdatabaseinseveralways.First, the PSA is not needed at all in BW 7.4 on HANA, which saves space whencompared toBWsystems that do not useHANA.You can also store first level data inwrite-optimizedDSOswhich can reside inNLS and save further space needed in yourHANAsystem.

InfoCubes,DSOs, tables,andpartitionscaneachbesetasNOTACTIVE.By flagging theseobjects as inactive, they will only be loaded into memory in the HANA system whenactually required. This further reduces the required size for your SAP BW on HANAsystem.

Usethesizingprogram!

SAPNote1736976containsenhancementsfortheHANA_BW_SIZINGmodule. Among these enhancements, the module will take the sizingsavingsdescribedabove intoaccountwhencomputing thesizeneededforyourSAPBWonHANAsystem.

4.3Housekeepingmadeeasy

While the list of steps above may be completed manually, you should use the toolsprovided by SAP for help in automating the process.With BW 7.0 SP 32 or higher, ahousekeeping list can be generated to guide you through the BW cleanup process. AsampleSAPBWHousekeepingchecklistisshowninFigure4.3.

Figure4.3:SampleBWhousekeepingchecklist

TheSAP_BW_HOUSEKEEPINGtasklistcanbecreatedandupdatedatintervalsduringthecleanupprocess.Thetasklistwillbeupdatedtoreflectyourcleanupeffortseachtimeitisrefreshed.Theitemsinthechecklistinclude:

1. ClearallOLAPcacheparameters2. Deleteaggregatedataviadeactivation3. DeleteBWstatisticaldata4. DeleteRSTTtraces5. ReorganizeanddeletebookmarkIDsandviewIDs6. DeleteentriesthatarenolongerrequiredintheRSIXWtable7. CheckBWmetadatawithregardtotheDDIC8. VerifyDataSourcesegmentsassignmenttoPSA9. EnsurerequestconsistenciesthroughoutthePSAlandscape10. EnsurepartitionedtablesarecorrectlyindexedforthePSA11. ReassignrequestswrittenintotheincorrectPSApartition12. RepairindexesonInfoCubefacttablesattheDataDictionarylevel

The SAP_BW_HOUSEKEEPING task list is accessed using transaction code STC01.Beforeyou can create the list, youwill need to install the program found inSAPNote1829728,aswellasanyothernoteswhichareprerequisitestothisnote.

4.4Beforeupgradetasklist

ForBWsystemsthatareusingversion7.0SP31orhigher,youcanusetransactionSTC01tocreateanSAP_BW_BEFORE_UPGRADEtasklist.TheprogramrequiredtocreatethistasklistisincludedinSAPNote1734333.

Aswiththeothertasklistsdescribedinthischapter,theSAP_BW_BEFORE_UPGRADEtasklistisintendedforuseasanincrementaltooltohelpyougetyoursystemreadyfortheupgradetoBW7.4andmigrationtoSAPHANA.Youshouldcreatethetasklistandrefresh it periodically in order to verify your progress in preparing the system for theupgradeandmigration.Ifyouchoosetosimplydisplaythetasklist,youwillseeascreensimilartotheoneshowninFigure4.4.

Figure4.4:SAP_BW_BEFORE_UPGRADEtasklist

Youcanalsomaintainthetasklistasyoucompleteitemsfromthelist.SeeFigure4.5foranexampleofthetaskmaintenancescreen.

Figure4.5:MaintainingtheSAP_BW_BEFORE_UPGRADElist

Spendnow,savelater!

Remember, themore time you spend on preparing the system for themigration, the less time you will spend in migrating the system. Byreducing the complexity and size of your BW system before themigration,youwillsavelaborduringthemigration,whilesavingmoney

inHANAhardwareexpenses.

5PrerequisitesforDMOBeforeyoucanbeginaDMOmigrationfromyourexistingSAPBWsystemtoSAPBWonHANA,yoursystemmustmeetcertainrequirements.Inthischapter,youwilllearnwhattherequirementsareforDMO,aswellasthebestpathforwardinordertoensureyoursystemmeetstheserequirements.

First,youwilllearnwhichversionofSAPBW,alongwiththeappropriateservicepack,must be installed in your existing BW system before you begin your DMOmigration.Next,youwilllearnaboutUnicodeandsecurityconversionsandhowDMOeliminatestheneed for separateUnicode and security conversionprojects.Youwill also learn how tomigrateyourBExWebApplicationDeveloper templates.Finally,youwill learnhow tousethechecklistthatisincludedintheSAPBWonHANAMigrationCockpittoprepareandvalidateyoursystemtomoveforwardwiththeDMOprocess.

5.1RequiredBWversionandservicepacks

SAPBWsystemsmustberunningatleastSAPBW7.00orhigherwithatleastservice19(SP19) or higher. According to SAPNote 1813548, your target release after theDMOprocessshouldbeatleastSAPBW7.31orhigher,butwerecommendatargetreleaseofSAPBW7.4orhigher.SAPBW7.4hasnumerousadvantagesoverpreviousreleasesofBW,includingOpenODSviews,newCompositeProviders,andAdvancedDSOs,andBW7.4 is the first release ofBW that has been optimized extensively to fully leverage thesimplifiedLSA++architecture.

SAPBW7.4isdesignedforHANA!

AstrongargumentcanbemadeagainstupgradingyourBWtoSAPBW7.4ifyouarenotimplementingHANAinyourbusiness,sincemostofthe optimizations in BW 7.4 are focused onmaximizing usage of theHANA calculation engine and the LSA++ architecture. If you do not

plan to implement HANA in your environment, SAP BW 7.31 is a perfectlyacceptablealternativetoBW7.4.

5.2Generalprerequisites

InordertousetheDMOprocessforyourSAPBWonHANAmigration,youwillneedtohaveatleastSoftwareUpdateManager(SUM)version1.0SP9.ThisversionofSUMhasthe added benefit of including a new user interface for DMO based on SAPUI5. Thismeans theDMOuser interfacewillbeaccessedviawebbrowserandwill allowyou toavoidthenecessityofloggingintotheapplicationserverinordertochecklogfiles.

SomeSAPBWsystemsmayhavebeenconfiguredasadual-stackimplementation,whichmeanstheycombinedbothSAPNetWeaverApplicationServerABAPandJAVAwithoneSAPsystemID.Thisconfigurationwasdesignedtoreducethetotalcostofownershipbyallowingcustomerstosavetheexpenseofhavingseparatedatabaseandapplicationserverhardware. Unfortunately, DMO only works with ABAP systems, so if your system isconfigured as a dual-stack implementation, youwill have to perform a dual-stack splitbeforetheDMOoptionwillbeavailabletoyou.

Thedual-stacksplit

Check SAP Note 1816819 for guidance on how to split a dual-stackimplementation.

As of SUM release 1.0 SP 12, SAPASEmay be used as the target database for yourmigration,butthetargetsystemmustbeSAP_BASIS740SP09.AlwaysmakesureyouchecktheSAPProductAvailabilityMatrix(PAM)forsourceandtargetdatabaseversionrequirementspriortobeginningtheDMOprocess.

The followingsectionwascreatedusing theGeneralPreparationsectionof theComeritDMO runbook. This runbook was created as part of the worlds two largest DMOmigration projects. In this example, the databasewasOracle-based, so any stepswhichrefertoOraclemayneedtobeadjustedifyourdatabaseisnotonOracle.

5.2.1AccessanduserIDs

AspartofthepreparationtobegintheDMOprocess,youmust:

1. RequestOSaccesstothesourcesystemforyourownuserID2. Verifyyouraccesstouseradm3. Verifyyouraccesstouserorasid4. ObtaintheOracleSYSTEMpassword5. ObtaintheOracleschemapassword6. ObtainthepasswordforuserDDICinclient000andtesttheloginwithuserDDIC

7. RequestBasisroleaccesstotheSAPdefaultbusinessclient8. ObtainthepasswordforuserSYSTEMinHANA,andverifylogininHANAStudio9. ObtainandverifyaccessforuseradmontheHANALinusservers10. ObtainandverifyaccessforuseradmonVMLinuxservers11. ObtaintargetinstancenumbersfortheHANA,ASCS,PAS,andAASservers

Onceyouhavedeterminedthatyouhaveusedthechecklistabovetoverifyyouhavetheproper credentials and authority levels in all systems necessary, you canmove forwardwithothergeneralpreparations.

5.2.2SSFSconfiguration

The first step of the general preparations involves determining whether SSFS (SecureStorage in File System) is configured on the Oracle system. Instructions for checkingSSFSarecontainedinSAPNote1639578.

5.2.3MigrationkeyandBWlicensekey

Next, youwill need to request yourOS/DBmigration key from the SAPMarketplace.SAPNote317096containsinstructionsandinformationregardingrequestingtheOS/DBmigrationkey.YouwillalsoneedtorequestanewlicensekeyforSAPBWonHANA,sobesuretodosowhileyouarealreadyloggedintotheSAPMarketplace.

5.2.4DiskspaceandanMOPZstack

Afteryouhaverequestedthemigrationkeyandthelicensekey,verifythatyouhavethediskspaceavailableforthelatestversionofSUM.Youwillneedapproximately50GBofdiskspacetoinstallSUMforDMO.

Next, create anMOPZ stack file for SUM.Make sure you include the following threesoftwarekernelsaspartofthisstackfile:

ThelatestpatchforthecurrentOraclesystem(orothersourcedatabase)ThelatestpatchforashadowsystemrunningOracle(oryourchosensourcedatabase)andBW7.4ThelatestpatchesforR3transandTP

5.2.5Downloadsoftwareandsupportpackages

Next,createadirectorycalledDOWNLOADSontheserverandcopyallinstallationsoftwareandsupportpackagesintothatdirectory.Bysavingalltheinstallersandsupportpackagestoonecentraldirectory,theprocessofcleaninguptheinstallationfilesaftertheprojectiscompletedwillbesimplified,sinceallthesourcefileswillbeinonecentrallocation.

Gettherightversion!

As part of this process, make sure you download the HANA clientwhich matches the version of the HANA database installed o