My Top 10 Features for Developers in Summer’19 Release

Swayam Chouksey
9 min readMay 2, 2019
#Salesforce #LightningPlatform #Summer19 #BeReleaseReady

1. Fire Platform Events from Batch Apex Classes (Generally Available)

Batch Apex classes can fire platform events when an error or exception is encountered. A batch Apex class declaration must be using API version 44.0 or later to implement the Database.RaisesPlatformEvents interface and fire a platform event. A platform event record now includes the phase of the batch job (start, execute, or finish) when the error was encountered. The start and finish methods of the Database. The batchable interface now fires platform events on error (which they didn’t do in the beta release).

Where: This change applies to Lightning Experience and Salesforce Classic in Enterprise, Performance, Unlimited, and Developer editions.

How: To fire a platform event, a batch Apex class declaration must implement the Database.RaisesPlatformEvents interface.

public with sharing class YourSampleBatchJob implements Database.Batchable<SObject>, 
Database.RaisesPlatformEvents{
// class implementation
}

2. Make Long-Running Callouts with Continuations in Lightning Component

Use the Continuation class in Apex to make a long-running request to an external web service from an Aura component or a Lightning web component. Process the response in a callback method. An asynchronous callout made with a continuation doesn’t count toward the Apex limit of 10 synchronous requests that last longer than five seconds. Therefore, you can make more long-running callouts and integrate your component with a complex back-end API.

Where: This change applies to Aura components and Lightning web components in Lightning Experience, Salesforce Classic, Lightning communities, and all versions of the Salesforce app.

How: Continuations can lead to multiple long-running actions, so be aware of these limits when using them.

Up to three callouts per continuation single Continuation object can contain a maximum of three callouts. Serial processing for continuation actions framework processes actions containing a continuation serially from the client. The previous continuation action call must have completed before the next continuation action call is made. At any time, you can have only one continuation in progress on the client.DML operation restrictions Apex method that returns a Continuation object can’t perform Data Manipulation Language (DML) operations. DML statements insert, update, merge, delete, and restore data in Salesforce. If a DML operation is performed within the continuation method, the continuation execution doesn’t proceed, the transaction is rolled back, and an error is returned. You can perform DML operations in the Apex callback method for the continuation.

3. Configure Your Component for Different Devices

If your Lightning component is used on a Lightning page, you can declare which form factors your component supports: desktop, phone, or both. For example, on an app page — which supports both desktop and phone — you can now configure a component to only render when that app page is viewed on a particular device. If you restrict form factor support for your component to phone only, the app page drops the component when the page is viewed on desktop, and displays it when the page is viewed on a phone.

Where: This change applies to Aura components and Lightning web components in Lightning Experience and all versions of the Salesforce mobile app.

How: To designate which device form factors an Aura component supports, use the design:suppportedFormFactors tag set the component’s design file. The design:suppportedFormFactor subtag supports the type attribute. Valid type values are Large(desktop) and Small (phone).

This “Hello World” component design file adds support for both desktop and phone form factors.

<design:component label="Hello World">
<design:attribute name="subject" label="Subject" description="Name of the person you want to greet" />
<design:attribute name="greeting" label="Greeting" />
<design:supportedFormFactors>
<design:supportedFormFactor type="Large"/>
<design:supportedFormFactor type="Small"/>
</design:supportedFormFactors>
</design:component>

4. Limit User Access When Delegating Access to Metadata (Generally Available)

Enable users to read and update metadata through Metadata API without assigning more access than necessary. Metadata API is used for deployments using change sets, the Ant Migration Tool, or the Salesforce CLI. The Modify Metadata through Metadata API Functions user permission doesn’t impact the direct customization of metadata using Salesforce Setup pages, because those pages don’t use Metadata API for updates.

Who: Users with the Modify Metadata through Metadata API Functions permission must also have the permission that enables use of the feature supported by the metadata they’re trying to modify. Users must also have the permission that enables their deployment tool (change sets, the Ant Migration Tool, or the Salesforce CLI). The Modify Metadata through Metadata API Functions permission allows users to deploy Apex metadata, but if a user includes some Apex development and debugging features they still need the Modify All Data permission.

