This is part one of a three-part series on how to build and distribute applications on

Salesforce's AppExchange.

I attended Salesforce's Dreamforce conference last month because I'd heard that Salesforce
has been making a big effort to build a platform that was friendly to developers. I expected to
be confronted with a pile of corporate-speak and a lot of vaporware, but what I found was
much more surprising. Six different keynote presenters talked about mashups, and one-third
of customers in attendance talked about wanting to build or purchase mashups. There was
some corporate-speak, which these articles should cut through. The technology, however,
was powerful and easy.

Two main things set Salesforce apart from other companies building development platforms.
The first is that their platform is entirely "on demand", meaning there's no installed software,
it runs across the internet in a software as a service model. The other is the directory of
Salesforce applications called AppExchange. You can build apps and keep them within your
organization -- if, for example, you work in a corporate IT department. But if you want to
share your application with the world, for profit or otherwise, the AppExchange directory is
the answer. It's integrated directly into all Salesforce accounts. If you build an application
inside your own account, you can package it directly to the AppExchange directory.
Customers who find your application on AppExchange can install it directly into their
accounts. Salesforce wants to remove the burden of customer acquisition and distribution so
that developers can focus on what they do best: finding and solving problems. I met a number
of small companies and individual consultants who all said that Salesforce is making it easier
to sell software to the corporate world.

This series of articles will show you how to build and distribute an application on
AppExchange. If you're not familiar with Salesforce, then there's some basic information that
you should know. I'll lay that out in this article, as well as the process for setting yourself up
as a Salesforce developer, the interfaces available for building applications, and the major
sources of news and reference. The next two articles will lead you through the steps of
building an application and distributing it on AppExchange.

What Is Salesforce.com?

If you're not in sales, you might not even know what Salesforce.com does or even what
Customer Relationship Management (CRM) is. Salesforce started out primarily offering
software for sales groups to manage their customer relationships. This included simple tools
like address books, which are called contacts in the Salesforce world, and more complicated
processes to track potential customers from lead to sale. Sales people also like reports with
charts and graphs, so those are part of the package.

The interesting point from a developer's perspective is that the underlying technology is
based around database concepts, with default actions and views. Salesforce has almost
completely opened up this infrastructure. Even novice users can create custom objects that
are the equivalent of database tables, and add or remove fields from the default objects.
This infrastructure includes a built-in customer base, built-in distribution through the
AppExchange directory, built-in data and authentication models, developer support on the
AppExchange Developer Network, and a slew of programming tools. That means developers
can focus on solving new problems and not reinventing solutions to old ones.

This infrastructure has been flexible enough to allow Salesforce to branch out into other
business applications like marketing and customer support. It has also been flexible enough to
allow customers to build their own applications in areas like financial services and human
resources.

Signing Up

To get a feel for what Salesforce customers experience, you need to sign up for an account.
This will also serve as a sandbox for developing your own applications. You might be
tempted to sign up for the 30-day, free trial offer that is prominently advertised on their home
page, but signing up for a developer account from the AppExchange Developer Network will
give you an account that never expires. The account does come with a few limitations. You
can only have two users, one an admin account so that you can build and install applications
and the other a normal user account so you can test your work from the perspective of a
normal user. The account has a 2MB data limit, which is enough space to add roughly 1500
contacts. There seem to be some other limitations--you can't send mass emails, for example--
but I didn't notice any that would hinder development.

After you sign up for an account you'll be sent a confirmation email. Following the link in the
email will give you your first look at your new Salesforce account.

Click for a larger view.

Browse the tabs to get a sense of the default functionality that comes with a Salesforce
account.

Customizing

For most Salesforce customers, customizing their Salesforce account is a common and
exciting experience that feels like application building. This functionality is available in the
Setup area. Here users can add and remove fields, customize templates, and even create new
database tables that come with automatically created forms and views. Salesforce provides a
web UI for all of this functionality.

Don't worry, as a developer you're going to be able to build applications much more powerful
than what most users are creating using the Salesforce customization forms. You should,
however, know how to use these. You will need this familiarity if you want to extend the data
schema, install AppExchange applications, or package your own AppExchange applications.

Start by clicking the Setup link located above the tabs.

Later in this article, we'll be using this area to install an application from AppExchange. For
now let's get a feel for how the Setup area works by adding a Website field to the Contacts
object, as many of our friends have their own websites.

