Salesforce.com Data Synchronization Tool?
March 30th, 2009
We’ve been using Relational Junction for a couple of years for data replications from Salesforce.com to SQL Server. Even though it works well we’ve been exploring other offerings namely Informatica, Reflection and Apatar. While all of these do a good job at replicating data, we can’t seem to find a service that will provide synchronization between two data stores. Here’s a fictional example of what we are looking for:
Let’s say we replicate some of our Account and Contact data to SQL Server for use on our corporate website. When someone updates a person’s email address in Salesforce.com we’d like the service to make this change in SQL Server. When a change to a person’s email address is made in SQL Server we’d like this change to be reflected in Salesforce.com. Obviously there are issues surrounding which fields are overwritten, but for simplicity we’d like the service to determine which system date is the most recent and then update the other data store with the changes.
Does anyone know of a service that performs this type of functionality?
Categories: Salesforce
Jeff,
Have you looked at Cast Iron System’s Integration Appliance (www.castiron.com)? It can perform the type of database synchronization you describe as well as tie into other enterprise systems like SAP R/3.
Thanks George! We’ll have a look! We also run multiple versions of SAP so this might come in handy. How does the integration work with with SAP? Web services? BAPIs?
Cast Iron can integrate natively with SAP using RFCs, BAPIs, or IDOCs. They also have the ability to invoke web services, so that option is available as well.
I’m a fan of the solutions from Pervasive. Contact Doug McLean at dmclean@pervasive.com and tell him I sent you. He can handle exactly what you’re talking about.
Absolutely agree with last comment. Pervasive is a cost effective and fully functional tool, we have been working with it for nearly 12 years! So contact Doug… or contact us if you want some pointers… aberger@forefrontcorp.com
This should be possible with informatica’s on demand synchronization tool. I believe they provide a free trial on their website.
Check out DbAmp (http://sites.force.com/appexchange/apex/listingDetail?listingId=a0N300000016bWzEAI). We use it at my client and they love it. It replicates out to SQL Server and we use it for our data loads where our devs load into a SQL Server table specific to that data load (similar in feel to a data loader CSV file, but a table instead) and then they run a process to upsert.
Hi Jeff,
I was wondering if you found a tool to meet this requirement?
Love the blog, keep up the good work!
Tom
@Tom, not specifically but have been using Boomi and am REALLY fond of it.
We have been using Centerprise from Astera and we love it so far.
http://sites.force.com/appexchange/listingDetail?listingId=a0N300000016cxvEAA
This seems like it’s coming a bit late from a post nearly 2 years ago, but I’ll explain how Relational Junction works in this case. In any event, a call to our support line would have cleared up the poster’s confusion. Informatica and Pervasive do not solve the specific problem here, which version of the data “wins”.
First, Relational Junction is really two products
1) a bi-directional data replication program
2) a database-centric ETL program. Many of our customers use other ETL products or stored procedures in conjunction with the data replication program, but the integration logic is fundamentally the same.
The reason for this bifurcation is to provide the maximum flexibility to the integration developer. You do your integration logic with the replicated database, which you should synch with Salesforce (SFDC to the database) before performing any integration logic. Then, you develop the integration between your “legacy” database and the replicated salesforce data. Finally, the changes to the replicated data are replicated back to Salesforce, using a command code in each table (“I” for insert, “U” for update).
The logic about which fields “win” during an integration and which versions of the record “win” can be handled through two mechanisms.
1) by not updating the replicated salesforce data if the SYSTEMMODSTAMP column is a later date than the source database, correcting for GMT to local time. RJ ETL automatically compensates for time zone offsets.
2) by setting a mask of what fields will be replicated to Salesforce, so only the fields desired will be copied and not overwrite user-entered fields.
If you were to use another approach of sending data directly to Salesforce, it would not work unless you specifically examined each record for it’s timestamp prior to updating it in Salesforce. Notwithstanding the unbridled enthusiasm of the Informatica and Pervasive commentators, that is neither a scalable or easy task using those tools.