How: The Modify Metadata through Metadata API Functions permission is enabled automatically when either the Deploy Change Sets or the Author Apex permission is selected. The Modify Metadata through Metadata API Functions permission also includes read and update access to Apex when the user also has the Author Apex permission enabled.

5. Monitor Custom Metadata Type Use in System Overview

Understand your current custom metadata type usage pattern to plan for future custom metadata type work. You can now view custom metadata type usage in System Overview. You can get information about the number of custom metadata types and the size of the custom metadata type records used in your org.

Where: This change applies to Lightning Experience and Salesforce Classic in Professional, Enterprise, Performance, Unlimited, Developer, and Database.com editions. Professional Edition orgs can create, edit, and delete custom metadata records only from types in installed packages.

How: From Setup, enter System Overview in the Quick Find box, and then select System Overview.

6. Store More and Larger Debug Logs

We raised the maximum size of a debug log from 5 MB to 20 MB. With the 20 MB limit, 99.99% of debug logs aren’t truncated. We also raised the limits for debug log storage per org and debug logs that you can generate in a 15-minute window from 250 MB to 1,000 MB.

Where: This change applies to Lightning Experience, Salesforce Classic, and all versions of the Salesforce app in Enterprise, Performance, Unlimited, Developer, and Database.com editions.

7. Process Change Event Messages in Apex Triggers

With Apex change event triggers, you can now process change event messages on the Lightning Platform. Change event triggers run asynchronously after the database transaction is completed. Perform resource-intensive business logic asynchronously in the change event trigger and keep transaction-based logic in the Apex object trigger. By decoupling the processing of changes, change event triggers can help reduce transaction processing time.

Where: This change applies to Lightning Experience and Salesforce Classic in Enterprise, Performance, Unlimited, and Developer editions.

How: Each change event processed in the trigger contains the record fields and metadata information about the change in header fields.

A change event trigger is an “after-insert” trigger, defined with the after insert keyword. The trigger fires after the change event message is published. You create an after-insert trigger in the Developer Console the same way you create an Apex object trigger. When you create a trigger, pick the change event object from the sObject dropdown, which is populated with the change events available in your org. For a supported standard object, the change event name is StandardObjectNameChangeEvent. For a custom object, the change event name is CustomObjectName__ChangeEvent.

Example: This trigger shows a simple change event trigger on AccountChangeEvent.

trigger MyAccountChangeTrigger on AccountChangeEvent (after insert) {
for (AccountChangeEvent event : Trigger.New) {
// Process event messages
}
}

Testing Change Event Triggers

Before you can package or deploy Apex change event triggers to production, you must provide Apex tests and sufficient code coverage.

To test change event triggers, enable the generation of change event notifications for the test method.

Test.enableChangeDataCapture();

The Test.enableChangeDataCapture() method ensures that Apex tests can fire change event triggers regardless of the entities selected in Setup. This method doesn’t affect the Change Data Capture entity selections for the org.

After performing DML operations, deliver the event messages to the corresponding trigger with:

Test.getEventBus().deliver();

Alternatively, if you use the Test.startTest(), Test.stopTest() method block in your test, change event messages fire the associated trigger after Test.stopTest() executes.

Example: This test method outlines the order of statements that must be executed in a test, starting with enabling Change Data Capture entities.

@isTest static void testChangeEventTrigger() {
// Enable all Change Data Capture entities for notifications.
Test.enableChangeDataCapture();

// Insert one or more test records
// ...

// Deliver test change events
Test.getEventBus().deliver();

// Verify the change event trigger’s execution
// ...
}

8. Choose the Publishing Behavior for Your Platform Event

When you define or modify a platform event, you can choose when the platform event message is published in a Lightning Platform transaction. Choose to have the event message published only after a transaction is committed or immediately when the publish call executes. Previously, platform event messages were published immediately.

Where: This change applies to Lightning Experience and Salesforce Classic in Enterprise, Performance, Unlimited, and Developer editions.

