openSAP BI 4 Platform Innovation and Implementation

This document contains a transcript of an openSAP video lecture. It is provided without claim of reliability. If in doubt, refer to the original recording on https://open.sap.com/.

WEEK 1, UNIT 1 00:00:12 00:00:17 Hello and welcome to BI 4 Innovation and Implementation. This is the fourth course in the openSAP online e-learning platform. My name is James Rapp and I'm a technical specialist in SAP's Strategic Customer Engagements Team. I've been working in the analytic space for some time now and I'll be copresenting this course with colleague, Henry Banks. This openSAP course consists of four weeks, plus one additional week for the final exam. In each week, there will be a number of videos like this one. And at the end of each video, there will be a self-test to help you measure your learning progress. We will also have weekly graded assignments, which will help you earn points toward your record of achievement. There will be a number of optional exercises to supplement the material and give you hands-on experience for the topics covered. There will also be an online forum, or you can go and collaborate with your fellow students and ask questions. Finally, you should expect to spend at least half a day per week to complete the course. Now let's start with week 1, unit 1, where we will begin with an overview and introduction to the BI 4 Platform. Based on market trends and our current state, SAP has identified five key criteria for strategic focus on business intelligence, the first of which is to maintain our strong core a leading business intelligence platform in the market. This includes enabling our customers to be successful with their latest releases and innovations. Second is creativity, ensuring that IT departments can be successful in configuring, deploying, consuming, and publishing business intelligence content. Third, making sure that business intelligence content is available on all mobile devices, so that you can be connected to the enterprise wherever you are. Next, what we terming extreme analytics or access to big data and leveraging SAP's real-time platform. And finally, social: the ability to collaborate and connect with your network through annotations and sharing of BI content. All set and done, we want to ensure that you're able to innovate without disruption to your existing investment and business intelligence.

00:00:38 00:00:44 00:00:54

00:01:08 00:01:14 00:01:20 00:01:31

00:01:47 00:01:54 00:02:05 00:02:15 00:02:25 00:02:35

00:02:44 00:02:50 00:02:58 00:03:09 00:03:18

Now let's move on and talk about the BI platfom, which this course is primarily about. First and foremost, the ability to access any data source anywhere, whether it be SAP-based or another vendor. On top of that, the universe semantic layer, enabling abstraction of business objects so that casual users can consume and leverage the BI content. On top, an industry-leading business intelligence platform that allows you to administer, manage, publish, and secure content. Powerful BI clients, visualization-related, such as SAP Lumira. Dashboards and apps, such as the SAP Dashboards formerly known als Xcelsius, and Design Studio applications to give you access to manifest valuable KPIs in browsers or in mobile devices. And finally, reporting: Crystal Reports an industry-leading pixel-perfect operational reporting tool. And Web Intelligence still the industry standard for ad-hoc query and analysis. On top of this platform, accessing content anywhere, anytime through a variety of mobile devices, browsers, and enterprise portals. To summarize a bit about the BI platform, the intent is to build engaging experiences. In order to do this, we enable you with self-service tools such as SAP Lumira and BusinessObjects Explorer. Dashboards and applications, allowing you to track these key performance indicators and delivery summary data. In addition, the ability to build enhanced customer experiences so users can get at the information they need, and get at it quickly. And finally, reporting. The ability to distribute information in a secure process across the entire organization. And finally, to build pixel-perfect reports with tools such as Crystal Reports for operational efficiency. That's it for unit 1. I hope you join us next time for unit 2, where we'll discuss what's new in the BusinessObjects BI platfom 4.1.

00:03:37 00:03:50 00:04:03

00:04:17

00:04:32

00:04:49

Page 2

Copyright/Trademark

WEEK 1, UNIT 2 00:00:15 00:00:29 00:00:38 00:00:43 00:00:58 00:01:09 00:01:26 00:01:39 00:01:46 00:02:02 00:02:13 Hi, welcome to unit 2 of week 1. In this presentation, I walk you through the latest features and enhancements as delivered in the BI 4.1 platform and its associated tools. SAP BusinessObjects BI 4.1 is the first point release of SAP's market-leading Business Intelligence Suite. This is the professional grade BI platform the market has been waiting for. BI 4.1 is the combination of core stability and capability improvements. It spans key new innovations, incremental product advances from 4.0, and reintroduced features from XI 3. We've delivered new capabilities around self-service, dashboarding, and mobility to enable users to make faster decisions without the reliance on IT. BI 4.1 also brings support for net new and updated platforms and database technologies... Firstly, let's turn our attention to enhancements in the core BI platform. BI 4.1 offers a number of installation options to upgrade your environments. If your hardware allows it, you can upgrade in situ or do a side by side. We offer both a full install or an update package, depending on your requirements. Using the Upgrade Management tool, there's a direct upgrade path for content coming from XI R2 SP2 and XI 3.1 straight into BI 4.1. Postinstallation of your software, it launches a System Configuration Wizard to help deploy and optimize your processing tiers, especially the adaptive processing servers. The Upgrade Management tool helps simplify the upgrade process, your legacy content, as it can now handle the migration of Active Directory and LDAP structures without needed recreation. Multitenancy provisioning features have also been enhanced and are auditable. The BI platform and its clients now also support HANA single sign-on via SAML. There is also tighter system landscape integration with Solution Manager for monitoring and supportability purposes. There's also now an option to migrate you old system database to SAP's own native Sybase instance. Now let's touch on BI launch pad topics. The BI platform's footprint now extends into social collaboration tools such as SAP JAM and StreamWorks. Content versioning for external files on the platform has been much improved. And BI workspaces have been enhanced to support Explorer content and layout personalization. Our user interfaces now support mirrored righ-to-left languages. This includes both UI rendering and the data itself. Now let's turn our attention to the universe semantic layer. In the area of semantic layers and universes, we've performance optimized BW access.

00:02:27 00:02:34 00:02:42 00:02:50 00:02:59 00:03:06 00:03:15 00:03:22 00:03:32 00:03:46 00:03:52

Page 3

Copyright/Trademark

00:03:58 00:04:07 00:04:18 00:04:30 00:04:37 00:04:48 00:04:59 00:05:06

We've improved our connectivity options and feature support for native HANA and ERP access. Our support for agnostic sources has extended to cover the latest Hadoop, oData, Exadata, and Teradata big data sources. With regards to the Information Design Tool, our table federation technology is now on par with the stand-alone data federation product for the BI use cases. New usability features and design wizards now also help a faster project development. We've also extended the reach of semantic SDK to allow partners and customers to automate universe deployment and lifecycle management. Interestingly, HANA customers can now also migrate their vendor relational database universes to HANA's new DB. Let's take a look at Crystal Reports for enterprise enhancements. Crystal Enterprise now benefits from enhancements in the area of support for BW variables, where functionality has been much improved and behaviors have been harmonized with the other client tools. Support for ECC parameters via universes has been extended. And most importantly, Crystal can now connect directly to HANA OLAP views without requiring an authored universe at all. Other enhancements for Crystal Reports for Enterprise include: the ability to edit the SQL execution plan. The verify database feature makes a comeback to ensure report integrity in case of data source modifications. Also, chunking performance enhancements have been delivered for list of values retrieval. Now let's look at Web Intelligence enhancements. Firstly, freeze header functionality much like Excel; this allows users to scroll through long lists of information whilst retaining a view of their column headers. Custom color palettes allow users to choose and use their own color branding, such as in charts for example. The delegation of measure aggregation has been improved. Using a new auto-refresh feature means that users will no longer encounter the #to refresh notification when using smart measures. This also means less #unavailable notifications when using delegated measures in workflows involving local report variables. Additionally, workflows that require merging and unmerging of objects are now much more flexible; and this includes the possibility of merging hierarchical dimensions. Web Intelligence access to BEx queries via BI Consumer Services (or BICS) has been optimized, with improvements to hierarchy note level selection. We furthered our extend goal into HANA technology and we've made query stripping optimizations available across all data provider types, now including relational. We also have the option to customize the WebI user interface by showing or hiding UI elements to specific users or groups.

