sizing mobile 2 0

8/6/2019 Sizing Mobile 2 0

1/22


2/22

SAP AG Released for SAP Customers and Partners 2

Copyright 2008 SAP AG. All rights reserved.

No part of this publication may be reproduced or

transmitted in any form or for any purpose without the

express permission of SAP AG. The information

contained herein may be changed without prior notice.

Some software products marketed by SAP AG and its

distributors contain proprietary software components of

other software vendors.

Microsoft, Windows, Outlook, and PowerPoint are

registered trademarks of Microsoft Corporation.

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,

Intelligent Miner, WebSphere, Netfinity, Tivoli, andInformix are trademarks or registered trademarks of IBM

Corporation in the United States and/or other countries.

Oracle is a registered trademark of Oracle Corporation.

UNIX, X/Open, OSF/1, and Motif are registered

trademarks of the Open Group.

Citrix, ICA, Program Neighborhood, MetaFrame,

WinFrame, VideoFrame, and MultiWin are trademarks or

registered trademarks of Citrix Systems, Inc.

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

contained in this document serves informational purposes

only. National product specifications may vary.

These materials are subject to change without notice.

These materials are provided by SAP AG and

its affiliated companies ("SAP Group") for informational

purposes only, without representation or warranty of any

kind, and SAP Group shall not be liable for errors or

omissions with respect to the materials. The only

warranties for SAP Group products and services are those

that are set forth in the express warranty statements

accompanying such products and services, if any.

Nothing herein should be construed as constituting an

additional warranty.

Disclaimer

Some components of this product are based on Java.Any code change in these components may cause

unpredictable and severe malfunctions and is therefore

expressively prohibited, as is any decompilation of these

components.

SAP Library document classification: CUSTOMERS &

PARTNERS

Documentation in the SAP Service Marketplace

You can find this documentation at the following address:http://service.sap.com/sizing
http://service.sap.com/sizinghttp://service.sap.com/sizing


3/22

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

TABLE OF CONTENTS

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

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

2.1 MI CLIENT ................... ........................ ....................... ........................ ........................ ....................... 22.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 ................... ....................... ............... 73.3 SIZING SAP MOBILE DIRECT STORE DELIVERY .................. ........................ ....................... .................. 93.4 SIZING SAP MOBILE SALES FOR HANDHELD (WITH R/3 AND ECC) .................................................... 11

3.5 SIZING SAP MOBILE TIME SHEET 2.0................ ....................... ........................ ....................... .......... 123.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 ................... ........................ ....................... ........................... .................... .... 174.3 SIZING THE WEB APPLICATION SERVER (MISERVER)...... ........................... ....................... ................ 18

5 MEMORY SIZING FOR THE DATABASE SERVER....................................................................... 19

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


4/22


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 toa consultant who simply tracks time and expenses on a mobile device for synchronization to a backoffice system at a later time. SAP Mobile Infrastructure provides capabilities that support mobile

scenarios in cross-industry applications, such as Customer Relationship Management, HumanResources, Supply Chain Management, Business Intelligence, and Product Lifecycle Management, aswell as industry-specific applications tailored for the service provider, chemical/pharmaceutical, andutilities industries. Mobile Infrastructure is embedded within SAP NetWeaver, which provides thetechnology 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 aJSP/AWT UI programming model and an extensive MI Client API offering generic services tomobile applications. It is installed locally on the mobile device.

The MI Server is a lean synchronization and replication middleware, completely integrated intoSAP Web Application Server. It features specialized administration and monitoring toolsspecifically targeted at managing, monitoring, and trouble-shooting large numbers of mobiledevices.

