3 Managing Your Mobile Applications

The administrator manages applications through the following tasks:

• Section 3.1, "Listing Applications"

• Section 3.2, "Publishing Applications to the Mobile Server Repository"

• Section 3.3, "Deleting an Application"

• Section 3.4, "Managing Application and Connection Properties"

• Section 3.5, "Managing User-Specific Application Parameters (Data Subsetting)"

• Section 3.6, "Managing Access Privileges for Users and Groups"

• Section 3.7, "Selecting Application Files for Public Use"

• Section 3.8, "Adding Web Application Archive (WAR) Files"

• Section 3.9, "Modifying Registry Entries"

3.1 Listing Applications

You can view all applications that are currently published on this Mobile Server from the Mobile Server home page. Click Applications. Figure 3-1 displays the Applications page, which lists existing applications and corresponding virtual paths.

Figure 3-1 Applications Page

Description of "Figure 3-1 Applications Page"

To search applications, enter your application name in the Application Name field and click Go. The Applications page displays the search result under the Application Name column.

3.2 Publishing Applications to the Mobile Server Repository

A developer builds the Mobile application and packages it together with a publication. At this point, the application is ready to be published to the Mobile Server through one of the following options:

Note:

If you developed the application on a machine remote to where the Mobile Server is installed, copy the application WAR or JAR file to this machine.

• An organizer or administrator can publish the application using the packaging wizard.

• An administrator can publish the application using the Mobile Manager from the Applications page with the Publish Application button, as shown in Figure 3-1.

3.3 Deleting an Application

To delete any application, select the application on the applications page (see Figure 3-1) and click Delete. This deletes it from the Mobile Server repository. However, because of the way Mobile Server is designed, you may wish to simply republish the application and not to delete an application.

By deleting the application, all synchronization related objects—such as publication, publication items, sequences and script definitions—are removed from the Mobile Server repository. However, the actual application tables in the back-end Oracle database are not removed.

Once the application has been deleted, existing Mobile clients can no longer synchronize for this application—ever again. Even if you were to publish the same application again, synchronizing existing Mobile clients will still fail. Instead, all transactions uploaded by the Mobile clients are placed in the error queue and require manual intervention from the administrator.

When a publication item is created, the Mobile Server assignes a unique identifier to each publication item. These unique identifiers are then used during the synchronization process to map snapshot tables on the Mobile clients to publication items and base tables on the back-end server. When a Mobile client uploads data, it uses this unique identifier to inform the Mobile Server as to which publication item this data is designated. If an application is deleted and republished, the Mobile Server uses a different set of identifiers for the publication items than the Mobile client; thus, the Mobile client and the publication item use different identifiers and the synchronization fails.

You should never delete an application if you have existing Mobile clients that still need to synchronize with the Mobile Server. If you want to modify an existing application, do not delete the application using Mobile Manager.

Instead, simply republish the application and indicate that you wish to overwrite the existing application.

3.4 Managing Application and Connection Properties

From the Applications page, you can modify application and connection properties for each application. Click on the application name to bring up its Properties page, shown in Figure 3-2.

Figure 3-2 Application Properties Page

Description of "Figure 3-2 Application Properties Page"

Table 3-1 describes the application properties that you can modify in this screen.

Table 3-1 Application Properties Page Description

Field	Description
Application Name	Name of your Mobile application.
Application Description	A brief description of your Mobile application.
Publication Name	Your application is published with a publication that contains the definition of the snapshot data for the clients. This field displays the publication name of the Mobile application. You cannot modify this field.
Platform Name	The platform name consists of the platform type and the language of the application. You can modify this platform to another type as displayed in the pull-down list.

Table 3-2 describes the following data connectivity properties that are available for OC4J or Web-to-Go applications.

• You can limit the number of connections are allowed to the database. To manage the performance and available resources of the database, you may want to set a limit of how many connections each application can have open at any given time.

• You can enable a connection pool for your OC4J or Web-to-Go application to use. Connection pools are set up for performance reasons. As each connection request comes in, a connection from the pool is used for the incoming request. When the request ends, the connection is returned to the pool. This eliminates the time necessary for creating and destroying the connections each time a new request comes in.

Table 3-2 Data Connectivity Properties

Property	Descripton
Maximum Database Connections	Number of maximum database connections used by your Mobile application.
Connection Sharing	Select Yes if you want to use connection pooling.
Database User Name	Username for the schema used by the application in the database. See Section 4.3.1.2.1, "Define Username and Password" for conventions for creating the username or password.
Database Password	Password of the schema user. See Section 4.3.1.2.1, "Define Username and Password" for conventions for creating the username or password.

To retain the modified application properties, click Apply. To remove the application, click Remove. To reset the Application Properties page, click Revert.

Alternatively, you can configure these connection parameters in the CONSOLIDATOR section in the webtogo.ora file, as follows:

• MAX_CONNECTIONS—specifies the maximum number of JDBC connections that can be open at one time by the Mobile Server.

• CONNECTION_TIMEOUT—specifies the JDBC connection timeout for the synchronization session.

You can configure for maximum concurrent clients with the RESUME_MAXACTIVE and RESUME_MAX_WAIT parameters. This limits the maximum number of concurrently synchronizing clients to RESUME_MAXACTIVE; additional incoming clients wait RESUME_MAX_WAIT before timing out. You can disable the resume feature by setting RESUME_TIMEOUT=0.

