• Page
|
• Edit

Download PDF.

Introduction to the Force.com Platform

The Force.com platform from salesforce.com is a service that lets companies create, customize, integrate, and share on-demand applications over the Internet—all without needing to purchase or install software. The service is composed of two main parts: the AppExchange directory, an online marketplace for sharing on-demand applications, and the Force.com platform on which those applications are developed. With Apex, companies can take advantage of a new, Internet-centric way of building applications that is dramatically simpler and more powerful than the approaches that have preceded it.

As a directory, the AppExchange is analogous to consumer Web sites such as eBay and iTunes, in the way that it provides an open, community-based approach to distributing, reviewing, and acquiring applications. As an on-demand platform, Apex is like traditional software-based tools, such as databases, operating systems, and application development environments, but is unique in the specific technologies it employs and the way it is delivered. Using the Force.com Platform, companies, developers, and ISVs have an innovative and powerful new way of bringing the benefits of on-demand to all aspects of a company’s business.

The technology that powers Salesforce, the Force.com platform provides the extensibility that customer relationship management (CRM) applications require to meet the most sophisticated CRM business needs easily. And, because it is a complete platform, developers can use it to create new applications that extend the capabilities of CRM as well as those that address entirely different types of requirements. Intended for business analysts, developers, and IT professionals, this paper provides an overview of the technologies and concepts behind the Apex platform and what is involved in using it across a variety of scenarios. Additional information, documentation, and case studies on the use of Apex are available on the developer.force.com Web site: developer.force.com.

The Force.com Platform at Work

The easiest way to understand the Force.com Platform is to review a few common examples of how it can be used. Broadly speaking, the use of Force.com as a platform falls into one of the following key categories: ::

• Customization: The Force.com Platform provides features that make it easy to modify Salesforce applications, such as Salesforce SFA or Salesforce Service & Support, to meet unique business requirements. This can range from simple examples, such as adding a new field on a customer lead form to track interest in a specific product, to advanced customizations, such as tracking all of the assets owned by customers or the status of professional service projects.

• Integration: Salesforce is typically used to manage customer-facing processes and information, so users frequently want to connect that customer, sales, and support data with back-office ERP and accounting systems. Meeting integration requirements of this type, such as taking closed opportunities in Salesforce and creating corresponding orders in an Oracle Financials system or sharing customer data between an SAP system and Salesforce, represents another common use of the Apex platform.

• Application Creation, Development, and Distribution: The most powerful way to take advantage of the Force.com platform is to use its capabilities—the same ones that support the easy customization and integration of Force.com apps—to create entire new on-demand applications, such as a new bug-tracking system or a recruiting management application. This use of Apex is especially interesting because in addition to making the core capabilities that power Salesforce available to developers who create new applications, it provides a way for the new applications to be packaged, shared, and even sold via the AppExchange directory.

Force.com Features and Concepts

Unlike some general-purpose platforms, such as a PC operating system, the Apex platform is designed explicitly for data-centric business applications, like the kind traditionally built with Visual Basic, PowerBuilder, or other database tools. Although implemented and exposed differently, the key concepts are similar: forms, page layouts, data tables, and business rules are common to almost all database tools, and they are a key part of Apex.

Although these traditional platforms and the Force.com Platform share some of the same concepts, the technologies and models behind Force.com will be new to some developers. These new technologies, including metadata/declarative development and Web services, are a foundation of most next-generation application platforms and are key to providing the app creation and deployment benefits of Force.com. Understanding the role and capabilities of these Apex components is important to understanding both how Force.com apps are designed and the options and alternatives available in their development (see Table 1 and the definition of terms below).

Multi-Tenancy

