Abstract
Wow! How much fun was that last chapter?! I’m sure you have a ton of questions, but unfortunately you will have to wait until Chapter 13 (which deals with frequently asked questions) to have them answered. I tried to think of every question you could possibly ask, but there is no way that I could possibly anticipate even half of them (sorry). The good news is that if your questions are about error handling or performance tuning, then this is the chapter you are looking for! A lot of the content in this chapter has been covered in pieces throughout out the previous seven chapters, but I thought it was important to centralize this information so you can read through it with a focus specifically on error handling and performance. So, this chapter is a bit of a review. Let’s get started.
This is a preview of subscription content, log in via an institution.
Buying options
Tax calculation will be finalised at checkout
Purchases are for personal use only
Learn about institutional subscriptionsNotes
- 1.
You should log all job runs with proper diagnostic information regardless of whether the job fails. This information will come in handy later. For example, suppose that one day you notice the job is taking longer than normal to finish. You can go through the logs and look at the historical runtime data. When did the slowdown start? Was it on a particular day? Or has there been a slow degradation of performance?
- 2.
For Salesforce integrations, I like to use a dedicated Salesforce service user account with its password set to never expire. Check your client’s IT security policies.
- 3.
This is the third footnote in Chapter 7. When we loaded TaskRelation records we used the Task Success table rather than download all tasks from Salesforce. So, we won’t add contacts that were loaded with this batch to tasks that where created from previous batches. What’s crazy is that we examined this exact issue several times, but with regard to adding contacts that were created with previous batches. It goes to show just how easily something like this can slip through the cracks. We really need to be diligent with our code.
- 4.
- 5.
For more information, see https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_triggers_order_of_execution.htm .
- 6.
Many companies, even ones with mature change release policies and procedures, have not yet caught up to the cloud revolution and have no policies on how to release code to cloud-based systems. In all fairness, it’s a tough issue. How can you hire a new Salesforce administrator then tie their hands and tell them, “No ‘coding.’ Oh! And you can’t so much as create a new page layout without running it through IT, an architecture review board, and a regression test of the entire system, followed by the creation of a release document. Don’t even think about it!” This kind of release process is simply not in the “Salesforce spirit”, I get it. But a line has to be drawn somewhere, and many organizations are struggling with this.
- 7.
Remember, this only happens in sandboxes. Salesforce won’t “break” a production org because of disk space.
- 8.
For more information, see https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_gov_limits.htm .
- 9.
- 10.
For more information, see https://help.salesforce.com/articleView?id=admin_monitorresources.htm&type=5 .
- 11.
Salesforce also has a nifty Record Locking Cheat Sheet. See https://developer.salesforce.com/blogs/engineering/2014/07/record-locking-cheat-sheet.html .
- 12.
Although you can submit 10,000 records with a single API call, and Salesforce reports on those 10,000 records as a single job on the Monitor Bulk Jobs page, under the covers it’s processing records in batches of 200.
- 13.
And presumably update it four times, if my inverted index theory I mentioned in Chapter 2 is correct. Regardless, Salesforce must be updating something on the account record; otherwise, why would it need to lock it?
- 14.
For more information, see https://www.google.com/search?q=premature+performance+optimization+debate .
- 15.
- 16.
For more information, see https://help.salesforce.com/articleView?id=relationships_considerations.htm&type=5 .
- 17.
For more information, see https://developer.salesforce.com/page/Best_Practice%3A_Bulkify_Your_Code .
- 18.
Remember that a single Salesforce user can only have ten active API queries running at once, so there are limits to how much you can run in parallel in your ETL package.
- 19.
Author information
Authors and Affiliations
Rights and permissions
Copyright information
© 2019 David Masri
About this chapter
Cite this chapter
Masri, D. (2019). Error Handling and Performance Tuning. In: Developing Data Migrations and Integrations with Salesforce. Apress, Berkeley, CA. https://doi.org/10.1007/978-1-4842-4209-4_8
Download citation
DOI: https://doi.org/10.1007/978-1-4842-4209-4_8
Published:
Publisher Name: Apress, Berkeley, CA
Print ISBN: 978-1-4842-4208-7
Online ISBN: 978-1-4842-4209-4
eBook Packages: Professional and Applied ComputingProfessional and Applied Computing (R0)Apress Access Books