TOPICS

Basic SAP Control Center Administration > 12%

Describe the SAP Sybase Control Center (SCC) and perform basic
administration tasks such as: Monitor Users and Licenses, review or Change
Communication and DCN Ports, manage various Synchronization Settings,
maintain and manage Cache Groups, review logs and manage option, configure
Apple Push Notifications, configure BlackBerry Enterprise Server
Communications, create, enable and remove Domains, manage EIS
Connections.
MBO Deployment and Backend Connectivity > 12%
Describe MBO/LBO concepts - Attributes, Operations, Roles, Relationships;
define general and SAP Connectivity: SOAP Web Services, RESTful Services,
database and SAP BAPI MBOs via JCO MBOs, SAP BAPI MBOs via Web Services
MBO, DOE, SAP NetWeaver Gateway. Perform additional JDBC installations and
configurations and create deployment packages.
Advanced SAP Control Center Admin > 12%
Deploy MBO packages and Mobile Workflow applications to production servers,
configure deployed MBO packages and Mobile Workflow applications.
Import/Export Applications, and manage applications and users.
Security Administration 8% - 12%
Create Users, Groups and Roles (e.g. supAdmin). Configure Server Security:
Secure Server Infrastructure, Secure Platform Administration, and Encrypt
Application Payloads.
Secure all ports and server infrastructure. Apply application authentication and
map physical and logical roles.
Sybase Unwired Platform Monitoring and Tuning 8% - 12%
Configure monitoring and then perform monitoring tasks for the following:
Security logs, synchronization, system queue status, data change notifications,
device notifications (replication), package statistics, device users, cache
activity. Apply performance tuning and configuration checks/adjustments for
the following: Thread Count, Synchronization Cache Size, Java Heap Size, Log
Levels/Settings, Number of queues, Connection Pool Size, general platform
sizing. Create Synchronization and Cache Groups and Cache Policies: e.g.
Cache Group/Cache Policy vs. Synchronization Group/Change Detection
Interval.
Sybase Unwired Platform Maintenance and Troubleshooting 8% - 12%
Perform common maintenance tasks for the following: caches, connections,
databases, devices and Users, error history, logs, packages, scheduled cleanup,

and investigate CDB, device connection, SCC access, relay server-related

errors. Perform backup and recovery for core platform components.

Implementation Planning, Installation and Design < 8%

Determine and validate key target landscape infrastructure requirements:
Relay server (RSOE and Relay Server platform), Server and Client License
Requirements, Underlying User Store: i.e. LDAP. Describe how to scale the SAP
Sybase Unwired Platform environment and define Domain strategies.
Data Change Notification and Push < 8%
Describe and create the two types of Data Change Notifications, implement
DCNs with and without payload, and impliment Push Notifications.
Product Introduction and Architecture < 8%
Describe the SAP Sybase Unwired Platform architecture (Runtime vs. SDK) and
the core components; identify installation prerequisites, and perform the
installation of key components, and apply post-installation procedures.

MODULE I
Sybase Unwired Platform and
Administration Architecture
The Sybase Unwired Platform is...
Sybase Unwired Platform (SUP) is a mobility-enablement platform that allows
you to create end-to-end mobile applications. It provides a server environment
for hosting mobile business objects. SUP consists of a cache, also referred to as
Cache Database (CDB), for storing mobile application data. SUP can handle
data synchronization between clients and back-end data systems. It provides
an integrated development environment (IDE) to create rich native applications
or quick hybrid web container applications. SUP supports client APIs to create
native mobile applications for BlackBerry, iOS, Windows Mobile, and Android
devices.
What is an EIS?
Enterprise Information System (EIS) is a back-end system that serves as the
source of data for Sybase Unwired Platform. Sybase Unwired Platform allows
connectivity to many types of EISs, such as:

Relational databases using Java Database Connectivity (JDBC);

Simple Object Access Protocol or SOAP-based Web Services;
REpresentational State Transfer or REST-based Web Services;
SAP BAPIs and RFCs.

Administrator Types
SUP has two types of administrators, namely, Unwired Platform Administrator
and Domain Administrator. The Unwired Platform Administrator has cluster-wide
administration rights, so he or she has full control of SUP. The Unwired Platform
Administrator is the super user of the platform. The Unwired Platform
Administrator can perform domain management, Server configuration, Device
Registration, Monitoring, and Package Deployment and Management. The
administrator is the domain owner and has all the domain administrator rights.
The Domain Administrator has the rights to perform Domain manager tasks.
The Domain Administrator can perform package deployment and management,
server connections, security configuration, and role mapping. The Domain
Administrator can only access the domains that the platform administrator
grants.
Administrator Tasks

The key tasks of an administrator are

..Mobile
..Mobile
..Mobile
..Server

application deployment;
application configuration and management;
application user and device registration;
configuration, maintenance, monitoring, and tuning.

To perform these tasks, you need to understand certain requirements such as

..System design required for the environment

..Security plan including level of security to be implemented
..Synchronization model to be used
..Back-end systems that applications must be integrated with
..Types of devices that need to be supported.

Sybase Unwired Platform Architecture: First View

The Unwired WorkSpace is a Development IDE that allows you to create Mobile
Business Objects (MBOs).
MBOs contain Attributes and Operations. Attributes define what data is shown
on the device, and Operations define how the data can be manipulated. By
using the Unwired WorkSpace, you can create Native and Workflow applications
and deploy them on Unwired Server.
The Management Console is another component of the SUP architecture. The
Sybase Control Console (SCC) is where an administrator can perform
administrative tasks. For example, deployment of Workflows, creating a
domain, security implementation, monitoring, and registration of user and
devices.
Sybase Control Center (SCC)
The Sybase Control Center (SCC) is the key component of SUP where the
administrator performs the tasks to manage the platform.

Generally, administrators use the SCC to

Configure the environment such as users, security, etc.;

Manage application components;
Monitor the health of the server.

The SCC is a browser-based utility where you can deploy and administer SUP. To
access the SCC, you need to enter the valid URL. After navigating to SCC, you
need to provide the user credentials. The user credentials are case-sensitive
Two Primary Components of a Mobile Application
Mobile Business Objects (MBOs) and the User Interface are the two main
components of a mobile application.
After the MBOs are created and deployed, developers create the User Interface.
The User Interface is the front end that contains the screens, controls, and
menus. The Workflow User Interface is created using the Mobile Workflow
Forms Editor in Sybase Unwired WorkSpace. The Native User Interface is
created in IDEs like Xcode, Eclipse, or Visual Studio.
Types of Sybase Unwired Platform Applications
By using Sybase Unwired Platform, you can build two types of mobile
applications. They are Workflow applications and Native applications.

The Workflow application is a simple request-response type

application. For example, the employee requests vacation, and the
manager approves or denies the application. Sybase Unwired Platform
Workflow applications are not the same as SAP Workflow applications.
The Native application allows access to more complex features on the
device platform. It requires more coding, knowledge, and time. The
developer can have more control of application development.

Mobile Workflow Development Model

In the Mobile Workflow Development Model, the first step is to create and
deploy MBOs and Workflow on the Production Unwired Server. Next, you need
to assign a workflow to the registered user. These two steps are common
administrative tasks.
Native Application Development Model
In the Native Application Development Model, administrators deploy the MBOs
on the Production Unwired server. Next, the developer generates the code to
create the native application.
Caching Mobile Data
When using the mobile application developed using Sybase Unwired Platform,
the devices do not communicate directly with the EIS. Therefore, the mobile
device data is cached. Caching is controlled by the Data Tier. The Data Tier
manages the cache database, also referred to as CDB or the Consolidated
Database.
Data Synchronization Approaches
One of the challenges in building mobile applications is to keep the data in sync
between the backend data source and the device. SUP supports two types of

data synchronization, namely replication-based synchronization (RBS)

and message-based synchronization (MBS).
Replication-based Synchronization (RBS)
Replication-based Synchronization (RBS) synchronizes data between a devices
database and the servers cache database (CDB). RBS can be used for
occasionally-connected devices that need access to data when offline. When
offline, you can view, add, modify, and delete data from the source. RBS is
optimal when you need to store large amount of data on the device. RBS
requires the device to initiate the synchronization. The changes are sent to the
data source in bulk. RBS is used by Windows, Windows Mobile, and BlackBerry
platforms.
Message-based Synchronization (MBS)
MBS initiates a session to perform the synchronization for a bulk transform of
changes. Whereas, Message Based Synchronization sends individual messages
between SUP and the mobile device. If the device is offline, the messages are
stored in a queue in the Data Tier and Advantage DB. When the device
connects to SUP, the cached data is transferred to SUP. iOS Native applications
and Workflow applications use MBS.
Supported Device Types
You can build mobile applications by using Sybase Unwired Platform for various
devices such as

Android which is limited to Mobile Workflow applications;

BlackBerry;
iOS devices;
Windows XP, Windows Vista, and Windows Mobile (laptops and tablets),
which are limited to RBS Native applications.

Device and Replication Support

RBS supports only these application types:

BlackBerry Native applications

Windows Mobile Native applications
Windows Native applications

MBS supports these application types:

iOS Native applications

All Mobile Workflow applications

Sybase Unwired Platform Editions

The Sybase Unwired Platform Runtime contains

Unwired Platform Server components;

Sybase Control Center (SCC);
Components that support Online Data Proxy for SAP NetWeaver Gateway.

Sybase Mobile SDK is an installable component that provides an interface to

develop mobile applications. SDK is used by developers to build the
applications. Sybase Mobile SDK contains three components, namely

Sybase Unwired WorkSpace;

Native Object API and additional OData SDK;
Hybrid Web Container.

SAP NW Gateway OData Support

The Online Data Proxy contains the Unwired Platform Server components that
support mobile applications consuming Open Data (OData) Protocol.
Supported Operating Systems
The Unwired Platform Runtime supports the Enterprise Server (Production)
Edition that runs on 64-bit Windows 2003 Server or Windows 2008 Server.
Sybase Mobile SDK supports

Windows XP Professional with SP2 and SP3

Windows Vista Business, Enterprise, and Ultimate Edition;
Windows 7 Professional, Enterprise, and Ultimate Edition versions for 32bit and 64-bit.

Platform Environment Options

Sybase Unwired Platform supports different environment types, such as

Development
Test;
Single server installation;
Clustered installation;
Multitenant environments.

Platform Editions
The Unwired Platform Runtime has two editions.

The Enterprise Development Server components can be deployed to

one or more server hosts. It supports clustering in a multinode
environment. The Enterprise Development Server supports multitenant
environments by allowing domains to be created in the server. Typically,
the Enterprise Development Server is used in the test environment.

The Enterprise Server is similar to Enterprise Development Server.

The only difference is, the Enterprise server is used for a production
environment. In addition, you need to purchase the number of client
software licenses based on the need.

Sybase Unwired Platform Architecture

Sybase Unwired Platform Components
Sybase Unwired Platform contains five core distinct components. They are

Relay Server;
Unwired Server;
Data Tier;
Unwired WorkSpace and Mobile Application Development SDKs;
Sybase Control Center (SCC).

Component 1: Relay Server

The first component in Sybase Unwired Platform is the Relay Server. The Relay
Server acts like a reverse proxy that allows devices to communicate with the
platform through the firewall that has common opened ports. The Relay Server
is a set of extensions that runs on Microsoft IIS or Apache Web server.
Component 2: Unwired Server
The second component in Sybase Unwired Platform is the Unwired Server. The
Unwired Server is an application server that acts as a container for MBOs.
MBOs are packaged and deployed on the Unwired Server. The Unwired Server is
a container for Workflow applications also. A production environment may have
several Unwired Servers running in a clustered environment.
Note:
Workflows App se deployan directamente en Unwired Server
Native Apps se deployan en el device
Component 3: Data Tier
The third component in Sybase Unwired Platform is the Data Tier. The Sybase
Unwired Platform mobile applications do not talk to the EIS directly. Therefore,
the Data Tier acts like a mediator between the device and EIS. The Data Tier is
a cache for mobile application data. In addition, the Data Tier manages
clustering and monitoring databases. The Data Tier manages the CDB and
Advantage Databases. A single Data Tier can serve multiple Unwired Servers in
a clustered environment. To do this, you need to have the Data Tier run on
Microsoft Failover Cluster
Data Tier Databases 1

The Data Tier supports five databases. The first two databases are the
Consolidated Database (CDB) and the Messaging Database. The CDB caches
runtime MBO data. CDB supports only the Sybase SQL Anywhere database.
The Messaging Database is used in MBS applications. It is a temporary storage
location for storing individual messages, when the device is offline. The
Messaging Database supports only the Sybase Advantage database.
Data Tier Databases 2
The Cluster, Monitoring, and Logging databases are Data Tier databases. The
Cluster Database is located in the server tier that contains configuration
information about the cluster. It supports only the Sybase SQL Anywhere
database.
The Monitoring Database is used to collect server runtime metrics for analysis
or troubleshooting, when enabled. Monitoring Database is a Sybase SQL
Anywhere database.
The Logging Database is used to collect application run-time metrics used for
analysis or troubleshooting, when enabled. Logging Database is a Sybase SQL
Anywhere database.
Sybase Unwired Platform Clusters
When installing Sybase Unwired Platform, a cluster is automatically created.
You can cluster both the Server and Data tiers in a server. A server can be a
member of only one cluster. Clusters serve two common purposes. They
provide high-availability / failover and allow Load Balancing. Load balancing is
implemented using O/S or third-party hardware and/or software solutions.
Primitive (round-robin) load balancing can be achieved using the Relay Server.
Cluster Strategies
Clustering in a single machine provides a nonredundant environment. It is used
by a developer where the Data and Server tiers reside on the same machine.
Clustering on two nodes is a primitive architecture where the Data Tier is on
one node, and the Server Tier is on another node.
Clustering on three nodes is an architecture with two Server Tier nodes and one
Data Tier node. Clustering on N+2 nodes is a redundant architecture with
multiple Server Tiers supported by a relay server(s) and two Data Tier nodes.
Component 4: Unwired WorkSpace
The Unwired WorkSpace allows developers to

manage Mobile Application Projects;

design and deploy MBOs to development or test servers;
design, deploy, and customize Workflow applications;
generate the code to be used with the client API to create Native
applications;

manage the connections to EIS sources;

explore EIS data. You can drill down into an SAP BAPI to view its
operations, inputs, and outputs.

MODULE II
System Design and Installation
Design Considerations for Sybase Unwired Platform.

Installation Considerations
Before you begin installing Sybase Unwired Platform, consider these prerequisites:

The type of environment that you are building (Is it a development,

testing, or production server)
The extent of clustering capabilities usage in your environment
The Operating System on which the platform will be installed
The need of a Microsoft Failover Cluster in your environment
The implementation of load balancing in the environment
The number of Server Tier nodes that you wish to install
The number of Relay Servers that are required (if any)

