Difference between revisions of "Package Items"
imported>Aeric |
imported>Aeric |
||
Line 201: | Line 201: | ||
| [[Business Hours Calendars]] || colspan="3" align="center"|''not included'' | | [[Business Hours Calendars]] || colspan="3" align="center"|''not included'' | ||
|- | |- | ||
| [[Classes]] || Y || '''N''' || '''N''' | | [[Classes]] || Y || bgcolor="pink"|'''N''' || '''N''' | ||
|- | |- | ||
| [[Dashboards]] || Y || Y || [[Overwrite Previous Package|Packaging option]] | | [[Dashboards]] || Y || Y || [[Overwrite Previous Package|Packaging option]] | ||
|- | |- | ||
| [[Global Picklists]] || Y || '''N''' || '''N''' | | [[Global Picklists]] || Y || bgcolor="pink"|'''N''' || '''N''' | ||
|- | |- | ||
| [[Mapping Profile]]s || Y || Y || [[Overwrite Previous Package|Packaging option]] | | [[Mapping Profile]]s || Y || Y || [[Overwrite Previous Package|Packaging option]] | ||
Line 217: | Line 217: | ||
| [[Roles]] || Y || [[Packages#Overriding or Merging Roles|Subscriber choice]] || '''N''' | | [[Roles]] || Y || [[Packages#Overriding or Merging Roles|Subscriber choice]] || '''N''' | ||
|- | |- | ||
| [[Sites]] || Y || '''N''' || '''N''' | | [[Sites]] || Y || bgcolor="pink"|'''N''' || '''N''' | ||
|- | |- | ||
| [[SLAs]] || colspan="3" align="center"|''not included'' | | [[SLAs]] || colspan="3" align="center"|''not included'' | ||
Line 225: | Line 225: | ||
| [[Tab Preferences]] || Y || Y || [[Overwrite Previous Package|Packaging option]] | | [[Tab Preferences]] || Y || Y || [[Overwrite Previous Package|Packaging option]] | ||
|- | |- | ||
| [[Team]] definitions || Y || '''N''' || '''N''' | | [[Team]] definitions || Y || bgcolor="pink"|'''N''' || '''N''' | ||
|- | |- | ||
| (global) [[Template Variables]]|| Y || '''N''' || '''N''' | | (global) [[Template Variables]]|| Y || bgcolor="pink"|'''N''' || '''N''' | ||
|- | |- | ||
| [[Team Data Sharing Policies]] || Y || Y || [[Overwrite Previous Package|Packaging option]] | | [[Team Data Sharing Policies]] || Y || Y || [[Overwrite Previous Package|Packaging option]] |
Revision as of 18:59, 9 March 2015
Platform elements can be selected for inclusion in a Package as package items. When selected, dependent elements are automatically included. Items that are related, but upon which the selected item does not actually depend are excluded by default--although they can generally be selected manually, if desired.
Standard Dependencies
Platform Element Dependent Elements - Application
- Includes Application settings
- Includes all Custom Objects used in the application, along with their dependencies (see below)
- Includes all Global Picklists referenced by a field in an included object
- Includes all Classes that are referenced by a Business Rule or Macro
- Includes Dashboards that are visible to all, a Role, or a Team. (Does not include private dashboards.)
- Includes all Pages used in Dashboards, Web Tabs, and Sites, as well as all Pages invoked by an Action Button
- Includes all Reports that are attached to an included dashboard. (Does not include other reports. They can be selected separately.)
- Includes all Roles used in the application
- Includes all Sites defined in the application
- Includes role-based Tab Preferences for objects
- Includes all Team definitions that are referenced in a Business Rule, Process, or Macro
- Includes role-based View Preferences for objects
- Includes all Web Services that are used in a Process, an External Lookup, an External Data Source, or a Business Rule
- Includes all Web Tabs defined in the application
- Includes all object settings and object relationships, including Record Locators
- Includes all objects that are the target of a Lookup
Note:- Does not automatically include objects that have a Lookup to the current object.
- If such Related Objects are not included in the package, any Related Information sections defined in object forms are automatically removed.
- Includes all objects that are encompassed by a Rollup Summary Field
- Includes Business Rules
- Includes Document Templates
- Includes External Data Source definitions
- Includes Forms, Layout Rules, Form Scripts, and Custom Form Actions
- Includes Fields and Field Scripts
- Includes Indexes
- Includes Macros
- Includes Processes
- Includes Validations
- Includes Web Forms
- Excludes Reports
Reports can be individually selected. Reports on an object are not automatically included. - Excludes data
Data is not included automatically. Java code can be written to create Package Data classes that add selected records during packaging, and that take the records out when the package is installed.
- Object data and other data (Package Data)
- Classes (includes
user-created classes)
- The Business Hours Calendar used in processes.
(A calendar modified by the installer is never overwritten, so installers are free to modify the calendar to suit their purposes.) - Teams and Roles used in Process tasks
- Sites
- Includes Pages
- Includes Teams and Roles involved
- Includes Child Teams if the Include Child Teams option is selected for that team
- Includes localized labels and items
- Web Tabs
Special Dependencies
When the following elements are added to a package, the listed items are added as dependencies:
- Team Data Sharing Policies
- Roles and Teams included as dependencies
- If the Include Child Teams checkbox is enabled, the child teams of the selected teams in the Data Sharing Policy are added as dependencies
- Objects in a Master-Detail relationship
Note:
The "Master-Detail relationship" option on a Lookup field has been deprecated. This section is provided for legacy objects that have a Lookup field for which that option has been selected.
Learn more: Master-Detail relationships
- If a Detail object is added to a Package, the Master object is added (automatically) as a dependent object
- If a Master object is added to a Package and if that Master object includes any Rollup Summary Fields, then the Detail object is added (automatically) as a dependent object
- When a Tenant installs a Package, the Rollup Summary Fields limit defined in Manage Tenant Capabilities is honored
- If the limit is exceeded, the installation process will stop and cannot proceed
- In order to complete the installation, delete existing Rollup Summary Fields to reduce the total number to within the defined limit
- After packaging, do not add or remove any Master-Detail relationships; doing so may cause unexpected results and/or loss of data
Items that are Never Packaged
These platform elements are never added to a package. Customizations made by the subscriber remain intact.
How Package Items are Applied
The principles that follow summarize the behavior of package items at installation time. Detailed tables list the behavior for individual items, following the summary.
Principles
- New items in the Package are added to the subscriber's system, while items with the same ID are replaced.
- Note:
- All aspects of an object (fields and forms, validations, and so on) are given a Globally Unique ID or GUID. Those IDs are preserved when the package is installed, which allows existing items to be replaced while new items are added. (When the overwrite option is chosen, items on the target system that do not have a matching GUID in the package are deleted.)
- If the subscriber created a new platform element with the same name as an item included in the package, the subscriber gets an error. (The error occurs immediately after they select the package. Installation is not allowed to proceed.)
- With few exceptions, modified items in the Package replace the versions that came from a previous Package.
The exceptions are:
- Global Picklists -- Subscribers are expected to have added items and modified labels, so they are left intact.
- Email Templates -- Subscribers are expected to have customized email templates with their return address, signature text, and possibly logo images, so they are left intact.
- Roles -- During installation, the subscriber has the option of merging or overwriting roles that are included in the package.
- __TBD: Confirm that Web Services are not part of this list.__
- Items deleted from the packager's application are never deleted from the subscriber's system unless the Overwrite Previous Package option has been enabled by the Service Provider, and the packager has chosen the Overwrite option. (Then, and then only, items deleted from the Service Provider's system are deleted from the subscriber's system when the package is installed.)
Object Aspects
This table describes the behavior of individual Object Aspects.
Object Aspect Added if New Replaced Deleted if Old Business Rules Y Y Packaging option Custom Form Actions Y Y Packaging option Document Templates Y Y Packaging option Email Templates Y N N External Data Source definitions Y Y Packaging option Fields Y Y Packaging option Field Scripts Y Y Packaging option Forms Y Y Packaging option Form Scripts Y Y Packaging option Indexes Y Y Packaging option Layout Rules Y Y Packaging option Macros Y Y Packaging option Processes Y Y Packaging option Record Locators Y Y Packaging option Validations Y Y Packaging option Web Forms Y N N
Application Elements
This table describes the behavior of other platform elements that go into an application.
Platform Element Added if New Replaced Deleted if Old Application settings Y Y Packaging option Access Profiles not included Business Hours Calendars not included Classes Y N N Dashboards Y Y Packaging option Global Picklists Y N N Mapping Profiles Y Y Packaging option Pages Y Y Packaging option Processes Y Y Packaging option Reports Y Y Packaging option Roles Y Subscriber choice N Sites Y N N SLAs not included Static Resources Y Y Packaging option Tab Preferences Y Y Packaging option Team definitions Y N N (global) Template Variables Y N N Team Data Sharing Policies Y Y Packaging option Translation Workbench Y Y __TBD__ View Preferences Y Y Packaging option Web Services Y __TBD__ Web Tabs Y Y Packaging option
Choosing a Deployment Strategy
AgileApps Cloud platform package deployment is based on the publisher/subscriber model, where subscribers are expected to have customized key aspects of the package. In the publishing process, those aspects of the installed application are left alone. Package deployment is already optimized for the publisher/subscriber model, so if that's what you're doing you're in pretty good shape. You may want to double-check the behavior of things you'll be publishing, but there shouldn't be much you need to do.
Things get a little more interesting if you're deploying packages in a development scenario, where you have one or more development systems, a test system, and a production system. In that model, the application built in the development environment needs to be fully and completely replicated in the test environment. When it is ready for distribution, it must then be fully replicated in the production environment(s).
In that situation, there are several things you'll need to do.
The first step, if you have multiple developers, is to partition the application appropriately:
- Make sure that only one person makes edits to any given aspect of an object.
If multiple people add validations, for example, that can work. But only one person should make edits to existing validations, otherwise someone's work will get overwritten. - Each person who owns objects should package them and share the package with other developers.
That step ensures that each of the development systems has the same object definitions. - Ideally, that person will be responsible for all additions to an object, as well.
If several developers add validations, for example, an integration step is required to get all of the validations on the test system. (Each developer can publish to the test system--but then individual developers don't have the same set. Or they can all publish to each other--but that requires coordination. It's easier to make one person responsible for all of the validations, and all of the forms, field definitions, and other aspects of any given object.) - Similarly, make one person responsible for each of the other application artifacts like Roles and Tab Preferences.
The next step is choose your deployment model (sandbox deployment or publish/install):
- If you have created development sandboxes, it's natural to use Sandbox Deployment.
- The advantage of that process is that sandbox pathways are clearly defined.
- The disadvantage is that the owner of the target sandbox has no say in the matter--the deployment comes at them when the packager says, whether or not the target system is ready.
- Is also important to note that the deployment process still follows the publisher/subscriber model, and that the same rules apply. So choosing sandbox deployment doesn't automatically replace everything on the target system.
- As a result, it is common even in the development scenario to use the normal publication process, where the packager "publishes" a package to make it available, after which the target systems install the package. The advantages of that process are:
- The installer can choose when to install the package.
- The installer can see what's in the package
- But:
- The installer needs to be sure to choose the "override roles" option during the installation, to be sure that any changes that were made to existing roles are reflected on the target system.
Finally, you need to make sure that each system targeted by the deployment process is an accurate reflection of the packaged application.
To do that:
- Publish the package in "overwrite" mode, so that deletes (for most package items) are replicated in the target environment.
Learn more: Packaging option - The package installer should choose the override option for roles, in case any role-definitions have changed. (Most developer-environments will also choose overwrite, unless they have been working on roles, in which case they will choose to merge role definitions.)Learn more: Subscriber choice
- On all target systems, manually delete any roles that are no longer needed.
- On all target systems, manually replicate any changes made to these application components, and manually delete any that were removed:
- Classes
- Global Picklists
- Object Email Templates
- Object Web Forms
- Site definitions
- Team definitions
- On all target systems, manually replicate any changes made to these system components (but only if they need to be replicated in the target environment):
- Access Profiles
- Business Calendars
- SLAs
- Make any required customizations to the target system:
- Web Services
(A developer may use a local Web Service. The test system may use a remote server that has been set up to return a few records, while the production system may use an actual service that returns hundreds. After deployment, each target system will need to redo the customizations to the Web Service definition.)
- Web Services