Sizing Mobile 2 0

Sizing Guide
Sizing SAP
for Mobile Business
Released for SAP Customers and Partners
Document Version 2.0, August 2008
Released for SAP Customers and Partners

© Copyright 2008 SAP AG. All rights reserved. contained in this document serves informational purposes
only. National product specifications may vary.
No part of this publication may be reproduced or
transmitted in any form or for any purpose without the These materials are subject to change without notice.
express permission of SAP AG. The information These materials are provided by SAP AG and
contained herein may be changed without prior notice. its affiliated companies ("SAP Group") for informational
purposes only, without representation or warranty of any
Some software products marketed by SAP AG and its kind, and SAP Group shall not be liable for errors or
distributors contain proprietary software components of omissions with respect to the materials. The only
other software vendors. warranties for SAP Group products and services are those
that are set forth in the express warranty statements
Microsoft, Windows, Outlook, and PowerPoint are accompanying such products and services, if any.
registered trademarks of Microsoft Corporation. Nothing herein should be construed as constituting an
additional warranty.
IBM, DB2, DB2 Universal Database, OS/2, Parallel
Sysplex, MVS/ESA, AIX, S/390, AS/400, OS/390,
OS/400, iSeries, pSeries, xSeries, zSeries, z/OS, AFP, Disclaimer
Intelligent Miner, WebSphere, Netfinity, Tivoli, and Some components of this product are based on Java™.
Informix are trademarks or registered trademarks of IBM Any code change in these components may cause
Corporation in the United States and/or other countries. unpredictable and severe malfunctions and is therefore
expressively prohibited, as is any decompilation of these
Oracle is a registered trademark of Oracle Corporation. components.
UNIX, X/Open, OSF/1, and Motif are registered SAP Library document classification: CUSTOMERS &
trademarks of the Open Group. PARTNERS
Citrix, ICA, Program Neighborhood, MetaFrame, Documentation in the SAP Service Marketplace
WinFrame, VideoFrame, and MultiWin are trademarks or You can find this documentation at the following address:
registered trademarks of Citrix Systems, Inc. http://service.sap.com/sizing
HTML, XML, XHTML and W3C are trademarks or

registered trademarks of W3C®, World Wide Web
Consortium, Massachusetts Institute of Technology.
Java is a registered trademark of Sun Microsystems, Inc.
JavaScript is a registered trademark of Sun

Microsystems, Inc., used under license for technology
invented and implemented by Netscape.
MaxDB is a trademark of MySQL AB, Sweden.
SAP, R/3, mySAP, mySAP.com, xApps, xApp, SAP

NetWeaver, 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 in several other countries all over the
world. All other product and service names mentioned
are the trademarks of their respective companies. Data
© SAP AG Released for SAP Customers and Partners 2

TABLE OF CONTENTS
1 INTRODUCTION TO SAP MOBILE BUSINESS................................................................................. 2
2 ARCHITECTURE OF SAP MOBILE INFRASTRUCTURE ............................................................... 2

2.1 MI CLIENT ......................................................................................................................................... 2
2.2 MI SERVER ........................................................................................................................................ 3
2.3 MOBILE DEVELOPMENT KIT (MDK) ................................................................................................... 3
3 DIFFERENT SIZING GUIDELINES .................................................................................................... 4
3.1 SIZING FOR SAP MOBILE ASSET MANAGEMENT – STANDARD AND UTILITIES VERSION ........................ 4
3.2 SIZING FOR SAP MOBILE SALES FOR HANDHELD WITH CRM 5.X ......................................................... 7
3.3 SIZING SAP MOBILE DIRECT STORE DELIVERY ................................................................................... 9
3.4 SIZING SAP MOBILE SALES FOR HANDHELD (WITH R/3 AND ECC) .................................................... 11
3.5 SIZING SAP MOBILE TIME SHEET 2.0................................................................................................ 12
3.6 SIZING SAP MOBILE TRAVEL EXPENSES 2.0...................................................................................... 13
4 SIZING FOR MOBILE INFRASTRUCTURE STANDALONE ......................................................... 14
4.1 INTRODUCTION TO THE SMART SYNC DATA MODEL .......................................................................... 15
4.2 SIZING THE MI CLIENT ..................................................................................................................... 17
4.3 SIZING THE WEB APPLICATION SERVER (MI SERVER)........................................................................ 18
5 MEMORY SIZING FOR THE DATABASE SERVER ....................................................................... 19
6 CHANGE HISTORY, COMMENTS AND FEEDBACK .................................................................... 20
© SAP AG Sizing SAP Mobile Business - SAP Customers and Partners 1