At the heart of the Force.com platform is one of the key innovations of salesforce.com: the idea of multi-tenant applications. In contrast to their single-tenant counterparts, such as client/server enterprise applications or email mail servers, multi-tenant applications are designed so that users share the same physical instance and version of the application. Individual “deployments” of those applications occupy virtual partitions rather than separate physical stacks of hardware and software. Multi-tenant applications, such as Salesforce, and platforms, such as Apex, are similar to consumer applications such as Google Mail and eBay, each of which runs a single code base and depends on an inf rastructure shared by all users. This multi-tenant design makes possible the quick deployment, low costs, and rapid innovation for which salesforce.com has become known.

In addition to providing significant operational benefits, the multi-tenant nature of the Apex platform also has implications for how developers use it to create new applications. Specifically, the multi-tenant nature of the Force.com allows for a clear boundary between the platform and the applications that run on it. While it allows applications to have their own data objects, forms, layouts, and integration, these and other customizations are managed as abstractions. This separation is key to ensuring that any given application can’t “behave badly” by encroaching on other users’ applications, or otherwise preventing low-level aspects of the platform from being upgraded, changed, or enhanced. So in contrast to developing for a single-tenant platform, where it is common to modify database tables or underlying code, in the case of an on-demand platform, similar tasks are accomplished using a different approach, which thankfully often requires much less work.

Application Customization and Building

The key to providing powerful and complete customization capabilities entirely on demand within a multi-tenant model rests on the concept of metadata-driven application development. Instead of hard coding the attributes of an application, such as its data tables and page layouts, metadata development relies on the creation of a “blueprint” that describes an application’s attributes and behaviors independent of its implementation. A common, real-world example of this approach is an HTML page. Instead of programmatically defining a page or form via code, as one might do with Visual Basic or another programming language, an HTML page is a declarative “blueprint” that is translated into a real page by the browser. Force.com apps in turn describe not just pages but entire applications and are rendered by the platform into complete applications on request, analogous to how a browser turns HTML into a Web page. Collectively, these metadata features of the platform are known as Force.com Builder.

One of the advantages of this model is that by using a simple point-and-click configuration process, you can create even sophisticated applications without code. This makes application development available to whole new classes of users unfamiliar with programming, and speeds development for experienced programmers. Significantly, the use of metadata also creates an implicit boundary between an application and the platform, which, as discussed above, is essential for the multi-tenant model. The limitation of this model, however, is that capabilities must be explicitly defined. Developers cannot modify the core code, for example, of how page layouts are rendered, and instead must work within the constraints defined by the metadata. In practice, this limitation is often a benefit, because it allows for the safe modification of an enterprise application while preventing the kind of “off the rails” customization that creates enormous complexity, cost, and upgrade pain for the managers of traditional enterprise applications.

Web Services Integration

Although metadata plays a key role in defining how applications are built for the Force.com Platform, it does not limit the kinds of application features that can be created, and, importantly, how data from Force.com apps can be shared and integrated with other systems. To go beyond the native metadata capabilities of the platform, and to connect with the other applications, the Apex platform provides a complete and robust Web services interface known as the Force.com API. Based on open Internet standards, including XML, SOAP, and WS-I Basic Profile, the Force.com API allows developers to access their Force.com apps from within their favorite programming language, development environment, or integration tool. Similar to the way Force.com Builder is based on metadata development concepts, the Force.com API is based on concepts and technologies of service-oriented architectures (SOAs), which means it aligns with the product direction of other vendors including Microsoft, IBM, and BEA.

Although you don’t have to use the Force.com API to create apps for the platform, the API is typically involved in more-sophisticated use cases, such creating a “mash up” of Salesforce account information and Google Maps or of Salesforce contact data and a data-cleansing service. In integration use cases, such as sharing customer data between Salesforce and a back-office ERP system, use of the API is essential. (A separate salesforce.com white paper, “Creating Salesforce Integrations with Force.com,” describes those integration capabilities in detail.) Note that code that uses the API does not run on the Force.com Platform, living instead on whatever inf rastructure and systems the developer chooses and accessing the Force.com API over the Internet. This separation of platform and developer code represents another implicit boundary that protects the multi-tenancy of the platform.

