sup 2.0 sizing guide wp

8/13/2019 SUP 2.0 Sizing Guide WP

http://slidepdf.com/reader/full/sup-20-sizing-guide-wp 1/12

WHITE PAPER

www.sybase.com

Sybase® Unwired Platform 2.0Sizing Guide – Workflow and Cache Synchronization



TABLE OF CONTENTS

1 Introduction

1 Functions of Sybase Unwired Platform

1 Mobile Workflow Enablement

1 Architecture of Mobile Workflow Deployment

2 Mobile Synchronization Applications

2 Cache Synchronization Deployment

3 Cache Synchronization Architecture

4 Sizing Fundamentals and Terminology

5 Initial Sizing for Workflow Applications

5 Assumptions

6 Business Scenario

6 Data Object Structure

6 Key Considerations for the Sizing Analysis

6 Initial Sizing for Cache Applications 6 Assumptions

6 Business Scenario

6 Data Object Structure

7 Key Considerations for the Sizing Analysis

9 Appendix

9 Deployment Options

10 Physical I/O Subsystems

10 Network Latency

10 Feedback



1

INTRODUCTION

This document is designed for service providers and enterprises that plan to deploy Sybase Unwired Platform

(SUP) and need to understand the different technology options and sizing considerations. Prior to deploying SUP,

you will need to make several technology decisions based on the requirements of your mobile application(s). These

technologies impact downstream sizing estimates for each component of the system. This paper will help define the

questions and answers related to technologies and sizing that everyone should ask prior to deploying SUP. Making

these assessments and decisions early in the process is essential in ensuring a successful project rollout.

Sizing guidance for the SUP messaging and replication nodes and associated data tier nodes are supplied

separately for the case of deploying the data tier on its own hardware (see the white paper “Sizing Fundamentals and

Terminology” for more information on the deployment options). The SAP® sizing numbers for the SUP server and data

tier must be taken together to account for the entire solution.

The memory requirements given in the sizing guidance is the suggested memory for the respective tier including

the operating system. If the solution is deployed on a single host, the memory requirements for both nodes should

be combined. The minimum memory requirement for any one host is 8 GB. When the nodes are deployed separately

and the sizing for a tier is shown to be below the minimum, use the minimum as the guidance for each node. For

example, if a small deployment is planned and the SUP node requires 4 GB and the data tier 4 GB, a single host install

would require 8 GB and a two host install would require 8 GB on the SUP node and 8 GB on the data tier.

FUNCTIONS OF SYBASE UN WIRED PLATFORM

Individuals and businesses develop mobile applications for specific user needs ranging from teams of service

workers who use devices for industry-specific applications to consultants who track time and expenses on a mobile

device for synchronization to a back-office system at a later time. SUP provides capabilities that support these mobile

scenarios as well as cross-industry applications, such as customer relationship management, human resources, supply

chain management, business intelligence, and product lifecycle management, and industry-specific applications

tailored for the service provider, chemical/pharmaceutical, and utilities industries.

SUP supports two major types of mobile application deployment configurations:

• Mobile workflow enablement

• Mobile synchronization applications

– Custom-designed applications using synchronization and caching in a stand-alone mode

– Mobile applications using synchronization with the Data Orchestration Engine (DOE)

Mobile Workflow Enablement

SUP provides Mobile Workflow technologies that enable mobile device users to be workflow participants. SUP provides

the last-mile connectivity for workflow applications, allowing the mobile user to start and respond to back-end

enterprise requests within a generic framework. Mobile Workflow utilizes the concept of a container on the device. A

container is a native application with a Web browser plug-in and built-in SDK for connectivity, guaranteed messaging,

caching and security. Mobile Workflow relies on messaging between the server and a container on the devices that

invokes either on-line operations to the back-end or cached Mobile Business Object (MBO) data in the SUP server.

Architecture of Mobile Workflow Deployment

In the workflow architecture, changes to back-end workflows (generally sent via data change notifications (DCN))

result in the creation of messages that are sent to the messaging server for dispatch. Spooled messages that meet

a specified set of matching criteria are placed in a queue for processing by plugins to the messaging transformer

component, which augment the message with application-specific data or processing instructions.



2

Figure 1. Mobile Workflow Architecture

Once transformed, the augmented message may be queued for transmission to the mobile device when the device

next connects to the SUP server, or the message may be sent to the device directly. These messages are stored in the

device’s in-box where they await the us er’s actions. When a user reviews an in-box message, the appropriate form is

