Mobile solutions are becoming increasingly important in the enterprise world. Companies use them for inspections, in the warehouse, to track timesheets/travel expenses, and to access workflows and reports while on the go. Companies that do not use mobile software have a competitive disadvantage. Because of this, mobile has become one of the main priorities of SAP. With the Sybase Unwired Platform, it now has a state-of-the-art mobile framework. The SAP NetWeaver Mobile 7.1 server is an ABAP stack that you can use to mobilize SAP back-end processes such as CRM Sales or asset inspection. It was originally created to work with SAP NetWeaver Mobile client and you can still use it in this way. However, using SAP NetWeaver Mobile standalone has several disadvantages:

• Only support for Windows Laptop and Windows PDA — no support for BlackBerry, iPhone, and other devices
• No native clients — the applications are Java based and therefore limited in regards to usability and performance
• No support for data push to the mobile device

All these issues disappear when you incorporate Sybase Unwired Platform. You can support all major device types and create native solutions with full support for data push. It is simple for developers who already have SAP ERP and SAP NetWeaver Mobile 7.1 knowledge to learn how to implement mobile solutions with Sybase Unwired Platform, as the learning curve for Sybase Unwired Platform is low. However, if you choose the co-innovation architecture of SAP NetWeaver Mobile and Sybase Unwired Platform to mobilize your SAP business process, you still need to execute many manual steps. These include code generation, manual generation of the sup-db.xml, entity set definition for mobile applications (ESDMA) adaption, and message component configuration and installation. I’ll walk you through each part of the process. First, I’ll introduce you to the different connection types, synchronization mechanisms, and supported database with Sybase Unwired Platform. Then I discuss the Sybase Unwired Platform architecture before describing the steps to set up Sybase Unwired Platform. Refer to the “Considerations When Planning a Mobile Project” sidebar for some ideas of the questions you should ask your team before embarking on a Sybase Unwired Platform project.

Sybase Unwired Platform Connection Types

Before you can mobilize your enterprise system, you have to decide which connection type you want to use to access your data. The Sybase Unwired Platform offers four different ways:

• Direct database connections: You can use any database that offers Java Database Connector (JDBC) as a data source. This connection type can be used to mobilize database-driven non-SAP systems. However, you should not access SAP databases this way.
• Web services: You can read and write to Simple Object Access Protocol (SOAP) Web services to mobilize Web-service driven systems such as SAP ERP and others
• SAP Remote Function Call (RFC)/ SAP Java Connector (SAP JCo): You can connect the Sybase Unwired Platform to your SAP system via RFCs. For this communication, the Sybase Unwired Platform development tools and server use SAP JCo. This connection can call any SAP function module and read or write data to the SAP system.
• Data Orchestration Engine (DOE) connector: SAP and Sybase implemented a connector architecture that allows you to connect the Sybase Unwired Platform server with the DOE, which is SAP NetWeaver Mobile 7.1 middleware

Synchronization Mechanisms

Each of these connection types supports one or both of the following two ways to exchange data between the SUP server and the mobile client:

• Replication based: In this variant, the server database is replicated to the mobile client and back. Push of data to the mobile device is supported.
• Message based: In this scenario, the data is exchanged via messages. Every business object is sent with a separate message via a JavaScript Object Notation (JSON) string. Data is pushed from the client to the server and back whenever a network connection is available. This guarantees a seamless online/offline experience for the user.

Supported Databases

Sybase Unwired Platform supports two databases on the mobile client:

• SQL Anywhere: Sybase’s mobile database. It is available for all major mobile device platforms.
• SQLite: an open-source database with a very low footprint. It is widely used and part of applications such Mozilla Firefox, Skype, the iPhone, Android, and RIM BlackBerry.

All these variants support different client databases and synchronization mechanisms. Table 1 shows the supported combinations.  

The Landscape of the Co-Innovation Architecture

Sybase and SAP systems use three layers: back end, mobile middleware, and mobile client (Figure 1). I discuss each layer, including their components and purpose.  

Back End

The co-innovation architecture enables you to mobilize any SAP back-end system, including SAP ERP Central Component (SAP ECC), SAP Customer Relationship Management (SAP CRM), and SAP NetWeaver Business Warehouse (SAP NetWeaver BW). All SAP releases since SAP R/3 4.6C are supported. The DOE middleware needs the data from the back-end system in a specific format. Because of this, you need to implement a set of BAPI wrappers, a set of remote-enabled function modules that can send the data to the DOE correctly. I discuss these later in the article.

