Sizing Considerations for mySAP Components

With the bulk of the solution stack behind us, we can now turn our attention to sizing specific mySAP components. My goal in the mySAP sections that follow is to identify critical or differentiating factors, such as the need to answer component-specific sizing questions or understand component-specific configuration options. And in all cases, the need to identify the particular release of a mySAP.com component is assumed; minimum hardware and software requirements can vary widely between different releases of the same SAP product line, and therefore greatly impact sizing. Thus, it is not enough to say that you plan to implement SAP BW or R/3—BW 3.0B or R/3 Enterprise 4.7 must be specified, for example.

Another general requirement is to understand and characterize either the active high-water user load or peak transaction rate of a particular system. From these numbers, concurrent user numbers can be calculated (or extrapolated or assumed, worst case) and the general impact that these numbers make on the system can be taken into consideration.

With an understanding of the basic mySAP architecture illustrated in Figure 7.5, let’s take a look at some of the most popular mySAP solutions to understand their unique sizing challenges.

Understanding the “New” Basis Layer—Web AS

As the underlying infrastructure for all new mySAP solutions, and the enabling component of SAP’s Exchange Infrastructure (XI) and Enterprise Portal, accurately sizing the SAP Web Application Server (Web AS) is critical indeed. Web AS is a hybrid application server, able to satisfy both J2EE (Java) and ABAP (SAP’s legacy native development language) needs with the advent of version 6.30. Additionally, it handles functions formerly handled by SAP’s Internet Transaction Servers—load balancing, DB connection pooling, serialization of update processing, and server-side data caching, all of which impact sizing. And Web AS leverages XML instead of HTML, resulting in a different load and different sizing criteria from those associated with ITS.

Web AS can be distributed such that the SAP Web dispatcher process resides on a server in your company’s DMZ, protected by a firewall both in front of and behind it. Meanwhile, the core Web AS functionality can be housed in your data center, and can be further isolated by means of another firewall between it and your core SAP back-end systems. This is very much like the ITS architecture promoted by SAP for its Internet Transaction Servers, where the Web and application components were distributed and surrounded by firewalls as described here.

The SAP Exchange Infrastructure

The SAP Exchange Infrastructure (XI) is an important new integration technology that can be used alone or in conjunction with the newest and future mySAP solutions. XI serves a number of purposes, including

• Integration Repository, used to manage components, interfaces, and mappings

• Integration Directory, for managing your mySAP system landscape, cross-landscape services, routing rules, and executable mappings

• Proxy Generation and Framework, supporting both ABAP and Java proxies from XML-based interfaces

• Integration Engine/Server, offering a runtime environment that supports routing and mapping

As seen in Figure 7.6, the latest version of XI takes these capabilities to the next level, providing a view into collaborative cross-mySAP business processes. For example, business processes that cross multiple R/3 systems, your CRM system, and your APO system can be tied together via synchronous and asynchronous messaging, and visually depicted and managed through XI. This allows heterogeneous system landscapes to be deployed, including SAP and third-party enterprise applications like Baan, Broadvision, JDE World Software, Oracle, PeopleSoft, Siebel, and others.

In terms of sizing considerations, the number and size of the messages that the XI’s Integration Server needs to process is paramount. SAP AG has been gracious enough to publish a sizing model that takes into account the following:

• Disk sizing is predicated upon the assumption that all messages are held in a compressed format for a day, and then either archived or deleted. Further, compressed data enjoys no greater than a 65% compression rate.

• The average size of a message is assumed to be 31KB (which not coincidentally equals the typical size of an iDoc with four line items). This can be easily changed to account for different average sizes however.

• Data held in Unicode format consumes twice the amount of disk space as non-Unicode formats.

• In terms of message traffic, only systems that are directly connected to the XI are factored into the sizing model; other systems, like those tunneling messages through proxy servers, are not taken into account.

• Routing is content-based.

• Average CPU utilization is not to exceed 65%, which is consistent with SAP’s general sizing methodology.

As XI matures and additional sizing data comes to light, be sure to check with your hardware vendor’s SAP Competency Center or SAP’s http://service.sap.com/sizing Web site for updated metrics and sizing model considerations.

Enterprise Portal Sizing Rules of Thumb

