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.

Visualizing and documenting Force.com and Database.com schemas just got a whole lot easier with the Beta availability of the new Schema Builder tool that’s accessible from each product’s primary console. To access the tool from each product’s console, click the new Schema Builder link in the App Setup menu and your off and running.

Click to enlarge this image.

Displaying Objects and Relationships

The controls in the left sidebar let you select the objects that you want to display in the canvas to the right. Use the sidebar option list to control the objects to display for selection below, and then just check the ones you want to see on the canvas. Once you pick the objects that you want to see, use the Auto-Layout button to visually reorganize them on the canvas.

Schema Builder also represents relationships among objects that are on the canvas. Lookup relationships are blue lines while Master-Detail relationships are red lines. When you hold you mouse over a particular relationship, a pop-up appears to reveal more information about the relationship.

When you close the Schema Builder with the Close button, the tool automatically saves the view of the objects you have selected for display.

Refining Your View

There are a few ways to refine the view of the objects on the canvas.

• Above the left sidebar there’s a View Options list. Use Display Element Labels/Names to toggle between field labels and API names; use Show/Hide Relationships to toggle relationship connectors on and off; and use Show/Hide Legend to toggle the display of the legend for canvas symbols.
• On the right edge of the canvas, use the zoom control to increase or decrease the field of focus of the canvas. I also found that I can use my mouse’s scroll wheel to accomplish the same task.
• On the lower right corner of the canvas, drag the focus window to the area of the canvas that you want to display.
• In the canvas itself, click a blank area and drag the canvas to pan your display.

Drilling Into Objects

While the first version of Schema Builder is read-only, we’ve provided easy methods to get to your field and object details so that you can modify them as needed. For example, you can quickly drill down into a particular object as follows.

• In the upper right corner of an object, click the icon and then View Object in New Window to display a new browser window/tab with the object’s detail page.
• Click a field label/name to display a new browser window/tab with the field’s detail page.

In either case, use the normal console techniques to modify the object or particular field.

Printing Your Diagrams

I’ve talked with many users that are looking forward to using Schema Builder as a tool for documenting their schemas. Currently, there’s no built in printing function. As a workaround, just use your favorite screen capture utility (my favorites are Shutter on Linux and Skitch on Mac).

Sending Us Feedback

This is the first release of Schema Builder, and we want it to meet your needs. So please use the link in the upper right corner above the canvas to provide us with feedback via IdeaExchange.

When you configure a Database.com security policy, you’ll start by building user profiles. The available permissions you can configure for a profile depend on the user license you associate with the profile.

For example, system administrator profiles use the Database.com Admin license, the only type of license that provides access to powerful, system-level access controls. Non-administrator profiles use the Database.com User license or the Database.com Light license. Assuming you understand the mechanisms for controlling system and data access within Database.com, here’s a quick summary of the difference between these user licenses.

• A standard Database.com User license is subject to all Database.com security controls, including authentication, profiles (system and object-level data access controls), and record sharing/row-level data access controls. When you want to leverage Database.com’s supported, scalable, fine-grained data access controls for record sharing, consider this type of user license for your app users.
• A Database.com Light user license is subject to Database.com authentication and profiles, but not to record-level data sharing controls. When your app doesn’t require record-level data access controls, or your team is comfortable with building and maintaining such controls in the application itself, then consider lower-cost light users.

In summary, with the Database.com User license, you get a powerful set of organizational structures and security mechanisms ideal for the construction of enterprise applications that have stringent security requirements. With Database.com Light, you get lower cost for applications that may be less structured or more consumer oriented.

Please see the Winter ’12 release notes for more information.

[Cross-posted at the Force.com Blogs]

TechGate, Saturday September 17 2011, brings together several of the Capital area’s finest technology user groups into one great event. I’ll be there, providing you with an under-the-hood look at the multitenancy magic that powers Database.com and Force.com, including a demo of our newly released cloud database service. And there’ll also be speakers from Amazon Web Services, Microsoft, RightScale, and many others to give you the latest scoop on various technologies. There’s sure to be something of interest for everyone.

Please feel free to ping me @databasedotcom if you have any questions. See you on Saturday.

For those of you that couldn’t attend Dreamforce 2011 and for those of you that want to relive the experience, here are a few photos from the Database.com stations in the DevZone.

* The correct quote is actually “if you build it, he will come” from the movie Field of Dreams.