Clustered Environments
A cluster consists of two or more servers or nodes that work together to
provide application services. The benefits of creating a clustered environment
are redundancy or fail-over and load balancing. Load balancing is important in
a more scalable environment, where you can easily install additional servers to
the cluster based on your business needs. In a Sybase Unwired Platform
environment, two types of clusters can be created. They are the Server Tier
and the Data Tier. When installing the Server Tier, a cluster is automatically
created. You also have an option to name the Server Tier cluster during
installation. Data Tier clustering requires Microsoft Failover Cluster.

Environment Options
The Sybase Unwired Platform can be installed for different reasons.
In a scenario where developers need a local installation on their machines, a
single server environment can be built, where the Server Tier and Data Tier
exists on the same machine.
Another scenario is where developers need a production-like environment to
test their applications prior to migration to production. In such a case, a
multiple server environment can be built, where the Server Tiers and Data Tiers
are installed on separate machines or may be clustered.
Additional Configuration Options

Additional Configuration options include options for load balancing and Relay
Servers. In your environment, a load balancer can be added in front of the
Relay Server by enabling a Windows Network Load Balance Cluster. To do this,
you need to provide static IP addresses. You can also use third-party load
balancing for hardware and/or software. When using Relay Servers, a Single
Relay Server option results in a chokepoint with no redundancy. To embed Relay
Servers with Windows Failover Cluster, you need to provide Active Directory,
Domain, and DNS. The Failover cluster is always mandatory for a Data Tier.

Downloads and Licensing processes

Information about Licenses
Sybase Unwired Platform uses a process called SySam to manage licenses.
The SySam license file controls the base number of devices or clients that can
be registered, the number of servers you install in your cluster, and the
expiration dates for devices and servers.
Each server in the cluster must be licensed. Multiple servers cannot share a
single license. However, the servers of a cluster can share the device or client
licenses.
License Models
The two types of SySam license models that are available are the Unserved or
local license that is specifically tied to a machines Physical Address and host
name. You can access the Physical Address or host name by using a commandline utility. Use the Physical Address of the primary wired Ethernet adapter. The
Served licenses are licenses that are generated and installed into a SySam
license server and used during product installation.
Selecting License Type
The CPU License or CP is only available for enterprise server editions.
Creating Client Licenses
Client licenses are mandatory and must be generated. The single license allows
the client to run only on one application, whereas unlimited licenses allow the
client to run on multiple applications. Licenses are generated based on classes.
The Class A license is generated for hand-held devices such as iPhone, WM,
and BlackBerry. The Class B licenses are for Win32 devices, such as Laptop or
tablet computers.
Post Installation: Location of Licenses
After installing the license file, you can view the license file in the licenses
folder.
C:\SYBASE\UNWIREDPLATFORM\SERVERS\UNWIREDSERVER\LICENSES
Changing licenses after installation

After installing the software, you can change the license. During the
installation, the bin folder is created. The bin folder contains the license.bat file
that allows you to upgrade or update SUP licenses without having to rerun the
installer. It can be used for both served and unserved license models. You can
change licenses at a command prompt using the license.bat PE LT command.

Microsoft Failover Cluster

Preparing to Install Microsoft Failover Cluster
The first step to install Sybase Unwired Platform is the Data Tier installation.
If Data Tier clustering is required, you first need to install the Microsoft Failover
Cluster.
The Microsoft Failover Cluster can be configured on Windows Server 2008
Enterprise R2 with the assistance of the IT department.
The IT team will provide static IP addresses for the server. Before you begin
installing the Microsoft Failover Cluster, you need to install the Active Directory
Domain Controller and a DNS server on the Domain Controller.
Domain Creation
After selecting the Active Directory Domain Services option in the Server Roles
page, you need to provide the Fully Qualified Domain Name (FQDN) of the
forest root domain.

Enabling the DNS Server

After providing the domain name, you should enable the DNS server as a part
of the Active Directory domain controller installation.
Post Domain Work
The domain controller will not contain any of the Sybase Unwired Platform
software.
The role of the domain controller is to manage other servers within that
domain.
You need to create additional servers that will host the Data and Server Tiers.
The class lab shared environment has two Data Tier nodes named supdata2
and supdata3.
They act as an active and passive server respectively. These two servers are
members of the supcourse.domain.
Adding the Failover Cluster Feature

After installing an Active Directory domain and a DNS server, you need to
install the Microsoft Failover Cluster. In the active machine or supdata2, in the
Server Manager Console, under the Features section, click Add Features and
then select Failover Clustering to install Microsoft Failover Clustering. After the
Failover Clustering feature is installed, you need to configure the cluster based
on your business needs.
Create Shared Storage
In this setup, the Data Tier requires a shared storage to control the physical
database files. To set up or view the shared storage, you need to use the
Failover Cluster Manager utility. After you installed the Microsoft Failover Cluster
and created a cluster, the Failover Cluster Manager utility is installed. In the
Failover Cluster Manager utility, expand the Storage node to view the shared
storage. This shared storage could either be a disk cluster or a RAID array to
store the database files. For the class lab environment, a shared E drive is
created to be used by the members of the cluster for storage.

Deployment Edition Installation

Pre-SUP Installation Requirements

During the installation process, the User Account Control (UAC) should be
temporarily disabled.
The user who is installing Sybase Unwired Platform should have
administrator privileges. Therefore, the user should run the setup.exe file
with the Run as Administrator option.
If the company policy permits, create a new user account with static
credentials for the install. Otherwise, ensure to update the password for
the Sybase Messaging Service every time the user password changes.

Multiple Installs Required

When creating a clustered environment, you need to run the Sybase Unwired
Platform installer multiple times.

First, the Data Tier nodes are installed.

3One installation for each node of the Data Tier.
Next, the Server Tier nodes are installed. Similar to the Data tier, you will
install for each node of the Server Tier.

Choosing Install License Type

Sybase Unwired Platform supports two types of licenses. They are the Unserved
or the local License type and the Served or the remote License type.

An unserved license type is a standalone seat license that is managed

on the local machine.
A served license type is a standalone seat license that is managed from
a license server.

It requires a license manager host name and license manager TCP port before
proceeding further. Select the type of license you wish to install and then click
Next.
Choosing Edition and Product License Types
To install a production server, you need to select the Enterprise Server option.
For Enterprise Server, the license type would be CPU License. For the
Enterprise Developer edition, the license type is Development and Testing.
Based on the business requirement, you need to select the edition and license
type.
Supply SySam Details
If you choose the served license type, you need to specify the host name and
port number of the SySam license server. Before you begin installing Sybase
Unwired Platform, you need to install the SySam license server.
Enable Data Tier Configuration
In order to change the defaults or install the Data Tier into a clustered
environment, the Configure data tier option should be enabled.
Data Tier Databases Configuration
After you enable the Data Tier configuration, you will be prompted to configure
the databases in the Data Tier. You need to set the port numbers and
passwords for all the databases. The Cache database server, Cluster database
server, and the LogData database server are SQL Anywhere databases with
default password SQL that can be changed during the installation process.
The SQL Anywhere database has .db and .log files. The transaction log is the
file that is updated on every transaction that occurs between the back-end and
front-end. By checking the checkbox, you can specify separate locations for
these files. To install into a Microsoft Failover cluster, enable the High
availability option
Installation Progress and Completion
The time to install a Data Tier node is approximately 10 minutes. At the end of
the installation, you need to ensure that there are no errors reported by the
installer. You should also confirm that the four Windows services namely
Advantage Database Server, Sybase Unwired CacheDB, Sybase Unwired
ClusterDB, and Sybase Unwired LogDataDB are created. Finally, you should
check if there are any errors logged in the Windows Event log.
Data Tier Servers Directories
The Servers folder contains the most important files stored in the folders
Advantage, SQLAnywhere, and Unwired Server.

The Advantage folder is used by the Messaging server for MBS

applications.

The SQLAnywhere folder is used primarily by RBS applications.

The Unwired Server folder contains only a minimum number of required files,
as this is not a Server Tier installation.
After installing the first Data Tier node, you can begin installing the second
Data Tier node. Before you begin installing the second Data Tier node, you
should shut down the active node of the Microsoft Failover Cluster. This allows
the passive node to become active, giving it access to the shared data storage
E: drive. Repeat the installation of the second Data Tier node in the same way
as the first was installed
This completes the installation of the platforms Data Tier.
Data Cluster Client Access Point
Before installing the Server Tier nodes, a Client Access Point must be created
for the Windows Failover Cluster. The Client Access Point can be created using
the Windows Failover Cluster Manager console. In the Failover Cluster Manager
console, log in as the Domain Controller Administrator. Right-click Services and
applications and then select Configure a Service or Application. This starts the
High Availability Wizard.
High Availability Wizard
The High Availability Wizard configures the cluster so that another server
automatically resumes the service or application when a server fails. If the
service or application itself fails, it can be automatically restarted either on the
same server or on another server in the cluster depending on the options
specified. This is also known as failover.
Bring All Resources Online
After adding all of the platform services as resources, the client access point on
the Failover Cluster Manager screen will show the name of the client access
point, the drive where it is stored, all the resources, and their status as offline,
initially. Now, right-click on the statuses and set them to online.
Adding a Shared Folder to Generic Service
A shared folder must be added to the Client Access Point. To add a shared
folder, right-click the client access point and then select Add a shared folder.
Choosing Shared Folder Location
After selecting the Add a Shared folder option, the Provision a Shared Folder
Wizard opens. Here, the first step is to specify a shared folder location. In the
Location box, type in the path or click Browse to locate the folder.
Specifying NTFS Permissions
In the second step, you need to set the NTFS Permissions. As an administrator
user, you need to have Full Control rights to the specific folder to set the NTFS

permission. Select the Yes, change NTFS permissions option and then click the
Edit Permissions button. In the permissions for administrator section, ensure
that all the permissions are allowed and then click OK.
Setting SMB Permissions
While setting SMB Permissions, click the option to enforce full permissions for
Administrators.
Advantage Database Authentication Error - 1
After installing the Server Tier, the status of the Advantage Database service
will be online. If the service is offline, then a problem occurred when
authenticating the Advantage Database Server. To troubleshoot this problem,
navigate to the Data Tier server and check for the registry key value
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\Advantage\Configur
ation\TPS_LOGS to find the location of the adsserver.ini file. The default value
is: C:\. If the adsserver.ini file does not exist, create it in the location identified
in the registry key value, on each data tier server.
End of Data Tier Install
At the end of the Data Tier installation, you will notice that both active and
passive nodes are installed.
The Client Access Point is created. You can now begin the Server Tier
installation. Firewall ports MBS port 5001 and RBS port 2480 may need
to be opened for the Server Tier installation to be successful, and
Windows Firewall may need to be disabled.
Providing Data Tier Information
Since you chose to configure the communication port, the installer prompts you
to provide data tier information. The Host name builds the connection to the
data tier. Enter the information required regarding Cache database, Cluster
database, and LogData database along with the password, which would by
default be SQL unless changed during the installation.
Server Tier Services
The Server Tier installs two Window services, the Sybase Control Center 3.2
and the Sybase Unwired Server.
Installation of Second Server Tier Node
Run the Sybase Unwired Platform installer again to install additional nodes
within the Server Tier cluster. Three different installation options are available:

Install the data tier for your Unwired Platform cluster

Install the first server node and connect it to the data tier
Install an additional server node and connect it to the data tier

Verifying Cluster Members are Running

Under the Unwired Platform Cluster, click on the Servers tab to view the Server
names and their role and status. Use the Sybase Control Center (SCC) to verify
that the members of the cluster are running.

Post Installation Tasks

Logging Into the SCC
The login page for the Sybase Control Center is displayed. You can log in to the
SCC using the credentials supAdmin as the user name and s3pAdmin as the
password. These are the default credentials for a deployment or production
server.
SAP JCO Installation
SAP JCO installation is mandatory for communications between Sybase Unwired
Platform and SAP ECC. The installation is now automatic in Sybase Unwired
Platform version 2.1.
Downloading DBMS JDBC Drivers
As part of the Sybase Unwired Platform installation, the Sybase JDBC drivers
are also installed. If you are going to use DB2 or Microsoft or Oracle as the
backend EIS, the JDBC drivers for those DBMSs must be downloaded and
installed.

Installing JDBC Drivers

Folder: \UnwiredInstallDir\Servers\UnwiredServer\lib\3rdparty\
The JDBC drivers are contained in Java Archive or JAR files. The downloaded JAR
files are placed in the Server Tier. There are multiple server tiers, and the JDBC
drivers must be placed on every node of the Server Tier. After placing the JDBC
drivers, you should restart the server
Relay Server Defined
The Relay Server is a feature provided by Sybase SQL Anywhere. It is a
communication architecture for mobile devices that communicates with Sybase
mobile middleware such as Sybase Unwired Platform. A Relay Server acts like a
reverse proxy, allowing devices to communicate through the firewall with the
platform through commonly opened ports such as port 80.
The relay server is a set of extensions that are installed on either Microsoft IIS
Web Server or Apache Web Server.
Outbound Enablers (RSOE)

One or more Outbound Enablers manage communications between the

Unwired Server and the Relay Server. The RSOE opens outbound HTTPS
connections to the Relay Server to handle both inbound and outbound
communication channels. Each RSOE is an Unwired Server process that
manages communication on either Messaging port 5001 or Replication port
2480.
Relay Server Install Files
The 32-bit and 64-bit ZIP files for the Relay Server installation are part of the
install media and are located in the modules\relayserver folder. You have to
extract the appropriate files contents to the Relay Servers wwwroot folder.
Path Modification
The servers Path environment variable is modified in order to include the
wwwroot\ias_relay_server\Server folder.
Adding a Relay Server Configuration
To add a relay server configuration, click the Relay Servers tab on the root node
of the Sybase Control Center and then click the New button.
Relay Server Farm Configuration
While configuring the Relay Server Farm, you have to specify the farm id(s) and
types in the Unwired Server farms information page. You also have to specify a
server node id and a token number for each farm id.
Relay Server Configuration File
Now that you have completed Relay Server configuration, you will generate the
relay server configuration file. In the Relay Servers tab, choose a relay server
configuration and then click the Generate button to create an rs.config file
based on the defined farms. After selecting the type of configuration for the
rs.config file, click Next to save the file in the desired location.
Editing the rs.config File
The generated rs.config file can be edited by changing the start attribute to a
value of auto. The verbosity attribute also has to be changed to the
maximum value of 5. This setting enables debug information to be written to
the Relay Server log file
Destination for Relay Server Config File
After performing necessary edits, the generated relay server configuration file
is copied to the C:\inetpub\wwwroot\ias_relay_server\Server folder on all of the
relay server(s).
SQL Anywhere 12 Environment Variable

