![\"\"](\"https:\/\/www.webperformance.com\/load-testing-tools\/blog\/wp-content\/uploads\/2023\/03\/salesforce-logo.png\"){kind=logo}
<\/p>\n<\/p>\n
<\/p>\n
CRM functionality is so integral to many business workflows that writing a Salesforce app is often cheaper and faster than starting from scratch. \u00a0Why reinvent the wheel with 50%+ of the functionality you need is already in Salesforce? \u00a0But just like a 100% custom app, Salesforce apps must be tested for performance, not just functionality, especially when integrating into an existing customer back-office or 3rd party system. \u00a0And Salesforce is one of the more difficult platforms to test because of the complicated field naming conventions typical of auto-generated front ends.<\/p>\n
The first challenge is just the sheer overall complexity of a Salesforce app. \u00a0 The last app we tested had around 40,000 separate fields, most needing to be updated dynamically. \u00a0 Often something this complex would require a browser-driven approach, but load testing through selenium still doesn’t collect the breadth of information you get with an HTTP-based approach. \u00a0To overcome that, we created custom configurations that <\/a>handle most of the complexity automatically. \u00a0The downside was running the auto-correlation process took between 15 minutes and several hours, depending on the test case’s length and the computer’s processing power.<\/p>\n The biggest challenge is that Salesforce uses dynamically changing field names<\/em> when writing values from forms. \u00a0Here is a typical example of how Salesforce handles writing parameters via a JSON POST:<\/p>\n The name part of the JSON name\/value pairs are in the format “a0Y760000…”, and they are different for every user and every field. \u00a0This is likely a design choice to increase parallelization when writing into the database at scale, but it makes simulating this behavior in a script quite difficult. \u00a0Upon playback, each virtual user must parse each of the field names and values, and correlate the updated field names with the existing form defined in the test case. \u00a0The field names are defined earlier in the HTML, and always use the format:<\/p>\n “Id”:”a0Y76000002HH5aEAG”<\/p>\n This means location context inside a larger JSON string must be used to determine exactly which dynamic field name “Id” refers to.<\/p>\n In addition to dynamically named fields, there are 1,400+ fields which dynamic values that need configuring. \u00a0The most important ones include token, aura.token, jwt, fuid, message, etc. \u00a0To use just one example, “token”, it is part of a JSON name\/value pair, and thus is delimited by a double-quote. \u00a0 The regular expression for parsing would then be \u00a0“token”:”([\\.0-9a-zA-Z_=-]++)”<\/strong> as shown below:<\/p>\n It’s possible to parse Salesforce name\/value pairs by simply looking for the typical JSON pattern of “name”:”value” without actually checking with is within the parentheses, but that leaves open the possibility that you’re actually parsing the wrong field, which is definitely possible with dynamic field names changing along with the values. \u00a0 It’s much safer to ensure the value being parsed matches the general pattern of what is expected.<\/p>\n This is just a general overview of Salesforce load testing via HTTP. \u00a0While the screenshots are specific to our load testing software<\/a>, the general approach is needed with any load-testing software.<\/p>\n <\/p>\n <\/p>\n <\/p>\n <\/p>\n","protected":false},"excerpt":{"rendered":" <\/p>\n CRM functionality is so integral to many business workflows that writing a Salesforce app is often cheaper and faster than starting from scratch. \u00a0Why reinvent the wheel with 50%+ of the functionality you need is already in Salesforce? \u00a0But just like a 100% custom app, Salesforce apps must be tested for performance, not just functionality, especially when integrating into an existing customer back-office or 3rd party system. \u00a0And Salesforce is one of the more difficult platforms to test because of the complicated field naming conventions typical of auto-generated front ends.<\/p>\n
<\/p>\n
\nThe first challenge is just the sheer overall complexity of a … Continue reading »<\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[57,8,202,42],"tags":[],"class_list":["post-6321","post","type-post","status-publish","format-standard","hentry","category-company","category-load-testing","category-uncategorized-en","category-load-tester-software"],"_links":{"self":[{"href":"https:\/\/www.webperformance.com\/load-testing-tools\/blog\/wp-json\/wp\/v2\/posts\/6321","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.webperformance.com\/load-testing-tools\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.webperformance.com\/load-testing-tools\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.webperformance.com\/load-testing-tools\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.webperformance.com\/load-testing-tools\/blog\/wp-json\/wp\/v2\/comments?post=6321"}],"version-history":[{"count":16,"href":"https:\/\/www.webperformance.com\/load-testing-tools\/blog\/wp-json\/wp\/v2\/posts\/6321\/revisions"}],"predecessor-version":[{"id":6338,"href":"https:\/\/www.webperformance.com\/load-testing-tools\/blog\/wp-json\/wp\/v2\/posts\/6321\/revisions\/6338"}],"wp:attachment":[{"href":"https:\/\/www.webperformance.com\/load-testing-tools\/blog\/wp-json\/wp\/v2\/media?parent=6321"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.webperformance.com\/load-testing-tools\/blog\/wp-json\/wp\/v2\/categories?post=6321"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.webperformance.com\/load-testing-tools\/blog\/wp-json\/wp\/v2\/tags?post=6321"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}