47,99 €
Mehr erfahren.
- Herausgeber: Packt Publishing
- Kategorie: Fachliteratur
- Sprache: Englisch
Companies of all sizes have seen the need for Force.com's architectural strategy focused on enabling their business objectives. Successful enterprise applications require planning, commitment, and investment in the best tools, processes, and features available.
This book will teach you how to architect and support enduring applications for enterprise clients with Salesforce by exploring how to identify architecture needs and design solutions based on industry standard patterns. There are several ways to build solutions on Force.com, and this book will guide you through a logical path and show you the steps and considerations required to build packaged solutions from start to finish. It covers all aspects, from engineering to getting your application into the hands of your customers, and ensuring that they get the best value possible from your Force.com application. You will get acquainted with extending tools such as Lightning App Builder, Process Builder, and Flow with your own application logic. In addition to building your own application API, you will learn the techniques required to leverage the latest Lightning technologies on desktop and mobile platforms.
Das E-Book können Sie in Legimi-Apps oder einer beliebigen App lesen, die das folgende Format unterstützen:
Seitenzahl: 661
Veröffentlichungsjahr: 2017
Ähnliche
Table of Contents
Force.com Enterprise Architecture - Second Edition
Force.com Enterprise Architecture - Second Edition
Copyright © 2017 Packt Publishing
All rights reserved. No part of this book may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, without the prior written permission of the publisher, except in the case of brief quotations embedded in critical articles or reviews.
Every effort has been made in the preparation of this book to ensure the accuracy of the information presented. However, the information contained in this book is sold without warranty, either express or implied. Neither the author, nor Packt Publishing, and its dealers and distributors will be held liable for any damages caused or alleged to be caused directly or indirectly by this book.
Packt Publishing has endeavored to provide trademark information about all of the companies and products mentioned in this book by the appropriate use of capitals. However, Packt Publishing cannot guarantee the accuracy of this information.
First published: September 2014
Second edition: March 2017
Production reference: 1280317
Published by Packt Publishing Ltd.
Livery Place
35 Livery Street
Birmingham B3 2PB, UK.
ISBN 978-1-78646-368-5
www.packtpub.com
Credits
Author
Andrew Fawcett
Reviewers
Zarna Chintan Naik
John M. Daniels
Peter Knolle
John Leen
Aaron Slettehaugh
Avrom Roy-Faderman
Commissioning Editor
Aaron Lazar
Acquisition Editor
Nitin Dasan
Content Development Editor
Rohit Kumar Singh
Technical Editors
Pavan Ramchandani
Kunal Chaudhari
Copy Editors
Sonia Mathur
Pranjali Chury
Project Coordinator
Vaidehi Sawant
Proofreader
Safis Editing
Indexer
Mariammal Chettiyar
Graphics
Jason Monteiro
Production Coordinator
Shraddha Falebhai
Cover Work
Shraddha Falebhai
Foreword
As a Developer Evangelist for Salesforce.com, I've seen an ever-widening demand for the exact kind of material that Andrew brings to the table with this book. While I often get the joy of showing developers new features that are rolling out on Force.com, I am often also asked questions about daily challenges when it comes to leveraging those features and implementing solutions within the ecosystem required by enterprise developer teams. This book will go a long way in providing new reference material specifically for those concerns.
In 2007, I started developing at Salesforce.com, and the landscape looked quite different than it is today. There was no Visualforce. Apex had just launched and lacked many of the interfaces it enjoys now, such as batchable and schedulable. Most custom interfaces were accomplished through extensive amounts of JavaScript embedded in S-Controls, which is a portion of the platform that is no longer supported. Communicating back to the platform could be done via the SOAP API using the AJAX toolkit. If you wanted truly fine-tuned business logic on the server side, you exposed it via a custom SOAP endpoint in Apex.
In 2014, the capabilities of the platform completely eclipse those days. With Standard Controllers, Visualforce provides basic business logic out of the box, without additional code required. For custom processing, a developer is not limited to just a single option, but various routes ranging from extending Visualforce's components library to exposing Apex methods directly to JavaScript—providing the flexibility from the old AJAX toolkit without ever needing to access the scope of the platform APIs. Apex can be scheduled, it can churn through records in the background, and it can be used to create completely custom REST endpoints. Developers now have access to powerful new APIs such as Streaming and Analytics as well as industrial strength identity services.
The platform continues to evolve. At Dreamforce, each year, we announce new tools, features, and functionality to the platform. Last year was Salesforce1 with a new mobile application that would make deploying interfaces to smartphones a simple and integrated process. This coming October, we will deliver new industry-changing innovations.
This pace of technical evolution combined with an ever increasing adoption of Force.com for enterprise applications poses a specific challenge for developers: to continually think of the platform not as just a solution for various use cases, but as a complete ecosystem that uses the platform efficiently. It is no longer sufficient to consider that a given application simply works on the platform; developers need to consider whether their applications are being designed in a way that leverages the correct features and that will co-exist efficiently and well. It takes the ability to view how the platform is being limited from a high level and with a clear direction.
I knew Andrew was the kind of architect with such an ability when we started discussing a new set of articles he was writing based on Martin Fowler's Separation of Concerns and how such design patterns could be used to develop Apex for enterprise solutions. Seven years ago, thinking about Apex in such layers of abstraction was certainly possible—it just wasn't really necessary. With all the potential tools and features in the hands of a Force.com developer now, not considering such concepts is begging for maintenance debt down the road.
Andrew being in a position to write this book should be a surprise to nobody familiar with his company's work. FinancialForce.com has created some of the most robust applications I've seen on Force.com, and as Chief Technical Officer, Andrew has been at the forefront of making them successful.
Hence, I'm delighted to see Andrew writing this book, and that at its core, we can see an expanded version of his previous design pattern articles. Actually, simply a printed copy of those articles would not be a bad addition to an architect's library, but here, we also see a more complete vision of what a developer should know before building applications on the platform that levels off from higher order considerations like interfacing Apex classes together down to the concrete tasks of properly leveraging Source Control software for Force.com.
I'm excited to see this book on my shelf, and hopefully yours—it will help you map out not only this generation of Force.com applications, but to move forward with future ones as well.
Joshua Birk
Salesforce Developer Evangelist
About the Author
Andrew Fawcett has over 25 years of experience, holding several software development-related roles with increasing focus and responsibility around enterprise-level product architectures with major international accounting and ERP software vendors over the years. He is experienced in performing and managing all aspects of the software development life cycle across various technology platforms, frameworks, industry design patterns, and methodologies, more recently Salesforce's Force.com and Heroku.
He is currently a CTO, Salesforce MVP, and Salesforce Certified Advanced Developer within a UNIT4 and Salesforce.com funded startup, FinancialForce.com. He is responsible for driving platform adoption, relationship, and technical strategy across the product suite. He is an avid blogger, open source contributor and project owner, and an experienced speaker at various Salesforce and FinancialForce.com events.
He loves watching movies and Formula1 motor racing and building cloud-controlled Lego robots! You can find him on Twitter at @andyinthecloud, and his Lego robot Twitter handle and website is @brickinthecloud.
You can visit his LinkedIn profile at https://www.linkedin.com/in/andyfawcett and his website at https://andyinthecloud.com/.
Acknowledgements
Firstly, I would like to thank my wife, Sarah, for supporting me in writing this book, giving up our weekends, and encouraging me. Also, the endless supply of tea and biscuits when needed!
I'd like to acknowledge the Salesforce community for their excellent contributions, feedback, and encouragement in respect to the many open source frameworks used in this book. Thank you, one and all, and keep it up!
Lastly I'd like to acknowledge FinancialForce.com for its commitment to the Salesforce community by sharing code through its public GitHub repositories, many of which are featured and leveraged in this book. Open source is nothing without contributors; these repositories continue to benefit from contributions made both in the past and present by developers both internal and external to FinancialForce.com. So I also want to say a big thank you to those contributors!
About the Reviewers
Zarna Chintan Naik is the Founder of YES CRM Consultants, a Salesforce.com consulting company based in Mumbai. YES CRM Consultants is primarily focused on Salesforce.com consulting, administration, and training services for clients based around the globe.
Zarna and her team also have expertise in multiple appexchange products, including Conga Merge, Clicktools, Rollup Helper, and Drawloop.
Zarna herself holds multiple certifications: Salesforce.com Certified Administrator, Developer, Sales & Service Cloud Consultant. Previously, she worked for one of the leading Salesforce.com partners in USA. She has also reviewed Learning Force.com Application Development, Packt Publishing. To know more about Zarna and YES CRM Consultants, log on to www.yescrm.org or visit her LinkedIn profile at https://in.linkedin.com/in/zarnadesai.
I would like to thank my parents, in-laws, husband, sister, friends, and family for their continued support for my work.
John M. Daniel has been working in the technology sector for over 20+ years. During that time, he has worked with a variety of technologies and project roles. Currently, he works at Morgan & Morgan Law Firm as their Lead Salesforce Platform Architect. He currently holds multiple certifications from Salesforce.com, including the Platform Developer I & II certifications and most of the Technical Architect Designer certifications. He is currently in the process of attaining the Certified Technical Architect certification. His loves to spend time with his family, swim at the beach, and work on various open source projects, such as ApexDocs and ApexUML. He co-leads his local area Salesforce Developers User Group and can be found on Twitter at @ImJohnMDaniel.
John has been a technical reviewer for:
I would like to thank my wife, Allison, for always giving me the freedom to pursue my interests.
Peter Knolle is a solutions architect at Trifecta Technologies and is a Salesforce MVP with a master's degree in software engineering and numerous Salesforce certifications. Peter has many years of experience developing a wide range of solutions on the Salesforce platform. When not working, he enjoys reading a good book and spending time with his sons, Tyler and Jack.
John Leen is a software engineer at Salesforce.com with over a decade of experience building enterprise software. As a lead on the Apex engineering team, John designed the Apex Stub API and enjoys building features that help Apex developers write great code. Prior to Salesforce, John has been an engineer at Google and at Microsoft.
Aaron Slettehaugh is senior director of Product Management for the Salesforce Platform. He has launched several products beloved by Salesforce developers, including custom metadata types and the Apex Metadata API.
Before joining Salesforce Aaron helped launch the global operations of an African NGO, led the product team at a leading IaaS innovator, and started a cloud computing company, leading it to acquisition by Citrix. He has an MBA from Stanford University and a bachelor in engineering.
www.PacktPub.com
eBooks, discount offers, and more
Did you know that Packt offers eBook versions of every book published, with PDF and ePub files available? You can upgrade to the eBook version at www.PacktPub.com and as a print book customer, you are entitled to a discount on the eBook copy. Get in touch with us at <[email protected]> for more details.
At www.PacktPub.com, you can also read a collection of free technical articles, sign up for a range of free newsletters and receive exclusive discounts and offers on Packt books and eBooks.
https://www.packtpub.com/mapt
Get the most in-demand software skills with Mapt. Mapt gives you full access to all Packt books and video courses, as well as industry-leading tools to help you plan your personal development and advance your career.
Why subscribe?
Instant updates on new Packt books
Get notified! Find out when new books are published by following @PacktEnterprise on Twitter or the Packt Enterprise Facebook page.
Customer Feedback
Thanks for purchasing this Packt book. At Packt, quality is at the heart of our editorial process. To help us improve, please leave us an honest review on this book's Amazon page at https://www.amazon.com/dp/1786463687.
If you'd like to join our team of regular reviewers, you can email us at <[email protected]>. We award our regular reviewers with free eBooks and videos in exchange for their valuable feedback. Help us be relentless in improving our products!
Preface
Enterprise organizations have complex processes and integration requirements that typically span multiple locations around the world. They seek out the best in class applications that support not only their current needs but also those of the future. The ability to adapt an application to their practices, terminology, and integrations with other existing applications or processes is a key to them. They invest as much in your application as they do in you as the vendor capable of delivering an application strategy that will grow with them.
Throughout this book, you will be shown how to architect and support enduring applications for enterprise clients with Salesforce by exploring how to identify architecture needs and design solutions based on industry-standard patterns.
Large-scale applications require careful coding practices to keep the code base scalable. You'll learn advanced coding patterns based on industry-standard enterprise patterns and reconceive them for Force.com, allowing you to get the most out of the platform and build in best practices from the start of your project.
As your development team grows, managing the development cycle with more robust application life cycle tools and using approaches such as Continuous Integration become increasingly important. There are many ways to build solutions on Force.com; this book cuts a logical path through the steps and considerations for building packaged solutions from start to finish, covering all aspects from engineering to getting it into the hands of your customers and beyond, ensuring that they get the best value possible from your Force.com application.
What this book covers
Chapter 1, Building, Publishing, and Supporting Your Application, gets your application out to your prospects and customers using packages, AppExchange, and subscriber's support.
Chapter 2, Leveraging Platform Features, ensures that your application is aligned with the platform features and uses them whenever possible, which is great for productivity when building your application, but—perhaps more importantly—it ensures whether your customers are also able to extend and integrate with your application further.
Chapter 3, Application Storage, teaches you how to model your application's data to make effective use of storage space, which can make a big difference to your customer's ongoing costs and initial decision-making when choosing your application.
Chapter 4, Apex Execution and Separation of Concerns, explains how the platform handles requests and at what point Apex code is invoked. This is important to understand how to design your code for maximum reuse and durability.
Chapter 5, Application Service Layer, focuses on understanding the real heart of your application: how to design it, make it durable, and future proofing around a rapidly evolving platform using Martin Fowler's Service pattern as a template.
Chapter 6, Application Domain Layer, aligns Apex code typically locked away in Apex Triggers into classes more aligned with the functional purpose and behavior of your objects, using object-orientated programming (OOP) to increase reuse and streamline code and leverage Martin Fowler's Domain pattern as a template.
Chapter 7, Application Selector Layer, leverages SOQL to make the most out of the query engine, which can make queries complex. Using Martin Fowler's Mapping pattern as a template, this chapter illustrates a means to encapsulate queries, making them more accessible and reusable and making their results more predictable and robust across your code base.
Chapter 8, User Interface, covers the concerns of an enterprise application user interface with respect to translation, localization, and customization, as well as the pros and cons of the various UI options available in the platform.
Chapter 9, Lightning, explains the architecture of this modern framework for delivering rich client-device agnostic user experiences, from a basic application through to using component methodology to extend Lightning Experience and Salesforce1 Mobile.
Chapter 10, Providing Integration and Extensibility, explains how enterprise-scale applications require you to carefully consider integration with existing applications and business needs while looking into the future by designing the application with extensibility in mind.
Chapter 11, Asynchronous Processing and Big Data Volumes, shows that designing an application that processes massive volumes of data either interactively or asynchronously requires consideration in understanding your customer's volume requirements and leverages the latest platform tools and features, such as understanding the query optimizer and when to create indexes.
Chapter 12, Unit Testing, explores the differences and benefits of unit testing versus system testing. This aims to help you understand how to apply dependency injection and mocking techniques to write unit tests that cover more code scenarios and run faster. You will also look at leveraging practical examples of using the Apex Stub API and the ApexMocks open source library.
Chapter 13, Source Control and Continuous Integration, shows that maintaining a consistent code base across applications of scale requires careful consideration of Source Control and a planned approach to integration as the application is developed and implemented.
What you need for this book
In order to follow the practical examples in this book, you will need to install the Salesforce Force.com IDE, Apache Ant v1.9 or later, and Java v1.8 or later, and have access to Salesforce Developer Edition Orgs via developer.salesforce.com.
The following is the list of software requirements for this book:
Who this book is for
This book is aimed at Force.com developers who are looking to push past Force.com basics and learn how to truly discover its potential. You will find this handy if you are looking to expand your knowledge of developing packaged ISV software and complex, scalable applications for use in enterprise businesses with the Salesforce platform. This book will enable you to know your way around Force.com's non programmatic functionality as well as Apex and aid you in learning how to architect powerful solutions for enterprise-scale demands. If you have a background in developing inside other enterprise software ecosystems, you will find this book an invaluable resource for adopting Force.com.
Conventions
In this book, you will find a number of text styles that distinguish between different kinds of information. Here are some examples of these styles and an explanation of their meaning.
Code words in text, database table names, folder names, filenames, file extensions, pathnames, dummy URLs, user input, and Twitter handles are shown as follows: "The Database.merge and merge DML statements support merging of accounts, leads, and contact records."
A block of code is set as follows:
When we wish to draw your attention to a particular part of a code block, the relevant lines or items are set in bold:
Any command-line input or output is written as follows:
New terms and important words are shown in bold. Words that you see on the screen, for example, in menus or dialog boxes, appear in the text like this: "You can see the current storage utilization from the Custom Settings page under Setup"
Note
Warnings or important notes appear in a box like this.
Tip
Tips and tricks appear like this.
Reader feedback
Feedback from our readers is always welcome. Let us know what you think about this book—what you liked or disliked. Reader feedback is important for us as it helps us develop titles that you will really get the most out of.
To send us general feedback, simply e-mail <[email protected]>, and mention the book's title in the subject of your message.
If there is a topic that you have expertise in and you are interested in either writing or contributing to a book, see our author guide at www.packtpub.com/authors.
Customer support
Now that you are the proud owner of a Packt book, we have a number of things to help you to get the most from your purchase.
Downloading the example code
You can download the example code files for this book from your account at http://www.packtpub.com. If you purchased this book elsewhere, you can visit http://www.packtpub.com/support and register to have the files e-mailed directly to you.
You can download the code files by following these steps:
You can also download the code files by clicking on the Code Files button on the book's webpage at the Packt Publishing website. This page can be accessed by entering the book's name in the Search box. Please note that you need to be logged into your Packt account.
Once the file is downloaded, please make sure that you unzip or extract the folder using the latest version of:
The collective source code for the application built throughout the book is available in the main branch. For each chapter, a branch has been provided containing the code added during that chapter building from the previous one, for example, branch chapter-02 will contain code from chapter-01.
The repository for this book can be found at https://github.com/afawcett/forcedotcom-enterprise-architecture.
An alternate way to download the source code is to navigate to www.github.com in your browser using the link given in the preceding section, locate the repository and branch you want to download, either the main branch or a specific chapter branch, and then click on the Download Zip button in the sidebar on the right.
Alternatively, you can download the GitHub desktop clients as listed above and click on the Clone in Desktop button.
Of course, if you are familiar with Git, you are free to use the tool of your choice.
Deploying the source code
Once you have the source code downloaded for your chosen chapter, you should execute the Ant build script to deploy the code into your chosen Salesforce Developer Edition org (as described in Chapter 1, Building, Publishing, and Supporting Your Application).
Open a command line and navigate to the root folder where you downloaded the source code (this should be the folder with the build.xml file in it). To deploy the code, execute the following command, all on one line:
Remember that the password and token are concatenated together.
Keep in mind that each chapter branch builds incrementally from the last and will overlay new files as well as changes into your chosen DE org. So, each branch may overwrite changes you make to existing files as you have been exploring that chapter. If you are concerned about this, it is best to use one of the desktop development tools listed earlier, and prior to running the previous command, download the code from the server for safe keeping.
Downloading the color images of this book
We also provide you with a PDF file that has color images of the screenshots/diagrams used in this book. The color images will help you better understand the changes in the output. You can download this file from https://www.packtpub.com/sites/default/files/downloads/ForcedotcomEnterpriseArchitectureSecondEdition_ColorImages.pdf.
Errata
Although we have taken every care to ensure the accuracy of our content, mistakes do happen. If you find a mistake in one of our books—maybe a mistake in the text or the code—we would be grateful if you could report this to us. By doing so, you can save other readers from frustration and help us improve subsequent versions of this book. If you find any errata, please report them by visiting http://www.packtpub.com/submit-errata, selecting your book, clicking on the Errata Submission Form link, and entering the details of your errata. Once your errata are verified, your submission will be accepted and the errata will be uploaded to our website or added to any list of existing errata under the Errata section of that title.
To view the previously submitted errata, go to https://www.packtpub.com/books/content/support and enter the name of the book in the search field. The required information will appear under the Errata section.
Piracy
Piracy of copyrighted material on the Internet is an ongoing problem across all media. At Packt, we take the protection of our copyright and licenses very seriously. If you come across any illegal copies of our works in any form on the Internet, please provide us with the location address or website name immediately so that we can pursue a remedy.
Please contact us at <[email protected]> with a link to the suspected pirated material.
We appreciate your help in protecting our authors and our ability to bring you valuable content.
Questions
If you have a problem with any aspect of this book, you can contact us at <[email protected]>, and we will do our best to address the problem.
Introducing the book's sample application
For this book, we will use the world of Formula 1 motor car racing as the basis for a packaged application that we will build together. Formula 1 is, for me, the motor sport that is equivalent to enterprise applications software, due to its scale and complexity. It is also a sport that I follow. My knowledge of both of these fields helped me when building the examples that we will use.
We will refer to our application as FormulaForce throughout this book, though please keep in mind Salesforce's branding policies when naming your own application, as they prevent the use of the word "Force" in the company or product titles.
This application will focus on the data collection aspects of the races, drivers, and their many statistics, utilizing platform features to structure, visualize, and process this data in both historic and current contexts.
For this chapter, we will create some initial Custom Objects and fields, as detailed in the following table. Do not worry about creating any custom tabs just yet. You can use your preferred approach to create these initial objects. Ensure that you are logged in to your packaging org (we will use the development org later in this book).
Object
Field name and type
Season__c
Name (text)
Race__c
Name (text)
Season (Master Detail Lookup to Season)
Driver__c
Name (text)
Contestant__c
Name (Auto Number CONTEST-{00000000})
Race (Master Detail Lookup to Race)
Driver (Lookup to Driver)
The following screenshot shows the preceding objects within the Schema Builder tool, available under the Setup menu:
Package types and benefits
A package is a container that holds your application components, such as Custom Objects, Apex code, Apex triggers, Visualforce pages, Lightning Components, and so on. This makes up your application. While there are other ways to move components between Salesforce orgs, a package provides a container that you can use for your entire application or deliver optional features by leveraging the so-called extension packages.
There are two types of packages—managed and unmanaged. Unmanaged packages result in the transfer of components from one org to another; however, the result is as if those components had been originally created in the destination org, meaning that they can be readily modified or even deleted by the administrator of that org. Furthermore, they are not upgradable, and are not particularly ideal from a support perspective. Moreover, the Apex code that you write is also visible for all to see, so your intellectual property is at risk.
Tip
Unmanaged packages can be used for sharing template components that are intended to be changed by the subscriber. If you are not using GitHub and the GitHub Salesforce Deployment Tool (https://github.com/afawcett/githubsfdeploy), they can also provide a means to share open source libraries to developers.
Features and benefits of managed packages
This book focuses solely on managed packages. Managed packages have the following features that are ideal for distributing your application. The org where your application package is installed is referred to as a subscriber org, since users of this org are subscribing to the services your application provides:
There are other benefits to managed packages, but these are only accessible after becoming a Salesforce partner and completing the security review process; these benefits are described later in this chapter. Salesforce provides ISVforce Guide (otherwise known as the Packaging Guide) in which these topics are discussed in depth—bookmark it now! The ISVforce Guide can be found at http://login.salesforce.com/help/pdfs/en/salesforce_packaging_guide.pdf.
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
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:
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.
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:
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:
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).
Package dependencies and uploading
Packages can have dependencies on platform features and/or other packages. You can review and manage these dependencies through the usage of the Package Detail page and the use of dynamic coding conventions, as described here.
While some features of Salesforce are common, customers can purchase different editions and features according to their needs. Developer Edition organizations have access to most of these features for free. This means that as you develop your application, it is important to understand when and when not to use those features (this is done in order to avoid unwanted dependencies that might block or inhibit the adoption of your application).
By default, when referencing a certain Standard Object, field, or component type, you will generate a prerequisite dependency on your package, which your customers will need to have before they can complete the installation. Some Salesforce features, for example Multi-Currency or Chatter, have either a configuration or, in some cases, a cost impact to your users (different org editions). Carefully consider which features your package is dependent on.
Most of the feature dependencies, though not all, are visible via the View Dependencies button on the Package Detail page (this information is also available on the Upload page, allowing you to make a final check). It is good practice to add this check into your packaging procedures to ensure that no unwanted dependencies have crept in. Clicking on this button for the package that we have been building in this chapter so far confirms that there are no dependencies.
For dependencies that are not shown, it is a good idea to make sure that the features enabled for your testing orgs are clear, thus any other dependencies will show during installation or further testing.
Later in this book, we will be discussing Lightning Components. If you're packaging these, you will be implicitly imposing the need for your customers to utilize the Salesforce My Domain feature. This is not enforced at installation time, so it is an optional dependency. However, users will not be able to use your packaged Lightning Components without first enabling and configuring My Domain.
Uploading the release and beta packages
Once you have checked your dependencies, click on the Upload button. You will be prompted to give a name and version to your package. The version will be managed for you in subsequent releases. Packages are uploaded in one of two states, beta or release, as described shortly.
We will perform a release upload by selecting the Managed - Release option from the Release Type field, so make sure you are happy with the objects created in the earlier section of this chapter, as they cannot easily be changed after this point.
Once you are happy with the information on the screen, click on the Upload button once again to begin the packaging process. Once the upload process completes, you will see a confirmation page as follows:
Packages can be uploaded in one of two states, as described here:
Tip
The ability to delete previously-published components (uploaded within a release package) is, at the time of writing this book, in pilot. It can be enabled by raising a support case with Salesforce Support. Once you have understood the full implications, they will enable it.
At this stage in the book, we have simply added some Custom Objects, so the upload should complete reasonably quickly. Note that what you're actually uploading to is AppExchange, which will be covered in the following sections.
Tip
If you want to protect your package, you can provide a password (this can be changed afterwards). The user performing the installation will be prompted for it during the installation process.
Optional package dependencies
It is possible to make some Salesforce features and/or base package component references (Custom Objects and fields) an optional aspect of your application. There are two approaches to this, depending on the type of the feature.
Dynamic bindings
For example, the Multi-Currency feature adds a CurrencyIsoCode field to the Standard and Custom Objects. If you explicitly reference this field, for example, in your Apex, Visualforce pages or Lightning pages or components, you will incur a hard dependency on your package. If you want to avoid this and make it a configuration option (for example) in your application, you can utilize dynamic Apex and Visualforce. Lightning value bindings are dynamic in nature, though aura:attribte element type references will form a compile time reference to the specified objects.
Extension packages
If you wish to package component types that are only available in subscriber orgs of certain editions, you can choose to include these in extension packages. For example, you may wish to support the Professional Edition, which does not support record types. In this case, create an Enterprise Edition extension package for your application's functionality, which leverages the functionality from this edition.
Tip
Note that you will need multiple testing organizations for each combination of features that you utilize in this way to effectively test the configuration options or installation options that your application requires.
Becoming a Salesforce partner and benefits
The Salesforce Partner Program has many advantages. The first place to visit is https://partners.salesforce.com/. You will want to focus on the areas of the site relating to being an Independent Software Vendor (ISV) partner. From here, you can click on Join Now. It is free to join, though you will want to read through the various agreements carefully, of course.
Once you wish to start listing a package and charging users for it, you will need to arrange billing details for Salesforce to take the various fees involved. While this book is not equipped to go into the details, do pay careful attention to the Standard Objects used in your package, as this will determine the license type required by your users and the overall cost to them, in addition to your charges.
Obviously, Salesforce would prefer your application to use as many features of the CRM application as possible, which may also be beneficial to you as a feature of your application, since it's an appealing immediate integration not found on other platforms, such as the ability to instantly integrate with accounts and contacts.
If you're planning on using Standard Objects, and are in doubt about the costs (as they do vary depending on the type), you can request a conversation with Salesforce to discuss this; this is something to keep in mind in the early stages.
Make sure, when you associate a Salesforce user with the Partner Community, you utilize a user that you use daily (known as your Partner Business Org user) and not one from a development or test org. Once you have completed the signup process, you will gain access to the Partner Community. The following screenshot shows what the current Partner Community home page looks like. From here, you can access many useful services:
This is your primary place to communicate with Salesforce and access additional materials and announcements relevant to ISVs, so do keep checking often. You can raise cases and provide additional logins to other users in your organization, such as other developers who may wish to report issues or ask questions.
Security review and benefits
The following features require that a completed package release goes through a Salesforce-driven process known as the security review, which is initiated via your listing when logged into AppExchange. Unless you plan to give your package away for free, there is a charge involved in putting your package through this process.