Sizing Enterprise Portal involves determining CPU and RAM requirements for both the EP server and the Unification Server, which consists of a Web server and a database repository that allows data to be shared and mapped between SAP products. It is assumed that 20% of all EP hits will access the Unification server. Important sizing questions that need to be answered include

• Parallel logons, which is the total number of users logging into the Portal during the peak hour of operation (normally from 8:00 a.m. to 9:00 a.m., or from 2:00 p.m. to 3:00 p.m.).

• Concurrent users, which for EP is expanded to mean the total number of users active in the system in the same hour. The SAP Quick Sizer assumes that 60% of these users have a think time of 600 seconds, 34% have a think time of 180 seconds, and 6% have a think time of 30 seconds—note that this is quite a different working profile than that observed in SAP’s other mySAP components.

• Content Management hits measured as a percentage, or the number of hits per 100 that access documents stored in the Portal.

SAP’s Quick Sizer also assumes that each Portal page contains four iViews. This number along with information as to how dynamic the portal data is, the number of Drag ‘n Relate operations, and the number of queries on non-indexed tables, is required to size the Unification Server.

Sizing R/3 Enterprise

Like R/3 4.6C and previous releases, SAP’s Quick Sizer process for R/3 Enterprise supports two different sizing approaches, based on the kind of information you have at your disposal regarding your planned R/3 Enterprise system. The first sizing approach is geared toward identifying the number of concurrent users in various functional areas, weighted for any combination of low, medium, and high users. Functional areas include the following:

• Financial Accounting (FI)

• Asset Accounting (FI-AA)

• Treasury (TR)

• Controlling (CO)

• Enterprise Controlling (EC)

• Sales and Distribution (SD)

• Materials Management (MM)

• Warehouse Management (LE-WM)

• Quality Management (QM)

• Plant Maintenance (PM)

• Customer Service (CS)

• Production Planning (PP)

• Project System (PS)

• Personnel Administration and Payroll Accounting (PA)

• Personnel Development (PA-PD)

• Basis Components (BC)

• Business Work Place (BWP)

It’s critical to provide an accurate mix of users; users should only be counted once (place them in the functional area they will spend the most time using). Also, unless you understand the sizing risks, avoid stuffing unknown users into a single “catch-all” functional area, like SD. A system sized for 100 SD users has different CPU and memory requirements than a system sized for 25 QM, 25 PM, 45 PP, and 5 BC users, for example, even though the number of users is the same in both cases. This is because each functional area places a different processing load on the R/3 Enterprise system. Further, more functional areas require a greater minimum amount of memory than fewer areas; there is a basic RAM requirement that must be fulfilled for each different functional area.

The second approach to sizing R/3 Enterprise involves answering a series of questions related to transaction loads and quantities of output structures created (like the number of planned sales orders created per day) or relevant to the various functional areas. Called transaction-based sizing, it’s more complex than user-based sizing but in return it is more precise. For each functional area, you need to provide transaction data like the following:

• The number of objects created annually (like FI documents, or TR postings, and so on), as well as the maximum number of objects created in your peak hour of processing. Note that the peak is a delta peak; the transactions per hour in excess of your typical 9–to–5 transaction load.

• You can also enter an “execution” period, which is the span of time in which you want to run a particular peak load (like perhaps a payroll run). This impacts CPU and to a lesser extent RAM sizing—the smaller the execution window, the more processing power required.

• The number of subobjects of each object (like the average number of line items in your typical FI document).

• The retention period of these objects, or how long they will reside in the database before they are deleted or archived. This directly impacts database sizing.

• In some cases, you can also enter the mix of object changes to object display activities. This impacts disk subsystem sizing, as changes equate to more-intensive disk writes or inserts, whereas display activity is read-based.

• Some functional areas also allow you to enter the maximum number of objects that will reside in the database.

Sizing mySAP Business Intelligence

Most BI sizings relate in some way to SAP’s Business Information Warehouse. Before specific CPU, RAM, and other hardware-specific metrics can be nailed down, it’s helpful to understand the primary architectures employed for BW systems, such as

• Three-Tiered Architectures, where the operational systems (like R/3) feed consolidated data to an enterprise warehouse, whereas smaller data marts are stocked with summary data. This is the most time-consuming and expensive BI solution to implement.