The Mobile Development Kit, integrated into SAP NetWeaver Developer Studio facilitates thedevelopment 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 througha rich set of Application Programming Interfaces (API). The API supports features like datasynchronization, read/write access to replicated business data, data persistence (to databases or localfile 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 platformsthat support Java. For more details on platforms and Java versions supported by SAP, check theProduct 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 devices browser and is best suited towhite-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 tocreate 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 collarapplications like Mobile Direct Store Delivery (DSD).


5/22


2.2 MI Server

The SAP MI Server is completely integrated into the SAP Web Application Server. The MI Server isresponsible for synchronization and replication, administration and monitoring, as well as lifecyclemanagement for the mobile landscape.

Synchronization and Replication

The MI server comprises a strong data synchronization and replication middleware, covering thefollowing 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 backend 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 tothese devices is key to keeping TCO down. The MI server allows applications and patches based onuser and role definitions to be deployed remotely. End users automatically receive software updateswhen synchronizing their devices. Server-side lifecycle management is completely integrated withSAP NetWeaver lifecycle management tools to ensure consistent roll-out of MI and mobileapplications across the mobile landscape.

2.3 Mobile Development Kit (MDK)

Many customers and partners are interested in mobilizing their mission-critical business applicationsby modifying SAP standard applications or developing their own applications from scratch usingMobile Infrastructure. To help customers and partners develop Mobile Infrastructure-basedapplications quickly and easily, SAP offers the Mobile Development Kit (MDK). This was first providedwith release SAP Mobile Engine 2.1 SP01. The MDK offers developers an integrated andcomprehensive 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 bestpractices, standards & guidelines, trouble-shooting information etc.)

Discuss implementation-specific questions

The MDK comprises all developer documentation that exists on Mobile Infrastructure. It is the centraltool that every developer for mobile applications should use throughout the entire developmentprocess. The MDK is updated and enhanced regularly. All feedback from application developmentteams in- and outside SAP is directly brought into the MDK to consistently improve the depth andscope of the development information contained there. The shipment of the MDK has changed: withME 2.1 it was a separate shipment, but as of MI 2.5, the MDK has been integrated into the SAPNetWeaver Developer Studio.


6/22


3 Different Sizing Guidelines

3.1 Sizing for SAP Mobile Asset Management Standard andUtilities 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 forHandheld, 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 offlinemobile application that helps field service and field maintenance technicians to perform their dailyactivities at their customer sites and at their plants with all the needed data synchronized onto theirmobile devices. In addition to this, the field personnel can capture related data, such as time andmaterial 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 MobileEngine 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 tobe considered. If both servers run on the same machine, the sizing is additive. The measuredbusiness 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 inventorycount per user is, therefore, 1000 materials. In addition to this, there is the assumption that onemeasurement document is completed on average for each order. A service technician synchronizesafter completing five orders (that is, 25 operations) and downloads five newly assigned service orderswith the above described characteristics. Synchronization takes place at least twice a day, once in themorning and once in the evening. Also, the synchronization can take place when a technician hascompleted five service orders. This scenario attempts to account for a representative number ofservice orders and synchronizations per day.


7/22


EntityNo. of objects on

device

Orders 10

Operations 50

Order Partners 30

Order Components 50

Notifications 10Notification 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 10Catalog 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 servicetechnicians synchronize their data twice per day, once in the morning, and once in the evening, so thatthere are peak hours that have to be satisfied. The measurements, which serve as the foundation forsizing, were performed for Mobile Infrastructure version 2.5, SP 13.

SAP Web Application Server SAP ECCCategory Up to #

Synchronizationsper hour SAPS

[1]

J2EEServer

SAPSABAPServer

MemoryABAPServer

SAPSDB

Server

SAPSABAPServer

MemoryABAPServer

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

ExtraLarge

1,000 60 1,600 2 GB 2,000 3,200 2 GB

For more information on memory sizing for the database server, see the chapter Memory Sizing forthe Database Server in this document.

For more information on network load, see the document: "Sizing Front End Network Load" athttp://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.
http://service.sap.com/sizinghttp://www.sap.com/benchmarkhttp://www.sap.com/benchmarkhttp://service.sap.com/sizing


8/22


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. Itis 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. Eachorder includes three operations, one functional location, two business partners and one piece ofequipment. 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 servicetechnicians synchronize their data twice per day, once in the morning, and once in the evening, so thatthere are peak hours that have to be satisfied. The synchronization processes simulate thesynchronization of one completed and one new dataset.

The reference measurements were conducted on Mobile Engine, version 2.1 SP03 (on WebApplication Server 6.20).

SAP Web Application Server SAP ECCCategory Up to #Synchronizationsper hour

SAPS[2]

J2EEServer

SAPSABAPServer

Memoryin MB

SAPS Memory inMB

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


http://www.sap.com/benchmarkhttp://www.sap.com/benchmark


9/22


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 ofSAP Mobile Business.

SAP Mobile Sales for Handheld enables you to carry out your daily work as a sales representativeanywhere and at any time, using a handheld device in offline mode. It offers you quick access tocurrent sales-related information, and provides you with a wide range of functions. Moreover, itenables you to manage customer information and business activities when creating quotations andsales 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 underhttp://Service.sap.com/quicksizing , for information on sizing the IPC, see the sizing document athttp://service.sap.com/sizing -> Media Library -> Literature.