Start by choosing Customize -> Contacts -> Fields in the left navigation bar. This will show a
long list of the standard fields for the Contacts object.

Click for a larger view.

At the bottom of the list of fields is a list of custom fields and a New button. Clicking this
button will start you on a four-step process for adding a field to the Contacts object.

The first step is to select a field type. I was expecting to make this a text field, but found that
Salesforce has an explicit URL field type that ensures that the URL will be displayed as a
link. Choose the URL field type.

The second step is to give the field a label and a name. The label is shown on displays and
reports alongside the field contents. The name is what you're going to use to reference the
field when you're writing code. I chose "Website" for the label and "website" for the name.
The last two steps are important if you're managing a Salesforce account with thousands of
users. If that were the case, you would want to spend some time setting the access controls
and templates. For our purposes, you should just choose the defaults and then save your
changes. To see your handiwork, visit the Contacts tab and click the New button. You should
see that your field has been automatically added to the form.

Installing an AppExchange Application

Before we can build our own application for the AppExchange, we need to figure out how to
install other people's applications.

The first step is to visit the AppExchange. There are over 400 applications in the directory so
far. Some of the applications require that you pay for them. Some require that you install
software on your own server. But many are completely free applications that run entirely in
your Salesforce instance. The Pricing section of each application entry will let you know if
the application is free or not.

If you see a Get It Now button then you can install the application directly into your
Salesforce account. Other applications have Download buttons instead. These are
applications that you run on your desktop or server that access your Salesforce account
through the API.

Let's install Salesforce for Google AdWords, an application that lets you create and track
Google AdWords campaigns from within Salesforce. It's a good example of a mashup that
combines an external service with the database and reporting features of Salesforce.
Click the Get It Now button to start the installation process. This will take you through a
series of confirmation screens asking you to review legal terms, the contents of the package,
and security settings. On step 3, choose "Grant access to all users," since we're installing into
an account that doesn't have any users.

It turns out that you still have a little more work to do once you've finished the install process.
You need to customize your account through the Setup area so that the new application is
visible. It would be nice if applications came with a help document that walked you through
this process. However, in my experience the next step is usually the same. Most applications
come with their own tab, which you need to add to your visible tabs. In this case click the
arrow on your last tab, which takes you to the All Tabs tab. Then click the Customize My
Tabs button.

Click for a larger view.

This will give you a form for moving available tabs to your selected tabs. Choose Search
Campaigns from the Available Tabs list and move it to the Selected Tabs list.
Once you have saved your choice you'll see a new Search Campaigns tab that will let you
create and track AdWords campaigns.

Building Native Applications

The most common form of Salesforce application development is done entirely through the
Salesforce.com interface. Native applications are built by extending Salesforce's data schema,
by writing custom HTML, and by writing JavaScript. These native applications can be
bundled and shared through AppExchange.

Extending the data schema can be as simple as adding a field to an existing object like we did
when we added a website field to the Contact object. It can also mean creating your own
objects. These are essentially database tables, called "custom objects" in Salesforce parlance.
Whenever you make a schema change, Salesforce automatically creates or updates the related
forms and pages. You don't need to build the standard CRUD actions like create, update,
show, or list.

Like most customizations, you can add custom objects through the Setup area. Get started by
visiting Setup and then Build -> Custom Objects in the left sidebar.
Click for a larger view.

Salesforce has just released a book that shows how to build an example recruiting application
using native application techniques. They gave away hard copies of the book for free at their
Dreamforce conference, but they've also just started including a link to a PDF copy as part of
an advertising campaign on TechCrunch. Until they produce a more official page, you can
download the book for free from their advertisement landing page.

Building Custom Pages with S-Controls

Congratulations on graduating from the basics. Most Salesforce development happens

entirely through the Salesforce web UI. This gives incredible power to customize and build
applications to people who wouldn't normally have any control over their application.
However, you probably want to write code. For native applications, that starts with S-
Controls.

S-Controls let you write your own HTML in order to build pages and forms. S-Controls
include templating variables that let you access Salesforce data. The application-building part
can be done in any web application technology, like Java applets or Flash. However, most
people use JavaScript.

