Archive for the ‘How To’ Category

Force.com IDE productivity boost – “Go to Resource”

My coworker Phil recently showed me a neat little shortcut in the Force.com IDE/Eclipse to quickly go to any file in the workspace with the “Go to Resource” dialog. To enable this shortcut, go to the Force.com IDE menu > Preferences > General > Keys and search for “Go to”. The first result should be “Go to” (this references the “Go to Resource” dialog), which you can assign to a key combo like “⌘G” (this conflicts with the “Go to Address” key combo, so you’ll just need to assign that to a different combo).

The “Go to Resource” dialog does a type-ahead search on all of the files in your workspace, and all you have to do is start typing the name of the file/resource that you’re looking for and hit enter when the right file is highlighted – much faster than hunting through your project folder tree for that class or trigger you need to edit!

Advertisements

Force.com Migration Tool (Ant) out of memory solution

(This is a pretty un-glamorous resuscitation of my blog, but it was fresh on my mind and needed to be shared, so here goes…)

If you try to do a large Salesforce.com metadata deployment using the Force.com Migration Tool (a.k.a Salesforce.com’s Apache Ant extension), then you’ll probably encounter this error:

BUILD FAILED
java.lang.OutOfMemoryError: Java heap space

Thankfully I was able to find the solution to this issue on the DeveloperForce discussion boards with some targeted Googling, but I’m hoping that this post will save others from having to encounter the error in the first place and then hack around for a while figuring out how to implement the fix.

The solution to this problem is pretty basic – all you need to do is to add the parameter “-Xmx1024m” to the “$ANT_OPTS” environment variable in your Ant shell script or batch file. (This parameter raises the maximum memory limit for your Java virtual machine to 1GB, instead of 128MB or whatever paltry amount the default is.) If you’re using the default installation of Ant on Mac OS X, you can find the Ant shell script in the “/usr/share/ant/bin” folder. Open “ant” with any text editor (my favorite is the free app TextWrangler) and go to line 322 of the file. Insert “-Xmx1024m” in between “$ANT_OPTS” and “-classpath”, save the file (you’ll probably need to provide your Mac OS X user account password since it is technically a system file), and you should be all set.

My condolences to the Windows users, as I don’t really use Windows any more, so you’ll have to figure out where that parameter goes. (If someone can post comprehensive instructions for Windows users as a comment, that would be greatly appreciated! I’ll be happy to update this post with the instructions.)

I’m planning to post some more extensive tips and guides on Force.com development and deployment tools (hopefully) in the near future, so please stay tuned!

Why can’t I see certain objects in the Apex Explorer?

I’ve had a number of people ask me “Why can’t I see such-and-such an object in the Apex Explorer when I have full rights to view it?” (usually referring to custom many-many/junction objects), and I thought it would be good to get a blog post out there to explain the cause of this phenomenon and how to correct it.

To start with, I should explain what the Apex Explorer is, because many people are not even aware of its existence. The Apex Explorer is a pretty simple .NET desktop application that functions as a sort of SOQL “Query Analyzer” and a Salesforce.com data model browser. You can learn more about it and download a copy from the Force.com developer wiki.

Only one version of the Apex Explorer was ever developed and released, and that is version 8.0. The reason that they gave it that version number was that it’s release coincided with the release of version 8.0 of the Salesforce.com API. The Apex Explorer was somewhat useful and unique at the time, but I’ve found it to be somewhat buggy when you try to use it for anything more than the most basic queries. [The Salesforce Schema Browser in the Ecplise plugin/Force.com IDE is much more robust as it is actively being developed for each new version of the API, so it is highly recommended that you use it for testing SOQL queries and digging into your Salesforce.com schema structure/data model] For some reason lots of people still use the Apex Explorer (and Salesforce still links to it in Setup > Develop > Tools), probably because it is the only light-weight Windows alternative to the incredibly awesome SOQL Xplorer for Mac OS X. (Now why Salesforce won’t link to the actively developed (and very feature rich) SOQL Xplorer from Setup > Develop > Tools or from the Force.com developer wiki is quite a head scratcher, but I digress…)

Salesforce versions the releases of their API so that integrations built on a certain version of the API won’t break when things are added or changed in the API for new releases.  For instance, “Many to Many Object Relationships” were added in the Summer ’08 release (version 13.0 of the API). If you log in with any previous version of the API, you won’t see any Many to Many objects in your schema.

