36. The Power of Salesforce Asynchronous(2) | Jitendra Zaa

Jitendra Zaa shares a story of using Salesforce Asynchronous to fulfill the customer requirements.

Jitendra is Salesforce MVP, Evangelist, famous Salesforce blogger, Sr. Technical Architect at Bluewolf, 23x Salesforce Certificates.

Main Points on Salesforce Asynchronous

This is the 2nd part of the storytelling from the guest Jitendra Zaa.

He shares a super exciting Salesforce implementation journey, where he and his team attempted to obtain as much as possible Salesforce platform potential by using asynchronous methods to fulfill customer requirements.

The story covers this and the previous episodes.

Links

• Jitendra’s twitter
• Jitendra’s home page
• Jitendra’s blog
• Virtual Dreamin’

Video Teaser

The YouTube Video URL

Transcript

AI-generated, unedited.

[00:00] Hi, this is the second part of the conversation I had with Jitendra Zaa. If you haven't listened to the previous episode, please go back to listen to that first. Otherwise, you won't understand what we are talking about here. That's it. Let's dive into the show. Okay, so then what happened is, I tried to find multiple ways that how can I submit more than fifty job. Okay, trust me. In a single transaction, I still have a limit. Okay, there is no way I can go beyond seventy two thousand. Out of five million, I can only grab seventy two thousand money. Yeah, that I did research and research and research. Now this is the heart of the solution. Okay, where things are gonna scale is what I did is. I did, and again, it's not me alone. A lot of my developers did POC with me. I ask, I gave each developer some task in my team. You try this, you try this, you try. There is no documentation around that. Okay. Okay. One thing you can do right in a single transaction is you can do the 10,000 DML. Agree. What I did is. I created

[01:31] 10,000 platform events from each one. Scheduler can fire 10,000 platform event. Okay,

[01:42] you can write a trigger on platform event.

[01:46] Ah, can you? And yes, you can. And that trigger, my friend, can fire each platform event can fire fifty cubable. So, so now you are talking about this platform event. We didn't talk about in the past. This is the newest asynchronous method, and that's the cube you found. Yes, and again, platform event is a pub sub model, very powerful feature, right? So, one so here is the previous, and you do the maths, okay? One scheduler was only able to process 50 job. Right. One platform event can fire, so one scheduler can fire ten thousand platform event, and each platform event can fire fifty jobs. So previously, one scheduler can only process fifty cubable. You increase the capacity of single scheduler by ten thousand fold. Okay. So that's how you are going to. Try to get the money again. Let's let's rewind. Let's rewind. Okay, without platform event, one scheduler can fire only fifty asynchronous job. Now what you do is you instead of firing the 50k able job, ask a scheduler. One scheduler I'm talking about that to create 10,000 platform event.

[03:17] The time you create the platform event transaction finishes, and there is another asynchronous transaction executes. Scheduler know nothing about that. Now each my platform event is one bucket. Previously I was talking about ten hundred bucket, and now I am talking about ten thousand bucket. Hmm. Okay. So each platform event know that okay, I am platform event bucket one. I am platform because in platform event also you can create some custom field. So while I was creating a platform event in a scheduler, I was giving each platform event their number. You are number one platform event. You are number two, which was nothing but the bucket number. Okay. So now I have ten thousand multiplied by fifty capacity. Hmm. So five hundred k. Now we are talking about. Yes, and once only one scheduler now. Yeah, yeah. You you can keep. Okay, I will come to that part also. Okay, that how I increase this limit also. But this is the initial, right? So you mean, and also one thing, one thing to cover is that by that time when you trying to find out what can solve your problem, you find out platform event can help. And by that time, you did not have any documentation publicly to telling you this can help you. You just tried it out. Yeah. Right. See, this is this is yeah. There is never one size fits all concept, right? Salesforce gives you a tool, and trust me, I don't think even Peter or anybody from Salesforce

[04:47] side would know what miracle Salesforce community can do. It's all permutation and combination game. Okay. They can tell you that what this feature does. They cannot tell you how to how that feature. It's like a Lego box, right? How you can use it in multiple ways, right? Okay. Yes. Yes. Okay. Yeah. Yeah. Let's move forward. But my yeah. Let's move forward now. Here is a twist in the story. Okay, platform event I got working. My capacity in the single off schedule single scheduler increased ten thousand fold because I could create ten thousand platform event. Each platform event can create fifty fifty jobs now.

[05:28] The slight problem is, platform event executes as a automated user.

[05:38] It does not execute as a system admin. So when you run a scheduler, you say that okay, run this scheduler as Jitendra Zaa or she, right, or maybe someone else. You have a you have a control that what would be the running user context on the scheduler, right? You don't have that control on the platform event. So you talk about platform event, or you talk asynchronous trigger, or you talk change data capture. All these three are new asynchronous methods. Behind the scene, everything is using platform event. Any trigger you write on platform event.

