CRT-450 Salesforce Certified Platform Developer – Testing, Debugging and Deployment – 17% Part 4

10. 6.2- Developer Console, Workbench and Force.com IDE – Demo 1 – Developer Console

First of all, we start with the Developer Console. To access it, just click on your name and click on Developer Console. This will open the developer console. This is the main page. At the bottom we have different tabs. Clicking on each one of these will change the view. And at the top I have the menu item. First, let’s talk about the file menu. First of all, what I can do with the new item. I can create new Apex classes, triggers, VF pages, VF components, Lightning application components, and so on. So if I click on any of these so let’s say I want to create a class. I write the name of the class and then I will have this. And then I can put my code here. I can also open components. I can open classes. These are existing classes in my. So let’s say I want to open this class. I would double click on it and I will have it. Now I can edit it. I can also open objects. So if I go to the Open page and I click on objects, I can open any existing object. So let’s say I want to open the book object.

I will double click on it and I will see the different feeds of this. These are the API names and these are the Apex types. I can also save all. I can close all the tabs. I can close one tab and I can also close all the tabs. Now, in the Edit menu, I can search for something in a file. So if I go to the Account trigger handler class and then I go to the Edit menu item, I can find something in this. I can also fix the indentation. So let’s say I have something like this and I want to fix. I will just go to Edit and click on Fix Indentation and this will fix the indentation of this file. I can also use the shortcut shift plus tab. And then the Debug menu item will allow me to open the Execute Anonymous window. This will allow me to run any Apex code. I can also go to this last link to check what trace flags I have and to create a new one. And I can also create a new debug level. Now, on the test menu item, I can run a new test run. I can define a new test suite. A suite is simply a number of tests that are put together.

I can also run the suite. I can run all the tests and my. And once I do that, I can see all the results and the tests tab. I can also run a test from the class itself. So let me open a class, a test class. If this is a test class, I will have an option to run this test. This is on the top right? Let’s do that. I will have a log and then I can check the test result and the test tab. I can see on the right side the overall code coverage and then the result of this test. I can also run so cool. And SSL queries. To do that, I need to go to the Query Editor tab, and there I will run my Soqual queries. So select ID and name from the book object. So there we go. We have the query result. What we can do, we can edit each one of these records. I will just double click on the field and then I can change. I will not do that now. I can also open this record in Salesforce. To do that, I will just go to the Open Detail page. I can edit this page and I can create a new page from here. So if I click on this, I will have the new page in Salesforce. I can delete this record from here. So if I click on this, it will get deleted.

I can also add a new row from here. So I click on insert row. I will have a new row, and I can specify the name. I can also run. SOSL queries? So let’s say find. And I will put this inside curly bracket, because this is not Apex. So I want to find the text build. So we have one record of author. So if I open the detail page, I can see the record itself. I also have five book records and one lead record. So this is briefly the developer console. It’s a great tool if you want to have a quick development on your salesforce. org. If you want to create Apex classes, apex triggers, VF pages, lightning components, Lightning applications, and so on. If you want to create test classes and run them and check the results and the code coverage, if you want to run So Cool and SOSL Queries. The drawback. First of all, it just connects to one. You cannot connect it to more than one. And it does not have any deployment facilities.

11. 6.2- Developer Console, Workbench and Force.com IDE – Demo 2 – Workbench

Let’s now talk about the world bench. This is a cloudbased tool and we need to go to its website, which is this one. And then because I’m already logged into my salesforce. org, I will automatically log into the world bench without providing any credentials. So there we go. Now what we can do, as you can see we have different tabs. First of all we talk about the info tab and this tab I can see the metadata information in my old. So if I click on this I can see all my standard and my custom objects. So let’s click on the account object and there you can see all the attributes of this object and the relationships. This is very important. I can know what are the relationships of this object, what are the different child objects and what are the parent objects. So if I click on child relationships, I can see the different relationships. For example, we have the opportunity object, which is a child of the account object and this is the name of the relationship. We can also run queries.