00:05:19 00:05:35 00:05:44 00:05:53 00:06:02 00:06:06 00:06:19 00:06:29

00:06:43 00:06:55 00:07:11 00:07:23 00:07:36

Page 4

Copyright/Trademark

00:07:47 00:08:01 00:08:06 00:08:15

The new RESTful Web service has been extended further in 4.1 to reach parity of the previous report engine Java SDK in XI 3.1. Now let's look at the Explorer innovations. Explorer benefits from a new setting that hides the facet of view and therefore speeds up performance on initial load. There are also improvements with regards to HANA sources. Now, users can refresh live without having to re-index their workspace. And timestamp or last refresh date information is displayed. Explorer support for the legacy UNV former universe has been reinstated, which is very beneficial to those used to invest in MDX OLAP universes, for example. It's also worth noting that MDA libraries, responsible for MDX processing, have been ported over to 64-bit technology with its inherent benefits. Explorer now offers a feature to help administrators manage their spaces, which means that content can be preserved and repointed to different sources without having to start over. Now let's take a look at Dashboards Designer. Xcelsius Dashboards can now be authored for use offline. This effectively downloads data into a local file. There's also now support for assistive options to help meet accessibility compliance. This allows support for screen readers and other key input controls. Finally, let's take a look at innovations for Analysis, edition for OLAP. Analysis OLAP improvements are focused around BW integration, especially in the handling of prompts and variables. We also included enhancements in the area of jump link navigation, which is similar to OpenDocument navigation. And we have included improved support for NetWeaver's own report-to-report interface. There are also exciting new productivity features, such as one-click materialization of Analysis OLAP workspaces and Design Studio Artifacts, which is perfect for rapid deployment to mobile solutions. Additionally, we are now also supporting the latest OLAP providers from external vendors, including vendor-specific navigation features. Natively, we have included new HANA OLAP features, such as hierarchies and enhanced prompting functionality. Finally, new chart types have also been delivered to harmonize the user experience across our technologies. That's it for part one of unit 2, What's New in BI 4.1. Join me again next time as I introduce part two for further innovations in the BI Analytics family. Thanks for listening. Good bye.

00:08:32 00:08:44 00:08:57 00:09:13 00:09:18 00:09:30 00:09:37 00:09:45 00:09:55 00:10:04

00:10:19

00:10:39 00:10:49 00:10:59 00:11:10 00:11:22

Page 5

Copyright/Trademark

WEEK 1, UNIT 2B 00:00:15 00:00:27 00:00:40 00:00:45 00:00:50 00:01:01 00:01:08 00:01:22 00:01:30 00:01:42 00:01:47 00:01:55 Hi, welcome to the second part of unit 2, week 1. In this unit, I'll introduce further innovations in the BI Analytics space. In this session, we'll cover the complementary BI tools that, whilst not being part of the standard BI installation, are tightly integrated into the overall solution. These are client tools that are supported by BI 4.1. Let's start with SAP Lumira Desktop. SAP Lumira is our powerful new self-sevice data discovery tool for visualization by the line of business. Lumira SP12 delivers a fresh HTML5 UI5 interface. We can now support BW InfoProvider access through federated SQL-based universes, as well as a large collection of third-party data sources through free-hand SQL. In this SP12 release, a new Compose tab is now available for creating interactive storyboards. Now sharing options have also been extended to Lumira Cloud, including scheduling options via desktop agents. Let's discuss Analysis, edition for Office, version 1.4. This version was released in parallel, post ramp-up with BI 4.1. Analysis Office 1.4 is optimized for use with BI 4.1. It can now leverage the BI platform single sign-on options. And the Analysis Office objects can be handled via promotion management processes using LifeCycle Manager on the BI platform. Just like Analysis, edition for OLAP, Analysis Office now benefits from tight integration with Design Studio, allowing users to quickly publish information to mobile devices. On the short-term future roadmap, it will be possible to broadcast published workbooks out to BI Platform Enterprise users. Let's turn our attention now to Design Studio, version 1.1. This is our premier mobile application framework, optimized for native BW and HANA access. Design Studio continues to evolve into a very desirable enterprise dashboarding solution. New design time improvements help authors quickly make progress, such as the ability to generate applications directly from the Analysis family of products. Global filtering parameters are used for reports of report interface scenarios...can help ensure that data safety belts aren't breached. Design Studio also benefits from multiple deployment options now either to BI platform or to BW NetWeaver, as well as a local desktop mode for testing purposes. There are now good additions of new chart types, which are interactive and customizable. Other productivity enhancements, such as snap to alignment, have been delivered to help designers craft their layout quickly and consistently. We now also have improved filtering options and event triggers, which are delivered in version 1.1.

00:02:15 00:02:29 00:02:41 00:02:55 00:03:03 00:03:14 00:03:25 00:03:41 00:03:48 00:04:00

Page 6

Copyright/Trademark

00:04:08 00:04:20 00:04:27 00:04:36 00:04:47 00:04:53 00:05:10 00:05:28 00:05:41 00:05:51 00:06:01 00:06:08 00:06:25 00:06:44 00:06:55 00:07:04 00:07:12

Also, we have CSS (Custom Stylesheets) to ensure that corporate templates are repeatable and standards can be met. Let's look at innovations in the Mobile BI space. Mobile BI 5.0 is now a single application covering both Explorer and Mobile BI content. Moreover, a single dashboard definition can now be compiled to both iOS or Android devices. There is improved QR code scan functionality and barcode support. Also, Sybase SUP provisioning support is substantially improved, as is HANA SAML authentication and other social collaboration options. WebI and Crystal Mobile integration covers a vast array of new charting options, including microcharts, color customizations, filtering, and contextual OpenDocument navigation. Also, location intelligence or Geomap enhancements are delivered for iOS for a greater user experience. Xcelisus Dashboards support on Mobile also now benefits from a new array of charting and formatting options. We also support now flash variables and Query As a Web Service data access types. Finally, let me introduce you to the Desktop Intelligence (Compatibility Pack). The first point to make is that Desktop Intelligence is still end of life. However, as of BI 4.1, you can update your XI 3.1 SP06 Desktop Intelligence full clients with an add-on. This allows Desktop Intelligence .rep files to be stored in and exported to the BI 4.1 repository. But importantly, Deski reports cannot be viewed over the BI launch pad Web application. This option simply gives you more time to retire these legacy clients, whilst your enterprise moves to BI 4.1. This brings us to the end of unit 2, What's New in BI 4.1 and Further Innovations in BI Analytics. I hope you found the information interesting. Please make sure to review these slide decks again in detail to help consolidate your learning. Thanks for listening. Good bye.