loaded by the workflow application, and the user may perform application-provided actions (such as approving an

expense request).

The device user’s responses are sent back to the messaging s erver. Depending on the application, the response

action may be queued, or may result in a synchronous action; this behavior is different from outbound message

transformations, which are always queued. Regardless of whether the response action is queued or performed

immediately, the application communicates with the SUP server to perform the action’s unit of work.

Mobile Synchronization Applications

Synchronization applications provide transactional consistency between the mobile device, the middleware and

the back-end system. These custom applications are designed and built to suit specific business scenarios from

the ground up or could start with a bespoke application and adapted with a large degree of customization. Several

application requirements must be considered to determine the best set of SUP technologies to employ with the

associated sizing. Application designs that fail to take these criteria into account may have challenges meeting their

key performance indicators (KPI).

Cache Synchronization Deployment

Cache synchronization allows mapping mobile data and service objects to SAP Remote Function Calls (RFCs) using

Java Connector (JCO) and to other non-SAP data sources such as databases and Web services. When SUP is used in

a stand-alone manner for data synchronization it utilizes an efficient bulk transfer and data insertion technologybetween the middleware cache and the device database known as replication-based synchronization (RBS).

2

Messaging Service SUP Data Service

Message Processor

Device Messaging

Device Inbox

Application(s)

EIS

ConsolidatedDatabase

Mobile Device Message Interceptor DCN Servlet

DCN ServletTransformerQueue

Transformer

Response Processor

ResponseQueue

Responder

DB

MMS

DS

JMSHost

J M

S B r i d g e



3

In a stand-alone deployment the mobile application is designed such that the developer specifies how to load data

from the back-end into the cache and then filters and downloads cache data using device supplied parameters. The

mobile content model and the mapping to the back-end are directly integrated.

This style of coupling between device and back-end queries implies that the back-end must be able to respond to

requests from the middleware based on user supplied parameters and serve up mobile data appropriately. Normally,

some mobile-specific adaptation is required within SAP Business Application Programming Interfaces (BAPI).

Because of the direct nature of application parameter mapping and RBS protocol efficiencies, cache synchronization

deployment is ideal:

• with large payloads to devices (may be due to mostly disconnected scenarios)

• where ad hoc data downloads might be expected

• for SAP or non-SAP back-ends

Large payloads, for example, can occur in task worker (service) applications that must access large product catalogs

or where service occurs in remote locations and workers might synchronize once a day. While RBS synchronization

benefits from middleware caching, direct coupling requires the back-end to support an adaptation where mobile user

data can be determined.

Cache Synchronization Architecture

The goal of synchronization is to keep views (i.e. the state) of data consistent between multiple tiers essentially

using bi-directional synchronization. The assumption is that if data changes on one tier (e.g. the enterprise system-

of-record) that all other tiers interested in that data (mobile devices, intermediate staging areas/caches and so on) will

eventually be synchronized to have the same data/state on that system.

The SUP server keeps data synchronized between the device and the back-end by maintaining records of device

synchronization activity in its consolidated database along with any cached data that may have been retrieved from

the back-end or pushed from the device. The SUP server employs several components in the synchronization chain.

• The Relay Server is a single point of contact for devices and is a specialized reverse proxy that avoids opening

inbound ports in the firewall to the SUP server. The outbound enabler opens a bidirectional communicationchannel from inside the firewall outward to the Relay Server.

• Mobile Channel Interfaces provide a conduit for data both from and to remote devices. These conduits vary based

on their approach (synchronous, asynchronous) and quality of services (proprietary or standards based)

– The Messaging Channel serves as the abstraction to all device-side notifications (BES, APNS and others) so that

when changes to back-end data occur devices can be notified of their changes

– The Replication Channel serves as the conduit over which data is replicated between device and the mobile

middleware. This is an efficient database row replication technology.

• Mobile Middleware Services (MMS) role is to arbitrate and manage communications between device requests

from the mobile channel interfaces in the form that is suitable for transformation to a common MBO service

request and a canonical form of enterprise data.

• Data Services (DS) is the conduit to enterprise data and operations within the f irewall or hosted in the cloud.



4

Figure 2. Cache Synchronization Architecture

Once a mobile application model is designed it can be deployed to the SUP server where it operates as part of a

specialized container managed application interfacing with the MMS and DS components. Cache data and messages

are persisted in the databases in the data tier. Changes made on the device are passed to the MMS component and

replayed against the DS interfaces with the back-end. Data that changes on the back-end is replicated to the devicedatabase. The Unified Agent Service acts as a central control and monitoring facility for the server.