1 Introduction to SAP Mobile Business
Mobile applications for SAP Solutions for Mobile Business are developed for specific user needs,
ranging from the needs of service workers who use devices for many industry-specific applications to
a consultant who simply tracks time and expenses on a mobile device for synchronization to a back
office system at a later time. SAP Mobile Infrastructure provides capabilities that support mobile
scenarios in cross-industry applications, such as Customer Relationship Management, Human
Resources, Supply Chain Management, Business Intelligence, and Product Lifecycle Management, as
well as industry-specific applications tailored for the service provider, chemical/pharmaceutical, and
utilities industries. Mobile Infrastructure is embedded within SAP NetWeaver, which provides the
technology foundation for SAP Business Suite.
2 Architecture of SAP Mobile Infrastructure

SAP Mobile Infrastructure consists of the following main building blocks:
The MI Client is a platform-independent and open standards-based client runtime, featuring a
JSP/AWT UI programming model and an extensive MI Client API offering generic services to
mobile applications. It is installed locally on the mobile device.
The MI Server is a lean synchronization and replication middleware, completely integrated into
SAP Web Application Server. It features specialized administration and monitoring tools
specifically targeted at managing, monitoring, and trouble-shooting large numbers of mobile
devices.
The Mobile Development Kit, integrated into SAP NetWeaver Developer Studio facilitates the
development and testing of mobile applications based on MI.
2.1 MI Client
The SAP MI Client is a Java-based framework offering generic services to mobile applications through
a rich set of Application Programming Interfaces (API). The API supports features like data
synchronization, read/write access to replicated business data, data persistence (to databases or local
file system), peripheral support (printers, scanners, RFID, etc.), configuration management,
logging/tracing, multi-user support, user authorizations, and application management.
In principle, the MI Client (and hence all mobile applications on top of MI) runs on all device platforms
that support Java. For more details on platforms and Java versions supported by SAP, check the
Product Availability Matrix for SAP NetWeaver and SAP Mobile Infrastructure.
SAP MI Client offers two different UI programming models:
The Java Server Pages (JSP) UI is displayed in the mobile device’s browser and is best suited to
white-collar applications like Mobile Asset Management (MAM) or Mobile Sales for Handheld
(MSH). This UI approach enables mobile developers to use existing Web user interface skills to
create mobile applications that run in a browser but on an occasionally connected device.
The Abstract Window Toolkit (AWT) uses Java controls for UI and is best-suited to blue collar
applications like Mobile Direct Store Delivery (DSD).

2.2 MI Server
The SAP MI Server is completely integrated into the SAP Web Application Server. The MI Server is
responsible for synchronization and replication, administration and monitoring, as well as lifecycle
management for the mobile landscape.
Synchronization and Replication

The MI server comprises a strong data synchronization and replication middleware, covering the
following functional areas:
Ensured, encrypted, compressed data transfer
Support of any connection type
Two synchronization modes
Multiple back end support
Mobile System Administration and Monitoring

The MI server contains tools specifically designed for administering and monitoring such landscapes.
Well integrated into the SAP Computing Center Management System (CCMS), they provide alerting
functionalities, a monitoring cockpit that enables end-to-end tracking of the data flow between the back
end and the mobile devices, remote configuration of devices, logs and traces from mobile devices,
and much more.
Lifecycle and Device Management

In mobile landscapes, the remote management of devices and the remote deployment of software to
these devices is key to keeping TCO down. The MI server allows applications and patches based on
user and role definitions to be deployed remotely. End users automatically receive software updates
when synchronizing their devices. Server-side lifecycle management is completely integrated with
SAP NetWeaver lifecycle management tools to ensure consistent roll-out of MI and mobile
applications across the mobile landscape.
2.3 Mobile Development Kit (MDK)

Many customers and partners are interested in mobilizing their mission-critical business applications
by modifying SAP standard applications or developing their own applications from scratch using
Mobile Infrastructure. To help customers and partners develop Mobile Infrastructure-based
applications quickly and easily, SAP offers the Mobile Development Kit (MDK). This was first provided
with release SAP Mobile Engine 2.1 SP01. The MDK offers developers an integrated and
comprehensive set of documentation and tools to:
Understand the development concept quickly
Set up the development environment easily
Start programming the first example programs
Provide in-depth discussion of the client API, including Javadoc
Find short, precise, and helpful answers to all implementation-specific questions (including best
practices, standards & guidelines, trouble-shooting information etc.)
Discuss implementation-specific questions
The MDK comprises all developer documentation that exists on Mobile Infrastructure. It is the central
tool that every developer for mobile applications should use throughout the entire development
process. The MDK is updated and enhanced regularly. All feedback from application development
teams in- and outside SAP is directly brought into the MDK to consistently improve the depth and
scope of the development information contained there. The shipment of the MDK has changed: with
ME 2.1 it was a separate shipment, but as of MI 2.5, the MDK has been integrated into the SAP
NetWeaver Developer Studio.

3 Different Sizing Guidelines
3.1 Sizing for SAP Mobile Asset Management – Standard and

Utilities Version
3.1.1 SAP Mobile Asset Management (SAP MAM) 2.5 SR 2

