Some embodiments relate to a multi-tenant application platform. More specifically, some embodiments relate to the activation of tenant-independent metadata within a multi-tenant application platform.
An application platform may execute applications (e.g., business processes) to provide business functions to a client. Efficiencies are realized by providing functionality to multiple clients from a single application platform, which may be referred to as a multi-tenant application platform. Due to the sensitivity of business data, it is preferable to isolate the data of each client (i.e., tenant) from the data of each other tenant. More specifically, a tenant of a multi-tenant application platform is unable to access the data of another tenant.
According to some systems, each of tenant-specific databases 114 and 124 include data which is modeled based on metadata stored in tenant-independent database 130. The metadata defines metaobjects and instances thereof (i.e., object models). Types of metaobjects include a Business Object, a Query Definition, a Business Intelligence View, a Floorplan (i.e., a user interface layout), User Interface Text, a Process Component, and a Message Type, among others. A Business Object-type metaobject, for example, is a software model representing real-world items used during the transaction of business. An instance of a Business Object metaobject may comprise a SalesOrder object model or an Organization object model. Instances of these object models, in turn, represent specific data (e.g., SalesOrder SO4711, ACME corporation).
It may be desirable to change the metadata of database 130. The change may provide new functionality, model simplification, or any other desired result. Even though tenant-independent database 130 stores tenant-independent metadata (i.e., the metadata is equally applicable to all tenants), changing the tenant-independent metadata may result in artifacts or content which are tenant-specific. For example, tenant-independent metadata defining a Query Definition may be changed to add fields to the query definition. Accordingly, new data columns should be added to the tenant database tables which store the data of tenant-specific query definitions.
Due to tenant isolation principles, an administrator currently effects the above-described changes by logging on to each tenant and manually coding the changes therein. Systems are therefore desired for facilitating the activation of changed tenant-independent metadata within isolated tenants. Such systems may assist the setup and administration of multi-tenant application platforms.
System 200, as well as tenant A 210, tenant B 220, and development tenant 240 are border by dashed lines to illustrate logical, but not necessarily physical, isolation of their respective elements. For example, tenant A processes 212, tenant B processes 222 and development tenant processes 242 may be executed by processor(s) of a single computer server. In some embodiments, however, tenant A database 214 and tenant B database 224 are implemented within physically separate storage devices.
Generally, each system described herein may be implemented by any number of devices in communication via any number of other public and/or private networks. Two or more devices of may be located remote from one another and may communicate with one another via any known manner of network(s) and/or a dedicated connection. Moreover, each device may comprise any number of hardware and/or software elements suitable to provide the functions described herein as well as any other functions. For example, databases 214, 224, 230 and 244 may each be implemented by any number of storage devices that are or become known.
Development tenant 240 may allow a developer to delete, add and/or modify metadata of tenant-independent database 230. As mentioned above, due to tenant isolation, development tenant 240 cannot access data of tenant A database 214 or tenant B database 224. However, by virtue of some of the features described herein, data of tenant A database 214 and tenant B database 224 may be changed to conform to the deleted/added/modified metadata.
Process 300 may be executed by and/or with respect to a computing system including a tenant-independent database and one or more tenant-specific databases. The tenant-independent database includes metadata defining the data stored in the one or more tenant-specific databases.
Initially, at S310, an instruction to activate first metadata of the tenant-independent database is received. The instruction may be received at S310 by development tenant 240 or by another component of system 200.
Prior to S310, a developer may manipulate user interface 400 to modify tenant-independent metadata. User interface 400 of
As mentioned above, the instruction may be received by development tenant processes 242 at S310. Next, at least one adoption task to be performed is determined at S320 based on the metadata. The metadata will be referred to as “first” metadata in the foregoing description, although “first” is not intended to denote any temporal or hierarchical property.
The at least one adoption task is intended to conform tenant-specific data of a tenant-specific database (which conforms to a previous version of the metadata of tenant-independent database 230) to the first metadata. For example, if the first metadata adds a field to an object model, an adoption task to add a column to a corresponding database table of the tenant-specific database may be determined at S320. Development tenant 240 may determine the at least one adoption task using any system that is or becomes known.
For example, after import of a transport request, sequencer steps of a transport management system determine follow-up actions such as generating UI loads (in order to speed up UI processing), refreshing TREX indices, etc. Similar logic may be employed at S320 according to some embodiments.
At least one adoption request corresponding to the at least one adoption task is added to a queue at S330.
Trigger API 550 includes one or more methods implemented by program code of system 500. According to the
Queue 560 may comprise a database table stored in tenant-independent database 530, as shown. By storing queue 560 in database 530, queue 560 may be visible to tenants 510 and 520. The at least one adoption task of queue 560 is then dispatched to the tenants at S340.
In the
The adoption tasks may be performed using any suitable system that is or becomes known. In one example, reception of the at least one adoption request implicitly triggers the execution of after-import methods based on the object type of the first metadata. Some systems may employ explicitly-provided execution statements corresponding to the at least one adoption request (e.g., eXecution of PRogram After import (XPRA)). In some embodiments, an activator may call “sequencer steps” at S350, which are traditionally used to cascade follow-up actions/adoptions during import into other systems.
According to the operation of system 600, steps S310 through S330 of process 300 may proceed as described above with respect to system 500. However, at S340, dispatcher 674 reads queue 660 and calls activators 616 and 626 to dispatch the at least one adoption task of queue 660 to activators 616 and 626. Dispatcher 674 may operate asynchronously as described above (e.g., five minutes after a previous dispatching) or, in some embodiments, S340 may be triggered by a Remote Function Call received from development tenant 640.
At S350, activators 616 and 626 perform the at least one adoption task determined at S320 to conform the data of their respective tenant-specific databases 614/624 to the first metadata. According to some embodiments, activators 616 and 626 transmit a log and/or other results of the adoption tasks to dispatcher 674 after S350. Dispatcher 674 may therefore provide feedback on the execution of the adoption tasks to development tenant 640.
Apparatus 700 includes processor 710 operatively coupled to communication device 720, data storage device 730, one or more input devices 740, one or more output devices 750 and memory 760. Communication device 720 may facilitate communication with external devices, such as an external design tool. Input device(s) 740 may comprise, for example, a keyboard, a keypad, a mouse or other pointing device, a microphone, knob or a switch, an infra-red (IR) port, a docking station, and/or a touch screen. Input device(s) 740 may be used, for example, to enter information into apparatus 700. Output device(s) 750 may comprise, for example, a display (e.g., a display screen) a speaker, and/or a printer.
Data storage device 730 may comprise any appropriate persistent storage device, including combinations of magnetic storage devices (e.g., magnetic tape, hard disk drives and flash memory), optical storage devices, Read Only Memory (ROM) devices, etc., while memory 760 may comprise Random Access Memory (RAM).
Program code 732 of data storage device 730 may be executable by processor 710 to provide functions described herein, including but not limited to process 300. Embodiments are not limited to execution of these functions by a single apparatus. Tenant-independent metadata 734 may include metadata as described herein, while tenant-specific data 736 and tenant-specific data 738 may comprise data of respective tenants. Accordingly, processor 710 may execute program code 732 to conform tenant-specific data 736 and tenant-specific data 738 to tenant-independent metadata 734 as described herein. As noted, each of tenant-independent metadata 734, tenant-specific data 736 and tenant-specific data 738 may be physically segregated from one another. Data storage device 730 may also store data and other program code for providing additional functionality and/or which are necessary for operation thereof, such as device drivers, operating system files, etc.
The embodiments described herein are solely for the purpose of illustration. Those in the art will recognize other embodiments may be practiced with modifications and alterations limited only by the claims.