Figure 2: Overview of Sales for Handhelds
http://service.sap.com/quicksizinghttp://service.sap.com/sizinghttp://service.sap.com/sizinghttp://service.sap.com/quicksizing


10/22


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 deviceand 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 salesrepresentatives synchronize their data twice per day, once in the morning, and once in the afternoonand 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

Category Up to #Synchronizations perhour

Component Requirements in SAPS[3]

CRM Server

Small 50 1,300

Medium 100 2,500

Large 250 5,200

Extra Large 500 10,000


www.sap.com/benchmark .
http://www.sap.com/benchmark.http://www.sap.com/benchmark.http://www.sap.com/benchmark.


11/22


Delta Synchronization for mid-size data set

Category Up to #Synchronizations perhour

Component Requirements in SAPS[3]

CRM Server

Small 50 2,500Medium 100 5,000

Large 250 12,500

Extra Large 500 25,000

Note: SAP strongly recommends an Expert Sizing for business requirements demanding particularcare, 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" athttp://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 ofroute transactions on mobile devices in disconnected mode. The solution empowers deliverypersonnel with the tools to serve customers and manage relationships. At the beginning and end ofthe day, users can seamlessly exchange data between their mobile devices and the SAP DSD backend.

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


www.sap.com/benchmark .
http://service.sap.com/sizinghttp://www.sap.com/benchmark.http://www.sap.com/benchmark.http://www.sap.com/benchmark.http://service.sap.com/sizing


12/22


3.3.2 Architecture of SAP mobile DSD

System ViewDSD System Landscape

Backend

http/httpsSAP NetWeaver

SAP WebAS

MI ServerComponents

SAP ERP

RFC

Device

MI ClientComponents

Mobile DSD

Application

DB

Mobile DSD Customizing

DSD Connector

DSD PricingEngine

DSD

Admin Console

Mobile Pricing Data Extractor

DB

Middleware

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 orderand 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 Infrastructureversion 2.5, SP 16.

Synchronization Process

The overall DSD scenario consists of three steps:

1. PreparationIn the preparation phase the backend sends the tour to the middleware server. Afterwards, thedata are available in the Outbound Queue. Preparation runs can be triggered by thesynchronization, but they usually run at night.

2. Synchronization to the Handheld (Download)During the synchronization which is triggered by the handheld, the middleware server downloadsthe 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 tothe backend.

In our measured mobile DSD scenario the upload and the preparation phase are combined to onestep. This means that directly after the upload the backend prepared the next tour and sends it to themiddleware.

Step 2: Synchronization to the Handheld

We assume 1000 synchronizations per hour. The CPU sizing for the backend system is irrelevant.


13/22


Requirements for the Web Application ServerScenario

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.

SAP Web Application Server SAP ECCScenario

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 mobileclient. Additional master data, such as the order type, also existed but it has very little influence onsizing.

The synchronization process takes place in the afternoon and evening, and consists of twosynchronization phases, upsynch and downsynch.

1. Upsynch 15 sales orders with 50 line items and one business partner each, which were created onthe handheld.

2. Downsynch the order numbers for the above orders.


14/22


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 version2.5, SP 02.

SAP Web Application Server Enterprise CoreComponent

Category Up to #Synchronizations

per hourSAPS

[4]

J2EEServer

SAPSABAPServer

Memoryin MB

SAPS Memoryin MB

Small 100 30 200 512 2,600 1,024

Medium 250 50 400 512 5,2501,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 administrativeuser 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 employeecreates one time entry per hour, for a 40-hour work week. Each time entry is composed of 5 timeattributes and a long text (additional information) made up of 30 characters. Synchronization takesplace 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 customizingconsists 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


per hour

SAP NetWeaver Server SAP ERP

SAPS Memory in

GB

SAPS Memory

in GB

Small 250 650 8 200 4

Medium 500 1300 8 400 4

Large 1000 2600 8 800 4




15/22


3.5.4 Administrative User Scenario

The business case consists of an administrative user entering data for 15 employees. The administrativeuser records 8 time entries per day for each of the 15 employees, for a total of 120 entries per day. Eachtime entry is composed of 5 time attributes and a long text (additional information) made up of 30characters. Synchronization takes place daily. During synchronization, 120 new time records areuploaded to the backend. In addition, 250 pick-list records as well as the customizing data aredownloaded 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

