Salesforce-to-Salesforce Mashup: 100% Native Force.com Apex Solution - March 16, 2009 at 5:32 am

I recently ran into a challenge regarding a Salesforce-to-Salesforce mashup.  We didn’t want to move the data (traditional integration, S2S/org to org sharing), but we also wanted to keep the solution as "clean" as possible — the simplest possible implementation with the fewest possible moving parts.  This article is a walk through of how we solved it.  I’ve included some lessons learned at the bottom.

Background

* Our goal was to create a mashup without a third party mashup provider.

* Although Apex facilitates callouts to external services, the API specs clearly state that Apex callouts are not designed to call full Salesforce.com API based webservices, so we knew we had to avoid that route.

* We wanted to have avoid creating a large number of dedicated Apex "stubs" on the data provider org.

* In addition to pulling information from the data provider org, we wanted to be update to update a record.

Here are the two screen shots that we ended up with.  Note that both are on the calling org.  In the first, you can see where a query has resulted in data coming back.  In the second, you can see where we’ve updated a field and refreshed the query results. Neat!

Screen 1: The query "Select Id, Name, BillingStreet from Account where BillingState = ‘CA’" results in two records.

Screen 2: Here you can see the results of the first query, as well as my entries in the "update" section.  I’m using the data I received from my query to determine which records to update.

Screen 3: And you can see here where "GenePoint" the company I select based on the ID has moved from "345 Shoreline Park" to "123 Reid Updated Blvd." (Class A digs if they ever existed.)

The Basic Process

1. Create a stub in the org that will provide the data.  This should be a global webservice class.  Save the generated WSDL for this class.

2. Import that WSDL using WSDL2APEX in the org that will consume the data.  It will create a matching objects.

3. Create a utility method that handles authentication for you.  You won’t be able to use either the partner or enterprise WSDL in your Apex so you’ll need to roll your own.  We have a quick & dirty version below.

4. You’ll need a Visualforce page and a Visualforce controller to tie everything together.  Those are pretty trivial so I’ve left them out of this post (but they’re in the code, below).

The Code – Data Provider Org

Code is posted in a separate file.  Download it!

We started by creating a "DataProviderRequest" Apex Webservice class that executes queries and returns data.

Next was the Data Consumer. Note that this has both a "getSobjectData" and an "updateSobjectData" section. 

Code contains working examples of:

* Dynamic SOQL / Dynamic Object Udpates

* Login to one SFDC org from another.

Lessons Learned

* You need to create your own intermediate data type to move content back and forth between the orgs.  If you use SObject, you’ll have a schema which includes all of the SObject sub-types.  Not very useful (and just too long).

* Performance is reasonably good although not perfect.  Caching the session ID rather than logging in every time would improve performance.

* This is a reasonably good alternative to traditional integration methods but IMHO I would generally rather use things like Salesforce to Salesforce if the use case supports it.

* Getting this to production ready will require some tweaking but my over all thought is that it shouldn’t be too hard.