Comments on: Salesforce.com Data Synchronization Tool? http://blog.jeffdouglas.com/2009/03/30/salesforcecom-data-synch-too/?utm_source=rss&utm_medium=rss&utm_campaign=salesforcecom-data-synch-too Get your head out of your #@! and into the clouds! Wed, 08 Feb 2012 07:57:55 +0000 hourly 1 http://wordpress.org/?v= By: Rick Banister http://blog.jeffdouglas.com/2009/03/30/salesforcecom-data-synch-too/comment-page-1/#comment-3148 Rick Banister Wed, 06 Apr 2011 18:51:15 +0000 http://blog.jeffdouglas.com/?p=621#comment-3148 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. 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.

]]> By: Ted Mathews http://blog.jeffdouglas.com/2009/03/30/salesforcecom-data-synch-too/comment-page-1/#comment-1894 Ted Mathews Wed, 06 Oct 2010 17:59:15 +0000 http://blog.jeffdouglas.com/?p=621#comment-1894 We have been using Centerprise from Astera and we love it so far. http://sites.force.com/appexchange/listingDetail?listingId=a0N300000016cxvEAA We have been using Centerprise from Astera and we love it so far.
http://sites.force.com/appexchange/listingDetail?listingId=a0N300000016cxvEAA

]]> By: Jeff Douglas http://blog.jeffdouglas.com/2009/03/30/salesforcecom-data-synch-too/comment-page-1/#comment-1143 Jeff Douglas Thu, 22 Jul 2010 17:19:08 +0000 http://blog.jeffdouglas.com/?p=621#comment-1143 @Tom, not specifically but have been using Boomi and am REALLY fond of it. @Tom, not specifically but have been using Boomi and am REALLY fond of it.

]]> By: Tom Cusack http://blog.jeffdouglas.com/2009/03/30/salesforcecom-data-synch-too/comment-page-1/#comment-1113 Tom Cusack Tue, 20 Jul 2010 23:07:50 +0000 http://blog.jeffdouglas.com/?p=621#comment-1113 Hi Jeff, I was wondering if you found a tool to meet this requirement? Love the blog, keep up the good work! Tom Hi Jeff,

I was wondering if you found a tool to meet this requirement?

Love the blog, keep up the good work!
Tom

]]> By: Scott Hemmeter http://blog.jeffdouglas.com/2009/03/30/salesforcecom-data-synch-too/comment-page-1/#comment-135 Scott Hemmeter Thu, 02 Apr 2009 15:47:52 +0000 http://blog.jeffdouglas.com/?p=621#comment-135 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. 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.

]]> By: Andrew Leigh http://blog.jeffdouglas.com/2009/03/30/salesforcecom-data-synch-too/comment-page-1/#comment-134 Andrew Leigh Thu, 02 Apr 2009 04:21:42 +0000 http://blog.jeffdouglas.com/?p=621#comment-134 This should be possible with informatica's on demand synchronization tool. I believe they provide a free trial on their website. This should be possible with informatica’s on demand synchronization tool. I believe they provide a free trial on their website.

]]> By: annemarie http://blog.jeffdouglas.com/2009/03/30/salesforcecom-data-synch-too/comment-page-1/#comment-133 annemarie Wed, 01 Apr 2009 20:44:06 +0000 http://blog.jeffdouglas.com/?p=621#comment-133 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 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

]]> By: dschach http://blog.jeffdouglas.com/2009/03/30/salesforcecom-data-synch-too/comment-page-1/#comment-132 dschach Tue, 31 Mar 2009 04:41:50 +0000 http://blog.jeffdouglas.com/?p=621#comment-132 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. 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.

]]> By: George Scott http://blog.jeffdouglas.com/2009/03/30/salesforcecom-data-synch-too/comment-page-1/#comment-131 George Scott Tue, 31 Mar 2009 02:53:49 +0000 http://blog.jeffdouglas.com/?p=621#comment-131 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. 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.

]]> By: jeffdonthemic http://blog.jeffdouglas.com/2009/03/30/salesforcecom-data-synch-too/comment-page-1/#comment-130 jeffdonthemic Mon, 30 Mar 2009 19:20:31 +0000 http://blog.jeffdouglas.com/?p=621#comment-130 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? 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?

]]>