On-Demand Programming Language

Apex Code is an upcoming feature that dramatically expands the types and sophistication of applications that can be built with the Force.com platform. As an on-demand programming language, Apex Code gives developers the kinds of power and control they have with traditional development environments, while freeing them from any of the associated operational and infrastructure costs and responsibilities. And since Apex Code runs directly within the Force.com platform, logic created in the language can be inserted into almost any part of an application’s flow and can be executed with consistency regardless of how it is invoked—including through the Web user interface or Web service API.

Application Deployment

Unlike on-demand offerings from other vendors, the Apex platform allows multiple applications to be run within the same Salesforce deployment, allowing all of a company’s Force.com apps to share a common security model, data model, and user interface. The Apex OS, which allows applications from a similarly broad set of providers to be installed alongside Salesforce, is analogous to a PC operating system, which allows the user to run applications created by the operating system vendor, a third-party ISV, or a company’s IT department. While these Force.com apps are preintegrated with Salesforce and each other by virtue of their common data model, administrators can control which users within a company have access to which apps and which data.

Application Sharing and Distribution

In addition to being able to run multiple applications, the Force.com platform allows apps created on the platform to be packaged and shared. These apps can be uploaded to and registered with the AppExchange directory, where other companies can browse, demo, review, and install them. Although the AppExchange does not provide a billing mechanism, companies can charge for the use of their applications. If an application is being created solely for distribution via the AppExchange directory, special considerations apply. Not all elements of the platform and Salesforce are available to apps packaged and redistributed via the directory.

The six Force.com features described above collectively define how applications are built for the AppExchange and frame the patterns, tools, and best practices for using the platform. Understanding the basic concepts and constraints involved with each is key to planning how to create a customization, integration, or new application for the AppExchange. The following section explores the various options for combining these features.

Force.com Application Types

As is the case with other systems, not every feature of the Force.com platform is required for every application. Depending on what kind of application is being built, only one or two of the capabilities may be required. In addition, the different features and development models are often combined, especially where sophisticated functionality is required or when multiple systems are being integrated with Force.com. This section presents and explains the three different kinds of Force.com applications—native, composite, and client. Understanding which of them is appropriate for a given use case is the first step to understanding the tools, resources, and technologies necessary for any given project.

Native Applications

Native apps are built exclusively with metadata, using Force.com Builder, and do not use the API or have any dependencies or links to other applications. One advantage of native apps is that they can be built entirely using the point-and-click tools available in the Salesforce setup area. Because they are built with metadata, no coding is involved in their creation, and they can often be created by nondevelopers, with even complex apps being built in just a few hours. These apps also run entirely on the Force.com Platform, require no external services, hardware, or infrastructure, and even scale to thousands of users. However, the capabilities of these apps are constrained by the capabilities of Force.com Builder. If a kind of form field or business logic isn’t explicitly defined by the platform, then it cannot be used in an application.

Composite Applications

Composite apps use a combination of the native platform capabilities available in Force.com Builder and the lower-level access provided by the Force.com API. This type of app supports more powerful kinds of customizations and extensions than is otherwise possible. For example, this allows the creation a unique page look and feel, form layout, or business process. In addition, composite apps can combine multiple services, such as Salesforce and an email marketing service, or internal apps, such as existing data warehouses and ERP systems.

This kind of app is commonly created to meet the needs of integration use cases like order entry and configuration, as well as for ISVs “porting” existing on-demand applications to the Force.com Platform. Because they are dependent on external code or services, however, composite apps come with a significant set of requirements. Developer-level coding skills are required, as is access to the appropriate tools and platform. Most important, since the external services and code used run outside the platform, the author of composite apps is responsible for the systems and infrastructure that run, maintain, manage, and scale those services. (Note this last consideration does not apply for client-side custom code, such as ActiveX controls and AJAX scripts.) For internal-company apps, this can be a modest requirement, but for ISVs offering a generally available service this can mean a significant investment in resources. For these reasons, as well to ensure a consistent user experience, composite elements of an app should be used only where necessary, and not as a way to re-create existing platform functionality. Reviewing common composite design patterns will help companies and developers get the most from this model.