[06:17] Will run as automated user. Okay, that's interesting. Okay, that's okay. So that means. You cannot access that user. You cannot change profile of that user. You cannot assign permission set to that user because that is not the real user. You're not paying for it. It's a Salesforce having some user which is automated process. You might have seen that user somewhere in your org, right? After upgrade, or Salesforce is doing some tricking or enhancement, right? Now the problem is I don't want my developers or all other 50 developers in my team and have a technical dept document. Hey, if you want to do this, don't you cannot use my asynchronous. I didn't want it that flaw in my solution. Yeah. The problem with that is you might be thinking, okay, what is the problem? Either it's running as a Jitendra Zaa or maybe it is running for automated user. That should be fine. No. If it is not the actual user, you cannot perform user-specific tasks. So, for an example, you cannot send an email. Oh, now there is a there is a stack exchange question. Lot of threads going on that hey, we are coming in the mainstream with the platform event. Almost every design architecture calls Dreamforce calls are happening, asking us to adopt the platform event. But until you resolve this problem, where it is being executed as an automated user, not the actual user, it would be the problem. Yes, you would not be able to take

[07:47] the. You cannot take the full advantage of the platform event. I agree. But how do you want to do that? If you want to know, wait ten more minutes on this podcast. You will. Okay. Okay. Alright.

[08:04] That's wow. Yeah, this is fascinating story. I like it. Okay, Dawa. Yeah, I mean you cannot send an email, right? You are solving one problem and then you are stopping on another problem. Yeah. Okay. Yeah. So what you will do? What you will do is, if somehow I can change the context of because my only problem is now the context of the running user, right? My running user is a. Automated user, can I make it back to the Jitender? Otherment, question is for all the audience. Think through it in Salesforce. Can you change the running? Can you change the context of the user? Now you can change the context in the test classes. Of course, test dot run as method you can use, and suddenly your user changes. Can you do it in the normal stream? Can you do it in normal way? Search stack exchange, search everywhere, and this is one of the blog posts that was private for the long time on my blog. Okay, okay, through it.

[09:14] If you ask anybody, can you change the running user context in the Salesforce? Might be some some may know about that. I'm not saying not everybody will know, but this is very unique solution. Okay, how do you change that? Because if I change that, if I resolve that problem, I'm good. Yeah, yeah. Right. All that's that's all I care, right? Yeah. So.

[09:38] Let me try to gather my thoughts. What I was thinking. Yeah, no worries. You can take as long as you want. This is the final shot. This is a final shot. Yes, this is a final piece of puzzle. Yeah, yeah. To make the whole picture. Indeed. Okay.

[10:00] Hi, here's a quick note. Don't forget to check the show notes of this episode, where you can find short video teasers, the guest contact information, the important complementary materials, and my own learning points, among many other useful information. In addition, I have also started a YouTube channel to share important stuff I learned from my guest. If you are serious about your Salesforce developer journey, you should definitely consider subscribing to this channel. And obviously, the name of this YouTube channel is Salesforce Way. Now let's get back to the show, shall we? How how did I change the running user context on the actual code or actual functionality, not in the test class? And solution, my friend, is named credential. Named? Oh Jesus! You can use that. So here is what I did. Okay, okay. I asked my system admin. Of course, projects like this big, you don't have a production access. Of course, you have to go from the DevOps CI CD. Again, that's a different story. So I asked my system admin. I need your help. Okay, of course I did my POC testing, everything, regression testing, system testing done on the sandbox and everything. What I ask him that, okay, go on the production org, maybe sandbox. I'll start with the sandbox.

[11:30] Authenticate yourself to the same org using name. So authenticate Salesforce org as a sales in the Salesforce org itself. You can do it. So you go in the named credential, and you say that okay, this named credential is for the Salesforce org login dot Salesforce dot com. You save the named credential. It asks you for the username and the password, which is OAuth two flow. We are not storing username any we are not storing password anywhere. It's all safe. App will appear and it will say, "Do you want to authorize the same org for your user in the name credential?" So in the same org I created name credential and the same org was talking to itself. It's the internally REST API. So here is how the puzzle works. So I create 10,000 platform event from a scheduler. Okay, each platform event is running as automated user, which was my challenge. Now what I'm doing is I am calling named credential to myself, or in the named credential, you know who authenticated that. That was the system admin. So automated process call the web service. Web service when I call it, change the context to the actual user. Now I have my main user, and that web service executed 50 queryable. That gave me what I wanted. Okay, so just just let let me make sure I'm hearing correct. So you have this auto