SAP Mobile Asset Management is one of a number of applications (such as Mobile Sales / Service for
Handheld, Handheld Direct Store Delivery, Mobile Procurement and Time and Travel Notebook)
offered within the framework of SAP Mobile Business. Mobile Asset Management is a full offline
mobile application that helps field service and field maintenance technicians to perform their daily
activities at their customer sites and at their plants with all the needed data synchronized onto their
mobile devices. In addition to this, the field personnel can capture related data, such as time and
material used, on their devices and then synchronize with the back office.
Apart from the mobile device, a back-end system with an SAP Web Application Server and the Mobile
Engine components are required (see figure below).
Figure 1: Overview of the Mobile Application
For sizing, only the SAP J2EE Server and the ABAP Server component of the Mobile Engine have to
be considered. If both servers run on the same machine, the sizing is additive. The measured
business scenario reflects the every day work of service technicians.
Measured Scenario as a Basis for Sizing
The scenario includes ten service orders per technician. Each order includes three business partners,
one functional location, one notification, five operations, one piece of equipment, and five materials.
Also, spare parts must be available in the mobile inventory for each technician. The average inventory
count per user is, therefore, 1000 materials. In addition to this, there is the assumption that one
measurement document is completed on average for each order. A service technician synchronizes
after completing five orders (that is, 25 operations) and downloads five newly assigned service orders
with the above described characteristics. Synchronization takes place at least twice a day, once in the
morning and once in the evening. Also, the synchronization can take place when a technician has
completed five service orders. This scenario attempts to account for a representative number of
service orders and synchronizations per day.

No. of objects on
Entity device
Orders 10
Operations 50
Order Partners 30
Order Components 50
Notifications 10
Notification Items 20
Notification Tasks 20
Notification Causes 20
Notification Activities 20
Equipment 20
Equipment Partners 40
Equipment Classification data 100
Functional Location 20
Functional Location Partners 40
Functional Location classification data (5 per FL) 100
Inventory (spare Parts) 1000
Partners 10
Catalog Codes 500
Table: Measured Scenario MAM
Sizing the Mobile Engine Components and Back-End System

One business case refers to one completely run scenario as described above. We assume the service
technicians synchronize their data twice per day, once in the morning, and once in the evening, so that
there are peak hours that have to be satisfied. The measurements, which serve as the foundation for
sizing, were performed for Mobile Infrastructure version 2.5, SP 13.
Category Up to # SAP Web Application Server SAP ECC

Synchronizations
[1]
per hour SAPS SAPS Memory SAPS SAPS Memory
J2EE ABAP ABAP DB ABAP ABAP
Server Server Server Server Server Server
Small 100 8 200 1 GB 200 350 1 GB
Medium 250 15 400 1 GB 500 800 1 GB
Large 500 30 800 1 GB 1,000 1,600 1 GB
Extra 1,000 60 1,600 2 GB 2,000 3,200 2 GB
Large
For more information on memory sizing for the database server, see the chapter “Memory Sizing for
the Database Server” in this document.
For more information on network load, see the document: "Sizing Front End Network Load" at
http://service.sap.com/sizing -> Sizing guidelines -> Business applications.
[1]
For more information on SAPS and their equivalent in hardware performance, see
www.sap.com/benchmark -> SAPS.

3.1.2 SAP Mobile Asset Management for Utilities (SAP MAU) 1.0, SR2
SAP MAU integrates the mobile processes with SAP for Utilities and Enterprise Asset Management. It
is based on SAP MAM and uses the same functions as well as some extended functions, for example,
meter replacement and meter readings.
The scenario includes ten service orders (two standard orders, two disconnection orders, two meter
reading orders, two meter repair orders and two periodic replacement orders) per technician. Each
order includes three operations, one functional location, two business partners and one piece of
equipment. The device additionally contains 50 materials.
Sizing the Mobile Engine Device and Back-End System
One business case refers to one complete scenario, as described above. We assume the service
technicians synchronize their data twice per day, once in the morning, and once in the evening, so that
there are peak hours that have to be satisfied. The synchronization processes simulate the
synchronization of one completed and one new dataset.
The reference measurements were conducted on Mobile Engine, version 2.1 SP03 (on Web
Application Server 6.20).
Category Up to # SAP Web Application Server SAP ECC

Synchronizations
per hour [2]
SAPS SAPS Memory SAPS Memory in
J2EE ABAP in MB MB
Server Server
Small 100 10 200 512 340 512
Medium 250 25 410 512 680 512
Large 500 50 820 1,024 1,360 1,024
Extra Large 1,000 100 1,650 2,048 2,750 2,048
[2]

