Sapewm_das Sizing - Basis

Sizing Guide

Document Version: 1.0 – 2012-11-06

CUSTOMER

Sizing SAP Extended Warehouse Management 9.0 - Dock Appointment Scheduling, Version 1.0


Disclaimer

CUSTOMER

© 2012 SAP AG. All rights reserved. 2

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 expressly prohibited, as is any decompilation of these

components.

Documentation in the SAP Service Marketplace

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

Caution

<Put your caution here>

Example

<Put your example here>

Note

<Put your note here>

Recommendation

<Put your recommendation here>

Syntax

<Put your syntax here>

http://service.sap.com/sizing


Typographic Conventions

CUSTOMER


Typographic Conventions

Type Style Description

Example Words or characters quoted from the screen. These include field names, screen titles,

pushbuttons labels, menu names, menu paths, and menu options.

Textual cross-references to other documents.

Example Emphasized words or expressions.

EXAMPLE Technical names of system objects. These include report names, program names,

transaction codes, table names, and key concepts of a programming language when they

are surrounded by body text, for example, SELECT and INCLUDE.

Example Output on the screen. This includes file and directory names and their paths, messages,

names of variables and parameters, source text, and names of installation, upgrade and

database tools.

Example Exact user entry. These are words or characters that you enter in the system exactly as they

appear in the documentation.

<Example> Variable user entry. Angle brackets indicate that you replace these words and characters

with appropriate entries to make entries in the system.

EXAMPLE Keys on the keyboard, for example, F2 or ENTER .


Document History

CUSTOMER


Document History

Version Date Change

1.0 2012-11-06 First Version


Table of Contents

CUSTOMER


Table of Contents

1 Introduction .................................................................................................................................................... 6 1.1 Functions of SAP EWM Dock Appointment Scheduling ....................................................................................... 6 1.2 Architecture of SAP EWM Dock Appointment Scheduling .................................................................................. 7 1.3 Factors that Influence the Performance ................................................................................................................ 8

2 Sizing Fundamentals and Terminology ....................................................................................................... 9

3 Initial Sizing for SAP EWM Dock Appointment Scheduling..................................................................... 11 3.1 Assumptions ........................................................................................................................................................... 11 3.2 Sizing Guideline ...................................................................................................................................................... 12

4 Comments and Feedback ............................................................................................................................ 16


Introduction

CUSTOMER


1 Introduction

With SAP Dock Appointment Scheduling, you can plan and proceed with appointments for trucks or other

transportation units to arrive at the warehouse for loading or unloading. It also allows carriers chosen by the

warehouse to plan their own appointments directly in the warehouse’s system. In this way it provides work

leveling and helps to prevent bottlenecks at the warehouse where trucks arrive but there are no available doors or

staff and they must wait. It also helps the carriers to plan their transport more efficiently as they can reduce the

amount of time trucks have to wait at warehouses with this application.

1.1 Functions of SAP EWM Dock Appointment Scheduling

Dock Appointment Scheduling allows the central planning and execution of loading appointments for loading

points.

One major process is the planning of loading appointments in the graphical view. Figure 1 shows an example of

this.

Figure 1: Maintenance in Graphical View


Introduction

CUSTOMER


Figure 2: Selection Criteria for Maintenance in Graphical View

1.2 Architecture of SAP EWM Dock Appointment Scheduling

SAP Dock Appointment Scheduling is part of the SAP EWM 9.0 installation, but can be used without reference to

any EWM functions.

The following diagram provides an overview of the system landscape for SAP Dock Appointment Scheduling.

Dock Appointment Scheduling uses Web Dynpro ABAP as the UI technology. In the case of Error! Reference

source not found. Dock Appointment Scheduling also uses Microsoft Silverlight.

Note

The following sizing guide focuses on Dock Appointment Scheduling only. As Dock Appointment Scheduling is

part of EWM, and EWM itself contains a SAP NetWeaver stack, you must also consider the sizing of these

components. This guide only contains the additional sizing for Dock Appointment Scheduling. This has especially

to be considered as the Dock Appointment Scheduling application itself only requires a small database size, but

for installation of EWM, and so also SAP NetWeaver, further resources are required.


Introduction

CUSTOMER


1.3 Factors that Influence the Performance

For Dock Appointment Scheduling, some of the factors that influence the performance include the number of

loading appointments for a day, the number of loading appointments general, the number of appointments to be

displayed, the number of active users in the system, and the number of loading appointments that are created or

changed in a certain time period (for example, an hour).


Sizing Fundamentals and Terminology

CUSTOMER


2 Sizing Fundamentals and Terminology

SAP provides general sizing information on the SAP Service Marketplace. For the purpose of this guide, we