You can create a new machine system environment variable named SQLANY12.
The SQLANY12 variable should specify the relay servers install location. (In
Windows/System Properties)
ISAPI Handler Mappings
After updating the Relay Server with the new configuration file, you will edit the
handler mappings. In the /ias_relay_Server Home page of the Internet
Information Services Manager window, double-click the Handler Mappings icon
to edit the Relay Servers ISAPI handler mappings.
Enabling ISAPI-dll
Once the Relay Servers ISAPI handler mappings are edited, you have to enable
the ISAPI-dll. In the Handler Mappings page, you will notice that the ISAPI-dll is
disabled by default. To enable the ISAPI-dll, select ISAPI-dll and then click the
Edit Feature Permissions link. In the Edit Feature Permissions dialog box, click
the Execute check box to enable the permission.
Configuring a State Manager as a Service
The dbsvc utility that is part of SQL Anywhere allows creation of Windows
Services. A service is created to run the State Manager as a process on a Relay
Server node. You should also ensure that the C:\Sybase\logs directory exists for
the service to start successfully.
Creating Outbound Enabler Configurations
To create an outbound enabler configuration for a given node of the server tier,
you will first choose its Server Configuration. Next, select the Outbound Enabler
tab and then click the New button.

Configuring Outbound Enabler

After creating the outbound enabler configuration, you will next configure the
outbound enabler. In the Update Configuration dialog box, you will choose a
farm type, a relay server host, and then select the server node id

MODULE III
Unwired Workspace Overview for
Administrators
Unwired Workspace
Installing the Sybase Mobile SDK 2
The ED(Enterprise Development Server) license is recommended for
development environment and not for production purposes. Each installable
component is available on the host and clustered systems. For a development
server, the license type is set to DT(Development and Test License Type
Servers). This type of license provides unlimited license on CPU/Cores or host
configuration for single host or multiple hosts or clusters. This license is
applicable for Enterprise Development Server and Enterprise Server.
Unwired WorkSpace User Interface
Let us explore the Sybase Unwired WorkSpace user interface. The WorkSpace
Navigator pane lists all the files related to a project. The Enterprise Explorer
pane contains connection profiles information. In this pane, you can navigate to
the Web Services, SAP Servers, Unwired Servers, REST Web Services, and
Database Connections. The Properties View window displays the properties of
the selected object. The Diagram Window displays project diagrams. The
Problems tab displays warnings and errors generated in a mobile application
project.

Introduction to the Mobile Business Objects (MBOs)

Mobile Application Requirements
To create a Native or Workflow based mobile application, you need to create
two main components. These are Mobile Business Objects and User Interface.
MBOs are designed using the Unwired WorkSpace and are deployed to an
Unwired Server. Native UIs are created with the IDE of your choice. Workflow
UIs are created with the Unwired WorkSpace by using the Mobile Workflow
Forms Editor.
MBO Defined
An MBO is an object that contains attributes and operations. The attributes
define the data-makeup of the object, and operations define what the object is
capable of doing. Native and Workflow applications contain screen to display
and edit data. The fields that are displayed or edited are derived from the
MBOs attributes. The types of changes that can be performed depend on the
MBOs operations.
MBO Data Sources

MBOs extract data from sources such as

SAP BAPI/RFCs,
Database tables or stored procedures,
SOAP Web Services, and
REST Web Services.

In this case, the MBO attribute will be mapped to a column in a database table.
When data is extracted from external sources, you need to create connection
profiles in the Unwired WorkSpace. These connection profiles provide designtime connectivity needed for development and testing.
MBO Attributes
Attributes are mapped to a data source when an MBO is created. For example,
if the Data Source is a database table, then, in the Attributes Mapping tab,
Attributes are mapped to columns using the SELECT statement.
MBO Operations
MBO Operations have a name and a type. The operation types are CREATE,
UPDATE, DELETE, and OTHER. The OTHER operation type does not allow
data manipulation.

Configuration of the Unwired Workspace

Connection Profiles
You can create connection profiles in the Enterprise Explorer pane. EIS
Connection profiles must be created before you begin application development.
Create New Unwired Server Connection Profile
You can create a New Connection Profile to the Unwired Server with the help of
connection profile parameters. The default password is set to s3pAdmin. The
Port number was set during installation.

Configuration of the Unwired Workspace

Importing and Exporting Projects
Mobile application projects and connection profiles can be exported from one
Unwired WorkSpace to another. The exported mobile application projects and
connection profiles retain all reference information such as data sources, roles,
generated code, and connection information. When a project is exported from
Unwired WorkSpace, the connection profiles are not part of the export.
Exported SAP Connection Profile
Connection profiles are exported as XML files, and the credentials are visible
unless the file is encrypted.
Importing a Connection Profile

On the Enterprise Explorer, click the Import button. Specify the exported profile
path. When the import process is complete, the connection profiles will be
automatically refreshed in the Enterprise Explorer.
Post-Import Tasks
After importing the project and the connection profile to an Unwired
WorkSpace, you may need to modify the project components. You should verify
that the connection profiles are referencing the correct Data Source and Sybase
Unwired Server. You should also verify that the connection profile is using the
appropriate credentials to connect to both the back-end data source and the
Unwired Server.

Project Deployment
Deployment Methods
Once a mobile application or workflow is complete, it must be deployed to the
Unwired Server. Developers can use Unwired WorkSpace to deploy an
application to a test server. Administrators are responsible for deploying
applications to a production environment using the Sybase Control Center.
Setting Deploy Options
When deploying an application, you need to select a deploy mode and verify
the version number, package name, and the synchronization method.
Deploying JARs
. During deployment, a JAR file can be selected to deploy with the application.
This wizard to deploy JARs is enabled only when the developer uses the
Advanced Developer profile option.

MODULE IV
Using
Sybase
Administration

Control

Center

for

Sybase Control Center (SCC)

Using the Sybase Control Center (SCC)
The Sybase Control Center (SCC) is an administrative tool used in the Sybase
Unwired Platform. It is installed with the Runtime package. A Windows service
named Sybase Control Center 3.2 is installed on each of the Server Tier
machines. The Sybase Control Center has two administrators, the Platform
Administrator and the Domain Administrator. The Platform Administrator
has a cluster-wide administration access to the Unwired Platform. The default
username is supAdmin. The Domain Administrator access is limited to a domain
assigned by the platform administrator. The default username is
supDomainAdmin.

Server Environment Administration

Basic Administration Tasks

The basic administrative tasks on a server environment are

monitoring licenses
reviewing or modifying communication and DCN ports
managing replication-based synchronization settings
managing message-based synchronization settings
configuring Apple Push notifications
configuring BlackBerry Enterprise Server communications
creating Domains;
managing EIS Connections.

Monitoring Licenses
A license is mandatory for each server tier and mobile device. However, these
licenses have expiration dates. The devices will not be able to connect to the
server, if there are not adequate licenses. All the license related error
messages are logged in the Server log. Monitoring the number of licenses
and their expiration dates are part of the administrators tasks.
Reviewing Licensing Information 2
Sometimes, the number of devices exceeds the total device license count. In
such case, the access to the server is not permitted unless the license allows

an Overdraft mode. An overdraft mode temporarily allows devices to access

the server during peak times.
Reviewing Licensing Information 3
When the Device license expires, the Unwired Server generates a license
expiration error, and the connection requests from the registered devices are
rejected.
Exceeding License Limits
When users exceed license limits, administrators can upgrade the license and
manually change the license by using the batch file named license in the \bin
folder. Alternatively, administrators can delete the inactive device users.
Server Communication Ports 1
Developers must create Unwired Server connection profiles in the Unwired
Workspace. These profiles use port 2000 to access the server.
Replication Listener Ports
In the Replication tab, administrators can configure or monitor the ports used
by the RBS device applications. The listener ports use a proprietary protocol
based on HTTP. In the Replication tab, administrators can set the maximum
cache size and the number of worker threads used in synchronization. If the
client application performance is not acceptable, increase the synchronization
cache size and thread count. 2480 normal port and 2481 for secure port
Replication Notification
When the CDB changes, notifications are sent to the device. As part of the
notifications configuration, you can either enable or disable the server-initiated
that is push-based or client-initiated that is pull-based notifications. These
notifications require application code. You can also specify the frequency that
the Servers notification table is polled.

In the Messaging tab, you can configure the ports used by RBS device
applications. It uses a strongly encrypted HTTP-based protocol. Listening
on multiple synchronization ports may provide greater flexibility and
reliability. Consider adding another port, when virus detection results in
dropped packets or connections. All messaging traffic is still funneled to
a single listener. Default ports: 5000 normal and 5001 for secure
port
Apple Push Notification Configuration 2
To create and download the Certificate file and to obtain a password, you
must be a registered Apple developer. The MobileWorkflowPushDistCert
is a sample Certificate file provided with SUP.
2195 and 2196 is used for Apple Push

BlackBerry Enterprise Server Configuration

BlackBerry devices must go through BlackBerry Enterprise Server (BES)
before accessing the Unwired Server. In the Messaging tab, in the
BlackBerry Push Configuration section, administrators can configure the
BES server ports. By default, port 8080 is used for the BES server
connectivity.
Domains
Domains provide a logical partitioning of a hosting organizations
environment.
For example, a host of Sybase Unwired Platform can create domains for
different departments within a company or even have domains that
support individual companies. Server connections, packages containing
MBOs, role mappings, logs, and so on can be viewed and managed
within a domain. Domain Administrator has the rights to perform domain
management tasks such as package deployment and management,
connection profiles, and so on.
Reasons to Create Domains
There are a number of reasons to create domains. Basically, domains
allow multiple customers to be segregated within the same Unwired
Server cluster. Administrators can configure a different security
configuration for different Domains.
This reduces exposure since the Domain Administrator can access only
certain portion of the overall Server environment such as package
management, logs, connections, and security within the domain.
EIS Connection Management
MBOs require connections to back-end data repositories. EIS connection
supports different types of connectivity. They are JDBC, SAP, and Web
Service such as SOAP and REST. Connection profiles are created during
the Unwired WorkSpace design-time, so that a developer can design
applications. The Administrator must create server connection pools for
the corresponding connection profiles. The Developer can also create
server connection pools from Unwired Workspace.
Other Connection Types SOAP
The connection profiles for SOAP Web Services require the address of the
service, specified with a URL. The authentication properties such as user
name, password, and certificate can also be specified by clicking the
<ADD NEW PROPERTY> command.

Other Connection Types - REST

The REST connection profiles are similar to SOAP. The REST connection
profiles require the Resource Base URI.
Other Connection Types - Database
The database connection profiles require port numbers, JDBC Database
URL, user id, and password.
Creating a Connection Template
Connection templates provide common connection properties and values
for a specific pool type.
Package Management
Package Management
Administrators
are
responsible
for
managing
packages.
The administrative tasks that are part of the Package Management are
deploying MBO packages to production servers, deploying Mobile Workflow
applications to production servers, configuring deployed MBO packages, and
configuring Mobile Workflow applications.
Using the SCC to Manage Packages
Administrators can manage packages by using the Sybase Control Center. In
the Sybase Control Center, expand the Packages node, and then select a
package you wish to configure. On the right pane, Sybase Control Center
provides various options to

enable or disable packages;

configure Package settings;
map physical roles to logical roles;
manage Cache group settings;
manage Synchronization group settings;
configure subscription templates;
administer Applications;
review Client logs;
view asynchronous operation replay; and
view Personalization keys.

Package Deployment Process

To deploy a package to a server, you need to specify certain configuration
settings in the Deploy Wizard. In the Deploy wizard, you need to

define the deployment unit or deployment descriptor and deployment

mode;
select the production-level security configuration for the package;

remap the roles to production values; and

configure the production server connections.

Deploying MBO Packages to Unwired Server 4

After selecting the jar file, you need to specify the deployment mode. The
different types of deployment modes are

the Update mode, which is the default mode, that updates the package
with updated objects;
the Noclobber mode that prevents the deletion of a package of the same
name on the target server from being deleted;
the Replace mode which replaces a package on the server; and
the Verify mode that verifies a package and returns any errors. However,
it does not deploy a package.

Select a deployment mode and then click Next.

Deploying MBO Packages to Unwired Server 9
After successful deployment, a message is displayed. The package is deployed
to the Unwired Server and is displayed in the Packages view of the Sybase
Control Center. Regardless of whether an MBO package is deployed as an RBS
or MBS package, it is labeled as UNIFIED in the Sybase Control Center.
Unified packages can be used for both replication and messaging
device application clients.
Configure a Cache Group
While setting the cache interval, the EIS data is cached in the consolidated
database (CDB), and the devices get their data from the CDB.
You have to set the interval to balance between devices getting stale data and
the network traffic involved in updating the cache. A higher value makes the
data more stale, whereas a lower value would cause a delay when the client
synchronizes because the cache would be updating more often.
You can set the Refresh Policy as Scheduled or On Demand. If the cache group
was created as scheduled, then the Schedule tab would be active and the
cache schedule could be modified.
Warning About Cache Groups
The default cache group is set to On Demand with a cache interval of 0h 0m 0s.
This means that every time the client synchronizes, there will be a delay
because the cache has to be updated first. This may not be the best performing
option possible.
Synchronization Groups and Subscriptions
The Unwired Server alerts the device users to update mobile business object
data based on synchronization group and subscription settings. When the MBOs
in a synchronization group are updated, the users subscribed to those

synchronization groups receive either a data update or a device notification

which depends on the type of application.
Notifications to Update Client Data 1
Notifications to update client data vary depending on the type of application. In
MBS or message-based synchronization applications, clients directly receive
data updates. The change detection interval for the synchronization group
determines how often the MBS applications push MBO data to the client when
cache refreshes occur. In RBS or replication-based synchronization applications,
clients receive device notifications. Both the change detection interval of the
synchronization group and the notification threshold of the subscription
determine how often the RBS clients receive device notifications.
Notifications to Update Client Data 2
Data updates through device notifications occur as the Unwired Server checks
the cache for data updates to MBOs according to the change detection interval
configured. If there are data changes, the server generates device notifications.
Once the RBS subscription notification threshold expires, the Unwired Server
delivers the device notifications to clients subscribed to the synchronization
group. Clients receive the device notifications and synchronize data for the
MBOs.
Notifications to Update Client Data 3
Administrators can use subscription templates to specify the notification
threshold for a particular synchronization group. These templates are used to
create subscriptions for device users. For RBS devices, the subscription settings
ultimately determine when the device notifications are delivered. For example,
if data for a synchronization group is updated every two hours but a device
user's subscription indicates a notification threshold of three hours, the
Unwired Server postpones delivering these updates for three hours.
Configure a Synchronization Group 1
Synchronization groups are defined by the developer and are part of the
deployment package. Changes to the Change Detection Interval can be made
by the administrator after the package is deployed. The administrator can
choose a package and select the Synchronization Group tab. Then, select the
group to manage and click Properties.
Configure a Synchronization Group 2
Change detection interval defines the time that the push notifications are sent
if a change is detected. The interval can be in hours, minutes, or seconds.
Change detection triggers a diff-calculation for sending data changes to
subscribed clients. These calculations can adversely affect performance.
Therefore, the administrator and developer must jointly determine this interval
value, before configuring it in a production environment.
Managing Subscriptions

