Salesforce Trailhead 2023 - Developer Intermediate

Learning Objectives

After completing this unit, you’ll be able to:

• Explain where User Interface API fits into the Salesforce Platform.

• Describe when to use User Interface API.

• Describe when not to use User Interface API.

Learning Objectives

After completing this unit, you’ll be able to:

• Install the Record Viewer sample app.

• Understand the structure of the Record Viewer app.

• View a record in the Record Viewer app.

Learning Objectives

After completing this unit, you’ll be able to:

• Install the Record Viewer sample app.

• Understand the structure of the Record Viewer app.

• View a record in the Record Viewer app.

Learning Objectives

After completing this unit, you’ll be able to:

• Make a request to User Interface API to get record data and metadata.

• Understand why and how to request form factors, layout types, and access modes.

• Understand why and how to request child records.

Learning Objectives

After completing this unit, you’ll be able to:

• Make a request to User Interface API to update a record.

• Describe what’s special about compound fields.

• Make a request to User Interface API to update a compound field.

Learning Objectives

After completing this unit, you’ll be able to:

• Make a request to User Interface API to get the default values to clone a record.

• Make a request to User Interface API to get the default values to create a record.

• Make a request to User Interface API to clone or create a record.

Learning Objectives

After completing this unit, you’ll be able to:

• Make a request to User Interface API to get all picklist values for a record type.

• Name the property that contains a map of an object’s dependent fields.

• Name the property that contains a list of a field’s controlling fields.

Learning Objectives

After completing this module, you will be able to:

• Describe the differences between web service and HTTP callouts.

• Authorize an external site with remote site settings.

Learning Objectives

After completing this module, you’ll be able to:

• Perform a callout to receive data from an external service.

• Perform a callout to send data to an external service.

• Test callouts by using mock callouts.

Test Callouts

There’s good news and bad news regarding callout testing. The bad news is that Apex test methods don’t support callouts, and tests that perform callouts fail. The good news is that the testing runtime allows you to “mock” the callout. Mock callouts allow you to specify the response to return in the test instead of actually calling the web service. You are essentially telling the runtime, “I know what this web service will return, so instead of calling it during testing, just return this data.” Using mock callouts in your tests helps ensure that you attain adequate code coverage and that no lines of code are skipped due to callouts.

YOUR CHALLENGE

Create an Apex class that calls a REST endpoint and write a test class.

To pass this challenge, create an Apex class that calls a REST endpoint to return the name of an animal, write unit tests that achieve 100% code coverage for the class using a mock response, and run your Apex tests.

• The Apex class must be called 'AnimalLocator', have a 'getAnimalNameById' method that accepts an Integer and returns a String.

• The 'getAnimalNameById' method must call https://th-apex-http-callout.herokuapp.com/animals/:id, using the ID passed into the method. The method returns the value of the 'name' property (i.e., the animal name).

• Create a test class named AnimalLocatorTest that uses a mock class called AnimalLocatorMock to mock the callout response.

• The unit tests must cover all lines of code included in the AnimalLocator class, resulting in 100% code coverage.

• Run your test class at least once (via 'Run All' tests the Developer Console) before attempting to verify this challenge.

Learning Objectives

After completing this module, you’ll be able to:

• Generate Apex classes using WSDL2Apex.

• Perform a callout to send data to an external service using SOAP.

• Test callouts by using mock callouts.

All experienced Apex developers know that to deploy or package Apex code, at least 75% of that code must have test coverage. This coverage includes our classes generated by WSDL2Apex.

YOUR CHALLENGE

Generate an Apex class using WSDL2Apex and write a test class.

Generate an Apex class using WSDL2Apex for a SOAP web service, write unit tests that achieve 100% code coverage for the class using a mock response, and run your Apex tests.

• Use WSDL2Apex to generate a class called 'ParkService' in public scope using this WSDL file. After you click the 'Parse WSDL' button don't forget to change the name of the Apex Class Name from 'parksServices' to 'ParkService'.

• Create a class called 'ParkLocator' that has a 'country' method that uses the 'ParkService' class and returns an array of available park names for a particular country passed to the web service. Possible country names that can be passed to the web service include Germany, India, Japan and United States.

• Create a test class named ParkLocatorTest that uses a mock class called ParkServiceMock to mock the callout response.

• The unit tests must cover all lines of code included in the ParkLocator class, resulting in 100% code coverage.