The SUP/DOE option is currently only available with the SAP CRM application or other custom applications

written by Sybase or SAP and is not reflected in this document. Please refer to the specific application sizing

guides for further guidance on SUP/DOE.

SIZING FUNDAMENTALS AND TERMINOLOGY

For the purpose of this guide, we assume that you are familiar with sizing fundamentals. You can find more

information at http://service.sap.com/sizing –> Sizing –> 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. The number of users using the various application components and the

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

Cluster DB

User Agent DB

AdvantageMessaging DB

MBS Client

Application(s)

Mobile Devices

SUP Data Tier(Active/Passive HA)

Public Network DMZ Private Network

UltraLite

RBS Client

UltraLite

Relay

Servers

LDAP Server

Unwired Server (Clustered)

Enterprise Information Systems

Outbound Queue

Inbound Queue

Messaging Channel Container Services

Replication Channel

Unified Agent Service

MobiLink

SybaseControl Center

JMSHost

M o b i l e M i d d l e w a r e

S e r v i c e s

D a t a S e r v i c e s

DataChange

Notification

ConnectionPools

JAAS

ConsolidatedDatabase

SAP Applications

Databases

SOAP/REST

Services

UnwiredWorkspace

L o a d B a l a n c e r

R e l a y

S e r v e r

O u t b o u n

d E n a b l e r

R e l a y S e r v e r

O u t b o u n d E n a b l e r

R e l a y S e r v e r

O u t b o u n d E n a b l e r

http://service.sap.com/sizing




5

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.

SAP Application Performance Standard

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

Expert Sizing

This term refers to a sizing exercise where customer-specific data is 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 http://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. Considerations include 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.

Some best practices may be valid for a specific combination of operating system and database. To provide guidance,

