CRT-450 Salesforce Certified Platform Developer – Process Automation and Logic – 38% Part 4

26. 3.12- Exception Handling – Demo

So I will go to the developer console and then I will open the execute anonymous window. And now let me type some code that will throw an exception. So I will create a variable of type integer and it’s called i. And then I will create another variable that is called a of type integer. And I will reference the Ivariable that is null. So what will happen now? I will get a null pointer exception because I’m trying to reference a variable that is null. Now let me try to create an S object and I will try to insert this without specifying the mandatory fields. Let’s see what will happen. I will get a DML exception. So in the first example I got an Alpointed exception, and in the second example I got a DML exception. Now, how can we fix this? Let me proceed this with some accord and then I will use the tricatch finally block. Now, let me get rid of this. Let me specify the generic exception for now. So control A and shift tab. So now what happens? I have a system that debug before the try block.

And then I have inside the try block the code that will cause the exception. This line will cause the exception. And then I have a catch block. So executing this, I will have the code executing. And then if I open the debug log, I will have the first line and the line and the catch block. So notice here, if I don’t have any tricatch, so let me remove this. I will have an Alponter exception and even the first line will not execute. What I can do more, I can add a statement here, and then I can also add another statement after the catch block. So what will happen? Now the first line will execute. This will execute because an exception occurred and this will also execute. But this will not execute because this is after the exception. Let me also add another line and the try block before the exception. So this is endertride before the exception. So let’s see what will happen. Now. The code will run. What I will get, I will get the line before the try catch finally block, the line before the exception and the try block, the line and the catch block because an exception has occurred and the line after the try catch finally block. Let me make this a little bit bigger. Now let me add more than one exception type. So what I will do, I will copy this.

So what I will put here, I will put a null pointed exception and it will cause this block to run. So the catch statement will catch it because it is an unpointed exception. But this will not run because a catch already ran. So there you go. Null pointer exception occurred, and I don’t have the generic one. And now let me try to add another exception type in this case, I will add a DML exception. And let me try to run this. Let’s see what would happen. What happened? I got the first exception, but I just got an all pointed exception occurred. I did not get the second one. Why? Because if I go back to the code, this line caused the exception and it will cause this catch block to run. And as we have stated, anything after this will not run. So this is just to show you that even if I have two exceptions in the same try, only one will run. Now, let me try to remove this. Let’s see what will happen now. There you go. Generic exception occurred. And also, hello, word occurred because this is from the trigger, as you can recall. So I got this exception. Why? Because this is not an Alponta exception.

This is a generic exception. If I have here a diml exception, this will run. But this will not run. Now, let me create a custom exception class. So file new Apex class and let me call it my exception. And this class extends the exception class by default because it ends with the word exception. I will save it and then I will open the execute anomalous window and let’s see how we can throw an exception. So let’s see what will happen. Now, if I execute this, I will get the error. Of course, I can use this anywhere in my code. So this was the exception handling lecture. In this lecture, we have talked about exceptions. What’s the difference between an error and an exception? What is the try catch? Finally, a statement and how Apex handles exception. We have also talked about the different types of exceptions. We have talked about building our own exception and throwing an exception in our code. And finally, we went into salesforce. And I have shown you exceptions in action. And we have also built a custom exception and we have used it to throw an exception. And finally, as usual, thanks for watching.

27. 3.13- Security in Apex

In this lecture we will talk mainly about the different aspects of security and Apex. What is system mode and what is user mode, what is declaring a class using the with sharing keyword and what is declaring a class using the without sharing keyword. And also how to restrict access to some Apex classes. And finally, I will go to salesforce and I will show you some of these. First of all, in Salesforce, the organization data in the database is accessed in one of two different modes. First of all, we have the system mode and then we have the user mode. Let’s talk about this. The system mode access allows the code to access all the records in the database. Even if the user executing this code does not have access to these records, it ignores the sharing model and it is a systemwide record access. So in this mode, if you are executing an Apex code, if you are a user and you are executing an Apex code, you will have access to each and every record and the salesforce. org. You don’t have restrictions based on your permissions, based on your profile. You are executing the code as if you are a system admin. But in contrast, the user mode access limits code access to only records that the user executing the code has access to, just like when the user access records using the graphical user interface. So it respects the sharing model and it is a user record access.