Subscriptions define how data is transferred between a users mobile device

and the Unwired Server. During data modification, users are notified about the
changes. Unwired Server allows push updates to the users mobile device.
Administrators can create subscription templates for RBS packages to allow a
device user to be notified when information is available. Subscription templates
are optional and required only if an administrator wants to define preset
subscription properties.
Creating a Subscription Template 1
Enable / Configure the Notification Mailbox 1
Notification Mailbox monitors incoming emails to Unwired Server. It uses a
listener to scan all the incoming email messages delivered. When the listener
identifies an email message corresponding to a matching rule, it knows which
workflow application needs to process the message. The listener then uses a
distribution rule to determine which workflow user receives the special email
that allows displaying the workflow forms. Saving changes to the Notification
Mailbox configuration deletes all email messages from the account; therefore it
is necessary to backup existing messages before saving changes.
Enable / Configure the Notification Mailbox 2
In the Sybase Control Center, select the Workflows node, and then select the
Notification Mailbox tab to configure the Notification Mailbox. From the Protocol
drop-down list, you can either select POP3 or IMAP, based on the protocol of the
mail server. The Use SLL option, when enabled, encrypts the connection
between the Unwired Server and the email server. In the Server and Port boxes,
enter the connection properties required for the Unwired Server to connect to
the email server. Default values of the port are 110 for unencrypted data
and 995 for encrypted data. In the Truncation limit field, enter the maximum
number of characters that can be taken from the original email message and
downloaded to the client during synchronization. Messages will be truncated to
the number of characters specified. The default truncation limit is 5000. In
the Poll seconds field, enter the number of seconds the listener sleeps between
polls. During each poll, the listener checks the master inbox for new email
messages to process. The default duration is 60 seconds.
Configuring a Mobile Workflow Package
When configuring a mobile workflow package, you can set general properties,
matching rules, and context variables; assign workflows; and assign users
properties. The Mobile workflow package must be deployed before the
configuration.
Configure Matching Rules 1
Configure Matching Rules 3
From the Field drop-down list, select a field in the email from which the
parameter value should be extracted. The fields could be From, To, Subject, CC,

Body, or Custom. If you select From, then the parameter value is extracted
from the line of the email message that indicates the name of the sender of the
email. The parameter value can also be extracted using expressions. An
expression includes various operators, such as

##Equals which specifies that the field must exactly match the text in
the label;
##Begins with which indicates that the field must begin with the
specified text in the label
##Ends with which indicates that the field must end with the specified
text in the label;
##Contains which specifies that the text in the label must exist
somewhere in the field; and
##Regular expression which searches for text that matches the
specified pattern.

Configure Context Variables

To configure the context variables of a workflow application, click the Context
Variables tab. The variables for the mobile workflow are displayed. Timeouts
are displayed in seconds and Message Length in bytes. An administrator can
change some of the variables if necessary for a production environment. Select
the variable and click the Modify button to change a context variable.
Assign Workflows to Device Users 1
Users can be assigned to or unassigned from mobile workflow packages
through the Application connections tab. You can click the Assign workflow
button to get the user list.

Application and User Management tasks

Applications in the SCC
Administrators manage and monitor applications using the Sybase Control
Center. An application is defined as a native application or mobile workflow
container instance on a device. Native application is a single binary deployed to
a device that may use one or more MBO packages. Mobile workflow application
is a collection of workflow packages and constitutes as one application. One or
more MBO packages can be assigned to an application.
When administrators deploy an MBO package to the Unwired Server,
applications are automatically created. The default application name is the
package name. Application ID is automatically assigned upon application
deployment. It differs based on type of application client. The Default and HWC
or mobile workflow applications are created during Unwired Server installation
and are displayed on this screen.
Modify / Review Application Properties

Once an application is registered, you can associate the application with one or
more domains and packages. On the Application tab, select an application and
then click Packages to view the application properties. In the Review
assignment window, the domains and packages assigned to the application are
displayed. Click the plus button to add a domain or package to the application.
Application Connections
Application connections can be made by associating an application instance
with a user. One application can be used by many users, or a user may be
associated with many applications. Click the Register button to create a new
application connection. This is similar to the Device Users in Sybase Unwired
Platform releases prior to release 2.1.
Register Application Connections
Before assigning users to workflow applications, you need to register and
activate the users.
Modifying Application Connections
When a device activation code expires, you can reregister an application
connection by using the options in the Application Connections tab. You can
also clone an application connection in the event that a user gets a new or
alternate mobile device. Cloning retains the user information so it can be
associated with another device.

MODULE V
Data Change Notification DCN and PUSH
Data Change Notification and Push
The Data Change Notification (DCN) is a mechanism that alerts and sends EIS
changed data to the CDB associated with an Unwired Server. The DCN
messages are formatted using JavaScript Object Notation (JSON) and are sent
over an HTTP or HTTPS connection. The DCN listener ports are 8000 for HTTP
and 8001 for HTTPS/secure.
Push is a mechanism that allows Unwired Server to notify clients of new MBO
data without waiting for the next MBO synchronization.
Administrator DCN Responsibilities
DCN administrator is responsible for creating the DCN messages. For example,
administrators can create an after-update trigger that will create the DCN
message and deliver it to the Unwired Server. Administrators should review the
DCN processing logs and work with responsible parties to correct the error
conditions. Administrators are also responsible for configuring secured and
unsecured ports to process DCN messages.
Data Change Notification Advantages

When data is modified in the back-end EIS system, the Data Change
Notification allows you to re-populate only the changed data and not the
entire MBO cache data.
It also allows the MBO cache to be updated in near real-time by the EIS
rather than on an Unwired Server driven schedule or client initiated
synchronization.

This reduces the traffic to and from the Unwired Server. Data Change
Notification ensures that there is consistency between the EIS and the Unwired
Server CDB.
Change Reconciliation with DCN
In order to implement DCN from the EIS to the actual device, two changes must
be reconciled which include the change from the EIS to Unwired Server CDB for
refreshing the data and the change from the CDB to the client database for
synchronization.
Types of DCN
There are two types of DCN. They are Regular DCN and Workflow DCN.

The Regular DCN provides Native Mobile Application DCN functionality to

replication-based
synchronization
(RBS)
and
message-based
synchronization (MBS) clients.
The Workflow DCN (WF-DCN) provides DCN functionality to workflow
clients by extending regular DCN for MBS workflow clients.

DNC With or Without Payload

The DNC with Payload requires a JavaScript Object Notation (JSON) string,
dcn_request. This string contains one or more :upsert and :delete operations. It
directly updates the Unwired Server cache (CDB), with either of the built-in
direct cache-affecting operations such as :upsert for update or insert and
:delete.
However, the DNC without Payload instructs the Unwired Server to sync an
MBO for read operation and invokes one or more MBOs CUD operations.
DCN Backend Configuration
Regular DCN and Workflow DCN must be configured either with or without
Payload. Both these DCN types can be created through

database triggers;
EIS system events
external integration processes such as user exits and Java.

The EIS systems configuration is required to support JSON and HTTP(S). The EIS
must be enabled to send the HTTP(S) requests to the Unwired Server.
Flow: Regular DCN with RBS
The flow of regular DCN messages between the client and the RBS involves
several stages.

Initially, the EIS data associated with an MBO is updated.

Next, the EIS pushes a DCN message that contains new or changed MBO
data through configured HTTP(S) port.
The DCN service receives the message and then executes the upsert
function by updating or inserting into the CDB partitions for that
corresponding MBOs. The DCN upsert operation also sets the changed
flag of an MBO package to true.
After the modification, the Unwired Server sends a response message
back to the EIS that contains the status of each DCN in the submitted
message.
After the message is responded back to the EIS, the Unwired Server
generates a message for the client indicating that it should synchronize.
The message is then pushed from the Unwired Server to the device.
Now, the client receives the message and issues a synchronization
request to the Unwired Server.
The Unwired Server, in turn, retrieves the new or updated data based on
the client synchronization parameter and returns it to the client.

Flow: DCN with Payload

The flow of message with the DCN payload involves different stages.
1. Initially, some events initiate the DCN request. For example, a database
trigger could initiate the DCN. T
2. The Unwired Server cache or CDB could be updated directly from the EIS,
or the DCN request could originate from a source other than the EIS. The
actual data or payload is applied to the cache through either an :upsert
or a :delete operation.
3. Finally, the Unwired Server returns a DCN status message to the
requester.
Flow: DCN Without Payload
This slide depicts the flow of message in DCN without payload.
The message flow in the DCN without payload involves different stages.
1. Initially, the DCN requester sends an MBO operation execution request,
along with operation parameters, to Unwired Server.
2. Then, the Unwired Server executes the operation or the MBO operation.
It also updates the consolidated database, depending on the operation's
cache update policy.
3. Finally, the Unwired Server returns a DCN status message to the
requester.
DCN Communicaton
The DCN communication is an HTTP(S) call to the DCN port for activating a
specific servlet to notify the Unwired Server.
The default DCN port is 8000.
The call can either be a GET or POST.
The response received from the Unwired Server to the EIS can either be
ignored or processed. Before processing the DCN, the HTTP request can be
altered to utilize the existing event notifications.
To alter and filter the DCN, you can use the DCN Filter Java classes.

DCN Loggin, Sizing and Monitoring

The DCN Log

The DCN log captures data for data change notifications between an enterprise
information system (EIS) and an MBO package. There are two types of DCN log,
namely, General DCN and Workflow DCN. The general log captures information
such as time, user, package, MBO, and error. Similarly, the workflow log
captures information such as time, user, package, operation, subject, from, to,
body, and error.
Enabling/Disabling DCN Logging
You can configure HTTP logging to record request event information logged by
DCNs.
By default, the HTTP logging for DCNs is enabled, and it prints the output to
<UnwiredPlatform_InstallDir>/Servers/
UnwiredServer/logs/<server.name> http.log file.
To disable the HTTP DCN logging, you need to follow certain steps. First, open
<UnwiredPlatform_InstallDir>/Servers/UnwiredServer/
Repository/Instance/com/sybase/djc/server/ApplicationServer/$
{yourserver}.properties file. Then, delete the enableHttpRequestLog line and
save the file. After saving the file, you have to restart the Unwired Server to
reflect the changes made.
This slide displays the locations of the <server.name>-http.log file and the
{yourserver}.properties file.

Changing Post Sizing

The default size of an HTTP request is 10 MB. However, to handle larger data
change notifications, you have to stop all the Sybase Unwired Platform
services. Next, open the jetty-web.xml file and locate the Set property. Increase
the value to 100MB and then save the file. Finally, restart the Sybase Unwired
Platform services.
DCN History Statistics
DCN history statistics provides historical information for monitored packages.
The detailed data provides specific information on past notification activity for
packages.
The history statistics displays information in several categories, such as

Domain to which the package affected by the DCN belongs

Package displays the name of the package that contains data changes
MBO is the name of the MBO to which the notification applies
Notification Time is the date and time when the Unwired Server received
the DCN
Processing Time is the time that Unwired Server used to process the
DCN.

DCN Performance Monitoring Statistics

The DCN performance monitoring highlights key totals and identifies average,
minimum, and maximum values for primary activities. The calculations are
dynamic and are based on the data currently available in monitoring database
for the specified time period. The table lists the key performance indicators and
their description.
Monitoring Device History
Device Notifications can be captured and monitored using various methods:

Device Notification Statistics which provide data about the occurrence

and frequency of notifications sent from Unwired Server.
Device Notification History Statistics which provide specific information
on past device notifications, indicating which packages, synchronization
groups, and devices were involved in synchronization request server to
replication synchronization devices.
Device Notification Performance Statistics which provide a general
indication of the efficiency of notification processing and the total
demand of synchronization requests on the system.

Implementing Regular Data Change Notification

JSON Digression

JavaScript Object Notation (JSON) is a lightweight, text-based open

standard designed for human-readable data interchange.
JSON is used to serialize and transmit structured data over a network
connection.
JSON Strings can be automatically parsed or marshalled by the eval()
JavaScript function into an object.
JSON schemas can be used to verify a JSON String.
The JSON Parsers are available for many languages.

DCN URI Template

The template of a Request URI for issuing a DCN is displayed. You will also
notice the different parameters used in the template.
The cmd [dcn|wf] parameter represents the regular DCN or workflow DCN.

In the username, enter the name of the user with DCN role assigned.
In the password, enter the password.
The domain parameter refers to the name of the SUP Domain that will be
notified.
In the package parameter, you need to provide the details of the
package
name
including
version
string
in
format
package_name:version_info.
The dcn_request is the JSON string containing the operation name and
parameters.
The dcn_filter parameter is optional. It refers to the custom filter class
name used to pre-process the DCN request and post-process the DCN
status message.

Similarly, the ppm parameter is also optional. It is a Base64-encoded map of

personalization parameters.
POST or GET?
There are two HTTP methods which are allowed namely, POST and GET. All
request parameters in DCN are present either in the URI or in the POST body.
However, usage of POST is always recommended.
If you are using HTTP BASIC authentication, the JSON encoded DCN request is
always sent as the HTTP POST body.
The
syntax
of
the
HTTP
BASIC
http://<hostname>:8000/dcn/HttpAuthDCNServlet

authentication

is

dcn_request
The dcn_request parameter contains a two part JSON string, namely the
package name and message array.
The package name in the dcn_request is required for backwards compatibility.
This is generally ignored, and instead, the package name in the request URI is
used.

dcn_request Messages
Each dcn_request message includes a set of parameters:

##Message id (id) is the identification that is used to track the DCNs

sent to the Server. This value will be returned in the DCN response.
##Mobile Business Object (mbo) is the name of the MBO that should be
updated.
##Operation name or (op) is the operation that this DCN should invoke.
##Bindings (cols) is the name value pairs representing the attributes
and values of an MBO.

:upsert and :delete Operations

The two important operations of DCN are :upsert and :delete.

The :upsert operation is used to inject data into the Unwired Server
cache or CDB for a specified MBO. This operation performs in place
update or insert to the Unwired Server cache.
The :delete operation is a specially built-in DCN operation and is not the
MBOs delete operation. This operation is used to delete data from the
Unwired Server cache for a specified MBO. It performs in place delete
to the Unwired Server cache.

:upsert

The :upsert operation requires to pass the entire key attribute(s) of the MBO in
order to locate the correct row. You can also use other MBO attributes in the
:upsert operation. In the :upsert operation, all columns should use the MBOs
attribute names, and not the data source column or parameter names.
:delete

