Patent Grant
10831462
The present invention relates generally to database systems, and more particularly to systems and methods for installing application packages to an application platform and upgrading installed applications.
Application packaging functionality in an on-demand database system was previously introduced to support exchanging customizations from one organization (org) to another. However, in early releases, limited support for customizations involving standard objects and page layouts was provided. For example, previously, there was limited or no ability to add custom fields to standard objects such as Accounts, Contacts, or Opportunities. In addition, there was no distinction between objects installed from the application exchange directory and those created manually by customers in a subscribing organization. All objects could be modified at will by the administrators in the subscribing organization. This aspect opens up the possibility that changes to components of an Application could break integrations with external services or controls. Finally, there were limited facilities provided to support future upgrades to the components installed as part of a partner application.
Therefore it is desirable to provide systems and methods that overcome the above and other problems. In particular, it is desirable to provide systems and methods that: ensure that all packages downloaded from an application directory can be successfully installed to a subscribing organization, even if they have components named the same as other components in the subscriber organization; enable developers/publishers to publish or reference anything they can create manually; ensure that key integration points and business process automation logic cannot be broken by the local administrators; and/or enable developers/publishers to provide updates to applications which have been installed by various users/subscribers.
The present invention provides systems and methods for installing application packages to an application platform and upgrading installed application packages. The systems and methods are particularly useful in an on-demand database service.
In certain aspects, systems and methods are provided that: ensure that all packages downloaded from an application directory can be successfully installed to a subscribing organization, even if they have components named the same as other components in the subscriber organization; enable developers/publishers to publish or reference anything they can create manually; ensure that key integration points and business process automation logic cannot be broken by the local administrators; and/or enable developers/publishers to provide updates to applications which have been installed by various users/subscribers.
In certain aspects, application packages may be uploaded to a directory by developing users (developers) for installation by subscribing users (subscribers). Alternatively, a developer may send identification information to a subscribing user to allow that user to access and install that application package created by the developer. Application packages may also be upgraded. For example, if a developer/export user changes the original source package, a subscriber can choose to pull into their organization the change(s) made by the publisher while preserving any data rows the subscriber had created since first importing the package. According to certain aspects, one or more flags may be set in the package definition to determine whether and to what extent customizations to a package may be made and upgraded by the subscriber and/or developer. In one aspect, a “manageable” field is provided to identify whether customizations to a particular object are subject to upgrade. For example, if the package or an object in the package is marked as managed, a user is allowed to customize the package or the object, and these customizations will not be altered upon upgrading of the package. In another aspect, a “control” field is provided to identify whether an object may be modified by the developer and/or the subscriber. In another aspect, an “immutable” field is provided to identify whether an object can or cannot be altered by anyone. For example, the developer can set the immutable flag so that nobody is able to modify the packages after it has been published. An upgrade process that executes checks each of these fields, where present, to determine the extent that customizations are maintained upon upgrading.
According to one aspect, a method is provided for installing application packages to an application platform managed by an on-demand database service. The method typically includes indicating, by a developer (publisher) of an application package, that the developer will allow a license manager that tracks applications on behalf of at least one developer, to track what versions of the application package the developer has uploaded and what versions a set of subscribers currently have installed, and permitting the license manager to inform at least one of the set of subscribers of a new update to the application package when the developer uploads the new update. In certain aspects, the method includes not applying changes made by the developer to a custom object having metadata indicating that the custom object is an “immutable” object to identify that the custom object cannot be altered by anyone. In certain aspects, the method includes restricting at least one of the developer and the subscriber from modifying a custom object having metadata indicating that the custom object is a “managed” object to identify that the custom object can be customized by the developer and the subscriber, thereby avoiding conflicting changes to respective versions of the metadata of the developer and the subscriber.
According to one aspect, a method is provided for installing application packages to an application platform managed by an on-demand database service. The method typically includes indicating, by a developer (publisher) of an application package, that the developer will allow a license manager that tracks applications on behalf of at least one developer to track what versions of the application package the developer has uploaded and what versions a set of subscribers currently have installed. The method also typically includes permitting the license manager to inform at least one of the set of subscribers of a new update to the application package when the developer uploads the new update.
According to another aspect, a method is provided for upgrading application packages installed to an application platform and managed by an on-demand database service. the method typically includes storing an uploaded application package at a directory that is accessible by a plurality of subscribers, the application package being created by a developer and including a set of metadata components. the method also typically includes responsive to receiving from a first subscriber a selection of the application package, installing the application package to the first subscriber, receiving, from the developer, a new version of the uploaded application package at the directory, storing the new version, wherein the stored new version includes only a) any new metadata component or components relative to a prior version and/or b) any changes to a metadata component of a prior version. The method also typically includes informing the first subscriber of the new version of the application package, and responsive to receiving from a subscriber a selection of the new version, installing the new version to the subscriber.
According to yet another aspect, a computer-readable medium storing computer code for controlling one or more processor components to manage installation of application packages to an application platform in an on-demand database service is provided. The code typically includes instructions to receive an indication by a developer of an application package that the developer will allow a license manager that tracks applications on behalf of at least one developer to track what versions of the application package the developer has uploaded and what versions a set of subscribers currently have installed, and permit the license manager to inform at least one of the set of subscribers of a new update to the application package when the developer uploads the new update.
According to another aspect, a computer-readable medium storing computer code for controlling one or more processor components to manage installation and upgrading of application packages to an application platform in an on-demand database service is provided. The code typically includes instructions to store an uploaded application package at a directory that is accessible by a plurality of subscribers, the application package being created by a developer and including a set of metadata components, and responsive to receiving from a first subscriber a selection of the application package, install the application package to the first subscriber. The code also typically includes instructions to, responsive to receiving from the developer a new version of the uploaded application package, store the new version to the directory, wherein the stored new version includes only a) any new metadata component or components relative to a prior version and b) any changes to a metadata component of a prior version. The code also typically includes instructions to automatically inform the first subscriber of the new version of the application package, and responsive to receiving from a subscriber a selection of the new version, install the new version to that subscriber.
According to yet another aspect, a system is provided for managing installation and upgrades of application packages installed to an application platform in an on-demand database service. The system typically includes a database system for storing metadata components, and one or more processors configured to store an uploaded application package to a directory portion of the database that is accessible by a plurality of subscribers, the application package including a set of metadata components created and uploaded to the directory by a developer. The processors are also typically configured to, responsive to receiving from a first subscriber a selection of the application package, install the application package to the first subscriber, and responsive to receiving from the developer a new version of the uploaded application package, store the new version to the directory, wherein the stored new version includes only a) any new metadata component or components relative to a prior version and/or b) any changes to a metadata component of a prior version. The processors are also typically configured to automatically inform the first subscriber of the new version of the application package, and responsive to receiving from a subscriber a selection of the new version, install the new version to that subscriber.
Reference to the remaining portions of the specification, including the drawings and claims, will realize other features and advantages of the present invention. Further features and advantages of the present invention, as well as the structure and operation of various embodiments of the present invention, are described in detail below with respect to the accompanying drawings. In the drawings, like reference numbers indicate identical or functionally similar elements.
The present invention provides systems and methods for installing application packages to an application platform and upgrading installed application packages. The systems and methods are particularly useful in an on-demand database service.
System Overview
The users of those user systems 12 might be users in differing capacities, and the capacity of a particular user system 12 might be entirely determined by permissions (permission levels) for the current user. For example, where a salesperson is using a particular user system 12 to interact with System 16, that user system has the capacities allotted to that salesperson. However, while an administrator is using that user system to interact with System 16, that user system has the capacities allotted to that administrator. In systems with an hierarchical role model, users at one permission level may have access to applications, data, and database information accessible by a lower permission level user, but may not have access to certain applications, database information, and data accessible by a user at a higher permission level. Thus, different users will have different capabilities with regard to accessing and modifying application and database information, depending on a user's security or permission level.
Network 14 can be a LAN (local area network), WAN (wide area network), wireless network, point-to-point network, star network, token ring network, hub network, or other appropriate configuration. As the most common type of network in current use is a TCP/IP (Transfer Control Protocol and Internet Protocol) network such as the global internetwork of networks often referred to as the “Internet” with a capital “I,” that will be used in many of the examples herein. However, it should be understood that the networks that the present invention might use are not so limited, although TCPIIP is a frequently implemented protocol.
User systems 12 might communicate with System 16 using TCP/IP and, at a higher network level, use other common Internet protocols to communicate, such as HTTP, FTP, AFS, WAP, etc. In an example where HTTP is used, user system 12 might include an HTTP client commonly referred to as a “browser” for sending and receiving HTTP messages to and from an HTTP server at System 16. Such HTTP server might be implemented as the sole network interface between System 16 and network 14, but other techniques might be used as well or instead. In some implementations, the interface between System 16 and network 14 includes load sharing functionality, such as round-robin HTTP request distributors to balance loads and distribute incoming HTTP requests evenly over a plurality of servers. At least as for the users that are accessing that server, each of the plurality of servers has access to the MTS′ data; however, other alternative configurations are contemplated.
In one aspect, the system shown in
According to one embodiment, each System 16 is configured to provide web pages, forms, applications, data and media content to user (client) systems 12 to support the access by user systems 12 as tenants of System 16. As such, System 16 provides security mechanisms to keep each tenant's data separate unless the data is shared. If more than one MTS is used, they may be located in close proximity to one another (e.g., in a server farm located in a single building or campus), or they may be distributed at locations remote from one another (e.g., one or more servers located in city A and one or more servers located in city B). As used herein, each MTS could include one or more logically and/or physically connected servers distributed locally or across one or more geographic locations.
One arrangement for elements of System 16 is shown in
Several elements in the system shown in
As discussed above, embodiments are suitable for use with the Internet, which refers to a specific global internetwork of networks. However, it should be understood that other networks can be used instead of the Internet, such as an intranet, an extranet, a virtual private network (VPN), a non-TCP/IP based network, any LAN or WAN or the like.
According to one embodiment, each user system 12 and all of its components are operator configurable using applications, such as a browser, including computer code run using a central processing unit such as art Intel Pentium® processor or the like. Similarly, System 16 (and additional instances of an MTS, where more than one is present) and all of Additionally, the term “server” is meant to include a computer system, including processing hardware and process space(s), and an associated storage system and database application (e.g., OODBMS or RDBMS) as is well known in the art. It should also be understood that “server system” and “server” are often used interchangeably herein. Similarly, the database object described herein can be implemented as single databases, a distributed database, a collection of distributed databases, a database with redundant online or offline backups or other redundancies, etc., and might include a distributed database or storage network and associated processing intelligence.
Application platform 18 includes an application setup mechanism 38 that supports application developers' creation and management of applications, which may be saved as metadata into tenant database 108 by save routines 36 for execution by subscribers as one or more tenant processes 104 managed by tenant management process 110 for example. Invocations to such applications may be coded using Apex 34 that provides a programming language style interface extension to API 32. Invocations to applications may be detected by one or more system processes, which manages retrieving application metadata 116 for the subscriber making the invocation and executing the metadata as an application in a virtual machine.
It should also be understood that each application server 100 may be communicably coupled to database systems, e.g., system database 106 and tenant database(s) 108, via a different network connection. For example, one server 1001 might be coupled via the Internet 14, another server 100N-1 might be coupled via a direct network link, and another server 1OON might be coupled by yet a different network connection. Transfer Control Protocol and Internet Protocol (TCP/IP) are typical protocols for communicating between servers 100 and the database system; however, it will be apparent to one skilled in the art that other transport protocols may be used to optimize the system depending on the network interconnect used.
In certain aspects, each application server 100 is configured to handle requests for any user associated with any organization that is a tenant. Because it is desirable to be able to add and remove application servers from the server pool at any time for any reason, there is preferably no server affinity for a user and/or organization to a specific application server 100. In one embodiment, therefore, an interface system implementing a load balancing function (e.g., an F5 Big-IP load balancer) is communicably coupled between the servers 100 and the user systems 12 to distribute requests to the servers 100. In one aspect, the load balancer uses a least connections algorithm to route user requests to the servers 100. Other examples of load balancing algorithms, such as round robin and observed response time, also can be used. For example, in certain aspects, three consecutive requests from the same user could hit three different servers 100, and three requests from different users could hit the same server 100. In this manner, System 16 is multi-tenant, wherein System 16 handles storage of, and access to, different objects, data and applications across disparate users and organizations.
As an example of storage, one tenant might be a company that employs a sales force where each salesperson uses System 16 to manage their sales process. Thus, a user might maintain contact data, leads data, customer follow-up data, performance data, goals and progress data, etc., all applicable to that user's personal sales process (e.g., in tenant database 108). In an example MTS arrangement, since all of this data and the applications to access, view, modify, report, transmit, calculate, etc., can be maintained and accessed by a user system having nothing more than network access, the user can manage his or her sales efforts and cycles from any of many different user systems. For example, if a salesperson is visiting a customer and the customer has Internet access in their lobby, the salesperson can obtain critical updates as to that customer while waiting for the customer to arrive in the lobby.
While each user's data might be separate from other users' data regardless of the employers of each user, some data might be organization-wide data shared or accessible by a plurality of users or all of the users for a given organization that is a tenant. Thus, there might be some data structures managed by System 16 that are allocated at the tenant level while other data structures might be managed at the user level. Because an MTS might support multiple tenants including possible competitors, the MTS should have security protocols that keep data, applications, and application use separate. Also, because many tenants will opt for access to an MTS rather than maintain their own system, redundancy, uptime, and backup are additional critical functions and need to be implemented in the MTS.
In addition to user-specific data and tenant-specific data, System 16 might also maintain system level data usable by multiple tenants or other data. Such system level data might include industry reports, news, postings, and the like that are sharable among tenants.
In certain aspects, client systems 12 communicate with application servers 100 to request and update system-level and tenant-level data from System 16 that may require one or more queries to database system 106 and/or database system 108. System 16 (e.g., an application server 100 in System 16) automatically generates one or more SQL statements (the SQL query) designed to access the desired information. Database system 108 may generate query plans to access the requested data from the database.
Each database can generally be viewed as a collection of objects, such as a set of logical tables, containing data fitted into predefined categories. A “table” is one representation of a data object, and is used herein to simplify the conceptual description of objects and custom objects according to the present invention. It should be understood that “table” and “object” may be used interchangeably herein. Each table generally contains one or more data categories logically arranged as columns or fields in a viewable schema. Each row or record of a table contains an instance of data for each category defined by the fields. For example, a CRM database may include a table that describes a customer with fields for basic contact information such as name, address, phone number, fax number, etc. Another table might describe a purchase order, including fields for information such as customer, product, sale price, date, etc. In some multi-tenant database systems, standard entity tables might be provided for use by all tenants. For CRM database applications, such standard entities might include tables for Account, Contact, Lead and Opportunity data, each containing pre-defined fields. It should be understood that “entity” may also be used interchangeably herein with “object” and “table”.
In some multi-tenant database systems, tenants may be allowed to create and store custom objects, or they may be allowed to customize standard entities or objects, for example by creating custom fields for standard objects, including custom index fields. U.S. patent application Ser. No. 10/817,161, filed Apr. 2, 2004, entitled “Custom Entities and Fields in a Multi-Tenant Database System”, and which is hereby incorporated herein by reference, teaches systems and methods for creating custom objects as well as customizing standard objects in a multi-tenant database system. In certain aspects, for example, all custom entity data rows are stored in a single multi-tenant physical table, which may contain multiple logical tables per organization. It is transparent to customers that their multiple “tables” are in fact stored in one large table or that their data may be stored in the same table as the data of other customers.
In one embodiment, users have the ability to create, post and exchange applications. As used herein, in one aspect, an application is a group or package of multi-tenant database setup data (e.g., metadata) that defines its data model, user interface and business logic. For example, in one aspect a user/developer may define a tab set, which logically defines the group of metadata that makes up an application. A tab represents a user interface into an element of an application or into a database object. Selection of a tab provides a user access to the object or element of the application represented by the tab. A tab set is a group of related tabs that work as a unit to provide application functionality. New tabs and tab sets may be defined and tab set views may be customized so that an end user can easily and conveniently switch between the various objects and application elements represented by the defined tabs and tab sets. In one aspect, for example, tabs and tab sets may be used as a means to switch between applications in a multiple application environment, such as an on demand web-based hosted application environment. U.S. patent application Ser. No. 11/075,546, filed Mar. 8, 2005, titled “Systems and Methods for Implementing MultiApplication Tabs and Tab Sets”, which is hereby incorporated by reference, discusses various aspects and details of tabs and tabs sets.
As used herein, a “package” is a metadata object that references the set of metadata objects used in an application in an organization. A “package” is or includes, in certain aspects, a collection of metadata components. A package can also include code (e.g., Apex, javascript, etc. or formulas) and files (e.g., Word documents or other file types). As used herein, an “organization” can mean a single tenant in a multi-tenant system and/or a set of metadata (both application data and metadata) for a single tenant in a multi-tenant system.
In one embodiment, a user/developer can precisely define a metadata “package” which includes all setup data (e.g., custom object definitions, page layout definitions, workflow rules, etc.) that make up an application. A package may include 0, 1 or more tab sets. The user can then export this package from one “source” organization to a “container” organization that is not associated with any tenant in the database system. An exported package is registered with or listed in an application directory. A user that creates and/or exports a package will be referred to herein as a source user or exporting user or a developer. The source user can choose to have the package name and application listed in a public portion of the application directory. Another user can import the package into a separate “target” organization allowing this organization to use the application independently of the developer organization. A user that views and/or imports a package will be referred to herein as a viewing user or importing user or a subscriber.
In one aspect, the application directory includes a public portion that includes published packages intended for use by anyone, and a private portion that includes packages not intended for general use (e.g., packages intended for use by import users as selected by the source user). The directory allows other users to browse published applications and choose which ones they want to install into their organization. In one aspect, the central directory is organized by a category hierarchy that allows users to search and browse by category for the types of application they're interested in.
In certain aspects, the directory is built using JSP pages, JSTL, a JSP tag library, JSP tags, and Java classes. In one aspect, data used by the directory is stored in an organization object managed by one or more directory administrators. Developers of applications may use the directory to input and maintain descriptive information held in a DirectoryEntry object for each application. Directory entries have an associated status field and only applications having a status of “published” or “public” are rendered for a visitor. A status of “preview” allows developers and directory administrators to see results as they will appear on the web before they become public.
Additional aspects and details of a package creation process, an application package export process and an application directory can be found in U.S. patent application Ser. No. 11/530,394 filed Sep. 8, 2006, titled “Systems and Methods for Exporting, Publishing, Browsing and Installing On-Demand Applications In A Multi-Tenant Database”, which is hereby incorporated by reference.
To import and install a package into an organization, an import user (subscriber) navigates to the URL that was generated by the package export process, either through the directory, or via a message from the developer. This URL contains a unique key that identifies a particular exported application and package. The import user may have found this URL by browsing the public directory, or an exporting user may have simply emailed the URL to that user. When the subscriber clicks on the URL they are able to access, view and import the package.
Upon selecting a package for import from the directory, for example, code on the server system takes the metadata from the container organization, selects the appropriate subscriber organization, reads the metadata from the container organization, and writes that metadata into the subscriber organization. Any conflicting metadata (e.g., object or field names) can be resolved by the importing user, e.g., by aborting or by renaming subscriber organization objects, fields, etc. It should be noted that the import process preferably does not overwrite any existing subscriber organization fields. Also, an import user can uninstall the imported application.
In one aspect, installation is a multi-step process with one or more steps performed using an installation wizard. For example, in one aspect, the steps include providing a display of the package contents for the user to examine and confirm they want to install, configuring the security for the existing profiles in the subscriber's organization, importing the package contents, and deploying the application to the intended users. An import user may also choose to customize items or components in the install package.
In certain aspects, some or all of the following steps may need to be performed or may occur during the package import and install process:
1) Log into the recipient organization by entering a UserID and Password. This is a user id for the recipient organization into which the package is to be imported.
2) Optionally, the exporter may have password protected the package. If this is the case, the import user has to enter the package password before they can import it (this is a different password than the user password required to log into the recipient organization).
3) If object names in the package conflict with setup data in the recipient organization, the import process may fail. The import user may change the object names on conflicting objects within the recipient organization and restart the import process.
4) During the import process, the recipient organization is locked to prevent inconsistent metadata updates.
5) The import process checks to make sure the importing user has appropriate organization permissions to import a package.
6) The import user may be asked to define mappings from source organization specific references in the package to values appropriate for the recipient organization. For example, the import user may be prompted to specify a user id, profile or role.
7) The setup data is copied into the subscriber organization in a “development” mode. This allows a subscriber to verify that the application functions correctly before deploying it to users within the subscriber organization.
8) The import process scans the package for malicious functionality. For example, it can check for any Web Integration Links (WILs) that may post data to third party websites.
If specified in the package definition, a subscriber is unable to change any of the setup data in the package after it is imported. For example, the import user cannot add or remove fields from a custom object after it is imported if specified in the package definition. This is implemented, in certain aspects, by the custom object edit screen functionality checking the package definition tables before allowing any edits to an object in the recipient organization.
A subscriber can optionally “uninstall” a package. This can be implemented because the system keeps track of which metadata objects belong to the package (e.g., through the package database schema).
In certain aspects, packages may be upgraded. For example, if a developer/export user changes the source package, the import user can choose to pull into their organization the change(s) made by the publisher while preserving any data rows the subscriber had created since first importing the package. According to certain aspects, one or more flags may be set in the package definition to determine whether and to what extent customizations to a package may be made and upgraded. In one aspect, a “manageable” field is provided to identify whether customizations to a particular object are subject to upgrade. For example, if the package or an object in the package is marked as managed, the user is allowed to customize the package or the object, and these customizations will not be altered upon upgrading of the package. In another aspect, a “control” field is provided to identify whether an object may be modified by the developer and/or the subscriber. In another aspect, an “immutable” field is provided to identify whether an object can or cannot be altered by anyone. For example, the developer can set the immutable flag so that nobody is able to modify the packages after it has been published. An upgrade process that executes checks each of these fields, where present, to determine the extent that customizations are maintained upon upgrading.
The upgrade model in certain aspects is a pull rather than a push paradigm. Pull is more forgiving: if an error occurs during the upgrade process, the administrator can manually address the problem and try again. Because of this leniency, guaranteed upgrades are not required. However, to implement automatic upgrades, in certain aspects, a framework for guaranteed upgrades is provided, so that upgrades can be automatically applied without failure and without human intervention. It should be noted that there are several different ways in which an upgrade to an application package could break down, including, for example the following:
Collisions: A new version of a package adds a custom object with the same name as an existing custom object in the subscribing organization.
Divergent changes: A new version of a package changes some attribute of afield, which has also been changed in the subscribing organization.
Destructive changes: A new version of a package removes a custom object or custom field, changes a custom field type, changes an API name, etc.
Resource limitations: A new version of a package adds 10 or more custom fields, and the subscribing organization is within 10 fields of the edition limit.
Permissions: A new version of a package requires an object such as Campaigns, and the subscribing organization has not licensed that object.
Corruption: Something goes wrong with the upgrade process, leaving the subscribing organization in an invalid state.
In certain aspects these problems are addressed as follows. To address Collisions, in certain aspects, entities for which the name conflict problem exists are enhanced to support namespaces as will be described in more detail below. For these entities, the name/label/etc will have to be unique only within a namespace. Local customizations and installed metadata will have distinct namespaces, as will metadata from different developers. In some cases the uniqueness requirement may be removed entirely. To address divergent changes, in certain aspects, a developer may mark a package as ‘managed’ on initial publication to the directory as will be described more below. To be upgradeable, a package must be managed. In general, managed metadata cannot be modified outside of the source organization, although there may be certain well-defined exceptions. To address destructive changes, in certain aspects, developers are not allowed to upload an upgrade which makes destructive changes.
To address resource limitations, in certain aspects, an upgrading subscriber may receive an error due to a resource limitation. Because upgrades are typically manual rather than automatic, the subscriber can address the error (by deleting unused metadata, upgrading to a different edition, etc.) and try again. This approach will not work with automatic upgrades. Therefore, in certain aspects, all resource limits are removed such that no work is required to prevent upgrade failures due to resource exhaustion. To address permissions issues, in certain aspects, as with resource limitations, an upgrading subscriber may receive an error due to an unsatisfied permissions requirement. The subscriber must address the problem and try again. To address corruption, in certain aspects, the upgrade process maintains a progress log, and uses this information to restart the upgrade if a recoverable error occurs.
Metadata Robustness
Another major goal is to allow developers to lock portions of their packages to prevent\ subscriber organizations from making breaking changes. Because installed metadata is typically treated no differently from locally created metadata, a subscriber can change various controls, rename objects and fields, and generally adversely impact the subscriber's organization. A second aspect of meta data robustness is protecting intellectual property. Developers may want to prevent subscribers from viewing the internal implementation details of some components, such as SControls and Field Formulas.
In certain aspects, directory upgrades are not automatically distributed to subscribing organizations. Instead, the process requires that a subscriber pull the upgrade to their organization. In certain aspect this includes the developer uploading the new version to the directory, notifying subscribers via an administration VI, email, and/or a visual cue in the Package VI., and manually initiating the upgrade by subscribers.
Some developers may want to convert their existing packages from unmanaged to managed. The state of such installed packages in each subscribing organization is unknown: subscribers could have made any sort of change to the original package content. In certain aspects, a subscriber will the following options:
1) Continue on the unmanaged path, with local customizations and extensions and
2) Manually restore the package to its original state. The restoration process should not be automated because there may be other local customizations that depend upon the modified package state. These customizations may have to be reimplemented.
In certain aspects, tools are included to help subscribers identify and reconcile changes between the package in their organization, and the original package state. In one aspect, a developer process for converting a package from managed to unmanaged includes flagging the package as ‘managed’, resolving any errors, such as namespacing custom objects and fields in the package, and publish the package to the directory.
Custom Fields on Standard Objects
In certain aspects, developers can package custom objects and all of their fields formulas, validations, etc. However, custom fields on standard objects should not be packaged in certain aspects. In certain aspects, developers are able to package individual custom fields on standard objects. This enhancement is closely related to support for publishing extensions to another developer's package: custom fields on a standard object will behave similarly to custom fields on another developer's custom object. In one aspect, =custom fields are handled as follows:
Custom Fields are automatically (and invisibly to the user) added to the package for all Custom Objects.
Custom Fields on Standard Objects are added individually by the user. A list of
Custom Fields would only show Custom Fields for Standard Objects (and for imported and managed Custom Objects, see below).
Custom Objects imported via managed packages are handled identical to Standard
Objects with respect to Custom Field packaging.
Dependency Tracking
In one aspect, dependencies are distinguished. For example, in one aspect, dependencies are identified as “highlevel” and “lowlevel” dependencies. “Lowlevel” dependencies are automatically derived dependencies that are added to a package before export and the dependencies are invisible to the user. “Highlevel” dependencies are also added automatically but at the time when the dependent object is added and visibly to the user. This requires that handling of a custom field dependency is treated differently depending on how the dependency was added. In one aspect, locally created Custom Objects are handled as “lowlevel” dependencies. Individually added Custom Formula Fields may introduce additional dependencies. These dependencies are added as “highlevellt dependencies to the package, i.e., the user is able to review the package contents before the final export. In certain aspects, the same holds true for other components. For example validation formulas will follow the same rules. All validations are added for a custom object (“lowlevel”), but may be individually added for standard (and imported and managed) Objects (“highlevellt). In general, formulas (e.g., Validations, Custom Formula Fields, Field Update Formulas, and Default Value Formulas) may contain references to Custom Fields on external object as well (for example User). These Custom Fields are automatically added to the package as “highlevel” dependencies. Technically this implies that Custom Fields on Custom Objects are added by the “Derived Object” logic that is performed at package export time. Custom Fields on Standard Object are handled by the dependencies spider process, both when a dependent object is added to a package and upon export validation of the package.
In one aspect, workflow rules, approvals, and workflow actions are managed and are exported as inactive. The subscriber may not change the active flag. All workflow items should be considered as templates that the subscriber may clone, e.g., rules, approvals, and actions, and customize to local needs.
Package Dependencies
In certain aspects, custom objects are treated as atomic units for the purposes of packaging: including a custom object in a package automatically includes all fields, formulas, record types, etc. The code does not analyze dependencies below the object level, because it does not have to. In certain aspects, an organization is able to package one or more fields on a standard object. In another aspect, an organization is able to package fields, formulas, record types, validations, etc. on custom objects from other developers. Currently custom objects can be added to packages only in their entirety. All custom fields, formulas, record types, etc, are implicitly added to the package. This feature allows a package maintainer to select individual custom fields (on both custom and standard objects) to be included in a package. Any custom fields that are referenced by other object wide properties will automatically be included in the package.
According to one aspect, object properties that should be scanned for references 10 include:
1. Validation Formulas
2. Custom Field Formulas
3. Custom Links
4. Mail Merge
5. Workflow Rules and Actions
Formulas (e.g., Formula Fields, Defaults, Validations) may also reference fields on external entities (e.g., User, RecordType, etc). If these references point to custom fields, those fields are automatically included into the package in one aspect.
If the number of custom fields per entity is limited, allowing to package fields on standard objects (or as extensions on custom objects) might rapidly exhaust the supply of custom fields at the installing organization. In certain aspects, at package export time, the user will be presented with a list of components that were automatically added to the package, hence custom objects will not be added without a conscious decision.
Since it is now possible to add “partial” objects to a package, the UI in certain aspects is changed as follows:
1. Custom Fields are added to the list of high-level components that can be manually selected to be added to a package.
2. Custom Objects are a high level choice of components to add to a package. A manually added custom object automatically causes all its custom fields, validations, record types, etc. to be added to the project.
3. Custom Objects referenced by manually added Custom Fields are automatically added as part of the spidering process at package export time.
4. The same logic applies to Custom Validations: A manual choice to add validations, referred objects are automatically included and all validations are included for
5 manually added custom objects.
Package Versioning
In certain aspects, a developer can create a package, upload that package to the application directory, make arbitrary changes to the package contents, and upload it to the directory again. The directory has no knowledge that a relationship exists between the two uploads, or what that relationship may entail. To support upgrades, certain aspects introduce package versioning. In one aspect, a package includes a sequence of versions, each of which includes a set of component references. An “Upload to Directory” button will move to the version. When the developer uploads a package version, the content of that version will no longer be editable: the developer will be able to look at what is in the package version, but will not be able to add or remove members. To make changes to the package, the developer will create a new version, and add the new items there. When the developer uploads the new version to the directory, subscribers are notified that an upgrade to the package is available. Each uploaded package version will correspond to a new container organization, which will include the metadata for that version and all preceding versions. A container organization in certain aspects, is a separate organization that only contains the contents of a package. All versions of the package will have the same version-invariant package identifier. Additionally, this identifier will be stable across organizations (the developer's organization, repository container organizations, and subscribing organizations) and across instances.
It is possible that during the development of the next major version of a package, the developer will need to release a patch to the current production version. To create the patch/minor version, the developer will create a new package version, place the new version between the current production version and the in-development major version, add items to the new version, and upload the patch to the directory. Subscribers will be notified of the available upgrade. Once a version has been uploaded, a new version cannot be created with a lower sequence number (i.e., once version 2 has been created, the developer cannot create a version between versions 1 and 2).
Because upgrades should be additive, any items added to the intervening minor version are automatically included in the next major version as well. When the developer uploads the minor version, any items that are duplicated in the in-development version will be removed, so that the list of items for a specific version includes just those items added in that version. The versioning functionality is independent of whether a package is managed or not. A developer could upload a new version of an unmanaged package. Although subscribers would not automatically be notified of the new version, and would not be able to upgrade, the directory can use the information to determine that the old version has been superseded. In one aspect, the new version is presented by default, but users can still see old versions. In another aspect, the old versions are not accessible at all.
Namespaces
The name of a component installed as part of an installed package could collide with the name of an existing component in the organization, and hence prevent the installation (this is true for managed and unmanaged packages). This collision can also occur at upgrade time: in the new version of a package, the developer may add a component with the same name as a custom object in one of the subscribing organizations. A namespace is an additional qualifier that increases the alternate index (non-id) uniqueness of a component. For example, if each custom entity in an organization must have a unique name, adding a namespace relaxes the uniqueness constraint on the name, and allows custom entities in the same organization but different namespaces to have the same name. The namespace may qualify fields other than the component name, e.g., the label, description, subject, etc. The namespaced field set is specific to each entity. To upload managed packages, a developer first enables namespacing. As part of this process, the developer's development organization will receive a unique namespace id and prefix. The developer may then update existing namespace-enabled components created in that organization.
Enabling namespacing for the organization will not impact existing namespacedenabled components: components created prior to obtaining a namespace will remain in the global namespace. A VI is provided, in one aspect, to allow a user to view namespaceenabled components in the global namespace, and to move those components into the organization namespace in bulk. New namespace-enabled components will default to the organization namespace, but can be moved to the global namespace. The namespace cannot be changed once the component has been uploaded in a managed package. The publication and installation processes preserve the namespace information. No two developers can create components in the same namespace, nor can the subscribing organization create components in a developer's namespace. This restriction eliminates the possibility for collisions at installation and upgrade.
Organizations that do not enable namespacing will continue to use the global namespace. Namespacing is separate from managed metadata. Managed metadata with unique alternate indexes must be namespaced, but the converse is not true: unmanaged metadata may also be namespaced. Unmanaged metadata uses whatever namespace is in place for the organization.
In one embodiment, the schema for each namespace-enabled entity is altered to include a namespace identifier, e.g., namespace_id, column. If uniqueness constraints are enforced at the database level, any alternate unique indexes can be altered to include the namespace_id column. In certain aspects, the indexes are not modified at the database level (for example, in certain aspects, there is one table for all customers); they include namespace as a column but the column is null if the entity doesn't have a namespace. If uniqueness constraints are enforced in Java, the code should be updated to allow the same name across namespaces. In one aspect, the namespace identifier include a value with a scope that is at least unique per developer organization. The namespace information, in certain aspects, should not be used for anything but making the namespaced field combinations unique. The 20 UI will use the package membership information to visually distinguish installed and local components of the same name.
In addition to the changes to each namespace-enabled entity, an additional change for managing namespaces at the organization level include adding a new Namespace entity and corresponding table to manage the namespace information: the namespace id, the id of the organization that owns the namespace, and the namespace prefix. in one aspect, the namespace id is automatically unique across all organizations. The namespace prefix must also be unique across all organizations.
Although the developer organization id and the namespace id will be coincident in subscribing organizations, the organization id should not be used as the namespace id. In some extreme situations, it may be necessary to manually transfer ownership of the namespace to another organization. Using the namespace id rather than the developer organization id minimizes the impact of this change.
Managed Metadata
In certain aspects, managed metadata includes two types of information: static information, and dynamic information based on package membership.
1. Managed Packages
In certain aspects, a package entity, e.g., application, includes a boolean ‘isManaged’ field. If the developer marks a package as managed, i.e., sets the boolean field appropriately, the package becomes upgradeable. Once the package has been uploaded, the ‘isManaged’ field cannot be turned off, or reset, and the developer cannot make destructive changes to the package contents.
2. Managed Components
In a developer/publisher organization, a component is managed if it is part of at least one managed package which has been uploaded to the application directory. In a subscribing organization, a component is managed if it is part of an installed managed package. In a developer/publisher organization, when a component changes from unmanaged to managed (either because the developer has added the component to a managed package, or because the developer has changed the package from unmanaged to managed), the system will enforce additional instance requirements. These requirements need to be satisfied prior to upload. These manageability requirements vary by type. The most common instance requirement for manageability is namespacing. Once a managed component has been uploaded (or, for the subscribing organization, installed from the directory), the framework restricts the changes that the user can make to that component. These restrictions guarantee that the package can be upgraded without conflicts and without breaking dependent functionality. The specific restrictions depend on the entity type, and also vary between the developer's organization and subscribing organizations.
Manageable State
The manageable state of a component will be determined via a secondary query to one or more of the package, version, and member tables. An example query might look like the following:
In certain aspects, the manageable state will be exposed in Java (e.g., using a data dictionary and related controller code) as an enum with the following values: managed-uploaded: the component is managed and owned by this organization (ie this is the publishing organization). managed-not-uploaded: the component is owned by this organization and is in a managed package, but has not been uploaded. managed-installed: the component is managed and owned by another organization (Le., the component is part of a managed package installed from the directory). unmanaged: the component is unmanaged.
In the developer/publishing organization, setup must be changed to prevent the developer from uploading an upgrade that could break the functionality of the package. Examples of breaking changes include: deleting any managed component, especially a custom object or custom field, and changing the API name of a custom object or custom field. The restrictions are enforced, in certain aspects, when the developer attempts to upload the upgraded package version. In one aspect, the restrictions are enforced within each entity VI so that the developer never makes the invalid changes (especially since some changes may be difficult or impossible to revert).
In the subscribing organization, setup must be changed to prevent the subscriber from making changes to managed components that could cause conflicts with local customizations, new packages, and upgrades to existing packages. Additionally, setup should prevent the subscriber from making changes that could break the functionality of the package, such as external integrations. In one aspect, these restrictions are enforced in each entity VI via display changes (separating local customizations and published content, disabling links and buttons, etc.) and error messages.
Certain enhancements to the entity and entity-field information described below provide the information necessary to implement these restrictions. In one aspect, each entity includes an attribute, with the following possible values:
packageable: the entity is packageable, but not upgradeable.
manageable: the entity is packageable, and may be upgraded in a managed package.
immutable: the entity is packageable, and may be upgraded in a managed package; however neither the developer nor subscribers can change any non-internal fields.
not specified: the entity is not packageable.
Additionally, in one aspect, for each manageable entity, each attribute will include an attribute that determines what changes if any can be made to that field if the component is managed. Categories of field manageability according to one aspect include:
Subscriber-controlled: the installation process sets the field to the default value specified in the data dictionary. The subscriber may change the value locally. The upgrade process ignores the field, and preserves any subscriber changes.
Overrideable: the developer specifies an initial value, and may modify the value in an upgrade. The subscriber may also change the value locally, and may revert to the most recent published value at any time.
Publisher-controlled: the developer specifies the value, and may modify the value in an upgrade. The subscribing organization cannot modify or override the value.
Immutable: once uploaded, neither the developer nor the subscribing organization can modify the value.
Internal: the field is system-controlled. Neither the developer nor the subscriber can explicitly change the value. It may be set either at installation or as part of usage.
Compound: the field includes multiple columns or flags, with a combination of different manageabilities.
For bit vector fields, manageability may be specified either for the field as a whole, or for each bit vector item. The attribute for bit vector fields and items can be subscribercontrolled, publisher-controlled, immutable, or internal, as described above. Bit vector items and fields should not be override able, because, in certain aspects, the overrideable behavior requires ternary logic (truelfalseldefault). If each bit vector item specifies its manageability, the field manageability is compound. Multi-column fields can be handled in a similar fashion. Unlike bit vector fields, overrideable columns or multi-column fields are feasible.
Overrideable fields allow the subscribing organization to make changes to field values while retaining the original published values. Upgrades from the subscriber will update the published values but should not change any overridden values. The subscriber can revert back to the latest published value. In certain aspects, overrideable fields can be stored in a general override table, in extra columns in a base table, or in an entity specific override table, in an override entity.
In certain aspects, if an entity has an attribute value of packageable, all of its fields are automatically subscriber-controlled, and if an entity has an attribute value of immutable, all of its fields are automatically immutable. In certain aspects, a foreign key field to an unmanageable entity is automatically subscriber-controlled. Further, if the foreign key domain is not packageable, the value is automatically set to the empty key on upload. In certain aspects, the unique id field for an entity is automatically immutable, and if an entity has an attribute value of manageable, its fields default to publisher-controlled.
As mentioned above, the setup area should behave differently for managed components. Distinct behavioral groupings include: locally-created components that are a part of at least one managed, uploaded package; managed components installed from the directory; and local customizations, not-yet-uploaded components, and unmanaged components from other developers. In certain aspects, the attributes of an entity will control the behavioral details. However, in order for the UI to determine how a particular component should behave, it should first obtain package membership information for the component, including, for example, the packages containing the component, whether any of the packages are marked as ‘managed’, if the package is managed, whether the current organization owns the package, and if the current organization owns the managed package, whether the package has been uploaded.
Promoting an entity from unmanageable to manageable presents an interesting problem. Developers may have released unmanaged instances of the entity in managed packages, and these components (as is the case with any unmanaged component) may have been modified in subscribing organizations. The developer must either convert the components to managed, or remove them from the package in the next version. If the developer converts the components to managed, the subscriber will have to abandon or reimplement their changes. To avoid this problem, newly packageable entities should not be released with an initial attribute value of unmanageable if the eventual goal is to have them be manageable. Instead, the new entity should be immutable. Managed instances of immutable entities cannot be modified by either the developer or subscribers. This restriction includes changing the component lifecycle status to ‘deployed’, activating the component, etc. To use the component, subscribers should create a clone. Because the developer cannot modify the component, the upgrade process for the entity should be easier to implement. Because the subscriber cannot modify the component, when the entity ultimately changes from immutable to manageable, there cannot be any conflicts.
A similar problem exists with regard to field manageability_ A change from anything less restrictive than publisher-controlled to publisher-controlled or a more restrictive level would result in the loss of any subscriber changes. Increasing the permissiveness is=acceptable, as is subscriber-controlled to overrideable.
Resource Limitations
Resource limitations such as the maximum number of custom objects for the organization, the maximum number of custom fields per object, etc. can cause problems at upgrade time, because the developer may have added more components than a subscriber has remaining. Because the upgrade model in certain aspects is pull rather than push, there is no need to address this problem. If an upgrade fails due to a resource limitation, the subscriber can delete other components or move to the next edition, and try the upgrade again. Additionally, in certain aspects subscribers may have the option of remaining on an unmanaged version of the package. Limits serve multiple purposes, roughly defined by the following categories. A particular limit may serve multiple purposes.
Complexity: the limit exists because removing it would be significantly more complex to implement, often because of a similar limitation in an underlying system.
Performance: allowing the organization to exceed the limit would degrade runtime performance.
Usability: allowing the organization to exceed the limit would make the application confusing, or unwieldy.
Business: the limit exists as a differentiator between editions or products, as incentive to upgrade.
One option is to lift all resource limitation, and allow an organization to exceed other limits via directory upgrades (and possibly installs). If this is not feasible, preallocation may be implemented.
Upgrade Mechanism
To make an upgrade available, in one aspect, some or all of the following actions may occur:
When the upload of the previous package version completes, the system automatically creates a new version with an appropriate internal version sequence identifier.
The developer either modifies previously uploaded components, adds new components, or both. The developer interacts with the package. Internally, the system associates these changes with the new version.
The developer initiates the upload of the new version to the directory via a wizard.
During the upload process, the developer may provide a descriptive version label, in addition to the internal sequence identifier.
As part of the upload process, the system runs a spidering algorithm to find any new dependencies and verify referential integrity. The system also verifies that all new components adhere to the requirements for manageability, and that all modified components adhere to the requirements for upgrade. To complete the upload, the developer may need to resolve any validation errors.
Prior to completing the upload, the developer may add or remove new components.
If the developer has modified a component since the previous version was uploaded, the system will update the package_version_id for the component to the id of the version being uploaded. Because each upload includes components in the current version and all previous versions, and because the previous version of a modified component no longer exists in the publishing organization, the developer cannot control whether modifications to a previously uploaded component are included in the next version.
Upgrading an Organization
In certain aspects, the upgrade process performs some or all of the following steps:
Prior to modifying any data in the organization, check for any issues requiring human intervention, such as resource limitations, organization permissions, etc. If such issues exist, the user is informed and the upgrade is failed/terminated.
Pre-load project membership and id mapping information.
Iterate over the project content, and process each member appropriately, according to its manageability and whether the component exists in the subscribing organization.
For managed components, the package version information can be used to determine whether a particular component exists in the subscribing organization. If the subscribing organization has version N of the package, it should have all components in version N and previous versions. The set of new components for version M would then be those components added in versions N+1 to version M. However, in one aspect, for simplicity and robustness, the upgrade process determines whether a component exists by looking in the subscribing organization.
In certain aspects, new managed components are inserted, with fields initialized as follows:
publisher-controlled fields are set to the published value.
subscriber-controlled fields are set to the default value specified in the data dictionary.
overrideable fields are set to the published value in the base table.
immutable fields are set to the published value.
internal fields are ignored by the upgrade process, but may be set indirectly via internal logic.
In certain aspects, existing managed components are updated according to the field level manageability for the entity as follows:
publisher-controlled fields are updated unconditionally.
subscriber-controlled fields are ignored.
overrideable fields are updated in the base table. Subscriber changes will be preserved in the override table.
immutable fields are ignored.
internal fields are ignored by the upgrade process, but may be modified indirectly via internal logic.
If the entity manageability attribute is set to packageable or immutable, the upgrade process ignores the entire component.
U.S. patent application Ser. No. 11/530,394 filed Sep. 8, 2006, which is incorporated by reference herein, discloses additional aspects and features regarding application package creation and exporting.
While the invention has been described by way of example and in terms of the specific embodiments, it is to be understood that the invention is not limited to the disclosed embodiments. To the contrary, it is intended to cover various modifications and similar arrangements as would be apparent to those skilled in the art. Therefore, the scope of the appended claims should be accorded the broadest interpretation so as to encompass all such modifications and similar arrangements.
This application is a continuation of application Ser. No. 15/132,128 filed Apr. 18, 2016 (now U.S. Pat. No. 9,870,218 issued Jan. 16, 2018), which is a continuation of application Ser. No. 14/094,738 filed Dec. 2, 2013 (now U.S. Pat. No. 9,348,576 issued May 24, 2016), which is a divisional of application Ser. No. 11/866,911 filed Oct. 3, 2007 (now U.S. Pat. No. 8,601,467 issued Dec. 3, 2013), which claims the benefit of Provisional Application No. 60/828,016 filed Oct. 3, 2006, which are hereby incorporated by reference.
| Number | Name | Date | Kind |
|---|---|---|---|
| 5577188 | Zhu | Nov 1996 | A |
| 5608872 | Schwartz et al. | Mar 1997 | A |
| 5649104 | Carleton et al. | Jul 1997 | A |
| 5671412 | Christiano | Sep 1997 | A |
| 5715403 | Stefik | Feb 1998 | A |
| 5715450 | Ambrose et al. | Feb 1998 | A |
| 5761419 | Schwartz et al. | Jun 1998 | A |
| 5805889 | Van De Vanter | Sep 1998 | A |
| 5819038 | Carleton et al. | Oct 1998 | A |
| 5821937 | Tonelli et al. | Oct 1998 | A |
| 5831610 | Tonelli et al. | Nov 1998 | A |
| 5873096 | Lim et al. | Feb 1999 | A |
| 5918159 | Fomukong et al. | Jun 1999 | A |
| 5963953 | Cram et al. | Oct 1999 | A |
| 6092083 | Brodersen et al. | Jul 2000 | A |
| 6161149 | Achacoso et al. | Dec 2000 | A |
| 6169534 | Raffel et al. | Jan 2001 | B1 |
| 6178425 | Brodersen et al. | Jan 2001 | B1 |
| 6189011 | Lim et al. | Feb 2001 | B1 |
| 6192518 | Neal | Feb 2001 | B1 |
| 6216135 | Brodersen et al. | Apr 2001 | B1 |
| 6233617 | Rothwein et al. | May 2001 | B1 |
| 6266669 | Brodersen et al. | Jul 2001 | B1 |
| 6295530 | Ritchie et al. | Sep 2001 | B1 |
| 6324568 | Diec | Nov 2001 | B1 |
| 6324693 | Brodersen et al. | Nov 2001 | B1 |
| 6336137 | Lee et al. | Jan 2002 | B1 |
| D454139 | Feldcamp | Mar 2002 | S |
| 6367077 | Brodersen et al. | Apr 2002 | B1 |
| 6393605 | Loomans | May 2002 | B1 |
| 6405220 | Brodersen et al. | Jun 2002 | B1 |
| 6434550 | Warner et al. | Aug 2002 | B1 |
| 6446089 | Brodersen et al. | Sep 2002 | B1 |
| 6535909 | Rust | Mar 2003 | B1 |
| 6549908 | Loomans | Apr 2003 | B1 |
| 6553563 | Ambrose et al. | Apr 2003 | B2 |
| 6560461 | Fomukong et al. | May 2003 | B1 |
| 6567107 | Stannard | May 2003 | B1 |
| 6574635 | Stauber et al. | Jun 2003 | B2 |
| 6577726 | Huang et al. | Jun 2003 | B1 |
| 6601087 | Zhu et al. | Jul 2003 | B1 |
| 6604117 | Lim et al. | Aug 2003 | B2 |
| 6604128 | Diec | Aug 2003 | B2 |
| 6609150 | Lee et al. | Aug 2003 | B2 |
| 6621834 | Scherpbier et al. | Sep 2003 | B1 |
| 6654032 | Zhu et al. | Nov 2003 | B1 |
| 6665648 | Brodersen et al. | Dec 2003 | B2 |
| 6665655 | Warner et al. | Dec 2003 | B1 |
| 6684438 | Brodersen et al. | Feb 2004 | B2 |
| 6711565 | Subramaniam et al. | Mar 2004 | B1 |
| 6724399 | Katchour et al. | Apr 2004 | B1 |
| 6728702 | Subramaniam et al. | Apr 2004 | B1 |
| 6728960 | Loomans | Apr 2004 | B1 |
| 6732095 | Warshaysky et al. | May 2004 | B1 |
| 6732100 | Brodersen et al. | May 2004 | B1 |
| 6732111 | Brodersen et al. | May 2004 | B2 |
| 6754681 | Brodersen et al. | Jun 2004 | B2 |
| 6763351 | Subramaniam et al. | Jul 2004 | B1 |
| 6763501 | Zhu et al. | Jul 2004 | B1 |
| 6768904 | Kim | Jul 2004 | B2 |
| 6772229 | Achacoso et al. | Aug 2004 | B1 |
| 6782383 | Subramaniam et al. | Aug 2004 | B2 |
| 6789215 | Rupp et al. | Sep 2004 | B1 |
| 6804330 | Jones et al. | Oct 2004 | B1 |
| 6826565 | Ritchie et al. | Nov 2004 | B2 |
| 6826582 | Chatterjee et al. | Nov 2004 | B1 |
| 6826745 | Coker et al. | Nov 2004 | B2 |
| 6829655 | Huang et al. | Dec 2004 | B1 |
| 6842748 | Warner et al. | Jan 2005 | B1 |
| 6850895 | Brodersen et al. | Feb 2005 | B2 |
| 6850949 | Warner et al. | Feb 2005 | B2 |
| 6983371 | Hurtado et al. | Jan 2006 | B1 |
| 7003767 | Larkin | Feb 2006 | B2 |
| 7062502 | Kesler | Jun 2006 | B1 |
| 7069231 | Cinarkaya et al. | Jun 2006 | B1 |
| 7069293 | Cox et al. | Jun 2006 | B2 |
| 7069497 | Desai | Jun 2006 | B1 |
| 7107589 | Tal et al. | Sep 2006 | B1 |
| 7181758 | Chan | Feb 2007 | B1 |
| 7210143 | Or et al. | Apr 2007 | B2 |
| 7289976 | Kihneman et al. | Oct 2007 | B2 |
| 7340411 | Cook | Mar 2008 | B2 |
| 7356482 | Frankland et al. | Apr 2008 | B2 |
| 7392522 | Murray et al. | Jun 2008 | B2 |
| 7401094 | Kesler | Jul 2008 | B1 |
| 7412455 | Dillon | Aug 2008 | B2 |
| 7508789 | Chan | Mar 2009 | B2 |
| 7603483 | Psounis et al. | Oct 2009 | B2 |
| 7620655 | Larsson et al. | Nov 2009 | B2 |
| 7698160 | Beaven et al. | Apr 2010 | B2 |
| 7765540 | McCollum et al. | Jul 2010 | B2 |
| 7774366 | Fisher et al. | Aug 2010 | B2 |
| 7779039 | Weissman et al. | Aug 2010 | B2 |
| 7779475 | Jakobson et al. | Aug 2010 | B2 |
| 7788662 | Haselden et al. | Aug 2010 | B2 |
| 7851004 | Hirao et al. | Dec 2010 | B2 |
| 7856631 | Brodkorb et al. | Dec 2010 | B2 |
| 7865888 | Qureshi et al. | Jan 2011 | B1 |
| 7949684 | Brooks et al. | May 2011 | B2 |
| 7996814 | Qureshi et al. | Aug 2011 | B1 |
| 8014943 | Jakobson | Sep 2011 | B2 |
| 8015495 | Achacoso et al. | Sep 2011 | B2 |
| 8032297 | Jakobson | Oct 2011 | B2 |
| 8060855 | Hegde et al. | Nov 2011 | B2 |
| 8060871 | Bernabeu-Auban et al. | Nov 2011 | B2 |
| 8065594 | Limberg | Nov 2011 | B2 |
| 8069184 | Becker et al. | Nov 2011 | B2 |
| 8073850 | Hubbard et al. | Dec 2011 | B1 |
| 8082301 | Ahlgren et al. | Dec 2011 | B2 |
| 8095413 | Beaven | Jan 2012 | B1 |
| 8095594 | Beaven et al. | Jan 2012 | B2 |
| 8176484 | Sero et al. | May 2012 | B2 |
| 8209308 | Rueben et al. | Jun 2012 | B2 |
| 8209333 | Hubbard et al. | Jun 2012 | B2 |
| 8239598 | Figge | Aug 2012 | B1 |
| 8245221 | Czeisler et al. | Aug 2012 | B2 |
| 8255362 | Johnson et al. | Aug 2012 | B2 |
| 8275836 | Beaven et al. | Sep 2012 | B2 |
| 8316364 | Stein | Nov 2012 | B2 |
| 8418168 | Tyhurst et al. | Apr 2013 | B2 |
| 8438559 | Naslaysky et al. | May 2013 | B2 |
| 8457545 | Chan | Jun 2013 | B2 |
| 8484111 | Frankland et al. | Jul 2013 | B2 |
| 8490025 | Jakobson et al. | Jul 2013 | B2 |
| 8504945 | Jakobson et al. | Aug 2013 | B2 |
| 8510045 | Rueben et al. | Aug 2013 | B2 |
| 8510664 | Rueben et al. | Aug 2013 | B2 |
| 8566301 | Rueben et al. | Oct 2013 | B2 |
| 8589903 | Felts | Nov 2013 | B2 |
| 8601467 | Hofhansl et al. | Dec 2013 | B2 |
| 8635611 | Criddle et al. | Jan 2014 | B2 |
| 8645939 | Felts | Feb 2014 | B2 |
| 8646103 | Jakobson et al. | Feb 2014 | B2 |
| 8667482 | Bernardi | Mar 2014 | B2 |
| 8752044 | Motta et al. | Jun 2014 | B2 |
| 8756275 | Jakobson | Jun 2014 | B2 |
| 8769004 | Jakobson | Jul 2014 | B2 |
| 8769017 | Jakobson | Jul 2014 | B2 |
| 8799298 | Weissman | Aug 2014 | B2 |
| 9230068 | Hess | Jan 2016 | B2 |
| 9256425 | Baird et al. | Feb 2016 | B2 |
| 9262366 | Lenzmeier | Feb 2016 | B2 |
| 9348576 | Hofhansl et al. | May 2016 | B2 |
| 10162618 | Fors | Dec 2018 | B2 |
| 20010044791 | Richter et al. | Nov 2001 | A1 |
| 20020042892 | Gold | Apr 2002 | A1 |
| 20020072951 | Lee et al. | Jun 2002 | A1 |
| 20020082892 | Raffel et al. | Jun 2002 | A1 |
| 20020099726 | Crudele | Jul 2002 | A1 |
| 20020129352 | Brodersen et al. | Sep 2002 | A1 |
| 20020133392 | Angel et al. | Sep 2002 | A1 |
| 20020140731 | Subramaniam et al. | Oct 2002 | A1 |
| 20020143997 | Huang et al. | Oct 2002 | A1 |
| 20020162090 | Parnell et al. | Oct 2002 | A1 |
| 20020165742 | Robins | Nov 2002 | A1 |
| 20020184618 | Bala et al. | Dec 2002 | A1 |
| 20030004971 | Gong et al. | Jan 2003 | A1 |
| 20030018705 | Chen et al. | Jan 2003 | A1 |
| 20030018830 | Chen et al. | Jan 2003 | A1 |
| 20030066031 | Laane | Apr 2003 | A1 |
| 20030066032 | Ramachandran et al. | Apr 2003 | A1 |
| 20030066065 | Larkin | Apr 2003 | A1 |
| 20030069936 | Warner et al. | Apr 2003 | A1 |
| 20030070000 | Coker et al. | Apr 2003 | A1 |
| 20030070004 | Mukundan et al. | Apr 2003 | A1 |
| 20030070005 | Mukundan et al. | Apr 2003 | A1 |
| 20030074418 | Coker | Apr 2003 | A1 |
| 20030120675 | Stauber et al. | Jun 2003 | A1 |
| 20030151633 | George et al. | Aug 2003 | A1 |
| 20030159136 | Huang et al. | Aug 2003 | A1 |
| 20030177397 | Samman | Sep 2003 | A1 |
| 20030187921 | Diec | Oct 2003 | A1 |
| 20030189600 | Gune et al. | Oct 2003 | A1 |
| 20030204427 | Gune et al. | Oct 2003 | A1 |
| 20030206192 | Chen et al. | Nov 2003 | A1 |
| 20030225730 | Warner et al. | Dec 2003 | A1 |
| 20040001092 | Rothwein et al. | Jan 2004 | A1 |
| 20040003266 | Moshir et al. | Jan 2004 | A1 |
| 20040010489 | Rio | Jan 2004 | A1 |
| 20040015981 | Coker et al. | Jan 2004 | A1 |
| 20040027388 | Berg et al. | Feb 2004 | A1 |
| 20040039746 | Bracha | Feb 2004 | A1 |
| 20040068721 | O'Neill et al. | Apr 2004 | A1 |
| 20040073903 | Melchione | Apr 2004 | A1 |
| 20040107125 | Guheen et al. | Jun 2004 | A1 |
| 20040128001 | Levin et al. | Jul 2004 | A1 |
| 20040153416 | Fujimoto | Aug 2004 | A1 |
| 20040153658 | Gunyakti | Aug 2004 | A1 |
| 20040181773 | Mortensen et al. | Sep 2004 | A1 |
| 20040186860 | Lee et al. | Sep 2004 | A1 |
| 20040193510 | Catahan et al. | Sep 2004 | A1 |
| 20040194079 | Nguyen | Sep 2004 | A1 |
| 20040199489 | Barnes-Leon et al. | Oct 2004 | A1 |
| 20040199536 | Barnes Leon et al. | Oct 2004 | A1 |
| 20040199543 | Braud et al. | Oct 2004 | A1 |
| 20040249854 | Barnes-Leon et al. | Dec 2004 | A1 |
| 20040260534 | Pak et al. | Dec 2004 | A1 |
| 20040260659 | Chan et al. | Dec 2004 | A1 |
| 20040267590 | Clark et al. | Dec 2004 | A1 |
| 20040268299 | Lei et al. | Dec 2004 | A1 |
| 20050049973 | Read et al. | Mar 2005 | A1 |
| 20050050555 | Exley et al. | Mar 2005 | A1 |
| 20050055687 | Mayer | Mar 2005 | A1 |
| 20050065925 | Weissman et al. | Mar 2005 | A1 |
| 20050091098 | Brodersen et al. | Apr 2005 | A1 |
| 20050149545 | Zenz | Jul 2005 | A1 |
| 20050172284 | Dandekar | Aug 2005 | A1 |
| 20050187935 | Kumar | Aug 2005 | A1 |
| 20050223022 | Weissman et al. | Oct 2005 | A1 |
| 20060010419 | Haselden | Jan 2006 | A1 |
| 20060021019 | Hinton et al. | Jan 2006 | A1 |
| 20060021065 | Kamperman et al. | Jan 2006 | A1 |
| 20060026585 | Haselden | Feb 2006 | A1 |
| 20060031547 | Tsui et al. | Feb 2006 | A1 |
| 20060075001 | Canning | Apr 2006 | A1 |
| 20060123414 | Fors et al. | Jun 2006 | A1 |
| 20060200419 | Cook | Sep 2006 | A1 |
| 20060206449 | Fletcher | Sep 2006 | A1 |
| 20060206834 | Fisher et al. | Sep 2006 | A1 |
| 20060235715 | Abrams et al. | Oct 2006 | A1 |
| 20060282440 | Fletcher et al. | Dec 2006 | A1 |
| 20060282815 | Yodaiken | Dec 2006 | A1 |
| 20060294506 | Dengler | Dec 2006 | A1 |
| 20070038489 | Kayahara et al. | Feb 2007 | A1 |
| 20070088741 | Brooks et al. | Apr 2007 | A1 |
| 20070169079 | Keller et al. | Jul 2007 | A1 |
| 20070169081 | Zhao et al. | Jul 2007 | A1 |
| 20070226687 | Fallen-Bailey | Sep 2007 | A1 |
| 20070240147 | Bernabeu-Auban | Oct 2007 | A1 |
| 20080071689 | Tabet | Mar 2008 | A1 |
| 20080201701 | Hofhansl et al. | Aug 2008 | A1 |
| 20080249972 | Dillon | Oct 2008 | A1 |
| 20090007162 | Sheehan | Jan 2009 | A1 |
| 20090063415 | Chatfield et al. | Mar 2009 | A1 |
| 20090100342 | Jakobson | Apr 2009 | A1 |
| 20090144727 | Felts | Jun 2009 | A1 |
| 20090177744 | Marlow et al. | Jul 2009 | A1 |
| 20110197287 | Hess et al. | Aug 2011 | A1 |
| 20110218958 | Warshaysky et al. | Sep 2011 | A1 |
| 20110247051 | Bulumulla et al. | Oct 2011 | A1 |
| 20120042218 | Cinarkaya et al. | Feb 2012 | A1 |
| 20120233137 | Jakobson et al. | Sep 2012 | A1 |
| 20120290407 | Hubbard et al. | Nov 2012 | A1 |
| 20130212497 | Zelenko et al. | Aug 2013 | A1 |
| 20130247216 | Cinarkaya et al. | Sep 2013 | A1 |
| 20140173582 | Hofhansl et al. | Jun 2014 | A1 |
| Number | Date | Country |
|---|---|---|
| 2008042984 | Apr 2008 | WO |
| Entry |
|---|
| Sapuntzakis et al., Virtual Appliances for Deploying and Maintaining Software, 15 pages (Year: 2003). |
| U.S. Appl. No. 11/866,911—Office Action dated May 5, 2011, 12 pages. |
| U.S. Appl. No. 11/866,911—Response to Office Action dated May 5, 2011 filed Jul. 28, 2011, 11 pages. |
| U.S. Appl. No. 11/866,911—Final Office Action dated Oct. 7, 2011, 9 pages. |
| U.S. Appl. No. 11/866,911—Response to Final Office Action dated Oct. 7, 2011 filed Jan. 6, 2012, 10 pages. |
| U.S. Appl. No. 11/866,911—Office Action dated Nov. 5, 2012, 8 pages. |
| U.S. Appl. No. 11/866,911—Response to Office Action dated Nov. 5, 2012 filed May 6, 2013, 11 pages. |
| U.S. Appl. No. 11/866,911—Notice of Allowance dated Jul. 25, 2013, 12 pages. |
| U.S. Appl. No. 14/094,738, Response to Office Action dated Dec. 3, 2014 filed Mar. 3, 2015, 10 pages. |
| U.S. Appl. No. 14/094,738, Response to Final Office Action dated Apr. 22, 2015, filed Aug. 24, 2015, 13 pages. |
| U.S. Appl. No. 14/094,738—Response to Office Action dated Sep. 30, 2015 filed Dec. 30, 2015, 11 pages. |
| U.S. Appl. No. 14/094,738—Notice of Allowance dated Jan. 25, 2016, 8 pages. |
| U.S. Appl. No. 15/132,128—Ex Parte Quayle Action dated Jun. 6, 2017, 5 pages. |
| U.S. Appl. No. 15/132,128—Notice of Allowance dated Sep. 11, 2017, 32 pages. |
| U.S. Appl. No. 15/132,128—Response to Ex Parte Quayle Action dated Jun. 6, 2017 filed Aug. 3, 2017, 10 pages. |
| Hebert et al., “A new collaborative software package: TeamSpace at Stanford University”, Nov. 2005, 4 pages. |
| Heiner et al., “Secure Software Installation in a Mobile Environment”, Jul. 2007, 2 pages. |
| Pechtchanski et al., Immutability specification and its applications, Nov. 2010, 10 pages. |
| Tschantz et al., Javan: adding reference immutability to Java, Oct. 2005, 20 pages. |
| Gummadi et al., Measurement, modeling, and analysis of a peer-to-peer file-sharing workload, Dec. 2003, 16 pages. |
| PCT/US06/35207, International Search Report, dated Nov. 26, 2007, 1 page. |
| U.S. Appl. No. 11/866,898, filed Oct. 3, 2007, for Ron Hess et al. |
| U.S. Appl. No. 13/016,941, Final Office Action, dated Jun. 21, 2012, 19 pages (non HBW). |
| U.S. Appl. No. 13/016,941, Non-Final Office Action, dated Mar. 9, 2012, 15 pages (non HBW). |
| U.S. Appl. No. 11/866,898, Final Office Action, dated Sep. 2011, 27 pages (non HBW). |
| U.S. Appl. No. 11/866,898, Non Final Office Action, dated Feb. 23, 2011, 36 pages (non HBW). |
| U.S. Appl. No. 11/866,898, Non Final Office Action, dated Oct. 8, 2014, 23 pages (non HBW). |
| U.S. Appl. No. 14/094,738, Non Final Office Action, dated Dec. 3, 2014, 29 pages. |
| U.S. Appl. No. 14/094,738, Final Office Action, dated Apr. 22, 2015, 14 pages. |
| U.S. Appl. No. 14/094,738, Final Office Action, dated Sep. 30, 2015, 16 pages. |
| Santinelli, Robert, et al., “Installing and Configuring Application Software on the LHC Computing Grid”, IEEE, 2005, 8 pages. |
| Guo, Chang Jie, et al., “A Framework for Native Multi-Tenancy Application Development and Management”, IEEE, 2007, 8 pages. |
| Shwartz, Larisa, et al., “IT Service Provider's Multi-Customer and Multi-Tenant Environments”, IEEE, 2007, 8 pages. |
| International Preliminary Report on Patentability for Application No. PCT/US2007/080345, dated Apr. 7, 2009, 4 pages. |
| International Search Report and Written Opinion for Application No. PCT/US2007/080345, dated Jul. 3, 2008, 4 pages. |
| Requirement for Restriction/Election from U.S. Appl. No. 11/866,911, dated Feb. 23, 2011, 5 pages. |
| Number | Date | Country | |
|---|---|---|---|
| 20170123785 A1 | May 2017 | US |
| Number | Date | Country | |
|---|---|---|---|
| 60828016 | Oct 2006 | US |
| Number | Date | Country | |
|---|---|---|---|
| Parent | 11866911 | Oct 2007 | US |
| Child | 14094738 | US |
| Number | Date | Country | |
|---|---|---|---|
| Parent | 15132128 | Apr 2016 | US |
| Child | 15404018 | US | |
| Parent | 14094738 | Dec 2013 | US |
| Child | 15132128 | US |
