JPWO2017090142A1 - Service provision system - Google Patents

Abstract

In a multi-tenant service provisioning system, each tenant has its own data that is separated and retained, and data that is common to each tenant is centralized, and these data are seamlessly shared by each tenant. This is a service providing system that can be handled. The database has a common schema and an individual schema corresponding to each tenant, and the common schema holds common data accessible to each tenant and unique data accessible only to each tenant. Each individual schema has a view for accessing the actual data in the common schema, and the view uses the tenant identification information as a parameter and accesses only the unique data related to the common data and the tenant corresponding to the identification information. Is possible. The application determines the tenant used by the user and accesses the database through the corresponding individual schema view.

Description

  The present invention relates to a technique for providing a service to a user via a network, and more particularly to a technique that is effective when applied to a multi-tenant type service providing system that is used by a provider who provides a service in a shared manner. is there.

  2. Description of the Related Art Forms in which businesses such as companies provide software and application functions to users as services via a network have been widely used by ASP (Application Service Provider) and SaaS (Software as a Service). In particular, as in SaaS, a multi-tenant type in which a plurality of companies and businesses that provide the same type of service on a system that a system vendor constructs and operates in a data center or cloud environment provides the service together The use of this mechanism is also spreading.

  Even in the multi-tenant type, each tenant that shares the vehicle needs to be handled separately and independently from the viewpoint of security, etc., and the data that each tenant can use and reference is limited to its own, and other tenants Access control needs to be performed so that the data related to cannot be used / referenced.

  As a technique related to service provision in a multi-tenant type, for example, in Japanese Patent Laid-Open No. 2010-26653 (Patent Document 1), a user ID is acquired based on a login request, and a tenant ID corresponding to the user ID is set as a tenant ID. Acquired from the management table and recorded in the identification information storage means, and upon receiving an access request to the database from the application software, based on the tenant ID recorded in the identification information storage means, out of a plurality of data areas in the database A technique is described that simplifies development of an application that accesses a database having a different data area for each user by transmitting an access request to the data area corresponding to the tenant ID to the database management unit.

JP 2010-26653 A

  By using a technique such as that described in Patent Document 1, in a mechanism such as a multi-tenant type SaaS, the application stores the data unique to each tenant in a different area (table or the like) on the database, and the application It is possible to hide the part related to access control to each table for each tenant when accessing the application from the application. It also describes the configuration of tables with different schemas for each tenant.

  However, in the technique described in Patent Document 1, it is necessary to develop and implement a function (the multi-tenant control unit 14 in FIG. 1 in Patent Document 1) for hiding the part related to the above access control from the application. Become.

  For example, in the business of financial institutions such as securities companies, each company has data such as data exchanged with institutions with a public role, such as securities exchanges and settlement institutions such as the Bank of Japan, and data related to currencies. There is a tendency to handle common data compared to other industries. Therefore, in a multi-tenant type SaaS system, etc., not all data is individually separated and held by each tenant, but data common to each tenant is held centrally and can be used by each tenant. It is more efficient to do.

  However, the conventional technology including the technology described in Patent Document 1 does not consider the configuration of the database including such common data, and has a configuration in which all the data used by each tenant is individually separated and held. It has become.

  Therefore, an object of the present invention is to separate and hold data unique to each tenant in a mechanism for providing a service in a multi-tenant type, and to centrally hold data common to each tenant. The object is to provide a service providing system that enables each tenant to handle data seamlessly.

  The above and other objects and novel features of the present invention will be apparent from the description of this specification and the accompanying drawings.

  Of the inventions disclosed in this application, the outline of typical ones will be briefly described as follows.

  A service providing system according to a representative embodiment of the present invention is a service providing system in which a plurality of tenants provide a service individually to a user via a network in a shared manner, and executes processing related to the service An application server having an application; and a database server for holding data used for the processing on the database.

  The database includes a common schema and an individual schema corresponding to each tenant, and the common schema includes only common data accessible to each tenant and each corresponding tenant only. Each of the individual schemas has a view for accessing the actual data on the common schema, and the view uses the identification information of the tenant as a parameter, Only the unique data related to the tenant corresponding to the common data and the identification information can be accessed. The application determines the tenant used by the user, and accesses data on the database via the view of the individual schema corresponding to the determined tenant.

  Among the inventions disclosed in the present application, effects obtained by typical ones will be briefly described as follows.

  In other words, according to the representative embodiment of the present invention, in a mechanism for providing a service in a multi-tenant type, each tenant individually separates and holds unique data, and data common to each tenant is stored. These data are stored centrally and each tenant can be handled seamlessly.