Middleware

The co-innovation architecture has two middleware components: SAP NetWeaver Mobile 7.1 with Mobile Gateway 1.1 and Sybase Unwired Platform Server 1.5.2 with DOE-C 1.1. To connect Sybase Unwired Platform to the SAP NetWeaver Mobile server, SAP developed SAP Mobile Gateway, which is an add-on that exchanges data via Web services with the Sybase Unwired Platform server. It uses the DOE architecture and implements its own channel to send data messages. Within the co-innovation architecture, the DOE has the following functionalities and responsibilities:

• Pulls data from an SAP back-end system by calling the back end’s BAPI wrapper or receiving it via push
• Replicates the data into the middleware’s consolidated data store (CDS). Business data is fetched from the SAP back-end system only once and not during the synchronization of each mobile device. As a result, the co-innovation architecture supports many mobile devices as well as a high data volume.
• Provides distribution rules that allow you to define which business data goes to which mobile user
• Converts the data via SAP Mobile Gateway into XML and push it to the Sybase Unwired Platform server whenever it changes in the CDS
• Receives messages from the mobile device via the Sybase Unwired Platform server
• Detects and resolves conflicts (i.e., simultaneous change of a data object on the client and the back end)

Sybase Unwired Platform Server 1.5.2 with DOE Connector 1.1

When used together with the DOE, the Sybase Unwired Platform server does not replicate data itself. Instead, it uses the DOE’s CDS. When the DOE sends a new data object, it transforms the received XML message into a JSON object and pushes it to the mobile device. If the device is currently not available because it is offline, the message is queued and sent when the device is connected again. The communication with the DOE server is handled by the DOE Connector on the Sybase Unwired Platform side.

Mobile Client

Sybase Unwired Platform does not have a mobile client that you install and that acts as a container for mobile applications as in SAP NetWeaver Mobile 7.0 and 7.1. In Sybase Unwired Platform, an application that is built on the Sybase Unwired Platform APIs can be deployed standalone. These client applications are native to the underlying operating system. This means that they have the same look and feel and behavior as other applications of this device.

Mobile Solution Development Based on the Co-Innovation Architecture

Now I will show you the end-to-end development process of a mobile solution based on the co-innovation architecture. I cover the back end, the middleware, and the mobile device (Figure 2).  

Data Objects

Before discussing the development cycle, I first need to talk about the concept of the data object. It is important to understand this concept because it affects all layers of the co-innovation architecture (backend, middleware, and client). A data object represents business data from the SAP back-end system that the DOE can consume. You have a data object definition and the data object instance. The definition is the blueprint of a data object. It describes which fields of which types a data object has. The instance is the business data with concrete values in the form of the data object definition. A data object always has a header and optional multiple child nodes. For example, a work order data object has a header that represents the order header data (e.g., order ID, description, and start and end dates). The work order data object also has multiple children (e.g., lists of jobs that need to be executed, business partners, and planned material). Figure 3 illustrates what a data object structure looks like.   Data objects can have associations to other data objects. The developer can use these associations to create distribution dependencies, which automatically download associated data objects (e.g., only download the equipment associated with a work order) and for faster and easier access to associated objects on the mobile client. The concept of the data object also exists on the Sybase Unwired Platform server and client. However, for these systems the data objects are called mobile business objects (MBOs). SAP NetWeaver Mobile 7.1 knows four different types of data objects:

• Standard: These data objects are used to exchange data between the back-end system and the mobile client
• Client only: These data objects do not exchange any data with the mobile client. They are also not connected to any BAPI wrappers. You can use them if you want to create data objects that can only hold instances on the client side. For example, this is helpful if you have temporary data or configuration settings that you want to persist on the client, but not synchronize.
• Receiver generator: You can use a receiver generator data object to create a logical device on the server. A logical device is the representation of a real device in the SAP NetWeaver Mobile system and is necessary to enable the synchronization. The receiver generator data object is helpful if you have many users and you want to create all the logical devices automatically. In this case, the data object’s BAPI wrappers are called and the returned information is used to create the logical devices. Logical devices have attributes, such as a unique device ID or the SAP user login, that allow the middleware to manage them. In addition to these standard attributes, you can use the receiver generator data object to add custom attributes. The sum of all standard and custom attributes is called the Receiver Meta Model (RMM). For example, you could add the user’s work center or the sales region to which the user is assigned. All these attributes can then be used for the distribution rules.
• Subscription generator: A subscription generator data object has the same structure as a standard data object except that its data is not sent to mobile devices. It is only used on the SAP NetWeaver Mobile 7.1 server to create associations and dependencies among data objects to allow cascading downloads to the mobile device.