assume that you are familiar with sizing fundamentals. You can find more information at service.sap.com/sizing

→ Sizing Guidelines → General Sizing Procedures.

This section explains the most important sizing terms, as these terms are used extensively in this document.

Sizing

Sizing means determining the hardware requirements of an SAP application, such as the network bandwidth,

physical memory, CPU processing power, and I/O capacity. The size of the hardware and database is influenced

by both business aspects and technological aspects. This means that the number of users using the various

application components and the data load they put on the server must be taken into account.

Benchmarking

Sizing information can be determined using SAP Standard Application Benchmarks and scalability tests

(www.sap.com/benchmark). Released for technology partners, benchmarks provide basic sizing

recommendations to customers by placing a substantial load upon a system during the testing of new hardware,

system software components, and relational database management systems (RDBMS). All performance data

relevant to the system, user, and business applications are monitored during a benchmark run and can be used to

compare platforms.

SAPS

The SAP Application Performance Standard (SAPS) is a hardware-independent unit that describes the

performance of a system configuration in the SAP environment. It is derived from the Sales and Distribution (SD)

Benchmark, where 100 SAPS is defined as the computing power to handle 2,000 fully business processed order

line items per hour. (For more information about SAPS, see www.sap.com/benchmark → Measuring in SAPS).

Initial Sizing

Initial sizing refers to the sizing approach that provides statements about platform-independent requirements of

the hardware resources necessary for representative, standard delivery SAP applications. The initial sizing

guidelines assume optimal system parameter settings, standard business scenarios, and so on.


http://www.sap.com/benchmark

http://www.sap.com/benchmark


Sizing Fundamentals and Terminology

CUSTOMER


Expert Sizing

This term refers to a sizing exercise where customer-specific data is being analyzed and used to put more detail

on the sizing result. The main objective is to determine the resource consumption of customized content and

applications (not SAP standard delivery) by comprehensive measurements. For more information, see

service.sap.com/sizing → Sizing Guidelines → General Sizing Procedures → Expert Sizing.

Configuration and System Landscaping

Hardware resource and optimal system configuration greatly depend on the requirements of the customer-

specific project. This includes the implementation of distribution, security, and high availability solutions by

different approaches using various third-party tools. In the case of high availability through redundant resources,

for example, the final resource requirements must be adjusted accordingly.

There are some “best practices” which may be valid for a specific combination of operating system and database.

To provide guidance, SAP created the NetWeaver configuration guides (service.sap.com/instguides → SAP

NetWeaver).


http://service.sap.com/instguides


Initial Sizing for SAP EWM Dock Appointment Scheduling

CUSTOMER


3 Initial Sizing for SAP EWM Dock Appointment Scheduling

3.1 Assumptions

Regarding sizing, this guide focuses on the process of an internal planner who uses the UI as described in Figure 1.

It is assumed that only a small number of users do the planning, so that this number is relatively stable. It is also

assumed that most of the planning is done within a certain small time period, for example an hour.

The varying factor is the number of loading appointments that are used and must be created or processed in a

certain time range.

Therefore, the sizing focuses on the following process:

A Dock Appointment Scheduling planner uses the application Maintain Appointments in Graphical View.

The planner displays the loading appointments for a specific loading point that are in the working range.

Here the influencing factors are as follows:

o The number of loading appointments for the selected loading point that are within the working range, for

example, 7 days.

This influences how much data must be read from the database and how high the memory consumption

is. It also influences the runtime as all data that is read from the database must also be processed.

o The number of loading appointments for the selected loading point that are displayed in the planning

table, for example, if the user decides to display 1 or 3 days.

The planner creates new loading appointments.

The planner saves the changes.

For execution, a Dock Appointment Scheduling specialist uses application Maintain Appointments in

Graphical View. Here it is assumed that this is usually spread over the complete day and not (as, for example,

with the planner) done within a certain small time period.

The specialist displays the loading appointments for a specific loading point for the current day that are in the

working range.

Here the influencing factors are:

o The number of loading appointments for the selected loading point that are within the working range (for

example 7 days, but for execution usually a smaller number of days is sufficient).

This influences how much data must be read from the database and how high the memory consumption

is. It also influences the runtime as all data that is read from the database must also be processed.

o The number of loading appointments for the selected loading point that are displayed in the planning

table, for example, if the user decides to display 1 or 3 days.

The specialist changes the execution status of existing loading appointments, for example, changes the

status to Arrived at Checkpoint.

The specialist saves the changes.



CUSTOMER


Assumptions on Data Volumes

For the above scenario, the following assumptions are used:

One loading point has opening hours from 07:00 to 11:30 and from 12:30 to17:00

The chosen slot length for the loading point is 30 minutes

There are multiple loading points in the system and loading appointments already exist for other loading

