+ Start a Discussion
Sushma PriyaSushma Priya 

How to integrate Salesforce with external systems

Hi,

 

As part of a Project, we are in the process of identifying the

1. Number of ways to connect to an External System from Salesforce(As we need to connect to the external system, get required data from the external system and use that data in the Salesforce application) and

2. Finalizing the feasible/suitable approach of the above.

 

Can anyone please provide the different approaches of connecting Salesforce to External Systems and their feasibility in usage.

If you can give me a sample code for each of the approaches that would be of really great help for me.

 

Thanks in advance,

Sush.

Best Answer chosen by Admin (Salesforce Developers) 
Rick.BanisterRick.Banister

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.

 

All Answers

Nimble TedNimble Ted

Salesforce doesn't have the ability to connect out to an external system, but you can push data in and out. 

 

To push data into Salesforce, there's the Apex Data Loader tool, and various  offerings on the AppExchange.

 

http://wiki.developerforce.com/page/Apex_Data_Loader

 

There is also an open source .NET project that shows how to push data in via the API, which could be instructive for a Java implementtion. 

 

http://code.google.com/p/salesforce-dotnet/

 

To get data out, there's the outbound messaging feature that pushes records out to an external web service. 

 

http://www.salesforce.com/us/developer/docs/api/Content/sforce_api_om_outboundmessaging.htm

 

I  believe you need to file a case to have this enabled, but I don't think there are any additional fees. 

 

Essentially, you pull the data from the external system, format it for Salesforce, and then push it in through the API. 

 

In the other direction, the outbound message sends the data out, your web service reformats for the external system, and then your service does the update. 

 

The Apex Data Loader works just fine, but if you have the development resources, it can be worth investing in developing your own tool, along the lines of the Salesforce DotNet offering. With your own tool, you can do the formatting and pushing on the fly, and not have to write it out to CSV files in between. (Huge difference!) 

 

Outbound messaging is great for one-by-one changes, but I've had trouble with external systems keeping up when there are massive changes on the Salesforce side. (LIke you touch 10,000 records with the Data Loader tool.)

 

HTH, Ted.

Rick.BanisterRick.Banister

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.

 

This was selected as the best answer
andrew.bladesandrew.blades

Hi Sushma,

 

Are you still looking for assistance with this integration? If so, I believe I can offer some assistance as I have helped several thousand Salesforce users to integrate with external systems.

 

Please feel free to contact me at andrew.blades@pervasive.com

 

I look forward to hearing from you!

 

Kind Regards,

 

Andrew Blades

AruAruAruAru
Hi, I am trying to integrate Salesforce with Sybase Unwired Platform(SUP). I have created a webservice which will create an Opportunity in Salesforce. Generated the WSDL out of this class. Now when i am trying to consume this service from SUP its not able to locate the End point URL. Please help i am new to SUP integration. global class MyWebService { webservice static Id makeOpportunity(String oppName, String forecastCategory, String stage, Date closeDate){ Opportunity opp = new Opportunity(Name= oppName,ForecastCategoryName=forecastCategory, StageName= stage, CloseDate=closeDate); insert opp; return opp.id; } }
moffetmoffet

i need some assistance to integrate salesforce wih zoho can u help

kishoredeepikakishoredeepika

We are trying to integrate SFDC with External system, were external system will invoke our webservice class(consumers od of WSDL) and salesforce will accept the request(Providers of WSDL).Here external system will send us something called as tickets which is in the below format, and SFDC has to capture that request and parse it, to create case in the SFDC and send back the response to external system.If anyone has worked on similar kind of requirement please let us know how to proceed.

 

<Account>

    <AccountId></AccountId>

    <Case>

           <CaseNumber></CaseNumber>

          <Ownerr></Owner>

                      <FalloutJob>

                   <JobId></JobId>

                   <!--One or more repetitions:-->

                   <Attribute>

                          <Name></Name>

                          <Value></Value>

                          <ValueType></ValueType>

                   </Attribute>

           </FalloutJob>

    </Case>

</Account>

Pavel MüllerPavel Müller
Have a look at http://www.snow-mirror.com/. SnowMirror replicates the data from Salesforce tables into a traditional database such as Oracle or MSSQL Server. It is simple and effective.
harjinder singhharjinder singh
hi,
i need to do some customization. Out of all the fields present in the Account page some 4-5 fields i need to keep as it is and
wanted to add extra 15-20 fields.Once all the fields are created in the account page i have to call API callout to external system to pass the data captured in accout page and at the same time need to save in the salesforce. 
Kevin PoklertKevin Poklert

Hello Sushma!

Take a look at Skyvia. This cloud tool can help you with data integration depending on your aim: import, export or maybe sync. It's simple in use and doesn't require writing a code: https://skyvia.com/data-integration/analyze-salesforce-with-microstrategy