The measurements, which serve as the foundation for sizing, were performed for NetWeaverMobile 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


per hour


SAPS Memory inGB

SAPS Memoryin 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 tripscenario, 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 tripconsists of five receipts and two segments and covers one day. Synchronization usually takes placeon a weekly basis.

3.6.2 Assumption

The measurements, which serve as the foundation for sizing, were performed for NetWeaverMobile Infrastructure 7.0 SP14 PL00

This sizing assumes that the customizing data not downloaded with every synchronization.


16/22




per hour


SAPS Memory in

GB

SAPS Memory

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 tripconsists of 25 receipts and ten segments and covers one week. The synchronization usually takesplace on a monthly basis.

3.6.5 Assumption

The measurements, which serve as the foundation for sizing, were performed for NetWeaverMobile 7.0 SP3 PL06.

This sizing assumes that the customizing data not downloaded with every synchronization.



per hour


SAPS Memory inGB

SAPS Memoryin 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 applicationsby modifying SAP standard applications or developing their own applications from scratch usingMobile Infrastructure. The scenario where MI is used to develop own applications from scratch iscalled MI Standalone. To help customers and partners develop Mobile Infrastructure-basedapplications quickly and easily, SAP offers the Mobile Development Kit (MDK), which is itself anintegral part of NetWeaver Developer Studio.

Since every customer application is different, giving concrete sizing figures for any customerapplication is not possible. Nonetheless, SAP does provide some sample scenarios that can serve asa guideline for sizing such custom-made mobile applications.

All client-side measurements have been performed on MI 2.5 SP13. Server-side measurements wereperformed on MI 2.5 SP13 and MI 7.0 SP05 and their results are published in separate tables.


17/22


Note: If your data volume is beyond the volume of the largest scenarios described in thissection, it is necessary to perform customer-specific sizing.

Customers developing their own applications should pay particular attention to the performancechapter 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 SmartSynchronization, read the architecture chapters within the Technical Infrastructure Guide

[8], or the

Smart Synchronization chapter within Mobile Development Kit[9]

.

The central entity in Smart Synchronization is the SyncBO (Synchronizer Business Object). A SyncBOcan be considered as a downsized business object that is made available to mobile devices. Duringthe mobile development process, the developer defines which attributes of the business object in theback end (with Business Application Programming Interfaces (BAPI) to access them) are madeavailable to mobile devices. Furthermore, foreign key relationships between SyncBOs can be defined.Such a relationship is also known as cascading. Additionally, the developer defines additionalproperties 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 possiblyseveral item rows. This then defines the generic structure of the SyncBO instances.

Example: SyncBO definition for Customer

In the SyncBO Customerthe header row has fields like

Customer ID

Customer name

Street

City

Etc.

The SyncBO Customermay 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 concreteobject instance. In the SyncBO instance, the header row is instantiated only once, while all item typesmay 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 inNWDS under Help > Help Contents. The MDK documentation is also available online on SAPDeveloper Network at http://media.sdn.sap.com/public/html/submitted_docs/MI/MDK_2.5/index.htm .
http://service.sap.com/nw-mobilehttp://media.sdn.sap.com/public/html/submitted_docs/MI/MDK_2.5/index.htm.http://media.sdn.sap.com/public/html/submitted_docs/MI/MDK_2.5/index.htm.http://media.sdn.sap.com/public/html/submitted_docs/MI/MDK_2.5/index.htm.http://service.sap.com/nw-mobile


18/22


Example: SyncBO Instance for Customer Henry Miller

In SyncBO instance CustomerHenry Miller, the header rowfields 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 synchronizedto a given mobile device. If, for example, a SyncBO Orderholds a foreign key relationship to SyncBOCustomer (meaning that an order was placed by a given customer), then synchronization can beconfigured to:

Synchronize orders and customers independently

OR

Synchronize only those customers to the mobile devices for whom there is an order to which theybelong and which itself is synchronized to the mobile device.

The figure below shows the dependency relationships for a complex mobile application.


19/22


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 deviceinfluence application performance: the Java Runtime Environment (JRE), the MI Client and the mobileapplication itself. For JSP-based applications, the device browser is essentially a runtime componentas 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 oreven add memory to increase application performance. The memory cards that can be inserted intothe 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 theaverage screen response time for applications. SAP has defined two scenarios (mid-size and XXL),


20/22


with concrete numbers of business objects and related object items that are downloaded to the mobiledevice.

