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.
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.
Edit Contact Fields
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.
AdWords App Page
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.
Customize Tabs
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.
Choose Search Tab
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.
Add Custom Object
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.
(http://www.oreillynet.com/pub/a/network/2006/11/13/an-introduction-to-saleforcecoms-appexchange.html)
No comments:
Post a Comment