So in this mode and the user mode, when you execute any Apex code, you are limited to the records that you have access to. So this is the difference between system mode and user mode. And system mode code execution has access to all the salesforce records, but end user mode code execution has access to only the records of the user executing the code. So in salesforce, what will run in system mode and what will run in user mode? First of all, triggers. Triggers will run in system mode. So if you are using a trigger, if a trigger gets executed, it will run in system mode and it will have access to all the salesforce records. It’s not restricted by the users records. And then we have custom web services will also run in system mode. Test classes were run in system mode. VisualForce controllers were run in system mode if it is a custom controller and in user mode if it is a standard controller.

VisualForce controller extensions depends on whether they are extended by custom controllers or in this case, they will run in system mode. And if they are extended by a standard controller, they will run a user mode. Anonymous block will run a user mode. So if you open the developer console and you hit Control plus e to open the execute anonymous window and you write some Apex code, this code will run end user mode. And finally, custom Apex class will run in either system mode or end user mode. This will all depend on the class definition. So if you use Without Sharing, when you define a class, the class will run in System Mode. But if you use the Wood Sharing keywords, when you define a class, the class will be in User Mode. So in conclusion, all Apex code were run in System Mode and it will ignore the users permissions and the user’s access to records. But we have exceptions. First of all, the execute anonymous block will run in user mode. The standard controller and its extensions were run also in User Mode. And finally, if you define an Apex class using the Wood Sharing keyword, this will run in User Mode. Now, let’s talk about the class definition. This is how we can define a class. This is the syntax of a class definition. We have, first of all the access modifier, and then we have Optional, Virtual or Abstract. And then we have class. And then class name? And then we have implements an interface or extends another class. We have seen all of these, but we have not seen yet the With Sharing and the Without Sharing keywords. We use the With Sharing and the Without Sharing keywords on a class to specify whether or not to enforce sharing rules when the class executes.

So we use these to specify if the class were run in System Mode or in User Mode if with or Without Sharing are not mentioned. So if we don’t mention anything, the default will be the Without Sharing. Now, if we use the Without Sharing keyword and a class definition, this means that this class will be running in System Mode and it means that the Apex code has access to all of the records of salesforce. But in contrast, if we use the With Sharing keyword, this means that this class will run in User Mode and it will respect the users access to the records. So if we have a user who is accessing this class that is using the With Sharing keyword, this means that he will only be able to access the records that he has access to. So he can only modify the records that he can modify on the DUI. He can only read the records that he can read on the DUI. So this is exactly as in the DUI.

So now, when a class will extend another class, or when a class will implement an interface, it will inherit the With Sharing or the Without Sharing that is set on the parent class and on the interface, an inner class will not inherit the sharing setting from the container class. And a class declared as With Sharing can call code that operates as Without Sharing. So, if a class is set with the With Sharing keyword, and if this class is calling another method and another class that is using the Without Sharing keyword, this class will have access to the record of this other class. And finally, using the with sharing keyword, SoCal and SOSL queries will return a fewer rows, or we can say they may return a fewer rows. Why? Because the access is much more restricted in this case.

And some DML operation may also fail because of insufficient privileges for the current user. So if you are a user and you are executing a DML operation on a record that you cannot modify, this DML operation will fail. So to conclude the with sharing and the without sharing keywords, to prevent the security leakage and to make sure that each user will only have access to his own records, always use the with sharing keyword and the class definition. And if you want to have a class accessing all of the records, use the without sharing. You can also specify which users can execute methods in a top level class based on their user profile or on the permission set.

