Wednesday, August 25, 2010

Integrating with Salesforce.com

Salesforce.com (aka Salesforce) is the most commonly used cloud-based Software as a Service platform for Customer Relationship Management (CRM). Recently, we have been involved with a lot of customers who are planning to start migrating to or have made a strategic decision to use Salesforce to manage their customer contacts, track sales orders, streamline their sales processes, etc. In fact, Prolifics itself is a Salesforce customer.

Our own experiences, and those with our customers who use Salesforce, have given us an in-depth understanding of what it takes to ensure that this CRM solution is made universally available within the enterprise – to business processes that require customer information or to portal applications that mash up customer information with data from other systems. This blog entry details three patterns that we have commonly used when integrating with Salesforce and that we believe can be reused – entirely at the design level and to a good extent at the implementation level.

1. Enterprise CRM Services – Every enterprise has defined standards when it comes to their enterprise services and data formats. The reusable enterprise services are exposed via the ESB and all the end applications use these enterprise services to communicate with end systems so that the ESB can provide the common functionality and the governance needed when performing system integration. Using this same concept when working with Salesforce allows enterprises to centralize the Salesforce integration at the ESB layer (the ESB communicates with Salesforce using SOAP/HTTP web services), do transformation, security, etc. at one common place and provide clients – processes, portals or mashups, etc. – with the consistent enterprise-wide data representation to which they are accustomed. The enterprise services provide the generic CRM interface to the clients, so that if the CRM system has to be changed, the hundreds of clients that use the CRM system in the enterprise do not have to change. The IBM WebSphere Enterprise Service Bus is commonly used for implementing this pattern.


2. Publish CRM Data – Another common requirement is to ensure that CRM data is passed from Salesforce to back end systems based upon changes that happen within Salesforce to this information. The ESB provides a service (SOAP/HTTP web service) that gets invoked by Salesforce (with all the relevant information from Salesforce) when data of interest changes in Salesforce. This data is then transformed and passed to the back end systems. The benefits of this approach include a centralized service definition on the ESB, transformation of data, centralized security management, supporting legacy applications that are not web service enabled [but still need CRM data], etc. The IBM WebSphere Enterprise Service Bus or IBM WebSphere Message Broker is commonly used for implementing this pattern. [Note: the reverse flow from end systems to Salesforce is handled similarly, instead of being invoked by Salesforce; the ESB invokes a service on Salesforce.]

3. Bulk Load of CRM data – It is very typical for customers to need the ability to bulk load customer data from their existing homegrown systems into Salesforce. These kinds of requirements are also common when mergers and acquisitions happen and new customer data needs to be loaded. During the bulk load of CRM data, there may also be a need to cleanse the information before loading it into Salesforce. The IBM InfoSphere DataStage, IBM InfoSphere QualityStage, and the IBM InfoSphere Information Server Pack for Salesforce.com together support this pattern that involves the definition of ETL jobs that extract data from different sources, cleanse, map the data to Salesforce format, and load it into Salesforce.


I want to conclude by saying that we at Prolifics believe in “eating our own dog food.” Prolifics has a production implementation of IBM WebSphere Enterprise Service Bus that was built using the pattern described above (Publish CRM Data) that enables the data we have in our Salesforce instance to be published to IBM’s Global Partner Portal based on Siebel.

In my next set of blog entries, I will focus on couple of related topics:

  • IBM’s acquisition of Cast Iron Systems and how the solution supports these patterns of integrating with Salesforce

  • A set of assets that we are currently working on at Prolifics to help customers jump start their own Salesforce integration initiatives.

Rajiv Ramachandran first joined Prolifics as a Consultant, and is currently the Practice Director for Enterprise Integration. He has 11 years experience in the IT field — 3 of those years at IBM working as a developer at its Object Technology Group and its Component Technology Competency Center in Bangalore. He was then an Architect implementing IBM WebSphere Solutions at Fireman’s Fund Insurance. Currently, he specializes in SOA and IBM’s SOA-related technologies and products. An author at the IBM developerWorks community, Rajiv has been a presenter at IMPACT and IBM's WebSphere Services Technical Conference.