Hi check it once...


To build this yourself, you would need to develop all the following features:

A transport mechanism to replicate the data to and from Salesforce.com using the AppForce API. There is no access to a physical database at Salesforce.com, and all data must be accessed using an API that delivers packets of 200 records at a time through their SOAP interface.
A data transformation mechanism (ETL) to map and modify raw data into a format recognized by the target system (such as changing yes-no to Boolean true-false for checkboxes)
A method of describing metadata to the gateway that is flexible and doesn’t break when the Salesforce.com schema is modified
A scheduling mechanism to tell the transport layer when to run and what timeframes to query records
A recovery mechanism to handle all possible network and system failures at Salesforce.com, which are a very frequent occurrence. There are days when the API interface is down for hours, which would cripple anything that requires direct API access. Relational Junction has built-in functionality to properly handle all outages, and to retry connections for up to 20 minutes at a time.
A restart mechanism to retry failed loads without missing records and without creating duplicate records
A technique to handle millions of Salesforce records without timing out.Relational Junction has a patented process to do just that which no other vendor has even attempted.
A method of determining which side wins when there are multiple updaters of the same record. Relational Junction can handle record ownership issues down to individual fields.
A logging mechanism to track job history and run statistics
A failure logging mechanism to trap record level exceptions with all data exposed for debugging purposes
A notification mechanism that will inform staff of problems without overwhelming them with information
A complete retesting of all functionality for every new release of Salesforce.com. There are generally four major releases each year, each of which requires code modification, often times without documentation until after the release is production.

Relational Junction was built by our company to solve all these problems. The products have been in hundreds of production customer sites since 2005, and have saved many projects from failure. The data recovery features have also saved careers, as Relational Junction is the only solution that not only backs up all data, archives deleted records,  can keep all versions of all records, and can recover the entire Account structure with all dependents intact and related to their parent records.

 

First, you cannot build a solution like ours in less than a year, even with totally committed and skilled resources. That is the typical time it takes a vendor with dedicated resources to develop a product in our space that has even the most rudimentary feature sets, has been tested as thoroughly as Relational Junction, and has been implemented successfully in hundreds of customer sites over many years. If time to market and reliability is at all important, you’ll leverage a package solution instead of building the infrastructure yourself.

 

Secondly, you cannot build nor maintain a solution as inexpensively as ours. The reason we have a product is because the effort involved is so significant that companies are not able to do this for themselves. Our annual pricing for all of this functionality translates into about $10 per hour in labor rates for the full suite, plus a year or more of development time. Given that even mature systems require ongoing maintenance, you will never be able to beat this price unless you can hire Java or C++ programmers for minimum wage. Salesforce API programming is a very specialized skill that is not readily available. I would venture from experience that development costs would far exceed $200,000 for a basic system that met the technical requirements outlined above. So, we have a 10-to-1 cost improvement over the home-grown approach. This is a conservative number because our solution is predictable and home-grown projects can fail or take longer than expected.

 

Thirdly, our database-centric solution makes it far easier to do integrations. Using Salesforce.com as a direct end-point complicates development and testing, since the data cannot be validated by conventional means short of visual inspection. It is also much harder to re-run tests, since you can only delete records one at a time from the user interface. Our approach lets your team using existing skill sets and tools, and leverages the power of a database. Not coincidentally, you then have a complete data warehouse on which you can run reports that cannot be done in Salesforce, such as anything with more than 2 levels, or “without” reports (“Opportunities without Tasks” is my favorite). Gartner has lately discovered and extolled the virtues of a hub-and-spoke integration approach instead of fragile point-to-point integration.

 

We are prepared to do the following to enable you to experience why our technology and methodology is far superior and much more economical than developing your own, and to ELIMINATE YOUR RISK. We will provide a 15 day Proof of Concept period at no cost. We will install the product, train your staff, walk them through the first integration, and provide any technical support through this POC period. There is no obligation involved, other than your time. All this could be done with a standard desktop or 1-proc rack-mounted computer. We do this with confidence that you will appreciate and buy our product because nearly every POC we’ve offered has resulted in a satisfied and intensely loyal customer.

 

Visit our listing on the AppExchange and see for yourself.