• Run your test class at least once (via 'Run All' tests the Developer Console) before attempting to verify this challenge.

Learning Objectives

After completing this module, you’ll be able to:

• Describe the two types of Apex web services and provide a high-level overview of these services.

• Create an Apex REST class that contains methods for each HTTP method.

• Invoke a custom Apex REST method with an endpoint.

• Pass data to a custom Apex REST method by sending a request body in JSON format.

• Write a test method for an Apex REST method and set properties in a test REST request.

• Write a test method for an Apex REST method by calling the method with parameter values.

Retrieve Data Using cURL

Every good developer should know at least three things: 1) how to make an animated GIF of yourself eating ice cream; 2) the value of pi to 25 decimal places; and 3) how to use cURL. The first two are beyond the scope of this module, so we’ll concentrate on the last one.

Test Your Apex REST Class

Testing your Apex REST class is similar to testing any other Apex class—just call the class methods by passing in parameter values and then verify the results. For methods that don’t take parameters or that rely on information in the REST request, create a test REST request.

Create an Apex REST service that returns an account and it's contacts.

To pass this challenge, create an Apex REST class that is accessible at '/Accounts/<Account_ID>/contacts'. The service will return the account's ID and Name plus the ID and Name of all contacts associated with the account. Write unit tests that achieve 100% code coverage for the class and run your Apex tests.

• The Apex class must be called 'AccountManager'.

• The Apex class must have a method called 'getAccount' that is annotated with @HttpGet and returns an Account object.

• The method must return the ID and Name for the requested record and all associated contacts with their ID and Name.

• The unit tests must be in a separate Apex class called 'AccountManagerTest'.

• The unit tests must cover all lines of code included in the AccountManager class, resulting in 100% code coverage.

• Run your test class at least once (via 'Run All' tests the Developer Console) before attempting to verify this challenge.

Learning Objectives

After completing this unit, you’ll be able to:

• Explain the difference between synchronous and asynchronous processing.

• Choose which kind of asynchronous Apex to use in various scenarios.

Learning Objectives

After completing this unit, you’ll know:

• When to use future methods.

• The limitations of using future methods.

• How to use future methods for callouts.

• Future method best practices.

YOUR CHALLENGE

Create an Apex class that uses the @future annotation to update Account records.

Create an Apex class with a method using the @future annotation that accepts a List of Account IDs and updates a custom field on the Account object with the number of contacts associated to the Account. Write unit tests that achieve 100% code coverage for the class.

• Create a field on the Account object called 'Number_of_Contacts__c' of type Number. This field will hold the total number of Contacts for the Account.

• Create an Apex class called 'AccountProcessor' that contains a 'countContacts' method that accepts a List of Account IDs. This method must use the @future annotation.

• For each Account ID passed to the method, count the number of Contact records associated to it and update the 'Number_of_Contacts__c' field with this value.

• Create an Apex test class called 'AccountProcessorTest'.

• The unit tests must cover all lines of code included in the AccountProcessor class, resulting in 100% code coverage.

• Run your test class at least once (via 'Run All' tests the Developer Console) before attempting to verify this challenge.

Learning Objectives

After completing this unit, you’ll know:

• Where to use Batch Apex.

• The higher Apex limits when using batch.

• Batch Apex syntax.

• Batch Apex best practices.

YOUR CHALLENGE

Create an Apex class that uses Batch Apex to update Lead records.

Create an Apex class that implements the Database.Batchable interface to update all Lead records in the org with a specific LeadSource. Write unit tests that achieve 100% code coverage for the class.

• Create an Apex class called 'LeadProcessor' that uses the Database.Batchable interface.

• Use a QueryLocator in the start method to collect all Lead records in the org.

• The execute method must update all Lead records in the org with the LeadSource value of 'Dreamforce'.

• Create an Apex test class called 'LeadProcessorTest'.

• In the test class, insert 200 Lead records, execute the 'LeadProcessor' Batch class and test that all Lead records were updated correctly.

• The unit tests must cover all lines of code included in the LeadProcessor class, resulting in 100% code coverage.

• Run your test class at least once (via 'Run All' tests the Developer Console) before attempting to verify this challenge.

Learning Objectives

After completing this unit, you’ll know:

• When to use the Queueable interface.

• The differences between queueable and future methods.

