You are currently browsing the category archive for the ‘Salesforce’ category.
I try to work on things I am excited about as much as possible because I work “harder, better, faster, stronger.”
Here are a few things I’m excited about at the moment:
(1) Meteor. Recent explosive entry into the Javascript libraries/frameworks, which provides a “railsesque” framework for developing with a Node.js backend and presumably MongoDB datastore. Fills a huge need and appears to do just about everything just right, both in terms of design decisions and community engagement. I predict total domination.
(2) 12 Factor App. Not commented on heavily with the Salesforce community though a product not only of top-notch Heroku smarts but also with commentary from top Salesforce eggheads (e.g. Mountjoy), I think this is the sort of document we will be reviewing in five years as “prophetic.” In many ways, the future is already here, but it will take most of us a long time to realize it.
(3) jQuery. I know that there is nothing new here, but as a diehard jQuery enthusiast, I still think its time of triumph “in the enterprise” is coming soon as people finally get the message (and also realize that UI of their product is important).
(4) Berlin. Not quite Silicon Valley but people are picking up the torch and I expect to see more significant European-based challengers instead of just imitators over the next few years. Don’t doubt the Curry Wurst.
(5) Polyglot solutions. Even though it has often failed to invest substantially in its own open source ecosystem, Salesforce has taken something of a lead in acquiring in the fascinating although occasionally murky world of “polyglot” solutions, where various languages are used to provide what presumably is the “right tool for the job.” Despite the occasionally murkiness and gangs of cheerleaders without any real understanding of the strengths and weaknesses of various technology sets, I’m excited to see more definition about what constitutes the “right tool for the job” and robust composite solutions — of course, expect to see this more on the “bottom up” Heroku side than the typically top-down Salesforce side.
(6) Fractals. Okay, probably you know this already, but I think other people are finally starting to get the message about just how “fractal-eque” many parts of the world are.
jQuery UI for Salesforce provides a complete set of jQuery powered elements that can be used instead of the standard elements. This includes automatic client-side validation.
A page showing the jQuery elements compared with standard elements can be found here.
Usage
Complete specifications follow for each enhanced component:
Text:
<c:enhancedText pageController="{!this}" fieldName="Text__c" />
You can also force there to be both a uppercase and lowercase letters by telling to to validate as a name:
<c:enhancedText pageController="{!this}" fieldName="Text__c" validateAs="name" />
Email:
<c:enhancedText pageController="{!this}" fieldName="Email__c" validateAs="email" />
Number (Double):
<c:enhancedText pageController="{!this}" fieldName="Number__c" validateAs="number" />
Percent:
<c:enhancedText pageController="{!this}" fieldName="Percent__c" validateAs="percent" />
Checkbox (Boolean):
<c:enhancedCheckbox pageController="{!this}" fieldName="Checkbox__c" />
Phone:
<c:enhancedText pageController="{!this}" fieldName="Phone__c" validateAs="phone" />
Defaults to international phone, for US domestic phone use:
<c:enhancedText pageController="{!this}" fieldName="Phone__c" validateAs="phoneus" />
Picklist:
<c:enhancedSelect fieldName="Picklist__c" pageController="{!this}" object="{!TestObject__c}" /
Multi-Picklist (Multiselect)
<c:enhancedMultiselect pageController="{!this}" fieldName="Picklist_Multi_Select__c" object="{!TestObject__c}" /
Lookup (Reference) :
<c:enhancedLookup pageController="{!this}" fieldName="Test_Lookup_Object__c" objectToLookup="TestLookupObject__c" />
Lookup (Reference) :
<c:enhancedLookup pageController="{!this}" fieldName="Test_Lookup_Object__c" objectToLookup="TestLookupObject__c" />
Textarea :
<c:enhancedTextarea pageController="{!this}" fieldName="Text_Area__c" expandable="true" width="145" height="50" />
Controller:
(1) Install enhanced components via unmanaged package install link.
(2) Have your main controller (which can be a standard controller) extend PageControllerBase:
public with sharing class DemoPageController extends PageControllerBase
If you want to use a standard controller include this:
public DemoPageController(ApexPages.StandardController controller) {
standardCon = controller;
this.myObject = controller.getRecord();
}
Then include this function:
// First we save the values from the Enhanced Component controllers, then whatever standard fields there are.
// If you are using standard fields in addition to enhanced components, whichever method is utilizing fields required by the API should always be in the first position
public PageReference save()
{
ecSave();
standardCon.save();
return null;
}
Page:
Include your favorite jQuery UI theme easily:
<apex:stylesheet value="{!URLFOR($Resource.JQueryUICup,'development-bundle/themes/cupertino/jquery.ui.all.css')}"/>
See how standard themes will look by choosing the switch theme option on this page. You can also easily create your own theme with Themeroller.
On your page you will also need to enable validation.
The easiest way is to assign a form styleClass element to your form declaration:
<apex:form styleClass="form" >
Then just before you close your form tag add an action function:
<apex:actionFunction action="{!pageController.save}" name="saveMe"></apex:actionFunction>
</apex:form>
Then add the automatically generated javascript:
<apex:outputText escape="false" value="{!pageController.completeJavascript}"/>
This line will not only add hotlinks to the Google and Microsoft CDNs (for JQuery, JQueryUI and JQuery validation plugin), it will enable validation any form with a form class and add all of the necessary methods for validation.
If you don’t want to use the automagic client-side validation, hotlink the necessary CDNs manually:
<script type="text/javascript" src="http://ajax.googleapis.com/ajax/libs/jquery/1.4.2/jquery.min.js"/>
<script type="text/javascript" src="http://ajax.googleapis.com/ajax/libs/jqueryui/1.8.1/jquery-ui.min.js"/>
Here is a list of all of the Plugins currently included:
JQuery UI 1.8
JQuery Validation (Joern Zaefferer)
Autocomplete 1.1.1 (Joern Zaefferer)
Expandable 1.0 (Brandon Aaron)
Select Menu (Filament Group)
Multiselect 0.6 (Eric Hynds)
Dreamforce is crazy. So many sessions, so many people to see, so little time. Moreover, there were a bunch of sessions related to Ruby, and it wasn’t always easy to know what sort of content would be covered ahead of time (esp. since some of them were added at the last minute).
I will summarize here all of the sessions covering Heroku and Ruby along with what you should know about the status of Ruby right now in the enterprise world, then present a summary and evaluation of Dreamforce presentations as a whole. It’s worth mentioning that all of these are among the most popular sessions, both from impressions at Dreamforce and Youtube views afterwards.
From high-level to very technical:
Platform State of the Union
The Platform State of the Union is the one *must* attend event for all developers. Highlights were the vision for the future of the platform by Byron Sebastian (former CEO Heroku, now Senior Vice President of Platform Technology), from 2:01-6:30, an appearance by the creator of Ruby and now, employee at Heroku, Matz, 6:40 – 8:40, as well as an extensive example from Barry Newman of Saveology of utilization of Heroku and Force.com platforms 35:48 – 45:00, followed and preceded by comments by Dave Carroll, Director of Dev Evangelism for Salesforce.
Heroku in the Enterprise
Oren Teich, COO @ Heroku
Very visually compelling and enthusiastic presentation by Oren Teich that gives a good introduction to the Heroku platform. Appropriately emphasized the core strengths of Heroku,”You as a developer have complete control over what is going on in your app.” Didn’t quite connect the dots as far as what would be compelling use cases for existing Salesforce customers. Nonetheless, my favorite presentation at Dreamforce.
Connecting Ruby Apps with Force.com
Alex Sutherland (Mavens) and Joel Dietz (me!)
Originally slated to be a more technical presentation, ended up being a high-level presentation of the use cases for hybrid apps that leverage the strengths of using the right tool for the right job. Also gives the history of Ruby integrations from the folks with the most experience (mainly Alex). Presented some compelling use cases for Ruby/Heroku utilization (although Joel Dietz said “umm” too many times, esp. at the beginning).
Building and Deploying Great Applications with Salesforce, Ruby, and Heroku
Danny Burkes, Pivotal Labs
Presentation by lead developer on how to use the new Database.com gem released by Salesforce at Dreamforce (see my earlier post for some background on this).
Using Ruby on Heroku
Alex Wong, Salesforce.com
Starter presentation on how to get a Ruby on Rails app running on Heroku. Another presentation with similar content was given by Morten Bagai (but doesn’t seem to have made its way to youtube).
Connect your Clouds with Force.com
Jeff Douglas, Appirio
Attempting to do a bit of everything and generally succeeding is Jeff Douglas. See his high-level description at 3:55 and demo of a mobile device focusing on Heroku at 36:14.
In general, all of the bases were covered somewhere at Dreamforce. There were introductory sessions for Ruby the language, introductory sessions for how to employ Heroku, high-level introductory sessions to the platform, and a couple sessions that showed compelling use cases and showed the when and what is the right tool for the job. In general, the Heroku sessions set a new standard for compelling presentations, and I’m confident that things will continue to progress in this direction — despite the fact that some of us (::cough cough::), continue to be forced to use the standard Salesforce powerpoint template.

