1) What are the main differences between REST and SOAP APIs in Salesforce, and when would you choose one over the other?
Differences between REST and SOAP APIs:
Format and Simplicity:
REST API: Supports both JSON and XML formats. It is lightweight, easy to use, and well-suited for modern web and mobile applications.
SOAP API: Supports only XML format, which can be more complex to handle.
Protocol and Methods:
REST API: Uses standard HTTP methods such as GET, POST, PUT, DELETE, etc.
SOAP API: Relies on a strict XML messaging protocol and includes a WSDL (Web Services Description Language) file for communication.
When to Choose:
Choose REST API when simplicity, speed, and modern formats like JSON are needed.
Choose SOAP API when integration demands more robust error handling, advanced security, or backward compatibility with older systems.
2) What is Salesforce Connect, and in what scenarios would you recommend using it for integration?
Salesforce Connect is a feature that allows users to access and display external data within Salesforce without storing it in Salesforce databases. It uses external objects to map to external data tables and accesses data on demand in real time.
Scenarios for Using Salesforce Connect:
Large Data Volumes: When you have large datasets that you don't want to replicate in Salesforce.
Real-Time Data Access: When you need real-time access to the latest external data instead of working with stale data copies.
Efficient Data Retrieval: When only small amounts of data are needed at a time, minimizing the need for storage and replication.
Advantages:
Avoids data redundancy
Ensures up-to-date and accurate information
Simplifies integration with minimal data storage overhead
Example Use Case: A company might use Salesforce Connect to access customer data stored in an external ERP system, ensuring sales teams always have the most up-to-date order and account details without duplicating that data in Salesforce.
3) What is the Bulk API in Salesforce, and when should it be used?
The Bulk API is designed for handling large-scale data operations asynchronously. It supports insert, update, delete, upsert, and query operations in batches, making it ideal for processing thousands or millions of records efficiently.
When to Use:
When working with large data sets (e.g., over 2,000 records)
For data migrations or regular bulk updates
To optimize performance and avoid API call limits
4) What is a Connected App in Salesforce, and why is it important for integration?
A connected app in Salesforce is designed to enable external applications to integrate with Salesforce APIs securely.
For example:
- To use OAuth authorization for external apps, configure the connected app with appropriate OAuth settings
- For SAML single sign-on (SSO) flows, configure SAML settings.
5) What is Single sign-on (SSO)?
Single sign-on (SSO) is an authentication method that enables users to access multiple applications with one login and one set of credentials. For example, after users log in to your org, they can automatically access all apps from the App Launcher. You can set up your Salesforce org to trust a third-party identity provider to authenticate users. Or you can configure a third-party app to rely on your org for authentication.
6) What is the role of SAML in Salesforce Single Sign-On (SSO), and how does it work between two Salesforce orgs?
SAML (Security Assertion Markup Language) enables Single Sign-On (SSO) between applications. In a Salesforce SSO scenario, one Salesforce org acts as the Identity Provider (IdP), where the user logs in, and another Salesforce org acts as the Service Provider (SP), where the user is redirected after successful authentication. The IdP authenticates the user and sends a SAML assertion to the SP to grant access.
7) What is Just-in-Time (JIT) Provisioning in Salesforce, and how is it used in Single Sign-On (SSO)?
Just-in-Time (JIT) Provisioning in Salesforce is a feature that automatically creates or updates user accounts in the Service Provider (SP) org during the Single Sign-On (SSO) process. It simplifies user management by eliminating the need to pre-create user accounts in the SP org.
How JIT Works:
The Identity Provider (IdP) sends user information in a SAML 2.0 assertion during the authentication process.
Salesforce processes this information using a JIT handler (Apex class) or standard JIT settings.
If the user does not already exist in the SP org, a new user account is created in real-time.
Example Use Case:
In a multi-org setup, if a user logs in to an Identity Provider org but their account does not exist in the SP org, JIT creates the account dynamically based on the information provided in the SAML assertion.
8) What are SAML Request, SAML Response, and SAML Assertion in the context of Single Sign-On (SSO), and how do they function?
SAML Request:
When a user tries to access a Service Provider (SP), the SP sends a SAML Request to the Identity Provider (IdP).
This request asks the IdP to authenticate the user.
SAML Response:
After authenticating the user, the IdP sends a SAML Response back to the SP.
The response includes a signed SAML Assertion containing user details.
SAML Assertion:
A SAML Assertion is part of the SAML Response and asserts facts about the user, such as their username or email address.
The assertion is signed by the IdP to ensure its authenticity.
The SP validates this signature to confirm the integrity of the information.
How They Work Together:
The SAML Request initiates the SSO process.
The SAML Response conveys the authentication result.
The SAML Assertion provides the necessary user details to complete the authentication and grant access.
This process ensures secure, seamless user authentication between the Identity Provider and Service Provider.
9) What are the key steps involved in any OAuth authorization flow?
OAuth flows typically involve three main steps:
Access Request: The client app requests access to a protected resource
Token Issuance: The authorization server grants an access token to the client app
Token Validation: The resource server validates the access token and allows access to the protected resource
10) What makes the OAuth 2.0 JWT Bearer Flow secure, and when should it be used?
Security Features:
Uses a JSON Web Token (JWT) signed with a certificate, ensuring data integrity and authenticity
Eliminates the need to transmit sensitive user credentials or rely on interactive logins
Requires prior approval of the connected app, adding an additional layer of control
Use Case:
Ideal for server-to-server integrations where ongoing access to Salesforce resources is needed without user interaction
11) How can you integrate two Salesforce orgs using the Username-Password Flow, and what are the main steps involved?
The integration of two Salesforce orgs using the Username-Password Flow involves securely fetching data from one org (ORG B) and displaying it in another org (ORG A). This method leverages OAuth 2.0 for authentication and the Salesforce REST API for data retrieval.
Key Steps in Integration:
In ORG B:
Create a Connected App to allow authentication
Implement a RESTful Web Service to fetch data
In ORG A:
Configure a Remote Site Setting to allow outbound calls to ORG B
Create an Apex Controller to:
a) Authenticate with ORG B using the Username-Password Flow
b) Call the web service in ORG B to fetch the required data
Develop a Visualforce Page or LWC to display the retrieved information
12) What is the difference between a self-signed certificate and a CA-signed certificate?
The main difference lies in the issuer of the certificate:
Self-Signed Certificate: Created, signed, and issued by the entity it is intended for. It does not involve any external validation
CA-Signed Certificate: Created, signed, and issued by a trusted third-party Certificate Authority (CA), which verifies the identity of the applicant
Key Consideration: CA-signed certificates are more widely trusted but come with a cost, while self-signed certificates are free but may not be trusted by external systems.
13) What is the purpose of Salesforce Streaming API?
The Salesforce Streaming API enables real-time data updates using push technology and an event-driven architecture. It operates on an event-based model, allowing applications to subscribe to events and receive updates as they occur in near real-time.
14) What types of events are supported by the Salesforce Streaming API, and in which scenarios should it be used?
Types of Events Supported:
Generic Events: Legacy, for custom notifications.
PushTopics: Legacy, for changes in Salesforce records based on SOQL queries.
Change Data Capture (CDC): For tracking changes to Salesforce data records in real-time.
Platform Events: For high-volume, custom business event notifications.
When to Use the Streaming API:
Use Streaming API when real-time data updates are required to synchronize external systems with Salesforce data, such as in applications that react immediately to changes in data or business processes.
Note: PushTopics and generic events are legacy products with limited support. For new implementations, use Change Data Capture instead of PushTopics and Platform Events instead of generic events.
15) What are platform events in Salesforce?
Platform events are secure and scalable messages used to enable real-time communication between Salesforce and external apps, as well as within Salesforce itself, using an event-driven messaging architecture.
16) What is the difference between ReplayId and EventUuid in platform events?
ReplayId: A system-assigned field that identifies the position of an event in the event stream. It isn’t guaranteed to be unique, especially during Salesforce maintenance activities.
EventUuid: A universally unique identifier (UUID) introduced in API version 52.0 and later. It is always unique and should be used to identify a platform event message.
Example of Retrieving EventUuid:
Database.SaveResult result = EventBus.publish(event);
if (result.isSuccess()) {
System.debug('UUID=' + EventBus.getOperationId(result));
}
Using EventUuid ensures the identification of an event message across different scenarios, including maintenance activities.
17) What are the Apex governor limits for platform event triggers?
Although platform event triggers run asynchronously, the synchronous limits apply to platform event triggers. This is because Asynchronous limits are for long-lived processes, such as Batch Apex and future methods. Synchronous limits are for short-lived processes that execute quickly and platform event triggers are short-lived processes that execute in batches rather quickly.
Because a platform event trigger runs in a separate transaction from the one that fired it, governor limits are reset, and the trigger gets its own set of limits.
18) How can you configure the user and batch size for a platform event trigger?
You can override the default running user and batch size of a platform event trigger using PlatformEventSubscriberConfig via Tooling API or Metadata API.
Default Configuration: Runs as the Automated Process user with a batch size of 2000.
Custom Configuration: Specify a custom user and a batch size between 1 and 2000. Smaller batch sizes help avoid hitting governor limits.
19) What is the High-Volume Platform Event Hourly Publishing Allocation?
It specifies the maximum number of platform events that can be published in one hour. The limit is 250000 events per hour for Performance and Unlimited Editions.
20) What publishing methods count toward the hourly publishing limit?
Publishing methods include:
Apex
Pub/Sub API
REST API
SOAP API
Bulk API
Flows
Process Builder processes
21) What happens if you exceed the hourly publishing limit?
Events published beyond the limit will fail. Organizations must monitor and optimize their event publishing to stay within the allowed limits.
22) What is Change Data Capture (CDC)?
Change Data Capture is a streaming product in Salesforce that enables real-time integration with external systems. It notifies subscribed systems of data changes like record creation, updates, deletions, and undeletions, helping keep external systems in sync without periodic data exports or repeated API calls.
23) What types of objects support CDC?
CDC is available for all custom objects and a subset of standard objects. Each object has an associated ChangeEvent object, named ObjectNameChangeEvent for standard objects and ObjectName__ChangeEvent for custom objects.
24) Can CDC events be queried or modified?
No, ChangeEvent objects don’t support CRUD operations or queries. They are used to capture and publish changes but cannot be directly manipulated.
25) How does CDC handle security for fields in change events?
CDC respects field-level security, delivering only the fields a user has access to. However, it ignores record-level sharing settings and doesn’t include derived fields (e.g., formula fields) except for roll-up summary fields.
26) What is the RestRequest class in Salesforce, and what are some of its key methods?
The RestRequest class in Salesforce is used to access incoming requests in Apex REST web services. It provides several methods to handle different aspects of an HTTP request. Some key methods include:
headers: Returns the headers received by the request (Map<String, String>)
httpMethod: Returns the HTTP method used for the request (String), such as GET, POST, DELETE, etc.
params: Returns the parameters received by the request (Map<String, String>)
remoteAddress: Returns the IP address of the client making the request (String)
requestBody: Returns or sets the body of the request (Blob)
requestURI: Returns or sets everything after the host in the HTTP request string (String)
resourcePath: Returns the REST resource path for the request (String)
27) What is the RestResponse class in Salesforce, and what are some of its key methods?
The RestResponse class in Salesforce is used to pass data from an Apex RESTful web service method to the HTTP response. It has several key methods:
responseBody: Returns or sets the body of the response (Blob)
headers: Returns the headers to be sent in the response (Map<String, String>)
statusCode: Returns or sets the HTTP status code for the response (Integer). Common status codes include 200 (OK), 201 (Created), 400 (Bad Request), etc.
For example, if you want to change the default status code of a RESTful service response, you can modify the statusCode property of the RestResponse class, like setting it to 201 (Created) instead of 200 (OK).
28) What is the purpose of the @HttpGet annotation in Salesforce, and how is it used in Apex?
The @HttpGet annotation in Salesforce is used to expose an Apex method as a RESTful GET service. This annotation allows external systems to retrieve data from Salesforce by making an HTTP GET request to the defined URL. The method must be defined as global static within a class annotated with @RestResource. For example, a method annotated with @HttpGet can fetch records like an Account based on an ID provided in the request URL.
29) Can you explain how Salesforce handles multiple HTTP methods in a single Apex class, and what restriction exists regarding their usage?
In Salesforce, a single Apex class can expose multiple HTTP methods (GET, DELETE, POST, PUT, PATCH) through different annotated methods. However, each method can only be annotated with one of these HTTP methods—only one method per HTTP method type is allowed in a class. For example, you can have one method annotated with @HttpGet, another with @HttpPost, and so on, but you cannot have multiple methods using the same annotation (e.g., two @HttpGet methods in the same class). This ensures each HTTP action is uniquely handled by its corresponding method.
30) What are named credentials in Salesforce and how do they improve security when integrating with external services?
Named credentials in Salesforce provide a secure and declarative way to store and manage the authentication details (like usernames, passwords, or OAuth tokens) required for HTTP callouts to external systems. They allow developers to specify the endpoint URL and authentication parameters in one definition, simplifying the setup of authenticated callouts. Named credentials eliminate the need for remote site settings and ensure credentials are stored encrypted, enhancing security. They also make maintaining integrations easier—if an endpoint URL changes, only the named credential needs to be updated, and all related callouts remain functional without modifying the Apex codo.
No comments:
Post a Comment