SAP Back-End Development: Create a BAPI Wrapper

The business data in the middleware is stored in object form as data objects. To fetch the data from the SAP back-end system, the DOE requires function modules that deliver the data in the right format. For that reason, you need to create BAPI wrappers, which have to follow a number of rules:

• Need to be RFC enabled
• A parameter must be present in the BAPI wrapper called RETURN of type BAPIRET2. This parameter returns success, warning, or error messages.
• Parameters in a BAPI wrapper can only refer to a structure or a structure’s field
• BAPI wrappers cannot throw exceptions
• Consistency between all the BAPI wrappers must be kept when defining the export, import, and table parameters
• BAPI wrappers of type Create/Update/Delete need to implement “Commit Work and Wait”. This ensures that the processing of the BAPI wrapper is finished before it returns to the middleware.

Each data object on the DOE requires one or more BAPI wrappers, depending on what you want to do with the data. Here are the types of BAPI wrappers:

• GetList: This BAPI wrapper returns a list of header business objects in the form of a table structure. You can implement the GetList BAPI wrapper two different ways. The standard version delivers all business objects in one RFC call. If you have a significant amount of data, you should consider implementing the bulk variant, which only delivers a subset of data per RFC call. This can be better for performance and you avoid running into memory issues. For example, if you have one million pieces of equipment, you could download them 50,000 items at a time.
• GetDetail: The GetDetail BAPI wrapper has the key of the requested object as an input parameter (the DOE obtains a list of all keys from the GetList call). It returns the header for this business object as well as its child items as tables. An example is a trip (header) with its receipts and advances (child items). As you can imagine, this can lead to many RFC calls if you have many business objects. To avoid this, the DOE allows you to pass in multiple keys with one call to reduce the network overhead.
• Create: The Create BAPI wrapper receives one header and child object and saves them in the SAP back-end system
• Update: The Update BAPI wrapper has a header and its child items as input parameters and updates the corresponding business data in the SAP system
• Delete: The Delete BAPI wrapper has the key fields of the business object as input parameters. It deletes the object in the back-end system.

Before you can start any development, you need to clearly define your business process and which business data you need to have on the mobile device. This includes in which direction the data is sent: From the client from the server, from the server to the client, or in both directions. Once this is clear, you can see automatically which BAPI wrapper you need to implement for which DOE. GetDetail, Create, Update, and Delete are optional and not required for all data objects. When you implement your BAPI wrappers, keep the following in mind:

• Always try to wrap existing BAPIs from SAP to make your development release independent
• Only select the data structures and fields that are relevant for the mobile scenario. The less data you send to the middleware and client, the better.
• Try to avoid overly complex models as these can result in many expensive data joins and queries
• Determine which objects should be pushed to the mobile device

Data Pushes: Key Push and Instance Push

If you want to push data from the SAP back-end system to the middleware (and from there to the mobile device), you have two different ways to implement it. The key push uses the function module SMMW_BE_CALL_DELATS in SAP NetWeaver Mobile 7.1. This function module is called from the back end via RFC and has the business object key as a parameter. The function module also contains the data object name, which is defined in the data object’s back end adapter, and the operation (e.g., delete or update). SMMW_BE_CALL_DELATS then calls the GetDetail function module in the back end with the key as the parameter. The instance push follows a different concept. Instead of only notifying the middleware of a changed object, it sends the complete data object to the middleware. For this, the developer must create a function module in the back end that sends all the data object’s data to SAP NetWeaver Mobile 7.1. This instance push function module can internally reuse the data object’s GetDetail function module because it has to send the same data. For both versions, you need to find the right spots to trigger the push. It should always be triggered if business data that belongs to a data object in the DOE is changed, a new object is created, or an existing one is deleted.

