SHARED DATA FOR NETWORK TENANTS

Systems and methods provide a common data container storing common data, a first data container storing first data associated with a first tenant, where the first container is accessible only to the first tenant, and where the first container is associated with read access to the common data of the common data container, and a second data container storing second data associated with a second tenant, where the second container is accessible only to the second tenant, and where the second container is associated with read access to the common data of the common data container, and where the common data container is not accessible to the first tenant or to the second tenant.

BACKGROUND

Conventional database systems store large volumes of data related to many aspects of an enterprise. Applications may provide this data to users belonging to different departments or divisions of the enterprise, to partner entities (e.g., suppliers, customers), or to any other entities. The data typically includes data which is common to all entities, as well as data specific to each entity. Various systems are employed to ensure that each user of each entity may only access the data which the user is authorized to access.

In one example depicted inFIG.1A, persistent data storage11(which may be a distributed storage system) stores monolithic data10. Application12accesses monolithic data10based on commands received from corresponding user interface components14, which are operated by users of each entity to which application12grants access. Monolithic data10includes data common to all entities and data specific to each entity. During operation, application12accesses authorization component16to ensure that each user of each entity only receives portions of data10which they are authorized to receive. This architecture requires complex definition and maintenance of roles, access control lists, and the like, as well as of the authorization logic required to properly enforce the roles, access control lists, etc. Errors may lead to data leakage across users of a given entity or across entities, both of which are particularly troublesome in view of business concerns and data privacy regulations.

The architecture ofFIG.1Billustrates physical separation of application data22,23and24, each of which corresponds to a separate entity and also includes common data20. For example, application data22includes data associated with a single entity and common data20, and users of that entity access application data22via application25. Accordingly, the users of each entity are prevented from accessing data of another entity. TheFIG.1Barchitecture inefficiently requires duplication of common data20within each of application data22,23and24, and complex synchronization to account for changes to common data20which might occur within storage21or within any of application data22,23and24.

Systems are desired to efficiently provide common data to disparate entities while isolating entity-specific data adaptations and mappings.

DETAILED DESCRIPTION

The following description is provided to enable any person in the art to make and use the described embodiments. Various modifications, however, will remain readily-apparent to those in the art.

Some embodiments utilize a common container for storing common data and tenant-specific containers for storing tenant-specific data. The common container may reside in a single tenant system, while the tenant-specific data is managed by a multi-tenant-enabled system including multi-tenant applications and storage. Each tenant-specific container may access common data of the common container using a grant mechanism. According to some embodiments, upon receipt of a request from a user of a given tenant, a multi-tenant application may efficiently and transparently consume common data directly from the common container and tenant-specific data directly from the tenant-specific container associated with the given tenant. The common data may also include data structures which allow inter-tenant discovery and communication.

FIG.2illustrates a multi-tenant architecture according to some embodiments. Container200stores common data205. Container200may be seen as hardware-based storage (e.g., one or more hard disk drives and/or Random Access Memory (RAM) modules), as software providing data access and management), or any combination thereof. Generally, container200is compatible with a data access mechanism which allows other containers to access common data205.

Container210includes tenant-specific data212. Tenant-specific data212may be data which should only be accessed by a particular tenant (i.e., by users of the particular tenant) and not by any other tenant. Containers220and230are also tenant-specific and include respective tenant-specific data (not shown).

Common data214of container210represents common data205accessed via the above-mentioned data access mechanism. Accordingly, a tenant associated with container210may access both tenant-specific data212and common data214/205. A tenant associated with container220(or230) may similarly access the tenant-specific data of container220(or230) and common data205.

Multi-tenant application240may comprise program code providing any suitable functionality. Multi-tenant application240may be deployed on-premise, in the cloud, or in any manner that is or becomes known. Multi-tenant application240provides functionality to users of disparate tenants using tenant-specific containers210,220and230.

For example, a user associated with a first tenant may access UI component252to forward a request to multi-tenant application240. Multi-tenant application240determines that the user is associated with the first tenant (e.g., via an authorization token) and serves the request based only on the tenant-specific and common data stored within the container (e.g., container210) associated with the first tenant. In a case that a user associated with a second tenant accesses UI component254to forward a second request to multi-tenant application240, multi-tenant application240determines that the user is associated with the second tenant and serves the second request based only on the tenant-specific and common data stored within the container (e.g., container220) associated with the second tenant. Systems may include several different multi-tenant applications, each of which access containers210,220and230as described above.

According to some embodiments, each of containers200,210,220and230consists of a design-time container to store design-time artifacts (i.e., representations of catalog objects to be created during deployment) and a corresponding run-time container to store catalog objects built according to the representations. The transformation of design-time artifacts into corresponding run-time catalog objects may be performed by so-called plug-ins, access to which may be defined by a container configuration file according to some embodiments. Generally, the configuration file for a container may map each design-time artifact type to a plug-in for building run-time catalog objects therefrom.