It is the figure which showed the outline | summary about the structural example of the service provision system which is one embodiment of this invention.

  Hereinafter, embodiments of the present invention will be described in detail with reference to the drawings. Note that components having the same function are denoted by the same reference symbols throughout the drawings for describing the embodiment, and the repetitive description thereof will be omitted. On the other hand, parts described with reference numerals in some drawings may be referred to with the same reference numerals although not illustrated again in the description of other drawings.

  FIG. 1 is a diagram showing an outline of a configuration example of a service providing system according to an embodiment of the present invention. The service providing system 1 according to the present embodiment includes, for example, one or more application servers 10 and one or more databases (for example, server devices in a data center or virtual servers constructed on a cloud computing environment). DB) The server 20 is configured. A plurality of tenants share a shared service on the service providing system 1 to a user terminal 3 that is an information processing terminal used by a user such as a customer via a network (NW) 2 such as the Internet. The tenant provides the service.

  The application server 10 and the DB server 20 can communicate with each other via a network (not shown). However, the application server 10 and the DB server 20 are built on the same server system, and the processes can be performed without using the network. It is also possible to adopt a configuration in which communication is performed by communication or the like. In addition to the application server 10 and the DB server 20, for example, a web server or a load distribution server (not shown) may be included.

  The application server 10 includes units such as an application 11 and an authentication unit 12 that are implemented as software programs that run on middleware such as an OS (Operating System) and a DBMS (DataBase Management System) (not shown). Further, as will be described later, a connection pool function included in a general DBMS is used, and the connection pool management unit 13 is implemented as a component of the DBMS.

  The application 11 is a software program in which processing related to services and operations that the service providing system 1 can provide to the user terminal 3 is implemented. There are various specific processing contents depending on the contents of the service provided by the execution of the application 11, but at least a function of accessing the data held on the DB server 20 is provided. Basically, it is assumed that each tenant sharing the service providing system 1 is implemented by a common program or module.

  Whether the authentication unit 12 has authority to use the service provided by the service providing system 1 by referring to a user management table (not shown) or the like in response to a request from the application 11, for example. User authentication is performed. At that time, it is also determined which tenant the user is, and responds to the application 11 with respect to identification information (for example, “company code” and “tenant ID”) of the tenant to be used. When the application 11 generates a transaction related to the service, the application 11 specifies the identification information of the tenant related to the target user as an input parameter.

  The setting contents of the connection pool management unit 13 will be described later.

  On the other hand, the DB server 20 separates and stores the unique data (unique data) of each tenant as a database that operates on middleware such as an OS or DBMS (not shown), as described above. Data common to each tenant (common data) is stored centrally. In the present embodiment, the data structure as described above is realized by defining a plurality of schemas on a database by a schema function of a general DBMS.

  In the example of FIG. 1, individual schemas corresponding to access to the data of each tenant (in the figure, schemas A (21a) to D (21d) corresponding to four tenants A to D are shown. These may be collectively referred to as individual schemas 21), and a common schema 23 is defined. Although four individual schemas 21 are defined in the example of FIG. 1, the number of individual schemas 21 is actually defined by the number of tenants that provide services by the service providing system 1.

  In the common schema 23, common data 24 and unique data (in the figure, A unique data 25a to D unique data 25d corresponding to four tenants A to D are shown. Hereinafter, these are collectively referred to as unique data 25) Each of which is). These data may be held in different areas as different tables or the like, or the common data 24 and the plurality of unique data 25 may be held together in one table. In any case, each unique data 25 can be specified and accessed by identification information such as a company code that uniquely identifies the target tenant.

  Each individual schema 21 defines a view 22 for accessing data entities held on the common schema 23. In the present embodiment, the view 22 can access only the common data 24 that can be accessed regardless of the tenant and the specific data 25 related to the target tenant by receiving the designation of the identification information of the tenant as a parameter. Is defined as

  Specifically, for example, in the schema A (21a) corresponding to the tenant A, the identification information such as the company code of the tenant A is specified, whereby the A specified by the common data 24 and the identification information of the tenant A The access range is limited at the DBMS layer so that only the unique data 25a can be accessed. The same applies to the individual schemas 21 corresponding to other tenants, and the access range is limited so that only the common data 24 and the unique data 25 corresponding to the target tenant can be accessed. In the present embodiment, it is assumed that the application 11 is mounted so as to access the database only through the view 22.

  In this way, by restricting the application 11 to access only the data entity held on the common schema 23 through the view 22 of the individual schema 21 for each tenant, the data access range is determined by itself. Can only be limited to those related to tenants. As a result, the security is improved and the influence on the processing performance of other tenants due to the difference in the data amount for each tenant is suppressed. For example, when the amount of data held by tenant A is 100 times or 1000 times the amount of data held by tenant B, access to data related to tenant B is delayed due to a large amount of access to data related to tenant A We will suppress the possibility of such effects as much as possible.

  In the present embodiment, in response to dividing the schema (individual schema 21) for each tenant, the connection pool management unit 13 of the application server 10 further establishes a plurality of connections established for each individual schema 21 (in the figure). Are shown as connections (schema A) (15a) and connections (schema B) (15b) respectively corresponding to schema A (21a) and schema B (21b). Pooled connection pools (shown in the figure as connection pools (schema A) (14a) and connection pool (schema B) (14b) respectively corresponding to schema A (21a) and schema B (21b). May be collectively referred to as connection pool 14. ) It is assumed to create.

  It is assumed that the application 11 uses the connection 15 pooled in the connection pool 14 of the individual schema 21 corresponding to the target tenant when accessing the database. As a result, the application 11 automatically accesses the view 22 of the target individual schema 21 without being particularly aware of the range of accessible data due to tenant differences, and on the common schema 23 via the view 22. Access control is performed so that only the common data 24 and the company-specific data 25 can be accessed.

  Specifically, each connection 15 used by the application 11 is preset with identification information such as a company code of a tenant corresponding to the individual schema 21 to which the connection 15 belongs, and the view of the target individual schema 21 In 22, the tenant identification information is acquired from the attribute value of the connection 15 to be used and used as a parameter. In the example of FIG. 1, the company code “001” is set as the attribute value in the connection (schema A) 15a, and in the schema A (21a), the view 22 is changed from the attribute value of the connection (schema A) 15a to this company. The value of code “001” is acquired and used as a parameter. As a result, the range of accessible data is limited only to the common data 24 and the unique data 25 corresponding to its own company code “001”.

  For example, the application 11 determines the connection pool 14 to be used based on input information (information that can identify a tenant) in a transaction. For example, when the user authenticates the user through the authentication unit 12 at the start of use of the application 11, the authentication unit 12 responds together with the identification information of the tenant to which the user belongs, and sends this information to the session of the application 11. Keep it as related information. The application 11 uses the identification information as input information in the transaction.

  As for determination of the connection pool 14 used by the application 11, for example, when the application server 10 is started, a correspondence relationship between the identification information of the connection pool 14 and the tenant identification information is created in advance and held in a memory table or the like. The application 11 refers to this and identifies the corresponding connection pool 14 based on the identification information of the tenant to which the user belongs.

  For each connection 15 that is actually used by the application 11, as described above, identification information such as a tenant company code is set in the attribute value in advance. The setting of the identification information to the attribute value of the connection 15 is automatically set for each connection 15 using the DBMS logon trigger function when the connection pool 14 and the connection 15 are created when the application server 10 is started. can do.

  As described above, according to the present embodiment, the schema is divided for each tenant, and in addition to limiting the data access range with the common data 24 and the specific data 25, the connection pool 14 is individually provided for each schema. Accordingly, it is possible to easily realize seamless access to the common data 24 and the specific data 25 by concealing the portion related to the multi-tenant in the database access from the implementation of the application 11 by the DBMS layer. In addition to improving security among tenants, it is possible to reduce the influence on the overall processing performance based on the difference in the amount of data for each tenant and improve performance.

  As mentioned above, the invention made by the present inventor has been specifically described based on the embodiments. However, the present invention is not limited to the above-described embodiments, and various modifications can be made without departing from the scope of the invention. Needless to say. For example, the above-described embodiment has been described in detail for easy understanding of the present invention, and is not necessarily limited to the one having all the configurations described. In addition, it is possible to add, delete, and replace other configurations for a part of the configuration of the above-described embodiment.

  INDUSTRIAL APPLICABILITY The present invention can be used in a multi-tenant type service providing system that is used by a company that provides services individually in a multi-carpool.