So if I go to the queries tab, I can run a sockwell query, SSL query. So if I click on this I will have this nice interface. I don’t need to type everything, I can see all the fields. So if, let’s say I go to the book object, I can see all the fields of this object. So let’s say I want to know, let’s say the name. So automatically I will have this query. I can also add other fields. So let’s say I want to also add the author. I can do that. I can also add the ID. I’m pressing control so I can have more than one field by just pressing control and selecting the field from the GUI. I can also have my filters. So let’s say filter result by ID and then I can specify the ID that I want. So let’s say starts with zero. So there we go.

I can add another filter. I can also sort by there we go, I can specify the maximum result that I want, this is the limit keyword and so on. And then I can run this query. I don’t have any result. Let me get rid of the filters and I will run it now. So, there we go, we have different records. What I can do, I can save this in a CSV file. So if I do that and I click on query, it will be saved in a CSV file. I need to click on this small icon to download this file. I can do the same for SOSL queries, there we go. I can have DML operations. So if I click on insert, I can either have one record or I can have a file that I can insert. So if I choose the first option, I can specify the different field values on this page and then I can click on confirm, insert and note that the fields and read are mandatory fields.

Because this is a lookup field. I can go to this smart lookup and I can specify the name of the author instead of the ID. Same thing for the owner and same thing for the publisher. I can also deploy metadata to My by going to the migration tab and clicking on the deploy link. And I can also retrieve metadata components from My. And finally, I have some tools that I can use. I can run the Execute anonymous block. There we go. I can also do password reset. I need to provide the ID and the new password. And I can also know the bulk API job status and the metadata API process status. So this is briefly the workbench. It’s a cloud based tool. I mainly use it for its metadata information tool. So I can know all the details of any object, all the fields, all the relationships and so on. And I can also use it for its so called query editor. I don’t need to learn all the fields. I just click on this and I select the field from this list. And I can also select any filter, and the query will get generated.

12. 6.3- Deploying Metadata

Hey guys, this is section six debug and deployment tools. And this is lecture number three, deploying metadata. In this lecture we’ll talk about what is metadata and how we can deploy it from an. org to another. First of all, what’s metadata? Metadata is the data that defines your. It’s the different configurations and attributes that make your. For example, it’s the different objects, fields, reports and so on. And it’s not related to your data by any means. So it’s just the configuration and it’s not the data itself, it’s not the records themselves. Deploying metadata is moving it from an. org to another. And you have to remember that a sandbox is a totally different than a production environment. So if you have a sandbox ad, you have a production environment. These are related, yes, but they are totally independent. So you have to move your metadata from the sandbox to the production environment. And this is called deployment. We have many different options and tools in salesforce that we can use to move metadata from an. org to another. We have the change sets, the force IDE, and the packages. And this lecture will talk about these three. But there are many other options, but this is the scope of this course. First of all, we’ll talk about change sets.

A change set is simply a bundle of metadata components that make up an application or a piece of functionality. So it’s mainly a number of different metadata components that are gathered together and they will form a change set. And then we can use this change set to deploy from an. org to another. So you can choose different objects, different fields and so on. And then you can put all of that in a chain set and then you can send this to another. In fact, using change sets is the easiest way to move metadata from an. org to another, from a sandbox to the production environment. Change sets are accessible from the setup page and they allow metadata movement or migration between related orgs. So this is the drawback the should be related. I cannot move a change set from an. org to another when these two orgs are not related. So this is from a sandbox to a production environment. And change sets also allow us to choose which metadata components to include and to find the dependencies. Because everything happens in the cloud. We don’t need to bring files to the local PC. Everything is happening in the cloud, I don’t need to do all of that. And you can also reuse a chain set. You can clone it and you can make changes to it and then you can deploy it again. And then after a chain set is made and is locked, you can deploy it to all connected organizations.

Now, what are the drawbacks of chainsets? First of all, you can only move metadata between a related. So this is between a sandbox and a production, between a sandbox and another sandbox. You cannot move metadata between unrelated. org and second, you can only add components with the chain set but you cannot delete them. So let’s say I need to delete something on the production. I cannot do so using a chain set. I need to go to the production and I need to manually delete them. Now what are the different steps to use chain sets? First of all, chain sets can be used to deploy metadata between related. So the orgs should be related and they also should be connected. To connect two orgs we need to use something called deployment connections to deploy metadata from one to another. We have to first configure the deployment connection between them and deployment connection is a link that gets established whenever you create a sandbox and you can configure it to specify the direction in which metadata can be deployed between these two orgs. So this is the first step. I need to make sure that the production and the sandbox or the two sandbox have deployment connections. How we can do that? Let’s say you want to move metadata from a sandbox called dev one to the production.