• Two-Tiered Architectures, where the operational systems feed only an Enterprise Data Warehouse. This normally results in a faster implementation than otherwise possible, sacrificing potential scalability of the BI solution in favor of ease of implementation.

• Two-Tiered Architectures, where the operational systems feed one or more functionally specific (that is, SD, MM, FI, or APO, and so on) Independent Data Marts. This is the most common two-tiered implementation, as it allows an IT organization the chance to support granular departmentalization of popular functional data and queries. Further, this is often at the expense of a dedicated repository for extracted, cleaned, and transformed detailed data.

Beyond the core release version and underlying architecture, a number of key sizing factors exist for BW, like the adoption of a SAP BW Persistent Staging Area (PSA) and general Operational Data Store (ODS). Both of these affect the database size and performance characteristics of the SAP BW system as well as the speed and additional system load of the operational systems during the data extraction window.

• Persistent Staging Area (PSA)—This transparent table for storing detailed requests in the original format of the transfer structure is actually nothing more than another InfoSource. The source system maintains a key request number, packet number, and record number.

• Operational Data Store (ODS)—The ODS provides a location for all raw operational data to be combined and housed, before such data is extracted, cleaned, and otherwise reformatted. It is often “persistent” too.

In the context of the ODS, the PSA makes up the first level and the ODS table makes up the second level of the ODS. Therefore, the first level consists of the transaction data from the source system, and the second level consists of the consolidated system’s raw data, as well as data from several source systems and InfoSources.

With this information in mind, we can now turn our attention to identifying the sizing questions that the SAP Quick Sizer needs to have answered:

• Three different types of users, classified by the frequency of their activity and the reporting performed. Frequency is measured in navigation steps per hour, one of which is equivalent to nine SD dialog steps. Users include information (low or normal users), executive (or advanced users), and power users, executing 1, 11, and 33 navigation steps per hour, respectively.

• Three different types of queries. Information users spend 80% of their time viewing reports and 20% performing OLAP analysis. Executive users split their time evenly between reporting and OLAP analysis. Power users, on the other hand, execute intensive data exploration activities 100% of the time. With knowledge of the user types and their activity breakdown, it is possible to estimate CPU and memory requirements.

• Number and types of InfoCubes, which are the objects within BW upon which reporting and analysis is performed. SAP BW ships with standard preconfigured InfoCubes, which can be described by attributes like dimensions, key figures, and length—with this kind of data, a sizing engineer can begin to calculate roughly how large your SAP BW database will be.

• Number of periods, or the amount of time measured in weeks that you want to keep a particular set of data.

Sizing BW is a challenge, to say the least; the aforementioned questions and data being collected are valuable in the hands of an experienced BW consultant, but can easily be misinterpreted otherwise. And because one of the major concerns in sizing BW relates to determining how big your BW database will initially be, and how quickly it will grow, experience with BW beyond simply sizing will make a huge difference in how close you come to sizing a useful mySAP BI solution.

Rules of Thumb for Sizing mySAP CRM

In addition to documenting and understanding the business scenarios that drive sizing the mySAP CRM server, sizing CRM can involve any or all of the following special-function servers as well:

• The InQMy Application Server provides an execution environment supporting Internet Sales business-to-consumer and business-to-business processes, implemented via Java Server Pages (JSPs). This takes the place of the SAP Internet Transaction Server (ITS) found in the earliest versions of SAP CRM.

• The TRex Server (Text Retrieval and Information Extraction) provides indexing and search capabilities for information held outside of the SAP CRM database, like catalog information or product documentation.

• A Workgroup Server acts as nothing more than a standard Microsoft SQL Server database server. I suggest that you size this using a traditional database sizing tool. In my experience, the end result for a “typical” Workgroup Server equates to a system capable of hosting 100 transactions per minute for every concurrent Mobile user expected on the SAP CRM system.

• A Communication Station, which acts as a gateway between front-end Mobile clients and the CRM system, and was originally built on Microsoft’s DCOM product running Microsoft Transaction Server (now based on Microsoft .Net technology). Sizing the Communication Station is akin to determining the number of active users who are connected to the system and simultaneously synchronizing their data between their client machines and the various data repositories maintained by mySAP CRM.