So, using the profiles, you can say that this profile can access this class, but that profile cannot access that class. You can only set security on Apex classes, but you cannot set any security on Apex triggers. So you can restrict the access based on the profiles and on the permission set to Apex classes, but you cannot do that on Apex triggers. We have many options that we can use to set security on Apex classes. First of all, in setup menu, we can go to the Apex classes link and then next to the class name we can click on the security link and then we can add and remove the allowed profiles. On this class, we can do the same, but in this case, we can select the class. We can click on the class and then we can go to the security part and then we can add and remove the allowed profiles. We can also create a permission set that will allow access to certain classes. And then we can give this permission set to some users. And finally, we can change the security of an Apex glass from the profile itself. We can go to the profile and we can specify which glasses this profile will have access to.

Let’s go to salesforce and let’s see these in action. First of all, in Salesforce, what I did, I created another user account. So under users, I created another user. This is the user. The name is John Smith and this user has the profile standard user. And then I went to the sharing settings and I edited the wide default and I made the account and the contact objects private, which means that any owner will only see his own account. And finally, I did allow the login as I went to the login access policies. And there I checked this box and using that I can log in as another user from this page. And I went to the session settings and I did uncheck this because I don’t want to relog in after logging in as another user. So now if I go to the second user using the login ads, I can see that this user has zero accounts. So he cannot see any of my account, any of the first users account.

Now let’s open the developer console. Let me first log out of this and I will open the developer console and let’s open the class that we have made, which is the account trigger handler and the trigger itself. So we have created this handler. It has two methods until now. It has the handle before insert and it has the handle after insert and this is the trigger on the account object. So now if I create a new account, this will be fired and this also will be fired. So before insertion I will have this in the description field and after insertion I will have a new task. Let me change this, let me remove this and I will add a new list of accounts that will run a sockwell query that will fetch all of the accounts of salesforce. So now handle after insert will do this and then it will use a for each loop. To do what? To change a field.

So let me go to salesforce, let me open the account object, let me open any account and let’s say I will take the employees field. What’s the employee API name? This is the API name. So let me copy this and I will go back to the developer console and I will change this to, let’s say 100. So what will happen now? Using this I will have a sockwell query that will fetch all of the accounts and then it will set this field to 100 and then it will update the old ACC list. So now if I create a new account, all of the accounts of salesforce will be updated by using this field. So this field will be 100. So let me click on save control s and now I will go back to salesforce. I will go to setup users login as John Smith account and new, what would happen now if I click on save what we will have? We will have this and we will have that. Why we have these but we don’t have any task.

Why? This is due to the before insert method and this is due to the after insert method. So this is the before insert method and this is the after insert method. But note, if I log out from John Smith and I open any of my accounts which John Smith does not have access to, notice that this was also set. Why? Because this class is by default a without sharing class. As we have mentioned, if we don’t specify any with sharing or without sharing, the default will be without sharing. So this class will have access to all of the salesforce records. So this sock will query will also have access to all of the accounts record, including the accounts that John Smith does not have access to. So this trigger was triggered by an account creation by John Smith.

But this sockwell query ran on all of the accounts of the system and it updated all of the accounts, including my own accounts, which John Smith does not have access to. How we can fix this, we can specify with sharing before the class dealt. So now calling any method inside this class will enforce the respect of the record access. Let me change this slightly and let me put this 200 controll s. Now, if I go to John Smith and I do create another account, what should happen now? So I will call this test account Y. This was set and this was also set. And let’s see the other accounts of adjustment. So we’ll go to the account test account X. And as we can see, this field was also set. But if I log out and I log in as this user and I open any account, let’s say this account, as you can see, this is not affected.

So this was affected by the first example. But in the second example this was not affected. It’s still 100. So this did not fire in the second example. Why? Because this is now a with sharing class. So this is briefly with sharing versus without sharing. Always use the with sharing to enforce access to records and to prevent security leakage. And if you want the class to access all the records, use the without sharing. Now, let me show you how to prevent access to some Apex classes. Let me go to the different options. So if I go to the Apex classes and I open any class, let’s say this class, and I click on the security button, I can specify which profile has access to this class. I can also click on the security link here. So instead of going to the class itself and then clicking on the security button, I can access the security directly from here. I can also set this using the profiles and the permission sets.