Why: Choose to publish after a transaction is committed if subscribers rely on data that the publishing transaction commits. For example, a process publishes an event message and creates a task record. A second process that is subscribed to the event is fired and expects to find the task record. For this scenario, choose the post-commit publishing behavior for the platform event. Another reason for choosing this behavior is when you don’t want the event message to be published if the transaction fails.

Choose to publish immediately if you want the event message to be available regardless of whether the transaction succeeds. Also choose this publishing behavior if the publisher and subscribers are independent and subscribers don’t rely on data committed by the publisher. For example, the immediate publishing behavior is suitable for an event used for logging purposes.

How: You can define the publishing behavior in Setup or through Metadata API. In Setup, enter Platform Events in the Quick Find box, then select Platform Events. Add a platform event or edit an existing one.

In Metadata API, set the new publishBehavior field on the CustomObject type to a valid value.

For platform events created before Summer ’19, the publish behavior remains publish immediately.

9. ConnectApi (Chatter in Apex): New and Changed Classes

Create custom experiences in Salesforce using Chatter in Apex. Get mission activity progress for a user and do more with social posts.

Many Chatter REST API resource actions are exposed as static methods on Apex classes in the ConnectApi namespace. These methods use other ConnectApi classes to input and return information. The ConnectApi namespace is referred to as Chatter in Apex.

In Apex, you can access some Chatter data using SOQL queries and objects. However, it’s simpler to expose Chatter data in ConnectApi classes, and data is localized and structured for display. For example, instead of making several calls to access and assemble a feed, you can do it with a single call.

10. Process Smaller Event Batches in Platform Event Triggers and Recover from Exceptions

Set a checkpoint in the event stream for where the platform event trigger resumes execution in a new invocation. If an Apex governor limit is hit or another uncaught exception is thrown, the checkpoint is used during the next execution of the trigger. Trigger processing resumes after the last successfully checkpointed event message. You can also set a checkpoint to explicitly control the number of events processed in one trigger execution.

Where: This change applies to Lightning Experience and Salesforce Classic in Enterprise, Performance, Unlimited, and Developer editions.

Why: By processing fewer event messages, your trigger is less likely to hit Apex governor limits. The maximum batch size of a platform event trigger is 2,000, while the maximum of an Apex object trigger is 200. Therefore, platform event triggers are more likely to reach limits and can benefit from this feature.

How: To set a checkpoint for trigger resumption, set the replay ID of the last successfully processed event message using the setResumeCheckpoint(replayId) method. When the trigger stops its flow of execution, either intentionally or because of an unhandled exception, such as a limit exception, it fires again with a new batch (the sObject list in Trigger.New). The new batch starts with the event message after the one with the replay ID that you set. The setResumeCheckpoint(replayId) method doesn’t cause the trigger execution to stop, but you can end the execution explicitly. For example, to control the batch size, end the execution flow after a certain number of event messages are processed.

Example: This trigger sets the replay ID of the last processed event message in each iteration. If a limit exception occurs, the trigger is fired again and resumes processing starting with the event message after the one with the set replay ID.

trigger ResumeEventProcessingTrigger on Low_Ink__e (after insert) {
for (Low_Ink__e event : Trigger.New) {
// Process the event message.
// ...

// Set the Replay ID of the last successfully processed event message.
// If a limit is hit, the trigger refires and processing starts with the
// event after the last one processed (the set Replay ID).
EventBus.TriggerContext.currentContext().setResumeCheckpoint(event.replayId);
}
}

There are lot many other features as well, Official release notes are available HTML format as well as PDF file.

Say Hello To Me On: Twitter | Facebook | Linkedin | MyBlog | Blogger | MyWebsite

#HappyLearning #Platform #SalesforceDeveloper #BeReleaseReady #Salesforceguy

--

--

Swayam Chouksey

Accomplished Salesforce Technical Architect | Technology Advisor @ mindZcloud Enterprise | Co-Founder @ SFDCMINDZ 🇮🇳 🇺🇸