Salesforce: Connected Apps, Auth Provider and Named Credentials

Connected Apps

A Connected App in Salesforce is a framework that enables external applications such as mobile apps, web apps, and APIs to securely connect with Salesforce. It supports various protocols including OAuth 2.0, SAML, and OpenID Connect.

• Key Features:
  • Define OAuth scopes to specify what data the app can access.
  • Configure callback URLs for OAuth flows.
  • Control IP restrictions, session policies, and permitted users.
• Use Cases:
  • Allowing a mobile app to access Salesforce data.
  • Enabling third-party integrations with platforms like Slack and Google Workspace.
  • Providing Single Sign-On (SSO) for external applications.

Auth Provider

An Auth Provider in Salesforce allows the platform to utilize an external identity provider (IdP) for authentication purposes. It supports protocols such as OAuth 2.0, OpenID Connect, and SAML.

• Key Features:
  • Define the provider type (e.g., Salesforce, Google, Facebook, Azure AD).
  • Store client ID, client secret, authorization/token URLs.
  • Utilize registration handlers (Apex classes) for managing user provisioning.
• Use Cases:
  • Allowing Salesforce users to log in using Google, Facebook, or another Salesforce org.
  • Enabling Named Credentials for secure server-to-server callouts from Salesforce to external APIs.
  • Supporting SSO where Salesforce trusts an external IdP for authentication.

Named Credentials

Named Credentials provide a secure method to store authentication details for external callouts, such as REST or SOAP APIs, in Salesforce.

• Key Features:
  • Store the endpoint URL, authentication protocol (OAuth, Basic, JWT).
  • Automatically handle token refresh and credential rotation.
  • Simplify Apex callouts by referencing the Named Credential instead of hardcoding URLs or secrets.
• Use Cases:
  • Salesforce making callouts to external APIs like Google Maps, SAP, or AWS.
  • Securely managing credentials without exposing them in Apex code.
  • Combining with Auth Providers for OAuth flows.

How They Work Together

• Connected App: Represents an external app connecting into Salesforce.
• Auth Provider: Represents an external IdP that Salesforce trusts for authentication.
• Named Credential: Represents Salesforce making secure callouts to an external service.

Example Flow:

1. You build a Salesforce integration with Google APIs.
2. You configure an Auth Provider for Google (OAuth 2.0).
3. You create a Named Credential that uses the Auth Provider.
4. Your Apex code calls the Named Credential endpoint, and Salesforce automatically handles authentication.
5. If you want Google to call Salesforce, you configure a Connected App in Salesforce for Google.

Key Takeaways

• Connected Apps: External apps integrating into Salesforce.
• Auth Providers: Salesforce integrating out to external IdPs.
• Named Credentials: Salesforce securely storing credentials for outbound callouts.
• Together, they form the authentication and integration backbone of Salesforce.

The post Salesforce: Connected Apps, Auth Provider and Named Credentials first appeared on Vinod Sebastian - B.Tech, M.Com, PGCBM, PGCPM, PGDBIO.

Salesforce: Creating SOAP Web Service

Overview

In Salesforce, you can create SOAP (Simple Object Access Protocol) web services using Apex classes. SOAP web services allow external applications to interact with Salesforce by calling exposed methods via SOAP requests. This guide will walk you through the steps to create a SOAP web service in Salesforce.

Steps to Create a SOAP Web Service in Salesforce

1. Define a Global Apex Class

To create a SOAP web service in Salesforce, you need to define a global Apex class with methods that you want to expose to external systems.

global class AccountService {
    // Expose a method to create an Account
    webService static Id createAccount(String name, String phone) {
        Account acc = new Account(Name = name, Phone = phone);
        insert acc;
        return acc.Id;
    }

    // Expose a method to fetch Account details
    webService static Account getAccount(Id accountId) {
        return [SELECT Id, Name, Phone FROM Account WHERE Id = :accountId LIMIT 1];
    }
}

Explanation:

• Use the global access modifier to make the class accessible outside Salesforce.
• Use the webService keyword to expose methods as web services.

2. Generate the WSDL

WSDL (Web Services Description Language) is a standard XML format for describing web services and how to access them. In Salesforce, you can generate the WSDL for your web service.