Page 7

Copyright/Trademark

WEEK 1, UNIT 3

00:00:14 00:00:25 00:00:34 00:00:44 00:00:55 00:01:02

Hi, welcome to week 1, unit 3 of this course. In this unit, we'll be discussing a variety of best practices for deploying SAP BI 4 on your platform. I'll also introduce to you some valuable resources such as our BI Pattern Books. Firstly, we're going to talk about upgrade planning. Let's take a look at an overview of a proposed deployment. Let's be honest here: BI architecture in BI 4.1 is complex! Just look at this diagram, it's documented in our Help Guide. In this unit, we're going to concern ourselves with the critical pieces of the BI equation that are marked in red on this diagram. Starting top down...Firstly, our Web tier servers, which include both static content preferably hosted on a dedicated Web Server and also our Application Servers for handling the dynamic Java content. Secondly, our Management Servers, specifically the Central Management Server (or CMS.) And thirdly, the Adaptive Servers, or Adaptive Processing Servers (APS for short), that host numerous individual services. And these processes handle the BI workflows in the Java architecture. A lot of thought needs to be given up front to the design and system landscape. Don't just charge in, recklessly running installers. Firstly, you need to assess the available hardware and your licenses. Then, consideration needs to be given to users and their reports, such as what content will be brought over into the new landscape. Next, decisions need to be made about the proposed system topology. This also includes choices pertaining to Web server technology and database vendors. The implementation and employment phases are time-consuming, but should be relatively straightforward if the planning was well done. A large proportion of the time spent will be in post-installation during the configuration phase. This is where it can get a little tricky. Let's be clear: Your enterprise needs to make sure that this proposed system is future-proof. So, it needs to be sized to allow for growth. This is of paramount importance: You need to work with your vendors to get the hardware that you need. How you architect the solution will be a pivotal decision, and one you'll have to live with. So you need to side a clear strategy up front. Are we going to split out the architectures vertically? Hopefully yes, to improve the user experience. Are we going to cluster nodes horizontally, thus improving balancing and fault tolerance (most probably).

00:01:20 00:01:27

00:01:46 00:01:53 00:01:58 00:02:04 00:02:15 00:02:29 00:02:39 00:02:52 00:02:59 00:03:11 00:03:16 00:03:21 00:03:28

Page 8

Copyright/Trademark

00:03:38 00:03:48 00:03:59 00:04:04 00:04:10 00:04:23 00:04:38 00:04:49 00:04:54 00:05:07 00:05:14

Don't forget that your existing IT infrastructure and its limitations may negatively impact the good ambitions you have for this system. You don't want to be hampered by a substandard network or storage system, for example. So, what are the conceptual tiers in a BI platform? Well, broadly speaking the BI platform could be split into three categories. Firstly, the web applications, or web tier. These handle static and dynamic content and are deployed onto Apache Tomcat or NetWeaver, for example. Secondly, the intelligence tier, including the CMS and FRS (or File Repository Systems), which is your Object Repository and system database, including its system security domains. This also includes management of authentication principles, and the object file stores containing your content on disk. Thirdly, the processing tier. This is where the action happens. Requests from applications are processed here, data is fetched and aggregated, and the computed results are then pushed on to the clients. So how do you prepare for a successful installation? Well you need to take baby steps first. Check the PAM (or Product Availability Matrix) to avoid common mistakes about product compatibility. For example, is a given Service Pack supported? Do you have the right configuration to allow interoperability, or maybe you are missing an add-in or another component? You need to ensure you have the right file permissions. You can't properly install the platform without. There's nothing worse than having to back-track and register the files manually. You might want to look into ordering the paths. The default path and the program files can eventually lead to read/write problems due to length limitations. Before we go about upgrading, make sure to take a full backup and capture everything, including the operating system and programs; not just taking a snapshot of your filestore and system database. Why would you do this? Well because in case of a rollback, it may make more sense to restore from the backup rather than uninstall and try to unpick the updates. Let's talk about managing and editing the custom web property files. Not knowing how to customize the web property files properly in a web tier is a common mistake. This slide outlines how to prevent loosing customizations after patching and redeplyoment. So firstly, you need to stop modifying content at the correct location. Then, make a file name copy to the Custom folder, and then you need only add the delta lines where the changes are different from the default. Doing this ensures that your changes are not overwritten and lost, and our Wdeploy tool can roll out your changes reliably. In this next section, we'll examine the configuration tips that are recommended for optimizing

00:05:35 00:05:41 00:05:47 00:06:00

00:06:14 00:06:30 00:06:36

00:06:50 00:06:55 00:07:06 00:07:18

Page 9

Copyright/Trademark

the BI server tiers. 00:07:31 00:07:36 00:07:53 00:08:10 00:08:22 This slide will help us illustrate the need for web tuning. Here's a little background: In XI R2, logging on to InfoView consisted of 3/4 MB of data and approximately a 130 requests. By XI 3.1, the products benefitted from feature improvements, and the result was almost double the amount of data streamed over the network. In BI 4.0 and 4.1, we thankfully added compression out of the box; but since the previous version, the number of requests had doubled again. The key message is therefore: BI keeps getting more complicated with every release as we have more functionality. Therefore, it's really important for us as BI administrators to have a solid understanding of how this application works. And then we can tune it to make sure that we're not negatively impacted by this evolution. To this effect, you really must take some time out and read up on the SCN resources referenced in this slide. This article here called Improve the User Experience with BI 4.1 is an absolute must read! And it's empirically proven to speed up user access. But let's take a step back for a moment. BI 4.1 is shipped with a Tomcat web application whose server component has a built-in HTTP plug-in, which also allows it to process static content. However, a dedicated web server, such as Apache or IBM HTTP server, allows significant benefits in terms of optimization, the handling of JavaScript and images, etc. The key point here is, firstly, if you arent using a dedicated web server, start planning to implement one. The benefits far out-weigh the cost, and the process is documented extensively here on SCN. By adding a stand-alone Apache web server, and using Wdeploy in split mode mode, you can improve navigation speed by 25% or more! You can even do this on the same machine as your Tomcat server. With regards to optimizing the server tiers, the key point here is that BI 4.1 is leveraging an SAP JVM for the embedded application server for the first time. However, it is currently on Java 6 at the moment. We know that Java 7 delivers significant performance improvements, especially around startup time and garbage collection for multi-core CPU. Something that quite a few of us here will be using anyway. Were looking for customer feedback about the use of Java 7 and it's our hope that it'll be included for consideration in the BI 4.2 roadmap. So in the meantime, be generous when increasing Tomcat's memory pool. Let's take a look now at the processing tiers. We're going to cover this topic in further detail during week 2, during our configuration module. But here's a brief introduction.

00:08:38 00:08:48 00:08:56 00:09:10 00:09:13 00:09:27 00:09:41

00:09:58

00:10:20

00:10:36 00:10:46 00:10:51 00:11:01 00:11:11 00:11:14

Page 10

Copyright/Trademark

00:11:24 00:11:34 00:11:47 00:11:55 00:12:03 00:12:03 00:12:25