[13:00] automated user which has a thread already in the platform, and then you create a named credential. Which sits there waiting for somebody to call it and use this automated method to reach that thread using the named credential, and then you use the REST API to call yourself, call the same platform in a way to switch the context or yeah. So what I did is I created a custom Apex, custom REST API. So named credential helps you to authenticate. After authentication is done, which endpoint you wanna hit? That endpoint is aware that which bucket I am. So platform event will pass number one to that API. Platform event two will pass number two. Same way, platform event number ten thousand will say I am number ten thousand. That REST API, all it is doing is it is reading the bucket number. It is doing the SOQL in the database, okay? And it is firing fifty kilobyte job of that bucket. So if you draw the so if you draw the diagram right, the diagram is scheduler. Scheduler calls platform event. Okay. Each platform event has a trigger written. Each trigger calls named credential to change the running user context, and that named credential has a custom Apex class behind the scene. Okay, which is calling the fifty fifty fifty fifty jobs. Okay.

[14:30] Okay. So the the essential part here is still using the named credential somehow to switch the the running user. User. Correct. How did you find it? How did you figure it out? This was the—I mean—how did you even think this was one of the solutions, one of possible solutions? Years of years of experience. Okay, have you used the named credential to bypass some other kind of limitations or challenges before? No named credential is pretty powerful and one of my favorite. Feature for the long time. So, eight or nine years back, I wanted to integrate Salesforce to Salesforce, and I wrote hundreds of hundreds of lines of code on authentication part. And then suddenly named credential came. Trust me, you can integrate one Salesforce org to another Salesforce org using named credential in the less than five line of code. And that post is still on my blog. Okay, so named credential is pretty powerful. You don't have to provide username or password. Salesforce internally handles it, and that really helps you to pass the security review of your org. If you have enterprise architect or you have security architect in your project, they always need a documentation from you. Hey, how do you are making sure that you are not passing username or password or anywhere? Name credential is the way to go. It's very easy to get a sign off from client that hey,

[16:01] the APIs which I am calling is super safe. And trust me, in these day, I mean, Salesforce is no no no longer a CRM. No, almost every client who is using Salesforce. Most of the time, they have a multiple orgs. I don't. I have not seen for the long time that the client is only having a one Salesforce org. I had one client which had like 40 plus org in 2013. Recently, I have seen one client which has like 200 plus Salesforce org. Really? Yes. And again, that's where comes the center of excellence. Sorry, we will go deviate. That's a different topic. Okay, all together. But that's how. There is very common need to integrate your Salesforce with Facebook, Genren, maybe Twitter, another Salesforce or an M credential is where comes into picture. And if something is not provided out of the box, you do have a capacity to write a custom Apex based connector. Which would be used by a named credential. So you Salesforce still like Salesforce is a API first platform, right? It first gives you the capability as a name. They love developer. They love admin, right? So. They give you all the way, all the they give you all the Lego boxes. You just go and yeah design your own Lego. Because, because I think here is the difference between you and me. For me, I understand the name credential idea, and I have tried it. Basically, to me, it's like you don't

[17:31] need. Uh, put your username password into like a plain text space, and here you can just put it there, and then securely, you know, it just does its magic to then authenticate, allow the web service to run according to your credential. But I never thought of put this into that challenge you had to switch the context. I never thought of how I need to understand, you know. Under that name credential, the Apex is running under the same user credential. That I, I mean, I'm not that deep enough understanding it, so I will never think about that. I think this is a major difference. So what I was thinking, right? I was on the hunt that how many ways I can, or other way to put it, in Salesforce setting, how many places I have to write run as user. That was the clue. That is the clue for every listeners. This is how you know that which part in Salesforce allows you to change the context. So for an example. Email services is also one of the solution you can go with because email services also gives you a run as capability. Scheduler gives you run as capability, and of course named credential gives you the run as capacity. So it's not only named credential can be used. You can use email services also. Do you mean when we run

[19:01] the email service, we can also switch the context of the user to send? Yeah, because if you go in this. If you go in the setting of email services, you will see there is an option saying that this email service needs to run by user A, B, or C. Okay. But then the question is, the question is why I have not used that? Why I have used this? Yeah, yeah. Okay, okay. Governor limits my. Yeah, this is this is a very good story. Okay, okay. Let's let's recap. So you are a principal architect in the project. You you need to study those governor limits around the, you know, the environment, and you know you have this five five million five hundred million money five million five million a day you need to spend. And with the scheduler, you can only hit certain amounts, and it's not totally not enough. And you want to scale up, and you try to find the different ways to scale up, and eventually you find that event, platform event can somehow scale it up, but still you have this context issue coming. From the event platform event because it's running under the automated user. So the question, the final question was how to switch from the automated user to the real user that you want to use under the named credential was the answer. Okay. Yes, I'm the principal architect now. See, that's that's