3.2 Sizing for SAP Mobile Sales for Handheld with CRM 5.x
SAP Mobile Sales for Handheld is one of a number of applications, such as Direct Store Delivery,
Mobile Service for Handheld, Mobile Procurement or Time and Travel offered within the framework of
SAP Mobile Business.
SAP Mobile Sales for Handheld enables you to carry out your daily work as a sales representative
anywhere and at any time, using a handheld device in offline mode. It offers you quick access to
current sales-related information, and provides you with a wide range of functions. Moreover, it
enables you to manage customer information and business activities when creating quotations and
sales orders, as well as allowing you to maintain opportunities.
Functional range:
Account Management
Sales Order Management
Opportunity and Quotation Management
Activity and Task Management
Product and Price Information
The following graph gives you a brief overview of the architecture of SAP Mobile Sales for Handheld.
For information on sizing the CRM Server, see the Quick Sizer under
http://Service.sap.com/quicksizing, for information on sizing the IPC, see the sizing document at
http://service.sap.com/sizing -> Media Library -> Literature.
Figure 2: Overview of Sales for Handhelds

3.2.1 Measured Scenarios as a Basis for Sizing
Two data sets were measured, reflecting different complexities.
Note: The download data volume signifies the amount of data that will be downloaded to the device.
The upload data volume signifies the number of business objects that will be created on the device
and subsequently synced to the backend.
3.2.2 Sizing the Mobile Infrastructure Components and Back-End System

One business case refers to one complete scenario, as described above. We assume the sales
representatives synchronize their data twice per day, once in the morning, and once in the afternoon
and evening, so that there are peak hours that have to be satisfied.
Sizing for Field Activity Management and Field Contact Management are the same.
Delta Synchronization for small-size data set
[3]
Category Up to # Component Requirements in SAPS CRM Server
Synchronizations per
hour
Small 50 1,300
Medium 100 2,500
Large 250 5,200
Extra Large 500 10,000
[3]
www.sap.com/benchmark.

Delta Synchronization for mid-size data set
[3]
Category Up to # Component Requirements in SAPS CRM Server
Synchronizations per
hour
Small 50 2,500
Medium 100 5,000
Large 250 12,500
Extra Large 500 25,000
Note: SAP strongly recommends an Expert Sizing for business requirements demanding particular
care, for example, when it comes to high user data volumes and/or high numbers of concurrent users.
For more information on network load, see the document: "Sizing Front End Network Load" at
http://service.sap.com/sizing -> Media Library -> Literature.
3.3 Sizing SAP Mobile Direct Store Delivery

SAP Mobile Direct Store Delivery (DSD) addresses the needs of drivers and van sellers in any direct-
store-delivery situation. Mobile DSD is a tailored solution that enables drivers to perform an array of
route transactions on mobile devices in disconnected mode. The solution empowers delivery
personnel with the tools to serve customers and manage relationships. At the beginning and end of
the day, users can seamlessly exchange data between their mobile devices and the SAP DSD back
end.
3.3.1 Functions of SAP mobile DSD

The key capabilities of SAP Mobile Direct Store Delivery include:
Check-out, check-in and on-truck inventory management
Delivery, invoice and order processing
Customer collections, driver expenses
Pre-sold and direct sales from truck deliveries
Invoicing and payment collections
Taking orders for future delivery
Tour, visit and visit-activity processing
On-truck inventory management
Processing of downloaded transactions or creating new transactions on handheld device
Delivery of pre-sold orders
Direct sales from truck
Customer invoicing
Payment collection for customer open items
Recording driver expenses
Invoicing and order pricing via Mini Sales Pricing Engine (Mini SPE).
[3]
www.sap.com/benchmark.

3.3.2 Architecture of SAP mobile DSD
System View
DSD – System Landscape
Backend
SAP ERP
Mobile Pricing Data Extractor
DSD Connector
Mobile DSD Customizing

DB
Device
RFC
Mobile DSD DSD Pricing
Application Engine Middleware
MI Client SAP NetWeaver

http/https SAP WebAS
Components
DSD MI Server
Admin Console Components
DB
Figure 3: Architecture of SAP mobile DSD
3.3.3 Measured Scenarios and Sizing guidelines

Three scenarios with different numbers of customers/visits were tested; each customer had one order
and fifty line items. The small scenario has 20 customers/visits, the medium 40 and the large one 60.
One business case refers to one complete scenario, as described above.
The measurements which serve as the foundation for sizing were performed for Mobile Infrastructure
version 2.5, SP 16.
Synchronization Process
The overall DSD scenario consists of three steps:
1. Preparation
In the preparation phase the backend sends the tour to the middleware server. Afterwards, the
data are available in the Outbound Queue. Preparation runs can be triggered by the
synchronization, but they usually run at night.
2. Synchronization to the Handheld (Download)
During the synchronization which is triggered by the handheld, the middleware server downloads
the tour to the handheld.
3. Synchronization to the backend (Upload)
This step is also triggered by the handheld and uploads the completed tour from the handheld to
the backend.
In our measured mobile DSD scenario the upload and the preparation phase are combined to one
step. This means that directly after the upload the backend prepared the next tour and sends it to the
middleware.
Step 2: Synchronization to the Handheld
We assume 1000 synchronizations per hour. The CPU sizing for the backend system is irrelevant.

Scenario Requirements for the Web Application Server
SAPS Memory in MB
Small (20 visits) 150 2,048
Medium (40 visits) 200 2,048
Large (60 visits) 250 3,072
Step 1&3: Synchronization to the backend and preparation for the next tour in outbound queue
We assume 1000 synchronizations per hour.
Scenario SAP Web Application Server SAP ECC

