Applications Server

Sizing Considerations for mySAP Components (part 1) - The SAP Exchange Infrastructure

- 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:43:53 PM
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 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 1, let’s take a look at some of the most popular mySAP solutions to understand their unique sizing challenges.

Figure 1. mySAP technology underpins various components and solutions.

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

Figure 2. The SAP Exchange Infrastructure ties into Web AS and all forthcoming mySAP solutions.

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

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