FIG.3illustrates a mechanism for granting a container (e.g., a tenant-specific container) access to data of a separate container (e.g., a “common” container) which may be used in some embodiments. Container310represents a common container controlled by common owner312and container320represents a tenant-specific container controlled by tenant322. It will be assumed that Table T1of container310includes data to be accessed by container320. Embodiments are not limited to theFIG.3mechanism.

According to the present example, owner312creates Table T1and Role R1# in container310. Role R1# assigns the SELECT privilege on Table T1. Next, owner322is assigned to Role R1#. Synonym Si is created in container320and associated with Table T1. View V1referencing Synonym Si is created in container320and Role R2defines privileges required by an application user to access View V1. Users340of multi-tenant application330which are assigned to Role R2may then, via multi-tenant application330, access Table T1of container310through View V1of container320. Rather than Table T1, a shared object of common container310may comprise a view, a function, a procedure, etc.

FIG.4illustrates a multi-tenant architecture according to some embodiments. Common data container410includes data to be shared with multiple tenant-specific containers420and430. The shared data includes partner data412and material repository414in theFIG.4example. Partner data412may include data associated with suppliers, buyers, and other entities, while material data414may include data regarding raw materials. Embodiments are not limited to these types of data.

Tenant-specific container420includes tenant-specific partner data421and tenant-specific material data424. Tenant-specific partner data421may include partner-related data which is defined in any manner suitable to the tenant associated with container420. The partner-related data of tenant-specific partner data421may represent extensions to partner data412and need not follow the schema thereof. Similarly, tenant-specific material data424may represent extensions to the material data414but does not necessarily follow the schema thereof.

Tenant-specific container420is also depicted as including reference423to partner data412and reference426to material data414. The references may comprise views on data412/414as described above.

Partner mapping422comprises data used to map tenant-specific partner data421to partner data412. Partner mapping422advantageously allows a tenant associated with container420to use terminology, data formats, data structures, etc. which do not conform to partner data412, while still associating data421with logically-related counterparts of partner data412in a manner allowing data412to be consumed by a suitable application. Material mapping425provides similar links between tenant-specific material data424and material data414.

Common data services440may comprise cloud-based executable program code to provide common data API442and common data interface444. Common data API442may be invoked by UI components to request operations on data of common data container410as well as to define roles, privileges and container configurations associated with the data. Common data API442in turn uses common data interface444to perform the operations and create the definitions. In this regard, common data interface444may access database interface450to communicate with common data container410. In some embodiments, common data services440and common data container410do not support multi-tenancy because only one tenant is intended to directly access services440and container410, thereby simplifying their implementation and reducing associated costs.

Launchpad460includes services which receive browser calls from browsers (not shown) executed by users (not shown) and provide, for example, HyperText Markup Language pages in response. The services may be executed by one or more Web servers, application servers, or the like, deployed on-premise, in the cloud, or in a hybrid arrangement.

In one example, a user operates a Web browser to access a Web page provided by common data maintenance UI462. The user provides authentication information associated with a tenant sub-account and a subscription to common data services440. In some embodiments, only one tenant possesses a subscription to common data services440. The user then interacts with UI462to manage container410via common data API442, common data interface444and database interface450.

Launchpad460also includes tenant UIs464, including tenant data mapping UI466and tenant data maintenance UI468. Tenant UIs464may be provided by one or more systems which are different from the system providing common data maintenance UI462.

A user may operate a Web browser to call either of tenant data mapping UI466or tenant data maintenance UI468. The user may provide authentication information for a subscription as described above, and the authentication information is passed to multi-tenant services472to determine an associated tenant. In the present example, the determined tenant is associated with one of containers420and430.

The user may thereafter interact with tenant data mapping UI466to manage mappings stored within the associated container. In particular, these interactions result in calls to tenant data APIs472, which in turn call tenant data mapping component474. Tenant data mapping component474accesses database interface450to manage data mappings of the container associated with the current tenant.

Tenant data maintenance UI468may be accessed to maintain tenant data of a particular tenant-specific container. As described above, the particular container is determined by the subscription information provided by the user. Interaction with tenant data maintenance UI468results in calls to tenant data APIs472, which in turn call tenant data interface476. Tenant data interface component476then accesses database interface450to maintain data of the particular container determined by the subscription information.

FIG.4illustrates multi-tenant services instances470and480. Each of instances470and480may be accessed by users associated with any tenant. That is, instances470and480are not tenant-specific but are provided for load balancing and increased throughput according to some embodiments.

FIG.5illustrates a run-time system according to some embodiments. Containers410,420and430have been configured as described above with respect toFIG.4. Multi-tenant services510and520are identical instances for purposes of load balancing and throughput as described above. Embodiments are not limited to two instances.

