Navi Mumbai Salesforce DUG meetup on integration
•
4 likes•1,345 views
Navi Mumbai Salesforce DUG meetup on integration
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (16)
Similar to Navi Mumbai Salesforce DUG meetup on integration
Similar to Navi Mumbai Salesforce DUG meetup on integration (20)
Recently uploaded
Recently uploaded (20)
Navi Mumbai Salesforce DUG meetup on integration
- 1. Integrating with the Salesforce Platform Speaker: Rakesh Gupta (DUG Leader Mumbai)
- 2. Safe Harbor Safe harbor statement under the Private Securities Litigation Reform Act of 1995: This presentation may contain forward-looking statements that involve risks, uncertainties, and assumptions. If any such uncertainties materialize or if any of the assumptions proves incorrect, the results of salesforce.com, inc. could differ materially from the results expressed or implied by the forward-looking statements we make. All statements other than statements of historical fact could be deemed forward-looking, including any projections of product or service availability, subscriber growth, earnings, revenues, or other financial items and any statements regarding strategies or plans of management for future operations, statements of belief, any statements concerning new, planned, or upgraded services or technology developments and customer contracts or use of our services. The risks and uncertainties referred to above include – but are not limited to – risks associated with developing and delivering new functionality for our service, new products and services, our new business model, our past operating losses, possible fluctuations in our operating results and rate of growth, interruptions or delays in our Web hosting, breach of our security measures, the outcome of intellectual property and other litigation, risks associated with possible mergers and acquisitions, the immature market in which we operate, our relatively limited operating history, our ability to expand, retain, and motivate our employees and manage our growth, new releases of our service and successful customer deployment, our limited history reselling non-salesforce.com products, and utilization and selling to larger enterprise customers. Further information on potential factors that could affect the financial results of salesforce.com, inc. is included in our annual report on Form 10-Q for the most recent fiscal quarter ended July 31, 2012. This documents and others containing important disclosures are available on the SEC Filings section of the Investor Information section of our Web site. Any unreleased services or features referenced in this or other presentations, press releases or public statements are not currently available and may not be delivered on time or at all. Customers who purchase our services should make the purchase decisions based upon features that are currently available. Salesforce.com, inc. assumes no obligation and does not intend to update these forward-looking statements.
- 3. OAuth Industry standard method of user authentication
- 4. Remote Application Salesforce Platform Sends App Credentials User logs in, Token sent to callback Confirms token Send access token Maintain session with refresh token OAuth2 Flow
- 6. REST API API leveraging industry standard HTTP
- 7. Mobile Application Salesforce Platform login.salesforce.com REST API 1. Authenticate /services/data/query? SELECT ID FROM ACCOUNT 2. Access API {“sObject”: “Account”, “id” : “oax02fdr756aFdad”} 3. Get JSON or XML
- 9. SOAP API XML messaging and WSDL based API
- 10. Java Web Server Salesforce Platform login.salesforce.com SOAP API 1. Authenticate <QUERY><SOQL> SELECT Id from Account </SOQL></QUERY> 2. Access API <RECORDS> <RECORD type=“Account”> <id>oax02fdr756aFdad</id> </RECORD> </RECORDS> 3. Get XML
- 11. Bulk API Asynchronous API for handling large datasets
- 12. ETL Tool Salesforce Platform BULK API 2. Push Updates TITLE: AppCo STREET: 1 Market Street REF:0001 1. Pull Recent Records Legacy Database NAME: AppCo MailingStreet: 1 Market Street ExternalID:0001
- 13. Streaming API Bayeux implementation for real-time delivery of data
- 14. Java Web Server Salesforce Platform STREAMING API 1. Handshake 2. Subscribe to Topic 3. Get Updates
- 16. Apex Endpoints Exposing Apex methods via SOAP and REST
- 17. Apex SOAP global class MyWebService { webService static Id makeContact(String lastName, Account a) { Contact c = new Contact(lastName = 'Weissman', AccountId = a.Id); insert c; return c.id; } }
- 18. Apex REST @RestResource(urlMapping='/CaseManagement/v1/*') global with sharing class CaseMgmtService { @HttpPost global static String attachPic(){ RestRequest req = RestContext.request; RestResponse res = Restcontext.response; Id caseId = req.requestURI.substring(req.requestURI.lastIndexOf('/')+1); Blob picture = req.requestBody; Attachment a = new Attachment (ParentId = caseId, Body = picture, ContentType = 'image/
- 19. Canvas Framework for using third party apps within Salesforce
- 21. Any Language, Any Platform • Only has to be accessible from the user’s browser • Authentication via OAuth or Signed Response • JavaScript based SDK can be associated with any language • Within Canvas, the App can make API calls as the current user • apex:CanvasApp allows embedding via Visualforce Canvas Anatomy
- 22. CANVAS DEMO
- 23. Apex HTTP HTTP Callouts from the Salesforce Platform
- 24. Apex HTTP public FlickrList getFlickrData(string tag) { HttpRequest req = new HttpRequest(); req.setMethod('GET'); req.setEndpoint('http://api.flickr.com/services/feeds/photos_public.gne?nojsoncallback=1&f ormat=json&tags='+tag); HTTP http = new HTTP(); HTTPResponse res = http.send(req); return (FlickrList)JSON.deserialize( res.getBody().replace(''',''),FlickrList.class ); }
- 25. FLICKR HTTP DEMO
Editor's Notes
- Docs to help:http://www.salesforce.com/us/developer/docs/api/index.htmhttp://www.salesforce.com/us/developer/docs/api_rest/http://www.salesforce.com/us/developer/docs/api_streaming/http://www.salesforce.com/us/developer/docs/platform_connectpre/canvas_framework.pdfhttp://www.salesforce.com/us/developer/docs/apexcode/index_Left.htm#StartTopic=Content/apex_classes_restful_http_http.htm
- Before we get into specifics about API integration – let’s talk a bit about Identity. Identity services, being able to authenticate your users securely – is incredibly important, especially once we start accessing the platform from third parties.Now many of you may have existing applications which use our API’s – who here has written a mobile or desktop app that logs into Salesforce, for instance? If you wrote that app with a username and password screen, consider what you are taking on there: you have to handle those credentials with the same care we do on login.salesforce.com, right?
- What if you didn’t have to? Stupid question time: who has used Facebook? Right, exactly – and if you’ve used Facebook you have probably seen those popups that say things like “Farmville would like to do these three things as you”. You hit confirm, and Farmville has access to some of your Facebook account, but only the parts you let it. And you never gave them your password. And at any time, you can revoke the app.That’s Oauth, and the Salesforce Platform has an excellent implementation of it. It works by having the app send the user to the first party platform, in this case Salesforce, who logs the person in. The application and the plattform essentially confirm each other, and then at the end of it – the app gets a session token with only the permissions you granted.
- Let’s see that in action. Going to demo Workbench, which is a great PHP application for various developer functions against the platform.https://workbench.developerforce.com/login.phpJust be sure to log out of your org, and then you can go here and walk through the whole login procedure. Workbench shows great user info in the upper right corner.
- Now let’s talk about our specific API’s. We have API’s to fit a wide range of use cases. Our REST API is very versatile, and one of the main use cases is mobile applications.
- That’s because the REST API is very lightweight. You access it with industry standard HTTP calls. So when you call http://cnn.com, that’s an HTTP GET call. Your browser returns HTML, and you see a web page. This is the same, but authenticated, and you get JSON back. JSON is a very lightweight data type and many languages and frameworks already know how to parse it.
- Let’s see that in action.https://workbench.developerforce.com/restExplorer.phpIe.e to demonstrate doing a query: /services/data/v28.0/query?q=SELECT+ID+FROM+ACCOUNT
- Now our old workhorse is our SOAP API.
- The flow of SOAP is very similar to REST, but the messaging is different. With SOAP, you are sending and receiving an XML message in a specific format. This can get heavy, size-wise, but it is also very stable and predictable. You can create a document called a WSDL (Web Services Definition Language) which defines how those messages look, and a lot of languages like Java and C# can easily consume a WSDL and create classes that talk to the API automatically.
- Now our Bulk API is meant specifically for loading large datasets. It’s asynchrounous to maximize the the server processing and allow for potentially lengthy load times.
- ETL (Extract Transform Load) tools can leverage the Bulk API to insert rows, pull data, and even modify the data in between … to say, match up columns with different names.
- Like the Bulk API – the Streaming API is designed for a very specific problem. What if you need real time updates, but you don’t want the API cost of constantly asking the server is anything has changed?{I usually talk about a Python dev who wrote a script to grab specific accounts, hand them off to a local process and then attach a resulting PDF to the account. It reduced a 45 minute process to a couple of minutes, and it made the system far more responsive. But to make it realtime, he polled the API every millisecond, which killed his API limit. Modified to work with the Streaming API, it now works great}
- The Streaming API gets a handshake from the platform, and then can subscribe to topics. Topics are mostly defined by SOQL to describe the kind of data the topic is pushing. Then, as long as that handshake is open – the updates get sent down to the client.
- Let’s look at a demohttps://workbench.developerforce.com/streaming.phpThis allows you to view topics, create new ones, and test connections. Create a new topic, update some data and see the message come across with the data update.
- Now, everything we’ve seen so far require no coding at all – these are the vanila API’s right out of the box. You get the basic Create Read Update Delete functionality. With Apex, however, you can extend our API’s to fit specific situations.
- For SOAP, it’s just annotating a method as a web service. With that annotation, the method gets exposed as an endpoint, is described in the WSDL and can send and receive SOAP messages which match the incoming and outgoing parameters.
- For REST, things get a little more organized. Since REST is based on HTTP methods, we annotate a class first as a REST resource to define the endpoint – and then we annotate functions to be associated with specific HTTP methods (GET, POST, PUT, PATCH and DELETE). When the endpoint gets an incoming request, it sends it over to the function that has the appropriate annotation. JSON transformation is done on the fly.
- Canvas is our technology for deploying third party applications within the Salesforce UI, complete with authenticated API access.
- For instance, maybe I have a large internal intranet applications. I don’t want to port all that functionality into Salesforce, but I do want to be able to integrate this one interface.
- Here is a very simple PHP demo:https://github.com/joshbirk/Canvas-PHPUse either of the install links to install it into an org. You’ll then need to configure the app to use admin configured users and add the profile. After that it will show up in Canvas App Previewer (under setup), Chatter tabs and can be used in VF pages, etc.
- Now we’ve been looking at how to call into theSalesforce Platform – but how about calling out?
- Apex has a system level HTTP library, which allows us to build requests to HTTP (and HTTPS) endpoints and handle their response. In this case, we’re simply calling the public Flickr feed to get some JSON about images, and then we can display that in Visualforce.