Firstly, the Adaptive Processing Server module is a pluggable service that hosts more than 20 services and is Java-based. As I said before, BI 4 is currently certified with use with SAP JVM using Java 6, so you don't have any garbage collection, GC1, or tiered compilation right now. That said, we do have a neat new feature in BI 4.1 by way of the System Configuration Wizard. This is a great first step in splitting the Adaptive Processing Servers into separate containers. This will help us trim out and stop unnecessary processes. How will this affect your new installation? Well, the back-end processes supporting our various applications will be enabled or disabled, and stopped or tuned, based on your selections here. For advanced administrators, if you want to take this concept further, there's also a whitepaper on the SCN that covers best practices for the Adaptive Processing Servers, and the link is contained here. If for some reason you choose to bypass the System Configuration Wizard, please be aware that the out-of-the-box monolithic Adaptive Processing Server does not assign enough resource allocation for complex user workflows. Arguably, the default configuration might be acceptable for a sandbox environment but that's debatable. My personal reason for favoring splitting the Adaptive Processing Server is for problem isolation and containment. Otherwise, there's simply too much white noise if we're tracking and tracing dozens of services in a single trace log. Similarly to the SCN document mentioned previously, there's a Note outlined here, which describes the labor-intensive process for splitting and grouping the logically related services together. My best advice is to go for the Configuration Wizard in BI 4.1 and build on that foundation. So, here is how it looks in principle. After installation and on first entry into your Central Management Console (or CMC), a new Welcome screen pops up. This utility helps administrators do the splitting task consistently. It absolutely does coexist with the manual guides described on SCN, but this Wizard is a great way to kick off a template. On subsequent runs, when you're configuring other machines, the Wizard gives you the option to reuse existing configuration templates, allowing you to preserve changes on subsequent runs. The generated response files are really helpful, and you rerun the file in batch mode, and restore the config exactly. Moreover, the simple text file that it generates itself can be commented with simple Yes or No line operations before execution. Let's take a little time now to talk about tailoring specific services and applications. When splitting the Adaptive Processing Server, there are some actual considerations that you need to have in mind in a distributed landscape.

00:12:42

00:12:58 00:13:07 00:13:15 00:13:26

00:13:40 00:13:51 00:13:56 00:14:12 00:14:22

00:14:36 00:14:45 00:15:00 00:15:06

Page 11

Copyright/Trademark

00:15:14

For example, with regards to promotion management, you should not have multiple LifCycle Manager Adaptive Processing Servers per instance. Not per single host, not per cluster. This causes various issues. As such, it's often recommended to have a stand-alone server for lifecyle management and promotion activities. More about this topic in week 4 of this course. Whereas when concerning LifeCycle Manager Job Server, it's OK to have multiple instances on a single host or deployed across multiple servers. When logically grouping Adaptive Processing Servers into groups, items like the STS (or Security Token Service) simply must coexist in synch with the semantic layer or DSL for the correct functioning of BICS consumer service authentication. Thirdly, placing auditing and monitoring services in the same Adaptive Processing Server can certainly make good sense. In the same way as the historical trending databases can be hosted on the same database instance. Post-installation, you definitely should review the auditing, monitoring, and platform search indexing depth, as recording too much detail could cause a general slowdown on your system. It's generally recommendable to stop or disable these services up front on a new installation, and gradually build a backup once you're confident with your system. Now let's turn our attention to the management or intelligence tier. The key points here are, or firstly: The CMS is the brains of a BI system. A bottleneck in the CMS will cascade throughout the system and cause performance problems. The CMS communicates with the database to update metadata, to verify security, etc. And it uses a connection pool, which is configurable in the CMC (Central Management Console). The default out-of-the-box setting is 14 but it can be set as high as 50. There's absolutely no excuse for having queuing at the CMS level, because this is directly within our control! The CMS holds object metadata in a cache. This is because reading from memory is significantly faster than reading from database tables. As a first point of mention, between XI 3.1 and BI 4 versions, the default cache storage capability was increased by a factor of 10 from 10,000 objects to now a 100,000 objects. Our sizing guide mentions that a CMS uses an approximate footprint of ~1GB of memory. That assumption means that each unique object itself is around 10KB but that could be more or less. So to conclude: Check under the CMC for the number of objects in your system database, and consider increasing the value for the maximum objects in cache if the requirement is over a 100,000 objects. But please understand this will increase the memory footprint of your CMS. This slide is going to recap some other topics for review. You need to start thinking about the IT infrastructures and strategies that will need to be in place to sustain and safeguard your productive system. That's before you sign off the delivery.

00:15:30 00:15:42 00:15:55

00:16:20 00:16:29 00:16:38 00:16:54 00:17:10 00:17:16 00:17:30 00:17:45 00:17:52 00:18:07 00:18:19 00:18:37

00:18:53

00:19:00 00:19:25 00:19:34

Page 12

Copyright/Trademark

00:19:47

Who or what will it be depending on? Are these processes or solutions reliable? Have you even implemented them? Are they correct and adequate? Are they fit for purpose? Have they been tested? You should assume nothing and validate everything. Going further still, have you canvassed your infrastructure team for feedback? How about your project team, do they have concerns or priorities? How about your business unit? Perhaps you have concerns about certain aspects of the integration. You need to score them out early. Will the required plugins work as expected on this new version? Are there current restrictions that need to be bypassed or perhaps some fit gaps addressed. The point here is: Everything needs to be planned up front before diving into the implementation. We don't want any surprises because this isn't an approve of concept any more. Thorough thought needs to be given to the topics on this slide before proceeding with an installation...such as do you have enough drive space. How about the prerequisites for other solution integration touch points. Other simplistic considerations need to be caught out also. Will you be loosing fixes if you're coming from the latest Service Pack and a patch; for example, if you're coming from a higher patch level or BI 4.0 SP07. Are your servers a standardized image or built? Do they have the right .NET framework versions if on Windows? How about parity with Microsoft hot fixes? Have you thought about the database clients and middleware that need to be downloaded from third-party vendors? Have you done the 32/64-bit data source name (DSN) administration? How about the browser choice deployed in your organization? Is it up to date? Is it supportable? Is your Adobe Flash version compatible with the latest dashboarding solutions? How about the Java clients used by the browsers? Is it secure? Are the databases you're leaning on...are they properly available for BI use cases? We're talking here about CMS auditing and trending databases. Are they in a correct geographic location? Do they have enough available threads? Or might they experience deadlocks? This list here is nowhere near exhaustive, so start brainstorming with your planning considerations by talking to your project stakeholders sooner rather than later. In this section, I'll introduce you to SAP's BI4 Pattern Books.

00:20:04 00:20:10 00:20:16 00:20:20 00:20:24 00:20:30 00:20:36 00:20:44 00:20:50 00:21:05 00:21:15 00:21:23 00:21:27 00:21:38 00:21:43 00:21:56 00:22:03 00:22:12 00:22:19 00:22:26 00:22:32 00:22:43 00:22:53 00:23:08

Page 13

Copyright/Trademark

00:23:16 00:23:29 00:23:39 00:23:46 00:24:02 00:24:09 00:24:14 00:24:24 00:24:34 00:24:46

