MK Partners Apex Code

MK Partners is proud to announce that we have a new Contact Us page on our website. Our former Contact Us page was a web-to-lead form that submitted new leads directly into our salesforce org. It was very good at what it did, but we really needed a more powerful page.

Our new Contact Us page is powered by force.com Sites and it does much more than just enter leads into salesforce. The new page dynamically changes the questions on the screen based on why you are contacting us. If you’re contacting us for product support it you have to fill out questions related to the issue. If you’re contacting us for sales you have to fill out questions related to your project. But wait, there’s more, not only do the questions on the screen change, but the resulting record in salesforce changes too. Support inquiries turn into cases and sales inquiries turn into leads!

We fell this upgrade is is long overdue for us, not only because we are such proponents of using force.com Sites but also because it improves our efficiency and helps us respond faster to support requests.

If you’re interested in having MK Partners create a custom force.com Sites powered page for your website, fill out our Contact Us form at http://www.mkpartners.com/contact

Jesper Joergensen posted some interesting info last week about a new endpoint for the API that is currently available. The new endpoint is https://login.salesforce.com and according to Jesper will reduce your authentication time slightly.

While you’re at it, you may want to update your SOQL queries to take advantage of some of the new Aggregate Functions.

Check out the full post at http://blog.sforce.com/sforce/2010/02/new-api-login-endpoint.html

There’s a great post by Alex Lucas at CallingShotgun.net about what companies can do to make their API’s more developer friendly. Salesforce.com stands well against the list, take a look:

www.callingshotgun.net

I use Maps a lot when I write code, usually to help me reduce the number of times I have to do queries. Normally they work just fine and I don’t pay attention to the little details like the case of the text used in its keys. The other day though, I was getting some really weird results from my code. The code was being used to dedupe incoming records against existing ones. I started by compiling the unique IDs for the new records, then queried existing records with the same ids, and then created a map of the Unique Id to existing record. Pretty straightforward simple stuff, right.

Well, for some reason my code didn’t work for one record. Since it was one record I knew it had to be data related, but a quick glance at the new record and the existing one didn’t yield any differences. A more thorough glance though revealed one letter that was lowercase where it should’ve been uppercase. It didn’t seem like that could be the problem, after all, text == TEXT results in TRUE. Well, it turns out that map.containsKey() is case sensitive and there’s no attribute that can be set to change this.

The solution is pretty simple, before putting a key into the map you use either string.touppercase() or string.tolowercase() to standardize the keys. Then when you use map.containsKey(), you use the same method to standardize the string you’re looking for.
After figuring this out myself, I found a post about it over at The Silver Lining. Sure wish it were in the developer docs!

Hopefully, you already know that s-Controls are being phased out at the end of 2009. Most of us haven’t worked with s-Controls, since Apex was released. With Apex and VisualForce, there’s very little that can’t be done in salesforce.com that we used to do with s-Controls.

The few things that are hard to do can usually be accomplished by using a custom button/link to run some javascript and then some javascript first then pass it off to Apex/VisualForce. A good example of this is a custom button on a related list. With s-Controls we could pass which records had the checkbox checked in the related list. When VisualForce came out, we lost this ability and forced the user to navigate to an additional page with the same list and check the boxes there.

There is a javascript workaround though, it involves having the custom button on the related list run some code that looks like this:

{!REQUIRESCRIPT("/soap/ajax/17.0/connection.js")}
{!REQUIRESCRIPT("/soap/ajax/17.0/apex.js")}
var records = {!GETRECORDIDS($ObjectType.Lead)};
if ( records.length > 0 )
{
var success = sforce.apex.execute("ApexClassName" , "ApexMethodName",
{
listIds:records
}
);
window.location.href=window.location.href;
}
else
{
alert('Please select one or more records');
}

Have you migrated your s-Controls yet? (Don’t worry, your existing ones aren’t going anywhere yet, you just wont be able to create new ones).

Taggart Matthiesen delivered an amazing tech talk last week on Batch Apex and Custom Settings functionality. Not only did he demonstrate some basic Batch Apex functionality but also gave some promising insight into the future of Apex (safeharbor applies of course).

