I
n previous chapters you’ve seen how salesforce.com removes a lot of the cost and complexity around software development infrastructure. Now imagine that as a developer you never need to worry about database connectivity, whether the web stack is up or whether there may be servers that need to be bounced before taking an improvement live. This would leave you with a lot more time to do the “real work”. Wouldn’t that be great?Salesforce.com’s Platform as a Service (PaaS), also known as Force.com, does exactly this and that’s only the tip of the iceberg. Force.com is comprised of a set of tools, APIs and programming languages that enable administrators, developers and architects to build anything from small-to large-scale enterprise applications quickly, and without compromising quality.
They have catered for IT personnel at all levels providing tools and support specific to those roles. Of course tools work better with processes to support them and salesforce.com together with a few community evangelists have grown a number of best practices that govern areas such as unit testing strategies; collaborative development; object-oriented principle implementations, and much more.
In this chapter you’ll learn more about the tools and strategies required to build, test and deploy applications on Force.com. Not only that but we’ll advise which tools are required when and provide usage best-practices where required.
A New but Familiar Development Infrastructure
Traditional software development tools and processes are mature and have been widely accepted. Salesforce.com has taken what might be considered the best of these approaches and tools, and built their platform on this sturdy foundation.
That’s Old School
In a simple traditional development topology, one or more engineers develop on desktop computers whilst sharing and integrating code through a Version Control System (VCS). Next, code is tested in a Quality Assurance (QA) environment, and then moves into a User Acceptance Testing (UAT) environment. If the software successfully passes each stage it is finally packaged and deployed to a production environment.
Developing in the Clouds
Force.com uses a similar setup but we find that instead of having our environments sit within the usual hardware infrastructure they are now cloud-bound. In figure 3 - 2 we see that developers still create code locally, but something to note is that code isn’t compiled locally. Instead it is deployed (in real-time by default) to developer environments, which compile the source-code and form our development runtime environments.
Developers can also create and edit applications directly in their browser thereby leap-frogging the local development step, but this is generally not advised for large applications and/or collaborative development.
Thankfully you still have the option of committing code to your favorite VCS and it is generally advised. A packaging step is not required with the Force.com platform as we can deploy directly into any developer and/or production environment.
In figure 3-3 we’ve noted an alternative setup with a build manager handling the deployments directly from the VCS repository. Using build managers can be a neat practice for a number of reasons including predictable deployment rhythms, code quality checks, automated testing and build/deployment history.
From what we’ve seen, development managers usually employ a combination of the methods shown in figures 3 - 2 and 3 - 3 with developers deploying directly to developer environments and using build managers to deploy code to their production environment.
As you’ll see later, Force.com projects can be deployed using Apache Ant. This means that server applications such as Hudson (http://hudson ci.org) can be used to manage and deploy code.
The Importance of Metadata
In previous chapters you saw that metadata plays a very important role in salesforce.com. It describes the structure of objects and their fields, as well as the page layouts associated with them. In fact, metadata describes many more structures in Force.com but what you might ask is, “Why use metadata at all?”
Metadata is a simple lightweight language (based on XML) for describing the structure of salesforce.com and Force.com development artifacts. Later on you’ll see that Force.com code can be organized into projects, which are essentially groupings of metadata files. Instead of the traditional development approach of code-compile-package-deploy, with Force.com you only need to code. The magic here is that the metadata is zipped and transferred to the Force.com servers (much faster than uploading compiled code) where it is unzipped and compiled on your behalf.
Not only is this super fast, but your changes are immediately available through any web browser, and there’s no downtime at all!
The Right Tool for the Right Job
Now that you’re equipped with an overview of how your cloud-based development network might be organized, it is important that you learn:
What Force.com developer tools exist When it is appropriate to use specific tools How to use these tools
In this section we will discuss everything you need to create, test and deploy your Force.com code whilst being mindful of the above points. We will also touch on desktop applications or areas of Force.com that you’ll need when analyzing and monitoring your code, as well as the various support options available to you.
Certain tools overlap several development tasks, and some development tasks overlap each other. It’s for this reason that the first two points are so important when discussing development toolsets.
Developing Applications on the Force.com Platform
Creating code in any modern language is usually done through an Integrated Development Environment (IDE) that offers a number of advantages over coding through a simple text-editor or something equally archaic. By the end of this section you’ll know which IDEs Force.com offers and when to use each of them.
Force.com App Builder Tools
Salesforce.com has created one of the best browser-based development environments in the world and it delivers most, if not all, of the core functionality you’d expect from a desktop-based IDE. There are two ways to access the functionality, each of which presents a slightly different experience.
The first way involves clicking Setup -> Develop as a logged in user. From there you have access to each Force.com area of development, namely:
Apex Classes Apex Triggers Components Pages
S-Controls are now deprecated and all the functionality they provided is now available through Visualforce pages.
Each section presents you with a list of code units of that type in your Org, as well as the option to edit the list items, and - in the case of Apex Classes, Components, and Pages - create new code units. We won’t go into the language specifics right now (we’ll cover each language and coding component later) but essentially touch on key areas of the development environment to demonstrate their strengths.
In figure 3 – 4 you can see the list of Apex classes that are created when you sign up for a new Developer Edition (DE) Org1. Notice the link labeled Edit on the left and the button label New at the top of the list.
If you click the New button you will be presented with a screen similar to the one shown in figure 3 – 5. We’ve taken the liberty of declaring a class and a single member method in order to demonstrate syntax highlighting. It has other features such as marking syntax errors, search and replace, and tabbed indentation (not such a simple feat in a browser window).
You’ll also notice a button labeled Version Settings. You will only need to modify the values on this tab if your class needs to maintain specific behavior not supported in subsequent releases.
You might have already noticed the two save buttons, which might seem confusing. The difference is that the Save button will save any changes and drop you back at the list-view page, while the Quick Save button will save your code and keep you on the same page. For keyboard shortcut junkies, pressing Ctrl/Cmd-S will also quick save.
Coding Apex Classes and Triggers in this environment offers very similar experiences but there are some surprises when developing code in the Pages and Components sections.
It’s in these sections that you can create and modify the pages (or page components) that your users interact with, and here the browser editor offers some bonus features. In figure 3 – 6 we’ve started coding by typing an open angle bracket and have been presented with a pop-up list of code completion suggestions.
This auto-completion feature is superb for beginners and is comprehensive for these code unit types. In addition to this you’ll notice an extra button labeled Component Reference at the top of the page which links through to a library documenting the language components along with working examples.
The second way to access the Force.com App Builder Tools development environment is by enabling Development Mode; this can be found by clicking Setup -> My Personal Information -> Personal Information, clicking Edit and then checking Development Mode as shown in figure 3 – 7.
This feature allows you to code and view the compiled results within the same browser window. It offers all the features we mentioned previously but adds a real-time view of the code you’re amending or creating. In figure 3 – 8 you can see that the development environment (also known as the Development Mode Footer) is unobtrusive, and more than this it has the component reference handy as well as offering the expected assistance when syntax is incorrect or if particular dependencies are missing. For all these reasons we proclaim this to be “King of Beginner Development Tools”.
From our commentary it’s quite obvious that the Development Mode Footer is superb for beginners, but some would contend that it’s also just as good for quick changes. We would disagree arguing that a good development infrastructure loses a lot of value without good development practices. We would consider some of these to be:
All changes must be tested, and this usually involves several test-phases.
All changes should be committed to a VCS (at very latest) prior to deployment.
All changes should be validated and accepted as correct by a colleague.
All testing should be validated and accepted as correct by a colleague.
These principles are especially important if you’re working in development teams as this increases the potential for overriding valid code or working with the wrong code version.
It is easy to overwrite code in these browser-based environments and this has the potential to cost hours or even days of work. Bugs can often be introduced when making “quick” changes through the browser as little thought goes into their implementation.
Force.com IDE
Developers will be pleased to learn that they can use the Eclipse IDE to code with the help of the Force.com IDE plug-in2. The Force.com IDE is a definitive interface for rapid development, testing and deployment of code on the Force.com platform. It also provides the ability to explore your salesforce.com schema, as well as tools to execute database queries and execute short code scripts on the fly. The theme of this section is “How to create code” and as such we’ll only explore that feature for now.
Once the IDE is installed you will have a new development perspective available to you. Open this up by clicking Window -> Open
Perspective -> Other -> Force.com at which point you’ll be presented with a page detailing information and other resources for the Force.com IDE.
To get started coding, right-click in the “Package Explorer” window and click New -> Force.com Project. If you’ve signed up for a DE (or any) Org you’ll have a set of credentials that need to be entered in this window. If you haven’t signed up yet, click the Sign Up Now! link to the right of the “Environment” drop-down box.
Many people get confused, as they’re not sure what the difference between a “Security Token” and a “Password” is. In Force.com jargon a security token is a randomly generated alphanumeric string that adds strength to your credentials in conjunction with your password. If you don’t have a security token you can get a new one emailed to you by logging into your target Org and clicking Setup > My Personal Information
-> Reset My Security Token --> Reset Security Token. It’s also important to note that if you change your password, a new security token is issued invalidating the previous one.
If you’re having trouble logging in and you’re certain that your username, password and security token are correct then the likely culprit is that the wrong environment type has been selected. Most developers will only work with “Production/Developer Edition” or “Sandbox” Orgs, so trying each of these should solve the problem. As an additional handy tip, if you use http://login.salesforce.com to login then means that you’re developing in a the first option is correct, whereas a login URL of http://test.salesforce.com sandbox.
Clicking the Next button in the wizard presents a page similar to that in figure 3 – 10. Here we encounter metadata once more, selecting those components you’d like to pull into your project. You can select a default set of components, customize the selection or choose none.
A lot of what you see in this window might be unfamiliar at this point (e.g. Apex Component, Apex Trigger, Static Resource) but you can revisit this page at any time during development and customize which metadata components you’d like to work with in Eclipse. The important concept here is that Eclipse wants to download a subset of your Force.com application in the form of metadata into a local project, thereby setting up a two-way subscription to application changes.
The default option is fine for now so you can click Finish to complete the wizard.
Looking at figure 3 – 11 you’ll see that we’ve expanded our project and opened the class that we created through the Force.com App Builder Tools IDE.
On the left, the project is laid out in a neat folder structure, grouping code unit types in their particular folders. On the right we have the code editor where you’ll notice that the code layout and highlighting is consistent with what we saw before. At the bottom of the right pane you can flip between the “Source” view – where you add actual code – and the “Metadata” view that shows how Force.com describes this class, as demonstrated in listing 3 – 1.
Listing 3 - 1. Example of Apex Class Metadata
To create new code in the Force.com IDE right-click on any folder or file in your Force.com project and highlight New. The available options are shown in figure 3 – 12 and as you can see there’s a mixture of programmatic development and declarative programming elements.
Feel free to experiment with creating declarative elements such as custom objects as this will give you feel for how they’re represented under the hood. Beyond experiment though, we’d advise steering clear of editing these files by hand as it’s error prone, and can be tough to debug if something goes wrong.
This chapter will only cover the programmatic elements and since the creation wizard for each element is a little different, these will be discussed in later sections.
Earlier we highlighted how integral metadata is to the platform and how a Force.com project is a collection of metadata files. To expand on this, each time you create or save a file in the Force.com IDE the metadata representation of that file is zip-archived and sent to the Force.com servers for compilation. The result of the compilation is then returned to your IDE to let you know whether it was successful or whether there were problems encountered. All of this is achieved at break-neck speeds via the Metadata API, which will be discussed at length in a later chapter.
This process is similar to what is usually termed deployment, although in the Force.com programming paradigm that name is reserved for another process. Deployment in the Force.com sense of the word will be discussed later in this chapter.
After working with the Force.com IDE for some time you will realize that it’s much richer than the browser-based version offering code completion for Apex classes, system classes and schema objects; verbose syntax and compilation error messages; quick code navigation including keyboard shortcuts (courtesy of Eclipse); better code organization and VCS integration. There are also features that enable deployment, analysis and testing. It is for these reasons that this IDE is the only true project development tool available to us. Luckily it’s excels in this role.
As you move from a beginner through to an intermediate, and finally to a guru Force.com developer you’ll use the Force.com IDE more, and in most cases will stop using the browser-based IDE completely. That’s not to say the Force.com IDE is a tool for advanced developers, more that the browser-based IDE is a beginner-to-intermediate level tool.
If you’d like more detail there is an official Force.com IDE article3, as well as a frequently asked questions (FAQ) document4 and the IDE release notes5. After you’ve gotten your feet wet we’d suggest checking them out.
Anonymous Blocks
Anonymous blocks provide a way to execute Apex code on the fly. The code that is executed in anonymous blocks is not persisted in the way that you’ve seen in the IDEs; instead it is lost when you “close” the anonymous block.
Because they execute immediately and create debug logs in their wake they are valuable when performing analysis, executing data fixes on
the fly, experimenting with chunks of functionality, running batch jobs, or scheduling jobs.
There are three ways to access the anonymous block functionality namely:
System Log Console Force.com IDE
A Web Services API call
Strictly speaking the third method sits outside of Force.com and as such will not be discussed here.
In a nutshell the system log console is the browser-based method used to execute anonymous blocks, and the Force.com IDE has a pane that delivers this functionality from the desktop.
System Log Console
To access the system log console you need to log into your Org and then click the System Log link6. Figure 3 – 13 shows the System Log Console window that pops up.
Clicking in the input area in the top left corner of the window will pop up an additional window that allows you to enter the code you wish to run.
If you click the Execute button and your code runs successfully each of the windowpanes will populate with a different type of information
If you click the Execute button and your code runs successfully each of the windowpanes will populate with a different type of information