So firstly, what is a Pattern Book? Well, a Pattern Book is a step-by-step guide of an actual how to deploy system and is documented as precisely as possible. The objective here is to give a live example of a successful deployment, and how it was technically achieved. It's worth noting that we've delivered Pattern Books in the past for previous versions. These resources are proven to help our customers through the implementation and support services alike. They are absolutely indispensable as reference guides. Indeed, we've had one for BI 4.0 for some time, based on Unix platforms. The good news is we now have one, an equivalent for Windows platforms. These online resources are absolutely free of charge and accessible via the SAP Community Network (or SCN). These walk-throughs cover everything, from the system topology to network components, to servers and their connections. How does it look in practice? Well, it's a decision tree-like detailed step-by-step setup with clear deployment instructions for each software component. It can handle multivariate considerations, such as your hardware, your operating system, the software right the way down to the different versions and patches, user accounts, network domains, etc. These guides even acknowledge the common pitfalls during deployments and their solutions. (The link to these resources can be found in the footer to this slide.) This next section will discuss best practices for running BI 4 in virtualized environments. This information is sourced from guidance determined from our co-innovation labs. These projects are called COIL labs. Whilst not exactly a new concept, there has been real growth and interest in the virtualization because of its flexibility and extensibility. So we've created a dedicated microsite where our experts blog and submit the latest articles. I invite you to take a tour of these resources, so please take some time outside of this course to familiarize ourselves with these articles. These are empirical studies based on hard facts, thanks to the close projects collaboration with the vendor VMware. Our very latest article was published in June 2013 of this year. It'll help ensure that you're getting all of the CPU power for the CPU licenses that you've paid for. It'll help you guarantee that other virtual machines on the same host aren't blocking the read/write paths from your host. It'll also ensure that memory allocation isn't being overcommitted without you knowing. In order to keep track of our co-innovation lab activities, please join the COIL microsites so that you're aware of our joint initiatives. Please do read up on the latest findings such as these recent white-papers. Firstly, LargeScale BI deployments with Sybase. Secondly, Evaluating Java Best Practices for BI 4

00:25:00 00:25:17 00:25:24 00:25:38 00:25:47 00:25:55 00:26:04 00:26:18 00:26:33 00:26:43 00:26:53 00:27:04

Page 14

Copyright/Trademark

Applications on vSphere. 00:27:26 00:27:37 00:27:40 00:27:52 Furthermore, your team should familiarize themselves with the other side of this VMware piece by reading the recommendation for VMware administrators. I've outlined a couple of documents below. Firstly, Performance Best Practices for VMware vSphere and also a vSphere Resource Management Guide for ESX. You may ask yourself why would you want to read up on these documents? Because it makes absolute sense for you to get familiar with VMware concepts and terminology, so that you can better negotiate with your IT infrastructure providers. You don't want to get shortchanged. We do provide more information about VMware best practices and recommendations in the next unit Sizing Methodology, as presented by Jim. That's it for the Architecture and Deployment Best Practices unit! Thanks for listening. Your attention and diligence is appreciated. Now over to Jim for unit 4 Sizing Methodology. Thank you! Good bye.

00:28:07 00:28:10 00:28:23 00:28:29 00:28:32 00:28:36

Page 15

Copyright/Trademark

WEEK 1, UNIT 4 00:00:12 Welcome back to Week 1, Unit 4 of this course, BI Sizing Methodology. In this unit we'll talk about the requirements for sizing a BI architecture and it goes without saying that well sized environments perform better than poorly sized environments. So to start lets talk about some general considerations for SAP BI and Sizing. The first thing that we all should be aware of is that Business Intelligence is quite I/O-intensive and this is a theme that Ill come back to, quite a bit, throughout the course of this unit. Now I/O, especially when it pertains to disc but also with network can be more difficult to measure than CPU and Memory. For example when youre measuring CPU and Memory consumption its very trivial to launch the Windows Task Manager and evaluate a process. I/O on the other hand, consists of reads, writes and other input/output operations that can be difficult to determine when theres a bottleneck. Second, the aggregation of millions of rows which is often what happens from a Business Intelligence point of view is more costly than streaming transactions in the classically ERP sense. And finally, it can be difficult to balance a constant load on the server rather than peak load which may occur on a daily basis or perhaps near a month end period. Second, BI is designed to use all the system resources and this is intended for optimal performance so that the processes can scale up to the limits of the machine as needed. Theres really no reason for us to restrict consumption on a per system basis. There are some techniques that you can take specifically on Linux and Unix platforms to restrict CPU consumption but theres really no reason to do so because BI manages itself and should be allowed to scale up to the available resources on the machine. Now in terms of actually deploying SAP BI some strategies to help you be successful are as follows: First and foremost its important to map out the deployment What I mean by that is, sit down and take a good understanding for how many servers you have available to you, how many resources each of those servers has and try and come up with a good setup for which processes can reside on which machine. Now some specifics around this. The CMS system database is really the key point to overall performance of the BI platform. Every operation in SAP BI causes the system to execute one or more queries against the backend database and if that database becomes a bottleneck either because of a limited number of threads perhaps or because the database itself is overloaded or because of insufficient network bandwidth between the CMS and the database, all operations will suffer. User navigation will become more slow, reports will take longer to process and generally the user experience will suffer. Whenever possible try to use dedicated hardware for the CMS database. Thats not to say it cant reside on a shared database server that hosts other processes but we want to ensure that its not sharing the same machine that the CMS resides on. Amongst other reasons, this is valuable for system fault tolerance and reliability so that if one CMS goes offline, the database, which is really the key component, isnt also lost as well. And finally we want to monitor the individual server tiers. We talked previously about the management tier, the intelligent tier and the processing tier as well as the web application tier.

00:00:29 00:00:34 00:00:44

00:01:00 00:01:11

00:01:23 00:01:34 00:01:49

00:02:11 00:02:22

00:02:37 00:02:46

00:03:09

00:03:33 00:03:46

Page 16

Copyright/Trademark

And its important to keep an eye on those individually to identify any potential bottlenecks. 00:04:03 The second point in terms of deploying BI is to look at starting small. Its really impossible to scale a system for thousands of users, put it in production and expect it to perform well right away. So the intent here is that we should try to start small whether that is for productive use or for performance testing and gradually add users as we get better visibility into how the system performs. Now finally the methodology I would suggest using especially for performance testing is to test, analyse and repeat. And this process can go over and over for a number of iterations making small point changes along the way to understand how the impact to the system performs. Lets talk now about the evolution of BI 4 as an overall architecture. As youre probably aware the BI 4 and 4.1 suites are 64 bit and its important to note that prior releases such as XI 3.1 were designed so that the entire suite could fit within the artificial constraints of a 32 bit architecture. Now because BI 4 is not artificially limited so its capable of stretching out and that means it can take advantage of all our modern hardware feasibly to hundreds of gigs of memory and 16 or more CPU cores on a single server. BI4 is also architecturally inclusive and what I mean by that is XI3.1 was more a collection of independent applications that have their own connectivity stacks. B14 has the advent of the common or dimensional semantic layer for data connectivity. And that means that a single service can handle talking to the universe for a variety of processing servers including crystal reports for enterprise, web intelligence and dashboards. And finally BI 4 is a first class and highly integrated SAP client. What I mean by that is that in the past if you used XI3.1 to SAP BW for example it was necessary to install an integration kit. Now SAP connectivity is provided natively and all of the processing servers are capable of consuming SAP data. Now in terms of scale up and scale out these are two concepts that are available to you when youre sizing a BI environment. Scale up or vertical sizing means that we raise the number of physical processes on a single machine to take advantage of modern hardware. Now you might think that I have a very powerful machine with hundreds of cores potentially so I can put 5,10 or more instances of web intelligence on a single machine Now while that might make sense lets not forget about disc I/O that I mentioned previously, if that becomes a bottleneck web intelligence will not be never able to take full advantage of the server hardware. Another point worth mentioning is that if you schedule crystal reports at night for example, the crystal report job servers can co-exist with something like web intelligence. You may want to keep in mind however, if your using crystal to do a lot of interactive analysis as you are web intelligence it probably doesnt make sense for the two to co-exist because they could end up fighting for system resources. Now the other part of this paradigm is scale out or horizontal scaling and virtualization really makes this a great proposition because theres little or no incremental hardware cost. Once youve procured a VM host you can add additional host machines or guest operating systems to the existing hardware. Now the design principles for scaling out are really no different from any other enterprise software, you still want to keep in mind the resource consumption, the disc I/O and the network I/O.

