Salesforce Platform Developer 2
The Salesforce Platform Developer 2 certification is a credential developed for Salesforce professionals who have experience in implementing advanced programmatic solutions on the Salesforce platform and are looking to verify their expertise.
The exam is made up of 60 multiple choice questions
120 minutes to complete
The passing score is 70%
Platform Developer 1 certification is a prerequisite
Cost is USD $200 and the retake fee is USD $100 if you are unsuccessful
In Platform Developer 2, there are 8 topics covered. The topic with the highest weighting is Logic and Process Automation. As it is weighted at 20%, this is an area that you must focus on to do well in the exam.
Logic and Process Automation
Data Modeling and Management
Debug and Deployment Tools
Platform Developer 2 Weighting Chart
The following are the core topic areas of the Salesforce PD2 certification and what you’re expected to know:
In this section, you need to be familiar with the capabilities of the base system objects and know the capabilities and use cases for the various Salesforce development platforms.
Salesforce provides multiple objects for programmatically accessing information about an organization’s customizations. A developer can use Apex, SOQL or API calls to retrieve information such as an object’s sharing settings, change history or metadata. Developers can also create custom code for including Chatter functionality.
Salesforce offers two development platforms, The App Cloud which was recently renamed to Salesforce Platform which is Salesforce’s native suite of tools for developing applications as well as Heroku Enterprise. Heroku is a cloud-based Platform as a Service which supports multiple open-source languages and databases. Heroku Enterprise is tightly integrated with Salesforce, which makes it easy to deploy public-facing applications linked to Salesforce data.
In order to pass the data modeling and management section of the PD2 certification exam, you must be familiar with a variety of topics related to data management. They include being able to design code that can deal with situations that include multi-language, multi-locale and multi-currency, implications of compound data types when programming in Apex, use cases and benefits of external IDs and use cases for different types of custom metadata and custom settings.
Salesforce provides a number of tools for creating apps that can accommodate multiple languages, currencies and locales. Object and field label translations can be provided declaratively through the user interface by specified users. To ensure that information is displayed correctly to all users regardless of language, locale or preferred currency, developers should use functions and special label notations provided in SOQL, Visualforce and Apex.
You need to be aware of the implications of compound data types when programming in Apex. Salesforce natively uses 2 compound fields: Address and Geolocation. Each of these fields consists of multiple component fields which each store a portion of the information. Address fields store information about an address and are broken down into components such as street address, city, etc. Geolocation fields store GPS latitude and longitude coordinates. Geolocation fields can be added as custom fields to any object.
From a development standpoint, compound fields can’t be treated like other fields. In most cases, operations involving compound fields (such as displaying, updating or importing data from them) should be done using the individual components of the fields. There are also formula limitations when working with compound fields.
External IDs are primarily used to import data from external systems and for integrating external system data into Salesforce. They allow Salesforce developers and admins to maintain data relationships between internal and external objects.
You need to understand the use cases for different types of custom metadata and custom settings. Custom Settings and Custom Metadata Types are used to store values which don’t change frequently but need to be frequently referenced in Salesforce. The data from Custom Settings and Custom Metadata Types is pulled into the application cache, which allows for efficient access of the data and, in most cases, does not count toward SOQL limit. Both approaches support many different data types. Referencing Custom Settings and Custom Metadata Types in business logic makes customizations easier to maintain and read, and reduces the number of places where changes need to be made. Custom Metadata Types are a newer concept and are preferred over Custom Settings in many cases. However, there are scenarios in which Custom Settings are still the preferred approach.
The Logic and Process Automation topic is the highest weighted and section with the most objectives.
In the Performance section, you need to understand the common performance issues for user interfaces and the techniques to mitigate them. You also need to understand the what will impact query performance.
In this section, you are expected to know how to expose Apex classes as SOAP and REST web services. You also need to be able to use system classes to integrate with SOAP or REST based web services. Also included in the integration section is when and how to use metadata, streaming, and Analytics API to enhance Apex and Visualforce solutions.
Apex classes can be easily modified to make them accessible via REST or SOAP. This is done with a combination of keywords on the classes and exposed methods. REST exposed services also use an annotation at the class level to define the service endpoint, and annotations at the method level to define the expected HTTP format. On the other hand, methods in SOAP exposed services use a keyword instead of an annotation.
Salesforce provides built-in utilities to reduce the complexity of making web service callouts to SOAP or RESTful web services. Callouts to SOAP services are handled almost like regular method calls thanks to the WSDL2Apex utility. REST callouts are made with a combination of Http, HttpRequest and HttpResponse classes. Various classes also exist to help with parsing or creating JSON data for REST services.
In the Testing section you need to understand the best practices for unit testing in Apex. This includes how to apply different techniques to create test data and responses, the various ways to execute tests and how to specify test execution options. In regards to Visualforce, you need to understand the implications of testing Visualforce controllers and controller extensions.
There are a number of different types of best practices for unit testing in Apex. It is necessary to follow certain measures while creating unit tests to ensure that unit tests behave as expected and cover as many lines of code as possible. Certain practices can also be followed for creating test data to reduce dependency on organizational data. Also, since tests executed from the user interface run in parallel mode, it is important to know how to avoid errors caused by conflicts between tests.
Salesforce offers a variety of ways to create test data to help developers create unit tests to achieve the minimum-required 75% code coverage for deployment. Test setup methods annotated with @testSetup provide an easy way to create test data for all methods in a single test class. Test utility classes and test data stored as static resources allow for easy reuse of test data across test classes. Web service callouts can’t be tested directly, but Salesforce offers mock interfaces which can be used to simulate test callouts.
As Visualforce controllers and controller extensions are Apex classes, they should have code coverage to ensure total code coverage is at least 75%. Because controllers and extensions are designed to work with pages visible to an end-user, some special coding is required in their test classes to simulate user input from the page.
Apex code deployed to production must have a minimum of 75% code coverage. Multiple options are available both when writing Apex classes and test classes and when running the tests to allow for more flexible test execution. Apex tests typically run asynchronously, although this can be disabled via Setup. Although tests run in development normally run asynchronously, Apex tests that run as part of a deployment always run synchronously and serially.
In this section, you need to identify the appropriate tool to analyze application performance profiles and troubleshoot data and performance issues. Additionally you need to be able to identify the appropriate deployment tool for a particular scenario.
The most common causes of performance issues are inefficient queries, callouts, and DML statements causing cascading updates. Identifying which particular process is causing problems frequently involves the use of debug logs, which, when viewed with the right tools, can provide valuable insights into performance bottlenecks. Performance analysis typically begins on the client side with the help of tools such as Chrome Developer Tools, and continues to the server side, where debug logs and SOQL queries can be analyzed.
Salesforce offers a variety of deployment options, depending on the preferences of the person doing the deployment, deployment options offered by the tool, and what development tools and practices are used by an org. Some tools allow for deployment completely through a user interface, while others require the use of scripts.
Every topic objective explained thoroughly.
The most efficient way to study the key concepts in the exam.
Test yourself with complete practice exams or focus on a particular topic with the topic exams. Find out if you are ready for the exam.
Copyright 2019 - www.FocusOnForce.com
Copyright 2019 - www.FocusOnForce.com