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