00:04:29

00:04:49

00:05:11

00:05:40

00:05:59

00:06:24

00:06:43

00:07:07 00:07:17

00:07:32 00:07:43 00:07:55

Page 17

Copyright/Trademark

00:08:06

And finally when scaling out you may not need servers with these vast system resources because each server handles part of the overall load and Ill get into that a little further when we talk about virtualisation. Now although the BI platform needs to be sized very carefully we shouldnt forget that there is a role that external systems play. I already alluded to this a bit when I talked about the CMS system database but its important to reaffirm that a poorly provisioned database will have what I will call an invisible effect and that means that problems with the database from a system database perspective will cascade throughout the user operations again causing logon time to suffer and report processing time (to suffer) as well. These I/O bottlenecks to disc and network can potentially have severe impacts and the number one thing I would say here is that if you starve a BI system for I/O it guarantees poor performance. This can also be an impact if you have a slow or old file server hosting the file repository server. The final point Ill call your attention to in terms of external systems has to do with patching your external BW systems. Theres significant incremental performance gains that may be possible and in the past weve traced a number of poorly performing web e-documents to older outdated SAP BW systems. Now lets talk about those conceptual tiers a little bit more and some of the key criteria to keep in mind when sizing your BI system. So for the central management server we generally expect to handle 4-500 heavy active concurrent users and the best practice is not to stack or vertically scale more than one CMS on the same physical system. Although its possible it eliminates fault tolerance and effective load balancing by keeping them on the same machine. So now, talking about the FRS, I already mentioned having a fast file server so probably a NAS or SAN based storage solution for your FRS is a positive thing. Now the input FRS should be close to the processing servers to ensure best performance. That means that when the web intelligence report server for example, requests a template it doesnt need to traverse a very wide set of network hops to get that file. And similarly to ensure optimal performance from the output file repository server we want to set instance limits whenever possible on our scheduled jobs. Without instance limits its possible to have thousands and thousands of report instances and it makes it more cumbersome for the output FRS to traverse the directory structure when retrieving a report instance. The final point Ill call out here has to do with repository databases and that includes both the CMS system database as well as the audit database. These should be kept close to the CMS because the CMS does so much query, insert and updates of these databases. If the CMS has to wait and requests go into a pending state, performance will suffer significantly. Now to talk about the monitoring database for a moment, if thats enabled make sure the trending database is kept close to the adaptive processing server that hosts the monitoring application. So lets talk now about virtual environments. There are a number of best practices, some of which were referred to in the previous unit that have to do with sizing virtual environments successfully. First and foremost use strict CPU reservations for every virtual machine on every host. Think about it this way, youre paying for a number of CPUs, perhaps youre even licenced for a certain number of CPUs to run the BI platform on.

00:08:21 00:08:29

00:08:54

00:09:06

00:09:35

00:09:59

00:10:24

00:10:46

00:11:00

00:11:17

00:11:38

00:11:50

Page 18

Copyright/Trademark

00:12:06

Its not worth the risk of not getting the CPUs you pay for and losing out on that part of your investment. So talk to your VM administrators and ensure that for your BI platform hosts youve set strict CPU reservations. Now the same holds true for memory reservations, Java applications in particular can be very sensitive to this. Java processes allocate memory in heaps and if we dont have enough memory available because that memory is being distributed to another VM or shared elsewhere those Java processes can start swopping to disc or they might, in fact, run out of memory and crash. Either way, its a bad thing for your users so the top 2 items on this list are to ensure that the CPU and memory that youre paying for and that BI believes you have are actually available to the application. In parallel to that we want to ensure that were not using shares or limits on the VMs especially when our BI hosts are sharing the same VM parent. If were using those shares we could find that CPU and memory are being swapped between the individual guest operating systems causing performance to suffer. The last couple of items on this checklist if you will, are to make sure that VMs are sized large enough to accommodate these very I/O intensive workloads. If the I/O pads get jammed on a particular VM host it will have a cascading effect to the BI services that run on those machines. And finally we found through testing with VMware that it really doesnt make a lot of sense from performance perspective to size VMs larger than 16 virtual CPUs. We found that after that, performance was fairly linear and did not increase the way it did below 16. So the rule of thumb is use more smaller sized VMs rather than a few very large ones. So lets talk about some general best practices around building better BI systems so that you dont end up like the gentleman in this slide. First and foremost, do you have enough CPU power? So lets go beyond SAPS and as we know SAPS are the SAP application benchmark. Are you set to properly scale your systems out? So, if you need to use three or four different BI clients such as Explorer, analysis, Web B etc Have you aligned those processing tier services on each of the machines?. And finally, do you have distribution across nodes? So think about what I mentioned with Crystal Reports job servers running reports overnight. If you have to share processing power between multiple BI clients consider adding an additional machine to host those in a dedicated fashion. Next we want to make sure that we evaluate I/O requirements not just for the BI platform services but as well for reporting databases, for the network channels that handle the internode communication and for any I/O links and paths that may exist on VM hosts. I already mentioned that CMS databases that are poorly provisioned will cause performance problems so we want to make sure that theyre configured for low latency and high throughput. Part of that can be handled by co-locating in the same data centre, the CMS system database and the central management server. And finally, although this is database vendor-specific, you want to make sure that if your CMS database resides on Oracle or SQL server that your using their best practices to ensure performance standards for that third party database. Finally memory. You can almost always use more memory in a large environment because the Java processes that run the adaptive processing server can be configured for 64 bit heaps. That would be 4 gigs, 8 gigs, even 16 gigs or higher.

00:12:20

00:12:45

00:13:00

00:13:20

00:13:38

00:14:07

00:14:25

00:14:40

00:15:00

00:15:19

00:15:38

00:15:54

Page 19

Copyright/Trademark

00:16:11