1 ... service providing system, 2 ... network, 3 ... user terminal,
DESCRIPTION OF SYMBOLS 10 ... Application server, 11 ... Application, 12 ... Authentication part, 13 ... Connection pool management part, 14 ... Connection pool, 14a, b ... Connection pool (schema A, B), 15 ... Connection, 15a, b ... Connection (schema) A, B),
20 ... DB server, 21 ... Individual schema, 21a-d ... Schema A-D, 22 ... View, 23 ... Common schema, 24 ... Common data, 25 ... Specific data, 25a-d ... A-D specific data

Claims (3)

A service providing system in which a plurality of tenants jointly provide services to users via a network,
An application server having an application for executing processing related to the service;
A database server for storing data used for the processing on a database,
The database has a common schema and an individual schema corresponding to each tenant,
The common schema holds common data that can be commonly accessed by the tenants and unique data that can be accessed only by the corresponding tenants.
Each individual schema has a view for accessing actual data on the common schema,
The view can access only the unique data related to the tenant corresponding to the common data and the identification information, using the identification information of the tenant as a parameter,
The service providing system, wherein the application determines the tenant used by the user, and accesses data on the database via the view of the individual schema corresponding to the determined tenant. The service providing system according to claim 1,
The application server has a connection pool that pools a plurality of connections for the application to access the database for each individual schema,
The application identifies the connection pool according to the individual schema corresponding to the tenant determined to be used by the user, and accesses the database using the connection included in the identified connection pool. Service provision system. The service providing system according to claim 2,
The service providing system, wherein the tenant identification information corresponding to the individual schema related to the connection is set in the attribute value of the connection.

Images