All about Platform Events

Platform Events are used to deliver secure, scalable, and customizable notification within Salesforce or external app. Platform Event is based on Event-Driven Architecture. This is built in real time integration patterns in the Salesforce Platform which helps to reduce point-to-point integration.

Publishing platform event: 

We can publish the platform events in 3 ways:

1. Publish Events Messaging using APEX.
2. Publish Events Messaging using Declarative tools (Process Builder or Cloud Flow Designer Tool / Visual Work flow).
3. Publish Events Messaging using Salesforce API from external app.

Not supported in Platform event: 

1. The allOrNoneHeader API header is ignored when you publish platform events through the API.
2. The Apex setSavepoint() and rollback() Database methods aren’t supported with platform events.

Subscription in Platform Event: 

1. Apex triggers receive event notifications.
2. write an “after insert” Apex trigger on the event object to subscribe to incoming events.
3. Triggers receive event notifications from various sources—whether they’re published through Apex or APIs.
4. Visualforce and Lightning component apps receive events through CometD.
5. CometD is a scalable HTTP-based event routing bus that uses an AJAX push technology pattern known as Comet.
6. In an external app, you subscribe to events using CometD as well.

Defining Objects and fields in Platform Events: 

Platform events can be created just like the custom objects. The biggest difference between Platform events and Custom object is suffix name for the api name. In Platform events, its api name suffix with __e where the custom object appends __c suffix to create api name. Unlike with custom objects, we cannot update or delete event record, or view event records in Salesforce User Interface.

Platform Events support only following custom fields type,

1. Checkbox
2. Date
3. Data/Time
4. Number
5. Text
6. Text Area (Long)

 All about Outbound Messaging

Pros

• Outbound Message has in-built retry mechanism. 
• Messages will be queued locally. A separate background process performs the actual sending, to preserve message reliability
• If the endpoint is unavailable, messages will stay in the queue until sent successfully, or until they are 24 hours old. After 24 hours, messages are dropped from the queue.
• If a message cannot be delivered, the interval between retries increases exponentially, up to a maximum of two hours between retries.
• Messages are retried independent of their order in the queue. This may result in messages being delivered out of order.
• Source object may change after a notification is queued but before it is sent, so the endpoint will only receive the latest data, not any intermediate changes. Because a message may be delivered more than once, your listener client should check the notification IDs delivered in the notification before processing.

Security Considerations

• All Outbound messages are sent from Salesforce IP address. Make sure that Salesforce IP addresses are white listed in external system.
• Using SSL/TLS provides confidentiality while data is transported across the internet.
• You can pass user session Id in outbound messages so that external system can callback and update data back in salesforce.
• The organization Id is included in each message. Your client application should validate that messages contain your organization Id.

If your application (endpoint) server's SSL/TLS may be configured to require client certificates (two-way SSL/TLS), in order to validate the identity of the Salesforce server when it takes the role of client to your server. If this is the case, you can download the Salesforce client certificate from the Salesforce application user interface. This is the client certificate that Salesforce sends with each outbound message for authentication.

• From Setup, enter API in the Quick Find box, then select API.
• On the API WSDL page, click Manage API Client Certificate.
• On the Certificate and Key Management page, in the API Client Certificate section, click the API Client Certificate.
• On the Certificates page, click Download Certificate. The .crt file is saved in the download location specified in your browser.

Import the downloaded certificate into your application server, and configure your application server to request the client certificate. The application server then checks that the certificate used in the SSL/TLS handshake matches the one you downloaded.