[20:32] the difference, right? An engineer, right? If you're the engineers, if you're building a bridge, you don't have a leverage or the flexibility that oh you build a bridge. Oh, I made a mistake. Break the bridge and and then build again. You don't have that leverage, right? You you're not in that world. Oh, mistake happens because if your design is wrong design, you are literally spending thousands of dollars or thousands of hours of your developers who trusted on your design. So you need to make sure that what you're suggesting to your developer. To design it, so you have to. That is the reason governor limit. I will to all the architects here, right? Even if you are an admin or developer or technical architect, solution architect, me, what I consider first thing is large data volume, how the indexing query, everything is gonna work. And second thing I always consider is governor limit. If something is not problem today. There is no that doesn't mean that it is not gonna problem tomorrow. If you are writing a code today, you are not hitting governor limit. That is because you don't have data volume. Same code that is working today will start failing tomorrow if your data volume starts increasing. And simplest example, you do SOQL without limit clause. Okay, you put it on the production. It is working fine one year. Okay, the time it crosses fifty thousand record, your code starts failing. Too late. You can't do anything now. Yeah, right. You stop develop. Do emergency deployment.

[22:02] I mean, you cannot bypass testing. There's a lot of challenges. Yeah. So these two, these are the two main principle I always follow: data volume and governor limit. That's cool. Thanks. Thanks a lot. This was a fascinating story, and I really enjoy the chatting with you, because I'm a developer, and I'm based in Finland. Most of the organizations, compared to the U.S. companies, they are very small. So I don't get the chance to really play with the really really large enterprise architect environment. Like you said, hundreds of orgs. I can never imagine that, under this five million daily record limit. Yeah, I. You know, previously I also talked with Dan Appelman, who write this Advanced Apex book, and he was also I don't know you know him right. Yeah, Dan Appleman is kind of idol for all the architects, developers like me, like my our generation basically, right? I don't think you can say you are a very good developer if you have not read his read his book. Yeah, okay. I read his book multi. I have read his book multiple times. Even I have written a book named Apex Design Pattern. That's a completely different book. But the Advanced Apex is the book you should read if you want to become a good developer. Okay. Highly recommended. Yeah, we will put the book link down below. It's like each time when I talk with a developer, always this book is in the list. So yeah, yeah, yeah.

[23:32] No, no, no, no doubt. I'm also reading that book, and it's a book with a lot of wisdoms. You know, I just come back to your story here. You are telling us like within an hour time, but you definitely during the during the journey, you you are seeking multiple options. You are hitting the wall. You come back. You get the support from different people, right? That's how you you reach the end destination. It was, I was. It was three weeks of effort. Okay. Okay. I had my I had my dedicated team. Okay. And before going to the developer, that is one advantage I will see all the technical architects have that they are core developer from heart. So before I go to the developer saying, hey, try this, I try myself first. I know this is going to work or not going to work, and I don't think it is going to take a lot of time. Even to the listener, right? Username credential change, it fired platform event. I mean, it's very simple, simple things you can do in the Developer Org. Okay, so even though it seems pretty big journey, it's the whole design and implementation was done like in less than three weeks, and again the one of. I think I got lucky that my previous employer Cognizant, my current employer IBM. So IBM has a huge enterprise-level project. I mean. Like like I I told you one of the right, it's a big big project. I'm getting a chance to work there, challenge myself, and clients are yeah they want a digital transformation,

[25:03] and they're really getting a lot from us. And I'm not only the technical architect. I will tell you there's so many smart people around me, and each day is learning for me here. Okay. Wow! Everybody wants to go to IBM to work for Salesforce projects. All right, great, great, Jitendra. So I think we can have a great ending here. So the story was fascinating. I definitely enjoyed it, and I think a lot of our listeners enjoy it as well. There's no doubt about that. So before we close in this session, do you still have anything you want to say? Uh, not really. One kind of announcement is we are announcing a virtual dreaming. Okay, so that people people around the world can join the Dreaming event from the comfort of their home, office, tablet, desktop. Okay, that is sometime around uh February. Okay, and there are going to be a lot of cool topics like this. It's a free entry for everyone who can join. Recorded one. Okay, so. Yeah, yeah. So keep a keep an eyes on a announcement. Yeah, give give me more information about that event. I'll put down in our show notes as well. Sure. Okay, okay. Thanks a lot. So, awesome. It's a nice talking to you. Yeah, nice talking to you. Thanks for having on your podcast. Thank you. Thank you. Talk next time. Bye bye.

[26:35] Yeah.

[26:38] If you enjoyed listening to this session and want to have a really easy way to support this podcast, Why don't you give us a quick rating or even a review on whatever channel you are listening to this show? If you are using iTunes, just go to SalesforceWay.com/itunes. It should open up the iTunes page for you. I read pretty much all the reviews you leave over there, and it really helps other people discover this show. So your support is very much appreciated, and and I'd really love to hear how you think about this podcast. At last, I hope you are doing well, taking care, and see you next time.