• Queueable Apex syntax.

• Queueable method best practices.

YOUR CHALLENGE

Create an Queueable Apex class that inserts Contacts for Accounts.

Create a Queueable Apex class that inserts the same Contact for each Account for a specific state. Write unit tests that achieve 100% code coverage for the class.

• Create an Apex class called 'AddPrimaryContact' that implements the Queueable interface.

• Create a constructor for the class that accepts as its first argument a Contact sObject and a second argument as a string for the State abbreviation.

• The execute method must query for a maximum of 200 Accounts with the BillingState specified by the State abbreviation passed into the constructor and insert the Contact sObject record associated to each Account. Look at the sObject clone() method.

• Create an Apex test class called 'AddPrimaryContactTest'.

• In the test class, insert 50 Account records for BillingState "NY" and 50 Account records for BillingState "CA". Create an instance of the AddPrimaryContact class, enqueue the job and assert that a Contact record was inserted for each of the 50 Accounts with the BillingState of "CA".

• The unit tests must cover all lines of code included in the AddPrimaryContact class, resulting in 100% code coverage.

• Run your test class at least once (via 'Run All' tests the Developer Console) before attempting to verify this challenge.

Learning Objectives

After completing this unit, you’ll know:

• When to use scheduled Apex.

• How to monitor scheduled jobs.

• Scheduled Apex syntax.

• Scheduled method best practices.

YOUR CHALLENGE

Create an Apex class that uses Scheduled Apex to update Lead records.

Create an Apex class that implements the Schedulable interface to update Lead records with a specific LeadSource. Write unit tests that achieve 100% code coverage for the class. This is very similar to what you did for Batch Apex.

• Create an Apex class called 'DailyLeadProcessor' that uses the Schedulable interface.

• The execute method must find the first 200 Leads with a blank LeadSource field and update them with the LeadSource value of 'Dreamforce'.

• Create an Apex test class called 'DailyLeadProcessorTest'.

• In the test class, insert 200 Lead records, schedule the DailyLeadProcessor class to run and test that all Lead records were updated correctly.

• The unit tests must cover all lines of code included in the DailyLeadProcessor class, resulting in 100% code coverage.

• Run your test class at least once (via 'Run All' tests the Developer Console) before attempting to verify this challenge.

Learning Objectives

After completing this unit, you’ll know:

• How to monitor the different types of jobs.

• How to use the flex queue.

Learning Objectives

After completing this unit, you’ll be able to:

• List the components of event-based software architecture.

• Explain the benefits of an event-driven software architecture.

• Describe use cases for the Platform Events feature.

• Describe the characteristics of a platform event.

Learning Objectives

After completing this unit, you’ll be able to:

• Define a platform event.

• Describe how platform event messages can be published.

• Use an Apex method to publish an event.

• Publish an event using clicks in a process or flow.

• Publish an event using REST API by inserting an sObject.

Learning Objectives

After completing this unit, you’ll be able to:

• Describe how to subscribe to platform event messages.

• Subscribe to an event on the platform and in external apps.

• Test platform events in an Apex test method.

• Subscribe to platform events via CometD.

YOUR CHALLENGE

Subscribe to a Platform Event in an Apex Trigger

Your Salesforce app uses a trigger to listen to events. Once your app receives the notification from the order system through the trigger, it creates a task to follow up on the order shipment.

• Create an Apex trigger named OrderEventTrigger for Order_Event__e. This trigger will be similar to the CloudNewsTrigger trigger, but operates on the Order_Event__e event and creates tasks instead of cases.

