 Hello everyone. I am Sanjay Gupta. I welcome you on Sanjay Gupta Tech School. So this is day 61 of Salesforce Learning Bootcamp and today we are going to discuss more things related to integration. So I have Ankit Jain with me. Welcome Ankit on the platform. So Ankit will be delivering the remaining topics of integration. So I hope you attended yesterday's session or if you missed you watched the recording and now you are good with the introduction to integration. So I invite Ankit to introduce himself. So Ankit please go ahead. Thanks Sanjay. Hello everyone. Hope you all are doing well. Again good morning, good afternoon. Based on your geographical location. Quick introduction of mine. My name is Ankit Jain. I am a Salesforce architect. Moreover I am also a certified instructor as well as I am a corporate trainer too. I do have more than 10 plus years of experience in the Salesforce ecosystem. Moreover I do have the experience to deliver the trainings to the corporates for more than 20 or 30 plus clients. I deliver the trainings on integrations as well as on the PD1, PD2 and on the numerous topics. In addition to that I am quite active on the stack exchange as well as on the developer community. I would appreciate if you guys please connect with me on the LinkedIn and follow it to me on the LinkedIn. I do share the good takeaways on the LinkedIn too. Thank you. Okay. So thank you Ankit for introducing yourself. So moving forward, Ankit please next slide. So if you want to become part of Salesforce community where lots of business are connected and helping each other solving their problem. So you can just scan this QR code and you can join the telegram group and become part of that community. And as you can see this week is dedicated for integration. So this week and next week Ankit will be covering all the aspects related to integration. And after those two weeks we'll be starting next phase of this bootcamp that is front end development which will be containing lightning aura component as well as lightning web component sessions. Okay. So please follow Sanjay Gupta Tech School on YouTube, LinkedIn, Instagram, Telegram and all the important links are available in the video description. And do follow Ankit because Ankit is learning new things and if you follow him so maybe you will get to know lot more things through him. So he is active on LinkedIn. So please follow him and you can just learn whatever he is doing for the community. Okay. So over to you Ankit. Just start the session and thank you Sanjay. So folks yesterday we talked about what is integration, moreover we discussed what are the different benefits that we get with the integration. Of course that we talked about the different approaches that we can use on the integration. We talked about the data level integration, process level integration as well as the virtual integration. Moreover we also talked about the different patterns available in the integrations as well. We discussed the different patterns available in the integration. Of course that we also discussed the timings that are important in the integration. So we do have the synchronous as well as the synchronous timing that also we discussed. In addition to that yesterday we also discussed the slow of integration. As I mentioned yesterday there can be two directions of integration. One is outbound integration and second is the inbound integration. So based on the outbound integration and the inbound integration, the approach that you have to follow and the timings that you have to use for the integration, you have to decide which pattern will be suitable for your integration. Right. Now we'll take one step further. We'll go and discuss about the web services. Yesterday also we understand a few of the terminologies that we frequently used in the integration where we discussed the web service. Now let's go and take one step further and talk about two very common web services that we very frequently used when we perform the integration. First one is the top web service and second one is the rest web service. Now the question comes when to go for the SOAP and when to go for the rest. Another question is what is SOAP and what is rest. So let's try to decode this. SOAP basically stands for simple object access protocol. Again I'm repeating SOAP stands for simple object access protocol. As the name says it's a protocol. However rest it stands for representational state transfer. Again rest is not a protocol. It's an architectural style that we use to perform the integration. SOAP is a protocol. REST is an architectural style that we use to perform the integration. As SOAP is a protocol SOAP is considered more secured as compared to the rest. If you are dealing with highly secured transactions then you should use the SOAP. Then you should use the SOAP. However there are few limitations that we do have with the SOAP. One of the limitation is SOAP only works with the XML language. SOAP only works with XML language. However REST is quite flexible. REST works with both JSON, XML and multiple other formats like HTML as well, Linux as well. However the SOAP only works with the XML language. It does understand the data in XML format only. Next thing is SOAP it is bit bulky because of which the processing time of the SOAP is bit higher as compared to the rest. And that is the reason SOAP is considered as slow as compared to the rest. However REST performance wise is much better. As in most of the times when we send the data on the REST we either use the JSON format or the LintTest format. There are multiple parsing methods which are available in both JavaScript as well as in the Apache classes with the help of which we can easily perform the operations on the REST. However for the SOAP also we do have the methods but the support is quite limited as compared to the rest. And because of all these different factors most of the organizations perform the integration they choose REST over the SOAP. But again as I said different architectures have the different requirement. If your architecture demands high security definitely the architecture can go and prefer to use the SOAP over the REST as well. It is completely up to the architectural decision that is coming up whether you should go for the REST as well as for the SOAP. Moving toward the next part let's go and try to understand few configuration things in the Salesforce with respect to the integration. Let's go and try to understand few configuration things in the Salesforce with respect to the integration. The first one that we'll be talking about here is the remote site setting. What is remote site setting? Whenever you have to perform the integration either you are doing the integration from the visual for pages or you are doing the integrations from the JavaScript file of a Thora or you are doing an integration from the JavaScript file of a Lightning Web Component or you are doing an integration from the Apache classes. Whenever you are doing any type of integration from any of the different mediums you have to go and register the endpoint where you are making the integration. It is mandatory in the Salesforce whenever you are making the integration with the third party system you have to go and register that URL. Where you will go and register that URL under the remote site setting. Where you will go and register the URL under the remote site setting. Moreover in case you are doing the integration specifically from the Lightning Web Component or from the Thora in addition to remote site setting you also have to go and configure one additional thing that is referred as the CSP trusted site as well. Although Salesforce does not recommend that we should go and perform the integrations from the JavaScript file because of the security results. And because of this most of the architectures they do prefer to perform the integration from the Apex only. Moreover it is also considered as the best practice to perform the integrations from the Apex and not from the JavaScript end. Let go and see how we can go and configure the remote site setting and what all the different parameters that we do have while configuring the remote site setting. So again I am in my org here this is a test org that I have created here and I am on the setup page here. To configure the remote site setting you have to go to the quick find and here you have to search for the remote site setting. Here you have to go and search for the remote site setting. To create the new remote site setting here you have to go and click on new remote site. Here the first thing that you have to provide is the remote site name. Again you can give any name here. Elseforth does not take this name although it is mandatory but you can go and provide any name here. Let's say I am putting the name here here. You can go and put any name here. Another thing that we do have here is the remote site URL. In this remote site URL you have to put the end point of the system with which you are making the integration. In the remote site URL you have to put the end point of the third party system with which you are making the integration. Let's say here I am making the integration with the API layer. This is my end point so I am putting this end point here. Again you do not have to put the complete path even though you put the platform will trim and keep only the home path for the end point. Even though you put the path will automatically trim and put the home path for this end point. Another thing that we do have here is the disable protocol security. If you go and enable this enable protocol security, right? Salesforce will not check whether the data is coming up from the HTTP or STTPS. Salesforce will not check whether the data is coming up from the HTTP and the STTPS and there will be security implications. If you over over this information icon, Salesforce clearly mentioned that we should check this check box only when we completely understand the security implications of the disable protocol security. Because it does compact the security of an integration that is the reason Salesforce does not recommend that you could go and check this. But again if you do have that kind of a requirement where the user connection can be over the HTTP or over the STTPS definitely you can go and check this check box. By default the user connection if you are not checking this the user connection will be considered over the secured HTTP that is nothing but the STTPS. Another thing that we have to go and specify here is the description. You can write down the purpose for which you are making the integration. Let's say the purpose that I am putting here is to integrate with API layer system. Let me show this in case you guys are not getting it all the different parameters that I have put here. I have put the remote site name followed by that I have put the remote site URL also I have put the description as well. This is how you go and configure the remote site settings. If you can zoom in more so it would be more clear. Yes, now it is better. Let's go and talk about the further topics. The next one that we do have here is the name credential. The next one is the name credential. What is name credential now? We understand the remote site setting that we have to configure to avoid or to white space or to whitelist the endpoint so that we can do the successful integration. Now what is name credential? You can say name credential is an advanced form of a remote site setting. You can say that the name credential is an advanced form of a remote site setting. With the remote site setting we can only go and put the endpoint which we are connecting. However, with the name credential along with the endpoint we can also pass the authentication parameters as well. With the name credential we can also pass the authentication parameters as well. And you can go and do this in one single operation. Before the name credential, what used to happen? The developers will be using the remote site setting. And in case they have to put the username and password, they are either putting the username or password in the custom metadata or they are putting the username or password in the custom label. As they are putting the username or password either in the custom metadata or a custom setting or a custom label as the password will be visible to the admin and it does raise the security flag. When you come this again the name credential will be very helpful. Whenever you are configuring the username and password in the name credential the password will be encrypted automatically. The password will be encrypted automatically. Again, in case you are using the name credential there is no need to use the remote site setting. In case you are using the remote site setting for the authentication you might have to write down the additional logic but in case you are using the name credential and you are implementing the OAuth authentication or the password authentication or different types of authentication, in such scenarios you do not have to go and write down the additional logic. You just have to go and define all those configurations in the name credential only. You just have to go and define the name credential only. Since in the latest release Salesforce have introduced the improved form of the name credential as well. In the latest release Salesforce have introduced the improved form of the name credential as well which is considered as a more extendable as well as the more customizable too. Which is considered as the more extendable as well as the more customization too. Now the question comes in what all scenarios the name credential will be helpful. The name credential will be helpful whenever we are making the call out from the Apex, whenever we are accessing the external data resources or we are accessing the external services as well. In such scenarios, we definitely use the name credential. In such scenarios, we could definitely use the name credential. Now, how to define the name credential? Let's say you have created the name credential. Now, how to use the name credential in the best classes? To use the name credential, you have to follow this approach. You have to first specify the call out, followed by the colon, followed by the name credential name. This is your name credential name, followed by the path, whatever the path that you have to provide. In the name credential, we only specify the home path, but in case you want to access a specific path, then you go and put all those path here. In case you have to pass any parameters, you can also go and put the parameters here. This is how we go and refer the name credential in our Apex program because we have to perform the authentication as well as authorization in the Apex classes with the help of name credential. So we have to specify which name credential we are using and how we will do that. We will specify the call out, followed by the colon, followed by the my name credential, followed by the whatever the name credential that you have to define here, followed by the slash, followed by the end point with which you want to integrate and followed in case you have to pass any parameters, you can pass those parameters here. Let's go and find out how we go and define the name credential in our system. To define the name credential, what you have to do here is here, you have to go and use the name credential. In the setup menu, you just have to search for the name credential. As I said, this is the latest one that Salesforce have introduced in the latest list, which is considered as the more extensible and the more customizable. But for this demo, I'll be using the legacy one only, that is the old one. To access the old one, you have to just click on this button and click on the legacy one. So here, what you will do, you will go and specify the label. Let's say here I am specifying the label as the my credential, right? Again, it's a label you can put without namespace as well, it's completely up to you. Again, here, what you can do, you can go and specify the endpoint where you have to make the integration. Let's say I have to go and make the integration with the gmail.com. So I can go and specify that complete endpoint where I have to go and make my integration. So here, I am putting the gmail.com. Now, the next thing is here, you have to specify what kind of authentication that you have to do. We do have the different types of authentication here. We do have the anomalies. In case for each user, you want to set a specific authentication, then you can go for the per user. In case for the system authentication, you can use the name principle as well. In case your system is dealing with the certificates exchange, then you can go and upload the certificates from here. And after selecting the name or principle, again, you do have the multiple authentication protocol that you can use here. Again, in case your integration system, it is not using any authentication, then you can use the no authentication. In case they are using the OAuth 2.0, you can go and specify the OAuth 2.0. In case of OAuth 2.0, you have to go and specify the authentication provider. You have to define the different scopes. I'll be taking a separate example for this when we do the demo session, or integrating the two different Salesforce org. Moreover, you can also go and define the password authentication as well. In the password authentication, you can go and put the username and password. And as I said, if you are using the username and the password, if you are using here, the username and password, the password that you are putting here, it will be stored in the Salesforce in the encrypted form. So that admins, they can see the username, but they also cannot access the password, right? This is one of the reason that the name credential got famous in the past. Definitely, authentication is the one way, but the additional functionality it does offer is, it stores your password in the encrypted way. So you do not have to go and put the username and password in the custom settings, or in the custom metadata, or at the custom label level, right? Moreover, there are two different call out options that you do have. Based on your requirement, you can go and select these different options from here. Once you go and define all those parameters, go and click on here, your name credential will be, right? Let me take a pause and open up for the question. Let me check which question we do have. So guys, if you have any question, you can just ask in the chat. Asif asked, where we'll get the endpoint? Again, whenever you are making the integration with any third party system as it, we generally get the documentations from the third party system, and they will let you know what endpoint that you have to connect, what type of API that you have to use, whether you can use the REST API or SOAP API, they will share all those details with you. Switching, URL mapping we do when we go and create the OPEX REST service. OPEX REST service, it is for the inbound integration. Whenever we go and configure the remote site setting and the name credential for the outbound integration, right? So in the case of inbound integration, there is no need to go and define the remote site setting or the name credential. Whenever you are making the outbound integration, then and then only you have to go and define the remote site setting and the name credential. Next one is name credential, and they are used when we call from a software. When I already answered it, sorry, sorry, it's available. Now, Phyrus, which protocol you have to use? Again, whatever external system that you are using, we will give you the proper documentation, which protocol that you have to use, right? In Salesforce, to make the connection, generally we use the OAuth protocol. Each and every integration that we have to do, they generally provide a complete documentation. What is the endpoint? Whether you have to use the REST API or the SOAP API, what kind of authentication mechanism that you have to use? Generally, we do have the different types of authentication mechanism. We talked about the OAuth, we talked about the username and password. Generally, people also do use the API key authentication as well. Moreover, if you're accessing the public API in such scenarios, there is no authentication. So they will put all those details in those documentation. You have to use the, again, to answer the youngest question, we have to use the name credential and the remote site setting whenever we are making the outbound integration. That means, for example, let's say we do have one system as the Salesforce and another system as the Oracle. If we have to call any third-party service from the Oracle, then we have to go and put the endpoint of the Oracle. We have to go and define what kind of authentication mechanism we are using for the Oracle. So that is where the remote site setting and the name credential will come up. Yes, Vinay, we have to use the name credential for callouts or when we need any type of security whenever we are making the third-party integration. So community portal also considered as integration. No, community portal, they are integrated inside the Salesforce. It is not considered as an integration. But from the community portal, if you are making any integration with the third-party system, then you have to do all those configurations. I'm not understanding your question, Vishal, how to enable the external credential. I think we'll be talking about the tool that we have to use as we move forward. But we'll most probably cover the portman as the tool. Yes, Sanjay. Yeah, I guess Vishal is asking about the second tab, which is beside named credentials. Okay, external credential. No, I have no idea on this one, Vishal. I never used it as of now. I do not have any clue on this. Okay, let's take further. There is one more question. I will share the few APIs that you can definitely use for the testing. If I had to take one API, for example, let's go and talk about one API because most of the people do have a confusion. How we'll come to know what kind of authentication mechanism that we have to use, what type of API that we have to use. So for the demo purpose, let me take one of the API, that is the NumVerify API. Okay, whenever you have to make integration folks, generally you will get this kind of a detail where you always have a documentation about the integration that you have to perform. Trust me folks, each and every integration that we do, all integrations are unique. First, you have to understand their documentation, what they are asking in their documentation, and after that, you have to go and start implementing the integration. In case you are making the integration with your enterprises applications, then you have to ask another team to provide the enough information before you go and initiate your integration. So for the demo purpose, I am showing you one of the API, that is the NumVerify API. What this API will do, this API will validate the phone number. In case you are passing the phone number, if phone number is correct or not, this API will do. Let's take one example here. Okay, so in Salesforce, at the contact object, let's say the user have put the, for example, let's say here we do have the contact object, in the contact object, user have put the phone number. But in Salesforce, we do not have any mechanism where we can go and validate whether the phone number is a valid phone number or an invalid phone number, right? So how you will come to know whether the entered phone number by the user, it's a valid phone number or an invalid phone number, right? Let's say you are taking these entries either from the digital experience or you are a sales rep, they are putting all those details here. One of the details that they are also putting here is the phone number, right? How you will come to know the phone number that the sales reps are putting, it's a valid phone number because in Salesforce, I can go and store the phone number, something like this as well. I will not get any validation error though. You can see here, I am saving the phone number, something like this. It's completely an invalid number. So how we can validate? So let's say business have proposed that you go and use this API to validate the phone number. So what is this API? It's a NumVerify API. For the first thing that you have to do here is you have to navigate to this API and create an account. Again, if you go over the pricing, this API is free for the practice as well. You can see it is free for the lifetime. You can make the hundred request monthly on this API. Again, no credit card is required. So you can directly go and create your account on this API, right? Now, what this API will do? This API, it is using the REST API. You can see here, everything is written in the documentation. This API, what it will do? It is using the REST API, right? Again, what they are dealing with, they are dealing here with the JSON type of information. If you move to, if you move downward, here you will see, they will first talk about the authentication. So whenever you are using this API, how you will do the authentication? Here, they are using the authentication as an API key authentication. What they are doing here, the authentication as an API key. So when you go and register for this one, what you will get first is the API key. Like this is the API key that I am getting after I go and sign them, right? So whenever I have to make the integration, what I have to do, I have to go and use this API key for the documentation. Now, I can go and store this API key either in the custom settings or in the custom metadata or in the custom label. That's completely up to me. Or I can also go and hard code. Generally, we don't hard code. We go and store this information in any of the admin tools that we do have. Again, if you follow their documentation, they further say that, what endpoint that you have to connect. If you see this, right, here they have put the endpoint where you have to make the connector. This is the endpoint where you have to make the connection. It is the complete path that you have to follow. It is the complete path that you have to follow. This is the endpoint and at this home path, validate is the location where they have posted their service and here you have to pass the authentication key that we are getting after we go and sign them. So this is where I do have the authentication. Moreover, in this documentation, they have also provided how to use this service, right? What all the different parameters that you have to pass. Everything is written very well in this documentation. You just have to follow the documentation and understand what all parameters that we have to pass. For example, here we have to go and use this validate along with that the first parameter that we have to pass here is the access key followed by that the next parameter that we have to pass is the phone number. So what it will do, it will go and hit this API and it will validate the phone number. Moreover, these are the few mandatory parameters that you have to pass, right? In addition to that, you can also pass these optional parameters as well. In case you want to validate this phone number for a specific country, in case you are expecting the value in the specific format, you can go and put all those details here. You can see here, once you go and hit the API, you will get the response of this type, whether the entered phone number is a valid phone number or not, right? You will get the response of this type, right? In case your authentication is filling, then you will get the response, something like this, where you will be getting the code as false. In case the phone number is missing or the phone number is having some special characters or if the service is down, then you will get the error code here. Again, I'll be talking about the error codes separately, but this is how generally we do have a documentation. You can go and pick any API. Let me pick another API for the demo purpose. Let's say this is another API that we do have. It's a spinocular API. This API, what it will do? Here, the API will suggest a recipe for the different items that you want to cook, okay? Again, like every documentation, like every API, this API also have a documentation. You just have to go over their documentation. You have to understand what kind of authentication mechanism that they are using. They will be putting the different endpoints here. You can see they will be putting the different endpoints. What kind of content that this API can access, like the JSON content, what are the different parameters that you can pass? All those details are available here, right? If you go over this authentication, here they will talk you how you can authenticate. Again, this is also an API key authentication. This is also an API key authentication. So again, this is your endpoint that you have to go and hit. Everything is available in this documentation. If you follow this, this is the endpoint that you have to hit. This is the API key that you have to use to perform the validation, right? And whatever the different endpoints that you have to hit, for example, you have to go and search the recipe, right? And while searching the recipe, you have to specify the cuisine or you have to specify the diet. You can go and pass all these different items, right? Whatever the items that you have to pass. Again, they are specified here, what all the different items that you have to pass. They have given an example. In case the field is closed, close means we have to go and pass the specific values that also we can figure out from here, right? And what it will return, it will return you the list of items, right? So this is the kind of an API that we have to hit. For example, if I'm hitting this API, again, this will not work because, this will not work because I have to go and sign in for this API. But if you go and create a sign in and you are hitting this API, you will get the response something like this, where they will be talking everything about this recipe, right? What is the title of the recipe? What is the image of the recipe? What they will return you, they will return you a JSON. You have to hit the API. Once the integration is successful, they will return you the JSON. Now the next job is to pass this JSON and get the information out of the JSON and put it on the UI or store in the database according to your integration requirement. I hope now most of the concepts are clear to everyone, right? What is endpoint? How to identify the authentication? You pick any type of integration. For example, you have to go and use the car API search or you have to make an integration with the LinkedIn or Twitter. Go and pick any integration. Every integration, you will see the documentation where they will specify the kind of authentication that you have to use, the endpoints that you have to use, what all the different methods that you have to use, what type of integration that you have to use, whether you have to use the REST integration or the SOAP integration, they will put everything in their documentation, right? So in case you are making an integration in your enterprises applications as well, like one of the folks has been asked, like if you are making the integration with the ERP, right? Then Sachin, you have to go and sit with your ERP team and understand what type of request that they are expecting, right? What type of integration that they want you to build? What type of, what is the endpoint where they have to go and hit your system? You have to ask all these questions to your ERP team and once you have the answers for this then and then only you can start building your integration. Again, I'm repeating folks, every integration is a unique experience. In every integration, we have to go and do something differently. And the key thing for, to build any integration under their documentation, you can try with these different APIs that I have referred, like the Punacular API or the NumVerify API, or you can search for the public APIs. There are different public APIs that are freely available. Just go, Google this public API, you will get the lots of public API that you can use for your testing. I'll just share the few with you, but if you go over this, just look for the public API here and go over this GitHub link, you will get one number of public APIs that are available that you can directly use. For every API, they will do all the different types of details that you have to build. You can see that there are different types of APIs that are available. In case you have to implement the currency exchange API, go for the currency exchange, click on this, they will give you the complete details, what is the endpoint that you have to hit, what type of integration that you have to build, they will put all those details in their documentation. You can see your authentication is the API key, API key, API key. If you observe, it does not require any authentication. Just go over that API and you can understand their documentation and start building it. Moving toward the next one, that is the connected application. As of now what we are doing, we are making the integrations with the third party system. Right? Now let's say there's a third party system that wants to make an integration with your system. What you will do in such scenarios? In such scenarios, you will go and create a connected application in your system. In the connected application, you can go and define what type of authentication as well as the authorization mechanism that the third party system should use. Right? In case you are implementing the single sign-on for your org, then also you have to go and use the connected application. So there are primarily four different use cases where you generally go and use the connected application. First one is if you have to integrate the external app with the Salesforce. Right? Let's say the V2 have the external app available. Let's say Oracle is the external app. And now this time Oracle is sending the request to the Salesforce. Right? Now what kind of data that Oracle can access? What kind of authentication mechanism that Oracle should use? You have to go and define all those details in the connected application. Right? The next thing is you have to go and define the, another use case is you can go and use the service provider. You can, your connected application can also be act as a service provider. There are different types of provider like we do have the authentication provider, we do have the service provider. Right? You can also use the connected application as the service provider. For example, let's say you have created one application and you want that user should login into that application with the Salesforce credential. In such scenarios, we go and create the service providers in the Salesforce. I will show you how to, we can go and create the service provider in the Salesforce as a part of demo. Right? Moreover, what kind of data that a system can access? As a given example, Oracle system wants to connect with your system. Now Oracle could access what kind of a data that also you can define in the connected application. And the last thing is to provide the authorization for the external API gateways. External API means basically, let's say you are using the Mulesoft as an external API. Provide the authorization to the external API gateway. Like we'll be using the Postman. Postman is nothing but again, an external API gateway. To provide the authorization for these different applications also, we go and create the connected applications in our system. Right? So how we can go and create the connected application in our system? So to create the connected application, what you have to do here is again, you have to go to the setup here. Sorry, you have to go and search here for the app manager. My bad. Like from the app manager, we go and create the Lightning application. Similarly, from the app manager, you can also go and create the connected application from here. You can give any name to the connected application. Let's say I want to create this connected application for the Oracle ERP. So I am giving the name here as the Oracle ERP. Right? Contact email. You can go and define your contact email here, whatever the contact email that you want to use. Make sure you're putting the correct email address because as soon as the connected application will be created, Salesforce will send an email to you on the email address that you are configuring here. Next thing is the phone. Again, it is optional. You can skip that part. In case you want to have the logo, you can upload that logo from here. You can either upload your own logo image for the application or you can choose one of the sample logos that Salesforce is offering. Let's say I want to use here the logo of an Oracle. So I can go here and search for the Oracle. I'm not sure whether we do have the logo for the Oracle available in their sample, but let me quickly check. We can use any of the different logo. Let me check if we do have the logo for the Oracle system available here. Or let's say for the time being, I'm using the logo of the SAP. So these are the two URL that I have to use. I'm just renaming my application name from Oracle to SAP as I'm using the SAP Oracle. Okay, and here I'm putting the logo URL. Moreover, you can also go and put the icon URL as well. Again, completely optional, but I'm just showing you how to do it. The next key thing that we do have, let's say I want this integration to be done based on the OAuth because whenever we are making the integration with the Salesforce, we have to do the OAuth integration only. So here you have to go and specify the callback URL. What is callback URL? Whenever the successful authentication has been done, where the control should navigate that is defined in the callback URL. So let's say for the time being, I am using this one of the dummy URL as the callback URL. Again, I'm repeating what is callback URL whenever the successful authentication have been done, where the control should navigate that will be driven based on the callback URL. Next thing is, as I said, the Oracle system is connecting with your Salesforce. Now what kind of features that they can access whenever we are integrating that you can define from here, right? Whether they should have the full access of an integration or not. Another key thing that we do have here is the refresh token. So whenever we are performing the integration with the help of OAuth, basically we use the token-based systems. And this token-based systems do have an expiry type. If your OAuth mechanism, it is implementing the refresh token, then automatically the refresh token will be generated as soon as the token has been expired. So we use this refresh token. In case you want the integration that you are doing, they should only access the data via the API when you go and provide this kind of an access, right? So here you go and define the different types of authorization that you want to provide whenever we are making the integration. Again, there are a few additional fields which are a few of them are specific to the service provider or the authentication provider for the time being I'm just clicking on the field. Whenever you go and create the connected application, it generally takes around 10 minutes to create that application. And once the application is created, you will get an email from the Salesforce. Whenever you go and create the connected application, Salesforce do provide two key important things. First is the client secret key, and second is the client key. So Salesforce do provide two important things whenever you go and perform any kind of an integration that is the client key as well as the client secret key. So let me check an email for the authorization code that Salesforce has sent. So authentication code here is, so what you have to do here is, you have to go and share this client consumer key as well as the consumer secret key to the third party system. Let's say Oracle systems comes to you or the developer from the Oracle comes to you and he asks you for the authentication details. What you will share with him, you will share this unique key that is the consumer key as well as the consumer secret key. Whenever they have to go and perform the integration, they have to go and specify the consumer key as well as the consumer secret key. And in return, you have to ask them for the callback URL. In return, you have to ask them for the callback URL. Callback URL is where the control will be transferred as soon as the connection has been successful. You can go and define this callback URL here. Again, I'm repeating, if you are making an integration with the Oracle system, then with this Oracle system, you have to go and share this consumer key as well as the consumer secret key. This key as well as this secret key is specific to the connected application that we have created. So whenever they have to make the integration with the Salesforce, they have to go and specify this consumer key as well as the consumer secret key. Ankit, can you please zoom in once so that people can see? Sure. Right? This is where you have the consumer key as well as the consumer secret key. If you go and create connected application in your own, you will get a unique consumer key as well as the unique consumer secret. All right? Your job is to save this and share with the Oracle system. I hope I'm making sense. I believe that's where today, here only we have to wrap up because there are few remaining topics that we have to cover from tomorrow onwards that we will be seeing these four different types of APIs that is the REST API, SOAP API, PubSub API as well as the Bulk API. As of now, we understood the theory part. We understood how we can do the configuration in the Salesforce, how we can go and configure the remote site setting or the name credential or the connected application. Tomorrow, we will see how we can use two things. First, REST API in the Postman, how we can use the Postman to make the calls to the standard APIs that Salesforce do offer. Moreover, we will also see how we can go and create our own REST services. In the REST services, I'll be taking the simple one as well as the few complex one, like you have to pass the different types of data or you have to return the different types of data from your web service. That also I'll be covering two complex scenarios. Definitely I'll be covering the easy one, but I'll also be covering the big complex one as well. Moreover, we'll also see how we can do the call out from the Salesforce too. These are the different topics that we have planned for the upcoming session. So tomorrow, we'll be starting with the REST API and as the session goes forward, we'll be covering these different APIs too. So let me take a few questions. Again, from the chart window, first question is from the ACID. ACID, you can taste this definitely from the Postman tool as well, right? But in case, again, for the testing, definitely you can use the Postman tool, but in case you have to go and perform some automation, then you have to either use the flows for the integration or you can use the PIX classes or you can write down the PIX classes to perform this integration as well. Connected app. RSJ, I have repeated multiple times. Let me know if you still have the questions on this one or not. Inbound integration, basically, whenever the Oracle system is making the call into the Salesforce, whenever from the third party system, we are getting the calls into the Salesforce, it is referred as the inbound integration. Whenever from the third party system, if we are getting a call into the Salesforce, it is referred as the inbound integration. First, yes, we use the connected apps for the inbound integration. Not only for that, there are a few additional cases that we discussed. Like we also use the connected app to act as a service provider. We also use the connected app to define the type of authorization that we have to do. Moreover, we also use the connected apps to provide the access to the external API gateways like the MuleSoft or the Postman. Moreover, we use the remote site setting and the name credential definitely for the outbound integration. Salesforce do recommend that we should use the name credential over the remote site setting. But in case you are making an integration with the API key or you are making an integration with the public API, then definitely you can go and use the remote site setting too. Whenever they have to send the response, now they will go and initiate the integration. Your job is to send the request, your job is done. Now they have to send the response, they will initiate the new integration and send the response to you. Sorry, your message is not clear to me. For the outbound integration, definitely we use the remote site setting and the name credential, right? And for the inbound integration, we use the connected apps, yes. Yeah, that's all for today, folks. Okay, so I hope guys, you understood whatever Ankit explained and if you still have any question you can ask, otherwise we are wrapping the session for today. Right, again, thank you for the audience for attending the session. I hope you got a few understandings or few learnings from this session, right? And this session definitely, I hope this session will be an add-on in your knowledge too. Again, thank you, Sanjay, for providing me this opportunity and providing me this platform to helping the community. Yeah, surely, Ankit and your hard work is appreciated. I can see a few questions, so if you can see if they are relevant, so you can answer them. Right, Archana said, is remote site setting optional in case we are using the name credential or vice versa? Vice versa is not true, in case you are using the remote site setting, then in case you are using the name credential, there is no need to define the remote site setting, right? Because name credential, it will done the both jobs for you, it will perform the authentication as well as it will also help you to define the end points as well, right? The next question is, can you please elaborate with using two Salesforce orgs? Yes, Shiva, we'll be taking that scenario where we'll be integrating the two Salesforce orgs with the help, where we are creating the rest surface in one of the org and we are making the call-outs from the another org. Most rarely in the next week, we will cover that scenario. Permission sets for the name credential, generally admins do configure the name credential, Vinay, but generally in the real world, we do not provide this setup access to the end users, right? As we are using the day walk, you might see this access, but when the end users, they are using this Salesforce application, they will not see the setup icon, okay? So end users are not supposed to do any type of configuration in the Salesforce, not only the name credential or the remote site setting, although they are not able to, they are not supposed to go and create the new objects or change any configuration in the real time. I hope I answered your question, Vinay. Yeah, that's all from my side. Again, thank you, folks. Thank you for your time. Yeah, thank you. Thank you, everyone. So thank you, Ankit, for sharing the knowledge once again. So guys will be connecting tomorrow, same time, and tomorrow I think Ankit will be doing some demo, right? Right, tomorrow we'll be covering how we can connect the postman with the Salesforce moreover, we'll also go and create a few rest services as well. Okay, great. So with this, we are taking a leave now and we'll be connecting tomorrow, same time. Thank you guys for being wonderful audience and thank you, Ankit, once again. See you guys tomorrow. Thank you all. Bye-bye.