The document discusses cross-platform integration using web services, including REST and SOAP, and highlights the key characteristics and advantages of each. It also details the process of creating a connected app in Salesforce to enable authentication and single sign-on (SSO), along with demos of each step. Furthermore, it compares REST and SOAP, outlining when to use each based on application requirements.

1. CROSS PLATFORM INTEGRATION
By:-
Raj, Amit, Amol
Narendra & Gunjan

2. AGENDA
➢ Web Services
➢ REST
➢ Inbound call using Connected app
➢ SOAP
➢ SSO (Single Sign On)

3. Web Services
Web service is a standardized medium to propagate communication between the
client and server applications on the World Wide Web.

4. Types of Web Service

5. What is REST ?
➢ A RESTful API --REpresentational State Transfer (REST)
➢ Provides access to resources, not logic
➢ Resource can be a single document or complex object
➢ Client-Server development
➢ Server does not maintain state for client, no cookies

6. Why use REST ?
➢ Predictable- regardless of domain
➢ Discoverable- standard verbs and routing structure
➢ Simple- know the domain, know the system
➢ Incorporates multiple W3 Standards

7. Standard REST
➢ Data Transfer Objects to represent resources
➢ HTTP Verbs to perform actions on resources
➢ Negotiate content type via headers i.e. Accept : application/json
➢ Respond with HTTP Status code

8. HTTP Verbs/Methods
➢ GET - provides read only access to one or more resources
➢ POST - to create new resources
➢ PUT - to update resources
➢ PATCH - to partially update resources
➢ DELETE - to delete resources

9. Status Code(Link)
1xx: Informational Communicates transfer protocol-level information.
2xx: Success Indicates that the client’s request was accepted successfully.
3xx: Redirection Indicates that the client must take some additional action in order to complete their
request.
4xx: Client Error This category of error status codes points the finger at clients.
5xx: Server Error The server takes responsibility for these error status codes.

10. REST API Demo

11. Inbound call using Connected app
➢ We need to install a connected app in org to enable authentication.
Then we can use profiles, permission sets, and IP range restrictions to
control which users can access the app.
➢ A connected app integrates an application with Salesforce using
APIs. Connected apps use standard SAML and OAuth protocols to
authenticate, provide single sign-on, and provide tokens for use with
Salesforce APIs.
➢ In addition to standard OAuth capabilities, connected apps allow
Salesforce admins to set various security policies and have explicit
control over who can use the corresponding apps.

12. Steps for Creation of Connected App
1. Go to Salesforce instance
2. Search for App in Setup>>App Manager (New Connected App)
3. Create New App Add the required fields
4. [App name, API name, Email, Select Enable Auth Setting => Call Back URL,
Selected Auth Scope => Full Access(Api)/Desired]
5. After app is ready store Consumer Key & Consumer Secret for further
usage.
6. Get the Security Token or Reset it.

13. Working Demo:
1. Creation of Connected App
https://www.screencast.com/t/9AFGnnT6qX
2. Security Token Reset
https://www.screencast.com/t/htkXny7iTxm
3. Getting the Security token after Reset
https://www.screencast.com/t/PozWin9f
4. Checking the Connected app using Postman
https://www.screencast.com/t/KEd6t12K

14. 5. Export of SF Accounts into Accounts
https://www.screencast.com/t/pq11Grfn
6. Upsert operation into SF Accounts from CSV
https://www.screencast.com/t/rY7OrV8FQ
Working Demo: Cont.

15. What is SOAP?
➢ A SOAP API --Simple Object Access Protocol
➢ The XML way of defining what information is sent and how
➢ Uses WSDL(Web Services Description Language)
➢ Designed to support conversational state management

16. Why use SOAP?
➢ Security (built in WS_Reliable Messaging)
➢ Good for applications that require formal contracts between the API
and consumer
➢ Offers built-in retry logic to compensate for failed communications

17. SOAP vs REST(Link)
➢ REST is an Architectural Style while SOAP is a Protocol
➢ REST APIs uses multiple standards like HTTP, JSON, URL and XML
while SOAP APIs largely based on HTTP and XML
➢ SOAP is more secure than REST
➢ SOAP has built-in error handling for communication errors (using
WS-ReliableMessaging Specification) while in REST we have to handle
error using Status code

18. SOAP API Demo

19. When to use REST? and When to use SOAP?

20. When to use REST ?
➢ Limited resource and bandwidth
➢ Statelessness
➢ Caching
➢ Ease of coding

21. When to use SOAP?
➢ Asynchronous processing and subsequent invocation
➢ A Formal means of Communication
➢ Stateful operations

22. What is SSO?
➢ Single sign-on (SSO) is a Session.
➢ User Authentication Service
➢ Permits an end user to enter one set of login
credentials to access many systems.

23. Why we use SSO?
➢ Connect multiple applications through a single login.
➢ Allows you to login once and access many systems.
➢ It makes life simple.

24. Implementation Related Terms
Focusing on SAML-based Single Sign-On
➢ Security Assertion Markup Language (SAML): allows security
credentials to be shared by multiple computers across a network
➢ Identity Provider (IdP): The authentication server(Salesforce).
➢ Service Provider (SP): An accessible business application(Appian).

25. How SSO Works?

26. SSO Demo