> View Session Now

In this session, we’ll show you how easy it is to create an HTML5 application that runs on browsers, mobile devices and tablets. We’ll walk through the entire process of setting up a jQuery Mobile application hosted on Heroku that uses Database.com as it’s backend with the Databasedotcom Ruby gem.

Join us as we walk through the Apex code used to create REST services, the Play! development process in Java, and touch lightly on the use of Scala.

Features we’re considering for future releases include:

• Additional content, like developer guides, workbooks, and discussion board posts
• Tools for filtering and sorting search results
• A place for readers to leave questions, comments, and best practices on every topic

Check out Version 1 at http://docs.database.com/ and let us know what you’d like to see in your dream doc portal.

The Salesforce Mobile SDK is an open-source suite of familiar technologies—like a REST API and OAuth 2.0—that you can use to build great mobile apps. It supports three development approaches for building mobile apps: native, HTML5, and hybrid.

• Native—You can code native apps for each mobile platform (e.g., Android, iOS), taking advantage of each platform’s native capabilities.
• HTML5—You can build HTML5 apps using familiar technologies such as HTML5, CSS, and JavaScript. An HTML5 app with lightweight server-side pages typically offers the most portability (i.e., the same app can run on all platforms), but won’t be able to access native platform features.
• Hybrid—You can create hybrid apps that use a JavaScript bridge in a native container to merge the portability of HTML5 with native device capabilities, such as the camera or address book.

So how can you get started with the Mobile SDK and Database.com?

• Read Getting Started with the Mobile SDK for Android
• Read Getting Started with the Mobile SDK for iOS
• Register for the free Mobile SDK Webinar, to take place on January 26, 2012.

Dan Farina, a developer at Heroku, recently clued me in to Multicorn, a PostgreSQL 9.1+ extension for writing foreign-data wrappers in Python. Foreign-data wrappers are a mechanism for exposing external data as PostgreSQL tables, allowing that data to be queried as if it were sitting in PostgreSQL just like any other table. That little nugget of information, and Josh’s Insanely Simple Python REST Script from earlier last week, inspired me to write my first Python script – a Multicorn foreign-data wrapper (FDW) for database.com (compatible with Force.com, of course, since they share the same API).

The README has full instructions, but, in summary, once you have PostgreSQL 9.1 or higher, Python and Multicorn all installed, you can create a Remote Access app in database.com/Force.com, build the database.com FDW, install it in the system-wide Python distribution and start using it. We’ll pick up the story here assuming you have completed the steps mentioned above. First, create the Multicore extension and a ‘foreign server’ in your database:

CREATE EXTENSION multicorn;

CREATE SERVER multicorn_force FOREIGN DATA WRAPPER multicorn
OPTIONS (
 wrapper 'forcefdw.DatabaseDotComForeignDataWrapper'
);

Now you can create a table. You can list any number of fields from a database.com sobject, but field names are (currently) case-sensitive and must be quoted:

CREATE FOREIGN TABLE contacts (
 firstname character varying,
 lastname character varying,
 email character varying
) SERVER multicorn_force OPTIONS (
 obj_type 'Contact',
 client_id 'CONSUMER_KEY_FROM_REMOTE_ACCESS_APP',
 client_secret 'CONSUMER_SECRET_FROM_REMOTE_ACCESS_APP',
 username 'user@domain.com',
 password '********'
);

At this point, you can query the foreign table as if it were any other PostgreSQL table. Note that FDWs are read-only, so you won’t be able to create, update or delete records.

postgres=# SELECT email FROM contacts WHERE lastname LIKE 'G%';
NOTICE:  SOQL query is SELECT lastname,email FROM Contact WHERE lastname LIKE 'G%'
       email       
-------------------
 rose@edge.com
 jane_gray@uoa.edu
 agreen@uog.com
(3 rows)

postgres=# SELECT favorite_color FROM example
 JOIN contacts ON example.email=contacts.email
 WHERE contacts.firstname = 'Rose';
NOTICE:  SOQL query is SELECT lastname,email,firstname FROM Contact WHERE firstname = 'Rose'
 favorite_color
----------------
 Red
(1 row)

Currently, the database.com FDW is very much prototype code. The main limitation right now is that the amount of data that you can read from database.com is somewhat limited, since the JSON response is parsed into a Python object in memory. If this looks interesting, then let me know in the comments and I’ll take a look at parsing the database.com response as a stream. Alternatively, if you’re a Pythonista and you’re interested in lending a hand, feel free to fork the project on Github and get to work!

UPDATE – the FDW now uses the yaml-py module to parse the JSON stream without reading it all into memory at once, and field names are no longer case sensitive.

A Quick Review of Access Controls

The profile that you assign to a user controls basic things like when the user can log in, from where, and among other things, which database objects and fields a user can access. After that, object-specific features such as organization-wide record sharing models, role hierarchies, groups, and sharing rules determine how to share records that a user owns. If you need a refresher on these concepts and features, please read Understanding Database.com System and Data Access Controls.

Profiles, As They Were

Before the Winter ’12 release, a profile is the only feature you can use to control which database objects and fields that a profile user can access. Consequently, this leads to two unfortunate situations.

• When your organization has two very similar types of users that vary by even a single object or field permission, you need to create two different profiles to satisfy your requirement. Multiply this by five, ten, or more times, and you get what many administrators commonly refer to as “profile explosion.”
• As the complexity of your organization schema grows with more and more objects and Apex classes, each profile typically becomes unwieldy as it must account for an overwhelming number of permissions.

Permission Sets to the Rescue

With Winter ’12, permission sets let you implement and manage security policies much more efficiently than ever before. Here’s how it works.