• A Multi-Channel Interface Server, which maintains the relationship between the CRM server and any CTI, email, chat, and similar middleware/services. These are not processor-intensive; something like a two-processor system with 1GB of RAM and 36GB of disk space will meet most organizations’ requirements.

Of course, the CRM Server is the “central” server of any SAP CRM solution, and can be hosted on any number of UNIX and Windows platforms. Central to providing this functionality is another server, the Internet Pricing Configurator (IPC). The IPC runs only on a separate Windows 2000 server and is a horizontally scalable Java application that provides pricing calculation and product configuration capabilities. For sizing the IPC, I suggest that you determine the peak number of orders received per hour, where it is assumed that each order is composed of four line items and an associated four images. Or, if only transaction data is available, determine the peak number of objects created in the potentially heaviest day of CRM processing. Next, it’s also important to determine and characterize the number of various CRM users, such as the following:

• CRM Internet Sales Users, who are usually split into either browsing users (the majority) and users who actually purchase goods. Browsing users tend to navigate the site and catalog, gathering information about products. Thus, they impact sizing the Web server component of CRM, but not the CRM server itself. Users who actually purchase goods go through the process of searching, and on top of this activity they eventually create and fill a shopping cart and then proceed to purchase the goods.

• Mobile Sales Users, who spend their time uploading data to the CRM system a few hours each day or so. For sizing purposes, the goal is to determine the greatest number of users expected to access the system in the peak one-hour period (usually in the very early morning or later in the evening, in my experience).

• Customer Interaction Center Users, usually tasked with supporting telesales, telemarketing, and service/support functions. Interestingly, these users not only place a load on the CIC component of CRM, but by virtue of the work that they perform, they also generate transaction and other loads across the rest of the CRM system. Therefore, according to SAP’s Quick Sizer, these users are actually counted twice—once as a CIC user, and once in their respective business or functional area.

If details related to the type of users have not yet been determined, but you still want to estimate (for budgetary reasons, perhaps) what a CRM configuration might consist of, you can instead estimate the number of concurrent users expected on the system during its peak period, using the following rules of thumb:

• One concurrent low user equals 3 orders per hour

• One concurrent medium user equals 30 orders per hour

• One concurrent high user equals 90 orders per hour

Certain activities tend to take place on the mySAP CRM system, too, which impact sizing. For example, managing opportunities and activities, creating customer orders, performing service-related transactions, and managing data related to customers, products, and even projects consume CPU, memory, and disk resources. It’s also important to estimate items like the number of incoming and outgoing CIC calls handled per hour, the retention period (measured in months, not weeks as is customary in other mySAP solutions) of objects maintained in the CRM database before they are archived or deleted, and the peak volume of objects (like sales orders) created in a certain time period.

CRM is not an island unto itself; it ties into many other mySAP solutions, especially your core R/3 system. For example, each CRM sales order is eventually processed on the R/3 system. I suggest employing traditional SD modeling to determine this impact, using the SAP Quick Sizer and its SD-SLS type of functional area.

SAP CRM can also touch APO—availability requests are transferred between the CRM server and APO system via SAP’s Remote Function Call (RFC) communication service. And CRM’s Mobile Sales users can leverage SAP BW for reporting and limited data mining; data is moved from BW to the SAP CRM server, and then downloaded to your Mobile Sales user in the form of an Excel workbook.

Finally, sizing for the CRM front-end clients (desktop and laptop interface devices, for example) must be performed. Client requirements are uncomplicated, but important. Three different user interfaces are available, but minimum front-end requirements dictate a 350MHz processor, 256MB of RAM, and about 30MB of free disk space, regardless of whether you employ the standard SAPGUI or the newer JAVA or HTML-based interfaces. Note that the addition of a mobile client bumps the minimum amount of RAM significantly, though, to 512MB. Further, at least 500MB of free disk space is required for mobile users.

Sizing Considerations for mySAP PLM

Product Lifecycle Management (PLM) supports users responsible with managing product, asset, and process information at any point in the product life cycle, from selection and purchasing through production ramp-up, installation, operation, engineering changes, maintenance/repair, retirement, and more. From a sizing perspective, you need to understand what exact functionality you will be implementing. Choices are many, including the following:

• Lifecycle Data Management

• Asset Lifecycle Management

• Program and Project Management

• Lifecycle Collaboration

• Quality Management

• Environment, Health, and Safety (EHS)

PLM is closely linked with SCM and CRM, and is implemented as an enterprise portal solution. Like typical portal solutions, it facilitates communication and collaboration between users; this activity must be quantified and fed into sizing models. Until SAP includes mySAP PLM in the Quick Sizer, I suggest that you approach this as a Portal sizing exercise, and work closely with SAP AG and your hardware partner’s SAP Competency Center.

Supply Chain Management Sizing Considerations

Sizing SAP SCM normally means focusing on SAP’s Advanced Planner and Optimizer component. Hardware vendors require a lot of very detailed information to even come close to sizing APO accurately. Questions about how you will actually use APO need to be addressed first, including which APO components you plan to implement. These include Demand Planning (DP), Supply Network Planning (SNP), Production Planning/Detailed Scheduling (PP/DS), Global Available to Promise (ATP), and Transport Planning/Vehicle Scheduling (TP/VS). Next, requirements like the following need to be understood:

• Characteristic combinations, or the number of different properties that can describe an object. The greater the number of characteristics, the greater the CPU load placed on a system.

• The number of key figures that reside in liveCache, which directly impacts the amount of RAM required in the liveCache server.

• The number of Demand Planning versions and Supply Network Planning versions, which are scenarios used in forecasting or simulating demand. Each version is assumed to consume roughly the same amount of space; more versions therefore require additional disk space.

• Duration of each Planning Run, or how quickly you want to execute your planning run. Faster runs obviously require more CPU processing power.

• How often these Planning Runs will be executed; daily, weekly, monthly, and so on.

• The number of periods, measured in weeks. Different types of periods are requested (historical, retention, planning, and others); each type impacts disk sizing.

• Additional data related to the number of orders (sales, purchase, planned, and so on), orders transferred from R/3 to APO, available-to-promise (ATP) and capable-to-promise (CTP) checks, stock locations, and so on, all of which primarily impact CPU sizing.

• Number of APO users, which also impacts CPU sizing.

In the big scope of sizing APO, the number of users is really of little consequence, unlike most of SAP’s other mySAP components.

Sizing mySAP SRM

SAP’s Supplier Relationship Management offering is much greater than simply eProcurement, even though its roots are planted squarely in what was only a few years ago SAP’s business-to-business procurement product line. As you see in Figure 7.7, an SRM solution can be quite complex. The eProcurement product line alone consists of SAP Enterprise Buyer, Requisite BugsEye, Requisite eMerge, SAP Business Information Warehouse, and SAP Enterprise Portal.

Like other mySAP.com components, you must first determine the SRM business scenario(s) that are to be implemented; each has different required and optional components, and impact the sizing process accordingly. Other components come into play, too, enabling core SRM business scenarios, including SAP R/3, BW, Exchange Infrastructure (XI), SAP Content Integrator, SAP Supplier Self-Services (for supplier enablement, which itself requires XI), and the SAP Bidding Engine (which supports strategic sourcing). All of this, and the following factors, can complicate mySAP SRM sizing:

• As of version 2.0C, SAP Enterprise Buyer has supported MCOD, which is SAP’s strategy for supporting multiple mySAP components on one database. As SAP R/3 4.6C SR2 also supports MCOD, some interesting synergies and economies can be gained by combining these two normally discrete databases into one.

• Support for an external catalog (running on Web-based marketplaces or your own supplier’s site) minimizes hardware required to support catalog hosting activities, but impacts network activity, not to mention security.

• SRM also integrates well with SAP Enterprise Portal, allowing you to benefit from single sign-on access to mySAP SRM from the portal, among other things, but also blurring the line between the two from a sizing perspective.

Details like the following need to be understood or analyzed with regard to business scenarios that might be implemented:

• List all of the business scenarios you intend to implement in your SRM landscape.

• Identify your average document size (for example, the size of your typical purchase orders), measured in terms of line items created and processed in your SRM scenario.

• Identify how many procurement transactions will be performed each year, and how many will specifically be processed in your peak hour.