SAPS Memory in MB SAPS Memory in MB
Small (20 visits) 650 2,048 2,700 2,048
Medium (40 visits) 950 2,048 4,200 2,048
Large (60 visits) 1,300 3,072 6,500 3,072
3.4 Sizing SAP Mobile Sales for Handheld (with R/3 and ECC)
3.4.1 Measured Scenarios as a Basis for Sizing

There were approximately 1,800 material masters and 300 customers as master data on the mobile
client. Additional master data, such as the order type, also existed but it has very little influence on
sizing.
The synchronization process takes place in the afternoon and evening, and consists of two
synchronization phases, upsynch and downsynch.
1. Upsynch 15 sales orders with 50 line items and one business partner each, which were created on
the handheld.
2. Downsynch the order numbers for the above orders.

3.4.2 Sizing the Mobile Engine components and backend system
The measurements which serve as the foundation for sizing were performed for Mobile Engine version
2.5, SP 02.
Category Up to # SAP Web Application Server Enterprise Core

Synchronizations Component
per hour [4]
SAPS SAPS Memory SAPS Memory
J2EE ABAP in MB in MB
Server Server
Small 100 30 200 512 2,600 1,024
Medium 250 50 400 512 5,250
1,024
Large 500 100 800 1,024 10,500 2,048
Extra Large 1,000 200 1,650 1,024 21,000 4,096
3.5 Sizing SAP Mobile Time Sheet 2.0

The sizing for SAP Mobile Time Sheet uses two different scenarios to match different business cases.
For the single mode scenario, synchronization takes place once a week, and for the administrative
user scenario, synchronization is performed on a daily basis.
3.5.1 Single Mode Scenario

The business case consists of an employee recording time sheet data for himself. The employee
creates one time entry per hour, for a 40-hour work week. Each time entry is composed of 5 time
attributes and a long text (additional information) made up of 30 characters. Synchronization takes
place weekly. During synchronization, 40 new time records are uploaded to the backend and 250 pick-
list records are downloaded. In addition, the customizing is also downloaded. The customizing
consists of about 130 records of field selection, rejection reasons and target hours.
3.5.2 Assumption
The measurements, which serve as the foundation for sizing, were performed for NetWeaver
Mobile Infrastructure 7.0 SP14 PL00.
This sizing assumes that all customizing entries are downloaded with every synchronization.
We recommend limiting the frequency with which the customizing data is synchronized.
3.5.3 Sizing guideline

Category Up to # SAP NetWeaver Server SAP ERP
Synchronizations
per hour
SAPS Memory in SAPS Memory
GB in GB
Small 250 650 8 200 4

Medium 500 1300 8 400 4
Large 1000 2600 8 800 4
[4]

3.5.4 Administrative User Scenario
The business case consists of an administrative user entering data for 15 employees. The administrative
user records 8 time entries per day for each of the 15 employees, for a total of 120 entries per day. Each
time entry is composed of 5 time attributes and a long text (additional information) made up of 30
characters. Synchronization takes place daily. During synchronization, 120 new time records are
uploaded to the backend. In addition, 250 pick-list records as well as the customizing data are
downloaded for each of the employees as well as for the administrative user. The customizing
consists of about 130 records of field selection, rejection reasons and target hours.
3.5.5 Assumption
Mobile Infrastructure 7.0 SP14 PL00.
This sizing assumes that all customizing entries are downloaded with every synchronization.
We recommend limiting the frequency with which the Customizing data is synchronized.
Sizing guideline
Synchronizations
per hour
GB in GB
Small 250 4,600 8 1,400 4

Medium 500 9,100 16 2,800 8
Large 1,000 18,200 32 5,500 16
3.6 Sizing SAP Mobile Travel Expenses 2.0

The sizing for SAP Mobile Travel Expenses uses two different scenarios to match different business
cases. For a daily trip scenario, synchronization takes place once a week, and for a weekly trip
scenario, synchronization is performed on a monthly basis.
3.6.1 Daily Trip Scenario

The business case involves the synchronization of five created trips and 5 changed trips. Each trip
consists of five receipts and two segments and covers one day. Synchronization usually takes place
on a weekly basis.
3.6.2 Assumption
Mobile Infrastructure 7.0 SP14 PL00
This sizing assumes that the customizing data not downloaded with every synchronization.


Synchronizations
per hour
GB in GB
Small 250 1,200 4 1,100 4

Medium 500 2,300 8 2,200 8
Large 1,000 4,600 16 4,300 16
3.6.4 Weekly Trip Scenario

The business case involves the synchronization of four created trips and four changed trips. Each trip
consists of 25 receipts and ten segments and covers one week. The synchronization usually takes
place on a monthly basis.
3.6.5 Assumption
Mobile 7.0 SP3 PL06.
This sizing assumes that the customizing data not downloaded with every synchronization.

