Welcome to That Salesforce Guy. My name is Rohitkumar and on this channel I will be sharing my experiences about my Salesforce Journey. I will be doing live streams and solving Trailhead as well as some custom projects. If you have any ideas do share them so I can learn from you guys as well! Feel free to drop a comment or an email if you have any questions.
Body is something that will contain data if not the URL Params, if your goal is to send information to Salesforce then you have to send data in body or URL params.
@@ThatSalesforceGuy great thanks, I have just come across the channel, and watched allll the videos. It would be really great if you could upload videos more frequently. Thank you!!!
Thank you, regarding callback url, umm imagine a callback URL like a doorbell. When a computer finishes its job, it rings this special doorbell to tell your computer, 'I'm done!
In output tab only you have to search, I will suggest put it as System.debug('oppList --> '+oppList); so you can hit CTRL + F and search for oppList , you will find your debug statement.
not working getting { "error": "invalid_grant", "error_description": "authentication failure" } i double check the client_id client_secret etc ip relaxation is selected and password+security token is also added still sam eissue
Really helpful video compared to the other demos I've seen. Note that now Salesforce is transforming Omnistudio into the standard object. The class should be instead "global without sharing class RemoteClass implements omnistudio.VlocityOpenInterface"
Thanks alot Ajay, I have planned few good tutorials but I am just having some hard time in my life right now so I am taking some break. Although I will mostly start creating content next month :) Take care.
Bro, can we use catch( exception EX) for all scenarios. I seen there many many types of exception handlings like catch(NullPointerException e), catch(DmlException e), AuraHandled Can we use just basic can we use catch( exception EX). Or do we need to use these specific one ? Please help me out with this clarification
yes, you can use ( exception ex) for all scenarios, you can use ex.getMessage(); and ex.getStackTraceString(); methods to get info on your error/exception. The reason salesforce has provided different types of exceptions is to get more granular information, like in DmlException you can call getDmlFieldNames, getDmlType etc (refer developer.salesforce.com/docs/atlas.en-us.apexref.meta/apexref/apex_classes_exception_methods.htm) So it again depends on your use case if you need more granular data but as far as I have seen, generic exception when implemented with getMessage & getStackTraceString methods is enough. I will be doing another video in depth for exceptions and handling, might include some open source frameworks (but I don't want to include extra unncessary code in any project where chances are most likely it won't be utilized haha) Thanks for the question btw.
This is not a good error handling strategy. You're basically just swallowing the exception and therefore it won't surface to the standard UI or any VF Pages or Lightning components or show up on import result files so your users won't have any idea that something went wrong, your execution will continue after the catch block if there's any code written after it which has a high probability of unexpected behavior since the operation in the try block didn't work as expected. If you were to re-throw the exception in your catch block then it would avoid those problems but then your insert of your log record would be rolled-back anyway so your admin or whoever is responsible for reviewing the logs would hear from the user there was a problem but not find the corresponding log file since it wasn't committed to the database. A proper logging framework (like Nebula Logger) uses platform events because that allows for log records to be created even if the overall transaction failed due to an exception. Additionally, whether you're logging or not, your exception handling needs to be done in a way that the caller code that is as close to the top of the call stack as possible is passing along some kind of message to the user that what they wanted to do failed and why. And ideally, depending on the type of exception, you'd be able to give them options for curing the issue and re-trying. Yes in this example he was just calling it from the anonymous apex window but in a real life example the code would be triggered by some user action or scheduled APEX or some other process that can't just fail silently like that. In order to do this effectively you should have some kind of layered architecture where you've got controller classes for your VF pages/Lightning Components, some kind of trigger handler framework, and some kind of service class implementation so that your business logic is separated out from the various places it might be called from. The exceptions will throw from wherever your logic is and then you'll catch them in the controller/trigger handler because then you'll know the context in which the code was called and what the appropriate message to pass along to the user is.
Hey Jim, I totally agree with you as this was just an example on how you can build your exception handling logic, to be honest, it depends on your use cases if you are using VF Pages, LWC/Aura or Scheduled Apex, APIs etc. Incase of any DML operation we can always use rollback mechanism, also for a good user experience (let's say you are giving retry option or retrying it through batch etc) it is going to be a custom logic/framework. However after reading your comment, I will be uploading videos on some good error handling frameworks out there (will try the Nebula Logger since it supports Apex, Lightning Components (lwc & aura), Flow & Process Builder) I always seek critical feedbacks and try to learn more, appreciate your response and I am hoping to receive your feedbacks on my future videos :)
@@ThatSalesforceGuy it's just that your thumbnail says "how to handle like a pro" and the description says "highly effective" and you use the hashtag #bestpractice so to someone who doesn't know any better they would try to implement this exact approach in their production code (in fact, another commenter said they did just that) so it isn't "just an example" I can't think of any use case where this would be the appropriate way of doing things.
@@jimconingsby4616 I have personally worked in multiple projects with some talented architects and trust me for apex this is the best and most effective logic we have always used, further this can be enhanced as per the needs. If you can't think of any use case then probably you are just making things complex with managed packages which are not needed most of the times :) I believe a developer should write minimum, effective code.
@@ThatSalesforceGuy if you say so. My original comment stands...in your example you're swallowing the exception which goes against basic programming best practices in almost all cases and you shouldn't be telling people on youtube to proliferate this pattern around their code base because it will 100% lead to data integrity issues and bad user experiences where something doesn't work but a) it doesn't explicitly tell them it didn't work and b) it doesn't explain why (presumably your average user isn't going to have access to your error log object or even know to go look there). Certainly it's enough of a recognized anti-pattern that it shouldn't be held up as the primary methodology of doing exception handling as you've done in your video. Present the normal use case (which is not swallowing the exception) and mention that it's acceptable to do so only if the use case for whatever reason doesn't need for the transaction to fail and for the user to be informed even if the code in the try block does fail. And the overwhelming consensus is that any attempt to do an error log should be done using platform events and that has been true since they became available. Feel free to dispute me but don't just say "well me and my friends have done it before" tell me why you don't think that it's a problem that your DML of your error log record will be rolled back if the transaction fails. You cannot justify it. Error logging is most useful when a transaction fails and if you do it the way you're doing it then you'll lose any of the error log records you thought you were making if there's any other exception thrown in the rest of the transaction. You don't need to use a managed package to do platform event based error logging, you can definitely roll your own. It's not difficult code to write. But using managed packages is also not a sign of complexity. This is what using Nebula logger looks like: catch(Exception e){ Nebula.Logger.error('Something went wrong',e); //even with nebula logger you still need to do something to either surface the exception in a user friendly way to the user or to execute some kind of logic to ensure the transaction is ok to continue. That code would go here, depending on what your use case it. } I would argue that using Nebula Logger is actually *less* complex than what you suggested because then you don't need to create your own object or code or anything (not that what you did is hard, but neither is installing a package) you just install it and use it as above. It is a well written and fully tested and widely adopted framework. Importantly, it works even if the transaction fails whereas yours does not. And if you're worried about tightly coupling your code to a third party framework then you can easily create a facade layer to de-couple it which shouldn't be any problem for a pro. I'm not worried about convincing you. But for anyone visiting your page I hope they read the comments and consider using actual best practices: Catch exceptions as high up the call stack as you can so that there's greater contextual awareness of the best way to handle them. Log them using a platform event based logging framework. If the code is invoked as part of a trigger then utilize the .addError() method on the record(s) affected so that the error will surface either to the record page UI or the error file produced by either the bulk or batch api. Generally it is best if you translate the exception message into something more user friendly when you do this. If the code is invoked by a call from a component or VF page then surface the error to the component or page to be handled and presented to the user. Or, if the user doesn't need to know about the problem and it's ok for the execution to continue on, execute some logic in your catch block that ensures the state of the transaction is ok to continue. Fault tolerant design is fine but you have to do *something* when almost any exception happens you can't normally just log it and say ok keep going. I agree that minimum effective code is the goal. But it must be effective. Your suggestion is a ticking time bomb where your users don't find out about any errors and your logs may or may not be saved. Add this line (throw new AuraHandledException('There was a problem with your request. Please view the error logs for more information'); ) after the line where you log (UtilityClass.createElog('TutorialClass','tutMethod'null,ex); ) and you'll find that your log file was rolled back and then you lose all knowledge of the error. Would you agree that your approach prevents you from elevating errors to the user interface while preserving your error log records?
Hi Rohit, These extensions are really awesome and famous but Please explain about Salesforce Simplified chrome extension as well. This extension is very old but not much famous but extremely helpful for Salesforce Admin, Dev and for Omnistudio developers, I am using this from last 2 years and this has saved my lot of time.
i create account as Developer and i followed same steps but still getting error { "error": "invalid_grant", "error_description": "authentication failure" }
I will be publishing the REST API Framework soon, stay tuned! Edit : I was occupied with my personal life, 2024 is gonna be the best year ahead! I am working on few videos already :)
Great trying to cover API things. Please make one real life scenario on fully Integration where cover those things which is related to Integration. Nice Video 🤠
Sure, I will be uploading the API Framework Video soon and Definitely a real life scenario as well, you can go through this custom rest api video before that --> ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-T9S6odjkxNE.html&lc
I have searched a lot on RU-vid for inbound integration in Salesforce. Basically, I am from a Siebel background and transitioned to Salesforce with no formal training. I struggled a lot and this video in a sense saved me. I can't thank you enough for teaching me how to do an inbound Rest API integration brother. 🫂