Another thing, and I am confident that this will be resolved in the next six months or so, is the lack of an unified and compelling vision for what is the right tool when. The increased investment in all parts of the platform is fantastic, but there is still a bit more to be done as far as connecting the dots with existing enterprise clients of Salesforce and Heroku.
What follows are instructions on how to get started with the databasedotcom gem, released yesterday afternoon at Dreamforce.
The examples here will be assuming you use Heroku for hosting and deployment although you can use all of the features mentioned without Heroku if you so chose.
This is also for the most part a tutorial and not a replacement for the existing documentation includes as part of the databasedotcom gem on Github and shared via Ruby docs, which hopefully will be expanded as the gem gets some love.
There are two main components of the current release:
(1) A wrapper for the Force.com REST API which currently works with both Force.com and Database.com
(2) A wrapper for the Chatter API which will not be useful until Winter ’12 (or in orgs w/ api v. 23 already enabled)
There is also an additional controller released separately on Github which provides a class that your controllers (assuming you are using a Rails app) can extend. By doing so they will instantly get access to the Force.com or Database.com backend you are hooking into.
As of right now, the gem only supports Ruby 1.9.x, although support for earlier versions of Ruby is promised within the very near future. Although the development of the gem was commissioned by Salesforce/Heroku, maintenance is less certain and depends largely on your contributions.
The first thing you need to do is include the gem in your app. Add the databasedotcom gem to your Gemfile.
gem 'databasedotcom'
If desired, use the edge version instead of the released gem version. This will allow you to get the latest version (you will probably want this if testing in the next couple of days, not necessarily later once the few warts have been ironed out).
gem 'databasedotcom', :git => "https://github.com/heroku/databasedotcom.git"
I’m assuming you’ve already initialized your app on Heroku. If not, go through the Heroku starter tutorial and create your heroku app.
I also recommend adding ssl to your Heroku app:
heroku addons:add ssl:piggyback
The first thing you need to do is add your credentials. You will need to add remote access for your heroku app in Salesforce (Setup -> Develop -> Remote Access).
Note your consumer key and secret. For the purposes of this gem, the client id is always your consumer key, and client secret is the same as consumer secret.
You can add this information to your app in one of three ways: (1) explicitly passing a hash. (2) Setting environment variables via Heroku (3) setting up a yml file in your config folder with the credentials. I recommend doing (3) unless you have a reason to use one of the other options.
The second thing you need to do to authenticate is do the OAuth handshake.
I recommend using the username and password combination for the user with the appropriate permissions for your org.
These can also be set in your yml file. I recommend also turning on debugging.
This will lead to a file called “databasedotcom.yml” in the config folder with the following info:
client_id: CONSUMER_KEY_FROM_REMOTE_ACCESS
client_secret: SECRET_FROM_REMOTE_ACCESS
username: SALESFORCE_USERNAME
password: PASSWORD_PLUS_SEC_TOKEN
debugging: true
Now make sure that is included and deploy the yml to Heroku.
To actually use the gem I recommend starting by extending the databasedotcom controller. Your code will look like this:
class SObjectNameController < DatabasedotcomController
You can then easily refer to the objects you need in that controller.
For instance in the index method you can do
@users = User.all
Where “User” is now your automagically instantiated SObject class queried via the REST API. The way this works is that if you use a variable (e.g. “User”) that is unknown to the class it will find all of the available SObjects and attempt to instantiate a new instance.
That should be enough to get you started. A bunch of other useful examples are in dburkes’ example code.
One note of caution, there is as of yet no session management for this app, so if your auth token times out you will need to re-authenticate yourself.
Krishnan Subramanian and Ben Kepes have just delivered a needed update on the state of cloud warfare, focusing especially on recent moves by Heroku (where I was earlier today). Krish of CloudAve breaks down the contenders into three main groups:
Traditional (Heroku) Server like a repository. You push. Everything just works.
Packaged (Amazon). Push, but exposed IaaS layer.
Federated (VMWare). Network of clouds, customization in side.
Krish expects federated servers to win out. Although he doesn’t pick any winners, he says Cloud Foundry/VMWare is the front runner at the moment. Folks like Heroku aren’t apparently not competitive for big enterprise apps.
Ben Kepes suggest the division is more like this:
Infrastructure PaaS (Heroku, Amazon). Caters to developers used to working with infrastructure. Customization where you need it.
Application PaaS (Force.com). Just get to the app! Fully managed infrastructure.
He also suggests that these are fairly separate arenas and are diverging.
First of all, I’m more on the Ben Kepes side of things. Basically, how you manage your PaaS offering (hopefully well!) is a distinct issue to how it appears to the world. Architectural decisions are not features. Choosing to expose certain aspects to your users or provide for certain technologies and not others is. However, diversification is frequently not a winning strategy if it ends up with feature bloat — too many features requiring maintenance without necessarily meeting the needs of paying users. What do the users want? I’d guess the main aspects are the following: ease of use, scalability, features, price. The fact that different market segments will weight different aspects differently is a good reason why despite a crowded market there will probably be a lot of contenders for quite some time.
Second, it is worth noting who is not mentioned. Microsoft is still here (albeit not a front runner), but Google and other Ruby cloud folks (Engine Yard) are not highlighted at all. Yikes!

