Sybase Unwired Platform 2.1 Sizing Guide

Transcription

1 white paper Sybase Unwired Platform 2.1 Sizing Guide OData Mobile Workflow Hybrid Web Container Native Object API

2 Table of Contents 1 Functions of Sybase Unwired Platform 1 Online Data Proxy 2 Mobile Messaging Applications 3 Mobile Synchronization Applications 3 Cache Synchronization Deployment 5 Sizing Fundamentals and Terminology 5 Sizing 5 Benchmarking 5 SAP Application Performance Standard 5 Initial Sizing 5 Expert Sizing 5 Configuration and System Landscaping 6 Initial Sizing for OData Applications 6 Assumptions 7 Initial Sizing for Messaging Applications 7 Assumptions 9 Initial Sizing for Cache Applications 9 Assumptions 12 Appendix 12 Deployment Options 13 Physical I/O Subsystems 13 Network Latency 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 applications. These technologies impact downstream sizing estimates for each component of the system. This paper helps 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 if you are deploying the data tier on its own hardware (see the white paper Sizing Fundamentals and Terminology for more information on the deployment options). To account for the entire solution, consider both the SAP sizing numbers for the Unwired Server and the data tier. The memory requirements provided in this paper are the suggested memory amounts for each respective tier, including the operating system. If you deploy the solution on a single host, combine the memory requirements for both nodes. The Unwired Server minimum memory requirement for any one host is 8GB. The memory requirements for different phases (for example, sync upload and sync download) are not cumulative. Likewise, when combining technologies (workflow and synchronization), use the higher memory value or the host minimum if that is higher. When you deploy the SUP and data tier nodes 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 you are planning a small deployment, and the SUP node requires 4GB and the data tier 4GB, a single-host installation requires 8GB and a two-host install requires 8GB on the SUP node and 8GB on the data tier.

3 Functions of Sybase Unwired Platform Individuals and businesses develop mobile applications for specific user needs, which range from teams of service workers using 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, product life cycle management, and industry-specific applications tailored for the service provider, chemical/pharmaceutical, and utilities industries. SUP supports three major types of mobile application configurations: OData Messaging-based applications Mobile Workflow or Hybrid Web Container Mobile synchronization applications (using Object API) Custom-designed applications using synchronization and caching in a standalone mode Mobile applications using synchronization with the Data Orchestration Engine (DOE) Online Data Proxy The SAP NetWeaver Gateway exposes OData with extensions specific to SAP. SUP incorporates facilities for publishing these service documents and allowing users to interact with the Gateway runtime, which then interacts with the SAP application suite via RFC. The Unwired Server provides administrative facilities for discovering OData service documents and allowing devices to communicate with those enterprise services. Architecture of the Online Data Proxy When device applications communicate through the Unwired Server to the NetWeaver Gateway, they do so through a synchronous message interface (providing their own retry capability for interrupted communications). The synchronous interface avoids message queues on the device, in the middleware, and associated database disk I/O, and may allow horizontal scaling of the middleware. Using synchronous messaging where a seamless online and offline experience is required places additional burden on the application developer to identify and compensate for interrupted connections. Public Network DMZ Private Network Unwired Server Mobile Devices OData Application(s) OData SDK HTTP Messaging Proxy Security/Config Logging Messaging Channel Load Balancer Relay Servers Native Push Services Relay Server Outbound Enabler Messaging Channel Async Channel Outbound Queue Inbound Queue Sync Channel Unified Agent Service JMS Host IIOPS Data Change Notification Mobile Middleware Services HTTP Proxy Handler HTTP Callback Router Data Services Domain Logging Container Services JAAS Connection Pools LDAP Server Single Sign on URL SUP Data Stores Cache Database Cluster DB Monitor DB Sybase Control Center SAP Applications OData Service Documents User Agent DB Figure 1. Onlind Data Proxy architecture 1