In this case a connection should be established prior to do that and these are the different steps that we need to do. First of all, we need to log in to the target, in this case to the production and then we need to go to the deployment settings. Then we will find a list of all related orgs. So in this case of all the sandboxes we have to select what sandbox we want to allow to give us change sets and then we have to establish the deployment connection by checking the box allow inbound changes. So this is it, we have to log in to the target, in this case to the production environment and we have to establish the deployment connection with dev one. And then after doing that we can create the outbound chain set and the source. So in this case dev one. An outbound chain set is changes that you want to send from an. org to another. So in this case from the dev one to the production. And you can think of it just like an email. So if you want to send an email from, let’s say one client to another client, you go to the source and you type the email and then you send it. So this is the same thing as outbound chain set.

To create it we have to log in to the source and then we have to click on outbound chain sets and after that we have to add which metadata components will form this outbound chain set and then we can send it to the destination. Now what will happen to this outbound chain set? It will be sent to the destination. org and there it will be called an inbound chain set. An inbound chain set is a chain set that has been sent from another from the source to the that you are logged in, in this case to the destination. org which is the production with inbound chain set you can receive metadata components from another and you can think of it just like an email inbox. So let’s say someone will send you an email from his outbox, you will receive it in your inbox. So this is the same email but from his point of view this is in the outbox and from your point of view this is in the inbox. When you click on the inbound a change set you can see all of the received chain sets.

Now when you click on the inbound a change set you can either validate it so this is mainly testing it or you can deploy it to your and finally you can also delete it. So this is the first way that we can use to deploy metadata between orgs. The orgs should be related, but this is the easiest way and the most convenient one. The second way that we can use to deploy metadata is by using the force IDE. Metadata can be deployed from within the force IDE to any other and it should not be only a related. So this is the good thing about that it should not be a related. Like in the case of change sets, deploying is the process of pushing your local project files into a different salesforce. org than the project home and the could be unrelated. This is what we have mentioned and this is not the case with chain set. And finally you can deploy a single component, or you can choose different components, or you can even deploy the whole project. And to do that, you have to right click on the component, go to the force menu item and click on Deploy to Server.

And then you have to choose which you want to deploy this metadata to. And the third way that we can use to deploy metadata from an. org to another is by using packages just like a change set. A package is a bundle of metadata components and typically a package would contain metadata stuff like objects like field, like Apex code, like layouts and so on. Packages can contain one component or a bundle of components or hundreds of components and packages are mainly used for distribution across different salesforce orgs. It can be either related or even unrelated and packages help by clustering related components together for code migration. Packages are mainly private, but they can be shared by sharing their URL. And to make a package publicly available, it can be published on the app exchange or it can be shared by a sharing its URL. Packages can be uninstalled at any point so in this case this will cause all of its components to be deleted. And finally we have two different package types, we have unmanaged packages and we have also managed packages. Let’s see the difference between these two. First of all, with unmanaged packages, the source code of the package, the metadata components of the package are available and they can be edited.

But this is not the case with managed packages where the source code is not available. The metadata components are not available for edit. Unmanaged packages are used to distribute feeware open source projects and so on, but managed packages are used to sell application to customers on the app exchange. Unmanaged packages cannot be upgraded, but managed packages can be. The metadata components of an unmanaged package will count towards the limit. But this is not the case with managed packages, where the metadata components of a managed package will not count toward the limit. When creating an unmanaged package, I don’t need to have any space, but I need an in space in order to create a managed package. And finally, unmanaged packages can be distributed via a link so I can share the URL of the unmanaged package. But once I do that, I cannot control its distribution. But with managed packages, the distribution is controlled, as a package cannot be redistributed like the case of unmanaged packages. Let’s now jump into salesforce and let me show you some of these in action.