Synchronizations
per hour
GB in GB
Small 250 1,200 4 1,700 4

Medium 500 2,400 8 3,400 8
Large 1,000 4,800 16 6,800 16
4 Sizing for Mobile Infrastructure Standalone

Many customers and partners are interested in mobilizing their mission-critical business applications
by modifying SAP standard applications or developing their own applications from scratch using
Mobile Infrastructure. The scenario where MI is used to develop own applications from scratch is
called MI Standalone. To help customers and partners develop Mobile Infrastructure-based
applications quickly and easily, SAP offers the Mobile Development Kit (MDK), which is itself an
integral part of NetWeaver Developer Studio.
Since every customer application is different, giving concrete sizing figures for any customer
application is not possible. Nonetheless, SAP does provide some sample scenarios that can serve as
a guideline for sizing such custom-made mobile applications.
All client-side measurements have been performed on MI 2.5 SP13. Server-side measurements were
performed on MI 2.5 SP13 and MI 7.0 SP05 and their results are published in separate tables.

Note: If your data volume is beyond the volume of the largest scenarios described in this
section, it is necessary to perform customer-specific sizing.
Customers developing their own applications should pay particular attention to the performance
chapter in the Mobile Development Kit (MDK). They should also use application-specific tuning options
(such as additional indices on important tables).
4.1 Introduction to the Smart Sync Data Model

The measurements below make regular reference to the Smart Synchronization data model. We will,
therefore, give a short introduction to this model. For a thorough introduction to Smart
Synchronization, read the architecture chapters within the Technical Infrastructure Guide[8], or the
[9]
Smart Synchronization chapter within Mobile Development Kit .
The central entity in Smart Synchronization is the SyncBO (Synchronizer Business Object). A SyncBO
can be considered as a downsized business object that is made available to mobile devices. During
the mobile development process, the developer defines which attributes of the business object in the
back end (with Business Application Programming Interfaces (BAPI) to access them) are made
available to mobile devices. Furthermore, foreign key relationships between SyncBOs can be defined.
Such a relationship is also known as “cascading”. Additionally, the developer defines additional
properties of a SyncBO, such as synchronization type (Two-way, Timed Two-Way, Server-Driven,
Upload), type checks (yes/no) and so on.
It is important to differentiate between the SyncBO definition itself (meta-data) and a SyncBO instance
(the data).
On a meta-data level, a SyncBO consists of one header row (also known as a “top row”) and possibly
several item rows. This then defines the generic structure of the SyncBO instances.
Example: SyncBO definition for Customer

In the SyncBO Customer the header row has fields like
Customer ID
Customer name
Street
City
Etc.
The SyncBO Customer may also have several item types for
Banking information (item type 010)
Customer orders (item type 020)
Etc.
Figure 4: Example: SyncBO definition for Customer
On a data level, such a generic structure of a business object is filled with the data of a concrete
object instance. In the SyncBO instance, the header row is instantiated only once, while all item types
may be instantiated several times.
[8]
The Technical Infrastructure Guide can be downloaded from SAP Service Marketplace at
http://service.sap.com/nw-mobile > Mobile Infrastructure > Media Library > Documentation & Guides
[9]
The Mobile Development Kit is delivered together with SAP NetWeaver Developer Studio (NWDS).
The MDK documentation (including extensive chapters on Smart Synchronization) can be found in
NWDS under Help > Help Contents. The MDK documentation is also available online on SAP
Developer Network at http://media.sdn.sap.com/public/html/submitted_docs/MI/MDK_2.5/index.htm.

Example: SyncBO Instance for Customer Henry Miller
In SyncBO instance Customer Henry Miller, the header row
fields may be filled like this:
Customer ID: 000254
Customer name: Miller
Street: The Burrow 12
City London
And so on
The items rows may be filled like this:
Banking information (item type 010; 2 item instances)
o Bank 1: Bank of Scotland
o Account no. 1: 123456
o Bank 2: Credit Suisse
o Account no. 2: 98765
Customer orders (item type 020; 3 items instances)
o Order no. 1: 45678
o Order value 1: 1200€
Figure 5: Example: SyncBO Instance for Customer Henry Miller

In the SyncBO definition, the developer can also define foreign key relationships between SyncBOs.
These can be evaluated during synchronization to determine which object instances are synchronized
to a given mobile device. If, for example, a SyncBO Order holds a foreign key relationship to SyncBO
Customer (meaning that an order was placed by a given customer), then synchronization can be
configured to:
Synchronize orders and customers independently
OR
Synchronize only those customers to the mobile devices for whom there is an order to which they
belong and which itself is synchronized to the mobile device.
The figure below shows the dependency relationships for a complex mobile application.

Figure 5: Dependency relationships for a complex mobile application
4.2 Sizing the MI Client