Each of multi-tenant services510and520includes multi-tenant applications512,514and tenant data interface516which allows applications512,514to access tenant-specific data of an appropriate tenant-specific container420or430. For example, a user of a first tenant may execute browser545of computing device540, such as a laptop computer, to call application UI component532of launchpad530. It will be assumed that application UI component532is associated with multi-tenant application512. Based on login information provided by the user, multi-tenant services510identifies the user as associated with the first tenant.

The user then interacts with application512via UI component532. In case an interaction requires application512to access data, application512accesses data of the one of tenant-specific containers420or430which is associated with the first tenant, and does not access the other container. Such access may, as described above, include access to partner data412or material data414of common data container410via a data sharing mechanism as described above. It should be noted that access to partner data412or material data414from a tenant-specific container does not necessarily include the ability to create, delete or update partner data412or material data414. In some embodiments, one or more partners and/or participants may be granted certain write permissions to contribute to portions of the common data.

A second user of a second tenant may execute browser555of computing device550to call application UI component532of launchpad530. Based on login information provided by the second user, multi-tenant services510identifies the user as associated with the second tenant. In such as case, and in response to interaction of the second user with application UI component532, application512accesses only the tenant-specific data container420or430which is associated with the second tenant. Again, this access may include access to partner data412or material data414of common data container410via a data sharing mechanism as described above.

FIG.6illustrates an architecture including a plurality of tenant-specific data containers610and620, and common data container630as described above. TheFIG.6architecture also includes core data container640which may be accessed to view data shared from and stored in common container630as described above. In some implementations, common data container630is managed and maintained by a provider of theFIG.6architecture, and core data container640is associated with a customer who manages the architecture to onboard tenants and the like.

For example, the network provider may access common data maintenance UI component673of launchpad670, which in turn calls core APIs662of network services660to manage data within container630via common data interface664. The customer, on the other hand, may access tenant administration UI674of launchpad670, to call core APIs662to onboard tenants via tenant onboarding component666. Such onboarding may include, but is not limited to, creating a container for tenant-specific data of a new tenant and deleting a container associated with a tenant that has unsubscribed from the network.

Onboarding may also include storing mappings between the tenant data and common data in common container630. This is in contrast to the architecture ofFIGS.4and5, in which the mappings were stored in tenant-specific containers. Common data container630stores material mapping634and partner mapping636, and each tenant-specific container610and620may access their associated mappings. Such an arrangement may be leveraged to facilitate communication between tenants.

For example, a given tenant may create a purchase order to send to another tenant which includes a material specified in materials614of the tenant-specific container associated with the given tenant. Upon receipt of the purchase order, the system may determine a mapping between the material of the given tenant and a material of the other tenant by determining, using material mapping634, the material of materials633to which the material of the given tenant maps, and then determining, again using material mapping634, the material of the other tenant to which the material of materials633maps. The purchase order may then be updated with the corresponding material identifier used by the other tenant and forwarded to the other tenant.

Similarly, partner mapping636includes mappings between partners635of common data container630and partners615of each tenant-specific data container610and620. Each tenant-specific container610and620may also store tenant-specific data such as purchase orders611, invoices612and delivery orders613which are not mapped to data of common data container630.

FIG.7is a diagram of cloud-based architecture700according to some embodiments. Each component of cloud-based architecture700may be implemented by any number of distributed servers, storage systems, virtual machines, etc., and the resources allotted to each component may expand or contract elastically as is known in the art of cloud deployments.

Common data system710provides common data services712to UI applications as described above. Common data services712may access cloud database management system730, which accesses common data742of storage740. Common data742may be stored in a single-tenant container as described herein.

Multi-tenant system720provides multi-tenant applications722which may be accessed by users of different tenants. Applications722communicate with cloud database management system730to access either tenant1data752or tenant2data754of storage750depending upon the tenant of the user being served. Tenant1data752and tenant2data754are stored in separate containers and each may be accessed to access shared data of common data742as described above. Although both are depicted as stored in storage750, tenant1data752and tenant2data754may be stored in separate storage systems in some embodiments.

FIG.8is a block diagram of system800according to some embodiments. System800may comprise a general-purpose computing apparatus and may execute program code to perform any of the functions described herein. The elements of system800may be distributed across several physical devices, including cloud-based resources, and system800may include other unshown elements according to some embodiments.

System800includes a processing unit including but not limited to processors, processor cores, and processor threads. Such processors, processor cores, and processor threads may be implemented by a virtual machine provisioned in a cloud-based architecture. The processing unit may execute program code stored along with required data in any non-transitory tangible medium, including combinations of magnetic storage devices (e.g., magnetic tape, hard disk drives and flash memory), optical storage devices. The memory may comprise Random Access Memory (RAM), Storage Class Memory (SCM) or any other fast-access memory.