Search icon CANCEL
Arrow left icon
Explore Products
Best Sellers
New Releases
Books
Videos
Audiobooks
Learning Hub
Conferences
Free Learning
Arrow right icon
Arrow up icon
GO TO TOP
Force.com Enterprise Architecture

You're reading from   Force.com Enterprise Architecture Architect and deliver packaged Force.com applications that cater to enterprise business needs

Arrow left icon
Product type Paperback
Published in Mar 2017
Publisher Packt
ISBN-13 9781786463685
Length 504 pages
Edition 2nd Edition
Languages
Arrow right icon
Author (1):
Arrow left icon
Andrew Fawcett Andrew Fawcett
Author Profile Icon Andrew Fawcett
Andrew Fawcett
Arrow right icon
View More author details
Toc

Table of Contents (15) Chapters Close

Preface 1. Building, Publishing, and Supporting Your Application FREE CHAPTER 2. Leveraging Platform Features 3. Application Storage 4. Apex Execution and Separation of Concerns 5. Application Service Layer 6. Application Domain Layer 7. Application Selector Layer 8. User Interface 9. Lightning 10. Providing Integration and Extensibility 11. Asynchronous Processing and Big Data Volumes 12. Unit Testing 13. Source Control and Continuous Integration Index

Creating your first managed package

Packages are created in your packaging org. There can be only one managed package being developed in your packaging org (though additional unmanaged packages are supported, it is not recommended to mix your packaging org with them). You can also install other dependent managed packages and reference their components from your application. The steps to be performed are discussed in the following sections:

  • Setting your package namespace
  • Creating the package and assigning it to the namespace
  • Adding components to the package

Setting your package namespace

An important decision when creating a managed package is the namespace; this is a prefix applied to all your components (Custom Objects, Visualforce pages, Lightning Components, and so on) and is used by developers in subscriber orgs to uniquely distinguish between your packaged components and others, even those from other packages. The namespace prefix is an important part of the branding of the application since it is implicitly attached to any Apex code or other components that you include in your package.

It can be up to 15 characters, though I personally recommend that you keep it to less than this, as it becomes hard to remember and leads to frustrating typos if you make it too complicated. I would also avoid underscore characters. It is a good idea to have a naming convention if you are likely to create more managed packages in the future (in different packaging orgs). The following is the format of an example naming convention:

[company acronym - 1 to 4 characters][package prefix 1 to 4 characters]

For example, the ACME Corporation's Road Runner application might be named acmerr.

When the namespace has not been set, the Packages page (accessed under the Setup menu under the Create submenu) indicates that only unmanaged packages can be created. Click on the Edit button to begin a small wizard to enter your desired namespace. This can only be done once and must be globally unique (meaning it cannot be set in any other org), much like a website domain name.

Tip

Assigning namespaces

For the purposes of following this book, please feel free to make up any namespace you desire, for example, fforce{yourinitials}. Do not use one that you may plan to use in the future, since once it has been assigned, it cannot be changed or reused.

The following screenshot shows the Packages page:

Setting your package namespace

Once you have set the namespace, the preceding page should look like the following screenshot, with the difference being that it is now showing the namespace prefix that you have used and that managed packages can now also be created. You are now ready to create a managed package and assign it to the namespace.

Setting your package namespace

Creating the package and assigning it to the namespace

Click on the New button on the Packages page and give your package a name (it can be changed later). Be sure to tick the Managed checkbox as well. Click on Save and return to the Packages page, which should now look like the following:

Creating the package and assigning it to the namespace

Adding components to the package

In the Packages page, click on the link to your package in order to view its details. From this page, you can manage the contents of your package and upload it. Click on the Add button to add the Custom Objects created earlier in this chapter. Note that you do not need to add any custom fields—these are added automatically.

The following screenshot shows broadly what your Package Detail page should look like at this stage:

Adding components to the package

When you review the components added to the package, you will see that some components can be removed while other components cannot be removed. This is because the platform implicitly adds some components for you, as they are dependencies. As we progress through this book, adding different component types, you will see this list automatically grow in some cases, and in others, we must explicitly add them.

Extension packages

As the name suggests, extension packages extend or add to the functionality delivered by the existing packages they are based on, though they cannot change the base package contents. They can extend one or more base packages, and you can even have several layers of extension packages, though you may want to keep an eye on how extensively you use this feature, as managing inter-package dependency can get quite complex, especially during development.

Extension packages are created in pretty much the same way as the process you've just completed (including requiring their own packaging org), except that the packaging org must also have the dependent packages installed in it.

As code and Visualforce pages contained within extension packages make reference to other Custom Objects, fields, Apex code, and Visualforce pages present in base package, the platform tracks these dependencies and the version of the base package present at the time the reference was made.

When an extension package is installed, this dependency information ensures that the subscriber org has the correct version (minimum) of the base packages installed before permitting the installation to complete.

You can also manage the dependencies between extension packages and base packages yourself through the Versions tab or XML metadata for applicable components (we will revisit versioning in Apex in a later chapter when discussing API integration).

You have been reading a chapter from
Force.com Enterprise Architecture - Second Edition
Published in: Mar 2017
Publisher: Packt
ISBN-13: 9781786463685
Register for a free Packt account to unlock a world of extra content!
A free Packt account unlocks extra newsletters, articles, discounted offers, and much more. Start advancing your knowledge today.
Unlock this book and the full library FREE for 7 days
Get unlimited access to 7000+ expert-authored eBooks and videos courses covering every tech area you can think of
Renews at $19.99/month. Cancel anytime