Integration is very important for Salesforce applications. Streaming API is one of the important integration concepts. This post is about the top Salesforce Integration Interview Questions question.
Q.1 What is Streaming API?
Ans. Streaming API is used to push notifications (information, data, data changes, etc.) to clients. Notifications are sent from Salesforce to the client based on criteria that we define.
Let us take an example, when the server is down, you want to notify your agent to work on another server. We can use streaming API to notify agents.
Q.2 How to create a Streaming API?
We can build streaming API using multiple ways. Below are some important approaches to build streaming API.
- HTTP using long poll: Long poll is a method used by HTTP servers to hold a connection for a client until data becomes available on the server. If data is immediately available, the connection is not held.
- Comet over HTTP – Comet is a web application model in which a long-held HTTPS request allows a web server to push data to a browser, without the browser explicitly requesting it. The CometD framework is an implementation of the Bayeux protocol.
- XMPP – Designed for publish-subscribe on the web but is not HTTP-based. XMPP(Extensible Messaging and Presence Protocol) has a lot of functionality beyond what is needed to build a streaming API.
- HTML 5 Event Source: The EventSource interface is the web content’s interface to server-sent events. An EventSource instance opens a persistent connection to an HTTP server, which sends events in text/event-stream format. The connection remains open until closed by calling EventSource.close(). Server-sent events are unidirectional.
Q.3 What is push technology?
Ans. Push technology is an internet communication system in which the transaction request is generated by the central web server or publisher. Push technology is the opposite of pull technology, where the information transmission request is made by the clients or receivers.
Q.4 What is Bayeux Protocol?
Ans: Bayeux is a protocol for transporting asynchronous messages, primarily over HTTP.
Q.5 What is Message Reliability?
Ans. Message reliability provides for end-to-end guaranteed delivery and order of messages, regardless of how many intermediaries are involved, and how many network hops are required to deliver the message from the client to the service. Message reliability is based on an industry standard for reliable message-based communication that maintains a session at the transport level.
Q.6 What is Message Durability?
Ans. Durability keeps messages persistent for any suitable consumer to consume them.
Q.7 What is the difference between Streaming API and REST API?
REST API is a web service that follows a request-response pattern. User will make an individual request for information from the REST API and receive the appropriate data in a single response. After the response is sent back to the user, the connection closes only to be re-opened when the user makes another request to the API. REST APIs are perfect for users wanting a “snapshot” of data where the information does not change very frequently.
Streaming APIs maintain a persistent connection that continuously sends updated data to the user until the connection is terminated. Streaming APIs are perfect when a user needs to consume a constant flow of rapidly updating live data. The server repeatedly sends responses back with updated information until the connection is eventually closed
by the user.
Q.8 What is the difference between Streaming API and outbound message?
|Outbound messaging is primarily server-driven
|Streaming API is client-driven;
|If the server went down for some reason, and we bring it back up, it would have to wait for messages to be delivered from Salesforce, which could take significant time
|If the client is down for some reason and we bring it back up, we can replay the older message immediately. Bringing the external source up to date much quicker, and getting the messages in the correct order.
|Can only be sent to a single endpoint
|A limited number of subscribers per topic.
|It is strongly typed and uses XML
|It is loosely typed and uses JSON.
|Outbound Message has an in-built retry mechanism. If the endpoint is unavailable, messages will stay in the queue until sent successfully, or until they are 24 hours old.
|Salesforce stores PushTopic events, generic events, and standard-volume events for 24 hours and high-volume events for 72 hours. We can use EventBus.RetryableException to retry if something fails.
|It might be loose order of delivery.
|Streaming API are guaranteed for ordered delivery.
Q.9. What are the types of Streaming API?
1. Generic Events:
Generic events to send custom notifications that are not tied to Salesforce data changes. Like Broadcast notifications to a target set of users, specific teams, or your entire org.
2. Push Topic:
PushTopic events provide a secure and scalable way to receive notifications for changes to Salesforce data that match a SOQL query you define. Eg, Capture changes for the fields and records that match a SOQL query like capture closed cases.
3. Change Data Capture:
Receive near-real-time changes in Salesforce records, and synchronize corresponding records in an external data store. Like we want to update the external system when some data is changed in the salesforce system.
4. Platform Event:
Platform events are secure and scalable messages that contain data. Publishers publish event messages that subscribers receive in real-time. Use platform events to connect business processes in Salesforce and external apps through the exchange of real-time event data.
Q.10 What is the difference between Change Data Capture vs Push Topic?
Ans. Change data capture and Push topic both are used for data change events. Below is some difference in both events
|Change Data Capture
|We can subscribe via apex triggers
|We cannot subscribe using the apex trigger
|We cannot use filter subscriptions like giving only closed case.
|It supports filter subscription
|We can’t choose fields to include in event notifications for Salesforce record changes
|We can use fields to include in the event notification
|We can encrypt field data with Shield Platform Encryption
|We cannot encrypt field data with Shield Platform Encryption
|We have 3 days of the event retention period
|We can retain only 1 day
|We can create different versions of the event schema
|We cannot create a versioning schema