Designing Salesforce Integrations with the Force.com Platform
Download PDF.
Connecting Salesforce to an existing enterprise application is a common and frequently performed task. And with the flexibility that the Force.com platform provides, there are a range of options available to best meet the type of integration that is required; choosing a solution for a specific project is typically a function of the business process being implemented, and what technology infrastructure is preferred or already in use.
The term “integration” can be used to describe a wide array of use cases and requirements. This section will focus on the common “enterprise integration” or “system to system integration” scenarios that involve connecting a company’s front office CRM systems to their back office and accounting ERP counterparts. In planning these types of integrations, note that the technology and design patterns will likely vary considerably from other use cases, such as CTI integration.
Concepts of the Service Oriented Architecture
As a Web service based platform, the technologies and concepts associated with the Force.com platform and Web service API are those of the Service Oriented Architecture (SOA), which aims to simplify integration and increase agility by creating well defined and standards-based boundaries between systems. This model, supported by the leading platform providers and AppExchange partners such as Microsoft, IBM and BEA, has natural implications on how Force.com interacts with the rest of the enterprise architecture.
What Force.com provides in terms of integration is a fully featured and straightforward Web services API that can provide programmatic access to almost all of the features and data available via Force.com's browser-based user interface. In practical terms, this means that the Frce.com API is simply a data source in your integration architecture – specific business logic, connectivity to other enterprise systems, and data transformations are built and managed in the middleware technology of your choice, that you control and maintain. This approach has a number of benefits, including the ability to use existing tools and skills in building integrations, and also means that activity between Force.com and other systems is always mediated by this middle layer. Put differently, integrations are not designed and implemented in Force.com; instead the Force.com API is used in conjunction with other tools (such as Java code or EAI tools) to create a larger integration architecture.
Architecting Integrations with Force.com
While each enterprise integration project seems as unique and particular as the systems and businesses involved, in practice almost all of the use cases can be designed by considering the following four criteria. Understanding how each of these relate to your use case is the first step in designing your integration with Force.com.
| Name | Description | Key Questions |
|---|---|---|
| Business Process | Specific processes being implemented between CRM and Accounting/ERP systems, such as Order-to-Cash or Account Master | What processes are required? What is the system of record? |
| Data Model | How the systems’ different data models will be reconciled and information common to both will be managed. | What data will be shared? What transformations are necessary? |
| Connectivity | What protocols and technologies will be used to allow basic communications and access to the systems being integrated. This applies only to the ERP side as for the AppExchange platform connectivity is always via the Web service API. | What interfaces or adaptors will be used to connect to and communicate with ERP and accounting systems? |
| Technology | Platforms and tools used to implement the integration, such as EAI tools (ie TIBCO, WebMethods) or custom code (ie Java, .NET). | What category of tool (ETL, custom code, EAI) will be used? What specific tool and skill sets are available or required? |
This framework provides a high level view of the types of questions that are addressed in designing integrations. Of these, the business process and technologies areas are typically most complex; to assist in addressing those two, additional detail is provided below.
Business Processes
As varied and unique as business processes between Force.com and ERP/account systems appear , they can almost always fall into one of the following three categories. Note that while all are common, most enterprises don’t implement all three, and instead only choose those most relevant to their requirements.
- Account & Customer Master: The first and most commonly implemented process, account & customer master describes how systems share a notion of the account and related contacts. As the account is the core unit of activity of both CRM and ERP activity, having a shared reference to an account between systems is the cornerstone of most integrations. Typically, the ERP/accounting system servers as the “master” for existing customer accounts, whereas non-customer “prospect” accounts are maintained only in Force.com, with a separate process to promote them to customers when appropriate. A similar process exists for sharing product data between systems, although it is only necessary if a common product master is also required – understanding if and how Salesforce product features will be used in an implementation is key to determining if this latter integration is necessary, and also has effects on the Order integration design.
- Order Integration: In contrast to account master, information in the order integration process flows from Force.com to the ERP system, and is typically triggered when a sale is completed or a new deal won. This process describes how those deals are converted into orders, which can then be used for billing, accounting and collection as part of a company’s back office operations. A key consideration in this process is how those orders are configured and entered; some companies have simple requirements that allow orders to automatically flow from Force.com to ERP, while others with more complex products require an order configure or entry step. Related to this issue is how and if Salesforce’s products and price books features are used, as if they are, it naturally represents an additional integration consideration.
- Billing and Account Status: This process describes how information from ERP systems is made available within Salesforce, typically to provide a view of the data to sales and support users. By completing this integration, companies can provide a complete view of account activity across CRM and ERP systems; for example, customer contact history with billing and order information could be provided within a single location. Information from the ERP system is typically treated as read only, and either copied into an custom object (which is in turn related to the account), or made available from an account screen via a Web Link that pulls the information on demand from the back office system. The former model, where the data is stored in Force.com, has the benefit of allowing full reporting and dashboard access to the information directly from the Force.com user interface for “free” without additional integration work.
Technology
As a Web service, the Force.com API supports a wide array of technology options, allowing companies to use the tools and skills of their choice when implementing integrations. Understanding the basic categories of technologies is useful in selecting the most appropriate choice for a given use case and company.
- Pre-built connectors. Some AppExchange partners, including eBridge, offer pre-built integration solutions between Salesforce and popular accounting packages, such as QuickBooks or Great Plains. For companies with “off the shelf” accounting solutions, this option may be the simplest. Salesforce.com sales engineers can provide details on the list of support partners and associated packages.
- ETL. A common approach is to use an ETL (Extraction, Transformation and Loading) tool to perform a batch migration of data between Force.com and the target system. These tools, such as Data Junction, typically provide connectors to both systems, and the facility to map and transform data between them. As a result, ETL-based solutions typically require little to no programming, and can be setup to regularly move specified sets of data on a regular basis.
- Point-to-point custom applications. Since the Force.com API supports a broad range of languages and platforms – including any that support SOAP – many customers prefer to create custom applications that perform the ETL function programmatically. Typically developed in Java, .NET or Perl, these solutions benefit from having direct access to the Force.com Web services API, and as such can provide greater control over the integration process, such as polling only for changed records. In addition, this control allows for more complex integration tasks, such as additional lookups or data cleansing, to be accommodated more easily than is possible with many ETL solutions.
- EAI. For companies with existing EAI (Enterprise Application Integration) solutions or message-based integration strategies, using a complete EAI solution like those provided by TIBCO and WebMethods can provide the full set of integration capabilities, including connectors, monitoring and transformation, required of sophisticated use cases. While the alternatives here are listed roughly in order of complexity, the actual amount of effort required is typically a function of internal skill sets and competencies. In addition to developing integration solutions internally, salesforce.com professional services can work with the options listed above to create integration solutions for a specific set of requirements.
Features of the Force.com Platform
Understanding a few of the key Force.com features is useful in understanding the specific product elements used in implementing Force.com integrations. (For a complete overview of the Force.com platform, see the “Creating Applications using AppExchange” whitepaper.) In the following section, the three most import integration related features of Force.com – the Web service API, web links / web applications, and Force.com Builder – are introduced.
The Force.com API
Central to the ability to integrate and extend Salesforce is the powerful and modern Force.com Web service API. Architected around the latest standards, including SOAP, WSDL and WS-I Basic Profile, this Web service provides the complete set of operations necessary to complete even demanding integration projects. And as an open Web service, the API is available to all platforms that support the core Web services standards, including Java, .NET and Perl.
The Force.com API is organized around a simple “noun/verb” separation, and is analogous to working with a database through an API such as JDBC or ADO.NET. The core API calls, for example, include query, create, update and delete. These operations are performed against a set of standard and custom objects, including Lead, Account, Contact and Opportunity. Unlike a database API however, the Force.com API can expose rich meta-data directly to a development environment as a Web service, providing a strongly-typed way of accessing the fields and properties for a given object.
In Java, for example, the API includes easy to use “getters and setters” for each object; setting the phone number for a lead is a simple as lead.setPhoneNumber(“415-555-1212”). This strong-typing – and developer convenience – is possible because Force.com generates a unique WSDL, complete with custom field and custom object information, for each organization. More information about the API, including full reference documentation, is available at http://developer.force.com.
Extending Force.com with Web Links and Web Applications
As a web-based application, Force.com provides a simple and powerful model to integration with other web sites and web-based applications. This feature, called Web Links, lets administrators configure Force.com to put hyperlinks to other sites directly on a page layout. And since these Web Links can be dynamically defined, they can, for example, automatically link to a finance web site and pass in the ticker symbol from the originating account record.
Used in conjunction with the Force.com Web services API and a Web application server technology, such as Java, .NET or PHP, these Web Links provide a complete framework to build Web applications that extend Force.com, and provide access to other systems. For example, a company with a Web-based product configuration system can modify that application to communicate with the Force.com API, and allow configured orders to be automatically inserted into Force.com. From an end users’ perspective, launching that Web-based configuration tool would be as simple as clicking on a link on the appropriate Force.com page. Since the Web application would get the users’ context – including session information, and the opportunity they are currently viewing – that application can automatically populate the appropriate values or do related lookups in other systems. The result is a seamless experience for users, and a familiar and straightforward programming model for developers.
This technique is used in order configuration and order entry business process integration scenarios, but can also be part of implementing account master and billing status use cases. For more information on extending Force.com with Web applications, including detailed sample code and documentation, visit the resources section of http://developer.force.com.
Leveraging Force.com Builder in ERP Integrations
A central part of configuring and extending Force.com, Force.com Builder provides a simple point and click interface to access many of the features of Force.com for building new on demand applications. These capabilities, and especially the ability to modify the Force.com data model by adding new fields and objects, are important in designing ERP integrations and helping create a shared view of data across systems.
Companies often want to make a portion of ERP and back office data available directly to their sales representatives within salesforce. By copying invoice or order information from the accounting system to Force.com, reps can easily see that data associated with their accounts, and without having to access a separate system.
Adding custom objects with Force.com Builder, this concept can be extending to almost any kind of ERP data. A company that collects metering or other field service data via an ERP system can easily copy that information – in whole or as a summary – into a custom object that is related to an account. Doing so not only provides a single view of all that account’s activity, but also allows business users the ability to create reports and dashboards on that information, all without leaving Salesforce.
Case Study – Analog Devices
Founded in 1965, and with over 8,500 employees, Analog Devices is a world-leading semiconductor company that serves over 60,000 customers worldwide. Like many companies that size, Analog's IT architecture contains a number of enterprise systems that serve a broad range of internal requirements. These systems include SAP for ERP and Force.com for enterprise CRM. Analog sought to combine these two critical systems to create company-wide business processes that spanned both customer-facing and back-office functions.
By integrating Force.com to SAP, Analog was able to deploy a best-of-breed CRM solution to its sales teams while maintaining consistency with SAP-based account and product information. In addition, because of Force.com's open and industry-standard Web services interface, Analog was able to use its existing WebMethod’s integration platform and skill sets to quickly complete the project, rather than learn new or proprietary tools required by the CRM vendor.
To learn more about how Analog Devices used AppExchange to integration Force.com and SAP, visit the complete case study at http://developer.force.com
Learning More
Salesforce.com provides a variety of tools and resources to help companies learn about and build integrations between Force.com and the rest of their enterprise systems. At http://developer.force.com, developers and IT Professionals can find additional whitepapers, documentation and sample code to help them learn about and develop Force.com based solutions. In addition, a force.com Developer Edition is provided for free at http://developer.force.com to allow programmers to get started learning and using the platform today. Finally, the developer community at http://developer.force.com provides a responsive and active resource for having both general questions and specific issues answered quickly. For more information about using Force.com to meet your company’s integration requirements, visit or contact your account manager.