From a sizing and performance perspective, several runtime components on the mobile device
influence application performance: the Java Runtime Environment (JRE), the MI Client and the mobile
application itself. For JSP-based applications, the device browser is essentially a runtime component
as well, since the browser rendering time influences the average response time experienced by the
mobile user.
A mobile device cannot be “sized” in the strict sense, since it is not possible to add additional CPUs or
even add memory to increase application performance. The memory cards that can be inserted into
the handheld have a considerably lower read-write access time than the built-in memory of the device.
They are, therefore, not suitable for increasing device performance.
CPU and Memory Sizing

The data load on the client influences the recommended minimum memory of a mobile device and the
average screen response time for applications. SAP has defined two scenarios (mid-size and XXL),

with concrete numbers of business objects and related object items that are downloaded to the mobile
device.
The table below shows details about the scenario definitions, together with the recommended memory
on a PocketPC device with a given CPU in order to achieve acceptable performance (< 3 seconds for
AWT-based applications and < 4 seconds for JSP-based applications).
Scenario # of # of BO Recommended Average Average CPU as Basis

Business Items Minimum Response Response for
Objects Memory Time AWT Time JSP Measurements
(BO)
Midsize 2500 13500 64 MB < 3 sec < 4 sec PXA 250
XXL 7000 48000 128 MB < 3 sec < 4 sec PXA 272
Table: Recommended CPU and memory for different data loads on mobile device
4.3 Sizing the Web Application Server (MI Server)

When sizing the Web Application Server (which serves as the middleware for SAP Mobile
Infrastructure), two separate aspects need to be differentiated for Smart Synchronization:
By “synchronization”, we mean the process of message exchange and processing that occurs
between a mobile device and the Web Application Server (Web AS). Synchronization starts when
end users click the Synchronize button on their mobile device. It ends when the mobile device
browser displays the success or error message of that process.
By “replication”, we mean the process of data exchange between Web AS and application back
end. The replication can be triggered through several events:
- For Two-Way SyncBOs, replication occurs when the Web AS processes download messages
that have been issued from a mobile device.
- For Timed Two-Way SyncBOs, replication is actively triggered by the administrator manually
(using transaction MEREP_EX_REPLIC) or triggered by a scheduled background job
- For Server-Driven SyncBOs, replication occurs whenever a change is made to the

corresponding Business Object in the application back end
In the following subchapters, sizing figures are given for synchronization and a formula is proposed for
estimating replication times.
Synchronization
As it is completely integrated into SAP Web Application Server (Web AS), the MI server sizing applies
to Web AS ABAP and Web AS Java, and only these two components need to be considered. If both
servers run on the same machine, the sizing is additive. The measured business scenario reflects the
every day work of service technicians.

The scenario includes 25 orders that are downloaded to the mobile device. Each order includes 12
related objects. The average object has five items (true for orders and related objects). Additionally,
250 material master objects reside on the device.
Furthermore, the assumption is that five orders have been changed and are uploaded during
synchronization. In addition to this, five new orders are downloaded from the application back end
during the same synchronization cycle.

Sizing the Web Application Server (MI Server)
One business case refers to one complete run of the scenario, as described above. We assume the
users synchronize their data twice per day, once in the morning, and once in the evening, so that there
are peak hours that have to be satisfied.
Category Up to # Application Server DB Server
Synchronizations [10]
per hour SAPS SAPS Memory SAPS Memory
J2EE ABAP in GB
Server Server
Small 250 25 400 1 GB 500 For details,
see chapter
Medium 500 50 800 2 GB 1,000 “Memory
Large 1,000 100 1,600 4 GB 2,000 Sizing for the
Database
Server”
Measurement for MI 2.5 SP13
Category Up to # Application Server DB Server

Synchronizations
per hour SAPS Memory in SAPS Memory
ABAP GB
Server
Small 250 500 1 GB 700 For details,
see chapter
Medium 500 1,000 2 GB 1,250 “Memory
Large 1,000 2,000 4 GB 2,500 Sizing for the
Database
Server”
Measurement for MI 7.0 SPS05
Replication
In order to calculate the time required to perform replication between the Web AS and the application
back end, the following applies: For an SAP Web Application Server that is sized as recommended
above, the replication of 1 million rows takes approximately one hour. The customer then needs to add
the time that is needed for data selection in the back end to that figure.
5 Memory Sizing for the Database Server

For maximum middleware performance and low synchronization response times when synchronizing
devices, it is recommended to add memory to the database server of the Web Application Server.
Optimal performance is reached if the memory is equal or higher than the sum of the sizes of tables
MEREP_207 and MEREP_10700, plus their indexes. With such a memory, hard disc access to the
database server is brought to a minimum. To estimate the sizes of the two tables plus their indexes,
customers should use the following formulas:
[10]

1 million rows in MEREP_207 plus the resulting indexes use about 2,8 GB
1 million rows in MEREP_10700 plus the resulting indexes use about 0,5 GB
If the memory differs to the recommendation above, the time required to synchronize a mobile device
will be affected by the size of the tables MEREP_207 and MEREP_10700. The time increase for each
synchronization can be estimated at 10-20% per 10 million rows in the above-mentioned tables.
This is applicable for all Smart Synchronization-based mobile applications, that means MAM,
MAU, MSR, MI Standalone, and so on.
6 Change History, Comments and Feedback

