AddThis Feed Button

Recent Items

My users recently reported a strange problem with an S-Control. Yes, we’re actually still using this outdated capability of Salesforce.com. In fact, when I got to manage the S-Controls, this message appears:

So why are we still using S-Controls? Well, most because it still works but also because I haven’t quite figured out how to convert the functionality to VisualForce. My S-Control is being used to show related opportunities, very similar to the technique that I published on the Salesforce Developer Wiki back in 2008 regarding S-Controls and AJAX: Showing a pull-down list of related contacts.

Jon Mountjoy, godfather of the Salesforce developer community, even put a note on it in December 2009 to say that S-Controls are being deprecated. So, point taken!

Anyway, my users were reporting that the S-Control occasionally didn’t work. I couldn’t figure out the problem but, while checking the browser error log, I saw this message:

Uncaught {faultcode:’sf:REQUEST_LIMIT_EXCEEDED’, faultstring:’REQUEST_LIMIT_EXCEEDED: TotalRequests Limit exceeded.’, detail:{UnexpectedErrorFault:{exceptionCode:’REQUEST_LIMIT_EXCEEDED’, exceptionMessage:’TotalRequests Limit exceeded.’, }, }, }

A Google search led me to a Pervasive page that sent me to the official Salesforce documentation on API Usage Metering. A quick check on my organization showed that I had exceeded my allowable limit of 28,000 API calls in a 24-hour period.

Salesforce, in selling subscriptions to a multi-tenant system, have wisely included governor limits on various parts of the system to prevent particular customers over-using the system, thereby impacting performance for other users. And, it would seem, we exceeded our limit.

The limit, I should point out, is actually very generous — especially when we realised how we are entitled to 28,000 API calls. It consists of:

  • 1,000 calls per full Salesforce license (we have 8 users, so that’s 8 x 1,000 = 8,000)
  • 200 calls per free Force.com license (we have 100, so that’s 100 x 200 = 20,000)

Yes, most of our allowance actually comes from free licenses (see my earlier blog post on 100 Free Force.com licenses on your normal Salesforce account)!

According to my calculations, it would have required my users to display a page every 6 seconds to exceed this limit. This was unlikely to be the culprit. So, I had to consider what else was using the API calls and I realised that it was our automated Data Loader processes. We load information into our Salesforce instance automatically each day and hour. If our data volumes had increased, this could have led to an API overrun.

Our Data Loader imports are running in batches of 100 due to a problem with larger batch sizes (again, see my earlier blog post Beware Trigger batches over 100 records). This might have been fixed since then, but the system is still running in batches of 100. To exceed the API limit, this would have required 2,800,000 records to be loaded in 24 hours, which is amazingly high.

Alas, it was true. Due to a problem we had in our system, a lot of our customer data had been updated. This, in turn, triggered an update to Salesforce. (To be honest, I was the cause of the problem — see my post on Atlassian’s news blog, 40,000 apologies from Kitty and friends).

Net result… tens of thousands of records were loading into Salesforce and, due to the way we load incremental data, they were loaded several times. Thus, the culprit was found!

Sure enough, now that it has been more than 24 hours since the update, our API Usage count has been decreasing and things are back to normal.

I have also setup an “API Usage Notification” (accessed via Setup) so that I’ll receive an email if this happens again in future. Those Salesforce people think of everything!

The Bottom Line

  • Governor limits protect other users on Salesforce.com
  • They are a good way to stop things that seem to be going wrong
  • If we had governor limits on our systems, a lot of embarrassment could have been avoided, too!
  • I’m still not going to change my S-Control, so there!

Once upon a time, I had to Override the standard New button on my Contact object to set a field value as part of the record created. (Specifically, I wanted to set the Account field to a default value.) I did this by creating a Custom S-Control:

It has to be done as an S-Control because the ‘Override’ function only permits S-Controls and Visualforce pages:

That all went very well.

Cloning

I have since been requested by my users to permit Cloning of a Contact record. Here at Atlassian, we have Contacts with two Record Types:

  • Manually created: Fully editable within Salesforce
  • Imported from our Customer Database: Mostly read-only, loaded via DataLoader

I have no problems with peole cloning ‘Manually created’ Contact records, so I provide the normal Clone button. However, for Contact records ‘Imported from our Customer Database’, I was not willing to permit cloning because:

  • The record type would need to be changed (to ‘Manually created’)
  • The ID field from our Customer Database would need to be cleared
  • Many fields should not actually be cloned (eg Name) because the prime purpose of enabling Clone was to save typing when creating a new Contact from the same company as an existing Contact

In the end, instead of a ‘Clone’ button, I decided to implement a ‘Copy’ button that created a new record but automatically copied selected fields across to the new record:

Two important things to note:

  • Field values are passed in the URL, eg ‘con4′ is the Account field
  • I appended a custom field to the end

The technique of setting fields in the URL is standard in the user community. I don’t know if it’s meant to be officially done, but enough people do it that it is pseudo-official. I get field names (eg con4, con19street) by viewing the Page Source of the Salesforce page and looking for the field of interest. Hopefully they’ll stay the same across change to the Page Layout.

Custom fields, however, are known to produce problems. Rather than having a nice field name (eg conRegion__c), the Page Source uses the ID of the custom field. You can prove this by putting the ID in a URL, such as na1.salesforce.com/00N20000001Bx9v. Unfortunately, this results in an error because the URL doesn’t understand something that starts with two zeros.

By a stroke of luck, I found that I could append the Custom Field to the end of the URL (outside the URLFOR command), which would be correctly added to the generated URL that creates the new object. This has driven people crazy for ages, so I figured it was worth a blog post to help future generations of Salesforce Administrators!

The Bottom Line

  • Add custom fields to a URL by placing the custom field assignment AFTER the actual URLFOR statement
  • It can be easier to create a New record rather than a Clone, especially if you don’t want to copy most fields
Tags: s-controls

Can you spot the error in this code?

if ( {!Contact.Department} == 'Finance' )
...

Come on — try and guess it before reading the next paragraph!

The problem is that Salesforce.com inserts the value of the variable within the S-Control text, resulting in this:

if ( Finance == 'Finance' )

It should really go in quotes like this:

if ( '{!Contact.Department}' == 'Finance' )

That one gets me every time!

The Bottom Line

  • Quote inserted field names when they are strings
Tags: s-controls

I recently created an S-Control that displays contacts related by Email Address.

I was quite proud of my effort and, since I’m quite familiar with wikis (Atlassian sells a darn good one!), I decided to contribute my code to the developer.salesforce.com wiki. I’m a big believer in sharing information and I’ve gained a lot from the Community information online.

I received a few messages and feedback from people, which gave me the warm-fuzzies and made the effort worthwhile, but I was really impressed when I opened the next Salesforce E-Newletter:


If you want to read the article, you can find it at: S-Controls and AJAX: Showing a pull-down list of related contacts.

The Bottom Line

  • Sharing is nice, and it’s great to be recognised and appreciated. Thank you Salesforce!