Applications Server

Sizing Considerations for mySAP Components (part 2) - Sizing mySAP Business Intelligence & Sizing mySAP SRM

- Free product key for windows 10
- Free Product Key for Microsoft office 365
- Malwarebytes Premium 3.7.1 Serial Keys (LifeTime) 2019
5/17/2012 3:45:10 PM

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 3, 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.

Figure 3. SRM business scenarios encompass much more than simple procurement processes.

Like other 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.

Other -----------------
- Active Directory Domain Services 2008 : Transfer the Infrastructure Master Role
- Active Directory Domain Services 2008 : Transfer the PDC Emulator Role
- SAP Hardware, OS, and Database Sizing
- Preparing for the SAP Sizing Process
- Microsoft Systems Management Server 2003 : Systems Management Server Installer Tools & Creating Installation Scripts
- Installing Systems Management Server Installer
- Microsoft Dynamic GP 2010 : Installing Integration Manager (part 2) - SQL Server maintenance jobs
- Microsoft Dynamic GP 2010 : Installing Integration Manager (part 1) - SQL Server and database settings
- Active Directory Domain Services 2008 : Transfer the RID Master Role
- Active Directory Domain Services 2008 : Transfer the Domain Naming Master Role
- Microsoft Dynamics AX 2009 : Working with Forms - Modifying application version
- Microsoft Dynamics AX 2009 : Working with Forms - Modifying the User setup form
- Microsoft Dynamics AX 2009 : Working with Forms - Adding a Go to the Main Table Form link
- Designing and Optimizing Storage in an Exchange Server 2007 Environment (part 4)
- Designing and Optimizing Storage in an Exchange Server 2007 Environment (part 3) - Adding in Fault Tolerance for External Storage Systems
- Designing and Optimizing Storage in an Exchange Server 2007 Environment (part 2) - Designing the Right Data Storage Structure for Exchange Server 2007
- Designing and Optimizing Storage in an Exchange Server 2007 Environment (part 1) - When Is the Right Time to Implement NAS and SAN Devices?
- Engaging the SAP Solution Stack Vendors : General Sizing Best Practices and Approaches
- Engaging the SAP Solution Stack Vendors : Overview—The Sizing and Blueprinting Process
- Microsoft Dynamics AX 2009 : Working with Forms - Building checklists
Top 10
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Finding containers and lists in Visio (part 2) - Wireframes,Legends
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Finding containers and lists in Visio (part 1) - Swimlanes
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Formatting and sizing lists
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Adding shapes to lists
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Sizing containers
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 3) - The Other Properties of a Control
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 2) - The Data Properties of a Control
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 1) - The Format Properties of a Control
- Microsoft Access 2010 : Form Properties and Why Should You Use Them - Working with the Properties Window
- Microsoft Visio 2013 : Using the Organization Chart Wizard with new data
- First look: Apple Watch

- 3 Tips for Maintaining Your Cell Phone Battery (part 1)

- 3 Tips for Maintaining Your Cell Phone Battery (part 2)
programming4us programming4us