1. You create a base level profile for each general type of user (administrator, app user, etc.), and for each profile, assign base level permissions that are common to all variations of the corresponding user type.
2. Create permission sets to handle exceptions to the base level permissions available via profiles.
3. Assign a user a profile and the permission sets that, together, provide the user with the permissions necessary to perform their job.

Here’s another way to think about the relationship between profiles and permission sets. As you create multiple apps, it becomes easier to manage additional permissions (beyond what a profile controls) when you think about permission groupings by app rather than by user. Permission sets let you implement this type of association. For example, you might have base user profile along with the PTO manager permission set to approve PTO requests.

For a more information about permission sets, take a look at the recording of the popular Dreamforce 2011 session I Love Permission Sets: A Deep Dive Into Profiles 2.0.

Enjoy!

[Cross-posted at Developerforce.com]

1) So, it’s an SDK for Database.com? – Yes and no. Even though the official name for the SDK is the ‘Database.com Java SDK’, you can use it to connect to both Database.com and Force.com/Salesforce.

2), Got it. So what is it? At the highest level, the SDK provides a JPA 2.0 interface to Database.com/Force.com. If allows any Java application to use Database.com or Force.com as their persistence/data layer and use the standard JPA interface provided by the SDK to query and update data from our platform. And the SDK is completely runtime agnostic in that you can deploy your application to a cloud environment that supports Java (e.g. Heroku), or to a local J2EE container – the SDK works in all cases. In addition to a JPA interface, the SDK also has a couple of other very important components/value adds.

3) But I can already connect my Java app to Database.com/Force.com. Why do I need the SDK? – Its true that Java applications (or any other language/platform for that matter) have always been able to integrate with Force.com using one of our APIs – for e.g. the Web Services (SOAP) API or the REST API. What’s different with the SDK is that you can now use a J2EE standard – JPA – to do the same. No WSDL/XML/JSON to parse or consume – simply use the standard ORM functionality provided by JPA and simplify and standardize your Java code. Other than the JPA provider, the SDK also has other components that provide additional value-adds to Java developers.

4) How is the SDK related to Java on Heroku? – As mentioned before, the SDK has absolutely no direct dependency on Java on Heroku. You can use the SDK no matter what you runtime environment. The only real intersection of the two is if you wanted to deploy a Java application to Heroku that used Database.com/Force.com as its persistence layer.

5) What are the various components of the SDK?

5.1) JPA Provider: The most important component of the SDK is obviously the JPA 2.0 provider. Here is quick snippet from a Java application that uses a simple ‘Album’ Entity with a Many-to-One relationship to the ‘Artist’ Entity.

@Entity
public class Album {

    @Id
    @GeneratedValue(strategy=GenerationType.IDENTITY)
    private String id;

    private String name;

    @DateTimeFormat(iso=ISO.DATE)
    @Column(nullable = false)
    private Date releaseDate;

    @ManyToOne
    @CustomField(type= FieldType.MasterDetail)
    private Artist artist;
    ....
    //Public accessor and mutator methods for the above variables
}

Anyone familiar with JPA will instantly recognize this code. JPA uses a POJO based persistence model and relies heavily on annotations – both of which you can see in the above snippet. The SDK supports most of the standard JPA annotations and adds a couple of custom ones (e.g. the ‘@CustomField(type= FieldType.MasterDetail)’ used above). Here is another small snippet of how you can query and update data from the Album entity using the SDK.

public static EntityManagerFactory emf =
                  Persistence.createEntityManagerFactory("forceDatabase");

public void saveArtistRecord(Artist artist) {
    EntityManager em = emf.createEntityManager();
    EntityTransaction tx = em.getTransaction();
    tx.begin();

    if(artist.getId()==null) {
                                em.persist(artist);
                } else {
                                artist = em.find(Artist.class, artist.getId());
                                artist =  em.merge(artist);
                }

                tx.commit();
}

public static List<Album> getAlbumsByName(String albumName) {
                if(albumName==null) {
                                throw new IllegalArgumentException("Album name cannot be null");
                }

                EntityManager em = emf.createEntityManager();

                String jpqlQuery = "SELECT a FROM Album a WHERE a.Name LIKE '%s'";
                jpqlQuery =        String.format(jpqlQuery,albumName);

                List<Album> albums = em.createQuery(jpqlQuery).getResultList();
                return albums;
}

Its all standard JPA code, including the use of JPQL (which the SDK supports) to query Database.com/Force.com data. Under the covers, the Album and Artist Entities will be mapped by the SDK to corresponding Custom Objects in the respective Database.com/Force.com Org. The SDK can even keep your data model in sync automatically. If you add a new Entity class (or a new field to an existing Entity class) and restart your application, the SDK will automatically detect these schema changes and create the custom object/field automatically in Database.com/Force.com.

5.2) OAuth and Spring Security: The SDK also has an OAuth component that lets you delegate the authentication and authorization for your Java web app to Salesforce. You only have to configure a couple of OAuth parameters (not a single line of code required) and every time a user tries to access your Java app they will be redirected to Salesforce to login and then redirected back to your Java app. The SDK also includes a Spring Security plugin that “wraps” this OAuth component and lets you delegate security for Spring MVC apps to Salesforce.

5.3) Maven Code generation plugin: Though not technically part of the SDK, I still see this as another component of the SDK. If you have your data model already defined in Database.com/Force.com using some Standard and/or Custom Objects, you can run a simple Maven command and generate the corresponding JPA Entity classes. This cuts down on your development time significantly.

6) This all sounds great! How do I get started? Check out the SDK’s home page for additional details and to get started. You can also watch a recording of the Dreamforce session where I previewed the SDK.