The built-in :delete operation requires to pass the entire key attribute(s) of the
MBO in order to locate the correct row.
While using the :delete operation, you have to ensure that all columns should
use attribute names instead of column names.
User-defined Operations
The User-defined MBO operation requires the name of the user-defined
operation.
For example, in the Customer MBO, createCustomer uses the CREATE
operation.
It also requires all parameters used in the MBO operation. While using the Userdefined MBO operation, all columns should use the MBO parameter name.
The User-defined operations support any type of operations such as CREATE,
UPDATE, DELETE, and OTHER.
Multiple Messages in a Single DCN
A single DCN may contain multiple messages, and each message will contain a
specific operation. For each message in the array, you get a result description
in the DCN response. To distinguish between message results, you must use
the message id.
DCN Response
Unwired Server returns a JSON string which contains a status message for each
message sent. You have to use a custom DCN filter to alter the response
representation.

The DCN response has three parts such as

recordID which is the messageID sent;

success which is displayed either as true or false;
statusMessage which is a string describing the result. You have to display
this string as empty, if success is true.

Implementing Workflow Data Change Notification

DCN for Workflows (WF-DCN) Overview
WF-DCN is very similar to Regular DCN. It sends notifications to devices to keep
the mobile workflow and the EIS in sync when a change in the EIS occurs.
You can start server-initiated workflows with a WF-DCN.
You must decide whether you will notify server-initiated device users through
the Notification Mailbox feature in the Sybase Control Center or the WF-DCN as
you cannot implement both for the same device user.
The two modifications for WF-DCN are that the cmd URI parameter is now
known as wf instead of dcn, and the message format has some new
parameters.
New WF-DCN Parameters
New parameters are added to the message so as to be compliant with the
Workflow Email Notification mechanism.

The Username or to parameter refers to the SUP user name and not the
username used to register the device.
The subject parameter refers to the workflow message.
The Originator or from parameter is the one from whom the workflow
message originates.
The Body of the workflow message or body parameter can embed
customized information.
The received is a parameter which indicates the received time of the
Mobile Workflow message.
The read parameter indicates whether the Mobile Workflow message is
read.
The priority parameter denotes whether the Mobile Workflow message
has a high priority, and
The list of dcn request or data parameter has the JSON format string as
previously seen in dcn_request.

WF-DCN Without Payload 1

The cache group policy of MBOs used in the WF-DCN without payload must be
online.
The online MBO contains the findByParameter object query with the same
parameters defined in the load operation.

The query is triggered by the workflow server-initiated starting point after

extracting the parameter values from the WF-DCN message body.
WF-DCN With Payload 1
When the EIS has new or modified data to push to Unwired Server, it initiates
an HTTP request to the WF-DCN URL. The WF-DCN message contains the new
or changed data object. When the WF-DCN message reaches Unwired Server,
the workflow engine evaluates the matching rule against all registered
workflows. If a matching rule matches this message, the workflow server
starting point for that workflow is triggered to process the message. The data
object included in the WF-DCN message is applied to the MBO CDB table by
inserting new records or updating existing records. The workflow serverinitiated starting point extracts parameter values from the message body and
triggers the MBO object query to retrieve the newly inserted or updated record.
The workflow engine converts the MBO data and WF-DCN message into a
workflow email, then pushes it to the device mobile inbox via the MOCA
protocol.
WF-DCN With Payload 2
According to the MBO cache group policy, the cache group policy of MBOs used
in WF-DCN with payload must be DCN. An example of message format is shown
in the slide.
Email Data and WF-DCN With Payload
The message must contain e-mail information such as Subject, To, and From.
Message must include Package name, MBO name, Attribute name, and
Attribute value. The message can include multiple MBOs.
Processing Messages
After Unwired Server receives the message, a matching workflow serverinitiated starting point parses the message, extracts data fields from the
message, and sets the extracted data into the parameter of an object query
operation.
Since the MBO uses an online cache policy, the object query is mapped to a
load operation. The data is then passed into the load operation as a load
parameter to trigger MBO data refresh.
WF-DCN Response
A WF-DCN Response is also a JSON string, but it differs from a Regular DCN
Response.
WF-DCN responses include two parts which are the result of processing the
Mobile Workflow request and the result of processing the general DCN
requests.

PUSH- Push Overview

Push Overview

Push is a mechanism to notify mobile clients of changes made to the cache or

CDB. Unwired Server determines when individual clients need to be notified of
data changes. Current Unwired Server push notification options for BlackBerry
is through the HTTP configured by Sybase Control Center; for Windows Mobile
and Windows, it is through the Light Weight Polling (LWP); and for iOS, it is
through the Apple Push Notification Service (APNS).
Pushable Applications

Mobile applications are modified to register for Push Notifications on the

Unwired Server; to implement a Push Listener, which is a separate application
for Windows; and to use built-in APIs for BlackBerry.
These modifications implement logic to react to Push notifications. MBS
synchronized applications are inherently pushable.

MODULE VI
Security Administration - RESUMEN
Intrusion Detection/Prevention Software
When using an Intrusion Detection or Prevention software, you should be aware
that these type of programs can cause problems in Sybase Unwired Platform.
The Personal Firewalls or Intrusion Detection or Prevention software such as
McAfee Host Intrusion Prevention can cause platform components to
malfunction or not function at all.
Unwired Server uses IP communications with all components through the
primary network interface. Therefore, any malfunction or dysfunction of the
components creates a security threat.
Platform Administration Security
For secure platform administration, you need to

enable authentication and Role Based Access Control (RBAC) for

Administrator logins;
change default certificates used for the Unwired Server and the SCCs
HTTPS listeners;
enable and configure encryption;
secure multiple domains.

Enabling Authentication and RBAC

To enable authentication and RBAC, you need to perform these steps:

First, log into the Sybase Control Center with the installation-defined user
name and password.
In the Security node of the navigation pane, click admin to make
changes to the admin security configuration and replace the
PreconfiguredUserLogin security provider.
Next, disable Authentication Caching and increase Log Levels.
Validate or test the changes made to the admin security configuration.
Finally, enable Authentication Caching and decrease Log Levels.

Definition of Installation Admin Password

During Unwired Platform installation, a password is defined for the supAdmin
super-user account. For example, you can set the password as s3pAdmin.
Sidebar: Choice of Authentication Provider 2
The Login Modules shipped with Sybase Unwired Platform include:

LDAP, which stores the users and groups in an LDAP server

CertificateValidation, which performs authentication services only

NTProxy, which allows the operating system's security mechanisms, such
as Active Directory, to validate user credentials
HttpAuthentication, which authenticates the user name and password
through HTTP or HTTPS calls to an EIS, using a GET against a URL that
requires BASIC authentication. This can be configured to retrieve a
cookie with the configured name and add it to the JAAS subject to
facilitate a single sign-on.

Sidebar: Choice of Authentication Provider 3

Additional Login Modules shipped with Sybase Unwired Platform include:

SAPSSOToken - Deprecated. You can instead use HttpAuthentication

when SAP SSO2 token authentication is required.
PreConfiguredUser authenticates the Unwired Platform Administrator
user whose credentials are specified during installation and is not for
production use.
CertificateAuthentication is used to implement SSO with an SAP
enterprise information system (EIS) with X.509 certificates. Unwired
Server does not perform any authorization. It defers authorization to an
SAP system.

Increasing Log Levels for Testing

By default, the security log level setting is INFO. For testing purpose, change
the log level to DEBUG.
Predefined Platform Logical Roles 1
Unwired Platform contains two predefined platform logical roles, namely SUP
DCN User and SUP Administrator.
The SUP DCN User role is used by the Unwired Server to authorize any DCN
event such as updating data in the cache, executing an operation, and
triggering a workflow package.
The SUP Administrator role is assigned to administrators, also referred to as
platform administrator.
The platform administrator is a superuser of the Sybase Control Center who can
perform all administrative operations.
Role Mapping 1
Logical roles have to be mapped to the Physical roles. To do this, select the
admin configuration within a domain. This is a domain-specific configuration for
the security configuration.
csi.properties and roles-map.xml

Changes implemented for the admin security configuration must be repeated

for the Sybase Control Center by editing the file called csi.properties.
Enable Caching and Decrease Log Levels
After testing the changes made in the admin security configuration, you need
to reverse these changes:

##Return the Authentication cache timeout values edited earlier, to

their original value. The default value is 3600 seconds.
##Return the Server log settings for the security component from Debug
to Warn.
At this stage, you control who can log into and administer the platform.

More About Security Configurations

Multiple security configurations can be created by the platform administrator.
The admin security profile is the default profile provided with Unwired
Platform. Other security configurations can also be added. Security
configurations include additional properties such as Settings and Audit tabs.
Security configurations are assigned to packages as part of the deployment or
post-deployment configuration. These security configurations determine how
the platform authenticates and authorizes application users.
Security Configuration Settings Properties
These are the key properties of a Security Configuration:

Authentication cache timeout defines how long authentication results

should be cached before a user is required to re-authenticate.
Maximum allowed authentication failure refers to the maximum
number of invalid login attempts after which the user is locked.
Authentication lock duration defines the time duration for which the
user is locked, after the maximum number of login attempts is reached.

Security Configuration Audit Properties

Security Configuration Audit properties are used to report all audit events to
evaluate the security system implementation for Unwired Platform. Each
successful authentication creates a session key that shows up in the
subsequent security checks for that user, which enables traceability. However,
unsuccessful authentications are also logged. Each authorization records the
roles checked, or the resource accessed.
Defining New Audit Provider
The Audit Provider can set these audit parameters:

Filters define which events are to be recorded;

Format defines the audit record format, which is currently only XML;

Audit File defines where the audit records are sent.

Audit Log Location

By default, the name of the log is default-audit.log.
Management Ports
Unwired Server has two management ports: 2000 is the unsecured port and
2001 is the secured port.
Default Security Profiles 1
During installation, two security profiles are created, namely domestic and
domestic_mutual. If you choose the domestic profile for communication, then
Unwired Server sends its certificate to the client Sybase Control Center or DCN.
The client will be configured to trust the Unwired Servers certificate. Therefore,
Unwired Server does not require a client certificate in return. Alternatively, if
you choose the domestic_mutual profile for communication, it is a two-way
stream. Both client and server exchange their certificates.
Default Certificates
During installation, the installer generates default or dummy certificates with
alias names sample1 and sample2. HTTP listeners use these default
certificates. As per the security policy, you cannot use the default certificates.
Therefore, after installing the platform, administrators must replace the default
certificates with production-ready or real certificates. Instead of replacing the
certificates associated with the sample1 or sample2 alias, you can create new
security profiles.
A security profile points to a certificate alias. The default profile points to
sample1 alias. The default_mutual profile points to sample2 alias.
Replace Default Certificates
You can create and use the new server certificates under the alias of sample1
and sample2. If you want to implement mutual authentication, you should use
the sample2 certificate. There are two different ways of creating certificates.
One method is using the PKI system
The other method of creating certificates is by using the platforms keytool
utility. This utility generates self-signed certificates.
Terminology
Keystore is the location where encryption keys, digital certificates, and other
credentials are stored for Unwired Server runtime components. Truststore is the
location where trusted certificates such as Certificate Authority (CA) certificates
are stored. Truststore is used when Unwired Platform makes an outbound
connection over SSL to another server with a server certificate. Unwired Server
checks that the server certificate is in the truststore or is signed by a CA
certificate in the truststore

SCCs Keystore / Truststore Locations

\Sybase\SCC-3-2\plugins\com.sybase.supadminplug_2.1.0\security
Securing Multiple Domains
For securing multiple domains, Sybase recommends that the Platform
Administrator

create at least one new tenant domain in the Sybase Control Center;
restrict the use of the "admin" security configuration on the "default"
domain to administration authentication only;
assign at least one domain administrator;
create and assign at least one new security configuration.

Unwired Server - MBS Devices/Apps

When you install MBS applications (including Mobile Workflow applications), an
RSA keypair is created during the platforms installation. When a device first
connects to Unwired Server, it retrieves the public key and the server uses it to
secure all future communications.
In an MBS application, you have to register the device users. Registration adds
the user name and authorization code to a whitelist. When the device connects,
it passes the user name, authorization code, and the device and application IDs
to the server. The device identified by the device ID is permanently assigned to
the user and added to the whitelist. For future communications, sessions are
initialized by using the public key.
Messaging Listener
Unwired Server - Device Push Notifications
Push notifications asynchronously notify the device that data has changed and
it needs to synchronize.
Notification methods depend on the platform.

BlackBerry uses the HTTP gateway push features of the BES. To enable
the push mechanism of BlackBerry, you have to use the Sybase Control
Center to configure the push notification from Unwired Server to each
BES Server.
iOS uses the APNS service. APNS is a server that is administrated by
Apple and requires ports 2195 and 2196 to be open in the firewall.
Android and Windows Mobile use either device tracker or lightweight
polling.

Unwired Server - RBS Devices/Apps

You can use HTTP or HTTPS in RBS applications. Developers can add end-to-end
encryption (E2EE) for added security. Everything is encrypted between device
and Unwired Server.

In RBS applications, a server keypair is created during the installation, which

has to be replaced for security reasons. Replacing these keys is performed in
the Sybase Control Center.
Replication Listeners 1
Client communications with the Unwired Server can be set up to use SSL
encryption ports.

2480 is used by RBS applications over HTTP.

2481 is used by RBS applications over HTTPS. This port is used only if
required, as HTTPS is slower than HTTP.

End-to-End Encryption
End-to-end encryption occurs when data is encrypted at the point of origin and
decrypted at the final destination. The data is always encrypted during
transmission.

Data Tier Security

Data Tier Review
The Data tier comprises multiple databases that perform a major role in the
operation of the Unwired Platform. It consists of five databases. CDB is the
default folder name of the database. It contains all types of databases, such as:

Consolidated Database or Cache Database or CDB

Cluster Database
Monitoring Database
Domain Logging Database
In the Messaging folder, you can view the Sybase Advantage Database,
which is used by the messaging database for offline devices. Sybase SQL
Anywhere Databases are made up of two files, namely the .db file and
the transaction log file.

Data Tier Security

After installing the data tier, you will secure the infrastructure and the data tier
databases. To secure the infrastructure, you will first set the file system
permissions and then secure the backup artifacts.
Next, to secure the Data Tier databases, you will initially change the DBA
password on SQL Anywhere databases.
This is done during the platform installation. After changing the DBA password,
you will encrypt the database and the log files.
Securing Database Backup Files
It is recommended to encrypt the SQL Anywhere databases and the backups,
and protect their access by providing only the Administrator and SYSTEM
accesses to them.

Securing Data Tier Databases

SQL Anywhere databases have a default user ID of dba and password of
sql.
Encrypt SQL Anywhere Databases
You can encrypt Sybase SQL Anywhere database and log files used by the
Unwired Platform data tier. These databases include consolidated or cache or
CDB, monitoring database, and domain log database.