So in the profile page, let me open any profile. And there you can click on the Apex class axis and you can edit the access. And you can do the same using a permission set. So I click on the Permission sets link and then I do create a new one. And there I will allow access to this class. And finally, I will assign this permission set to users. And finally in this lecture, we have explained basic security features of Apex. We have explained the difference between System Mode and User mode and which staff use the System mode and which use the User mode. We have explained the difference of the with sharing keyword and the without sharing keyword when defining a class. And we have also explained how to give access to a class using our setup menu. And finally we went into salesforce and we showed you some of these in action. And finally, as usual, thanks for watching.

28. 3.14- Apex Impact on Declarative Changes

In this lecture we’ll talk about how coding and Apex impacts declarative changes. First of all, as a rule of thumb, you have to always try to use declarative customization first before even thinking about Apex and triggers when faced with the business case with the business requirement. Let’s say when your boss comes to you and ask you to implement something in Salesforce, you have to first think which declarative tool in Salesforce might implement this requirement. So why declarative customization is the first option? Why not jump into Apex and into triggers in the first steps? First of all, cost and time using the declarative development features is very fast. It does not involve any code writing, it does not involve any test classes building. You should not worry about checking on the code and you should not worry about version control.

You do everything in the GUI. You don’t code anything. And you don’t need to even write test classes maintenance using declarative development features there is no code. There is not even a single line of code. And there is also no need for test automation using Apex. And in order to deploy your code from a sandbox to a production environment, you have to build something called test class. And this will also involve so many lines of code. And finally, complexity and scalability. Using declarative automation tool is much less complex than using Apex. Plus building test classes for Apex, there are also less things to worry about, including stuff like governor limits, which are only applicable to Apex and are not applicable to any declarative automation tool.

And finally, we can state that nowadays these declaration tools are very much mature and we can do a lot of things using them. These are some examples and use cases. First of all, if you have a requirement to automate field updates, you have to start thinking of workload rules and Process Builder. And if you cannot achieve this requirement using these, you can revert back to triggers. If you have a requirement for automatic field calculation, you have to first think of formula field and of roll up summary fields. And if your requirement cannot be achieved by these, you can think of a VisualForce page. If you have a requirement to enforce business rules, you have to first think of the validation rules. And if you cannot achieve your requirements using these, you can think of triggers. And if you have some requirements that involve approval, you can use the approval process. And if it’s more complex, you can use the Flows. And finally, even before creating a new custom object, you have to check the standard object and you have to see if your custom object can be replaced by any standard object and you have to use the standard object instead. So the rule of thumb is to first think of the declarative tools like the workflow rules, like the Process Builder formula fields, roll up summary fields, validation rules, approval process flows. And if your requirements cannot be solved by any of these, you can revert back to Apex and two triggers.

Now, what’s the impact of Apex on the character changes? Anything that you write in Apex, be it Apex classes, Apex trigger, Execute Anonymous window will be directly reflected in the user interface. So let’s say if you create a new account using the Execute Anonymous window and you click on Execute and then you go to the user interface, you can see that this account shows in the UI. And also, if you modify if you delete, if you change any record using Apex, this will be directly reflected in the UI. And as a result, you can make any changes declaratively and using the user interface on this record that was created by Apex as if it was created by the user interface itself. There are also some restrictive Apex impacts on declarative changes.

 Any API name, be it any object name, any field name, and so on that is referenced and your code, be it Apex class Apex trigger, cannot be modified using the DUI. It cannot also be deleted, and it cannot have a style changed. So let’s say that you have a trigger on the account object, and this trigger is referencing the name field. So in this case, you cannot modify the API of this field name. You cannot delete it, and you cannot change its type. This is the restriction that Apex imposes on the changes in the GUI. You cannot do all of that because the field name is being referenced in Apex. This was a short lecture. We have learned Apex versus declarative customization. And we have also learned that you have to always think of a declarative customization, a declarative automation tool first. And then you will revert to Apex. As a last resort, you have learned how coding and Apex will impact the declarative changes. And finally, you have learned how coding and Apex will restrict declarative changes. And finally, as usual, thanks for watching.