SAP created the SAP NetWeaver® configuration guides (http://service.sap.com/instguides –> SAP NetWeaver).

INITIAL SIZING FOR WORKFLOW APPLICATIONS

Assumptions

The Hybrid Workflow Container is suitable for simple, small payload scenarios. You will need to remap workflow

scenarios that exceed these characteristics to native custom applications.

Planners should determine the specific application demand on the server(s) to properly estimate the sizing for

workflow. These factors affect the sizing calculations for workflow:

• Total user population that are assigned workflows

• Rate at which workflows are executed (number of application requests per hour)

• Latency of operations executed in the middleware (on-line, cached MBOs and back-end)

• Size of the data sent between the server and the device

The combination of these factors reflects the application load on the server based on the rate of messages. When

comparing your deployment to the business scenarios presented in this paper, your deployment should be adjusted

based on variances in these factors.

http://www.sap.com/benchmark




http://service.sap.com/instguides

http://service.sap.com/instguides






6

Business Scenario

The business example for the workflow application is a simple application to approve sales orders. A back-end

process starts with a push from the back-end workflow system to SUP via a data change notification. This notification

signals the start of a mobile workflow and is sent through SUP to the specific device/user registered for this

workflow. The device responds by changing the approved field to indicate the status and an asynchronous action is

passed on to the back-end and the workflow is implicitly terminated. The total messages for this workflow scenario

are two per complete workflow — initialization and response/termination. The workflow response rate is one

workflow per hour per user.

Data Object Structure

To trigger the mobile workflow, a message must be sent form

the back-end to the SUP server and routed to the device. The single

dimensional object used in the message in this case is a simple

approval object without any further references. The payload size in

this scenario is 50Kb per workflow message.

Key Considerations for the Sizing AnalysisWithin any workflow at least two messages are involved, one from

the back-end and a response from the device. Extra on-line invocations to the mobile middleware may occur during

the workflow but are not accounted for in this sizing. Larger payloads will increase the time to move and marshal

data throughout the system (small payloads are recommended).

Table 1 Workflow Reference Sizing reflects a push f rom the back-end and a response from the device. Care should be

taken to account for on-line interactions from the device within the context of the workflow (if the application allows

for that pattern).

CATEGORY WORKFLOWSPER HOUR

SIZING

SERVER SAPS MEMORY IN GB DATA TIER SAPS DATA TIER

MEMORY IN GB

Small 1,000 500 4 350 4

Medium 5,000 2,500 4 1,750 4

Large 10,000 5,000 8 3,500 8

Very large 20,000 10,000 8 7,000 8

Table 1. Workflow Reference Sizing

The number of registered users in the system has a relatively minor impact on sizing or performance (roughly 2

percent degradation in throughput for 10,000 users as measured on the same hardware).

INITIAL SIZING FOR CACHE APPLICATIONS

Assumptions

Business Scenario

This business scenario uses a service order management application that allows customers to place service-

order requests in the back office of a s ervice company. The requests are stored in a back-end system, along with

information such as the customer’s address, contact information, details of the product to be serviced, and so on.

After the customer places a request, the appropriate field representative receives the order request.

Data Object Structure

For the sizing measurements, each order request contains one header record and ten item records. The header

record corresponds to one order request (User ID, Order type and so on), and the ten items correspond to three order

activities, two object lists and five components. So, each instance of the order data object corresponds to 11 rows in

the database.



7

The customer data in this sizing example contains one header record and three items. The header record

corresponds to customer details, and the three items correspond to three contact details. So, each instance of the

customer data object corresponds to four rows in the database.

In our scenario, order requests in the back-end system can be newly created, deleted or changed. In other terms, the

instances can be inserted, deleted or modified in the back-end database.

Data is exchanged between the client devices and the back-end in the form of messages. Each message contains

the changes in the instance, message type (insert, delete, modified) and other details. The data used in this sizing

example had the follow change characteristics during the performance runs:

• For each insert message, one header record and its ten item records were created.

• For each delete message, one header record and its ten item records were deleted.

• For each modified message, one header record and two item records were changed, namely one activity record

and one object list.

•

•

••

•

•

•

Figure 3. Synchronization Reference Model

Key Considerations for the Sizing Analysis

Two key processes influence the resource consumption in this architecture scenario. Both the data change

notification (DCN) and the synchronization are considered to be integral parts of the same scenario where a balance

of changes from the back-side is applied along with device-side changes.

1. Initial Download

This phase is considered to be an administrative roll-out phase accomplished prior to normal operation so the sizing

numbers for that phase are not reflected in this guide.

2. DCN

During this phase DCNs are sent from the back-end to the cache and the payload of the change is also sent in the

same message. As the DCN arrives in the cache the SUP server determines the difference between that change

notification and what is already in the cache and applies the differences to the cache. The sizing for this phase is

reflected in Table 3. Synchronization Cache Data Change Notification Sizing.



8

3. Client Synchronization

There are two synchronization stages where the client initiates synchronization. First uploading any changes

they have made to the sales orders and line items, and applying those changes to the back-end, and second

downloading subsequent changes. The sizing for these two stages is calculated and described separately because

the sizes are usually quite different. The processing in our disconnected scenario is calculated during two distinct

times — during the morning when back-end changes are retrieved from the server and in the evening when

devices changes are uploaded. The sizing for the download is described in Table 4 while the upload phase is

reflected in Table 5.

SUP 2.0 architecture provides for device uploads and transactions to the back-end in the same synchronization

cycle as downloads (this behavior will be changed in future releases). In this scenario no server-side notifications

are sent; all clients synchronize when the user is ready.

Because the disconnected scenario calls for DCN (night), delta download (morning), and delta upload (evening)

to occur at mutually exclusive periods of time, the higher of the sizing requirements can be used for deployment.

In a case where DCN and synchronization occur during the same period (as in a mostly connected scenario) the

sizing should account for the higher of the upload/download synchronization sizing (since upload and download are

executed as a single transaction in this version) plus the adjustment for additional concurrent DCN activity.

The following information describes the payload and number of objects associated with the payload for each

process phase. The T-Shirt sizing for DCN and the two synchronization phases follow.

PHASE TOTAL PAYLOADTRANSFER

INSERT OBJECTS DELETE OBJECTS MODIFIED OBJECTS

Initial load (Rolloutphase not reflected insizing)

31 Mb 4,400 N/A N/A

DCN (back officeprocessing)and downloadsynchronization

2.3 Mb 160 160 80

Uploadsynchronization(End of day sync)

1.4 Mb N/A N/A 200

Table 2. Stand-alone Per Device Data Characteristics

DCN metrics in Table 3 depict the total DCN activity to upload the entire delta payload to a client. The DCN actual

activity used to push the delta payload to a client is broken down into 400 distinct operations. While a single DCN

could push the entire payload it may prove to be more efficient to provide finer grained operations to improve

concurrency.

CATEGORY DCN ACTIVITYCLIENT PAYLOADS

PER HOUR

SIZING

SERVER SAPS MEMORY IN GB DATA TIER SAPS DATA TIERMEMORY

Small 300 2,500 4 3,750 4

Medium 500 4,000 8 6,250 8

Large 1,000 8,250 16 12,500 16

Very large 2,000 16,250 16 27,750 16

Table 3. Synchronization Cache Data Change Notification Sizing



9

CATEGORY DOWNLOADSYNCHRONIZATIONSPER HOUR

SIZING


Small 1,000 250 4 1,500 4

Medium 2,000 500 8 3,000 8

Large 3,000 1000 8 4,500 8

Very large 5,000 1,500 16 7,500 16

Table 4. Synchronization Cache Download Delta Synchronizations

CATEGORY UPLOADSYNCHRONIZATIONSPER HOUR

SIZING


Small 1,000 3,250 4 4,500 4

Medium 2,000 6,250 8 8,750 8

Large 3,000 9,500 8 13,000 8

Very large 5,000 16,000 16 21,750 16

Table 5. Synchronization Cache Upload Change Synchronizations

APPENDIX

Deployment Options

For small or medium-sized deployments it may make economic sense to host all of the SUP components on the

same physical hardware. When high availability is required a Microsoft cluster and some form of highly available

storage tier can be employed to allow for failover. This configuration works as an active/passive cluster where only one

of the nodes is active at one time. Both nodes should be identically sized to take over the entire work stream.

Figure 4. Active/Passive Cluster

Storage TierNAS or SAN

DMZWeb App Zone

Default DB

Messaging DB

Tx Log

Monitoring DB

3 U

3 U

3 U

3 U

12 U

SUP Node 1

Active

Passive

MS Cluster

RSOE

....

SUP Node 2

RSOE

....

Relay ServerFarm

(HA)

LoadBalancers



www.sybase.com

Sybase, Inc.

Worldwide Headquarters

One Sybase Drive

Dublin, CA 94568-7902

U.S.A

1 800 8 sybase

Copyright © 2011 Sybase, Inc. All rights reserved. Unpublished rights reserved under U.S. copyright laws. Sybase andthe Sybase logo are trademarks of Sybase, Inc. or its subsidiaries. ® indicates registration in the United States ofAmerica. SAP, the SAP logo and SAP NetWeaver are the trademarks or registered trademarks of SAP AG in Germanyand in several other countries. All other trademarks are the property of their respective owners. 08/11

In larger deployments some advantage can be gained by breaking out the data tier from the SUP tier and sizing

each separately. This configuration may allow for sizing each tier independently, which makes the most of smaller,

less expensive, hardware on the tier. In these more demanding cases it is necessary to vertically scale the database

tier (use more powerful hardware) and horizontally scale (add more hardware) in the tier. Normally two active

nodes provide sufficient processing power to fully meet the database physical I/O limits on the data tier. In hosted

environments or larger deployments the SUP tier can be virtualized taking advantage of economies of s cale. Failures

on a single node can be managed by spreading the load across more than one other virtualized server so that each

node is not required to be completely capable of assuming the full cluster load.

Figure 5. Active/Active Cluster

Physical I/O Subsystems

All the current SUP application types are heavily reliant on one or more forms of persistence in the middle tier. This fact

implies that the scalability of the server is a direct reflection of the properties of the physical storage infrastructure.

Two main physical data storage systems (the Advantage Database Service for messaging and the Consolidated

Database) are on SUP and one (Consolidated Data Store) in DOE. To increase the throughput on the storage subsystems

separate all three physical I/O contenders and their associate logs onto separate disk spindles or RAID systems.

Faster storage (i.e., SSD) can dramatically improve the performance of the SUP cluster beyond the quoted metrics

(potentially by as much as 50 percent or more). If SSDs are used it is important to use a compatible operating system

that provides SSD TRIM support, which as of the date of this publication is Windows Server 2008 R2. Follow vendor

recommendations for disabling disk defragmentation and other forms of dis k caching for optimal SSD performance

and life.

Network Latency

All the reference numbers are for LAN-based device communication. 3G or Wi-Fi networks have different response

times and should be taken into account when considering individual download speeds. Application-specific testing is

required to adequately test performance.

FEEDBACK

Send any feedback on this document to [email protected].

Internal Network DMZWeb App Zone(SUP Cluster)

SUP Node 1

Primary Server

Monitor Server

Secondary Server

RSOE

....

SUP Node 2

RSOE

....

Relay ServerFarm(HA)

Load

Balancers

SUP Data TierCDB/Messaging Cluster

mailto:[email protected]




sup 2.0 sizing guide wp

Documents