Steps to generate the WSDL:

1. Go to Setup.
2. Navigate to Apex Classes.
3. Click on your class.
4. Click on “Generate WSDL”.

Download the generated WSDL file. External systems use this file to understand and interact with your SOAP web service.

3. Consume the Service

External applications that want to interact with your SOAP web service need to import the WSDL into their development environment, such as Java or .NET. They can then make SOAP requests to call the exposed methods like createAccount and getAccount.

4. Example SOAP Request

An example SOAP request to create an Account might look like:

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:acc="http://soap.sforce.com/schemas/class/AccountService">
   <soapenv:Header/>
   <soapenv:Body>
      <acc:createAccount>
         <name>Test Account</name>
         <phone>1234567890</phone>
      </acc:createAccount>
   </soapenv:Body>
</soapenv:Envelope>

5. Authentication

External clients interacting with your Salesforce SOAP web service must authenticate themselves. This can be done through the login() SOAP call or OAuth. After successful authentication, the session ID is passed in the SOAP header (SessionHeader) for subsequent calls to maintain a secure connection.

Key Concepts

Here are some key concepts to remember when creating SOAP web services in Salesforce:

• global keyword: It makes the class and methods visible outside Salesforce.
• webService keyword: Marks methods as callable via SOAP.
• WSDL file: Acts as a contract between Salesforce and external systems.
• Session ID: Ensures secure communication between Salesforce and external systems.
• Error Handling: Exceptions thrown in Apex are reflected in the SOAP fault response.

Conclusion

Creating SOAP web services in Salesforce using Apex classes allows you to integrate external systems with your Salesforce instance. By following the steps outlined in this guide, you can expose custom functionality or CRUD operations as SOAP methods, enabling seamless interaction between Salesforce and external applications.

Sources: Salesforce Developer Guide sample code

The post Salesforce: Creating SOAP Web Service first appeared on Vinod Sebastian - B.Tech, M.Com, PGCBM, PGCPM, PGDBIO.

Salesforce: Consuming SOAP Web Service

Importing the WSDL

Salesforce acts as the client calling an external SOAP web service. This process is achieved through Apex callouts using the WSDL (Web Services Description Language) provided by the external system.

• Obtain the WSDL file from the external SOAP service provider.
• In Salesforce Setup, navigate to Apex Classes → Generate from WSDL.
• Upload the WSDL file. Salesforce will then generate Apex classes (referred to as stubs) that represent the SOAP operations and data types defined in the WSDL.

Example Apex Code to Call External SOAP Service

Once the WSDL is imported and the Apex classes are generated, you can write Apex code to interact with the external SOAP service.

For instance, if the external SOAP service offers an operation like getWeather(city), Salesforce will create a stub class based on the WSDL, such as WeatherService.

public class WeatherConsumer {
    public static String getWeatherForCity(String cityName) {
        // Create an instance of the stub from the generated WSDL class
        WeatherServiceSoap ws = new WeatherServiceSoap();
        
        // Set the endpoint (can be from WSDL or overridden if necessary)
        ws.endpoint_x = 'https://api.example.com/soap/weather';
        
        // Call the SOAP operation
        String result = ws.getWeather(cityName);
        
        System.debug('Weather result: ' + result);
        return result;
    }
}

Authentication

Many SOAP services require authentication using credentials such as username/password, API key, or token. Salesforce-generated stubs typically include a SoapHeader class where you can set these credentials.

WeatherServiceSoap ws = new WeatherServiceSoap();
ws.inputHttpHeaders_x = new Map<String, String>();
ws.inputHttpHeaders_x.put('Authorization', 'Bearer YOUR_TOKEN');
// Or, if the WSDL defines a LoginHeader, you set it like:
WeatherService.LoginHeader header = new WeatherService.LoginHeader();
header.username = 'myUser';
header.password = 'myPass';
ws.SessionHeader = header;

Testing with Mock Data

When testing Salesforce code that interacts with external SOAP services, it is essential to use mock data to simulate responses. This is due to the restriction on making actual callouts during tests.