Since the Apex Explorer was created when version 8.0 of the Salesforce API was the current and latest version, it defaults to logging into Salesforce.com with the URL for that version of the API. In order to see new objects in your Salesforce schema that are or have features that weren’t available with version 8.0 of the API, you’ll need to change the login URL that the Apex Explorer uses. Thankfully this is pretty easy to do – open Apex Explorer and go to the Tools menu and select “Options”:

Apex Explorer Tools-Options Menu

In the Options dialog, all you have to do is change the “8.0” to “15.0” on the URL in the “Endpoint” field:

Apex Explorer Options - API v15

And now you will be able to see your “many to many” objects, new standard objects that Salesforce has exposed through the API since version 8.0, and probably anything else in your schema that wasn’t available with version 8.0.

CAUTION: Using a newer version of the API than this application was originally developed for MAY cause certain parts of its functionality to malfunction. I have NOT tested this application thoroughly with any newer versions of the API, so please proceed with caution, and don’t be surprised if something doesn’t work or worse, the data in your Salesforce org gets corrupted somehow. I would highly recommend that you switch to using the Force.com IDE as your schema browser as it is the only officially supported tool for this purpose.

Return the Account Merge wizard to beginning upon completion

A while ago there was an Idea on the IdeaExchange asking if the Account Merge wizard could be returned to the beginning. I responded with a simple workaround, but the comment function of the IdeaExchange wasn’t really suited for providing the solution, so I decided to blog the solution here to make it a little easier to read and find, and also provide a new way to implement the solution.

Basically, the solution is just a simple modification to the URL used to access the Account Merge wizard. Most URLs in Salesforce.com accept a “retURL” querystring parameter that tells the page where to return the user once the operation on the current page (or series of pages) is complete. So, the URL that I came up with for this solution is:

/merge/accmergewizard.jsp?retURL=%2Fmerge%2Faccmergewizard.jsp

The URL lacks any “http://…” because it needs to be relative to your particular Salesforce.com datacenter pod (NA1, NA2, Na3, etc.). Now, the only thing that you really need to do is to take this URL and make a custom link somewhere in your Salesforce org, perhaps on the sidebar or on a page layout, and you’ll have a way to launch the Account Merge wizard set to return to the beginning upon completion. 

However, you’ll probably want to make this solution a little bit more robust and create a custom tab to launch the modified Account Merge wizard. You can create Custom Web Tabs that reference a URL, but if you do this with the URL above you’ll get a second copy of the Salesforce header (tabs, application menu, etc.) under the custom tab. That isn’t very good use of screen real estate (and it is rather confusing to users), so we need to use a little bit of JavaScript magic to redirect the entire browser window to the URL that we’ve created. We can do this by creating an HTML S-control that contains the following code:


<script language="JavaScript">

function redirect()

    {

        parent.parent.frames.location.replace('/merge/accmergewizard.jsp?retURL=%2Fmerge%2Faccmergewizard.jsp');

    }

redirect();

</script>  

Next, create your Custom Web Tab (Setup > Create > Tabs), and choose the “Custom S-Control” Tab Type, and associate it with the Custom S-Control that you created containing the code above. Make the tab visible to the appropriate profiles, and now you have an easily accessible Account Merge Wizard that will cycle back to the beginning upon completion.

For those who want to implement a more future-proof solution (Salesforce is in the process of phasing out S-Controls over the next few years), you can easily implement a VisualForce page that accomplishes the same thing using the following code:


<apex:page >

<script language="JavaScript">

function redirect()

    {

        parent.parent.frames.location.replace('/merge/accmergewizard.jsp?retURL=%2Fmerge%2Faccmergewizard.jsp');

    }

redirect();

</script>

</apex:page>

Then create a VisualForce Tab that references the page you created, and it will work just like the S-control solution above.

This is just one example of how you can use the parameters of the Salesforce URLs (and a little bit of JavaScript magic) to make some helpful modifications to the basic Salesforce functionality. Perhaps in later posts I’ll demonstrate some of the other neat little tricks that you can do with Salesforce URLs, custom links & buttons, and other simple tools.

(My JavaScript in the code above may not be bulletproof, so if you have any issues with the code please let me know and I’ll see if I can find a workaround.)