4 Device users may publish their logical device address to the Gateway, allowing data change notifications (DCNs) to be forwarded from the Gateway to SUP and onto the device. These notifications are guaranteed to be delivered to the device. Device notifications may be registered over native device platform-specific channels, such as APNS or BES. Mobile Messaging Applications SUP provides mobile messaging technologies that enable mobile device users to interact with an application in the Hybrid Web Container (HWC). The container is a native application with a Web browser plug-in and built-in SDK for connectivity, guaranteed messaging, caching, and security. Mobile workflow and the container rely on messaging between the Unwired Server and a container on the devices that invoke either online operations to the back end or cached mobile business object (MBO) data in the Unwired Server. Do not confuse mobile messaging with messagebased synchronization (MBS), where the latter adds synchronization services to the base messaging protocol 1. Architecture of Mobile Messaging Deployment In the messaging architecture, changes to back-end data (generally sent via DCNs) 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 plug-ins to the messaging transformer component, which augment the message with application-specific data or processing instructions. Messaging Service SUP Data Service Mobile Device Device Inbox Device Messaging Message Processor Message Interceptor Transformer Transformer Queue JMS Bridge JMS Host DCN Servlet DCN Servlet MMS EIS DB Response Processor Application(s) Responder Response Queue DS Cache Database Figure 2. Mobile messaging architecture workflow/hybrid web container Once transformed, the augmented message may be queued for transmission to the mobile device when the device next connects to the Unwired 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 user s actions. When a user reviews an in-box message, the appropriate form is loaded by the device 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 server. 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 Unwired Server to perform the action s unit of work. 1 MBS is used for ios cache synchronization and for SUP/DOE. 2

5 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 or may start with a bespoke application and be adapted with a large degree of customization. There are several application requirements to consider when determining 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. SUP used in a standalone manner for data synchronization utilizes an efficient bulk transfer and data insertion technology between the middleware cache and the device database, known as replication-based synchronization (RBS). In a standalone deployment, the mobile application is designed such that the developer specifies how to load data from the back end into the cache, 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 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 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 (that is, the state) of data consistent between multiple tiers using bidirectional synchronization. The assumption is that if data changes on one tier (for example, the enterprise systemof-record), all other tiers interested in that data (mobile devices, intermediate staging areas/caches and so on) are eventually synchronized to have the same data/state on that system. The Unwired 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 Unwired 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 Unwired Server. The outbound enabler opens a bidirectional communication channel 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. 3

6 The role of Mobile Middleware Services (MMS) is to arbitrate and manage communications between device requests from the mobile channel interfaces in a 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 firewall or hosted in the cloud. Public Network DMZ Private Network Unwired Server (Clustered) Mobile Devices Application(s) MBS Client UltraLite RBS Client UltraLite Load Balancer Relay Servers Message Sync Web Messaging Channel Outbound Queue Inbound Queue Replication Channel MobiLink Unified Agent Service Sybase Control Center JMS Host Mobile Middleware Services Data Change Notification Data Services JAAS Connection Pools LDAP Server SUP Data Tier (Active/Passive HA) Cache Database Cluster DB Unwired Workspace Figure 3. Cache synchronization architecture Enterprise Information Systems SAP Applications Databases SOAP/ REST Services User Agent DB Advantage Messaging DB Once you have designed a mobile application model, deploy it to the Unwired 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 device database. The Unified Agent Service acts as a central control and monitoring facility for the server. Note: The SUP/DOE option is currently available only with the SAP CRM application or other custom applications written by Sybase or SAP and is not reflected in this document. See the specific application sizing guides for further guidance on SUP/DOE. 4

7 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 > Sizing > General Sizing Procedures. This section explains important sizing terms that 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. Hardware and database size is influenced by both business aspects and technological aspects. You must take into account the number of users using the various application components and the data load they put on the server. Benchmarking Determine sizing information using SAP Standard Application Benchmarks and scalability tests, both are available from Released for technology partners, benchmarks provide basic sizing recommendations by placing a substantial load on a system during the testing of new hardware, system software components, and relational database management systems (RDBMSs). 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. See > 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 Expert sizing 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. See > 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, 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 NetWeaver configuration guides, available from > SAP NetWeaver. 5

