Posts Tagged ‘SalesForce’
Logging into Salesforce through the Web Interface
You Shall Not Pass!
There are a number of ways to authenticate with the Force.com Platform and I thought I’d create a few lightning posts documenting my findings for each.
The first method in this series will be logging in through the web interface. There are 2 sites that you would hit in order to authenticate:
- http://login.salesforce.com – for Developer Edition and Production Orgs
- http://test.salesforce.com – for all other sandboxes
If you’re not able to log in with a username and password that you know is correct then the first port of call is to check that you’re using the correct URL above. I’ve seen many developers forget to hit ‘enter’ after swapping “test” for “login” (or vice versa) and then being puzzled because their credentials still didn’t work so don’t forget (okay by “many developers” I actually mean me).
There’s also a neat trick that’s quite well-known and can be used to log you in automatically based on bookmarked URLs. All you need to do is append 2 URL parameters onto the appropriate environment HTTPS URL e.g. I could create a bookmark with the URL https://test.salesforce.com?un=wes@cloud-corporation.com&pw=abc123 where:
- un = your username for that environment
- pw = your password for that username
Pro-tip: Make sure that the URL is using HTTPS.
If you exclusively use Chrome you might want to use the Force.com Logins plug-in which will save you some hassle.
Salesforce: A better way to work with jQuery selectors and Visualforce Component Ids
Irregular Expressions
I get very sad when discussing this particular topic. There are a variety of ways of get Visualforce component Ids and using them in JavaScript but all of them keep me awake at night. Srsly. A commenter on one of my posts got me thinking about how we can do this better and I’ve come up with a way that I think is great. Hopefully you’ll agree.
This post means that my older posts here and here are now retired in favour of this method.
If the world was on the brink of nuclear war with no clear path to peace what could you count on to save the day? Regular Expressions of course. If a meteor the size of Pluto was about to crash into Earth and Bruce Willis was too old to land on it and blow it up what could we count on to rid us of the troublesome rock. Yes that’s right, Regular Expressions. I think you can guess where I’m going with this.
jQuery has the ability to understand very simple regular expressions in it’s attribute selectors. The full documentation can be found here.
To solve our particular problem however the code is simple:
<apex:page>
<head>
<style>
a,span{
display:block;
}
</style>
<script src="https://ajax.googleapis.com/ajax/libs/jquery/1.4.2/jquery.min.js"></script>
<script>
jQuery(document).ready(function($){
$('#btn').click(function(e){
e.preventDefault();
console.log('The following element was found when looking for an id of \'output1\':');
console.log($('[id$=output1]')); /* Here's where we're grabbing the element. */
});
});
</script>
</head>
<apex:outputText value="She sells seashells by the seashore." id="output1"/>
<apex:outputText value="Peter Piper picked a pack of pickled peppers." id="output2"/>
<a href="" id="btn">Click me.</a>
</apex:page>
The important part here is the selector $(‘[id$=output1]’) which says, “Find the id value that ends with ‘output1′”. This comes with a warning though! Do not duplicate the Visualforce Id that you give to your elements otherwise this piece of code will find all of them.
When I first wrote this post I used a selector extension library that gives you the full power of JavaScript-based regular expression but Ryan Fritts has rightly shown that the above will deal with 99% of use cases and is simpler. For those of you that need to deal with the extra 1% I’ve implemented a wrapper to regex selector as an example. It does exactly what jQuery is doing above and gives you access to the regex flags as documented here.
Thanks again Ryan!
How many Salesforce Roles do you have in your Org?
I’ve worked with many Org instances in my career with salesforce.com and the Force.com Platform and was stunned by an Org that had a massive number of Roles, way beyond anything I’d ever seen before. This made me curious as to what other people were dealing with and I’m sure the result will be interesting.
Note: If you work with several Orgs and you have a high tolerance for boredom please submit an answer for each 🙂
Salesforce: Debugging JavaScript
Alert(). Old skool and not in a good way
I love JavaScript, and working within the Force.com Platform I’m always finding new ways that it can be applied to business needs. I know this is the case for many developers out there but I’ve seen that their typical development process is:
- Develop the JS code
- Create bug
- Include calls to the alert() method to troubleshoot
- Iterate
alert() is bad for debugging
I’m sure this process sounds familiar to many of you, but do you know what, the alert() method is a very weak way of troubleshooting. I abandoned it years back because of poor features such as outputting object representations as ‘[object]’ or ‘[undefined]’ – which doesn’t give you a lot to go on.
Meet console.log()
Modern browsers have access to a library called ‘console‘ which offers a far richer experience, and without the annoying pop-ups. The console.log() method accepts any JavaScript type as a parameter and will always give you detailed and sensible output. In the images below I’ve passed the method a variable representing a Div and the log outputs the entire DOM from the Div down. You can even pass it jQuery objects and it’ll output all of that object’s associated data!
Console. Unobtrusive with richer output.
Now that's what I call a debugger!
So where does it output to? On the console tab of course. I almost always use Chrome these days and you’ll find the console tab if you open Chrome’s Developer Tools. It’s similarly placed within Firebug for Firefox.
For those who’d like to learn more about the console library here’s an excellent article. There you’ll see that the library has far more to offer than just the log() method.
Debugging Custom JavaScript Button
A neat tip to remember is that console.log() is available wherever JavaScript is used on the platform. That means you can even debug the JavaScript you use to access the AJAX API through Custom Buttons!
Salesforce & LinkedIn Developer API: 401 – Unauthorized
Image via CrunchBase
I’m not going to get into the boilerplate code you’ll need in order to get OAuth up and running as it’s pretty straight forward, but I did run into a peculiar issue which took me some time to narrow down. To reproduce these steps you’ll need to:
- Correctly setup OAuth between the Force.com Platform and LinkedIn
- Authorise access to your LinkedIn account
- Attempt to fetch a resource using an API endpoint such as:Â http://api.linkedin.com/v1/people/~/network/updates?scope=self
When attempting to make the call out in step 3 you’ll get a “401 – Unauthorized” error. So to be clear OAuth is working perfectly but a call like this one will still result in the error.
After some troubleshooting I noticed that some API endpoints didn’t result in the error e.g. http://api.linkedin.com/v1/people/id=abcdefg/network/updates?scope=self. At this point I realised the issue was probably the tilde (‘~’) character in the URI.
Grasping at straws I manually replaced the tilde with it’s URL friendly equivalent ‘%7E’ and the callout worked perfectly. Now this is strange because I am, in the course of making the callout, URL encoding all parts of the endpoint URL. It seems that for some reason the LinkedIn OAuth services needs to have the tilde encoded twice when signing the request 
Salesforce: Programmatically Populating Sample Data Post-Deployment
I’m not sure if this concept is obvious when reading my previous post, so I thought I’d run through it with a specific example.
Rule one of packaging - Finish your bolognese first!
Let’s say that you’ve created what can only be described as an exemplary application in the form of a Managed Package. Although your user interface is beyond compare, you’d also like to populate some of your core objects with example data. Some options that immediately spring to mind are:
- Get the person that installs the package to call you, and you can do it post-installation.
- Get the person that installs the package to create sample data manually post-installation.
- Give the user a “Start Here” page with a call-to-action – such as a commandButton – that fetches the data from some API and parses into object data.
Option 3 is pretty excellent, especially now that you can package Remote Site Settings but I think we can do one better. And when I say better I mean simpler and with fewer potential points of failure. Read the rest of this entry »
Salesforce: Instantiating an SObject Dynamically at Run-time
I’m sure a lot of you have this documented somewhere but I’ve recently discovered that it’s quite difficult to find an obvious reference to this knowledge on the interwobbles. So how would you create a Generic SObject at run-time? It’s rather easy thankfully:
String sObjectName = 'MyObject__c'; Schema.SObjectType t = Schema.getGlobalDescribe().get(sObjectName); SObject s = t.newSObject();
If you require this type of functionality quite often I’d suggest putting it in a utility class.
Salesforce: Enhanced Custom Settings
Okay book’s done, now where were we? Oh yes software development, right? Programming software engineering application development h4x0R-ing. Oh how I’ve missed getting my mitts dirty so without further ado…
Now this one goes right about... here!
Some time back Custom Settings were introduced on the Force.com Platform and we all star-jumped in the air, w00ting to anyone who would listen. Up till this point – if you’re anything like me – you were using custom objects to hold configuration data, whether this be lists of language-codes, or operational settings such at outbound web service endpoints, usernames, passwords etc. With Custom Settings you finally had a place to put this information – a home if you will – for your lonely, orphaned Control Data.
Quite quickly however I realised there was still a gaping hole that could be filled with Custom Settings but just didn’t feel right. Lists of data (such as currency codes and descriptions) fit really well into this structure but more serious Control Data that you only need to be listed once-off (such as important URLs, flags to active/deactive modules in your application, usernames and passwords) just don’t seem like they really belong with this other crowd. A quick list of reasons highlights this:
- Control Data is typically entered once off and creating an entire Custom Setting for a single line of data feels like a waste.
- Custom Settings are data so they can’t be deployed with code, they must be created after the fact. Control Data should be a little more important than regular data, it needs a smarter vehicle than plain-old data entry.
- If you’re creating packages you want as much autonomy for your clients as possible. If you use custom settings there will have to be that “Create data in Custom Setting X__c” step in each and every deployment. Read the rest of this entry »
Salesforce: System.Assert vs System.AssertEquals
For a time I’d wondered what the difference between the System.Assert and System.AssertEquals methods might be (System.AssertNotEquals to a lesser degree). To be honest this tip isn’t going to help much with World Peace or Curing Internetlessness, but it’s certainly gonna save you some time.
Looking at the documentation there are some obvious differences.
- System.Assert accepts two parameters, one (mandatory) which is the condition to test for and the other a message (optional)Â to display should that condition be false.
- System.AssertEquals and System.AssertNotEquals both accepts three parameters; the first two (mandatory) are the variables that will be tested for in/equality and the third (optional) is the message to display if the assert results in false.
Pretty standard stuff, and can all be learnt simply by Reading The Manual.
Now testing best practices state that you should assert some condition but also output a “console” message that shows the values of each of the operands. This certainly helps you debug unit tests when asserts are failing, but man I hate typing extra code just to check out some variable values! So the time saving trick that isn’t obvious is that when omitting the optional third parameter for System.AssertEquals and System.AssertNotEquals the compiler automagically outputs the values of the operands to the console log. That’s right, instead of typing:
System.assert(var1 == var2, "The value of var1 is: " +var1 + " and the value of... oh hell I don't care I mean it's just a variable");
You could type:
System.assertEquals(var1, var2);
If the second assertion fails the console will output the values of var1 and var2 with the labels “expected” and “actual”. Knowing this now I can see no exceptional reason to use System.assert any longer (sorry little guy).
As I said this trick’s not gonna start any Mexican Waves but it should help delay the onset of RSI.
(thanks to l-dawg for opening my eyes)
Announcing the Salesforce Handbook
Recently, Jeff Douglas and I saw the potential for a beginner’s book – aimed at business owners, analysts and developers, that comprehensively documents Salesforce and Force.com. There is a tonne of documentation out there and we thought “Wouldn’t it be nice to have a handbook that lightly summarised the most important areas of the platforms as well as offering some best practise advice”. We mulled it over for a time, and today we’d like to announce that we’re currently writing:
The Salesforce Handbook
A newcomer’s guide to building applications on Salesforce.com and the Force.com Platform.
Hand-in-hand with the book we’ll be publishing content from the book on a WordPress site. Here you can expect to find excerpts from the book, but also content that supplements the book e.g. areas that’ll serve as best-practice hubs with links to official documentation, blog posts that rock the party, and even superb discussion forum threads.
We’d love to get your feedback on the book as it progresses, but for now you can checkout the announcement and let us know what you think of the idea.
The Silver Lining 