Oracle® Fusion Middleware Mobile Client Developer's Guide for Oracle Application Development Framework 11g Release 1 (11.1.1.5.0) Part Number E14826-02 |
|
|
View PDF |
This chapter provides an overview of how to set up Oracle Database Lite Mobile Server (Mobile Server) to work with ADF Mobile client so that you can publish data and synchronize data between back-end servers and mobile devices and smartphones or their respective simulators and emulators.
This chapter includes the following sections:
Section 9.1, "About Synchronizing Data with Oracle Mobile Server"
Section 9.4, "Enabling Data Synchronization at Application Startup"
Section 9.6, "Setting Up ADF Mobile Transaction Replay Service"
For general information on Mobile Server, see Oracle Database Lite Getting Started Guide.
As illustrated in Figure 9-1, Oracle Database Lite Mobile Server (Mobile Server) serves as a bi-directional data conduit between your mobile device and the base ADF application server. When synchronizing data downstream from server to device, SQL statements are executed directly against the mobile database to bring its state in line with that of the enterprise database. When synchronizing data upstream, however—from device to server—it is not safe to push the data directly through unchecked. Even though ADF Mobile client supports data validation on the device, there may be additional validation rules and business processes that must execute before the enterprise database can be safely updated with changes from the mobile device. While these validation rules and business processes can be executed immediately in the context of the base ADF Faces application, this is not the case for mobile applications, which may not have network connectivity, or which may otherwise be unable to access corporate resources. This is where ADF Mobile transaction replay service comes in. Transaction replay service encapsulates database changes in XML records known as Replay Items. Replay items are then "replayed" in the context of the base ADF Faces application and a given user so that the same validations and business processes that would normally be applied to a Web application can also be applied to an ADF Mobile client application.
ADF Mobile transaction replay service is a server-side component which provides a general mechanism for deferred execution (replay) of arbitrary server-side actions that are unavailable to a client. Clients generate Replay Items, XML records containing information about which method to call on the server and which parameters should be passed to that method. Later, those XML records are pushed back to the server, parsed by transaction replay service, and finally converted into appropriate method calls which are executed.
Mobile Server receives requests and passes data between the ADF Mobile client application and the Windows Mobile device or BlackBerry smartphone. To publish application data, you create a connection between the mobile client application and the Oracle Mobile Server Repository Schema by specifying login credentials to Mobile Server.
The credentials required to connect the mobile client application to Mobile Server are not the same as the login credentials for the database connection to the Mobile Server repository schema. The login credentials for the mobile application's connection to the Oracle Mobile Server repository schema are also used later in the deployment on the device or device emulator when you synchronize changes back to the server. These login credentials are set during the installation of Oracle Database Lite. For more information, see "Installation of Oracle Database Lite" in Oracle Database Lite Getting Started Guide.
For the publication process, you specify where data will be stored.
Application data is published for deployment to the mobile device through Mobile Server, using publications and publication items that are based on mobile entity objects.
When you deploy the ADF Mobile client from JDeveloper, ADF Mobile client automatically creates publications used by Mobile Server to determine the server-side and client-side data schemas. ADF Mobile client creates a mobile sync user as well as subscriptions to the publications. Finally, the ADF Mobile client application is deployed to the target mobile device, smartphone, emulator, or simulator. For more information, see Section 8.3, "Creating Data Sync Publications on the Server."
When a user interacts with your mobile client application in the ADF Mobile client framework, this is what happens:
The user makes changes to the data and saves.
DBTransaction.commit()
is invoked, which in turn generates appropriate DML statements for all changes to the data model.
As each statement is posted to the database, an event is fired, which in turn generates an XML record—an entity Replay Item—which encapsulates the details of the INSERT, UPDATE, or DELETE statement.
After the transaction is committed, another event is fired, which causes the previously-generated XML records to be written to the database in a separate transaction.
At some later point, data synchronization is initiated, either on-demand or in the background, and Oracle Mobile Server transfers the Replay Item(s) up to the Mobile Server instance.
Transaction replay service monitors the Replay Item queue and converts the XML records into appropriate method calls as they arrive.
These method calls effectively simulate a specific user making the same changes to the data model in the context of a standard ADF application. All standard validations and business processes are applied.
If data satisfies all necessary criteria, then it is committed to the enterprise database. Otherwise, an error is recorded in Mobile Server and then delivered to the mobile client the next time synchronization occurs.
When you import entity objects from the base ADF application into your mobile client application, JDeveloper automatically inserts additional metadata into the entity definitions to support replay-item generation at runtime. This metadata takes the form of EventPub
elements and EventDef
elements. EventDef
elements define the payload of required attributes that must be serialized into the Replay Item when an event fires. This payload can be thought of as the parameters that will be passed to transaction replay service, so that it in turn can invoke the appropriate server-side method. EventPub
elements map a named EventDef
element to an event generation point, such as CREATE
, UPDATE
, or DELETE
. By default, every imported entity object will contain three event definitions:
TRS_Delete
—This is triggered in response to the deletion of a row. The payload is comprised of just the primary key attributes.
TRS_Create
—This is triggered in response to the creation of a new row. The payload consists of all attributes.
TRS_Update
—This is triggered in response to the modification of an existing row. The payload consists of all modified attributes.
To deploy and test an ADF Mobile client application, you must provide JDeveloper with Mobile Server information. For JDeveloper, you use the Mobile Server user name, password, and host name to:
Create a database connection for Mobile Server.
Specify database credentials for an administrative user to be able to create publications and publication items for synchronizing data.
Set up a sync user and the sync user's database credentials to be used by the test application to synchronize with the server. The mobile sync user credentials you specify subscribe the mobile sync user to the publications.
For details on how to install and configure Mobile Server, see "Installation of Oracle Database Lite" in Oracle Database Lite Getting Started Guide.
Note:
A sync user cannot have two schemas on the same device.Although you can create ADF Mobile client applications that do not require synchronization because they either use a standalone database or no database at all, most ADF Mobile client applications require synchronization with a back-end database. For applications that require this type of synchronization, the ADF Mobile client runtime attempts to locate a database on the mobile device, smartphone or their respective simulators and emulators the first time that the application requires data. If the runtime is unable to find this client database, it creates one through synchronization with Oracle Database Lite Mobile Server (Mobile Server). To begin this process, the runtime prompts the end user to define synchronization credentials and various connection parameters in a dialog similar to the one shown in Figure 9-2.
After a user enters the correct values and clicks Sync, the ADF Mobile client runtime retrieves this data from the Mobile Server and creates a SQLite database instance that it stores on the mobile device or smartphone. The application continues to run after synchronization completes.
As described in Section 8.5.3, "What Happens When Oracle Database Lite Mobile Server Manages an Application's Database," if you configure the application's deployment profile to use Mobile Server, ADF Mobile client automatically uses data synchronization to populate the device's local database when you start an application for the first time. The ADF Mobile client framework requires the following to enable synchronization between Mobile Server and multiple mobile devices:
Sync username
Sync password
Mobile Server hostname/IP address
Whether to save the password
ADF Mobile client uses the following three modes for collecting these parameters at application startup. You can set these modes by selecting the Authentication Policy options in the Client Database page as described in Section 8.5.3, "What Happens When Oracle Database Lite Mobile Server Manages an Application's Database."
You activate data synchronization after your application has started by constructing a SyncOptions
object as illustrated in Example 9-1.
Example 9-1 Calling a SyncOptions Object for Provided Sync Parameters
SyncOptions options = new SyncOptions("username", "password", "http://syncserver.my.domain.com"); myAppModule.sync(options);
Constructing a SyncOptions
object enables the display of a synchronization UI and automatically initiates data synchronization with the specified parameters while displaying progress and error messages as necessary without prompting the user for credentials.
If the data synchronization operation is successful, the synchronization UI will automatically be dismissed and returns users to the previous page of the application. If any errors occurred, the synchronization UI remains visible, enabling the user to either cancel the operation or correct any issues and try again. After a successful synchronization operation, the client database has the latest changes from the server database. Those changes, however, are not reflected in the application until you refresh view objects by re-executing them.
The SyncOptions
object encapsulates the parameters required by the synchronization operation.
Username
— The sync user name.
Password
—The sync password.
Server
—The URL of the Mobile Server. For example: http://syncserver.my.domain.com
SyncProgressListener
—Enables you to specify your own UI for handling sync progress events and errors by implementing oracle.adfnmc.sync.SyncProgressListener
as illustrated in Example 9-2.
SavePassword
—Whether the password should be saved for future use; default is false
.
SyncMode
—One of the following constants, defined in oracle.adfnmc.sync.SyncOptions
, that specifies how sync credentials are to be provided:
SYNC_CREDENTIALS_MODE_PROMPT
—Prompt the user for all necessary parameters.
SYNC_CREDENTIALS_MODE_EL
—Use EL expressions which have already been populated with the required parameters. See also Table 9-2.
SYNC_CREDENTIALS_MODE_LASTUSER
—Reuse the previously saved credentials.
SYNC_CREDENTIALS_MODE_PARAMS
—The caller is providing all required parameters directly in the SyncOptions
container.
SYNC_CREDENTIALS_MODE_SAME_AS_STARTUP
—Use the same mode that was used at application startup, specified in the sync-credentials-mode
key; this value is SYNC_CREDENTIALS_MODE_LASTUSER
by default.
The user will be prompted to enter any missing values if not all of the required parameters have been provided, regardless of which SyncMode
is specified. Table 9-1 lists examples of various synchronization modes.
Table 9-1 Sync Options
Sync Mode | Example |
---|---|
Developer-Provided Credentials |
SyncOptions options = new SyncOptions("username", "password", "http://syncserver.my.domain.com"); |
User-Provided Credentials |
SyncOptions options = new SyncOptions(SyncOptions.SYNC_CREDENTIALS_MODE_PROMPT); |
Use Data Controls |
// Bind UI controls to the following expressions: // #{syncContext.userName} // #{syncContext.password} // #{syncContext.url} SyncOptions options = new SyncOptions(SyncOptions.SYNC_CREDENTIALS_MODE_EL); // When sync begins, the required parameters are read from the EL expressions above |
Use Previously Save Parameters |
SyncOptions options = new SyncOptions(SyncOptions.SYNC_CREDENTIALS_MODE_LASTUSER); |
Use Mode Specified at Application Startup |
SyncOptions options = new SyncOptions(SyncOptions.SYNC_CREDENTIALS_MODE_SAME_AS_STARTUP); |
Mobile Server notifies the application with status messages, progress, and errors as the sync operation proceeds. By default, ADF Mobile client uses oracle.adfnmc.sync.ELExpressionSyncProgressListener
to receive these events and display them in the default sync UI, but you can create your own listener by implementing oracle.adfnmc.sync.SyncProgressListener
and registering it with the SyncOptions
container. Example 9-2 illustrates a simple progress listener that logs data sync events to the console.
Example 9-2 Progress Listener
public class ConsoleSyncProgressListener implements SyncProgressListener { public void progress(String message, int progress, int phase) { System.out.println("Sync phase: " + phase + ", progress %" + progress + ", message = " + message); } } SyncOptions options = new SyncOptions(SyncOptions.SYNC_CREDENTIALS_MODE_PROMPT); options.setSyncProgressListener(new ConsoleProgressListener()); myAppModule.sync(options);
By design, SQLite employs very coarse-grained locking, so any writer must acquire an exclusive lock on the whole database. This has two implications:
There can be either multiple read-only connections or a single read-write connection to any given database.
A commit operation will succeed if there are any open cursors, but a rollback operation will not.
In a typical ADF Mobile client application, the application module owns a read-write database connection through which you indirectly access the database. When you call ApplicationModule.sync()
, this database connection is implicitly shared with Mobile Server so that it can make modifications to the client database. If sync succeeds, these modifications are committed to the database, and your application continues running. If sync fails for any reason, Mobile Server rolls back the pending changes. Because the ADF Mobile client framework may have open cursors, the rollback operation will often fail. Under such circumstances the ADF Mobile client framework does the following:
Preserves the state of the existing view object.
Disconnects from the database.
Reconnects to the database.
This effectively rolls back the Mobile Server transaction and enables the user to continue using the application as though sync had never been invoked.
You can customize the setup for mobile synchronization by creating a page that prompts users when they need to synchronize.
To equip an application with a page that tells users when they need to synchronize the application, you create an additional task flow for the application that includes the MCX file for the synchronization page itself. You then update the application task flow to point to the custom synchronization task flow.
To enable this page (the custom sync page), you must create an additional ADF Mobile client task flow as well as an MCX file using the ADF Mobile client page and task flow dialogs.
Before you begin:
Familiarize yourself with creating MCX pages and task flows as described in Chapter 6, "Creating the ADF Mobile Client User Interface."
To create the custom sync page:
Right-click the MobileClient
project and choose File then New then ADF Mobile Client and then ADF Mobile Client Page.
Create an MCX file. For example, create a page called CustomMobileSyncPage.mcx
, shown in Figure 9-3 with code similar to Example 9-3.
Example 9-3 A Custom Sync Page
<?xml version='1.0' encoding='windows-1252'?> <amc:view xmlns:amc="http://xmlns.oracle.com/jdev/amc"> <amc:form onShow="#{syncContext.MobileSyncBean.onShow.execute}"> <amc:panelGroupLayout id="home" layout="vertical"> <amc:outputText id="lblTitle" value="Custom Mobile Sync" fontWeight="bold" /> <amc:panelFormLayout> <amc:inputText id="txtUserName" label="User Name: " value="#{syncContext.userName}" /> <amc:inputText id="txtPassword" label="Password: " value="#{syncContext.password}" secret="true" /> <amc:inputText id="txtUrl" label="URL: " value="#{syncContext.url}" /> <amc:selectBooleanCheckbox id="cbSave" label="Save Password:" value="#{syncContext.saveCredentials}" /> </amc:panelFormLayout> <amc:panelGroupLayout layout="horizontal"> <amc:commandButton id="btnGo" disabled="#{syncContext.syncInProgress}" actionListener="#{syncContext.MobileSyncBean.sync.execute}" text="#{syncContext.syncLocal != true ? 'Sync' : 'OK'}" /> <amc:commandButton id="btnStop" actionListener="#{syncContext.MobileSyncBean.cancel.execute}" text="Cancel" /> </amc:panelGroupLayout> <amc:panelGroupLayout layout="horizontal"> <amc:outputText id="lblProgress" rendered="#{syncContext.syncInProgress}" value="Progress:" /> </amc:panelGroupLayout> <amc:outputText id="lblStatus" value="Status: #{syncContext.statusMessage}" foregroundColor="#{syncContext.error == null ? '#000000' : '#FF0000'}"/> </amc:panelGroupLayout> </amc:form> </amc:view>
For the page to function properly, it must include the following:
onShow
handling to reset values on the page:
<amc:form onShow="#{syncContext.MobileSyncBean.onShow}">
User name, password, and URL information are defined within inputText
components with the following values:
<amc:inputText id="txtUserName" label="User Name: " value="#{syncContext.userName}" /> <amc:inputText id="txtPassword" label="Password: " value="#{syncContext.password}" secret="true" /> <amc:inputText id="txtUrl" label="URL: " value="#{syncContext.url}" />
To save credentials, create a checkbox
component with the following value:
<amc:selectBooleanCheckbox id="cbSave" label="Save Password:" value="#{syncContext.saveCredentials}" />
To initiate the sync process, you must have the following listener tied to a control:
<amc:commandButton id="btnGo" disabled="#{syncContext.syncInProgress}" actionListener="#{syncContext.MobileSyncBean.sync}" text="#{syncContext.syncLocal != true ? 'Sync' : 'OK'}" />
To terminate the sync process (which is optional), you must have the following listener tied to a control:
<amc:commandButton id="btnStop" actionListener="#{syncContext.MobileSyncBean.cancel}" text="Cancel" />
The remaining content in Example 9-3 is optional. Table 9-2 lists the sync-related EL expressions used in this page.
Table 9-2 Sync EL Expression Reference
Expression | Description |
---|---|
|
Contains any exception that may have been thrown by a synchronization operation. |
|
Inquires if a synchronization operation is currently running. |
|
The sync user name. |
|
The sync password. |
|
Inquires if the password should be saved. |
|
The address of the Mobile Server against which to synchronize. |
|
A brief message describing the current synchronization phase (for example, sending data, receiving data). |
|
The percent complete of the current sync phase. |
Right-click the MobileClient project and choose File then New then ADF Mobile Client and then ADF Mobile Client Task Flow.
Create the bounded task flow. For example, create a task flow called custom-mobile-sync-task-flow.xml
using code similar to that illustrated in Example 9-4.
Example 9-4 The Sync Task Flow
<?xml version="1.0" encoding="windows-1252" ?> <adfc-config xmlns="http://xmlns.oracle.com/adf/controller" version="1.2"> <task-flow-definition id="custom-mobile-sync-task-flow"> <default-activity id="__1">CustomMobileSyncPage</default-activity> <view id="CustomMobileSyncPage"> <page>/CustomMobileSyncPage.mcx</page> </view> <task-flow-return id="mobileSyncSuccess"> <outcome id="__2"> <name>mobileSyncSuccess</name> </outcome> </task-flow-return> <task-flow-return id="mobileSyncFailure"> <outcome id="__3"> <name>mobileSyncFailure</name> </outcome> </task-flow-return> <control-flow-rule id="__4"> <from-activity-id id="__5">CustomMobileSyncPage</from-activity-id> <control-flow-case id="__6"> <from-outcome id="__7">toMobileSyncSuccess</from-outcome> <to-activity-id id="__8">mobileSyncSuccess</to-activity-id> </control-flow-case> <control-flow-case id="__9"> <from-outcome id="__10">toMobileSyncFailure</from-outcome> <to-activity-id id="__11">mobileSyncFailure</to-activity-id> </control-flow-case> </control-flow-rule> </task-flow-definition> </adfc-config>
Figure 9-4 shows the task flow created from the code illustrated in Example 9-4.
In the application task flow, add a task flow call that points to the sync task flow, such as CustomMobileSyncTaskFlowCall
in Example 9-5. For more information on task flow calls, see "Using Task Flow Call Activities" in Oracle Fusion Middleware Fusion Developer's Guide for Oracle Application Development Framework.
Add a control flow rule to override the toMobileSyncTaskFlow
outcome as illustrated in Example 9-6.
Example 9-6 The Override Control Flow Rule
<control-flow-rule> <from-activity-id>*</from-activity-id> <control-flow-case> <from-outcome>toMobileSyncTaskFlow</from-outcome> <to-activity-id>CustomMobileSyncTaskFlowCall</to-activity-id> </control-flow-case> </control-flow-rule>
Figure 9-5 shows the task flow override in the diagrammer.
You must set up and configure ADF Mobile transaction replay service, a server-side component that is a mechanism for replaying server-side actions that are unavailable to a client when it is offline. It parses specially formatted XML records that contain information about what method to call on the server and what parameters to pass that method. For instructions on setting up and configuring transaction replay service, see Installation Guide for ADF Mobile Transaction Replay Service.
Transaction replay service allows the changes made on a mobile device to be processed with the full validation logic and downstream trigger behavior of changes made on the server or online client. After a user makes a change on the ADF Mobile client application, ADF Mobile client automatically makes a transaction replay service Replay Record corresponding to the ADF BC changes made by the user. The Replay Item is brought to the server, either through the Mobile Server's synchronization or through the transaction replay service web service. Transaction replay service processes the Replay Item, invoking the server-side business logic corresponding to the changes made on the client.
Setup includes enabling the transaction replay service technology to the base ADF application and configuring the ADF Mobile client application's entity objects to use it as described in Section 5.8, "Enabling ADF Mobile Transaction Replay Service for an ADF Application." You also deploy the transaction replay service components to a web application server. Several transaction replay service-related wizards are available in the ADF Mobile client extension to help with this deployment and configuration.