points.

The number of loading appointments for one slot depends on the size category, so small, medium or large.

Obsolete and old loading appointments are deleted on a regular basis.

The sizing is done for one loading point. If multiple loading points are used, you must consider this. Also, the sizing

describes one user for Dock Appointment Scheduling planning and one person for execution of Dock Appointment

Scheduling in the system, who may work at the same time or at times independent of each other. If more users

work in the system, you must consider this accordingly.

3.2 Sizing Guideline

The following are definitions of some important factors that influence the sizing and memory/runtime

consumption.

N_APP_UI:

Number of appointments used in the UI. This number has an effect on the memory consumption of a single user

process and also on the runtime for the application.

N_APP_LP:

Number of loading appointments for a loading point in the system. This number is an indicator for the database

usage for Dock Appointment Scheduling.

To calculate these key figures, the following numbers are required:

N_CAP:

Capacity of a loading point, which means how many loading appointments are created on average for one time

slot.

N_WW:

Workdays in a 7 day week, for example, in a week, Saturday and Sunday are non-working days, so this would be 5.

It is assumed that there are 7 weekdays.

N_SLOT:

Number of time slots in a day with available capacity. In the above example, where the opening hours are 07:00-

11:30 and 12:30-17:00 with 30 minute slots, this would be 9 + 10 = 19 Slots.

(A time slot is an object that Dock Appointment Scheduling uses for planning. It has a time range with a starting

time and finishing time and information about whether capacity is available at this time or not.)

N_RANGE:

Number of days in the working range (Figure 2 shows this selection criteria in the selection screen, while Figure 1

shows how it looks in the UI). This factor influences the performance and runtime of the graphical view as it

influences how many loading appointments are read and processed from the database.



CUSTOMER


N_DAY:

Number of days that are displayed in the UI (Figure 2 shows this selection criteria in the selection screen, while

Figure 1 shows how it looks in the UI). It has an effect on the runtime as it influences how many appointments are

displayed in the UI. Nevertheless, it has a less important role then N_RANGE.

N_WDEL:

Number of weeks for which loading appointments are kept before they are deleted

N_APP_CHG_H:

Number of appointments that are created or changed in one hour using the UI for graphical maintenance of

loading appointments (Figure 1). This is one important key figure, as it has the biggest influence on the number of

SAPS that are required.

This can then be used to do the following calculations:

N_APP_UI = N_CAP * N_SLOT * N_RANGE * N_WW / 7 (number of days per week)

N_APP_LP = N_CAP * N_SLOT * N_WW * N_WDEL

Examples

The average capacity is 10, meaning that in the same time slot, 10 loading appointments can be

created/handled. If the available capacity changes during the day, you need to take an average.

The planner has a working range of 7 days

N_APP_UI = 10 * 19 * 7 * 5 / 7 = 1862 loading appointments

Assuming that loading appointments are kept for 52 weeks (one year) before they are deleted

N_APP_LP = 10 * 19 * 5 * 52 = 49400 loading appointments

Typically, systems can be classified as small, medium, and large. The numbers used in the classifications are only

used as examples. In the examples, mainly the number of loading appointments that have to be created varies. If

other factors change in your scenario, for example, more users or more loading points, you must consider this

accordingly. The following also describes how this influences the sizing.

Small

o In this scenario, half hour slots are used. 9 slots exist for each day where capacity is available (for

example, only opened in the morning). Average capacity of a loading point is 5.

o The loading point has 45 loading appointments a day. This means 45 loading appointments are created

and also confirmed during a day.

o There are 5 working days in a 7-day week

o The user works with the maintenance of appointments in graphical view. He or she uses a working range

of 7 days and always displays 3 days at once.

o In one hour, on average 45 appointments are created or changed (executed). It is assumed that planning

and execution of the appointments are not done at the same time. If they are done at the same time, the

number of created/changed appointments in an hour has to be adjusted, which has then an influence on

the calculated SAPS.

So in this example N_APP_CHG_H = 45.

o Loading appointments are kept for 52 weeks before they are deleted (retention period).

o Slots are created for 40 weeks in advance and are deleted on a regular basis.



CUSTOMER


Medium

o In this scenario, half hour slots are used. 12 slots exist for each day where capacity is available. The

average capacity of a loading point is 10.

o The loading point has 120 loading appointments a day. This means 120 loading appointments are created

and also confirmed during a day.

o There are 5 work days in a 7-day week



o In one hour, on average 120 appointments are created or changed (executed). It is assumed that planning

and execution of the appointments are not done at the same time. If they are done at the same time, the

number of created/changed appointments in an hour has to be adjusted, which has then an influence on

the calculated SAPS.




Large

o In this scenario, half hour slots are used. 19 Slots exist for each day where capacity is available. The