@isTest
private class WeatherConsumerTest {
    @isTest static void testGetWeatherForCity() {
        // Mock the SOAP response
        Test.startTest();
        // You can use HttpCalloutMock if the SOAP stub internally uses Http
        Test.setMock(HttpCalloutMock.class, new WeatherMock());
        
        String result = WeatherConsumer.getWeatherForCity('Cochin');
        
        Test.stopTest();
        System.assertEquals('Sunny', result);
    }
}

// Mock class
global class WeatherMock implements HttpCalloutMock {
    global HttpResponse respond(HttpRequest req) {
        HttpResponse res = new HttpResponse();
        res.setStatusCode(200);
        // Simplified SOAP response body
        res.setBody('Sunny');
        return res;
    }
}

Explanation

• WSDL Import: This step generates Apex classes (stubs) that represent the SOAP service based on the WSDL.
• Stub Usage: Instantiating the stub allows you to call its methods like regular Apex methods.
• Authentication: Authentication is often managed through SOAP or HTTP headers.
• Testing: Utilize HttpCalloutMock to mimic SOAP responses in test classes, as real callouts are restricted.

Key Takeaways

• Salesforce can consume external SOAP services by importing WSDLs and utilizing generated Apex stubs.
• Authentication mechanisms are typically required and can be managed via headers.
• Always incorporate mock-based test classes for SOAP callouts to ensure proper functionality.
• This approach is commonly used to integrate Salesforce with legacy systems that expose SOAP APIs.

The post Salesforce: Consuming SOAP Web Service first appeared on Vinod Sebastian - B.Tech, M.Com, PGCBM, PGCPM, PGDBIO.

Salesforce: Consuming REST Web Service

Overview

Salesforce can act as a client calling an external REST API by utilizing Apex callouts. This article provides a step-by-step guide on how to consume a REST service in Salesforce.

Step 1: Enable Callouts

To enable callouts in Salesforce, follow these steps:

• Add the external endpoint to Remote Site Settings by navigating to Setup → Security → Remote Site Settings. This step is crucial as Salesforce blocks callouts by default.

Step 2: Apex Code to Consume REST Service

Below is a simple example of Salesforce consuming a REST API through Apex:

public class RestConsumerExample {
    public static void getWeatherData(String city) {
        // Prepare the HTTP request
        Http http = new Http();
        HttpRequest req = new HttpRequest();

        // Example external REST API endpoint
        String endpoint = 'https://api.example.com/weather/' + city;
        req.setEndpoint(endpoint);
        req.setMethod('GET');

        // Add headers if needed (e.g., authentication)
        req.setHeader('Authorization', 'Bearer YOUR_ACCESS_TOKEN');
        req.setHeader('Content-Type', 'application/json');

        // Send the request
        HttpResponse res = http.send(req);

        // Handle the response
        if (res.getStatusCode() == 200) {
            System.debug('Response Body: ' + res.getBody());
        } else {
            System.debug('Error: ' + res.getStatusCode() + ' ' + res.getStatus());
        }
    }
}

Step 3: Parsing JSON Response

To parse JSON responses in Salesforce, you can use JSON.deserialize to convert JSON into Apex objects. Here’s an example:

public class WeatherResponse {
    public String city;
    public String temperature;
    public String condition;
}

public class RestConsumerExample {
    public static WeatherResponse getWeatherData(String city) {
        Http http = new Http();
        HttpRequest req = new HttpRequest();
        req.setEndpoint('https://api.example.com/weather/' + city);
        req.setMethod('GET');
        req.setHeader('Authorization', 'Bearer YOUR_ACCESS_TOKEN');

        HttpResponse res = http.send(req);

        if (res.getStatusCode() == 200) {
            WeatherResponse wr = (WeatherResponse) JSON.deserialize(res.getBody(), WeatherResponse.class);
            return wr;
        } else {
            throw new CalloutException('Failed with status: ' + res.getStatusCode());
        }
    }
}

Step 4: Test Class Example

It is essential to write test classes to validate the callout logic. Here’s a test class example:

@isTest
private class RestConsumerExampleTest {
    @isTest static void testGetWeatherData() {
        // Mock the HTTP response
        Test.startTest();
        HttpResponse res = new HttpResponse();
        res.setStatusCode(200);
        res.setBody('{"city":"Cochin","temperature":"30C","condition":"Sunny"}');

        // Use HttpCalloutMock to simulate the external service
        Test.setMock(HttpCalloutMock.class, new WeatherMock());

        WeatherResponse wr = RestConsumerExample.getWeatherData('Cochin');
        Test.stopTest();

        System.assertEquals('Cochin', wr.city);
        System.assertEquals('30C', wr.temperature);
        System.assertEquals('Sunny', wr.condition);
    }
}

// Mock class
global class WeatherMock implements HttpCalloutMock {
    global HTTPResponse respond(HTTPRequest req) {
        HttpResponse res = new HttpResponse();
        res.setStatusCode(200);
        res.setBody('{"city":"Cochin","temperature":"30C","condition":"Sunny"}');
        return res;
    }
}

Explanation

Here are some key points to remember while consuming REST services in Salesforce:

• Http & HttpRequest: Apex classes used for making REST callouts.
• Remote Site Settings: Required to whitelist external endpoints.
• Headers: Used for authentication such as Bearer tokens and API keys.
• JSON.deserialize: Converts JSON responses into Apex objects.
• Test.setMock: Necessary for unit testing callouts as Salesforce prohibits real HTTP calls in tests.

Key Takeaways

• Salesforce can function as a REST client using Apex callouts.
• Always configure Remote Site Settings for external endpoints to ensure smooth callouts.
• Utilize JSON.deserialize to effectively parse responses into Apex objects.
• Write mock-based test classes to validate the functionality of callouts.

The post Salesforce: Consuming REST Web Service first appeared on Vinod Sebastian - B.Tech, M.Com, PGCBM, PGCPM, PGDBIO.

Salesforce: Web Services

SOAP Web Services

SOAP (Simple Object Access Protocol) is a protocol-based web service that uses XML for messaging. Here are some key points about SOAP web services:

• Protocol-based: SOAP is a strict XML-based messaging protocol.
• Contract-driven: Requires a WSDL (Web Services Description Language) file that defines operations, types, and bindings.
• Features:
  • Strong typing and formal contracts
  • Built-in error handling via SOAP faults
  • Extensible headers (security, transactions, etc.)
• Use cases: SOAP Web Services are commonly used for enterprise integrations, legacy systems, banking applications, and scenarios that require strict standards and reliability.

REST Web Services

REST (Representational State Transfer) is an architectural style that is not protocol-based. It focuses on exposing resources through URLs and typically uses JSON or XML payloads. Here are some key points about REST web services:

• Architectural style: REST is not a protocol but a design style.
• Resource-driven: Exposes resources via URLs, typically using JSON or XML payloads.
• Features:
  • Lightweight and faster than SOAP
  • Uses standard HTTP verbs (GET, POST, PUT, DELETE)
  • Easier to consume with modern clients (JavaScript, mobile apps, etc.)
• Use cases: REST Web Services are suitable for modern APIs, mobile/web applications, and integrations where simplicity and speed are important.

Salesforce Context

Salesforce supports both SOAP and REST web services for integration and development. Here’s how Salesforce integrates with these web service types:

• SOAP: Salesforce allows the creation of Apex classes with webService methods which can be consumed via WSDL.
• REST: Salesforce supports Apex classes annotated with @RestResource, which can be consumed via HTTP endpoints returning JSON.

APIs in Salesforce

Salesforce provides various APIs to help developers interact with Salesforce programmatically. These APIs enable integration with external systems, automate business processes, and customize Salesforce functionalities.

Callouts

Salesforce callouts allow the execution of HTTP requests to external services from Apex code. These callouts are essential for integrating Salesforce with external APIs, sending data to third-party services, or fetching information from external sources.

The post Salesforce: Web Services first appeared on Vinod Sebastian - B.Tech, M.Com, PGCBM, PGCPM, PGDBIO.

Salesforce: Creating REST Web Service

Define the REST Resource Class

To create a RESTful web service in Salesforce, you need to define a REST resource class. Here is an example:

@RestResource(urlMapping='/AccountService/*')
global with sharing class AccountRestService {
    // GET method: fetch account details
    @HttpGet
    global static Account doGet() {
        RestRequest req = RestContext.request;
        RestResponse res = RestContext.response;
        
        // Extract accountId from the URL
        String accountId = req.requestURI.substring(req.requestURI.lastIndexOf('/')+1);
        Account acc = [SELECT Id, Name, Phone FROM Account WHERE Id = :accountId LIMIT 1];
        
        return acc;
    }
    
    // POST method: create a new account
    @HttpPost
    global static Id doPost(String name, String phone) {
        Account acc = new Account(Name = name, Phone = phone);
        insert acc;
        
        return acc.Id;
    }
    
    // DELETE method: delete an account
    @HttpDelete
    global static String doDelete() {
        RestRequest req = RestContext.request;
        String accountId = req.requestURI.substring(req.requestURI.lastIndexOf('/')+1);
        delete [SELECT Id FROM Account WHERE Id = :accountId LIMIT 1];
        
        return 'Account deleted successfully';
    }
}

The @RestResource(urlMapping='/AccountService/*') defines the endpoint where external clients can call URLs like https://yourInstance.salesforce.com/services/apexrest/AccountService/{Id}.

The @HttpGet, @HttpPost, and @HttpDelete annotations map Apex methods to HTTP verbs. The RestRequest and RestResponse classes provide access to request parameters, headers, and response handling.

Salesforce automatically serializes Apex objects, like the Account object, into JSON for responses.

Example REST Calls

Here are examples of REST calls you can make to interact with the Salesforce REST web service:

• GET Request:

GET https://yourInstance.salesforce.com/services/apexrest/AccountService/001XXXXXXXXXXXX
Authorization: Bearer

Response:

{
    "Id": "001XXXXXXXXXXXX",
    "Name": "Test Account",
    "Phone": "1234567890"
}

• POST Request:

POST https://yourInstance.salesforce.com/services/apexrest/AccountService/
Authorization: Bearer 
Content-Type: application/json
{
    "name": "New Account",
    "phone": "9876543210"
}

Response:

“001YYYYYYYYYYYY”

Below is an example test class for the AccountRestService class:

@isTest
private class AccountRestServiceTest {
    @isTest static void testDoPostAndGet() {
        // Simulate POST
        RestRequest req = new RestRequest();
        RestResponse res = new RestResponse();
        req.requestURI = '/services/apexrest/AccountService/';
        req.httpMethod = 'POST';
        RestContext.request = req;
        RestContext.response = res;
        
        Id accId = AccountRestService.doPost('Unit Test Account', '111222333');
        
        // Verify account created
        Account acc = [SELECT Name, Phone FROM Account WHERE Id = :accId];
        System.assertEquals('Unit Test Account', acc.Name);
        
        // Simulate GET
        req.requestURI = '/services/apexrest/AccountService/' + accId;
        req.httpMethod = 'GET';
        RestContext.request = req;
        Account fetched = AccountRestService.doGet();
        System.assertEquals(accId, fetched.Id);
    }
    
    @isTest static void testDoDelete() {
        Account acc = new Account(Name='Delete Me');
        insert acc;
        
        RestRequest req = new RestRequest();
        RestResponse res = new RestResponse();
        req.requestURI = '/services/apexrest/AccountService/' + acc.Id;
        req.httpMethod = 'DELETE';
        RestContext.request = req;
        RestContext.response = res;
        
        String result = AccountRestService.doDelete();
        System.assertEquals('Account deleted successfully', result);
        System.assertEquals(0, [SELECT COUNT() FROM Account WHERE Id = :acc.Id]);
    }
}

Key Takeaways

• REST services in Salesforce are built using Apex classes with @RestResource annotations.
• Methods are exposed via HTTP verbs such as @HttpGet and @HttpPost.
• Authentication is mandatory, with OAuth access token provided in the Authorization: Bearer header.
• Salesforce automatically serializes Apex objects into JSON for responses.
• Always write test classes to validate your REST logic and meet deployment requirements.

The post Salesforce: Creating REST Web Service first appeared on Vinod Sebastian - B.Tech, M.Com, PGCBM, PGCPM, PGDBIO.