• Characterize shopping cart details—the creation, display, transfer, and update of a user’s shopping cart needs to be determined as well as possible.

• Identify your total number of trading partners.

• Identify your total expected number of named and concurrent users (where concurrent users are actively logged into the system and browsing or otherwise performing work).

• Identify auctioning details, including the average number of line items and number of bidders.

Then leverage a throughput-based sizing model that addresses the processes to be implemented. A sample process might emulate a workflow commencing with browsing, then creating a shopping cart, then cutting a purchase order, then performing contract administration, followed by confirmation of delivery and subsequent invoicing.

After the specific business processes are understood, sizing can commence by using the SAP Quick Sizer to determine SAPS. This data may then be shared with hardware partners, to be further refined in terms of core CPU, RAM, and disk requirements for individual servers. The number of servers needed depends primarily on CPU resource consumption of each business scenario (other factors are not even considered). Business scenario CPU resource requirements can be measured and/or estimated if necessary, too. However, keep in mind that business scenario CPU consumption depends on the size of your business objects as well as transaction and user-based loads.

Next, the overall SAP system landscape can be looked at more closely. SAP AG’s hardware and other technology partners can recommend the kind and number of servers that will fulfill the necessary “SAPS” requirements for development, Test/QA, production, and so on. Security requirements will come into play, too, as components will almost certainly need to be isolated and segregated by firewalls. And the need for high availability could easily require roughly twice the hardware otherwise necessary to satisfy your online user and transaction loads.

After an SRM system is in place, it’s not unusual to continue the sizing process (at that point called capacity planning), to refine and tune the system. Java Virtual Machine (JVM) tuning is common, especially around memory heap and generational Garbage Collector (GC) tuning. JVM memory tuning can effectively optimize memory usage, and also increase runtime performance by reducing CPU usage for the Garbage Collection process. SAP has published an excellent note that reflects their latest JVM tuning recommendations—see SAP Note 552522: Java Hotspot VM Memory Parameters. Note that JVM tuning is specific to the operating system—Sun Solaris, HP-UX, and other operating systems present unique challenges in that they tend to include system-specific parameters. Tune the number of threads and number of dbpool connections, for instance, according to monitored usage.

mySAP Strategic Enterprise Management

Strategic Enterprise Management relies heavily on SAP BW; a business warehouse acts as the foundation for SEM functionality. SEM’s analytic application components rely on multidimensional system-intensive OLAP data structures. Thus, it’s key to architect and implement a well-performing BW system before any number of SEM modules can be implemented, including

• SEM-BIC, Business Information Collection.

• SEM-BPS, Business Planning and Simulation. SAP AG recommends that SAP Notes 358529, 411725, 407563, and 381022 be reviewed prior to sizing BPS.

• SEM-BCS, Business Consolidation. A rule of thumb for calculating the CPU and memory needs of BCS users is to perform a user-based R/3 sizing; multiply the number of expected BCS users by two, and then plug the result into the SD module.

• SEM-CPM, Corporate Performance Monitor.

• SEM-SRM, Stakeholder Relationship Management.

The SAP Quick Sizer supports a combination user/transaction-based approach for sizing the individual SEM modules, too. For example, data like the maximum number of concurrent users per group, average number of manipulated data records, number of steps executed per user per hour, and so on can be entered.

Sizing the primary OLAP SEM/BW system, on the other hand, requires converting your expected SEM users into high, medium, and low BW users. Then, you need to calculate the data volume of a closing and the complexity of the various SEM groups (for example, the number of consolidation units, investment structure, and parallel hierarchies). Finally, to calculate disk space requirements, multiply the total number of expected SEM records by four (measured in kilobytes). These can be pretty difficult numbers to obtain—work hand-in-hand with the BW functional and technical teams to best position yourself to come even close to accurately sizing SEM.

Interestingly, SAP AG does not push a three-system landscape for SEM. If standard functionality is sought, only development and production systems are absolutely required. However, for consistency within your various mySAP component landscapes, I still recommend a Test/QA system. And in cases where you want to test different methods of slicing and dicing the individual SEM data structures, or provide some level of hands-on training to your development and super user communities, I highly suggest a business sandbox as well.