Third, it is worth noting the challenge of the “enterprise,” which most likely still hasn’t moved much if any of its core services into the cloud. Yes, Salesforce is “enterprisy,” but apps are usually extensions of its core CRM functionality, not fully featured “standalone” apps. Who will service them? I think that is still to be determined, and I wouldn’t write off any of the main contenders just yet.
Heroku co-founder Adam Wiggins stated in a recent interview that Salesforce is “Really good with business and enterprise, but … not necessarily as knowledgeable about how to engage developers.” That started this fascinating exchange with Salesforce’s ISV Architect Evangelist Shoby Abdi:
So is there an “engagement equation” ? Why are developers interested, engaged, and passionate in certain things and not others?
Regardless of what Salesforce is doing or not doing, here are my suggestions for how to engage developers better:
Tools that are awesome
– If you want developers to be productive and happy, give them good tools
Tools that can be modified
– Good developers, like folks in other fields, like to tweak their tools. Also try not to lock people into tools that you’ve made.
Cutting-edge technology
– Awesomeness in technology usually means things that are pushing some technological edge. Integrations between existing technologies frequently do not meet this standard (hint: XML and SOAP are not cutting-edge any more).
Push your edge
– Not just with respect to technologies, but also more broadly with respect to how you work and who you work with — competitions and late night coding sessions are awesome! As Yehuda Katz says, “Find something impossible and do it.”
Props
– Don’t leave your developers in the basement contemplating how to siphon fractions of cents from your corporate bank account. Give them props for what they do. Open source is a lot about props. People can see what you did and what you can do (follow me on Github!).
Independence
– Brilliant people frequently want to work on a variety of stimulating things since they get smarter that way. Remember, more challenge (usually) equals better. There needs to be room for people hack here, hack there, hack around, whatever. Don’t put chains on your developer!
Insulate
– Specialization is awesome. Some folks work really well on some things but don’t want to deal with others. Don’t make your developers do things other than development or sit through the presentations of people who do. CIOs should get paid more to drink corporate kool-aid. Don’t make your developers!
$$$
Not the number one concern for awesome developers, admittedly, but a concern. Don’t throw pennies at people contributing in awesome ways. Find some way to make them part of a thriving ecosystem. They don’t want to starve (me neither, hire me!)
I’m not going to issue a Salesforce grade in each of these areas, but I think it is clear that Wiggins is correct in general. Salesforce has a way to go in engaging developers. Hopefully Heroku can be a turning point.
This week I :
(1) Wrote and deployed a Sinatra App to Heroku to test Jeff Douglas’s code. It works! Link.
(2) Leveraged the Cinch framework to write an IRC Bot for the #salesforce IRC channel on Freenode. Please say hello to “Saasy” in the #salesforce channel and see what it can do.
(3) Wrote and deployed a simple Rails app (v. 3) to Heroku which displays the log from the IRC Bot (link edited 2/28/11).
Here are some takeaways:
(1) Getting started with Ruby can be a bit tough. There are often versioning issues and incompatibilities which can take a long time to solve. I was switching back between different versions of Ruby, Rails, and various gems — often finding that documentation was out of date. You also need to spend a fair amount of time on the command line, which can be difficult for folks used to a super IDE.
(2) Writing with Ruby is fun. Of course, there is a learning curve with anything, but there is a lot of syntactical sugar that makes writing Ruby one of my favorite things to do (once I get the hang of it).
(3) Heroku is awesome. I’ve written a couple Rails apps before but deployment was kind of pain. No longer! Heroku is super fun and super easy.
(4) The Ruby community is great. Even if sorting through blogs to find up-to-date instructions is not the most fun activity, there is tons of information out there and also lots of helpful people on various IRC channels (#heroku #ruby #cinch #rubyonrails).
So why not get started? For resources I highly highly recommend Peepcode, as well as the “Pickaxe”. For a (if you are doing Rails stuff, also the Agile Guide). For a quirkier, quicker, and in many ways more delightful (if not as comprehensive) approach, check out Why’s Guide to Ruby and learn the meaning of chunky bacon.
Special thanks to Domink Honnef, who provided helpful advice and put up with my safe harbor statement testing on the #cinch-bots channel, as well as aliasweird, apothecary, and others who made helpful suggestions re: the irc bot in #salesforce.
Problem:
You use the 10000 record limit on your queries but they still could fail since you might return 5000 in one and 6000 in the next leading to greater than 10000 records returned. Or potentially more annoying… running into the different limits at play when you are in a test method.
Solution:
Use my rapidly growing Limit Utilities class:
public class LimitsUtility
{
static final Integer PERCENT_PER_QUERY = 65;
public Integer rowsAvailable()
{
Integer rowLimit = Math.round( ( Limits.getLimitQueryRows() - Limits.getQueryRows() ) * ( PERCENT_PER_QUERY / 100.00 ) );
if (rowLimit < 15)
rowLimit = 1;
return rowLimit;
}
}
This function simply takes the total limit and subtracts the available rows, then only queries a certain percentage of the available rows (in this case, 65%).
Use as follows:
List<SObject> sos = [select id from MySObject__c limit = :LimitsUtility.rowsAvailable() ];
I’ve also created a little spreadsheet to show how fast you will burn down the queries at various percentages (assuming you are hitting a full record set).
Note that things won’t be quite this bad if you use my method, since it will drop the limit to 1 if you go below 15 available rows, giving you a little bit of an extra lifeline before you hit the limit. This code is now also available on Snipplr.
With the sponsorship of the phenomenal company Hoopla Software, I’ve put together a number of enhancements to the SOQLBuilder as included in Apex-lang, a community project headed by developer hero Richard Vanhook. For those who don’t know, SOQL Builder allows you to simply and reliably create queries like this:
new al.SoqlBuilder()
.selectx('name')
.fromx('Opportunity')
.wherex(new al.FieldCondition('employees').lessThan(10))
.toSoql();
I’ve added support for aggregate queries:
Count:
new al.SoqlBuilder()
.selectCount('Id')
.fromx('Opportunity')
.toSoql();
Sum:
new al.SoqlBuilder()
.selectSumx('Amount')
.fromx('Opportunity')
.toSoql();
Average:
new al.SoqlBuilder()
.selectAveragex('Amount')
.fromx('Opportunity')
.toSoql();
Max:
new al.SoqlBuilder()
.selectMaxx('Amount')
.fromx('Opportunity')
.toSoql();
Min:
new al.SoqlBuilder()
.selectMinx('Amount')
.fromx('Opportunity')
.toSoql();
I’ve also added support for Group by:
new al.SoqlBuilder()
.selectx('OwnerId')
.fromx('Opportunity')
.groupBy('OwnerId')
.toSoql();
Get Apex-lang here.
Here’s a video showing the sort of things that are possible with this library:
Although this technique has been around forever I’ve never seen it documented anywhere so I thought I’d share for all those looking to power up their Salesforce skilz.
Problem: You’ve got a record, potentially a junction object, and you want to create a new object if both of the other objects you are referencing exist but and update if there is an existing record with references to both of the other objects.
Solution:
(1) Create an external id field called “Composite_Key__c”
Make sure you set it to be Unique, Required, and the External id:
(2) Populate it with a composite id (id of object 1 + id of object 2)
If you are doing this via Apex (as I always do since I’m a code monkey)
myObject.Composite_Key__c = '' + object1.id + object2.id;
You can also set this via a workflow rule.
(3) Upsert on the composite key
upsert myObject Composite_Key__c;
Now you will get a new record if it is not there, and update the existing record if there is one already with that key.
As an added bonus, here’s what Force.com guru Simon Fell has to say about how awesome this is:
Upsert + External ID, there’s so many uses for this its hard to know where to start. The External Id is a flag on custom fields, when you turn it on, we index that field (improved query performance for filtering on that field), in addition it now allows you to use the upsert call which uses that external Id as the key instead of the Salesforce Id. If you’re syncing additional data sources with Salesforce, it makes that process much easier to handle. On additional use is to an external Id field as an operation identifier, SOAP over HTTP is not 100% reliable, if you make a create call and the response never makes it back to the client, its hard to work out if the data got created or not, by adding an operation Id custom field, you can make all your creates calls via the upsert call, simply assign a unique id (say a GUID) to the create you’re trying to do and call upsert. If something goes wrong and the response is lost in transit, you can simply make the upsert call again, if the original insert never happened, then there won’t be a row for that GUID and we’ll do the insert, or if we did the original insert, the row will now be there, and we’ll just update it. This can drastically simplify handling failure conditions.
Additional Acknowledgement: This technique shamelessly swiped from the ever percolating mind of Alex “Idea Exchange” Sutherland.