Data Model Creation in the Data Orchestration Workbench

Once you have your BAPI wrapper created in the back-end system, you need to define the data model in the DOE. This data model contains the definition of all data that is exposed to the mobile world. It describes the data objects, which are exchanged between the back-end system, the DOE, and the mobile device. The central place for developers in SAP NetWeaver Mobile 7.1 is the Data Orchestration Workbench (transaction SDOE_WB). Here, the first step is to create a software component version (SWCV) that holds the application’s information including name, version, and vendor. The SWCV also bundles your data objects together. In addition, you can also use the Data Orchestration Workbench to define the data model and the associations among the data objects. You can start three ways:

1. Run the BAPI wrapper wizard and create your data object based on the BAPI wrappers that you already created in your back-end system (bottom-up approach).
2. Run the BAPI Wrapper wizard and create your BAPI Wrappers based on the Data Objects that you defined in the middleware (top-down approach)
3. Create a new data object and assign it manually to an existing BAPI Wrapper

If your function modules already exist, the easiest way to start is the bottom-up approach. If they are not available, you should go with the top-down approach. Figure 4 shows the DOE workbench.   The next step after creating the data objects is to create the distribution model. It consists of distribution rules, which determine which individual mobile user receives which business data. These rules also ensure that each user receives only the necessary subset of data that he really needs. The less data you send to a mobile device the better for the performance of the client and the synchronization. The simplest form of a distribution rule is a bulk rule. In this case, all data object instances are downloaded to all mobile devices. If you want to filter and restrict the data, you have to define the criteria for how data should be distributed. This should always be done to only send the absolute necessary data to each mobile device. For example, a field technician should only receive the work orders that are assigned to him, not the ones for his colleagues. You can do the distribution several ways, in which the RMM and receiver generator/subscription generator data objects play important roles:

• Use the RMM attributes to define which object goes to which device. For example, you could state “Send all work order instances to mobile devices, where the RMM attribute work center equals the work center field for the work order data object.”
• Define data patterns that allow you to download only objects from a defined date range (e.g., only the order history of the last 90 days)
• Define constant values that only synchronize work orders that have the assigned status
• If dependencies are created, you can synchronize only the associated data object instances (e.g., only synchronize those business partners assigned to a sales order)
• With extract rules, you can download a subset of data from a data object instance. This is helpful for multi-language scenarios. An example would be to create an equipment data object with a description in multiple languages, in which the description is a child node of the equipment. The goal is to send users the description only in their languages. The GetDetail BAPI Wrapper from the SAP back end downloads the description in all languages to the middleware, but the middleware extracts the languages that are not required on the mobile device and only sends the user’s language. This reduces the amount of data that needs to be synchronized.

You can create the distribution model and the rules in the Data Orchestration Workbench. In theory, you can create the distribution rules in the same SWCV as the data model, but it is best practice to create a separate SWCV for it. This separation makes it more flexible. For example, all customers use the same data model for an SAP Customer Relationship Management (SAP CRM) Sales scenario, but each customer has his own rules on how to distribute this data.

ESDMA Creation, Generation, and Download

ESDMA is a different way of looking at the same data model that I created in the previous step, this time for the outside world. Sybase Unwired Platform uses it to create the necessary structures on the Sybase Unwired Platform server and the code generation for the mobile application. Use transaction SDOE_ESDMA_DESIGN to create your ESDMA. Here you can select one or multiple SWCVs — which are the basis of your ESDMA — as well as the data objects from these SWCVs that you want to use. You can also define the default Distribution Model Software Component Version (DMSWCV) that should be assigned to the devices when they subscribe. Furthermore, you can define which fields for each data object that you want to transfer to the mobile device. Remember, the more you can reduce the amount of data, the better the performance. Within the ESDMA you can define online searches, which offer direct access to the SAP back-end system from the mobile client. For example, if you have 10 million records in a database, you do not want to download them all to a mobile device. If you can live with the fact that online searches are only available when a network connection exists, they offer a simple way to query for data directly in the back end. The ESDMA bundle that you can export from the DOE contains various files, including Web Service Definition Languages (WSDLs) and other XML documents. They describe the data object structure of the data model. Sybase Unwired Platform can generate subscriptions and receive and push data to and from DOE only when the ESDMA is available.