Relay Server
RSOE Security
Device to Platform Communications
The Relay Server is the first line of defense. The devices communicate through
the Relay Server. It acts as a proxy for the device and resides in the DMZ. The
Relay Server facilitates communications with Unwired Servers residing behind
the corporate firewalls. The Web Server host on IIS or Apache that the Relay
Server resides on should be configured to use a secure port.
How It Works
The Relay Server connects to the Unwired Server through RSOE.
The RSOE notifies the Relay Server about the farm that needs to be processed.
The Relay Server maps the farm name with the appropriate RSOE and routes
the request. The Relay Server will not read or manipulate the message content.
The authentication does not take place at the Relay Server level.
Client Application Settings Example
While setting up the workflow, you will have to install the Sybase Messaging
Client and provide details such as Host name of the Relay Server, Farm ID, and
Client Plug-in.
Relay Server and Security
The clients are not authenticated or authorized by the Relay Server. It is simply
a pass-through process. If the administrator enables the highest tracing
options, data may get copied to log files.
The data is not decipherable when an end-to-end encryption is used.
Security administrators secure the Relay Server as they would with any other
Web Server.
The Relay Server requires that a signed certificate be installed in order to use
HTTPS Authentication Provider.
RSOEs

Relay Server Outbound Enablers (RSOEs) run as an Unwired Server process.

They manage communication between the Unwired Server and the Relay
Server.
To communicate with a Relay Server over HTTPS, you will either have the Web
server use a certificate signed by a CA for HTTPS or load HTTPS certificates for
the RSOE and add it to the Unwired Server node.
RSOE Properties
The RSOE connects to the Relay Server through HTTP or HTTPS. When you are
configuring the RSOE, you can switch over to the HTTP port.
Choosing a certificate is required if you specify the HTTPS (443) port.

Device Security
Device Security Overview
The multiple mechanisms that are combined to secure devices are

Built-in device security features;

Built-in Unwired Server security features for data encryption, login
screens, and data vaults;
Afaria which is a security manager channel.

Encrypting Device Data

Afaria can be used to supply full device data encryption.
The device local database can be encrypted through coding that a developer
writes in the application.
During encryption, DatabaseClass.generateEncryptionKey( ) function is called
which generates an AES-256 bit encryption key that is used to encrypt the
client database.
The client database or UltraLite database can then be encrypted by setting the
ConnectionProfile.EncryptionKey property during the application initialization
and before creating or accessing the client database.
After encryption, the encryption key is stored in the data vault.
What is a Data Vault?
A Data Vault is a local repository for sensitive data such as the encryption keys,
user login, application login credentials, synchronization profile settings, and
digital certificates. They are strongly encrypted using the AES-256 bit
symmetric program.
To access the information in the data vault, it needs to be unlocked with code
to use the application. You can make the data vault self-destruct after a set
number of incorrect pass code attempts. Data Vault is used by all the native
applications except Workflow.

Registering Application Users

Before MBS or Mobile Workflow applications can access the runtime server, the
user must be identified by first registering with Unwired Server.

If automatic registration is enabled, the device user needs to provide

valid Unwired Platform credentials that are defined as part of a security
configuration.
If automatic registration is disabled, the administrator provides the user
with a user name and activation code.
The activation code is needed for the first time to access the application.
Activation codes have an expiration time of 72 hours by default.

Subscriptions
Subscriptions determine the data set the device user receives upon
synchronization and how frequently the synchronization can occur. You can lock
the subscription to prevent the user from modifying the template and
controlling the synchronization frequency.
Application Connections
You can either lock or unlock the connections to control the users who are
allowed to synchronize data. On the Application Connections tab, select a user
and then click the Lock button to lock the user access. This is an effective way
to disable a specific user.

EIS Security
EIS - Unwired Server Communications
The EIS communicates with Unwired Server using the DCN feature. DCN uses
HTTP or HTTPS authentication providers, which prompts the user to enter a
user name and password. Administrators use the Sybase Control Center to
configure the HTTPS listener for DCNs. Developers should create the DCN
messages so that they use HTTPS. DCN authenticates all requests with the DCN
user role.
Unwired Server - EIS Communications
The Unwired Server communicates with the EIS by means of Operation Replays.
Replays are communicated depending on the EIS.

The EIS is a REST or a SOAP Web Service that uses BASIC authentication
over HTTP or HTTPS.
REST or SOAP for SAP uses BASIC/SSO2/X.509 authentication over HTTP
or HTTPS.
Whereas, JCo uses user name and password, SSO2 tokens or X.509 over
SNC. JDBC uses driver-specific mechanisms to encrypt data.

Authorization

Authorization is handled through RBAC or Role-based access control. The

logical roles are built in administrative roles and additional roles can be created
in Unwired Workspace.
You need to map the logical roles to physical roles in the Sybase Control Center.
Unwired Platform uses a role mapping feature to map logical and physical roles
during an access control check.
Logical Roles Feature
The default logical roles are SUP DCN User Role, SUP Administrator, and SUP
Domain Administrator.
Map Logical Roles in SCC 1
Once a new logical role is created, you can map the logical roles in the Sybase
Control Center. The mapping state can be set to AUTO, NONE, or MAPPED.
Mapping can be done on the domain or package level. The package mapping
overrides the domain-level mapping. The package-level mapping can also be
done during the deployment of the package in the Sybase Control Center.

MODULE VII
Monitoring and Tuning
Introduction to Monitoring
Monitoring Overview

The goals of monitoring are to provide

records of activities occurred on a server
input to server tuning and configuration
resolution for errors occurring on the server after identifying them.

What Can Be Monitored?

In the Sybase Unwired Platform environment, administrators monitor

security logs;
replication-based synchronization;
message-based synchronization;
system queue status;
data change notifications;
device notifications such as replication;
package statistics;
device users;
cache activities.

Monitoring Database
The monitoring database (monitordb.db) is one of the SQL Anywhere databases
that is created when the Data Tier node is installed.
Monitoring Profiles
A monitoring profile is available as part of the installation. The profile is named
as default and it is in disabled mode. You can configure the default monitoring
profile by selecting it and then clicking Properties. One of the parameters that
can be changed is the length of time that must pass before monitoring data is
flushed from the servers memory to the database
Configuring Monitoring Schedule
After selecting the domains and packages, you can schedule the monitoring by
using the options in the Schedule tab. By default, monitoring is scheduled to
Always On. To change the schedule, select Run Once or Custom. You need to
enter the Start date and the End date for the monitoring process. Also, you
need to specify the start and end time at which the monitoring will start and
end. If you choose Custom and if you did not provide the start and end date
and time, the Server will consider it as Always On.

Monitoring Configuration
Using the options in the Monitoring Configuration dialog box, you can configure
the monitoring profile based on your business needs. Auto-purge removes data
from the monitoring database.
To enable auto-purge, select the Enable auto-purge configuration option and
enter the number of days that data should be removed from the database.
Enabling flush threshold will automatically flush the monitoring data from the
servers memory to the monitoring database on an interval of every 5 minutes.
You can either enable or disable the auto-purge and flush threshold. When
enabling the flush threshold, you need to set the time interval and the number
of rows.
Enabling/Disabling Monitoring Profiles
Newly created profiles are not automatically enabled. You need to manually
enable them

Statistics
Security Log Monitoring
Security Log Monitoring in SUP is used to monitor user authentication.
The Security Log tab shows the user authentication history. On the Security Log
tab, you can view and analyze the connection or authentication errors for a
range of time periods.
Filtering the Security Log
. Entries can be sorted based on users, security configuration, time, and
package name.
Monitoring Data Categories
The Replication and Messaging tabs contain options to monitor replicationbased synchronization data. The Replication tab contains three subtabs:

The Current tab displays information on the current state of an object

or checks for abnormal conditions such as blocked data request.
The History tab displays completed data requests.
The Performance tab accumulates the history for calculating
performance data.

RBS Current Data

On the Replication tab, the Current subtab displays information on application,
package name, entity, synchronization start time, and username. Similar to
Security Log, you can filter data in the Replication tab. This tab is the first place
to begin when troubleshooting is an issue.

RBS History Data 1

After the RBS request is complete, the application information moves from the
Current to the History tab.
On the History tab, you can view summary and detail views.
The summary includes information about the user, package, number of rows
synchronized, total operations replayed, total bytes sent and received, total
synchronization time, and total errors.
RBS History Data 2
RBS History Filtering
RBS History data can be viewed by filtering the data. Data is filtered based on
domain and packages within a domain. The amount of history information
depends on the settings in the monitoring profile.
Performance Data
The performance tabs list the Key Performance Indicators or the KPIs.
KPIs help to identify system or application bottlenecks or problem areas.
Administrators should review the KPIs for high-level details, and then move on
to history details to further investigate performance or error conditions.
The KPI calculations are dynamic and are based on the data currently available
in the monitoring database.
Replication tab displays totals of key performance indicators.
On the Replication tab, you can filter by domain and by package within a
domain.
Enter the start and end dates for filtering, and then click Retrieve to display the
monitoring data for performance.
MBS Current Data
MBS has three subtabs, namely Current, History, and Performance. The Current
tab displays key metrics information such as package, user, message type,
import, replay, and subscribe, entity, and start time. The filtering capabilities
are same as for RBS messages.
MBS History Data
Similar to RBS history data, data from current subtab moves to the history
subtab. Here the Message Type is analogous to RBS Phases. The Message Type
IMPORT is data payload message from server to client, and all other types, like
REPLAY, are client to server.
Message Queue Size

Data Change Notification (DCN) Data

The Data Change Notification tab allows you to troubleshoot and diagnose
performance issues such as the unacceptable Processing Time to update the
CDB.
Statistics such as this help to identify which packages take the longest time to
process data changes and the peak performance or strain times on the system
Device Notification Monitoring Data
The Device Notification tab provides information on the occurrence and
frequency of notification sent from Unwired Server to RBS devices. .
The historical data includes packages, synchronization groups, and devices
affected by RBS requests in a given time frame.
Cache Statistics Data
The Cache tab is the last tab in the Monitoring area. It displays data on cache
hits, misses, average wait time and refresh times. It helps to drill down to
different levels that include

Domain level
Package level
MBO level
Cache group level.

Too many cache misses may dictate the need to change the refresh schedule.
Exporting Data
Every tab in the monitoring process has the export option. Any of the
monitoring data can be exported as either XML or CSV files.
Defining a Performance Analysis Strategy
When defining a performance analysis strategy, know the specifics from users
regarding their perceptions of performance. Statements such as "Everything
runs slow are unacceptable. Determine specifics of a problem, such as:

Event;
Function;
Process;
Technique.

Prioritize performance issues by identifying areas where performance impedes

the user and take small steps to resolve performance problems, whereby
resolving the biggest payoff issues first.
Caution
When doing performance tuning, you need to be cautious on certain factors.
They are:

Avoid too many changes at once.

Avoid solving a problem in a way that will be difficult to maintain.
Know when to re-design instead of trying to continually tune a poorlywritten application.

Tuning: Areas To Look At

The components that you may need to tune are:

Number of RSOEs;
Increase shared memory of Relay Servers;
Unwired Server;
Data Tier;
Connectivity to the EIS;
Native or Workflow application.

Relay Server Outbound Enablers (RSOEs)

While tuning for performance, RSOE is the first area that has to be checked.
RSOEs provide an Unwired Server with an upload or download channel to the
Relay Server. Sybase recommends you to create three RSOEs for each
Messaging port (5001) and Replication port (2480). Manual configuration of
RSOE creates only one per port. The Quick Configure option will create three
RSOEs for each port.
Relay Server Shared Memory
The next area to be tuned for performance is the Relay Server shared memory.
After installation, a default of 10MB memory is set for the relay server shared
memory. A production environment is recommended to have a minimum of
2GB shared memory.
Server Replication Settings
The server replication settings include the thread count and the cache size.
The thread count controls the number of threads servicing devices during
synchronization. These thread counts affect CPU usage of both server and data
tiers. If they are set too high, the server and data tier CPU usage will be high
and if they are set too low, parallel requests may not be possible. Hence it is
recommended to have 12 per cluster node whereas 10 is the default.
Synchronization cache size is the maximum amount of memory the server uses
to hold table data related to synchronization. If the amount of data the server
has exceeds this size, the data is written to disk. Again, this is recommended to
be 1GB and is 50MB by default.
Server JVM Settings
In the Server configuration, the heap size of JVM has to be set. The Minimum
Heap Size of the memory allocated to differencing and cache management
functions of the server are recommended to be 2GB which is by default 512MB.

The Maximum Heap Size of JVM is recommended to be 4GB which is by default

2048MB. This should be done for every server node in the cluster. Ensure to
restart the servers after making these changes.
Assess Impact of Changes
Every time you make changes to the server configuration properties, you
should assess the impact of those changes.

Test the impacts without testing through the Relay Server. Ascertain the
maximum throughput of the Unwired Server and the cache database
alone.
Using a tool like Process Monitor, determine if JVM memory settings were
adequate and if the Data Tier servers CPU load is too high because of
the allocation of too many threads.
Iteratively test access by changing the thread count until low response
times are found for the same number of clients.
Re-introduce the Relay Server and test again.

Disk Configuration of SA Databases

One of the options while installing the data tier is to specify separate locations
for database and transaction log files. This option affects performance and
should be enabled. The log file gets the most activity and should be on a
Storage Area Network or SAN infrastructure with write-ahead caching and highspeed disk spindles.
Messaging Tuning
While tuning messages, one Unwired Server can handle 70 messages per
second to devices. Adding a second node to the cluster will provide an
additional 60% increase in delivery capability.
Package Tracing
Synchronization tracing, though good for troubleshooting and development and
testing, has a negative impact on performance as it adds on to the log space.
Disable synchronization tracing unless absolutely necessary.
Terms Review
Important terms that need to be reviewed are EIS, CDB, Device-local database,
data refresh and synchronization.

EIS or Enterprise Information System is a Back-end data source.

CDB or Consolidated Database is a Sybase Unwired Servers cache
database.
Device-local database is the local database for RBS applications.
Data Refresh is the process of updating the CDB from the EIS.
Synchronization is the process of updating the device-local database
from the CDB. The synchronization involves an upload or download
process. For example, a device user updates a customer. The update( )

operation is replayed on the server, which updates the CDB and uploads
that change to the EIS. Afterwards, the EIS downloads any changes to
the CDB which is uploaded to the device-local database.
Initial Synchronization Process
Initial synchronization process follows certain steps. First, the user initiates
synchronization by including a load parameter value. This request and
parameters are then passed to the EIS. Later, the EIS returns the data to the
CDB. After returning the data to the CDB, a partition is created for that request.
Finally, the device is synchronized with data from that partition.
Subsequent Synchronizations
After initial synchronization, subsequent synchronization can occur. Initially,
subsequent synchronizations will search directly to the CDB for their data. The
CDB may be updated or refreshed depending on settings in the Cache Group.
For example, a Cache Group could have an On Demand policy along with a
Cache Interval of 10 minutes, that is, the device gets the data from the CDB
every 10 minutes. After the CDB is updated, the data in that partition of the
CDB gets updated from the EIS. Finally, the updated data is returned to the
mobile device.
Performance Strategies
Performance strategies include designing the CDB cache to refresh client
application data on-demand. It also includes creating Cache Groups that
specifies data refresh behavior for every MBO in the group.