8 Initial Sizing for OData Applications Assumptions The OData service is suitable for small payload scenarios. You must remap scenarios that exceed these characteristics to other more robust transfer protocols. To properly estimate sizing for OData, planners should determine the specific application demand on servers. These factors affect the sizing calculations: Total registered user population Rate at which requests are executed 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, adjust your deployment calculations based on variances in these factors. Business Scenario The business example for the OData application is a lookup application for sales orders. The device starts a pattern of request/response by initiating a lookup on the server for a set of sales orders. The server responds to this request by sending a collection of sales orders that contains two sales orders. Data Object Structure The sales order field number and size is not important in the context of the Unwired Server sizing because the server is acting as a proxy without inspecting or manipulating the payload. The sales order in the reference scenario returns entities with approximately 30 fields. The payload size in the reference scenario amounts to two sales orders, which is equivalent to a payload size of 8KB, including XML tags and attributes. Key Considerations for Sizing Analysis The request/response metrics for the reference sizing scenario of 8KB messages is listed below. OData request/ response sizing does not make a distinction between the Unwired Server node and the data tier because the request/ response does not use data for storing messages. Request/Response per Sizing Category Hour Server SAPS Memory in GB Small 50, Medium 100,000 1,000 4 Large 200,000 2,000 6 Very large 400,000 4,000 8 Table 1. Request/Response Metrics for 8KB Messages 6

9 The size of the payload has a material impact on the throughput of the proxy. You can see this effect in the following table, where the reference scenario is 8KB, and the processing power is held constant. Adjustments in the request/response rate should be made relative to the expected change in throughput for various sizes. For example, if we double the payload size to 16KB, we decrease throughput by about 11%; for example, for a small size payload, from 50,000/hour to 44,500/hour. Request/Response Payload KB Relative Throughput from Reference 8KB 16 89% 32 73% 64 56% % % % Table 2. OData payload size effect If an OData scenario requires notifications, then that sizing must be applied in addition to the request/response calculations. The processing cost for notifications is much higher than the cost of requests/responses because notifications are persisted in queues to guarantee delivery to the device. Sizing Category Notifications per Hour Server SAPS Memory in GB Data Tier SAPS Data Tier Memory in GB Small 5,000 1, Medium 10,000 2, ,750 4 Large 20,000 5, ,500 8 Very large 40,000 10, ,000 8 Table 3. OData proxy notification The number of registered users in the system has a relatively minor impact on sizing or performance (roughly 2% degradation in throughput for 10,000 users). Initial Sizing for Messaging Applications Assumptions The Hybrid Workflow Container is suitable for simple, small payload scenarios. You must remap scenarios that exceed these characteristics to native custom applications. To properly estimate the sizing for messaging applications, planners should determine the specific application demand on servers. These factors affect the sizing calculations: Total user population Rate at which workflows are executed (number of application requests per hour) Size of the data sent between the server and the device 7

10 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, adjust your deployment calculations based on variances in these factors. Business Scenario The business example for the messaging application is sales orders approval. A back-end process starts with a push from the back-end workflow system to SUP via a DCN, which 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; the workflow implicitly terminates. The total number of messages for this messaging scenario is two per complete workflow initialization and response/termination. The response rate is one workflow per hour per user. Data Object Structure To trigger the mobile workflow, a message must be sent from the back end to the Unwired 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 and the MBO fields are pictured below. Key Considerations for the Sizing Analysis Within any workflow at least two messages are involved, one from the back end, and a response from the device. Extra online invocations to the mobile middleware may occur during the workflow but are not accounted for in this sizing. Larger payloads increase the time to move and marshal data throughout the system; Sybase recommends small payloads. Table 4. Workflow Reference Sizing reflects a push from the back end and a response from the device. Remember to account for online interactions from the device within the context of the workflow (if the application allows for that pattern). Sizing Category DCN/Response per hour Server SAPS Memory in GB Data Tier SAPS Data Tier Memory in GB Small 1, Medium 5,000 2, ,750 4 Large 10,000 5, ,500 8 Very large 20,000 10, ,000 8 Table 4. Workflow reference sizing The number of registered users in the system has a relatively minor impact on sizing or performance (roughly 2% degradation in throughput for 10,000 users as measured on the same hardware). 8

11 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 to the back office of a service 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 1 header record and 10 item records. The header record corresponds to one order request (user ID, order type and so on), and the 10 items correspond to 3 order activities, 2 object lists and 5 components. So each instance of the order data object corresponds to 11 rows in the database. The customer data in this sizing example contains 1 header record and 3 items. The header record corresponds to customer details, and the 3 items correspond to 3 contact details. So each instance of the customer data object corresponds to 4 rows in the database. In our scenario, 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 in this example had the following change characteristics during the performance runs: For each insert message, 1 header record and all its 10 item records were created. For each delete message, 1 header record and all its 10 item records were deleted. For each modified message, 1 header record and 2 item records were changed, namely 1 activity record and 1 object list. Figure 4. Synchronization reference model 9