• If the order has shipped (event.Has_Shipped__c == true), create a task with the following values:

  • Priority: 'Medium'

  • Subject: 'Follow up on shipped order ' + event.Order_Number__c

  • OwnerId: event.CreatedById

  • (Note: You are assigning the task OwnerId to the same user who published the event. This step keep things simple so you don't have to perform any prerequisites.)

Learning Objectives

After completing this unit, you’ll be able to:

• Identify customizations that are safe to make directly in the production org.

• Define application lifecycle management.

• Explain why the use of the application lifecycle management process helps teams develop apps faster.

Learning Objectives

After completing this unit, you’ll be able to:

• Identify the three release categories and the kinds of changes that go in each category.

• Describe a change set.

• Explain why it’s important to track changes and dependencies for change set releases.

In this unit, Calvin and his colleagues begin applying the ALM process. As you read, consider the choices you’d make for your team. Then work through the modules listed at the end of this module to get familiar with the process so you can decide what works for you.

Learning Objectives

After completing this unit, you’ll be able to:

• Explain how using version control can benefit a change set release.

• Describe the similarities between the change set and org development models.

This unit describes why Calvin and his colleagues move to developing with code and a version control system. As you read through this unit, consider which choices you would make for your team. Get hands-on by working through the modules listed at the end of this module to learn the process and make the most informed decision about what will work for you.

Learning Objectives

After completing this unit, you’ll be able to:

• Identify key differences between package development and change set development.

• Describe what a package version is and how it helps you manage change in your org.

• Summarize why you don’t have to track Setup changes manually when using the package development model.

Learning Objectives

After completing this unit, you’ll be able to:

• Identify which development environment to use in each ALM step when working in the change set development model.

• Create a new sandbox.

• Establish a method for tracking changes made in a release.

Learning Objectives

After completing this unit, you’ll be able to:

• Create a change set, including any dependencies for your customization.

• Authorize a deployment connection to another environment.

• Upload a change set to an org.

• Describe when it’s necessary to clone a change set.

Learning Objectives

After completing this unit, you’ll be able to:

• Clone a change set.

• Validate a change set.

• Deploy a change set.

Learning Objectives

After completing this unit, you’ll be able to:

• Describe how you manage change using the org development model.

• Identify the tools that you need for org development.

• Explain the benefits of using a source control system.

Learning Objectives

After completing this unit, you’ll be able to:

• Create a branch and commit changes to a source control repository.

• Authorize a sandbox using Salesforce Extensions for VS Code.

• Retrieve changes from a sandbox.

Learning Objectives

After completing this unit, you’ll be able to:

• Convert your source to the proper format to deploy to production.

• Explain the commands used to deploy changes to your org.

• Describe how to speed up deployments with Quick Deploy.

Learning Objectives

After completing this unit, you’ll be able to:

• Describe what platform cache is and what it’s used for.

• List the two types of platform cache and give examples of each.

• Describe partitions and how to use them.

Learning Objectives

After completing this unit, you’ll be able to:

• Create a partition.

• Store and retrieve values in the org and session cache.

• Describe how long values last in the cache.

• Handle cache misses.

• Read session cache from a Visualforce page.

YOUR CHALLENGE

Create an Apex class that writes and reads from the org cache.

In this challenge, you’ll write an Apex class that writes and reads a bus schedule from the org cache. Your method for reading the cache has to handle cache misses.

• Create a partition called BusSchedule with 0 MB for the size of org cache and session cache. The 0 MB allocation enables you to test cache misses.

• Create a public Apex class called BusScheduleCache.

• Add this variable to the class: private Cache.OrgPartition part;

• In the constructor, create a new instance of Cache.OrgPartition by passing it the partition name (local.BusSchedule). Assign this object to the class variable (part).

• Add two public methods. a. The first method, putSchedule(), returns void and takes these parameters: String busLine, Time[] schedule. b. The second method, getSchedule(), returns a bus schedule as a time array (Time[]) and takes this parameter: String busLine.

• Implement the putSchedule() method so that it stores the passed-in values in the org cache by using the partition class variable (part).

• Implement the getSchedule() method so that it returns the schedule for the specified bus line by using the partition class variable (part).

• Add logic to the getSchedule() method to handle cache misses. If null is returned for the cached value, getSchedule() should return the following default schedule as a Time array with two Time objects: one Time object value of 8am and another of 5pm. Use the Apex Time.newInstance() method to create the Time objects.

Learning Objectives

After completing this unit, you’ll be able to:

• Explain a pattern for storing and refreshing cached data.

• Decide on the data structure to use for the cached value.

• Diagnose your cache usage.

Learning Objectives

After completing this unit, you’ll be able to:

• Describe what big objects are.

• Identify common use cases for custom big objects.

• Identify ways to query big objects.

Learning Objectives

After completing this unit, you’ll be able to:

• Create a custom big object.

• Build a custom index.

• Deploy a custom big object.

• Populate a big object.

Learning Objectives

After completing this unit, you’ll be able to:

• Use standard SOQL to query big objects.

• Use Async SOQL to query big objects.

• List the pros and cons of using Async SOQL over standard SOQL.