Adapt the ESDMA for Client Use and Sybase Unwired Platform Deployment

Before you can deploy the ESDMA to the Sybase Unwired Platform server or generate the client source code for your target device, you need to adopt the ESDMA bundle. To do this, you need to follow these steps: Step 1. Unzip the ESDMA bundle Step 2. Within the unzipped bundle, create a new subfolder called META-INF Step 3. Within the META-INF folder, create a new XML file called sup-db.xml. Add the code shown in Figure 5.

<package short-name="EXAMPLE" sup-name="EXAMPLE" version="1.0" java-package="com.sybase.example.db" cs-namespace="Sybase.Example.db" oc-namespace="example_db_"> <!-- Update with new host and port, listener.url must end with /doe/publish. --> <property value="https://10.22.118.96:8000/doe/publish" /> <database /> <database-class /> <personalization-parameter owner="client" /> <include file="afx-esdma.xml" /> </package>

Figure 5

Code that defines the ESDMA bundle properties

This code describes the following:

• How the package should be named on the Sybase Unwired Platform server (e.g., attributes name and short name)
• How the technical package or namespaces should be called in Java, C#, or Objective-C

The listener.url should point to the Sybase Unwired Platform server. With the database-specific attributes you can specify how the database file and class are called. In addition, you can specify the language that should be used as default on the mobile client. After you finish these steps, the content of the ESDMA bundle needs to be zipped again.

Sybase Unwired Platform Package Deployment

To deploy the Sybase Unwired Platform package that you created in the last section, you need a command line tool that is part of the Sybase Unwired Platform server installation. Execute the following steps: Step 1. On the Sybase Unwired Platform server, navigate to the <Sybase Unwired Platform install directory>UnwiredPlatformServersUnwiredServerdoe-c_clubin folder and execute the program CLU. When prompted, enter the command deploy. Step 2. Log in to the Sybase Control Center (SCC), the browser-based administration tool for Sybase Unwired Platform. You can find a link to it in the Windows Start menu in the Sybase group. Step 3. Check if the deployment was successful. Figure 6 shows the SCC and the successfully deployed package.  

MBO Code Generation

Now that the Sybase Unwired Platform package is deployed on the Sybase Unwired Platform server, you can generate the code for your target device. In a DOS box, navigate to the folder <Sybase Unwired Platform install directory>UnwiredPlatformServersUnwiredServerbin and execute the command esdma_converter <ESDMA directory>. This starts the ESDMA converter that transforms the ESDMA files into an AFX file. This is a new file that contains the data definition. It is located in the META-INF subfolder of the ESDMA directory. Next, you need to run the afx command. To get a full list of all available options, execute the command without options. This is a summary of the most important ones:

• -output: Specify the folder where the code should be generated
• -cs: Generate C# code for the .NET platform
• -client | -server: Generate client or service source code
• -oc: Generate Objective C code for the iPhone/iPad
• -md: Generate the MetaData class
• -vb: Generate Visual Basic source code
• -j2me | -rim: Generate code for the Java Micro Editon or for the Blackberry
• -sqlite: Generate the source code for use with the SQLite database

Device-Sybase Unwired Platform Messaging Setup

Now you have everything you need to start the development of your mobile application. However, to download test data from the server to the client running on Windows or Windows Mobile, you need to install and start a service called MOMessaging. This service is responsible for synchronizing data between the mobile client and the Sybase Unwired Platform server. Both the MOMessaging and the Sybase Unwired Platform-based mobile application access the same database and therefore interact indirectly.

Create a Messaging User in the SCC

To register your mobile device on the Sybase Unwired Platform server, you need a messaging user account, which you create in the SCC. The messaging user is only used to establish and manage the interaction between Sybase Unwired Platform and the client. It should not be confused with the SAP user account. Follow these steps to create the messaging user: Step 1. Login to the SCC and navigate to Users > Messaging Step 2. Click the Register button and enter the following information:

• User name: A new unique user name, it does not need to match the SAP user name
• Server name: The host name or IP address of the Sybase Unwired Platform server
• Activation code: This is free text and can be any string, for example 123

Install the MOMessaging Service

