• Page
|
• Edit

Understanding Data Management in Adobe Flash Builder for Force.com Applications

Force.com is the industry's leading cloud computing platform. The Adobe Flash Platform is the leader in the rich Internet application space. Using both, you can deliver compelling applications that leverage the benefits of a cloud-based solution and deliver a great user experience.

In this article you will learn about the management and movement of salesforce.com data in applications built using Adobe Flash Builder for Force.com. To learn more about the technologies used to build these applications, read the technology overview article on Adobe Developer Connection.

Data Management Components

The following items comprise the key components in the management of data in applications built using Flash Builder for Force.com.

• Force.com: This is salesforce.com's industry-leading cloud-based application platform for data-centric business applications. It lets you build and deploy applications very quickly without any hardware or software infrastructure.
• Salesforce.com database: This is the main data store for all objects and associated records that are held within and managed by salesforce.com. These could be standard objects that come with the Force.com platform or custom objects that have been defined by individual customers. As a developer, you don't have direct access to this database from outside salesforce.com.
• Force.com web service: This is the SOAP-based web service API that provides access to the Force.com database. The core operations it exposes map to standard CRUD (create, read, update, and delete) actions you would require to work with the data. All of these operations require a valid "session id" which you obtain from the login operation.
• Force.com Flex framework: This is the new data access and synchronization framework that ships as part of Adobe Flash Builder for Force.com. It enables developers to easily build applications that interact with salesforce.com data using Adobe Flex and AIR. Force.com Flex builds on the client-side data management included in Adobe LiveCycle Data Services, but does not include the LCDS server-side data management functionality. Force.com Flex provides login functionality, network detection and online and offline data synchronization, a conflict resolution service, and UI components that look and act just like data input fields on salesforce.com. The developer uses the Flex for Force, or simply F3 public API to read and write records to and from salesforce.com.
• Local SQLite database: A SQLite database is embedded within the Adobe AIR runtime and provides an offline data cache of salesforce.com data.

Data Movement

In this section we'll walk through the movement of data during the life cycle of a desktop application built using Flash Builder for Force.com, that is a Force.com Flex desktop application (see Figure 1).

Figure 1. The movement of salesforce.com data in Force.com Flex desktop applications.

Application startup

When the application starts, code in the Force.com Flex framework causes a series of events to occur without any initiation or process control by the developer. First, the application asks the user for his or her salesforce.com username and password via a login window. These credentials are taken by the application and used to perform a Force.com login web service call. Upon success, a valid session is established.

Next, the application checks to see if there is already a cache of data in a local SQLite database. If there isn't, it uses the Force.com metadata web service call to pull down the schema for the objects that have been placed in a Force.com offline briefcase. (You create an offline briefcase on the salesforce.com website. It defines a subset of salesforce.com data that will be accessible from desktop applications.) the application then creates corresponding tables within the local database to hold records of those object types and a few other configuration tables. After, it uses the Force.com query web service call to retrieve all the records within those objects and store them in the local database (a full sync is performed). At this point, the application startup phase is complete and the local database and the salesforce.com database are in sync.

If the application does find a local data cache upon login, it needs to sync the data. It checks to see if there were any changes to either database while the user was offline and not connected to the Force.com cloud. If there were changes, it attempts to commit them either to the salesforce.com database or the local database accordingly (a partial sync is performed). If a record field was changed both online and offline since the last sync, a conflict resolution UI is displayed where the user can select which value to commit to both the local and salesforce.com databases.

An Internet connection must be available the first time a user runs the application so the local database can be created and populated with salesforce.com data. After this, if an Internet connection is not available at application startup time (perhaps the user has run the application while on an airplane) then the sync process is delayed until the next time a connection is available.

Data queries

Fairly soon after application startup, it's typical for an application to query for some data to be displayed to the user. To do this, the developer uses the F3 API, which exposes a query() method that retrieves data from the local database. Even when connected to the Internet, all queries are made against the local database, not the salesforce.com database. This is because there is a limit on the number of API calls that can be made to salesforce.com using web services in a 24-hour period. An application will probably make lots of queries to retrieve data so instead of using up API calls to make these queries against the Force.com cloud, the queries are made against the local database which is automatically kept in sync with the salesforce.com database by the Force.com Flex framework.

Query results can then be bound to any UI components, including Flex components like the DataGrid and Force.com Flex UI components like the LabelAndField and EntityContainer which creates a data input/output UI component (that mimics the input fields on salesforce.com) for use in a form.

Record modifications

To update records, the user needs to simply modify a property value of one of the objects. For example, the phoneNumber property of a Contact object could be set to a new string value. Then the developer just needs to call the save F3 API which commits the changes to the local database and if the user is online, to salesforce.com. If the user is offline, the application will attempt to commit the changes when the user is back online. If any conflicts are detected at that time, the conflict resolution UI is displayed.

You can also tell the application to hold off committing the changes to the Force.com cloud until later. Because of the limit on the number of API calls that can be made to salesforce.com, if the user is going to make lots of data changes (by modifying existing records or creating or deleting lots of records), you will want to initially only save the changes to the local database and then later send all the changes to salesforce.com at once with one web service call.

The process for adding records to the databases is the same as the process for modifying records except the developer must first create a new instance of the appropriate typed object class (like Contact) and then provide a UI for the user to set its properties. The same save F3 API is used to save the new records to the local database and salesforce.com as it was to update records.

Data synchronization

The developer can programmatically define the synchronization behavior of the application, e.g. provide a “Synchronize” button in the UI or automatically synchronize, e.g. every 20 minutes. If the application finds new or updated records on the client, it will make the matching updates and creations on salesforce.com. Likewise, if a record has changed on salesforce.com since the last update, it will perform the matching update in the local database. Of course, this process only occurs when a valid Internet connection is available.

Summary

In this article, you learned how data is managed and moved in Force.com Flex desktop applications between a local database on the client and the Force.com cloud. The Force.com Flex framework which is part of Flash Builder for Force.com greatly simplifies the process of synchronizing data between the two data stores and handles the detection and resolution of conflicts. This frees up the developer to instead focus on application architecture, design, and presentation and not data management. Developers can query, update, create, and delete records as if all that existed was the local database. This ability to easily build occasionally connected applications that leverage the cloud-based data platform of Force.com and the rich, presentation platform of Adobe will benefit all sorts of business applications, including field service operations, medical records, field sales management, and more.

References

• To learn more about Adobe Flash Builder for Force.com and how these type technologies work together, visit the Salesforce.com technology center in the Adobe Developer Connection, or the Adobe Flash Builder for Force.com resource page on Developer Force.
• To learn more about Force.com, visit Developer Force.
• To learn more about Flex, visit the Flex 4 and Flash Builder 4 resource page on Adobe Labs.

About the Authors

Written by Jeanette Stallons (stallons.com), edited by Markus Spohn (salesforce.com)