For full details, see Section 5.6, "Resuming an Interrupted Synchronization" and Section A.7, "[CONSOLIDATOR]".

3.5 Managing User-Specific Application Parameters (Data Subsetting)

In retrieving data for each user, the application often requires that a parameter is set defining the type of data to retrieve. Set this parameter, also known as data subsetting, in one of two places: on the Data Subsetting page off the Applications page or on the Data Subsetting page off the Users page. See Section 4.5, "Managing Application Parameter Input (Data Subsetting)" for directions on how to manage the input parameter values for the application from the User page.

What is Data Subsetting? When you set up your publication item, you may have set up an input parameter that defines what snapshot of data is to be retrieved for this user. For example, if you have an application that retrieves the customer base for each sales manager, the application needs to know the sales manager's identification number to retrieve the data specific to each manager. Thus, if you set up each sales manager as a unique user and set their identification number in the data subsetting screen, then the application is provided that unique information for retrieving data.

1. Navigate to the Applications page. Click the specific application.

2. Click Data Subsetting. The Data Subsetting page enables the administrator to add parameter input for each user of this application. This displays all of the users that the application is associated with.

3. Select the user for which you want to add the parameter value.

4. Enter the parameter values for the application.

5. Click Save.

3.6 Managing Access Privileges for Users and Groups

Similar to Data Subsetting, you can set the access privileges for the application either from the Users page or from the Applications page—except for groups. Groups can only be given access to applications from the Applications page. See Section 4.4.1, "Grant or Revoke Application Access to Users" for directions on how to manage the access privileges from the user page.

The Mobile Server Administrator grants access privileges to Mobile applications by designating the users that can access these applications. This section describes how an adminstrator may grant or revoke application access to users and groups:

• Section 3.6.1, "Granting Application Access to Users and Groups"

• Section 3.6.2, "Revoking Application Access to Users and Groups"

3.6.1 Granting Application Access to Users and Groups

The administrator can grant access to applications for specific users within the Mobile Manager, as follows:

1. Navigate to the Applications page. Click the specific application that you wish to modify. The Properties page appears.

2. Click Access. The Access page displays a list of users and groups for this application.

3. Select the checkbox next to each user or group that you wish to give access to for this particular application.

4. Click Save.

As Figure 3-3 displays, the Access page displays a list of available users and groups for the Sample3 application. Select the users or groups that you want Sample3 to have access to and click Save. In this example, the administrator granted access for the Sample3 application to the SampleUsers group and to the users: John, Jane, and Jack.

Note:

Once you provide access to a group, all users in that group have access to this application.

Figure 3-3 Granting Application Access

Description of "Figure 3-3 Granting Application Access"

3.6.2 Revoking Application Access to Users and Groups

To revoke application access to any user or group, clear the check box displayed against a group or user name and click Save.

3.7 Selecting Application Files for Public Use

To use the Branch Office, you install the Mobile client software on the Branch Office itself. Then, as shown in Figure 3-4, Branch Office maintains its own clients—which are not Mobile clients— by downloading the application onto its clients, which, in turn, communicate directly with the Branch Office. For an overview on what Branch Office is and how to use it, see Chapter 8, "Manage Your Branch Office". For details on setting up a Branch Office and its clients (requiring you to make certain application files public), see Section 8.2, "Branch Office Installation and Configuration".

Figure 3-4 A Branch Office Environment

Description of "Figure 3-4 A Branch Office Environment"

How do you enable the Branch Office to create its clients? The application that is to be executed on the Branch Office clients is published to the Mobile Server. The application, often an executable, that is to be installed on the client is exposed as a public file. The Branch Office downloads the public application executable and is able to install this application on its clients.

Do the following to make the application installation file public.

1. Navigate to the Applications page and click the application link. The Applications home page appears.

   Click Files. As Figure 3-5 displays, the Files page lists application files that are assigned for public use.

   Figure 3-5 Files Page

   
   Description of "Figure 3-5 Files Page"
   
   

2. Select the check box against the application file that you want made public and click Make Public

Synchronize the Branch Office, which was previously set up with the appropriate Mobile client software. This brings down the application, the data for this application, and the public application installation file.

On the Branch Office, copy and execute the application public installation file on each Branch Office client. This installs the application on each Branch Office client.

Users can download public files from the Branch Office through the following URL.

http://<client>/public/download

For full instructions and details, see Section 8.2, "Branch Office Installation and Configuration".

3.8 Adding Web Application Archive (WAR) Files

Using the Mobile Manager, you can add WAR files to your Mobile applications. In accordance with J2EE specifications, you can add Web components to a J2EE application in a package called a Web Application Archive (WAR). It contains all files that make up a Web application including other resources.

To add a WAR file, navigate to the Applications page and click the required application link. The Application Properties page appears. Click the Add WAR File link. As Figure 3-6 displays, the Add WAR File page appears.

Figure 3-6 Add WAR File Page

Description of "Figure 3-6 Add WAR File Page"

To upload the WAR file, click Browse and locate the WAR file. Click Upload. You are returned to the Add WAR File page.

3.9 Modifying Registry Entries

If you have used registry entries in the past, you can enable them in the Mobile Manager by adding the REGISTRY_TAB parameter to the webtogo.ora file. Once you have located the webtogo.ora file, enter your registry value in the REGISTRY_TAB parameter.