So because of the spiky and dynamic nature of BI its important to have a large amount of memory available to you. So now that weve sized an environment weve come up with a scaling plan and architecture diagram and weve built the system how do we test and tune the SAP BI application? Now Ill talk a bit more about this in week 3 but for now lets talk about a general approach to testing and tuning. The goal, when youre sizing an environment, should be to ensure reliability so that the system stays up. So if weve built a number of CMSs in a cluster we should be able to handle the outage of any single CMS. So once that architecture is sound well want to naturally stress test the environment to see how it handles a certain amount of load. Second (point), consistency we want to ensure that when we add a 100 or a 1000 users to this system our report processing time doesnt increase by 30 or 40%. And finally, this is a concept that we hear quite frequently from SAP and that is performance should no longer just be just acceptable, we want to move to an enjoyable experience. Think about the technology world we live in these days with mobile devices in 4G LTE, SAP Hana for example for In Memory. People are used to getting responses in the way that they get responses from Goggle in seconds. So we want to ensure that were building BI systems that deliver this enjoyable experience to our users or frankly, theyll go somewhere else. The approach you can take to test and tune the system is ideally to start with a clean system. So this goes back to what I talked about a few slides ago with having a small number of users initially. If you try to test a system thats already in production with thousands of users youre apt to fail. Second (point) we want to capture vital statistics. These statistics include things like throughput, average response time as well as the report size were testing with and the number of users. We want to gradually scale up the number of users so rather than go from a single user to a thousand users, try to identify some incremental up ticks in the number of users that youre testing with. Well analyse the tests using these metrics for CPU and memory response time and finally well make changes and iterate. When we make changes however, its better to make a single or couple of changes rather than make wholesale changes across the application. If you find yourself introducing too many variables in between test iterations ultimately you wont know which of those change parameters had a positive or negative impact on your tests. Now lets identify some criteria that we can use to determine when its best to scale, whether that be horizontally or vertically. Typically we suggest aiming for a 60-65% average CPU utilisation and the reason being that we dont use a threshold of that level, peaks of 80 to 90% which could be standard might set off data centre alerts for high utilization. And its a guarantee that if your system is peaking at 100% users will suffer and we want to keep in mind things like month end where we may see additional load so this average CPU utilization of 60-65% gives us a bit of leg room to grow. You know it also empathises how important it is to scale slowly so if we end up adding a ton of hardware, how do we know a particular service resides in an adaptive processing server that actually needs more headroom? And also, what is a better use of your resources? If you have so much hardware that your services are separate, you may not know whether you need to add another web E service or an additional MDAS server for analysis for OLAP

00:16:32

00:16:56

00:17:15

00:17:37

00:17:51

00:18:12

00:18:37

00:18:54 00:19:08

00:19:35

00:19:45

00:20:08

Page 20

Copyright/Trademark

00:20:22

From a CMS-specific point of view theyre usually on their own machines ok? We mentioned previously that stacking or vertical scaling CMSs is a bad idea. We add additional CMS hosts at that same amount of CPU utilization and finally, dont get carried away. In the past we used to have a limit of 2-4 CMSs but thats been resolved and eliminated in BI4.0 SP4. So what that means is that for every 5-800 active concurrent users youre fully able to add an additional CMS instance. Now finally we talked about CPU now lets talk about memory. I already mentioned that having more memory for these Java processes is valuable but frankly, you should be generous with RAM whenever possible. The reason being is that these Java processes: the APS, the adaptive job server and some of the other processes allocate memory in heaps and that means that they can quickly grab large amounts of RAM. As we mentioned in the previous unit, its also possible to right-size your APS so that the initial heap is equivalent to the maximum heap. And by virtue of that you want to make sure that youre allocating enough memory to accommodate multiple APS services. Now Java garbage collection is also something worth pointing out. When a Java process consumes a certain amount of memory close to its maximum heap it will clean up some of that memory space so that it can use it for other objects. And if your heap is too small your APS processes could typically be spending more time in garbage collection than they actually are in processing business requests. That would be a terrible thing for performance. So lets look at max usage as opposed to average usage. In VMware situations you may typically report low active memory and infrastructure folks may overcommit the memory or try and take it elsewhere. Some of these Admins consider it a best practice but ultimately we need to ensure that the memory is available during peak times. So by virtue of that we recommend looking at max usage as opposed to average. And finally, make sure the infrastructure team understands how BI is different, try to talk their language. Most folks dont understand that BI isnt like an exchange or a database its very bursty and it will scale up and down according to user load. That does it for this unit, join me next time to talk about BI sizing and tools and resources that you can leverage.

00:20:39

00:20:59

00:21:10

00:21:31

00:21:54

00:22:13

00:22:32

00:22:56

Page 21

Copyright/Trademark

WEEK 1, UNIT 5 00:00:13 00:00:26 Welcome back to week one, unit five of this course, where we will learn about some valuable tools and resources that SAP provides to help you size your BI 4 environments correctly. Id like you to keep this quote in mind throughout the course of the unit. The number one priority of a BI administrator should be to deliver that enjoyable user experience I talked about in the previous unit and ensuring that your BI system has appropriate sources is paramount to achieving this. The first document Id like to talk to you about is the BI sizing companion. This is the document that youll need to use to find out about thresholds and specifications that are involved in sizing your BI infrastructure. This guide helps you answer such important questions as Why is it bad to have more than one Crystal Reports processing server on an individual machine? And the answer is that Crystal Reports processing servers have a parent child relationship and scale up the appropriate number of child processes automatically. Adding additional Crystal Reports processing servers can undermine this algorithm and impact performance in a negative fashion. You can find the sizing companion guide on service.sap.com under sizing guidelines and in the Analytics section. Lets keep in mind that sizing of each individual service in the BI platform is very important. An example of this might be that your Java application server should not have more than 8GB of RAM in terms of heap size and process more than a thousand threads at a given time. I mentioned previously the Crystal Reports Processing server but keep in mind some of the other specifications of the sizing companion talks about. Specifically here youll see that analysis OLAP servers or multi-dimensional analysis services require one instance for every 100 active connections. Henry spoke a bit about the APS in Unit 3, and here its important to point out that the service container hosts up to 22 individual processes in the BI platform. You can find this technical paper on SCN that will give you all the details about command line references, heap settings and other parameters you can configure for the APS. Delving just a little deeper into the APS and its pluggable architecture, I mentioned that it can host a number of services simultaneously and the out of the box configuration is to have all of those 22 services running on a single instance of the APS. Keep in mind that this default installation is really only intended for test and trial purposes and before going to production, you should split those out. Those of you using BI 4.1, can benefit from the system configuration wizard that makes splitting these services into bundles a much easier prospect than in prior versions. It gives you the ability to select the BI clients you wish to use such as Web Intelligence, Explorer, Lifecycle Management etc. and it splits them into individual components to help ease your initial configuration. Now important services should always be hosted within a dedicated APS and an example of this might be an environment where the DSL bridge is very important for data connectivity to SAP BW. By giving the DSL bridge its own dedicated service, we ensure availability and a dedicated

00:00:48

00:01:02 00:01:10

00:01:30 00:01:41

00:01:58

00:02:15

00:02:40

00:02:56 00:03:06 00:03:16

00:03:31

00:03:43

Page 22

Copyright/Trademark

