Installing and testing your package

When you uploaded your package earlier in this chapter, you will receive an e-mail with a link to install the package. If not, review the Versions tab on the Package Detail page in your packaging org. Ensure that you're logged out and click on the link. When prompted, log in to your testing org. The installation process will start. A reduced screenshot of the initial installation page is shown in the following screenshot; click on the Continue button and follow the default installation prompts to complete the installation:

Package installation covers the following aspects (once the user has entered the package password, if one was set):

• Package overview: The platform provides an overview of the components that will be added or updated (if this is an upgrade) to the user. Note that, due to the namespace assigned to your package, these will not overwrite existing components in the subscriber org created by the subscriber.
• Connected App and Remote Access: If the package contains components that represent connections to services outside of Salesforce services, the user is prompted to approve these.
• Approve Package API Access: If the package contains components that make use of the client API (such as JavaScript code), the user is prompted to confirm and/or configure these. Such components will generally not be called much; features such as JavaScript Remoting are preferred, and they leverage the Apex runtime security configured post-installation.
• Security configuration: In this step, you can determine the initial visibility of the components being installed (objects, pages, and so on), selecting admin only or the ability to select profiles to be updated. This option predates the introduction of permission sets, which permit post-installation configuration.

Tip

If you package profiles in your application, the user will need to remember to map these to the existing profiles in the subscriber org, as per step 2. This is a one-time option, as the profiles in the package are not actually installed, only merged. I recommend that you utilize permission sets to provide security configurations for your application. These are installed and are much more granular in nature.

When the installation is complete, navigate to the Installed Packages menu option under the Setup menu. Here, you can see the confirmation of some of your package details, such as namespace and version, as well as any licensing details, which will be discussed later in this chapter.

Tip

It is also possible to provide a Configure link for your package, which will be displayed next to the package when installed and listed on the Installed Packages page in the subscriber org. Here, you can provide a Visualforce page to access configuration options and processes, for example. If you have enabled Seat based licensing, there will also be a Manage Licenses link to determine which users in the subscriber org have access to your package components, such as tabs, objects, and Visualforce pages. Licensing, in general, is discussed in more detail later in this chapter.

Automating package installation

It is possible to automate some processes using the Salesforce Metadata API and associated tools, such as the Salesforce Migration Toolkit (available from the Tools menu under Setup), which can be run from the popular Apache Ant scripting environment. This can be useful if you want to automate the deployment of your packages to customers or test orgs. In the final chapter of this book, we will study Ant scripts in more detail.

Options that require a user response, such as the security configuration, are not covered by automation. However, password-protected managed packages are supported. You can find more details on this by looking up the installed package component in the online help for the Salesforce Metadata API at https://www.salesforce.com/us/developer/docs/api_meta/.

As an aid to performing this from Ant, a custom Ant task can be found in the sample code related to this chapter (see /lib/antsalesforce.xml). The following is a /build.xml Ant script (also included in the chapter code) to uninstall and reinstall the package. Note that the installation will also upgrade a package if the package is already installed. The following is the Ant script:

<project name="FormulaForce" 
   xmlns:sf="antlib:com.salesforce" basedir=".">

  <!--  Downloaded from Salesforce Tools page under Setup -->
  <typedef 
    uri="antlib:com.salesforce" 
    resource="com/salesforce/antlib.xml" 
    classpath="${basedir}/lib/ant-salesforce.jar"/>

  <!-- Import macros to install/uninstall packages -->
 <import file="${basedir}/lib/ant-salesforce.xml"/>
  <target name="package.installdemo">
 
    <uninstallPackage 
       namespace="yournamespace"   
       username="${sf.username}" 
       password="${sf.password}"/> 
    <installPackage
       namespace="yournamespace"version="1.0"
       username="${sf.username}"
       password="${sf.password}"/>
  </target>
</project>

You can try the preceding example with your testing org by replacing the namespace attribute values with the namespace you entered earlier in this chapter. Enter the following commands, all on one line, from the folder that contains the build.xml file:

ant package.installdemo
							-Dsf.username=testorgusername
							-Dsf.password=testorgpasswordtestorgtoken

Tip

You can also use the Salesforce Metadata API to list packages installed in an org, for example, if you wanted to determine whether a dependent package needs to be installed or upgraded before sending an installation request. Finally, you can also uninstall packages if you wish.