Pls Check Update in question for answer
I am a newbie to salesforce. After few hours of researching I am able to figure out how can I do basic CRUD Options via rest Services.
Now I am Stuck at how can I link my salesforce data to an external Sql Database, Initial research suggests this can be achieved by Using APex Rest API, but honestly I find the documentation a little tough.
My requirement is whenever a new record is added in Accounts or contacts, a rest Service will be called and data will be saved at external database as well.
I can easily save the data but how will i get the data is big question for me.
What is the best approach and are their any good examples to follow ?
I know its a broad question, but i just require the initial push.
My effort For CRUD operations
var auth = new Salesforce.Common.AuthenticationClient();
auth.UsernamePasswordAsync(_clientId, _clientSecret, _username, _Password).Wait();
var client = new ForceClient(auth.InstanceUrl, auth.AccessToken, auth.ApiVersion);
Task<QueryResult<dynamic>> results = client.QueryAsync<dynamic>("SELECT Id,FirstName,LastName,Email From Contact");
results.Wait();
var contacts = results.Result.Records;
foreach (var contact in contacts)
{
Console.WriteLine(contact.FirstName + " " + contact.LastName );
}
Console.WriteLine("Press Any Key to continue");
Console.ReadLine();
————————————————————————–
Finally Solved it
Update
Solution Using Soap.(WCF Service)
Best Answer
You don't need the Salesforce REST API for this use case, you need a receiving API on the end of your external database. The code you have is going to call out from the machine executing it and grab the data from Salesforce. That would be reliant on that machine running it regularly and would be more of an ETL style integration than a transactional web service.
To make this a transactional web service you'd need to have a SOAP or REST endpoint hosted to receive the data from Salesforce when changes are made. To implement it you'd need to use one of several methods in Salesforce to trigger app logic from database DML events.
I'll outline the different ways to achieve this type of integration below. If you want to learn more about the different patterns and see which patterns fit the different use cases then I recommend reading the Salesforce documentation for integration patterns and best practices. It includes a matrix that helps you to pick the right integration pattern and provides the different ways that pattern can be utilized in Salesforce.
https://developer.salesforce.com/docs/atlas.en-us.integration_patterns_and_practices.meta/integration_patterns_and_practices/integ_pat_intro_overview.htm
Outbound Messages (SOAP)
Salesforce provides a point and click solution called Outbound Messages, but it is specific to SOAP (no REST), and it uses a specific schema that provides a session Id so you can connect back to Salesforce via SOAP if necessary.
The developerforce site has an example of how this is done (using Java on the receiving end):
https://developer.salesforce.com/page/Creating_an_Outbound_Messaging_Notification_Service_with_Eclipse_3.2
This is a recommended pattern for your use case from Salesforce. I'm not a fan of it because of the lack of a REST capability and the requirement to conform to their WSDL. If you've already got a middleware good at building SOAP services from an existing WSDL this is a good option. If you have to write your own listening service I'd opt for building a REST service and implement it with one of the next patterns.
Apex trigger calling Apex class
Apex has a way to write custom database triggers which can do app logic before or after DML. It can be used to make callouts by passing to an static asynchronous method (@future method) in another class. This method allows you to use REST or SOAP, but requires coding on the Salesforce side.
Here is an example of how to do a REST callout from a trigger:
http://blog.jeffdouglas.com/2009/03/16/restful-web-service-callout-using-post/
For SOAP, you'd have to generate an apex class from the WSDL using apex2wsdl and then use the generated stub class to make your callout. Here is the documentation for async callouts in SOAP
https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_continuation_callout_soap.htm
Salesforce lists this as suboptimal on the integration patterns documentation, and I can list a couple reasons they might have decided that.
Triggers are a powerful tool and integrated at the database level. Failures in triggers that aren't handled can result in data not getting stored (you don't want to be the guy responsible for Leads not coming in anymore).
Apex doesn't have a built in way of handling failed transactions to the callout. If your transaction fails in the async method for any reason (external issues included), you can't stop the user from committing the data because the process is async from the UI (requirement of triggers to make callouts). To deal with it you need to handle the errors, and queue a later callout. This part can by tricky because @future can't call @future methods. You end up essentially building your own queueing system. There is a lot of work involved to get it right, but it has the advantage of being much more flexible in the web service side; e.g. it can use REST or a SOAP spec that you can alter which is beneficial when integrating with a third party.
Process Builder calling Apex class
A more recent addition to Salesforce is the Process Builder. It has the capability of calling Apex as an action, and allows you to build logic with point and click tools around database actions (DML). This can be used identically to triggers, but requires a little less code. Here is a good blog post showing an example of how to achieve that:
http://cloudyworlds.blogspot.com/2015/03/invoking-apex-callout-from-process.html
External data connector via OData / Salesforce Connect (formerly Lightning Connect)
This one is not applicable to your use case, but I decided to post it for others facing the same situation with data that is hosted in an external database, doesn't link to a standard object, and not in an existing custom object in Salesforce or one that can be removed and replaced with an external object.
External data sources allow you to create external objects in Salesforce using "connectors". The external objects it creates sync an external data source (as the name implies) with an object exposed in Salesforce. Winter '16 added the capability to make connections bi-directional when using either the OData or the Apex connectors.
http://docs.releasenotes.salesforce.com/en-us/winter16/release-notes/rn_forcecom_external_data_writeable_objects.htm
OData is a specification that essentially wraps around REST to allow applications to communicate with external data sources (or middleware acting as an OData bridge). The advantage with OData is that it is a standard and the work involved to implement is less. It has the disadvantage of requiring an OData middleware or capability for your database.
Apex Connector Framework was added in Summer '15 and provides a way to build your own connectors for use with the External Data feature. The advantage here is the ability to write connectors in your own code. This opens up the possibility of connecting to non-OData capable systems (or whatever else your mind can dream up that fits within apex, limits, and the interface spec).
http://docs.releasenotes.salesforce.com/en-us/summer15/release-notes/rn_forcecom_external_data_apex_adapter.htm
This article on the Engineering developerforce blog has a great introduction to the custom apex connectors.
https://developer.salesforce.com/blogs/engineering/2015/05/introducing-lightning-connect-custom-adapters.html
There are some special considerations with Salesforce Connect:
As of a few months ago when I last checked, there was a cost associated with each external data source. Make sure to check that you're licensed for a connection, and check with your Salesforce account manager about pricing if necessary.
Then there is this help article, which outlines a bunch of different limitations with external data sources. There are a lot of things listed and I haven't read into them all yet, but a quick glance spots some critical things to think about. For example, the like operator isn't available in SOQL or SOSL, and aggregates aren't fully supported.
https://help.salesforce.com/HTViewHelpDoc?id=platform_connect_considerations.htm&language=en_US
Additional info
I always recommend Trailhead, it's a great resource to learn about Salesforce development, integration, etc. Here is the module for integration:
https://developer.salesforce.com/trailhead/module/apex_integration_services
Another good resource for learning about web services and callouts is the article on developerforce that discusses and provides examples of some of the patterns:
https://developer.salesforce.com/page/Apex_Web_Services_and_Callouts