WO2008042984A2 - Procédés et systèmes pour mettre à jour et installer des ensembles d'application sur une plate-forme d'application - Google Patents

Procédés et systèmes pour mettre à jour et installer des ensembles d'application sur une plate-forme d'application Download PDF

Info

Publication number
WO2008042984A2
WO2008042984A2 PCT/US2007/080345 US2007080345W WO2008042984A2 WO 2008042984 A2 WO2008042984 A2 WO 2008042984A2 US 2007080345 W US2007080345 W US 2007080345W WO 2008042984 A2 WO2008042984 A2 WO 2008042984A2
Authority
WO
WIPO (PCT)
Prior art keywords
application
package
subscriber
developer
version
Prior art date
Application number
PCT/US2007/080345
Other languages
English (en)
Other versions
WO2008042984A3 (fr
Inventor
Lars Hofhansl
Nathan Jensen-Horne
Scott Hansma
Steven Tamm
Craig Weissman
Ron Hess
David Brooks
Amy Palke
Evan Moses
Original Assignee
Salesforce.Com, Inc.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Salesforce.Com, Inc. filed Critical Salesforce.Com, Inc.
Publication of WO2008042984A2 publication Critical patent/WO2008042984A2/fr
Publication of WO2008042984A3 publication Critical patent/WO2008042984A3/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/60—Software deployment
    • G06F8/65—Updates

Definitions

  • 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 and managing licenses and license objects.
  • 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.
  • 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 can not be broken by the local administrators; and/or enable developers/publishers to provide updates to applications which have been installed by various users/subscribers.
  • application packages may be uploaded to a directory by developing users (developers) for installation by subscribing users (subscribers).
  • 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.
  • 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
  • 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.
  • a "control" field is provided to identify whether an object may be modified by the developer and/or the subscriber.
  • 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.
  • a method 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.
  • 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.
  • 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.
  • a method 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.
  • a method 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.
  • 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.
  • 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.
  • One method embodiment typically includes associating a license manager application (“LMA") with an application installed to the application platform by a developer, notifying a license manager to which the license manager application is installed of the installation of the application to the application platform, and managing subscriber access to the application using the license manager application.
  • LMA license manager application
  • One embodiment provides a method for managing license objects to applications in an application platform that includes performing a verification process to determine if a manifest violates a set of provider controlled rules.
  • a version control step in an LMA may be validated to determine whether a user selected version is an upgrade or an extension and managing necessary prerequisite package installations.
  • a license object may be associated with a user and a package.
  • the license package may be installed and associated with an LMA such that an application installed to the application platform by a developer and downloaded by a subscriber matches the license on either a per package basis or on a per object basis.
  • a set of provider defined rules may be applied to those packages that are managed.
  • Another embodiment provides a method for managing license objects to applications in a multi-tenant application platform that includes installing a license manager organization ("LMO") to obtain a proxy user in a partner organization.
  • LMO license manager organization
  • the proxy user has authority to disable the package and appears to the subscriber as editing a record in a multi- tenant application platform.
  • An object edit step allows the proxy user to edit package objects, version objects, and licensee objects in a database schema wherein the proxy user determines status changes as either active or disabled and implements notification of a new or upgraded version of a custom application being uploaded to the application services platform application exchange.
  • licensee objects comprise license properties including package version, license status, install date, the number of seats, formula for the number of seats, expiration date and formula, the proxy user, account and contact information.
  • all license property, package and version objects are updated across the subscriber instance of the multi- tenant application platform in the network when a package is installed, hi a separate aspect of the replication step, all updates of the subscriber instance are associated with the multi- tenant application platform across multiple time zones during a replication of the database schema.
  • the replication is performed asynchronously to achieve schema updates when a subscriber organization instance is offline for maintenance.
  • Another embodiment provides a computer readable medium that implements a method for managing license objects to applications in a multi-tenant application platform.
  • One embodiment includes a program code for associating an LMA with an application installed to the application platform by a developer.
  • Another aspect of the application provides program code for notifying a license manager to which the license manager application is installed of the installation of the application to the application platform.
  • An additional aspect of the application provides program code for managing subscriber access to the application using the license manager application.
  • a further embodiment includes a method for providing a bootstrap sequence when a license management application is created to install into the LMO.
  • an LMA is created and associated with an LMO in a host developer organization.
  • the initial step is next verified by making a check call to the organization to make sure that it has the LMA already installed.
  • the host developer uploads the LMA into the application exchange directory.
  • the next step in the bootstrap sequence determines if the package exists when an LMA is downloaded into the LMO. If it does not exist, a message servers creates the package.
  • the message server creates the package by downloading an LMA associated with the LMO and creating a package license in the LMO. Once the package is associated with both the LMA and LMO, an installation sequence is executed to complete the bootstrap sequence.
  • a method for managing license objects to applications in a multi-tenant application platform.
  • the method includes installing an LMO to obtain a proxy user in a partner organization.
  • the proxy user has authority to disable the package and appears to the subscriber as editing a record in a multi-tenant application platform.
  • the proxy user may be provided with the capability to edit package objects, version objects, and licensee objects in a database schema.
  • the proxy user has the ability to track three messages including a version upload, a package installation upgrade, and a package uninstallation. During a package uninstallation tracking step, a message is sent to the LMO and the status of the license object is changes to uninstalled.
  • the proxy user determines status changes as in either an active or disabled mode and implements notification of a new or upgraded version of a custom application being uploaded to the application services platform, application exchange.
  • the licensee objects may include license properties, such as for example and without limitation, package version, license status, install date, the number of seats, formula for the number of seats, expiration date and formula, the proxy user, account and contact information. License properties, package and version object updates may be replicated across the subscriber instance of the multi-tenant application platform in the network when a package is installed, upgraded or uninstalled in a cross instance, two phase commit process aspect of the embodiment.
  • two phase commit process a record displayed is verified to belong in the database table to gain access to the package update data for the subscriber instance, hi another aspect of the embodiment, updates of the subscriber instance associated with the multi -tenant application platform may be replicated across multiple time zones. Further, asynchronous replications may be performed to update a subscriber organization instance when the subscriber organization instance is offline for maintenance or the like. A similar, analogous procedure is implemented to uninstall a package, upload a version update, and install a package upgrade using the two phase commit, cross instance aspect of the embodiment.
  • a system 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.
  • FIG. 1 illustrates an environment wherein an on-demand database service might be used.
  • FIG. 2 illustrates elements of an example System 16 and various interconnections in an embodiment.
  • FIG. 3 illustrates an overview flow diagram of an embodiment.
  • FIG. 4 illustrates an overview flow diagram of a license manager application bootstrap sequence embodiment.
  • FIG. 5 illustrates a diagram of a subscriber install application data flow embodiment.
  • FIG. 6 illustrates a diagram of a message server API call to an LMO in an embodiment.
  • FIG. 7 illustrates a code sequence of a package object in an embodiment.
  • FIG. 8 illustrates a code sequence of a package version object in an embodiment.
  • FIG. 9 illustrates a diagram of an application exchange upload sequence in an embodiment.
  • FIG. 10 illustrates an embodiment of a code sequence of a license object in an embodiment.
  • FIG. 11 illustrates embodiments of code sequences of listener actions in an embodiment.
  • 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.
  • the present invention provides systems and methods for managing license objects to applications in an application platform.
  • the systems and methods are particularly useful in an on-demand database service.
  • System, mechanism and method embodiments can provide the ability to associate a subscriber license with a customized version of an application installed to the application platform by a developer.
  • a subscriber license is a license permitting a subscriber to use an application installed to the platform.
  • some system and method embodiments can notify a licensor of a standard object when a third party had customized the application.
  • a standard object is a member of a set of objects included with an instance of an on-demand service at initiation of the service.
  • Some embodiments can further provide a tracking mechanism to determine when a subscriber exceeds a contracted number of users of both the customized application and standard application.
  • FIG.1 illustrates an environment wherein an on-demand database service might be used.
  • user systems 12 might interact via a network 14 with an on-demand database service 16.
  • Some on-demand database services may store information from one or more tenants stored into tables of a common database image to form a multi-tenant database system (MTS).
  • MTS multi-tenant database system
  • on-demand database service 16 and system 16 will be used interchangeably herein.
  • a database image may include one or more database objects.
  • Some on-demand database services may include an application platform 18 that enables creation, managing and executing one or more applications developed by the provider of the on-demand database service, users accessing the on-demand database service via user systems 12, or third party application developers accessing the on-demand database service via user systems 12.
  • 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.
  • 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.
  • TCP/IP Transfer Control Protocol and Internet Protocol
  • Internet 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.
  • I Internet 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.
  • HTTP HyperText Transfer Protocol
  • 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.
  • 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.
  • 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.
  • System 16 includes application servers configured to implement and execute CRM software applications as well as provide related data, code, forms, Web pages and other information to and from user systems 12 and to store to, and retrieve from, a database system related data, objects and Web page content.
  • CRM customer relationship management
  • data for multiple tenants may be stored in the same physical database object, however, tenant data typically is arranged so that data of one tenant is kept logically separate from that of other tenants so that one tenant does not have access to another tenant's data, unless such data is expressly shared.
  • system 16 implements applications other than, or in addition to, a CRM application.
  • system 16 may provide tenant access to multiple hosted (standard and custom) applications, including a CRM application.
  • User (or third party developer) applications which may or may not include CRM, may be supported by the application platform 18, which manages creation, storage of the applications into one or more database objects and executing of the applications in a virtual machine in the process space of the system 16.
  • FIG. 1 One arrangement for elements of System 16 is shown in FIG. 1, including a network interface 20, application platform 18, storage 22 for tenant data, storage 24 for system data accessible to System 16 and possibly multiple tenants, program code 26 for implementing various functions of System 16, and a process space 28 for executing MTS system processes and tenant-specific processes, such as running applications as part of an application hosting service. Additional processes that may execute on System 16 include database indexing processes.
  • each user system 12 could include a desktop personal computer, workstation, laptop, PDA, cell phone, or any wireless access protocol (WAP) enabled device or any other computing device capable of interfacing directly or indirectly to the Internet or other network connection.
  • WAP wireless access protocol
  • User system 12 typically runs an HTTP client, e.g., a browsing program, such as Microsoft's Internet Explorer browser, Netscape's Navigator browser, Opera's browser, or a WAP-enabled browser in the case of a cell phone, PDA or other wireless device, or the like, allowing a user (e.g., subscriber of the multi-tenant database system) of user system 12 to access, process and view information, pages and applications available to it from System 16 over network 14.
  • HTTP client e.g., a browsing program, such as Microsoft's Internet Explorer browser, Netscape's Navigator browser, Opera's browser, or a WAP-enabled browser in the case of a cell phone, PDA or other wireless device, or the like.
  • Each user system 12 also typically includes one or more user interface devices, such as a keyboard, a mouse, touch screen, pen or the like, for interacting with a graphical user interface (GUI) provided by the browser on a display (e.g., monitor screen, LCD display, etc.) in conjunction with pages, forms, applications and other information provided by System 16 or other systems or servers.
  • GUI graphical user interface
  • the user interface device can be used to access data and applications hosted by System 16, and to perform searches on stored data, and otherwise allow a user to interact with various GUI pages that may be presented to a user.
  • embodiments are suitable for use with the Internet, which refers to a specific global internetwork of networks.
  • 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.
  • VPN virtual private network
  • non-TCP/IP based network any LAN or WAN or the like.
  • 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 an Intel Pentium® processor or the like.
  • Applications such as a browser, including computer code run using a central processing unit such as an Intel Pentium® processor or the like.
  • System 16 and additional instances of an MTS, where more than one is present
  • a computer program product aspect includes a machine-readable storage medium (media) having instructions stored thereon/in which can be used to program a computer to perform any of the processes of the embodiments described herein.
  • Computer code for operating and configuring System 16 to intercommunicate and to process web pages, applications and other data and media content as described herein is preferably downloaded and stored on a hard disk, but the entire program code, or portions thereof, may also be stored in any other volatile or non- volatile memory medium or device as is well known, such as a ROM or RAM, or provided on any media capable of storing program code, such as any type of rotating media including floppy disks, optical discs, digital versatile disk (DVD), compact disk (CD), microdrive, and magneto-optical disks, and magnetic or optical cards, nanosystems (including molecular memory ICs), or any type of media or device suitable for storing instructions and/or data.
  • any type of rotating media including floppy disks, optical discs, digital versatile disk (DVD), compact disk (CD), microdrive, and magneto-optical disks, and magnetic or optical cards, nanosystems (including molecular memory ICs), or any type of media or device suitable for storing instructions and/or data.
  • the entire program code, or portions thereof may be transmitted and downloaded from a software source over a transmission medium, e.g., over the Internet, or from another server, as is well known, or transmitted over any other conventional network connection as is well known (e.g., extranet, VPN, LAN, etc.) using any communication medium and protocols (e.g., TCP/IP, HTTP, HTTPS, Ethernet, etc.) as are well known.
  • a transmission medium e.g., over the Internet
  • any other conventional network connection e.g., extranet, VPN, LAN, etc.
  • any communication medium and protocols e.g., TCP/IP, HTTP, HTTPS, Ethernet, etc.
  • computer code for implementing aspects of the present invention can be implemented in any programming language that can be executed on a client system and/or server or server system such as, for example, in C, C++, HTML, any other markup language, JavaTM, JavaScript, ActiveX, any other scripting language such as VBScript, and many other programming languages as are well known.
  • JavaTM is a trademark of Sun Microsystems, Inc.
  • 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.
  • System 16 provides security mechanisms to keep each tenant's data separate unless the data is shared.
  • MTS Mobility Management Entity
  • 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).
  • each MTS could include one or more logically and/or physically connected servers distributed locally or across one or more geographic locations.
  • 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.
  • 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.
  • FIG. 2 illustrates elements of an example System 16 and various interconnections in an embodiment.
  • example System 16 includes a network interface 20 (of FIG. 1) implemented as one or more HTTP application servers 100, an application platform 18 and database objects 106, 108.
  • system process space 102 including individual tenant process spaces 104, a tenant management process space 110 and database objects 106, 108.
  • a Tenant database 108 might be divided into individual tenant storage areas 112, which can be either a physical arrangement or a logical arrangement.
  • user storage 114 and application storage 116 might similarly be allocated for each user. For example, a copy of a user's most recently used (MRU) items might be stored to user storage area 114.
  • MRU most recently used
  • a user interface UI 30 provides a user interface and an API 32 provides an application programmer interface to System 16 resident processes to users and/or developers at user systems 12.
  • 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.
  • 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.
  • database systems e.g., system database 106 and tenant database(s) 108
  • one server 1001 might be coupled via the Internet 14
  • another server lOON-1 might be coupled via a direct network link
  • another server IOON might be coupled by yet a different network connection.
  • Transfer Control Protocol and Internet Protocol TCP/IP
  • TCP/IP Transfer Control Protocol and Internet Protocol
  • 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.
  • an interface system implementing a load balancing function e.g., an F5 Big-IP load balancer
  • 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.
  • System 16 is multi -tenant, wherein System 16 handles storage of, and access to, different objects, data and applications across disparate users and organizations.
  • one tenant might be a company that employs a sales force where each salesperson uses System 16 to manage their sales process.
  • 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).
  • tenant database 108 e.g., 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.
  • 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.
  • System 16 might also maintain system level data usable by multiple tenants or other data.
  • system level data might include industry reports, news, postings, and the like that are sharable among tenants.
  • 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
  • SQL query the SQL query
  • 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.
  • 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.
  • standard entity tables might be provided for use by all tenants.
  • 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 “obj ect” and “table”.
  • 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.
  • 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.
  • 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.
  • database setup data e.g., metadata
  • 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.
  • 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.
  • US Patent application Serial No. 11/075546 filed March 8, 2005, titled “Systems and Methods for Implementing Multi- Application Tabs and Tab Sets", which is hereby incorporated by reference, discusses various aspects and details of tabs and tabs sets.
  • 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).
  • 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.
  • 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.
  • 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, hi 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.
  • the directory is built using JSP pages, JSTL, a JSP tag library, JSP tags, and Java classes, hi 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.
  • an import user 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.
  • 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
  • the import process preferably does not overwrite any existing subscriber organization fields. Also, an import user can uninstall the imported application.
  • installation is a multi-step process with one or more steps performed using an installation wizard.
  • 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.
  • 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.
  • the import process checks to make sure the importing user has appropriate organization permissions to import a package.
  • 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.
  • 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.
  • 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.
  • WILs Web Integration Links
  • a subscriber is unable to change any of the setup data in the package after it is imported.
  • 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).
  • 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.
  • 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, hi 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.
  • a "control" field is provided to identify whether an object may be modified by the developer and/or the subscriber.
  • 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:
  • a new version of a package adds a custom object with the same name as an existing custom object in the subscribing organization.
  • a new version of a package changes some attribute of a field, 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.
  • 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.
  • 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 metadata 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.
  • directory upgrades are not automatically distributed to subscribing organizations. Instead, the process requires that a subscriber pull the upgrade to their organization, hi certain aspect this includes the developer uploading the new version to the directory, notifying subscribers via an administration UI, email, and/or a visual cue in the Package UI., 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, hi certain aspects, a subscriber will the following options:
  • 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 should not be packaged in certain aspects, hi 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.
  • 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.
  • 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, hi 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 "highlevel” dependencies to the package, i.e., the user is able to review the package contents before the final export. In certain aspects, the same holdss 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)
  • Custom Fields 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.
  • 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.
  • 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.
  • an organization is able to package one or more fields on a standard object
  • hi another aspect an organization is able to package fields, formulas, record types, validations, etc. on custom objects from other developers.
  • 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.
  • object properties that should be scanned for references include:
  • Formulas 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.
  • external entities e.g., User, RecordType, etc.
  • Custom Fields are added to the list of high-level components that can be manually selected to be added to a package.
  • 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.
  • Custom Objects referenced by manually added Custom Fields are automatically added as part of the spidering process at package export time.
  • Custom Validations A manual choice to add validations, referred objects are automatically included and all validations are included for manually added custom objects.
  • 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.
  • certain aspects introduce package versioning.
  • 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.
  • An "Upload to Directory" button will move to the version.
  • 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.
  • the developer will create a new version, and add the new items there.
  • 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.
  • any items added to the intervening minor version are automatically included in the next major version as well.
  • 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.
  • the new version is presented by default, but users can still see old versions. Li another aspect, the old versions are not accessible at all.
  • 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.
  • a developer 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 namespaced- enabled components: components created prior to obtaining a namespace will remain in the global namespace.
  • a UI is provided, in one aspect, to allow a user to view namespace- enabled 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.
  • 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 UI will use the package membership information to visually distinguish installed and local components of the same name.
  • a namespace identifier e.g., namespace id, column.
  • 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.
  • 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. hi 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 includes two types of information: static information, and dynamic information based on package membership.
  • a package entity e.g., application
  • a package entity 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.
  • a component is managed if it is part of at least one managed package which has been uploaded to the application directory.
  • a component is managed if it is part of an installed managed package.
  • 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.
  • manageability requirements vary by type. The most common instance requirement for manageability is namespacing.
  • 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.
  • 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:
  • 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 (i.e., the component is part of a managed package installed from the directory).
  • the component is unmanaged.
  • setup 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 UI so that the developer never makes the invalid changes (especially since some changes may be difficult or impossible to revert).
  • setup 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, hi one aspect, these restrictions are enforced in each entity UI via display changes (separating local customizations and published content, disabling links and buttons, etc.) and error messages.
  • 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.
  • the entity is packageable, and may be upgraded in a managed package; however neither the developer nor subscribers can change any non-internal fields.
  • the entity is not packageable.
  • 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 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.
  • 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.
  • 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 subscriber- controlled, publisher-controlled, immutable, or internal, as described above.
  • Bit vector items and fields should not be overrideable, because, in certain aspects, the overrideable behavior requires ternary logic (true
  • 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. Ij 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.
  • 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.
  • 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, hi 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.
  • 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, hi certain aspects, the attributes of an entity will control the behavioral details.
  • the UI 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.
  • 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.
  • 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.
  • 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.
  • the developer may provide a descriptive version label, in addition to the internal sequence identifier.
  • 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.
  • the developer may need to resolve any validation errors.
  • the developer may add or remove new components.
  • 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
  • the upgrade process performs some or all of the following steps:
  • 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.
  • 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.
  • 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.
  • a method 300 is provided for managing license objects associated with applications in an application platform.
  • a license is associated with a custom object that has a lookup relationship with a package.
  • Packages can be either managed or unmanaged.
  • a managed package includes control elements enforcing versioning, customization of the package metadata.
  • An unmanaged package is one that, lacking these control elements, cannot be as easily upgraded, while a managed package is an application package that can be upgraded by the installing organization.
  • an application includes a group or package of multi-tenant database setup data (e.g. metadata) that defines its data model, user interface and business logic.
  • the term "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.
  • An organization may be associated with an LMO and a Subscriber to create an instance of the disclosed method and system.
  • a license object includes various properties such as package version, license status, install date, the number of seats, formula for the number of seats, expiration date and formula, a proxy user, account and contact information and other such pertinent information depending upon the embodiment.
  • An example of a license object and associated fields implemented in one embodiment is further described and illustrated in FIG. 10.
  • the method 300 typically includes associating an LMA with an application and correspondingly downloading a custom application that has been created and uploaded to an application exchange by a third party developer.
  • a license manager implements the process of method 300 and views install information from subscribers.
  • a third party license manager may download an LMA to its organization, hi block 320, an application installation sequence is executed to create a lead and a license copy in the LMO.
  • a third party developer may create a custom application in the developer partner organization. During packaging, the developer specifies the LMO that is associated with the package.
  • the developer may upload the custom application into the application exchange directory. An outbound message may then notify the license manager of the package information.
  • the subscriber instance of the downloaded package may be asynchronously updated to all linked database schema via a two phase commit process and updated to the host organization database schema.
  • Updates can include status changes in objects and field attributes that define whether that field or object can be altered. For example, an "immutable" field may not be able to be altered by anyone.
  • the source user can set an immutable flag so that nobody is able to modify the field or object after it has been packaged and published.
  • An upgrade process that executes checks on each of such fields, where present, determines the extent that customizations are maintained upon upgrades and on updates. Updates may also include the various properties from the license as discussed above.
  • block 350 subscribers may download the custom application into their own organization 362.
  • the license manager may monitor the LMA to view the installation information. Upon inspecting the LMA records, a local installation record may be displayed.
  • block 320 executes an application installation in a sequence of blocks, including creating a license administration user and a corresponding license object; sending an outbound message to a message server 342 with license information and a session identification; and making an API call to the subscriber to get the license manager organization 344 identification record, user and organization information upon receiving a message from the third party developer.
  • Some method embodiments include notifying a license manager to which the license manager application is installed of the installation of the application to the application platform includes creating, by a third party developer, block 330, a custom application and specifying the LMO when packaging the custom application, uploading, by the third party developer, the custom application into the application platform, and sending a message to the LMA so LMA can get package information for the custom application 320.
  • managing subscriber access to the application using the license manager application includes downloading a custom application by a subscriber 350, and tracking a subscriber's install of the custom application by the LMA.
  • the method also includes notifying of a new version of a custom application being uploaded to the application services platform.
  • the method also includes notifying of upgrading versions of a custom application to make available in the application services platform application exchange.
  • the method also includes notifying of uninstallation of a custom application to limit availability in the application services platform application exchange. An uninstallation can be implemented because the system keeps track of which metadata objects belong to the package through the package database schema.
  • the custom application is installed, 350, the following are executed including creating a license administration user and a license object, sending an outbound message 340 to a message server 342, with license information and session identification.
  • message server 342 Upon receiving the message, message server 342 makes an API call to the subscriber to get the license manager organization identification, user and organization information 320.
  • message server then makes another API call to license manager (using the proxy user instance created when the LMA was installed in the license manager (a proxy user), to create a lead and a license copy in the license manager organization 320.
  • a method for providing an association between a partner and a client creating a client specific instance of an application exchange directory which enables partners to determine which customers have installed particular versions of their application, when such use occurred and whether such use was in accordance with an agreed upon licensing agreement clicked through when the custom application version was installed 342, 360, 362.
  • the entire license management process is supplemented with the additional steps including installing a tracking process 360 and, once a managed application is downloaded into an organization 350, providing an installation sequence 320 that will be executed.
  • the installation tracking process comprises a computer-readable medium of providing code to perform the steps of downloading a third party LMO into a third party organization, executing installation sequence steps in the license manager organization instance, creating a custom application in a partner developer organization by a third party developer and then specifying the LMO, uploading the custom application into the application exchange directory by a developer, sending an outbound message from the application exchange directory to the LMA such that the LMA can get the package information, downloading the custom application into the subscriber organization, executing the installation sequence, and tracking the subscriber's installation by an LMA.
  • a method is disclosed of providing an installation sequence 440.
  • the method includes creating a license administration user and a license object 441, sending an outbound message to the message server with license object and session identification 442, upon receiving the message, making an API call to the subscriber by the message server and getting the user, subscriber organization identification record, and license management organization identification 443.
  • making another API call to the publisher using the proxy user created when the LMA was installed in the publisher
  • message server then uses the proxy user information to create a package, lead, license copy in the proxy user organization instance.
  • a method for providing a bootstrap sequence 400.
  • the method embodiment includes the steps to perform when a license management application is created to install into the LMO.
  • the method includes creating the LMA in the host developer organization 412, specifying an associated license management organization with the LMA 410, making a check call to the organization to make sure that it has the LMA already installed, uploading the LMA into the application exchange directory 422 by the host developer 420, when an LMA is downloaded into the LMO 430, determining if the package exists by the subscriber organization 432, creating the package by a message server if one does not exist, downloading an LMA by the LMO, creating a package license in the LMO; and executing the installation sequence 440, as described above.
  • FIG. 5 illustrates a method 500 for installing an application at a subscriber organization in an embodiment.
  • Method 500 illustrates a subscriber installation application data flow through a plurality of objects including the subscriber organization 550, the message server 560, the proxy user instance organization 570, and the LMO 580.
  • Method 500 includes downloading an application 501 into the subscriber organization to create a user instance of the application 502 within the subscriber organization database object 550.
  • the method includes providing a process for handling a case of a subscriber installation application data flow 500, including creating a license administration record when the LMO installs the LMA for the first time 501, wherein the license administration has not been replicated into the LMO itself.
  • the subscriber organization sends an outbound message to the message server with the subscriber instance license information and session identification record 512.
  • the message server then makes an API call to obtain user information license manager organization identification, and subscriber organization record information 522, thereby matching identical records in the publisher proxy user organization and subscriber organization to allow the message server to use the user name sent through the outbound message 524, and eliminating a lookup step, as described in block 530.
  • the message server uses a password to lookup the license manager administration proxy user from the proxy user instance organization.
  • the proxy user information is stored in the proxy user instance organization LMA license table when the LMA was installed in the LMO.
  • the message server then uses this user to query the license manager license administration user name 534 through the proxy user instance organization 532. Finally, the message server then makes an API call to create a license/lead in the license manager organization 540.
  • the method 600 includes processing performed by the message server to make an API call to the license manager organization 620 using the license administration user name to return the record to the message server 624.
  • the message server receives an outbound message 601 and then uses the username from the proxy user instance organization 610 to get the LMO's license administration user information record 610 and returns the record to the message server 614.
  • the message server makes an API call 620 to the LMO 622 using the license administration username 620 and upon obtaining the appropriate data from the LMO, returns the query information to the message server 624.
  • the message server When the message server does not have any user information about the user in the publisher's host organization, it cannot change data directly in publisher's organization.
  • the proxy user instance organization has the publisher's license administration user information, however, because when the publisher installs the LMA, a user record is copied to the proxy user instance organization. A password to the proxy user instance organization will be hard coded into the message server to provide this login availability. Once the message server obtains the user information record, it can then login as the publisher and make changes as per the process outlined above.
  • FIGS. 7, 8 and 10 a package object and related fields 710, 810, and 1010 will be described in conjunction with the corresponding program code 720, 820, and 1020.
  • Fig. 7 illustrates various embodiments of a method to provide a package object 700.
  • An example arrangement of fields including package name, package identification, developer name, developer organization identification, release date, latest version, and lead manager is illustrated in block 710.
  • block 720 an example Web Services Description Language (WSDL) rendering of a package object is illustrated.
  • WSDL Web Services Description Language
  • FIG. 8 illustrates various embodiments of a method to provide a package version object 800.
  • An example arrangement of fields including package version name, package, version, version identification, release date and sequence is illustrated in block 810.
  • block 820 an example WSDL rendering of a package version object is illustrated.
  • the directory server When a new package is first uploaded into the application exchange directory, the directory server must send an outbound message to the LMO so the message server can create the data record that corresponds with the new package. Subsequently, if a package is upgraded, the application exchange server will send another message so the LMA can get the changes as shown in method 900.
  • Fig. 9 illustrates an application exchange application upload method 900 in an embodiment.
  • a developer uploads the application to the application exchange directory, or uploads an upgrade to an application 901.
  • the data is then collected into the application exchange directory 902 and the application exchange directory is replicated and the records are thereby updated to include the newly uploaded data.
  • the developer sends an outbound message to the message server with package information corresponding to the required fields including, in an example arrangement, package name, package identification, developer name, developer organization identification, and version 920.
  • the data is then collected into the message server files 922 and the files are thereby replicated and updated.
  • the message server then uses a password to lookup the license manager administration user from the organization corresponding to the proxy user instance 930.
  • the user data is next stored in the proxy user instance organization LMA license table at the time when the LMA was installed in the LMO.
  • the message server will then use the proxy user instance to query the license manager license administration user name through the proxy user instance 930.
  • the data is further replicated and updated into the proxy user instance of the organization LMA license table 932.
  • the updated records from the updated table in the proxy user instance are then returned to the message server via a further replication 934.
  • the message server makes an API call to create a new package object in the LMO.
  • the LMO data is then replicated and updated in block 942.
  • FIG. 10 illustrates various embodiments of a method to provide a custom license object 1000.
  • block 1020 an exemplary WSDL rendering of a license object is illustrated.
  • Fig. 12 illustrates a method for managing license objects to applications in a multi- tenant application platform 1200 in an embodiment.
  • the method includes installing an LMO to obtain a proxy user in a partner organization.
  • the proxy user has authority to disable the package 1210 and appears to the subscriber as editing a record in a multi-tenant application platform 1220.
  • the proxy user may be provided the capability to edit package objects, version objects, and licensee objects in a database schema 1230.
  • the proxy user determines status changes as either active or disabled 1240 and implements notification of a new or upgraded version of a custom application being uploaded to the application services platform, application exchange 1250.
  • the licensee objects may include license properties, such as for example and without limitation, package version, license status, install date, the number of seats, formula for the number of seats, expiration date and formula, the proxy user, account and contact information. License properties, package and version object updates 1260 may be replicated across the subscriber instance of the multi- tenant application platform in the network when a package is installed. Updates of the subscriber instance associated with the multi-tenant application platform may be replicated across multiple time zones 1270. Further, asynchronous replications may be performed to update a subscriber organization instance when the subscriber organization instance is offline for maintenance 1280 or the like. A similar, analogous procedure is implemented to uninstall a package, upload a version update, or install a package upgrade.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Stored Programmes (AREA)

Abstract

L'invention concerne des systèmes et des procédés pour installer et mettre à jour des ensembles d'application sur une plate-forme d'application. Les systèmes et les procédés sont particulièrement utiles dans un service de base de données à la demande. Les ensembles d'application peuvent être téléchargés vers un répertoire par des utilisateurs de développement (développeurs) pour une installation par des utilisateurs abonnés (abonnés). En variante, un développeur peut envoyer des informations d'identification à un utilisateur s'abonnant pour permettre que l'utilisateur ait accès et installe cet ensemble d'application créé par le développeur. Les ensembles d'application peuvent aussi être mis à jour. Si un développeur change l'ensemble source d'origine, un abonné peut choisir dans son organisation le ou les changements faits par l'éditeur tout en préservant toutes les rangées de données que l'abonné avait créées depuis la première importation de l'ensemble. Un ou plusieurs drapeaux peuvent être établis dans la définition de l'ensemble pour déterminer si, et dans quelle mesure, des personnalisations d'un ensemble peuvent être faites et mises à jour par l'abonné et/ou le développeur. Un champ 'gérable' est fourni pour identifier si des personnalisations d'un objet particulier sont soumises à une mise à jour; si l'ensemble ou un objet de l'ensemble est marqué comme géré, un utilisateur peut personnaliser l'ensemble ou l'objet, et ces personnalisations ne seront pas modifiées lors d'une mise à jour de l'ensemble. Un champ 'contrôle' est fourni pour identifier si un objet peut être modifié par le développeur et/ou l'abonné. Un champ 'immuable' est fourni pour identifier si un objet peut ou ne peut pas être modifié par quiconque.
PCT/US2007/080345 2006-10-03 2007-10-03 Procédés et systèmes pour mettre à jour et installer des ensembles d'application sur une plate-forme d'application WO2008042984A2 (fr)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US82802306P 2006-10-03 2006-10-03
US82801606P 2006-10-03 2006-10-03
US60/828,016 2006-10-03
US60/828,023 2006-10-03

Publications (2)

Publication Number Publication Date
WO2008042984A2 true WO2008042984A2 (fr) 2008-04-10
WO2008042984A3 WO2008042984A3 (fr) 2008-09-18

Family

ID=39269199

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2007/080345 WO2008042984A2 (fr) 2006-10-03 2007-10-03 Procédés et systèmes pour mettre à jour et installer des ensembles d'application sur une plate-forme d'application

Country Status (1)

Country Link
WO (1) WO2008042984A2 (fr)

Cited By (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20100299664A1 (en) * 2009-05-21 2010-11-25 Salesforce.Com, Inc. System, method and computer program product for pushing an application update between tenants of a multi-tenant on-demand database service
RU2507570C2 (ru) * 2008-07-28 2014-02-20 Майкрософт Корпорейшн Пакеты компьютерных прикладных программ с индивидуальной настройкой
US20140298312A1 (en) * 2010-03-15 2014-10-02 Salesforce.Com, Inc. System, method and computer program product for deploying an update between environments of a multi-tenant on-demand database system
US9348576B2 (en) 2006-10-03 2016-05-24 Salesforce.Com, Inc. Methods and systems for upgrading and installing application packages to an application platform
US9495372B2 (en) 2011-09-23 2016-11-15 Corent Technology, Inc. Multi-tenant agile database connector
WO2016191629A1 (fr) * 2015-05-27 2016-12-01 Speaktoit, Inc. Place de marché en ligne de modules d'extension pour améliorer des systèmes de dialogue
WO2018052914A1 (fr) * 2016-09-19 2018-03-22 Microsoft Technology Licensing, Llc Déploiement d'applications se conformant à un schéma de plateforme de service de décision et de partage de données d'application
CN107844314A (zh) * 2017-12-22 2018-03-27 税友软件集团股份有限公司 一种升级Weblogic应用程序的方法及系统
US10216510B2 (en) * 2016-06-04 2019-02-26 Airwatch Llc Silent upgrade of software with dependencies
US10311492B2 (en) 2015-05-27 2019-06-04 Google Llc Enhancing functionalities of virtual assistants and dialog systems via plugin marketplace
US10372514B2 (en) 2016-09-19 2019-08-06 Microsoft Technology Licensing, Llc Application data sharing and decision service platform
CN111061493A (zh) * 2019-12-18 2020-04-24 北京神舟航天软件技术有限公司 一种基于应用仓库的客户端应用全生命周期管理方法
US10700951B2 (en) 2014-07-31 2020-06-30 Corent Technology, Inc. Multi-application SaaS metering engine
CN111367550A (zh) * 2020-03-02 2020-07-03 深圳前海达闼云端智能科技有限公司 物联网管理系统、方法和设备
US10715603B2 (en) 2016-09-19 2020-07-14 Microsoft Technology Licensing, Llc Systems and methods for sharing application data between isolated applications executing on one or more application platforms
CN112306474A (zh) * 2020-10-28 2021-02-02 科大国创云网科技有限公司 一种基于组件化模板的vue项目平滑升级方法
US11019136B2 (en) 2014-07-31 2021-05-25 Corent Technology, Inc. Partitioning and mapping workloads for scalable SaaS applications on cloud
US12126676B2 (en) 2023-05-09 2024-10-22 Corent Technology, Inc. Multitenant cross dimensional cloud resource visualization and planning

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6789215B1 (en) * 2000-04-21 2004-09-07 Sprint Communications Company, L.P. System and method for remediating a computer

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6789215B1 (en) * 2000-04-21 2004-09-07 Sprint Communications Company, L.P. System and method for remediating a computer

Cited By (36)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10831462B2 (en) 2006-10-03 2020-11-10 Salesforce.Com, Inc. Methods and systems for upgrading and installing application packages to an application platform
US9348576B2 (en) 2006-10-03 2016-05-24 Salesforce.Com, Inc. Methods and systems for upgrading and installing application packages to an application platform
US9870218B2 (en) 2006-10-03 2018-01-16 Salesforce.Com Inc. Methods and systems for upgrading and installing application packages to an application platform
RU2507570C2 (ru) * 2008-07-28 2014-02-20 Майкрософт Корпорейшн Пакеты компьютерных прикладных программ с индивидуальной настройкой
US20130246356A1 (en) * 2009-05-21 2013-09-19 Salesforce.Com, Inc. System, method and computer program product for pushing an application update between tenants of a multi-tenant on-demand database service
US20100299664A1 (en) * 2009-05-21 2010-11-25 Salesforce.Com, Inc. System, method and computer program product for pushing an application update between tenants of a multi-tenant on-demand database service
US20140298312A1 (en) * 2010-03-15 2014-10-02 Salesforce.Com, Inc. System, method and computer program product for deploying an update between environments of a multi-tenant on-demand database system
US9442713B2 (en) * 2010-03-15 2016-09-13 Salesforce.Com, Inc. System, method and computer program product for deploying an update between environments of a multi-tenant on-demand database system
US10146526B2 (en) * 2010-03-15 2018-12-04 Salesforce.Com, Inc. System, method and computer program product for deploying an update between environments of a multi-tenant on-demand database system
US9495372B2 (en) 2011-09-23 2016-11-15 Corent Technology, Inc. Multi-tenant agile database connector
US10824591B2 (en) 2011-09-23 2020-11-03 Corent Technology, Inc. Automatic transformation of single-tenant software applications to multi-tenant SAAS systems
US11689435B2 (en) 2014-07-31 2023-06-27 Corent Technology, Inc. Multi-application SaaS metering engine
US11019136B2 (en) 2014-07-31 2021-05-25 Corent Technology, Inc. Partitioning and mapping workloads for scalable SaaS applications on cloud
US10700951B2 (en) 2014-07-31 2020-06-30 Corent Technology, Inc. Multi-application SaaS metering engine
US11671482B2 (en) 2014-07-31 2023-06-06 Corent Technology, Inc. Multitenant cross dimensional cloud resource visualization and planning
US11551273B2 (en) 2015-05-27 2023-01-10 Google Llc Enhancing functionalities of virtual assistants and dialog systems via plugin marketplace
US10324704B2 (en) 2015-05-27 2019-06-18 Google Llc Online marketplace of plugins for enhancing dialog systems
US10311492B2 (en) 2015-05-27 2019-06-04 Google Llc Enhancing functionalities of virtual assistants and dialog systems via plugin marketplace
US10990377B2 (en) 2015-05-27 2021-04-27 Google Llc Online marketplace of plugins for enhancing dialog systems
US11769184B2 (en) 2015-05-27 2023-09-26 Google Llc Enhancing functionalities of virtual assistants and dialog systems via plugin marketplace
US11170415B2 (en) 2015-05-27 2021-11-09 Google Llc Enhancing functionalities of virtual assistants and dialog systems via plugin marketplace
US11861346B2 (en) 2015-05-27 2024-01-02 Google Llc Online marketplace of plugins for enhancing dialog systems
WO2016191629A1 (fr) * 2015-05-27 2016-12-01 Speaktoit, Inc. Place de marché en ligne de modules d'extension pour améliorer des systèmes de dialogue
US10216510B2 (en) * 2016-06-04 2019-02-26 Airwatch Llc Silent upgrade of software with dependencies
WO2018052914A1 (fr) * 2016-09-19 2018-03-22 Microsoft Technology Licensing, Llc Déploiement d'applications se conformant à un schéma de plateforme de service de décision et de partage de données d'application
US10715603B2 (en) 2016-09-19 2020-07-14 Microsoft Technology Licensing, Llc Systems and methods for sharing application data between isolated applications executing on one or more application platforms
US10409786B2 (en) 2016-09-19 2019-09-10 Microsoft Technology Licensing, Llc Deployment of applications confirming to application data sharing and decision service platform schema
US10372514B2 (en) 2016-09-19 2019-08-06 Microsoft Technology Licensing, Llc Application data sharing and decision service platform
CN109716331B (zh) * 2016-09-19 2023-09-12 微软技术许可有限责任公司 符合应用程序数据共享和决策服务平台模式的应用程序部署
CN109716331A (zh) * 2016-09-19 2019-05-03 微软技术许可有限责任公司 符合应用程序数据共享和决策服务平台模式的应用程序部署
CN107844314A (zh) * 2017-12-22 2018-03-27 税友软件集团股份有限公司 一种升级Weblogic应用程序的方法及系统
CN111061493A (zh) * 2019-12-18 2020-04-24 北京神舟航天软件技术有限公司 一种基于应用仓库的客户端应用全生命周期管理方法
CN111367550A (zh) * 2020-03-02 2020-07-03 深圳前海达闼云端智能科技有限公司 物联网管理系统、方法和设备
CN112306474A (zh) * 2020-10-28 2021-02-02 科大国创云网科技有限公司 一种基于组件化模板的vue项目平滑升级方法
CN112306474B (zh) * 2020-10-28 2022-09-20 科大国创云网科技有限公司 一种基于组件化模板的vue项目平滑升级方法
US12126676B2 (en) 2023-05-09 2024-10-22 Corent Technology, Inc. Multitenant cross dimensional cloud resource visualization and planning

Also Published As

Publication number Publication date
WO2008042984A3 (fr) 2008-09-18

Similar Documents

Publication Publication Date Title
US10831462B2 (en) Methods and systems for upgrading and installing application packages to an application platform
US11314494B2 (en) Systems and methods for exporting, publishing, browsing and installing on-demand applications in a multi-tenant database environment
WO2008042984A2 (fr) Procédés et systèmes pour mettre à jour et installer des ensembles d'application sur une plate-forme d'application
US9230068B2 (en) Method and system for managing license objects to applications in an application platform
US10768926B2 (en) Maintaining manageability state information distinct from managed metadata

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 07843773

Country of ref document: EP

Kind code of ref document: A2

NENP Non-entry into the national phase in:

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 07843773

Country of ref document: EP

Kind code of ref document: A2