average capacity of a loading point is 20.

o The loading point has 380 loading appointments a day. This means 380 loading appointments are

created and also confirmed during a day.

o There are 5 work days in a 7-day week



o In one hour, on average 380 appointments are created or changed (executed). It is assumed that

planning and execution of the appointments are not done at the same time. If they are done at the same

time, the number of created/changed appointments in an hour has to be adjusted which has then an

influence on the calculated SAPS.




CPU and Memory Sizing

System Category and Hardware

Requirements System Category

CPU in SAPS Memory in MB

Small 126 20

Medium 340 33

Large 1071 73

As mentioned before, N_APP_CHG_H has the biggest influence on the required SAPS.



CUSTOMER


This number can depend on the number of users who are working with Dock Appointment Scheduling, but it can

also be independent. It depends how many users create or change loading appointments at the same time (in this

example in one hour).

Example:

There is one user who creates 120 loading appointments in one hour. This will require 340 SAPS.

If two users both create 120loading appointments, but they do this at different times, then N_APP_CHG_H is

still 120.

However, if they both create the loading appointments in the same hour, then N_APP_CHG_H is 240 and the

number of SAPS doubles to 680.

If one user creates 120 loading appointments, but instead of creating them in one hour, it has to be done in

half an hour, then the number of SAPS also doubles to 680.

So in general, you need to determine how many loading appointments are created or changed (for example,

status change like check in) at a peak time in a specific time period (here one hour). Based on this, you can

calculate the required SAPS.

Note that the SAPS calculated above are done based on the settings in the small, medium, and large sample

scenarios. As mentioned, the working range and number of days that are displayed in the UI have an

influencing factor. So if more or fewer days are selected, this can have an effect on the number of SAPS.

Memory consumption:

The above examples are for scenarios where one user works in the UI with the corresponding scenario (small,

medium, or large). If more users are working at the same time, the memory consumption has to be multiplied with

the number of users that work at the same time in the UI, as described in Error! Reference source not found..

Disk Sizing

The following sizing guidelines for sizing the disk are recommended. As mentioned, this assumes that one loading

point is used and old and obsolete loading appointments are deleted on a regular basis. Also remember that these

figures are only for Dock Appointment Scheduling. Additional disk size is required for the underlying system stack

(EWM, NetWeaver, and so on, which have separate sizing guides).

System Category and Hardware

Requirements System Category

Loading Appointments in

the System

Slots in the System Minimal Disk Size in

MB

Small 11,700 13,440 9

Medium 31,200 13,440 18

Large 98,800 13,440 53

Note: Here, the number of slots is the total number of slots, including slots where no capacity is available. This

differs from N_SLOT, which is the number of slots with available capacity.

The overall number of slots depends on the number of weeks for which slots are generated and the slot duration.

So if slot length is 30 minutes for a 7 day week and the generation is done for 40 weeks, it is 24 / 30 * 60 * 7 *40 =

13440 slots


Comments and Feedback

CUSTOMER


4 Comments and Feedback

This is a first release of EWM 9.0 Dock Appointment Scheduling Sizing Guide. To improve this guide, we

appreciate your feedback and comments.

For feedback, open an OSS ticket with component SCM-EWM-DAS and with low priority. In the Short Text field,

enter “Feedback for dock appointment sizing guide”. Request that the ticket is forwarded to development support

www.sap.com/contactsap

Material Number

© 2012 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, Excel, Outlook, and PowerPoint are registered

trademarks of Microsoft Corporation.

IBM, DB2, DB2 Universal Database, System ads, System i5, System

p, System p5, System x, System z, System z10, System z9, z10, z9,

iSeries, pSeries, xSeries, zSeries, eServer, z/VM, z/OS, i5/OS,

S/390, OS/390, OS/400, AS/400, S/390 Parallel Enterprise

Server, PowerVM, Power Architecture, POWER6+, POWER6,

POWER5+, POWER5, POWER, OpenPower, PowerPC, BatchPipes,

BladeCenter, System Storage, GPFS, HACMP, RETAIN, DB2

Connect, RACF, Redbooks, OS/2, Parallel Sysplex, MVS/ESA, AIX,

Intelligent Miner, WebSphere, Netfinity, Tivoli and Informix are

trademarks or registered trademarks of IBM Corporation.

Linux is the registered trademark of Linus Torvalds in the U.S. and

other countries.

Adobe, the Adobe logo, Acrobat, PostScript, and Reader are either

trademarks or registered trademarks of Adobe Systems

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

SAP, R/3, xApps, xApp, SAP NetWeaver, Duet, PartnerEdge,

ByDesign, SAP Business ByDesign, 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.

Documents

Sapewm_das Sizing - Basis