Client Applications

This is more of a descriptive term than a technical one. Client apps are applications that use the Force.com API exclusively and run outside the context of the Salesforce user interface. Classic examples of this kind of app include apps designed for mobile devices such as the BlackBerry, desktop app integrations such as Microsoft Outlook connectors, and enterprise integrations with ERP and account systems that run outside Salesforce on a scheduled or batch basis. Development of these apps is the most varied of the three types, because it spans the full gamut f rom J2ME client apps to .NET forms applications to EAI tools such as TIBCO or WebSphere. In each of these examples, however, the development model is defined by the tool being used, with the Force.com platform serving only as the data source for those systems, much as a database does in traditional development. Note that because these apps do not run directly on the Force.com Platform, they cannot be installed automatically using the AppExchange directory.

Choosing which type of Force.com app to create to best meet your goals is the first step in planning your project. Unless an external system is involved, most users will start by considering the native model, and then considering whether using the API in support of a composite app is appropriate and worth the trade-offs involved. Because they are distinct, it should be clear when the client application pattern is required for a given use case.

Developing for Success

Understanding the basic technologies and kinds of applications associated with the Force.com Platform is the first step to creating applications for the platform. Familiarity with the best practices and design philosophy behind Force.com apps will further increase the likelihood of success for any given project.

Keep It Simple

Much of the success of salesforce.com’s flagship applications can be attributed to their simplicity, ease of use, and support for user productivity, even at the expense of functionality. When using other applications created for the platform, Salesforce users often expect a similar experience. Although developers are often justified in introducing new modalities and designs into their Force.com applications, those creating apps that provide the simplest solution for a given problem are most likely to be rewarded with quick adoption by the Salesforce community.

Focus on the Data Model

At their core, most Force.com applications are data-centric. As such, the design of the data model behind a given app is typically the biggest factor in its success or failure. One key area of the data model to consider is its complexity. Perhaps the most common mistake is to create objects that require such detailed and highly structured information that they greatly restrict both the applicability and usability of the application they support, crippling user adoption. Knowing when to use structured data, such as pick lists and check boxes, and when simple fields, such as text areas, would suffice is key to creating an effective data model. As indicated above, keeping it simple is always a good rule of thumb.

The second important data model area involves when and how to relate or link objects with each other as well as with standard Salesforce objects such as leads, contacts, and opportunities. The goal is not just ease of use, but also to ensure that a new application effectively builds on and enhances the existing customer, marketing, and sales information common to most Salesforce deployments. While specific guidelines vary between different kinds of applications, building apps that can take advantage of existing Force.com apps and avoiding the re-creation of existing functionality is a good practice.

Take Advantage of Available Resources

Salesforce.com’s developer.salesforce.com, includes resources that help developers quickly create successful applications for the Force.com Platform. This site includes an active community that can address most technical questions, complete documentation and sample code for most platforms, and an open-source area with common building blocks and tools. Also available on the site is salesforce.com’s f ree, fully functional Developer Edition, which allows developers to get hands-on experience with all aspects of the Apex platform. By using Developer Edition to play around and experience the features of Force.com directly, developers can quickly and clearly understand the concepts and tools available for creating new apps.

The Force.com Platform represents salesforce.com’s vision of changing software in general as much as the company’s flagship service has already changed CRM, making the technology available and successful in a way that previous generations of technology have never allowed. To achieve that vision, the collective resources and creativity of developers—using the platform to create the solutions that interest them most—are essential. Be sure to let your contacts at salesforce.com know how they can help you be successful in reaching that goal.