Some of the big news items included:

• Increasing the max size of collections to whatever the heap will support
• Being able to schedule Batch Apex (currently in pilot)
• Being able to do a mixed DML operation with custom settings

Great job Taggart, thanks for the extremely informative and educational session.

The webinar was recorded, so you can check it out here if you missed it:
http://wiki.developerforce.com/index.php/Tech_Talk:_Whats_New_in_Apex_Code

Let us know in the comments what you plan on using Batch Apex for!

For those of you who don’t know, salesforce.com limits the number API requests you can make in a given 24 hour period. An API request occurs when you connect to the salesforce.com API and call a method. Everyone is guaranteed a minimum limit of 5,000 calls per 24 hour period. The maximum limit varies depending on the number of licenses you have but is capped at 1,000,000 (5,000,000 for UE and sandbox orgs).

So what does this all mean? Well, if you’re building an integration that is going to connect to salesforce.com’s API, you have to make sure to build it so that it wont exceed this limit. For example, let’s say you only have 1 license, so your limit is 5,000 calls per 24 hour period and you’re going to send purchases made on your website one at a time into salesforce. You have to ensure that you don’t send over 5,000 purchases in a 24 hour period, because if you do, anything over 5,000 wont be received by salesforce.com.

There are various workarounds. You could use Apex to callout to your website instead. You could pass data in batches on a regular schedule. You could also use Force.com sites to create public webservices which have higher limits.

What limits in salesforce have you hit? How have you overcome them?

We just got this email from LinkedIn:

You requested access to the LinkedIn APIs and we wanted you to be the first to know that our APIs are now available.

With the LinkedIn platform, your users can bring their professional identities and networks with them to your site. You’ll be able to provide more engaging experiences and extend your site’s reach.

Visit the LinkedIn Developer Network to learn more about how you can get access to rich professional information and core LinkedIn features.

The race is on for all developers to integrate with LinkedIn!

Our friends at nonprofitcrm.org have put together a great demo of batch Apex. Check it out here.

Since batch Apex is only available in pilot, you may not be that familiar with it. It’s an asynchronous form of Apex that can run over the normal Apex governor limits. It’s very useful for nightly jobs that have to run on all your records and other complex processes.

Warning!!! This post is for the Uber-Apex Programmer and should not be attempted by novices. It may cause headaches, hair-loss, eye-strain and more, but it’s well worth it!

On two different occasions in the last week a client has needed email addresses in salesforce.com validated. The only true form of validation for an email address is to send an email and see if it bounces. This post doesn’t cover that. Instead, we’re focusing on the formatting of the email address.

According to a salesforce.com solution (login required), as of the Winter ‘08 release, salesforce.com validates email addresses as follows:
1. For the local part of the email address we accept the following characters. (The local part is anything before the @ sign.)
abcdefg.hijklmnopqrstuvwxyz!#$%&’*/=?^_+-`{|}~0123456789
Note: The character dot “.” is supported; provided that it is not the first or last character in the local-part
2. For the domain part of the email address we accept. The domain part is anything after the @ in an email address:
0-9 and A-Z and a-z and dash “-“
3. Example email address:
abcdefg.hijklmnopqrstuvwxyz!#$%&’*/=?^_+-`{|}~0123456789@acme-inc.com

Our goal was to perform the same validation via Apex prior to saving the record. This can be done using a lot of String methods and If statements, but really this type of comparison is best done with a Regular Expession.

Apex already has built-in Pattern and Matcher Classes for this purpose, so all we had to do was come up with the right regular expression. Thanks to some tips at www.regular-expressions.info it was actually an easy task to complete. It was so easy, that we’re releasing this code into the wild for all of our customers (and competitors) to use.

String pat = '[a-zA-Z0-9\\.\\!\\#\\$\\%\\&\\*\\/\\=\\?\\^\\_\\+\\-\\`\\{\\|\\}\\~\'._%+-]+@[a-zA-Z0-9\\-.-]+\\.[a-zA-Z]+';
Boolean test = Pattern.matches(pat, email);