The installation on Windows Mobile requires you to deploy a cabinet (CAB) file. This deployed CAB adds a new application to your start menu (Sybase settings). If you launch the application, you can enter your settings. On Windows, the MOMessaging is just an .exe file. During its first launch, it reads a configuration file (Messaging.cfg) to access the connection information. You need to create this configuration file manually in the folder %APP_DATA%SybaseMOMessaging. It has the following syntax: s=<serverName>;p=<serverPort>;c=<companyID>;u=<userName>;a=<activationCode> In the above, the values represent the following:

• s = Server’s host name or its IP address
• p = The server port on which Sybase Unwired Platform is running
• c = The company ID — set this to 0 (this is for the relay server farm ID)
• u = The user name of the activation user defined in the SCC
• a = The activation code defined in the SCC

If you have defined your user in the SCC and created the property file on your mobile device, start the MOMessaging service. This registers your device at the server. To verify if this was successful you can go back to the SCC and take a look at your user. The status should now be set to online.

Mobile Application Development

The development of your mobile application depends very heavily on your target platform. As you are able to implement native applications, you can use the development environments and tools for the target operating system. Table 2 provides an overview.   Pros

• Applications have the look and feel of the target device
• Better usability
• No limitations, only the ones from the target platform
• Most of the time a better performance than interpreted solutions
• Better integration into the platform
• Easier hardware access to connect to RFID and barcode readers
• Many skilled developer for each platform available

Cons

• Application needs to be re-coded for each platform and does not run out-of-the-box on all of them
• Only one skill set required to support all platforms
• Less maintenance, as bug fixes for all platforms can be done in one codebase

It is a philosophical question whether you prefer native-developed applications or interpreted/platform-independent ones. For those who like the latter ones, Sybase Unwired Platform also allows you to create platform-independent applications. You can do this with the Sybase Unwired Platform plug-in in Eclipse, but it is not supported for the co-innovation architecture, therefore I do not cover it here.

Developing for the Windows Platform

As stated earlier, the development for the windows platform is done in C# and Microsoft’s Visual Studio. Developers have two APIs they can use to develop their application: the generated MBO code and a software development kit (SDK) that offers interfaces for commonly used functionality. Synchronized data is saved on the mobile device in the local database for offline use. This data should not be accessed directly via SQL. Instead, developers should use the generated MBO classes and their methods. Each MBO has a number of these methods (Figure 7):

• Find(string id): This method returns one instance for this MBO, which is defined by the passed-in ID
• FindAll(): This method returns all instances of the MBO
• FindWithQuery(Query query): This method allows you to query for specific instances of the MBO, which are defined by the passed query
• GetCHILDREN… : Each MBO that has child nodes has a number of methods to access these children
• Create: This method creates a new instance of the MBO on the client
• Update: An update of the MBO instance is performed when this method is called
• Delete: Calling this method on an instance of an MBO deletes it

  The SDK provides a number of services to facilitate development. This includes:

• Initialization of your application: The SDK provides a manager call that contains methods for initializing the application and to establish the messaging between the client and the Sybase Unwired Platform server
• Queries: The SDK provides an easy way to build queries for your MBOs
• Online search: Searches in the back-end system via an online search are simplified within the SDK
• Callbacks: There are a number of callbacks that developers can use. The most important are notifications of new or updated MBO instances that are received from the server via push. It is also possible to receive a callback when the device is low on storage.
• Logging: The SDK offers logging on the client, which is implemented via Log4net

The SDK recommends a client architecture for custom applications. This architecture is used in the Sybase Mobile Sales for CRM application. The SDK also contains an example application that shows how to use the services and the architecture.

Recommendations and Tips

From the first implementations with Sybase Unwired Platform, I learned several things I would like to share with you: Back end/DOE:

• Minimize the number of fields returned by the BAPI wrapper. The less data you have in the DOE database, the better for performance.
• Filter the data that is sent to the Sybase Unwired Platform server via the Mobile Gateway as much as possible by using distribution rules
• To improve performance, add associations among data objects in the DOE if you use them for data distribution

Mobile Client

• Minimize the number of objects that you instantiate to use as little memory as possible on the mobile device
• Try to always access the MBOs via their SyncKey when available
• Only load the MBO fields that you need at the time
• Frequently cache used objects, such as master data and customizing, within your application to avoid repeating the same queries multiple times