heap to process those critical business requests. 00:03:54 Now it does carry a slightly higher memory for consumption because youre allocating heap for each service independently but youll reap some massive benefits in terms of overall performance. So now we ask the question, well whats wrong with one APS if I have enough RAM on the machine? In a previous unit, I talked about is being generous with memory, and assuming that you have 20 or 30 GB of memory to allocate, why would it be a problem to allocate 22 services in a single APS? There are a couple of reasons but primarily supporting, troubleshooting or debugging that APS process could be painful if not impossible. In fact, you might ask the question what would a 16 GB Java process even look like? The answer is that it could be spending more time in garbage collection and reclaiming memory than it is processing active business requests. This is certainly going to cause user experience and performance to suffer and we want to make sure we dont clutter the APS with unnecessary services. Now Id like to move onto another tool, armed with the sizing companion guide, the other half of the equation is known as the BI 4Sizing Estimator. Youll see an image of it on this slide. This tool takes in a number of inputs such as number of users, type of reports and BI clients in use and it will give you a certain number of values for the CPU and the memory that you would need on a single node and well talk more about that in just a couple of minutes. Keep in mind that this is an estimator and not an analyser and it shouldnt replace an expert sizing which is a service that SAP offers to take in your business specific requirements and give you customized output in order to scale an environment, both horizontally and vertically. Some limitations of the tool, you will find that once the numbers become too large and youre inputting hundreds and hundreds of users, one or more of the values will turn red indicating that you should consider an expert sizing. Now the reason for this is we did find internally that the test results werent linear and once we crossed a certain threshold, the tool became invalid for the general results. Its also worth pointing out that it does not explicitly cover your BW or HANA figures so those need to be sized separately and finally scheduling and publishing are not directly in scope. Now as I mentioned using the estimator never replaces a real sizing exercise but it can be a very valuable tool as long as you remember that the results are always dependant on inputs. So map out those environments very carefully and ensure that youre not getting too complicated or adding too many BI clients at the same time. Its entirely valid to size for say Web Intelligence and then reset the value to zero and input for Crystal Reports, aggregate the numbers and then youll have your values for both of those BI clients. The CPU outputs will be in SAPS which stands for SAP Application Performance Standard and this is effectively a unit of measurement that is agnostic to CPU manufacturers. You can find a number of results on the website listed here on the slide that will give you both ERP outputs from SAP as well as some BW benchmarks to give you an idea of how powerful a certain configuration of CPU is. Id encourage you to leverage this resource especially if you find yourself repurposing existing

00:04:06

00:04:24

00:04:40 00:04:48 00:05:00 00:05:12

00:05:29

00:05:47

00:06:01 00:06:12 00:06:25

00:06:45

00:06:59 00:07:14

00:07:28

Page 23

Copyright/Trademark

hardware for use with the BI 4 Platform. 00:07:39 So now, lets change gears a little bit and talk about some of the challenges that you may find when youre trying to estimate these workloads. Sure the sizing estimator is a great tool but it does require a large number of inputs that well talk about here in a couple of slides. So keep in mind that BI 4 is enterprise software, its complicated to configure so be sure that you use the resources were sharing with you throughout this course to plan your environment and take it step by step. Additionally SCN is a fantastic resource for technical papers like the APS white paper I mentioned on the previous slide. We should make sure in order to deliver that enjoyable experience, that we do plan for head room and that should be growth above lets say 65% average CPU utilization. The expectation is that users are going to use the system even more than you anticipate so plan ahead and dont be surprised. So lets dig into estimating the actual usage of the sizing estimator. We use a couple of calculations, the first being active users. An active user is just a user whos logged on to the system. They may be performing an action or they may be sitting idle. And if the number is not known, we generally recommend as a rule of thumb taking 10% of the users in the environment. Now the primary number you want to be aware of to use the sizing estimator is called Active Concurrent Users or ACU. And these are users who are legitimately performing a workflow. Lets think about actively refreshing or drilling in a WEBI report, navigating through a dashboard or an exploration view. All of these things require resources from the system at a given moment in time. And if this number is not known, we suggest taking10% of the total active users. So in the example here, we have 10,000 total users mapped into the system and the active users would be 1,000 10% of 10,000 Similarly if you take another 10% of the active users, youre given 100 active concurrent users. Now one word of caution, we find that most people dont ever revisit this 10% of 10% rule and usage can be significantly higher at closing time, around months end or in significantly targeted systems towards a particular business unit or line of business. In those situations you may consider using a higher value say 20 or 30% but thats really dependent on your business consumption. In terms of report size, this is the other slider in the sizing estimator. These complexities and data sets that weve used to come up with the criteria of small, medium and large reports are well documented in the sizing companion guide. It gives you details and guidance on the number of records, the number of cells, other navigational criteria that might exist in a report. So please use that when youre trying to come up with values. One thing I would point out, is that by default each slider will be set to 100% medium reports and this should really never be used. The odds of you having 100% of the same type of report are really zero. And finally, its important to keep in mind that different BI clients and workflows actually have impact on report sizes. So a large Crystal Report for example that returns tens of thousands of rows in formatted fashion would be very different from a dashboard that brings the same type

00:07:56

00:08:10 00:08:19 00:08:31 00:08:41

00:09:05 00:09:13

00:09:35 00:09:44 00:09:51

00:10:08 00:10:19

00:10:45

00:11:00

Page 24

Copyright/Trademark

of thing back. 00:11:20 And it can really be difficult to estimate the load generated by the a group because all workflows are different. So remain in contact with your business users and try to plan ahead for this type of scenario. And finally, well talk a little bit about the user categories so dependencies are that every environment has some information consumers or people that generally view predefined or static content. Now these could be report instances generally so lets say a Crystal Report that has data already in it and a user pulls this up and simply views the report. Now it could also be viewing that same report in PDF format or excel. But the reality is that information consumers generally have an average of five minutes between navigation steps and thus are the lowest impact on the system. Now business users would be the next level and generally if youre in doubt, try to define your users as business users. And these are folks that have a moderate amount of drilling and filtering. They may be using Web Intelligence or some simple ad-hoc queries and they may be doing some filtering but generally have an average of 30 seconds between individual navigation steps. Now the final user profile would be your expert users. These are often people using tools like Analysis Edition for Olap that are online in nature and require constant slicing, dicing and drilling a particular report object. We say that they have an average of 10 seconds between steps and theyre going to contribute to a significant amount of load on the system. So now armed with the sizing estimator and the sizing companion guide along with the methodologies that I shared with you in unit 4, you should be well equipped to size your BI Platform and move forward to next weeks unit which deals with installation, upgrade and promotion. Thank you.

00:11:31

00:11:54

00:12:08

00:12:30

00:12:45 00:12:54

Page 25

Copyright/Trademark

www.sap.com

2013 SAP AG or an SAP affiliate company. All rights reserved. No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP AG. The information contained herein may be changed without prior notice. Some software products marketed by SAP AG and its distributors contain proprietary software components of other software vendors. National product specifications may vary. These materials are provided by SAP AG and its affiliated companies ("SAP Group") for informational purposes only, without representation or warranty of any kind, and SAP Group shall not be liable for errors or omissions with respect to the materials. The only warranties for SAP Group products and services are those that are set forth in the express warranty statements accompanying such products and services, if any. Nothing herein should be construed as constituting an additional warranty. SAP and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP AG in Germany and other countries. Please see http://www.sap.com/corporate-en/legal/copyright/index.epx for additional trademark information and notices.