You have to ensure that the related MBOs must be within the same
Cache Group.
Creating Synchronization groups is also a part of performance strategies,
where the mobile business objects or MBOs that are to be synchronized
as a group are identified. The related MBOs must be within the same
Synchronization Group.
Performance strategies also include working with Data change
notifications or DCNs to define how often to update data in the cache
after data changes are detected in the EIS.

Cache Group
Every Mobile Application Project contains one Cache Group named Default.
MBOs are initially placed in this group. A cache group specifies the data refresh
behavior for every mobile business object or MBO within that group.
You can create a new cache group using the Unwired WorkSpace. Once created,
MBOs can be dragged from the Default cache group into the new cache group.
Cache Group Properties
New Cache Groups can only be created in the Unwired Workspace.

On demand option is where the application logic is combined with the cache
interval to determine when a cache refresh is triggered. The cache is not
updated until a request is made of the cache and the cache has expired.
On demand Policy
The interval is a balance between the device getting stale data and the
network traffic involved in updating the cache. A higher value makes the
data more stale, a lower value would cause a delay when the client
synchronizes because the cache would be updating more often.
Warning About Cache Groups
You will notice that the default cache group is set to On Demand with a cache
interval of 0h 0m 0s.
This means that every time the client synchronizes, there will be a delay
because the cache first has to be updated. This may not be the best performing
option possible.
Cache Policies - Scheduled
You will notice the Scheduled radio button displayed in the Cache Policy tab for
setting the cache interval. The cache is refreshed when a scheduled task is
executed. The scheduled task is defined by the Unwired Server administrator in
the Unwired WorkSpace. The scheduled tasks are configured in the Sybase
Control Center. The cache can also be refreshed as per the Cache interval. The
developer must configure the cache group to be scheduled and deploy the
project before the administrator can use the Sybase Control Center to configure
the schedule.
Configuring Scheduled Refresh in the SCC
After selecting the Scheduled radio button in the Cache Policy tab, next you will
configure the scheduled refresh in the Sybase Control Center.
The administrators are provided with access to configure the details of a
scheduled refresh in the Sybase Control Center.
You will notice the Schedule repeat field in the Schedule tab. There are three
options available under Schedule repeat field such as Daily, Hourly, and
Custom. The Custom option allows you to set the schedule interval.
Cache Policies - DCN
You will next select the DCN radio button in the Cache Policy tab.
In the DCN or Data Change Notification option, the cache never expires. Data
refresh is triggered by an EIS Data Change Notification. You will notice that
under the DCN option, the cache interval fields are disabled.
Cache Policies - Online

The last option in the Cache Policy tab is Online. The Online option is used with
Mobile Workflow applications which requires access to real-time EIS data.
Mobile Workflow applications are simple request/response applications.
Hence, this option is available only for MBS. Online option bypasses
the Unwired Server cache or CDB.
Updating Client Data
Unwired Server alerts the device users to update mobile business object or
MBO data based on synchronization group and subscription settings. When
MBOs in a synchronization group are updated, users subscribed to those
synchronization groups receive either a direct data update or device
notification. The type of notification depends on which type of application is
running on the mobile device - RBS or MBS.

Updating Client Data by Application Type

If it is an MBS application, data updates are directly sent to the Message-based
synchronization or MBS clients. The change detection interval for the
synchronization group determines how often MBS applications push MBO data
to the client when cache refreshes occur.
If it is an RBS application, device notifications are sent to the Replication-based
synchronization or RBS clients. The notification delivery time is determined by
an equation. The delivery of push notification is the sum of the cache group
interval, the synchronization group change detection interval value and the
notification threshold value.
Synchronization Groups
Every Mobile Application project contains one synchronization group named
Default.
The MBOs are automatically placed in this group. Synchronization defines a
group of related MBOs in terms of their data synchronization requirements.
The synchronization groups can be created only by the developers using the
Unwired WorkSpace. When new synchronization groups are created, you have
to re-deploy the MBOs to the Unwired Server.
Creating Synchronization Groups
You will notice the New Synchronization Group window displayed prompting you
to enter the name, description and change detection interval of the newly
created synchronization group.
The Change detection interval is the frequency set in hours, minutes, and
seconds. Setting the change detection interval notifies the Unwired Server
about the data changes within the synchronization group.
If you enable the Use as default synchronization group option, any new MBOs
created will be automatically assigned to this synchronization group.
Using the New Synchronization Group
Once the new synchronization group is created, you will use this group to
assign the MBOs through drag and drop option. For example, you can drag an
MBO from the Default group and drop it in the new synchronization group. Now,
the FlightCustomer MBO can be synchronized on a different schedule than the
MBOs residing in Default.
Synchronization Developers Perspective
When developers create an application, the applications must call the
synchronize function to fetch data.
When the synchronize( ) API function is overloaded, one version takes the
name of the synchronization group to synchronize.

For example, the synchronize group named DataChangesLessOften is used to

update FlightCustomer only, whereas synchronize group named default is used
to update the rest of the MBOs such as FlightBooking, FlightList, and FlightTrips.
When the synchronize( ) API function is overloaded, it will synchronize all MBOs
in all Synchronization Groups.
Synchronize Administrators Perspective
Administrators cannot use the Sybase Control Center to create new
Synchronization groups or move MBOs between groups.
Developers must perform that function and then re-deploy the package for the
changes to be visible in the Sybase Control Center.
In the Synchronization Group tab, the administrator has to choose a
synchronization group and then click the Properties button to edit. The
administrator can change only the detection interval in the SCC.
SCC Configuration of Synch Groups
The Synchronization Group Properties can be configured in the Sybase Control
Center.
The change detection interval defines the time that push notifications are sent
if a change is detected.
The interval can be in hours, minutes, or seconds. Change detection triggers a
diff-calculation for sending data changes to subscribed clients.
These calculations can adversely affect performance. Therefore, the
administrator and developer must together determine this interval value,
before configuring it in a production environment.
Subscription Templates
You can create subscription template in the Sybase Control Center. To create a
subscription template, you have to first choose a package, and then select the
Subscriptions tab.
In the Subscriptions tab, you have to click the New button to create a new
subscription template.
Notifications to Update Client Data 1
RBS data updates occur through device notifications, in this sequence:
Initially, Unwired Server checks the cache for data updates to MBOs according
to the change detection interval configured. If there are data changes, the
server generates device notifications. Once the RBS subscription notification
threshold expires, Unwired Server delivers the device notifications to clients
subscribed to the synchronization group. Clients receive the device
notifications and synchronize data for the MBOs.

Notifications to Update Client Data 2

Administrators can use subscription templates to specify the notification
threshold for a particular synchronization group. These templates are used to
create subscriptions for device users.
For RBS devices, subscription settings ultimately determine when device
notifications are delivered. For example, assume that data for a synchronization
group is updated every two hours, but a device user's subscription indicates a
notification threshold of three hours. In such cases, Unwired Server postpones
delivering these updates for three hours.

Platform Sizing
Sizing Defined
The term Sizing refers to the activity of determining the types of hardware
required to run a platform, such as:

Network bandwidth;
Physical memory;
CPU processing speeds;
I/O capacity.

When sizing a hardware platform, the number of users and the data load on the
server should be considered.
SAP Application Performance Standard
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.
The numbers describe the number of SAPS needed to accommodate the
scenarios. For more information about SAPS, visit the SAP website.
Sizing for MBS Applications
Sizing MBS applications is typically simple because they have small payloads.
The factors that impact sizing of MBS applications include:

Total number of users;

Number of workflow requests per hour;
Size of the data sent between server and device.

An MBS Scenario

Let us consider a scenario. In a vacation request approval application:

The EIS pushes a DCN to the platform which triggers a server-initiated

mobile workflow application.
The user on the device either approves or denies the request resulting in
a message sent back to the server.
Two messages are involved with this scenario namely, the DCN message
and the update message.
The payload size is 50kb.
The table lists the category, DCN response per hour, server SAPS,
memory size, number of SAPS and memory size of the Data Tier.

An RBS Scenario

Let us consider an RBS scenario. The service order management application

allows customers to place requests with a service organization. The EIS stores
information about the request, customer or contact information, and product to
be serviced.
The data structure of this request contains 1 header and 10 detail records.
Each request corresponds with 11 rows in a database. The associated customer
information is 1 header and 3 detail records; each request corresponds with 4
database rows.
The mobile user can insert, delete, and modify requests. Back-office users are
also updating the request data.
Sizing Synchronization (RBS) Applications
The two factors affecting the sizing of RBS applications, are:

DCNs with payload updating the CDB for EIS changes;

Client synchronization, including the upload and download phase.

Upload phase replays the operations to the CDB and to the EIS. In download
phase, the changes in EIS are brought back to the CDB. A sample data for a
sizing scenario is displayed on the screen.
Sizing Per RBS Scenario

You will notice sample data displayed that provides the sizing for each RBS
scenario.
The application performing 300 DCN activity client payload is categorized as
Small.
This DCN activity requires 2500 server SAPS and 3750 data tier SAPS. To
download 1000 synchronizations, the application requires 250 server SAPS and
1500 data tier SAPS. Similarly, to upload 1000 synchronizations, the application
will require 3250 server SAPS and 4500 data tier SAPS.

MODULE VIII
Maintenance and Troubleshooting
Common Maintenance Tasks
Maintenance Required
The artifacts that impact the performance of the platform are:

Caches;
Connections;
Databases;
Devices and Users;
Error history;
Logs;
Packages.

For better performance, administrators clean up these artifacts. The cleanup

can be automated and may require heavy system resources. It is
recommended to schedule the cleanup when the load on the system is
minimal.
Domain Level Scheduled Tasks
There are four domain-level scheduled tasks that the administrators should
monitor:

Subscription Cleanup removes subscriptions that are no longer

referenced by active users.
Error History Cleanup removes data related to MBO operation replay
failures.
Client Log Cleanup removes client log files that are synchronized to the
device or logs that are no longer associated with active users.
Synchronization Cache Cleanup removes logically deleted rows in the
cache that are older than the oldest synchronization time on record in
the system. It also removes unused or stale partitions in the CDB.

Enabling Domain-Level Cleanup Tasks

. Select the cleanup tasks on the Scheduled Tasks tab and then, click Enable.
These tasks can also be scheduled to run automatically.
Cleanup Task Properties
You can schedule the cleanup by selecting one of the cleanup tasks on the
Scheduled Tasks tab of the Sybase Control Center and then clicking Properties.
On the Schedule tab of the Task Properties dialog box, enter the start and end
date of the cleanup tasks. Now, select the frequency at which the cleanup

should happen from the Schedule repeat drop-down list. Finally, on the Options
tab, enter the number of days the cleanup should be preserved. This option is
applicable only for Client Log Cleanup and Subscription Cleanup tasks.
Review: Domain Log
The Domain logs provide detailed information on synchronization, such as
device notification; DCN; security, error, and connection information. They also
provide different views of information which are helpful in tuning and
troubleshooting the environment.
Package Maintenance
When the applications are updated or deleted, the corresponding packages
should be removed from the Unwired Server.
Select a domain in the navigation pane of the Sybase Control Center and
expand the Packages node. Then, select a package you wish to modify.
To remove the package from the Unwired Server, click Delete on the General
tab. The status of the package is displayed on the General tab. Select a
package and then click Disable to deactivate it.
Maintaining Connections
Similar to packages, the connection profiles will become stale or unneeded.
Administrators should ensure that the unneeded connection profiles are
deleted.
Application Connection Maintenance
Each device user has a license. When the number of device users exceeds the
number of device licenses, the server rejects the connection and stops
functioning. Therefore, you need to delete any unwanted application
connections. Sometimes, application connections are referred to as device
users.
Workflow Maintenance
Administrators can lock or remove the unwanted workflow applications. For
example, when administrators have deployed workflow application version 2
and user are working on version 2, you can remove the version 1 workflow
application which is not in use anymore.
On the General tab, select a workflow application and then click Delete or Lock.
Workflow Assignments
Apart from removing and locking the workflow applications, administrators
have to assign and unassign workflow applications to the users. To do this,
expand the Workflows node in the Sybase Control Center and then select a
workflow application. Then, on the Application connections tab, click Assign

workflow to assign users to the workflow application. To remove the users

access from the application, click Unassign workflow.
Package Error History Cleanup
The Error History Cleanup task is a domain-level scheduled task. Apart from the
scheduled cleanup, you can manually clean up the error history. In the Sybase
Control Center, expand the Packages node and then select a package. Then,
click Error Cleanup on the General tab to clean the error history for all the
MBOs of that specific package.
MBO-Level Error History Cleanup
The error history can be cleaned at the MBO level. Expand the Packages node
in the Sybase Control Center and expand a package. Then, select an object. On
the History tab, specify the start and end date and then click Clean to clean
error history for that specific object.
Operation-Level Error History Cleanup
You can clean the error history at the operation level. Expand a package in the
Sybase Control Center and expand an object. Then, select an operation. On the
History tab, specify the start and end date and then click Clean to clean the
error history for that specific operation.
Purging Cache Group Data
Administrators can purge the unused and logically deleted rows in a
synchronization cache group. Expand the Packages node in the Sybase Control
Center and then select a package. On the Cache Group tab, click Purge to
purge the selected package.
Purging Inactive Subscriptions
You can purge inactive subscriptions. This is a domain-level scheduled task.
Expand the Packages node in the Sybase Control Center and then select a
package. Then, click Purge on the Subscriptions tab. Finally, in the Purge
Subscriptions dialog box, enter the number of days for which the subscription
was inactive.
Purging Client Logs
You can purge client logs, which is part of the domain-level scheduled task.
First, expand the Packages node in the Sybase Control Center and select a
package. Then, click Purge on the Client Logs tab. Finally, in the Purge Client
Logs dialog box, enter the number of days beyond which the client logs should
be purged.
Backup of Server File System
The backup of the server file system is mandatory. A routine backup of the
Unwired Platform directory should be performed. Backups should also be
coordinated with any application changes, for example, deploying new

applications and configuration changes. If required, you can back up individual

application artifacts by performing an Export using the Sybase Control Center.
Maintenance Outside of SCC
Sybase Unwired Platform provides several command-line utilities that can be
used to perform administrative activities. It is easier to open a command
prompt and type a command instead of logging into the Sybase Control Center
and navigating across the options. By using the command-line utilities, you can
also create batch files that will perform the administrative tasks on a daily
basis.
Command-Line Utilities 1
These are the command-line utilities to perform the administrative tasks:

The Relay Server utility allows you to configure or update the relay
server.
The Relay Server utility is used to perform RSOE administration.
The Unwired Server utility applies manual configuration changes.
The Unwired Server utility reconfigures the Unwired Servers to use new
cache (CDB) properties.
The Licensing utility is used to upgrade licenses.

Command-Line Utilities 2
This slide depicts some command-line utilities:

The Synchronization Monitor utility allows you to monitor the

synchronization.
The Package Administration utility is used to deploy, delete, import, and
export packages.
The Advantage Database Backup utility allows you to back up the
database.
The Advantage Database Compression utility is used to compress the
ADS data files to increase message performance.
The Unwired Server utility is used to update specific server properties
outside of the Sybase Control Center.

Configuration Files
The configuration files contain values read by the Unwired Server at startup.
Some server components read these configuration files periodically.
Administrators can instruct the Unwired Server to read the configuration files
on demand. Some changes will require you to restart the server. Sybase
recommends that you modify the configuration files only if you cannot use the
Sybase Control Center.
sup.properties
Sup.properties is a global properties file that allows you to configure many
Unwired Server components.

LOCATION:
\sybase\unwiredplatform\servers\unwiredserver\repository\instance\co
m\sybase\sup\server\SUPServer
View of sup.properties File

You can open the sup.properties file in Notepad to view the various
configuration settings of the Unwired Server. Rather than opening the Sybase
Control Center to change the settings, you can open the sup.properties file and
make the required changes in Notepad. After editing the file, you need to
restart the server to reflect the changes made.
Using UpdateProps.bat

If you do not want to update the sup.properties file directly, you can use the
UpdateProps.bat utility to edit the settings. At the command prompt, type
updateprops nv <name of the property> = new value. This utility updates
the sup.properties file. You need to restart the server for the changes to take
effect.
Understanding SQL Anywhere Databases
SQL Anywhere databases consist of two physical files. They are the database
file and the transaction log file. The database file or the *.db file is composed of
pages of data from the database tables and index information. The transaction
log file or the *.log file contains a record of all the operations performed on the
database. If the *.db file becomes corrupted, it can be re-created by restoring
an older *.db file and applying the changes in the *.log files. The performance
increases because information is written to the log file, and the server writes to
the database file less frequently. These log files are used during
synchronization.
Preparing to Work with Databases
Before performing any administrative tasks on the database, the connections
to the SQL Anywhere database must be shut down. Therefore, in the class lab
environment, you need to shut down the generic service on the active Data
Tier machine and then re-activate only the Cluster Disk.
Location of SQL Anywhere Utilities
\sybase\unwiredplatform\servers\sqlanywhere12\bin64

The key management utilities, such as dbvalid, dbbackup, dbunload, and dbinit
are available in the BIN64 folder. The BIN32 folder has other utilities like
mlmon.
Validating SQL Anywhere Databases
Before you back up an SQL Anywhere database, you should always validate the
integrity of the database.
By using the dbvalid utility, you can check the tables, indexes, pointers, and
table spaces.
In the dbvalid utility, the c refers to the connection.
In the DBF option, you need to enter the path of the Database file.
You should also specify the username and password for accessing the
database. After validating the database components, a No errors message is
displayed. Now, your database is ready for backup.
Backup SQL Anywhere Databases
The dbbackup utility allows you to back up the database. A sample of the
database backup command is displayed on the screen. The SABackups is the
folder where the backup files are stored. If this folder is not created, the utility
creates the folder for you. Once the backup is completed successfully, a
message is displayed. While performing a backup, you need to ensure that the
backup folder is placed on a different drive or machine. You should repeat the
validation for all four of the Data Tiers SQL Anywhere databases.
This is a safety measure.
Restoring SQL Anywhere Databases
To restore the SQL Anywhere databases, you must first confirm that the Data
Tier services are stopped. SQL Anywhere comes with two database engines:

##dbeng12.exe, a personal or local engine;

##dbsrv12.exe, the server engine.

When running dbeng12, no users that are external to the machine can access
the databases. Restoring is performed with the dbeng12 engine.
SQL Anywhere Restore Scenario
Consider a troubleshooting scenario where the disk containing the main
database file *.db file crashes, but the disk containing the log files is intact.
Here, you need to restore the file and then repair or replace the disk. Next,
copy the *.db file from the latest backup to a new drive. Assuming that the
*.log files are healthy, use dbeng12 to apply the log files. If you have multiple
log files, you may need to run the dbeng command multiple times.
Rebuild SQL Anywhere Databases

Platform databases need to be rebuilt regularly. Without regular maintenance,

the database log can grow to be large and several gigabytes in size, and
performance could degrade. If you experience long shutdown times with data
services for the Unwired Platform data tier, you need to unload and reload data
with the SQL Anywhere dbunload utility. This rebuilds your database and
maintains a healthy data tier performance. Sybase recommends you to perform
this action every four to five months.
dbunload Utility
The an option combines the operations of unloading a database, creating a
new database, and loading the data back into the new database. You need to
periodically repeat the rebuild process for all four of the Data Tiers SQL
Anywhere databases.
Tasks After Running dbunload
After running dbunload, move the original database and log files, default.db
and default.log, onto another drive or machine for safekeeping. Then, rename
the new database files, default_new.db and default_new.log, to default.db and
default.log.
Controlling Log File Size
If left alone, the log files will grow indefinitely which will eventually affect
system performance.
Using a different flag such as -x with the dbbackup utility makes a backup of
the current log file and creates a new empty log file. Hence, multiple log files
have to be used for a restore operation.
Messaging Database Utilities
The messaging database backup utility is available in the Server folder. For
simplicity, add this folder in the systems path. The slide shows the directory
structure of a Data Tier machine. Server Tier machines have a different
directory structure under \UnwiredPlatform\Servers. The distinction becomes
important when recovery takes place.
Messaging Database Backup
The adsbackup.exe utility performs a backup of the messaging database.
Specify the database location and directory for the backup adsbackup.exe as
E:\Messaging\OBR\OBR.add and E:\MsgBack. Backups are performed with the
Advantage Database service running and should be performed at off-peak
hours.

Troubleshoothing
Server Logs Directory (1)
The Server Logs directory contains the log file or folder which is named as
hostname-server.log. In the Sybase Control Center, you view the log settings.

Server logs are rolled over at a configured size, that is 10 MB by default. The
configured number of files is retained after rollover, that is 10 files by default.
When you encounter a problem with the DCN, use the HTTPS log for resolution.
When you encounter a problem in synchronizing RBS applications, you can use
the Mobilink Server Error log (that is, mlsrv_err.log). The Server log contains a
set of stacked traces. You can trace the problem by date and time of error.
In the server logs directory, there are subdirectories that contain log
information
that
you
should
review
occasionally.
For
example,
DroppedMessages indicates a serious issue. You can view which device and
when a message was dropped as well as the binary message.
Windows Event Viewer
System messages are logged in the Windows Event log. Sources include

Sybase Unwired Server;

Advantage Database;
Sybase Messaging Server;
SQLANY or SQLANY64;
Sybase Control Center.

Platform Components/Sub-Systems
This slide shows where the data services are installed and implemented in a
Sybase Unwired Platform landscape.
Data Services Defined
The Data Services component of the Unwired Server has these responsibilities:

Connectivity to the back-end EIS system

Maintaining data integrity
Managing data transactions

More About DataServices Logging

The messages written to the DataServices logs tell when and if updating of
Cache groups was successful. They also contain messages to indicate when a
row was deleted.
MMS Defined
The MMS is the core and administrative component of the Unwired Server. It is
responsible for a variety of operations, such as

interaction between the device and the server;

security enforcement;
sending notification to the devices; and
runtime component management.

MMS Troubleshooting

You can troubleshoot at the system level by enabling MMS logging. The MMS
logging can be reviewed in the server logs. However, if the specific package is
known, you can enable the domain logging for that package and then review
the contents of the server log. The major drawback for a domain log
configuration is that it defaults to flushing data to the domain log every five
minutes.

To perform low-level debugging, select a Package in the navigation pane of the

Sybase Control Center. On the Settings tab, enable Synchronization Tracing.
This will enable writing the detailed information about the bug to the Server
log. You also need to check client logs and MBO error history in the Sybase
Control Center.
MBO History Review
During troubleshooting, you can review the MBO history for help. You will have
to navigate down the SCC Domains, Packages, MBOs, and Operation until you
reach the History tab to view the MBO History. In the History tab, you will be
able to view the Number of Failed Operations Replays. The History tab displays
more details of the failed operations than the Client Logs.
Messaging Component Defined
Messaging Component of the Unwired Server is responsible for the transport of
MBS messages between the Unwired Server and the device. It is a Java
Message Service (JMS) that uploads and downloads the changes between the
devices and the CDB.
Enabling Workflow Tracing
You can enable Workflow Tracing for various system components. This will trace
message activity. The workflow tracing file is called TraceConfig.xml. This slide
shows the shared storage location of the Data Tier machine.
Sample TraceConfig.xml
Levels listed in order of granularity are

All,
Trace,
Debug
Info,
Warn
Error.

The default is Info. You can view the location of the log file being displayed.
Location of Workflow Tracing Output

The TraceConfig.xml is stored in the Unwired Server\logs folder. The logs folder
contains the defined log files. You can view the log files in the logs
subdirectory folders. These log files contain information to help diagnose or
troubleshoot issues.
Blocked Workflow Messages
It is possible that the workflow messages are blocked in a queue, if the
messages are not processed for a given workflow. You can correct a blocked
message by selecting the message and clicking the Unblock button. If you
cannot unblock a message in this way, you can review the trace log file of the
workflow message. Some messages will require further attention which can be
determined from the trace logs. In the Queue Items tab, you can select a
specific workflow application and check for the status.
Locked Application Connections (Users)
You will receive an error when the workflow messages are not processed due to
the application connection or device users being locked. You can check for the
lock status of the device users. You can also select the user and click the
Unlock button to activate the user.
Locking Workflow Applications
You can prevent a person from deploying workflow applications by locking the
workflow application. It results in others not being able to redeploy the
application but does not stop users from accessing or using the application. You
can click the Lock button, if enabled, to lock a person from deploying. If
somebody tries to deploy the workflow from the Unwired Server, it throws an
error and the deployment would fail.
Cache Database (CDB) Defined
Cache Database or CDB is the runtime cache database used by the Unwired
Server. It is primarily used by RBS-type applications but can also be used by
MBS applications under certain configurations. It is an SQL Anywhere v.12
database.
Troubleshooting the CDB
CDB by reviewing the Error Log file of the CDB.
Data Tier Will Not Start
When the CDB shows a cache error, the Data Tier will not start.
You can view the reason for the error in the errorlog.txt file.
For example, when you have a corrupted transaction log file, you will have an
error stating Cannot open transaction log file. You will have to restore the
CDB log file from a backup as it helps in resolving the error.

You can locate the cache error log file in the same directory as the CDB.
Example E:\CDB
Trouble Connecting to EIS?
To troubleshoot the connections to the EIS, open the Sybase Control Center. In
the navigate pane, select Domains domain_name Connections.
Select a connection profile that has connection issues. In the connection
profiles properties, ping the connection.
If the ping fails, check the connection profiles properties and make sure that
properties like host name, user id, password, and others are correct.
If you suspect EIS is the problem, then check the EISs server logs for
communication errors. You may also find more information by using the EISs
administrator tools.
Pinging EIS Connection
You can ping the connection in the connection profiles properties. You can
enter the property values and test the connection. You will receive the Ping
successful! message if the connection is available.
Server Tier Will Not Start
If the Server Tier does not start, first open the *.lic file to confirm that the
server license has not expired.
Next, check the Windows services to determine if the Server and Data tier
services are started.
If these components are on separate machines, then you will need to check
Windows services on all machines.
You can also check the Windows Event Viewer for details if services are not
starting.
You will have to check the server log file to see if the startup got far enough to
write any information and also check for the existence of and review the
bootstrap log.
Unwired Server Bootstrap Logs
You can locate the bootstrap log files in the same directory as the Server log
file. Check the bootstrap logs first when an Unwired Server will not start.
\Sybase\UnwiredPlatform\Servers\UnwiredServer\logs
No SCC Access
If you cannot access the Sybase Control Center, make sure the Sybase Control
Center service has started and is running on the Server Tier.

Device/Client Not Connecting 1

If the device or client is not connecting, try these tasks:

Confirm that the Server and Data Tiers are running.

Verify if there are any port blocking issues or if the firewall is blocking
the access.
Ensure that the device has Internet connectivity and then try to access
the Internet through a device browser.
Check if other non-Sybase applications work on the device.
Check if other Sybase applications work on the device.
In the Sybase Control Center, in the Application Connections, check if the
device is shown as Online in the SCC and check if the device is locked.
Check client licenses to confirm that the number of client licenses has
not been exceeded.

Review Licensing Information

You can display Licensing Information by clicking on Licensing. The licensing
information can be reviewed by checking the Used device license count against
the Total device license count.
License Errors in Server Log
When the license limits are reached, errors displaying license expiration and
license maximum message appear in the server log and on the device.
Device/Client Not Connecting 2
If the device or client is not connecting when the Relay Server is not being
used, then you should check if the client application is properly configured to
access the server. For a native application, you will have to check the
connection code and confirm that the application is using the proper host
name, ports, user id, and password. For a workflow application, check the
workflow client application to confirm that it is properly configured. You should
also check the client application log for messages. Finally, try restarting the
client application and check the log.
Workflow Client Log
If you have trouble connecting the Workflow Client, you will have to check if the
workflow client is showing Connected to Server. If not, compare the clients
configuration settings to that of the Application Connection that was created in
the Sybase Control Center.
Device/Client Not Connecting 3
If the Relay Server is used and if you still find a problem, confirm that the Relay
Server service is running. You will have to check the Relay Server log file and
the IIS servers log files. You must also check if the Relay Server is configured
properly. In the rs.config file, you can set verbosity=2 to enable tracing. Check

whether the Server Tiers RSOEs are running or stopped or reporting errors. You
can look at the RSOE log files to determine the reason for the errors.
RSOE Errors
Errors can occur when starting the RSOE. If an error occurs, you can retrieve
the log file and figure out why the error occurred. This is done by clicking the
Retrieve Log button.
Sample RSOE Log
Server Tier Port References

You can use the information shown in this slide to troubleshoot server port
issues.
Data Tier Port References

The information displayed in this slide can be used to troubleshoot data tier
port issues.

SCC Port References

This slide depicts the information that you can use to troubleshoot SCC port
issues.
Other Port Reference

You can use the information shown in this slide to troubleshoot relay server and
other port issues.
Check the Domain Logs
If the server log is not helpful, you need to review the Domain log. You can see
that the error message in the Domain log is also not helpful. You have to
remember that when enabling the domain log, the five minute flush time will
not be seen immediately. On the Settings tab, click Configuration to change the
flush time. Note that the flushing log entries more often impacts server
performance.