Salesforce is putting a lot of work into their Ajax toolkit. This toolkit allows you to call back
to the Salesforce API in order to read and write data to the database. The beta release includes
two excellent tutorials to get you started.

The Ajax toolkit will graduate from beta in Salesforce's Winter '07 release, due out in the
next few months.

Accessing Data with SOQL

Many times when you're developing for Salesforce you'll be treating it like a database.
Salesforce provides an SQL-like query language called SOQL that you use in combination
with the API to query data. SOQL has been limited by the ability of Salesforce to host the
high volume and unpredictable data queries of its users. The Winter '07 release will eliminate
the biggest limitation, finally allowing users to join multiple tables. The other difference
you'll notice right away is that queries won't return the full result of a large data set. Instead
you'll have to use queryMore until you've retrieved everything you need.

The developer documentation has the basic syntax.

The Salesforce API

So far, we've been talking about building applications that are limited to filling out web forms
and writing JavaScript. If you'd rather build an application in your favorite programming
language, then you should plan on hosting the application on your own server and treating
Salesforce as a database that you access through their API. This way you can access the data
that your company or client is entering into the Salesforce application without having to be an
expert yourself.

The Salesforce Projects and Toolkits page lists toolkits for almost every language including
Java, .NET, Perl, PHP, and Ruby. Many of the toolkits hide the API behind a traditional
Object Relational Model.

Before you get started, you need to generate and download a Salesforce WSDL file. Do this
by going to the Setup area and then to Integrate -> AppExchange API.

Here's an example Perl script that would list the names, emails, and websites of all of our
contacts. You could get going with a similar few lines of code in almost any language.

use WWW::Salesforce::Simple;

my $sforce = WWW::Salesforce::Simple->new(
'username' => $user,
'password' => $pass,
);

my $query = "select FirstName, LastName, Email, website__c from Contact";

my $res = $sforce->do_query($query);

foreach my $field ( @{ $res } ) {

print $field->{'FirstName'} . "\n"
. $field->{'LastName'} . "\n"
. $field->{'Email'} . "\n"
. $field->{'website__c'} . "\n";
}

The developer docs will probably be your main reference when using the API.

Getting More Information

Developers will probably spend most of their research time referring to the documentation on
the AppExchange Developer Network. However, there are several other important sources of
information.

Salesforce hosts very active developer forums. You can get most any question about the API
or the toolkit answered there. Many members of Salesforce's API and development teams
also spend time there, so you're likely to get the inside scoop or even influence the direction
of the product.

There's also two popular blogs that cover Salesforce and AppExchange development. Mark
Mangano summarizes Salesforce news at SalesForceWatch by monitoring nearly a hundred
RSS feeds. Scott Hemmeter talks about his experiences as a developer and Salesforce
consultant at Perspectives on Salesforce. You should probably also subscribe to the official
AppExchange blog.

If you're looking for a job as a Salesforce consultant or developer, you will want to watch the
job board section of the developer forums. If you're looking to build a product that you can
sell on AppExchange, then you should definitely check out Salesforce's IdeaExchange.
Salesforce built IdeaExchange so that customers could submit feature requests and other
customers could rate the requests, Digg-style. This is a gold mine for product ideas.
Salesforce knows they can't develop all of these ideas themselves. That's why they're putting
so much effort into encouraging an active developer community.

The Future

The Winter �07 release of Salesforce will be out within a few months. This release will
introduce many powerful new development features including inline S-Controls, improved
Ajax support, improved SOQL, and external outbound messaging. Soon after the release,
Salesforce will release the beta of a new programming language called Apex that runs on the
Salesforce servers. This will let you write validation rules, triggers, and stored procedures.
They�re re-branding the development platform Apex as well, not to be confused with their
new programming language.

On the development roadmap is a JavaScript proxy that will let you access external APIs
from JavaScript running on Salesforce hosted pages. This will eliminate one of the major
challenges to building JavaScript-powered mashups.

One clearly missing feature of AppExchange is the ability to bill your customers. If you want
to charge for your product, you're going to have to build the infrastructure yourself. The good
news is that the people I talked to at Salesforce recognized this as a key service to enable
developers to make a living by focusing on what they do best. It's not on the development
road map yet, but it should be.

In the next article, we'll build a Salesforce application using the Salesforce API and add that
application to the AppExchange.

Return to the O'Reilly Network.