The table below shows details about the scenario definitions, together with the recommended memoryon a PocketPC device with a given CPU in order to achieve acceptable performance (< 3 seconds forAWT-based applications and < 4 seconds for JSP-based applications).

Scenario # ofBusinessObjects(BO)

# of BOItems

RecommendedMinimumMemory

AverageResponseTime AWT

AverageResponseTime JSP

CPU as BasisforMeasurements

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 MobileInfrastructure), two separate aspects need to be differentiated for Smart Synchronization:

By synchronization, we mean the process of message exchange and processing that occursbetween a mobile device and the Web Application Server (Web AS). Synchronization starts whenend users click the Synchronize button on their mobile device. It ends when the mobile devicebrowser displays the success or error message of that process.

By replication, we mean the process of data exchange between Web AS and application backend. The replication can be triggered through several events:

- For Two-Way SyncBOs, replication occurs when the Web AS processes download messagesthat 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 thecorresponding Business Object in the application back end

In the following subchapters, sizing figures are given for synchronization and a formula is proposed forestimating replication times.

Synchronization

As it is completely integrated into SAP Web Application Server (Web AS), the MI server sizing appliesto Web AS ABAP and Web AS Java, and only these two components need to be considered. If bothservers run on the same machine, the sizing is additive. The measured business scenario reflects theevery day work of service technicians.


The scenario includes 25 orders that are downloaded to the mobile device. Each order includes 12related 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 duringsynchronization. In addition to this, five new orders are downloaded from the application back endduring the same synchronization cycle.


21/22


Sizing the Web Application Server (MI Server)

One business case refers to one complete run of the scenario, as described above. We assume theusers synchronize their data twice per day, once in the morning, and once in the evening, so that thereare peak hours that have to be satisfied.

Application Server DB ServerCategory Up to #Synchronizations

per hour SAPS

[10]

J2EEServer

SAPSABAPServer

Memoryin GB SAPS Memory

Small 250 25 400 1 GB 500

Medium 500 50 800 2 GB 1,000

Large 1,000 100 1,600 4 GB 2,000

For details,see chapterMemorySizing for theDatabaseServer

Measurement for MI 2.5 SP13

Application Server DB ServerCategory Up to #

Synchronizationsper hour SAPSABAPServer

Memory inGB

SAPS Memory

Small 250 500 1 GB 700

Medium 500 1,000 2 GB 1,250

Large 1,000 2,000 4 GB 2,500

For details,see chapterMemorySizing for theDatabaseServer

Measurement for MI 7.0 SPS05

Replication

In order to calculate the time required to perform replication between the Web AS and the applicationback end, the following applies: For an SAP Web Application Server that is sized as recommendedabove, the replication of 1 million rows takes approximately one hour. The customer then needs to addthe 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 synchronizingdevices, 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 tablesMEREP_207 and MEREP_10700, plus their indexes. With such a memory, hard disc access to thedatabase server is brought to a minimum. To estimate the sizes of the two tables plus their indexes,customers should use the following formulas:




22/22

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 devicewill be affected by the size of the tables MEREP_207 and MEREP_10700. The time increase for eachsynchronization 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

Changes to version 1.8 of this document are:

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 toSebastian Schmitt (sebastian.schmitt@sap.com), Performance, Data Management & Scalability, SAPAG.
mailto:sebastian.schmitt@sap.commailto:sebastian.schmitt@sap.com

sizing mobile 2 0

Documents

case study sizing natural language/uml requirements for...

telecommunications sector update : sizing up the pure mobile...

md1-0-e-505!06!00001 generator transformer sizing...

sizing a rotary axis using motion...

system sizing sizing methodologies sizing calculations

electrical designer deliverables for design of electrical...

sizing and selection - steven engineering · pdf...

sybase unwired platform 2.1%3a sizing guide (odata%2c mobile...

mobile money market sizing toolkit

line sizing, trv sizing sample

sizing the opportunity of mobile to support energy and ......

sap businessobjects bi4 sizing guide.0 sizing companion...

system performance: sizing and tuning - novell...system...

att475 0 sizing

physical synthesis buffer insertion, gate sizing, wire...

mobile applications development - lecture 0

25 - battery sizing & discharbattery sizing &...

zpcr capacity sizing lab part 2 hands on lab …...zpcr...

the growing fintech ecosystem |sizing up and … 2.0 |...

sizing electric motors for mobile robotics