12 Key Considerations for the Sizing Analysis Two key processes influence the resource consumption in this scenario. Both the DCN and the synchronization (download and delta synchronization) are considered to be integral parts of the same scenario where a balance of changes from the back end is applied along with device-side changes. 1. Initial download This phase is considered to be an administrative rollout 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 Unwired Server determines the difference between that change notification and what is already in the cache and applies any differences to the cache. This sizing for this phase is reflected in Table 6. Synchronization Cache Data Change Notification Sizing. 3. Delta Synchronization There are two synchronization phases where the client initiates synchronization by first uploading any changes they have made to the sales orders and line items, applying those changes to the back end, and downloading subsequent changes. The sizing for these two phases is calculated and described separately because the sizes may be, and usually are, 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 SUP 2.1 architecture provides for device uploads and transactions to the back end in the same synchronization cycle as downloads (this behavior will change in future releases). In this scenario, no server-side notifications are sent; all clients synchronize when the user is ready. The sizing for the download is described in Table 7, while the upload phase is reflected in Table 8. Because the disconnected scenario calls for DCN (night), delta download (morning), and delta upload (evening) to occur at mutually exclusive periods of time, use the greater of the sizing requirements 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 information in Table 5 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 Payload Transfer Insert Objects Delete Objects Modified Objects Initial load (Rollout phase not reflected in sizing) 31MB 4,400 N/A N/A DCN (back office processing) and download 2.3MB synchronization Upload synchronization from device (End of day sync) 1.4MB N/A N/A 200 Table 5. Standalone per device data characteristics 10

13 The DCN metrics in Table 6 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. DCN Activity Sizing Client Category Payloads per Hour Server SAPS Memory in GB Data Tier SAPS Data Tier Memory Small 300 2, ,750 4 Medium 500 4, ,250 8 Large 1,000 8, , Very large 2,000 16, , Table 6. Synchronization cache DCN sizing Download Sizing Category Synchronizations per Hour Server SAPS Memory in GB Data Tier SAPS Data Tier Memory Small 1, ,500 4 Medium 2, ,000 8 Large 3, ,500 8 Very large 5,000 1, , Table 7. Synchronization cache download delta synchronizations Upload Sizing Category Synchronizations per Hour Server SAPS Memory in GB Data Tier SAPS Data Tier Memory Small 1,000 3, ,500 4 Medium 2,000 6, ,750 8 Large 3,000 9, ,000 8 Very large 5,000 16, , Table 8. Synchronization cache upload change synchronizations 11

14 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, you can employ a Microsoft cluster and some form of highly available storage tier to allow for failover. This configuration works as an active/passive cluster where only one node is active at a time. Both nodes should be identically sized to take over the entire work stream. Storage Tier NAS or SAN Web App Zone (MS Cluster) DMZ SUP Node 1 RSOE 3 U 12 U Default DB 3 U 3 U 3 U Messaging DB Tx Log Monitoring DB Active SUP Node 2 RSOE Relay Server Farm (HA) Load Balancers Passive Figure 5. Active/Passive cluster In larger deployments, you may gain some advantage 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, you must 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, you can virtualize the SUP tier, taking advantage of economies of scale. Failures on a single node can be managed by spreading the load across more than one other virtualized server so that no single node is required to assume the full cluster load. 12

15 Internal Network Web App Zone (SUP Cluster) DMZ SUP Node 1 RSOE Primary Server SUP Node 2 RSOE SUP Data Tier CDB/Messaging Cluster Relay Server Farm (HA) Load Balancers Monitor Server Secondary Server Figure 6. 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, implying 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 cache database) are on SUP, and one (the Consolidated Data Store) is 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 (that is, SSD) can dramatically improve the performance of the SUP cluster beyond the quoted metrics (potentially by as much as 50% or more). If you use SSDs, 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 disk 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. 13

16 Sybase, Inc. Worldwide Headquarters One Sybase Drive Dublin, CA U.S.A sybase Copyright 2012 Sybase, Inc. All rights reserved. Unpublished rights reserved under U.S. copyright laws. Sybase, the Sybase logo, Afaria and MobiLink are trademarks of Sybase, Inc. or its subsidiaries. indicates registration in the United States of America. SAP, the SAP logo and SAP NetWeaver are the trademarks or registered trademarks of SAP AG in Germany and in several other countries. All other trademarks are the property of their respective owners. 1/12