Changes to version 1.9.1 of this document are:
SAP Mobile Timesheet 2.0 updated
SAP Mobile Travel Expenses 2.0 updated
Architecture of SAP mobile DSD updated
Changes to version 1.9 of this document are:

New Sizing for SAP Mobile Sales for Handheld with CRM 5.0

The chapters were re-structured
Mobile DSD included

Chapter 2 (Architecture of SAP Mobile Infrastructure) completely re-written
Sizing Scenario for Mobile Asset Management extended.
Sizing figures for Mobile Asset Management updated
Introduction of new chapter 8 (MI Standalone)
Introduction of new chapter 9 (Memory Sizing to the Database Server)
Updated sizing for MSR (the number of line items has been increased by a factor of 10)
Comments and feedback on this document would be highly appreciated. Please direct them to
Sebastian Schmitt (sebastian.schmitt@sap.com), Performance, Data Management & Scalability, SAP
AG.

Sizing Mobile 2 0

Enviado por

Dados do documento

Descrição original:

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Sizing Mobile 2 0

Enviado por

Direitos autorais:

Formatos disponíveis

Sizing Guide

Released for SAP Customers and Partners

Document Version 2.0, August 2008

Released for SAP Customers and Partners

HTML, XML, XHTML and W3C are trademarks or

Java is a registered trademark of Sun Microsystems, Inc.

JavaScript is a registered trademark of Sun

MaxDB is a trademark of MySQL AB, Sweden.

SAP, R/3, mySAP, mySAP.com, xApps, xApp, SAP

© SAP AG Released for SAP Customers and Partners 2

1 INTRODUCTION TO SAP MOBILE BUSINESS................................................................................. 2

2 ARCHITECTURE OF SAP MOBILE INFRASTRUCTURE ............................................................... 2

6 CHANGE HISTORY, COMMENTS AND FEEDBACK .................................................................... 20

© SAP AG Sizing SAP Mobile Business - SAP Customers and Partners 1

2 Architecture of SAP Mobile Infrastructure

© SAP AG Sizing SAP Mobile Business - SAP Customers and Partners 2

Synchronization and Replication

Mobile System Administration and Monitoring

Lifecycle and Device Management

2.3 Mobile Development Kit (MDK)

© SAP AG Sizing SAP Mobile Business - SAP Customers and Partners 3

3.1 Sizing for SAP Mobile Asset Management – Standard and

3.1.1 SAP Mobile Asset Management (SAP MAM) 2.5 SR 2

Figure 1: Overview of the Mobile Application

© SAP AG Sizing SAP Mobile Business - SAP Customers and Partners 4

Sizing the Mobile Engine Components and Back-End System

Category Up to # SAP Web Application Server SAP ECC

© SAP AG Sizing SAP Mobile Business - SAP Customers and Partners 5

Category Up to # SAP Web Application Server SAP ECC

© SAP AG Sizing SAP Mobile Business - SAP Customers and Partners 6

Figure 2: Overview of Sales for Handhelds

© SAP AG Sizing SAP Mobile Business - SAP Customers and Partners 7

3.2.2 Sizing the Mobile Infrastructure Components and Back-End System

Delta Synchronization for small-size data set

© SAP AG Sizing SAP Mobile Business - SAP Customers and Partners 8

3.3 Sizing SAP Mobile Direct Store Delivery

3.3.1 Functions of SAP mobile DSD

© SAP AG Sizing SAP Mobile Business - SAP Customers and Partners 9

Mobile Pricing Data Extractor

Mobile DSD Customizing

MI Client SAP NetWeaver

Figure 3: Architecture of SAP mobile DSD

3.3.3 Measured Scenarios and Sizing guidelines

© SAP AG Sizing SAP Mobile Business - SAP Customers and Partners 10

We assume 1000 synchronizations per hour.

Scenario SAP Web Application Server SAP ECC

3.4.1 Measured Scenarios as a Basis for Sizing

© SAP AG Sizing SAP Mobile Business - SAP Customers and Partners 11

Category Up to # SAP Web Application Server Enterprise Core

3.5 Sizing SAP Mobile Time Sheet 2.0

3.5.1 Single Mode Scenario

3.5.3 Sizing guideline

Small 250 650 8 200 4

© SAP AG Sizing SAP Mobile Business - SAP Customers and Partners 12

Small 250 4,600 8 1,400 4

3.6 Sizing SAP Mobile Travel Expenses 2.0

3.6.1 Daily Trip Scenario

© SAP AG Sizing SAP Mobile Business - SAP Customers and Partners 13

Category Up to # SAP NetWeaver Server SAP ERP

Small 250 1,200 4 1,100 4

3.6.4 Weekly Trip Scenario

3.6.6 Sizing guideline

Category Up to # SAP NetWeaver Server SAP ERP