Supporting multiple type users on a single type computing system - Patents.com

Abstract

The persistent storage may include a parent table and one or more child tables, the parent table including a class field specifying a type and one or more filter fields. The one or more processors may receive a first request to retrieve first information of a first type for a first entity, determine in a first entry of the parent table for the first entity that the first type is specified in the class field, obtain the first information from a child table associated with the first type, receive a second request to retrieve second information of a second type for a second entity, determine in a second entry of the parent table for the second entity that a filter field associated with the second type indicates that a second type is present, and obtain the second information from a set of additional fields in the second entry.

Description

[Technical field]

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This application claims priority to U.S. Patent Application No. 17 / 397,480, filed August 9, 2021, the entire contents of which are incorporated herein by reference. [Background technology]

[0002] A conventional organization of data objects stored in a remote network management platform or another form of cloud-based platform is by type of those data objects. In particular, user identities of users authorized to log in and / or otherwise access or use the platform are categorized into types (e.g., customer, vendor, or citizen). Such user identities are represented in database tables, and for each type of user, at least some of the data may be represented in a table dedicated to that type.

[0003] In these environments, the user's type can be used to determine the capabilities and functions the platform allows the user to access, such as permission to access certain data or use certain applications, information presented to the user on a graphical user interface when the user logs in, etc. Additionally, standard and custom software applications on the platform can be written based on the format of such tables and the concept that each user is of a single type. Thus, a single type user is considered a fundamental aspect of the platform.

[0004] In this regard, to support multiple types of users, the platform can set different user IDs for the users (one for each type), but this is inefficient because it requires additional records per user and wastes storage space. In addition, multi-type users must remember multiple passwords and switch between these user IDs to access all capabilities. Summary of the Invention

[0005] The embodiments described herein overcome this (and possibly other) limitations of conventional designs by providing backward-compatible support for multiple type users. In particular, these embodiments allow at least some existing software applications to continue to operate under the assumption of a single type user, while other software applications can support multiple type users. This is accomplished by simultaneously supporting the definition of user types in dedicated tables as well as in metadata stored in parent user tables. As a result, the remote network management platform (or other types of platforms) conserves storage space and provides a more intuitive and less burdensome user experience.

[0006] Thus, a first exemplary embodiment may include receiving a first request to retrieve first type-specific information of a first type for a first entity from persistent storage, the persistent storage including a parent table and one or more child tables, the parent table including (i) a class field specifying a type, and (ii) one or more type-specific filter fields, each of the types being associated with a different table from the one or more child tables, each of the one or more type-specific filter fields being associated with one or more of the types. The first exemplary embodiment may also include determining that in a first entry of the parent table for the first entity, the first type is specified in the class field. The first exemplary embodiment may also include obtaining the first type-specific information from a particular child table of the one or more child tables, the particular child table being associated with the first type. The first exemplary embodiment may also include providing the first type-specific information in response to the first request. The first exemplary embodiment may also include receiving a second request to retrieve second type-specific information of the second type for the second entity from the persistent storage. The first exemplary embodiment may also include determining that the second type is indicated as present by a particular type-specific filter field associated with the second type in a second entry of the parent table for the second entity. The first exemplary embodiment may also include obtaining the second type-specific information from a set of additional fields in the second entry of the parent table, the set of additional fields being associated with the particular type-specific filter field. The first exemplary embodiment may also include providing the second type-specific information in response to the second request.

[0007] A second exemplary embodiment may include receiving a first request to write first type-specific information of a first type for a first entity to persistent storage, the persistent storage including a parent table and one or more child tables, the parent table including (i) a class field specifying a type, and (ii) one or more type-specific filter fields, each of the types being associated with a different table from the one or more child tables, each of the one or more type-specific filter fields being associated with one or more of the types. The second exemplary embodiment may also include determining in a first entry of the parent table that the first type is specified in the class field. The second exemplary embodiment may also include writing the first type-specific information to a particular child table of the one or more child tables, the particular child table being associated with the first type. The second exemplary embodiment may also include receiving a second request to write second type-specific information of a second type for a second entity to persistent storage. The second example embodiment may also include determining that the second type is indicated as present by a particular type-specific filter field associated with the second type in a second entry of the parent table for the second entity. The second example embodiment may also include writing the second type-specific information to a set of additional fields in the second entry of the parent table, the set of additional fields being associated with the particular type-specific filter field.

[0008] In a third exemplary embodiment, an article of manufacture may include a non-transitory computer-readable medium having stored thereon program instructions that, when executed by a computing system, cause the computing system to perform the operations described in the first and / or second exemplary embodiments.

[0009] In a fourth exemplary embodiment, a computing system may include at least one processor as well as a memory and program instructions that may be stored in the memory and that, when executed by the at least one processor, may cause the computing system to perform the operations described in the first and / or second exemplary embodiments.

[0010] In the fifth exemplary embodiment, the system may comprise various means for performing the operations of the first and / or second exemplary embodiments, respectively.

[0011] These and other embodiments, aspects, advantages, and alternatives will become apparent to those skilled in the art upon reading the following detailed description, with reference to the accompanying drawings, as appropriate. Moreover, this summary, as well as other descriptions and figures set forth herein, are intended to illustrate embodiments by way of example only, and many variations are possible. For example, structural elements and process steps can be rearranged, combined, distributed, removed, or otherwise modified while remaining within the scope of the embodiments, as claimed. [Brief description of the drawings]

[0012] [Figure 1] FIG. 2 is a schematic diagram of a computing device according to an exemplary embodiment. [Diagram 2] FIG. 2 is a diagram of a server device cluster in accordance with an exemplary embodiment. [Diagram 3] FIG. 1 illustrates a remote network management architecture according to an exemplary embodiment. [Figure 4] FIG. 1 illustrates a communication environment including a remote network management architecture according to an exemplary embodiment. [Figure 5A] FIG. 2 illustrates another communication environment including a remote network management architecture according to an exemplary embodiment. [Figure 5B] 1 is a flow chart according to an exemplary embodiment. [Figure 6] FIG. 2 illustrates a database schema according to an exemplary embodiment. [Figure 7] FIG. 13 illustrates another database schema according to an exemplary embodiment. [Figure 8] FIG. 13 illustrates yet another database schema according to an exemplary embodiment. [Figure 9A] FIG. 1 illustrates a process for reading from a database according to an exemplary embodiment. [Figure 9B] FIG. 1 illustrates a process for writing to a database according to an exemplary embodiment. [Figure 10A] 1 is a flow chart according to an exemplary embodiment. [Figure 10B] 1 is a flow chart according to an exemplary embodiment. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0013] Exemplary methods, apparatus, and systems are described herein. It should be understood that the words "example" and "exemplary" are used herein to mean "serving as an example, instance, or illustration." Any embodiment or feature described herein as "example" or "exemplary" is not necessarily to be construed as preferred or advantageous over other embodiments or features, unless so stated. Thus, other embodiments can be utilized, and other changes can be made, without departing from the scope of the subject matter presented herein.

[0014] Accordingly, the exemplary embodiments described herein are not meant to be limiting in any way. It will be readily understood that the aspects of the present disclosure as described throughout this specification and illustrated in the drawings can be arranged, substituted, combined, separated, and designed in a wide variety of different configurations. For example, the separation of functionality into "client" and "server" components can be implemented in many ways.

[0015] Moreover, unless the context indicates otherwise, the features shown in each of the drawings can be used in combination with one another, with the understanding that the drawings should generally be viewed as component aspects of one or more overall embodiments, and that not all of the illustrated features are required for each embodiment.

[0016] Additionally, any recitation of elements, blocks, or steps in the specification or claims is for purposes of clarity, and therefore such recitation should not be construed as requiring or implying adherence to a particular arrangement of those elements, blocks, or steps, or performance in a particular order.

[0017] I. Introduction Large enterprises are complex entities with many interrelated activities. Some of these can be found across the enterprise, such as human resources (HR), supply chain, information technology (IT), and finance. However, each enterprise also has its own unique activities that provide critical capabilities and / or build competitive advantage.

[0018] To support a wide range of business operations, enterprises typically use off-the-shelf software applications, such as customer relationship management (CRM) and human capital management (HCM) packages. However, custom software applications may also be required to meet the unique requirements of the enterprise. Large enterprises often have dozens or even hundreds of these custom software applications. In contrast, the advantages provided by embodiments herein are not limited to large enterprises, but may be applicable to enterprises of any size or other types of organizations.

[0019] Many such software applications are developed by individual departments within a company. These range from simple spreadsheets to bespoke software tools and databases. However, the proliferation of disconnected, custom software applications has many drawbacks. This negatively impacts a company's ability to operate and grow its business, innovate, and meet regulatory requirements. Without a single system that integrates its subsystems and data, companies may find it difficult to integrate, streamline, and enhance their operations.

[0020] To efficiently generate custom applications, enterprises would benefit from remotely hosted application platforms that eliminate unnecessary development complexity. The goal of such platforms is to reduce time-consuming, repetitive application development tasks, allowing software engineers and other individuals to focus on developing high-value, unique functionality.

[0021] To achieve this goal, the concept of aPaaS (Application Platform as a Service) is introduced to intelligently automate workflows across the enterprise. aPaaS systems are hosted remotely from the enterprise but have access to the enterprise's data, applications, and services through a secure connection. Such aPaaS systems have many advantageous features and characteristics that are believed to improve the enterprise's operations and workflows in terms of IT, HR, CRM, customer service, application development, and security.

[0022] aPaaS systems may support the development and execution of Model-View-Controller (MVC) applications. MVC applications enable efficient code reuse and parallel development by separating the representation of information from the way that information is presented to the user by dividing each functionality into three interconnected parts (model, view, and controller). These applications may be web-based and provide create, read, update, and delete (CRUD) functionality, allowing new applications to be built on a common application infrastructure.

[0023] An aPaaS system may support standardized application components, such as a standardized set of widgets for graphical user interface (GUI) development. In this way, applications built using an aPaaS system have a common look and feel. Other software components and modules may be standardized as well. In some cases, this look and feel can be branded or skinned with a company's custom logo and / or color scheme.

[0024] aPaaS systems may support the ability to configure application behavior using metadata, allowing applications to quickly adapt their behavior to meet specific needs. Such an approach reduces development time and increases flexibility. Additionally, aPaaS systems may support GUI tools that make metadata creation and management easier, reducing metadata errors.

[0025] An aPaaS system may support well-defined interfaces between applications, allowing software developers to avoid unnecessary inter-application dependencies. To this end, an aPaaS system may implement a service layer where data such as persistent state information is stored.

[0026] An aPaaS system may support a rich set of integration capabilities so that applications on the system can interact with legacy and third-party applications. For example, an aPaaS system may support a custom employee training system that integrates with legacy HR, IT, and accounting systems.

[0027] The aPaaS system may support enterprise-level security. Additionally, because the aPaaS system may be hosted remotely, it should also utilize security procedures when interacting with enterprise systems or with third-party networks and services hosted outside the enterprise. For example, the aPaaS system may be configured to detect and identify common security threats by sharing data between parties such as enterprises.

[0028] There may also be other features, functions, and advantages of an aPaaS system. This description is for illustrative purposes and is not intended to be limiting in any way.

[0029] As an example of an aPaaS development process, a software developer may be tasked with creating a new application using an aPaaS system. The developer may first specify a data model that specifies the types of data the application will use and the relationships between each. The developer then inputs (e.g., uploads) the data model via the aPaaS system's GUI. The aPaaS system automatically creates all of the corresponding database tables, fields, and relationships, which are accessible through an object-oriented services layer.

[0030] The aPaaS system can also build a fully functional MVC application with a client-side interface and server-side CRUD logic. This generated application can serve as a basis for the user's further development. Developers do not need to spend a lot of time on the basic functionality of the application, which is convenient. Furthermore, the application can be web-based, so that it can be accessed from any internet-enabled client device. Alternatively or additionally, a local copy of the application can be accessed, for example, when internet service is not available.

[0031] Additionally, aPaaS systems may support a rich set of predefined features that can be added to applications, including search, email, templates, workflow design, reporting, analytics, social media, scripting, mobile output, and support for customized GUIs.

[0032] Such an aPaaS system may represent the GUI in a variety of ways. For example, a server machine in the aPaaS system may generate a representation of the GUI using a combination of HTML and JAVASCRIPT. The JAVASCRIPT may include client-side executable code, server-side executable code, or both. The server machine may send or otherwise provide this representation to the client machine so that the client machine displays it on its screen according to a locally defined look and feel. Alternatively, the representation of the GUI may be in some other form, such as an intermediate form (e.g., JAVA bytecode) that the client machine can use to generate graphical output directly. There are other possibilities.

[0033] Additionally, user interaction with GUI elements, such as buttons, menus, tabs, sliders, checkboxes, toggles, etc., may be referred to as "selecting," "activating," or "actuating," respectively. These terms may be used regardless of whether the interaction with the GUI element is through a keyboard, a pointing device, a touch screen, or another mechanism.

[0034] The aPaaS architecture is particularly effective when integrated with and used to manage an enterprise's network. The following embodiments describe the architecture and functional aspects of an exemplary aPaaS system, as well as respective features and advantages.

[0035] II. Exemplary Computing Device and Cloud-Based Computing Environment 1 is a simplified block diagram illustrating a computing device 100 showing some of the components that may be included on the computing device and configured to operate in accordance with embodiments herein. The computing device 100 may be a client device (e.g., a device that is actively operated by a user), a server device (e.g., a device that provides computing services to client devices), or some other type of computing platform. Some server devices may act as client devices at times to perform certain operations, and some client devices may incorporate server functionality.

[0036] In this example, computing device 100 includes a processor 102, memory 104, a network interface 106, and input / output units 108, all of which may be coupled by a system bus 110 or similar mechanism. In some embodiments, computing device 100 may include other components and / or peripherals (e.g., removable storage, printers, etc.).

[0037] The processor 102 may be one or more of any type of computer processing element, such as a central processing unit (CPU), a co-processor (e.g., a mathematical, graphics, or encryption co-processor), a digital signal processor (DSP), a network processor, and / or in the form of an integrated circuit or controller that performs processor operations. In some cases, the processor 102 may be one or more single-core processors. In other cases, the processor 102 may be one or more multi-core processors with multiple independent processing units. The processor 102 may also include a register memory for temporarily storing instructions and associated data to be executed, as well as a cache memory for temporarily storing recently used instructions and data.

[0038] Memory 104 may be any form of computer usable memory, including, but not limited to, random access memory (RAM), read only memory (ROM), and non-volatile memory (e.g., flash memory, hard disk drives, solid state drives, compact disks (CDs), digital video disks (DVDs), and / or tape storage). Thus, memory 104 represents both a main memory unit and long term storage. Other types of memory include biological memory.

[0039] The memory 104 may store program instructions and / or data on which the program instructions may operate. As an example, the memory 104 may store program instructions on a non-transitory computer-readable medium such that, upon execution by the processor 102, these instructions may perform any of the methods, processes, or operations disclosed herein or in the accompanying drawings.

[0040] As shown in FIG. 1, the memory 104 may include firmware 104A, kernel 104B, and / or applications 104C. The firmware 104A may be program code used to boot or start some or all of the computing device 100. The kernel 104B may be an operating system including modules for memory management, processor scheduling and management, input / output, and communication. The kernel 104B may also include device drivers that allow the operating system to communicate with the hardware modules (e.g., memory units, network interfaces, ports, and buses) of the computing device 100. The applications 104C may be one or more user space software programs, such as a web browser or email client, as well as any software libraries used by these programs. The memory 104 may also store data used by these and other programs and applications.

[0041] The network interface 106 may be in the form of one or more wired interfaces, such as Ethernet (e.g., Fast Ethernet, Gigabit Ethernet). The network interface 106 may also support communication over one or more non-Ethernet media, such as coaxial cable or power line, or wide area media, such as Synchronous Optical Networking (SONET) or Digital Subscriber Line (DSL) technologies. The network interface 106 may also be in the form of one or more wireless interfaces, such as IEEE 802.11 (Wifi), BLUETOOTH, Global Positioning System (GPS), or wide area wireless interfaces. However, other forms of physical layer interfaces and other types of standard or proprietary communication protocols may be used over the network interface 106. Furthermore, the network interface 106 may include multiple physical interfaces. For example, some embodiments of the computing device 100 may include Ethernet, BLUETOOTH, and Wifi interfaces.

[0042] The input / output unit 108 may facilitate user and peripheral interaction with the computing device 100. The input / output unit 108 may include one or more types of input devices, such as a keyboard, a mouse, a touch screen, etc. Similarly, the input / output unit 108 may include one or more types of output devices, such as a screen, a monitor, a printer, and / or one or more light emitting diodes (LEDs). Additionally or alternatively, the computing device 100 may communicate with other devices, for example, by using a Universal Serial Bus (USB) or a High Definition Multimedia Interface (HDMI) port interface.

[0043] In some embodiments, an aPaaS architecture may be supported by the deployment of one or more computing devices, such as computing device 100. The exact physical location, connectivity, and configuration of these computing devices may not be known and / or important to the client devices. Thus, the computing devices may be referred to as "cloud-based" devices that may be housed in a variety of remote data center locations.

[0044] Figure 2 illustrates a cloud-based server cluster 200 according to an example embodiment. In Figure 2, the operation of a computing device (e.g., computing device 100) may be distributed among server devices 202, data storage 204, and routers 206, all of which may be connected by a local cluster network 208. The number of server devices 202, data storage 204, and routers 206 in server cluster 200 may depend on the computing tasks and / or applications assigned to server cluster 200.

[0045] For example, server devices 202 may be configured to perform various computational tasks for computer device 100. Thus, computational tasks may be distributed to one or more server devices 202. To the extent that these computational tasks can be performed in parallel, such distribution of tasks may reduce the total time to complete these tasks and return results. For simplicity, both server cluster 200 and individual server devices 202 may be referred to as "server devices." This nomenclature should be understood as an implication that one or more different server devices, data storage devices, and cluster routers may be involved in the operation of a server device.

[0046] Data storage 204 may be a data storage array including a drive array controller configured to manage read and write access to a set of hard disk drives and / or solid state drives. The drive array controller may also be configured, alone or in conjunction with server devices 202, to manage backup or redundant copies of data stored on data storage 204 to protect against drive failure or other types of failure that would prevent one or more server devices 202 from accessing units of data storage 204. Other types of memory besides drives may also be used.

[0047] Router 206 may include network equipment configured to provide internal and external communications to server cluster 200. For example, router 206 may include one or more packet switching and / or routing equipment (including switches and / or gateways) configured to provide (i) network communications between server equipment 202 and data storage 204 via local cluster network 208, and / or (ii) network communications between server cluster 200 and other equipment via communications link 210 to network 212.

[0048] The configuration of router 206 may also be based at least in part on the data communications requirements of server equipment 202 and data storage 204, the latency and throughput of local cluster network 208, the latency, throughput, and cost of communications links 210, and / or other factors that may contribute to the cost, speed, fault tolerance, resilience, efficiency, and / or other design goals of the system architecture.

[0049] As one possible example, data storage 204 may include any form of database, such as a Structured Query Language (SQL) database. In such a database, various types of data structures may store information, including, but not limited to, tables, arrays, lists, trees, and tuples. Furthermore, any database in data storage 204 may be monolithic or distributed across multiple physical devices.

[0050] The server device 202 may be configured to transmit data to and / or receive data from the data storage 204. The transmission and retrieval may be in the form of SQL queries or other types of database queries and the output of such queries, respectively. Similarly, text, images, video, and / or audio may additionally be included. Furthermore, the server device 202 may organize the received data as a representation of a web page or web application. Such a representation may be in the form of a markup language, such as Hypertext Markup Language (HTML), Extensible Markup Language (XML), or some other standardized or proprietary format. Furthermore, the server device 202 may be capable of executing various types of computerized scripting languages, including, but not limited to, Perl, Python, PHP Hypertext Preprocessor (PHP), Active Server Pages (ASP), JAVASCRIPT, and the like. Computer program code written in these languages ​​may facilitate the provision of web pages to client devices as well as the client devices' interaction with the web pages. Alternatively or additionally, JAVA may be used to facilitate the generation of web pages and / or provide web application functionality.

[0051] III. Exemplary Remote Network Management Architecture 3 illustrates a remote network management architecture according to an example embodiment, which includes three main components: a managed network 300, a remote network management platform 320, and a public cloud network 340, all connected by the Internet 350.

[0052] A. Managed Network Managed network 300 may be, for example, an enterprise network used by an entity for computing and communication tasks as well as storage of data. To this end, managed network 300 may include client devices 302, server devices 304, routers 306, virtual machines 308, firewalls 310, and / or proxy servers 312. Client devices 302 may be embodied by computing devices 100, server devices 304 may be embodied by computing devices 100 or server clusters 200, and routers 306 may be any type of router, switch, or gateway.

[0053] The virtual machine 308 may be embodied by one or more of the computer device 100 and the server cluster 200. In general, a virtual machine is an emulation of a computing system that mimics the functionality (e.g., processor, memory, and communication resources) of a physical computer. A single physical computing system, such as the server cluster 200, can support up to thousands of individual virtual machines. In some embodiments, the virtual machines 308 may be managed by a centralized server device or application that facilitates allocation of physical computing resources to the individual virtual machines, as well as performance and error reporting. Enterprises often employ virtual machines to efficiently allocate computing resources as needed. Providers of virtualized computing systems include VMWARE® and MICROSOFT®.

[0054] Firewall 310 may be one or more dedicated routers or server devices that protect managed network 300 from unauthorized attempts to access internal devices, applications, and services while allowing legitimate communications originating from managed network 300. Firewall 310 may also provide intrusion detection, web filtering, virus scanning, application layer gateways, and other applications or services. In some embodiments not shown in FIG. 3, managed network 300 may include one or more virtual private network (VPN) gateways for communicating with a remote network management platform 320 (see below).

[0055] The managed network 300 may also include one or more proxy servers 312. An embodiment of the proxy server 312 may be a server application that facilitates communication and movement of data between the managed network 300, the remote network management platform 320, and the public cloud network 340. In particular, the proxy server 312 may be capable of establishing and maintaining secure communication sessions with one or more computing instances of the remote network management platform 320. Such sessions may enable the remote network management platform 320 to discover and manage aspects of the architecture and configuration of the managed network 300 and its components. In some cases, the proxy server 312 may also assist the remote network management platform 320 to discover and manage aspects of the public cloud network 340 that the managed network 300 uses.

[0056] A firewall such as firewall 310 typically denies all communication sessions coming in via Internet 350 unless such sessions ultimately originate behind the firewall (i.e., a device on managed network 300) and the firewall is explicitly configured to support the sessions. Locating proxy server 312 behind firewall 310 (e.g., by being located within managed network 300 and protected by firewall 310) may allow proxy server 312 to initiate these communication sessions through firewall 310. This may mean that firewall 310 does not need to be specially configured to support incoming sessions from remote network management platform 320, thus avoiding a potential security risk to managed network 300.

[0057] In some cases, managed network 300 may consist of just a few devices and a few networks. In other deployments, managed network 300 may span multiple physical locations and include hundreds of networks and hundreds of thousands of devices. Thus, the architecture shown in FIG. 3 can be scaled up or down by orders of magnitude.

[0058] Furthermore, the number of proxy servers 312 deployed may vary depending on the size, architecture, and connectivity of the managed network 300. For example, each proxy server 312 may be responsible for communicating with a remote network management platform 320 for a portion of the managed network 300. Alternatively or additionally, sets of two or more proxy servers may be assigned to such portions of the managed network 300 to provide load balancing, redundancy, and / or improved availability.

[0059] B. Remote Network Management Platform The remote network management platform 320 is a hosted environment that provides aPaaS services to users, particularly operators of the managed network 300. These services may be in the form of a web-based portal, for example using the web-based technologies mentioned above. This allows users to securely access the remote network management platform 320, for example from the client device 302 or potentially from a client device outside the managed network 300. The web-based portal allows users to design, test, and deploy applications, generate reports, review analytics, and perform other tasks. The remote network management platform 320 may also be referred to as a multi-application platform.

[0060] As shown in FIG. 3, the remote network management platform 320 includes four compute instances 322, 324, 326, and 328. Each of these compute instances may represent one or more nodes running a dedicated copy of the aPaaS software and / or one or more database nodes. Flexible placement of servers and databases on physical server equipment and / or virtual machines may be allowed and may change based on the needs of the enterprise. In combination, these nodes may provide a set of web portals, services, and applications available to a particular enterprise (e.g., a fully functional aPaaS system). In some cases, a single enterprise may use multiple compute instances.

[0061] For example, managed network 300 may be an enterprise customer of remote network management platform 320 and may use compute instances 322, 324, and 326. A reason for providing multiple compute instances to a customer may be that the customer desires to independently develop, test, and deploy its applications and services. Thus, compute instance 322 may be dedicated to developing applications associated with managed network 300, compute instance 324 may be dedicated to testing these applications, and compute instance 326 may be dedicated to live operation of the tested applications and services. Computing instances may also be referred to as hosted instances, remote instances, customer instances, or some other designation. Any application deployed to a computing instance may be considered a scoped application in that access to the database within the computing instance may be restricted to specific elements therein (e.g., specific database table(s) or specific rows within one or more database tables).

[0062] For simplicity, this disclosure refers to the configuration of application nodes, database nodes, the aPaaS software running thereon, and the underlying hardware as a "computing instance." Note that users may colloquially refer to the graphical user interface provided thereby as an "instance." However, unless otherwise defined herein, a "computing instance" is a computing system disposed within the remote network management platform 320.

[0063] The multi-instance architecture of the remote network management platform 320 provides several advantages as opposed to traditional multi-tenant architectures. In a multi-tenant architecture, data from different customers (e.g., enterprises) is mixed in a single database. The data of these customers is isolated from each other, but this isolation is enforced by the software that operates the single database. As a result, a security breach in the system affects all of the customers' data, creating additional risks, especially for government, healthcare, and / or financial regulated entities. Furthermore, any database operation that affects one customer may affect all customers that share the database. Thus, in the case of an outage due to a hardware or software error, the outage affects all such customers. Similarly, when a database is upgraded to meet the needs of one customer, the upgrade process makes it unavailable to all customers. Such maintenance windows are often long due to the size of the shared database.

[0064] In contrast, a multi-instance architecture provides each customer with its own database in a dedicated compute instance. This prevents intermingling of customer data and allows for independent management of each instance. For example, if one customer's instance goes down due to an error or upgrade, other compute instances are not affected. Maintenance downtime is limited because the database contains only one customer's data. In addition, the simpler design of a multi-instance architecture allows redundant copies of each customer database and instance to be deployed geographically diversely. This promotes high availability and allows the live version of a customer's instance to be moved when a failure is detected or maintenance is performed.

[0065] In some embodiments, the remote network management platform 320 may include one or more central instances controlled by the entity that operates the platform. Similar to the computing instances, the central instance may include several application and database nodes distributed on several physical server devices or virtual machines. Such a central instance may act as a repository for the computing instances as well as a particular configuration of data that may be shared by at least some of the computing instances. For example, there may be definitions of common security threats that may occur on the computing instances, software packages commonly found on the computing instances, and / or an application store for applications that may be deployed on the computing instances. The computing instances may communicate with the central instance by well-defined interfaces to obtain this data.

[0066] To efficiently support multiple computing instances, remote network management platform 320 may run multiple of these instances on a single hardware platform. For example, when running on a server cluster, such as server cluster 200, the aPaaS system may run virtual machines that allocate different amounts of computing, storage, and communication resources to the instances. However, full virtualization of server cluster 200 is not required, and other mechanisms may provide for isolation of instances. In some examples, each instance may have a dedicated account on server cluster 200 as well as one or more dedicated databases. Alternatively, a computing instance, such as computing instance 322, may span multiple physical devices.

[0067] In some cases, a single server cluster of remote network management platform 320 may support multiple independent enterprises. Additionally, as described below, remote network management platform 320 may include multiple server clusters deployed in geographically diverse data centers to facilitate load balancing, redundancy, and / or high availability.

[0068] C. Public Cloud Networks Public cloud network 340 may be remote server equipment (e.g., multiple server clusters, such as server cluster 200) available for outsourced computing, data storage, communication, and service hosting activities. These servers may be virtualized (i.e., virtual machines). Examples of public cloud network 340 include AMAZON WEB SERVICES® and MICROSOFT® AZURE®. Similar to remote network management platform 320, multiple server clusters supporting public cloud network 340 may be deployed in diverse geographic locations for load balancing, redundancy, and / or high availability purposes.

[0069] The managed network 300 may use one or more public cloud networks 340 to deploy applications and services to its clients and customers. For example, if the managed network 300 provides an online music streaming service, the public cloud network 340 may store the music files and provide a web interface and streaming capabilities. In this way, the businesses in the managed network 300 do not need to build and maintain their own servers for these operations.

[0070] The remote network management platform 320 may include modules that expose internal virtual machines and managed services to the managed network 300 through integration with the public cloud network 340. These modules may enable users to request virtual resources, discover allocated resources, and flexibly report to the public cloud network 340. To establish this functionality, a user of the managed network 300 may first open an account with the public cloud network 340 and request a set of related resources. The user may then input the account information into the appropriate modules of the remote network management platform 320. These modules may then automatically discover the manageable resources of the account and provide reports related to usage, performance, and billing.

[0071] D. Communications Support and Other Operations Internet 350 may represent a portion of the global Internet, although Internet 350 may alternatively represent different types of networks, such as private wide-area or local-area packet-switched networks.

[0072] Figure 4 further illustrates the communication environment between managed network 300 and computing instances 322, introducing additional features and alternative embodiments. In Figure 4, all or a portion of computing instances 322 are replicated in both data centers 400A and 400B. These data centers may be geographically separate from one another, perhaps in different cities or different countries. Each data center includes managed network 300 as well as supporting facilities that facilitate communication with remote users.

[0073] In the data center 400A, network traffic to external devices flows through a VPN gateway 402A or a firewall 404A. The VPN gateway 402A may be peered with a VPN gateway 412 of the managed network 300 by a security protocol such as Internet Protocol Security (IPSEC) or Transport Layer Security (TLS). The firewall 404A may be configured to allow access from authorized users, such as the user 414 and the remote user 416, and to deny access to unauthorized users. The firewall 404A allows these users to access the computing instance 322 and possibly other computing instances. The load balancer 406A may be used to distribute traffic among one or more physical or virtual server devices hosting the computing instance 322. The load balancer 406A may simplify user access by hiding the internal configuration of the data center 400A (e.g., the computing instance 322) from client devices. For example, if a computing instance 322 includes multiple physical or virtual computing machines that share access to multiple databases, the load balancer 406A may distribute network traffic and processing tasks among those computing machines and databases so that some computing machines or databases are not significantly busier than others. In some embodiments, a computing instance 322 may include a VPN gateway 402A, a firewall 404A, and a load balancer 406A.

[0074] Data center 400B may have its own versions of the components of data center 400A, such that VPN gateway 402B, firewall 404B, and load balancer 406B may perform the same or similar operations as VPN gateway 402A, firewall 404A, and load balancer 406A, respectively. Additionally, computing instances 322 may exist simultaneously in data centers 400A and 400B, with real-time or near real-time database replication and / or other operations.

[0075] Data centers 400A and 400B as shown in Figure 4 may facilitate redundancy and high availability. In the configuration of Figure 4, data center 400A is active and data center 400B is passive. Thus, data center 400A serves all traffic for managed network 300 while the versions of computing instances 322 in data center 400B are updated in near real-time. Other configurations, such as a configuration in which both data centers are active, may be supported.

[0076] If data center 400A experiences some kind of failure or becomes unavailable to users, data center 400B can take over as the active data center. For example, a Domain Name System (DNS) server that associates the domain name of computing instance 322 with one or more Internet Protocol (IP) addresses of data center 400A may reassociate the domain name with one or more IP addresses of data center 400B. After this reassociation is complete (which may take less than a second or a few seconds), computing instance 322 is made accessible to users by data center 400B.

[0077] FIG. 4 also illustrates possible configurations of managed network 300. As described above, proxy server 312 and users 414 can access compute instance 322 through firewall 310. Proxy server 312 can also access configuration items 410. In FIG. 4, configuration items 410 may represent any or all of client device 302, server device 304, router 306, and virtual machine 308, any applications or services running thereon, as well as relationships between the devices, applications, and services. Thus, the term "configuration item" may be shorthand for any physical or virtual device, any application or service capable of being remotely discovered or managed by compute instance 322, or relationships between discovered devices, applications, and services. Configuration items may be represented in a configuration management database (CMDB) of compute instance 322.

[0078] As mentioned above, VPN gateway 412 may provide a dedicated VPN to VPN gateway 402A. Such a VPN may be useful when there is a large amount of traffic between managed network 300 and compute instance 322, or when security policies suggest or require the use of a VPN between these sites. In some embodiments, any device of managed network 300 and / or compute instance 322 that communicates directly through the VPN may be assigned a public IP address. Other devices of managed network 300 and / or compute instance 322 may be assigned a private IP address (e.g., an IP address selected from the ranges 10.0.0.0-10.255.255.255 or 192.168.0.0-192.168.255.255, abbreviated as subnets 10.0.0.0 / 8 and 192.168.0.0 / 16, respectively).

[0079] IV. Exemplary Device, Application, and Service Discovery To manage the devices, applications, and services of the managed network 300, the remote network management platform 320 may initially determine the devices present in the managed network 300, their configurations and operational states, and the applications and services they provide, as well as the relationships between the discovered devices, applications, and services. As mentioned above, each device, application, service, and relationship may be referred to as a configuration item. The process of defining the configuration items in the managed network 300 is referred to as discovery, and may be facilitated, at least in part, by the proxy server 312.

[0080] For purposes of embodiments herein, an "application" may represent one or more processes, threads, programs, client modules, server modules, or any other software running on a device or group of devices. A "service" may represent advanced functionality provided by multiple applications running on one or more devices acting in conjunction with each other. For example, an advanced web service may include multiple web application server threads running on one device accessing information from a database application running on another device.

[0081] 5A is a logical depiction of how configuration items may be discovered, as well as how information associated with the discovered configuration items may be stored. For simplicity, the remote network management platform 320, the public cloud network 340, and the Internet 350 are not shown.

[0082] 5A, the CMDB 500 and task list 502 are stored in the computation instance 322. The computation instance 322 may send a discovery command to the proxy server 312. In response, the proxy server 312 may send probes to various devices, applications, and services in the managed network 300. These devices, applications, and services may send responses to the proxy server 312, which may then provide information about the discovered configuration items to the CMDB 500 for storage. The configuration items stored in the CMDB 500 represent the environment of the managed network 300.

[0083] Task list 502 represents a list of actions that proxy server 312 is to perform on behalf of computation instance 322. When a detection occurs, an entry is made in task list 502. Proxy server 312 repeatedly queries task list 502 to obtain the next task therein and executes this task until task list 502 is empty or another stop condition is reached.

[0084] To facilitate discovery, a proxy server 312 may be configured with information about one or more subnets in managed network 300 that are reachable by the proxy server 312. For example, the proxy server 312 may be given the IP address range 192.168.0 / 24 as a subnet. The computing instance 322 may then store this information in the CMDB 500 and place tasks in the task list 502 to discover devices at each of these addresses.

[0085] 5A also illustrates the devices, applications, and services in managed network 300 as configuration items 504, 506, 508, 510, and 512. As discussed above, these configuration items represent a set of physical and / or virtual devices (e.g., client devices, server devices, routers, or virtual machines), the applications running on them (e.g., web servers, email servers, databases, or storage arrays), the relationships between them, as well as services that include multiple individual configuration items.

[0086] Placing a task in the task list 502 may trigger or cause the proxy server 312 to initiate detection. Alternatively or additionally, detection may be manually or automatically triggered based on a triggering event (e.g., detection may be initiated automatically once a day at a particular time).

[0087] In general, discovery can take place in four logical stages: scanning, classification, identification, and exploration. Each stage of discovery involves different types of probe messages being sent by the proxy server 312 to one or more devices in the managed network 300. Responses to these probes may be received and processed by the proxy server 312, with respective representations sent to the CMDB 500. Thus, with each stage, more configuration items may be discovered and stored in the CMDB 500.

[0088] During the scan phase, the proxy server 312 may determine the general type of device by probing each IP address within a specified range of IP addresses for open Transmission Control Protocol (TCP) and / or User Datagram Protocol (UDP) ports. The presence of such open ports at an IP address indicates that a particular application is running on the device to which that IP address is assigned, which may identify the operating system used by the device. For example, if TCP port 135 is open, the device is likely running a WINDOWS operating system. Similarly, if TCP port 22 is open, the device is likely running a UNIX operating system such as LINUX. If UDP port 161 is open, the device may be otherwise identifiable through Simple Network Management Protocol (SNMP). There are other possibilities. Once the presence of a device and its open ports at a particular IP address is detected, these configuration items are stored in the CMDB 500.

[0089] During the classification phase, the proxy server 312 may further probe each detected device to determine its operating system version. The probes used for a particular device are based on information collected about the device during the scan phase. For example, if a device is found with TCP port 22 open, a set of UNIX-specific probes may be used. Similarly, if a device is found with TCP port 135 open, a set of WINDOWS-specific probes may be used. In either case, an appropriate set of tasks may be placed in the task list 502 for the proxy server 312 to execute. These tasks enable the proxy server 312 to log on to or access information from the particular device. For example, if TCP port 22 is open, the proxy server 312 may be instructed to open a Secure Shell (SSH) connection to the particular device and retrieve information about the operating system on the device from a particular location in the file system. Based on this information, the operating system may be determined. As an example, a UNIX® device with an open TCP port 22 may be classified as AIX®, HPUX, LINUX®, MACOS®, or SOLARIS®. This classification information may be stored in the CMDB 500 as one or more configuration items.

[0090] During the identification phase, the proxy server 312 may determine specific details about the classified device. The probes used during this phase may be based on information collected about the particular device during the classification phase. For example, if the device is classified as LINUX, a set of LINUX specific probes may be used. Similarly, if the device is classified as WINDOWS 2012, a set of WINDOWS 2012 specific probes may be used. As with the classification phase, an appropriate set of tasks may be placed in the task list 502 for the proxy server 312 to execute. These tasks enable the proxy server 312 to retrieve information from the particular device, such as basic input / output system (BIOS) information, serial numbers, network interface information, media access control addresses assigned to those network interfaces, IP addresses used by the particular device, etc. This identification information may be stored in the CMDB 500 as one or more configuration items.

[0091] During the discovery phase, the proxy server 312 may determine further details regarding the operational status of the classified device. The probes used during this phase may be based on information collected about the particular device during the classification and / or identification phase. Again, a suitable set of tasks may be placed in the task list 502 for the proxy server 312 to execute. These tasks enable the proxy server 312 to retrieve additional information from the particular device, such as processor information, memory information, list of running processes (applications), etc. Here again, the detection information may be stored in the CMDB 500 as one or more configuration items.

[0092] Discovery may be performed on network devices such as routers using SNMP. As an alternative or in addition to determining a list of running processes or other application related information, discovery may involve the router determining additional subnets known to it and the operational state (e.g., active, inactive, queue lengths, number of dropped packets, etc.) of the router's network interfaces. The IP addresses of the additional subnets may be candidates for further discovery procedures. Thus, discovery may proceed in an iterative or recursive manner.

[0093] Once discovery is complete, a snapshot representation of each discovered device, application, and / or service is available in CMDB 500. For example, after discovery, operating system versions, hardware configurations, and network configuration details of client devices, server devices, and routers in managed network 300 may be stored, as well as the applications running on them. This collected information may be presented to a user in a variety of ways to allow the user to view the hardware configuration and operational status of devices, as well as the characteristics of services across multiple devices and applications.

[0094] Further, the CMDB 500 may include entries regarding dependencies and relationships between configuration items. More specifically, applications running on a particular server device as well as services that depend on the applications may be represented in this manner in the CMDB 500. For example, a database application may be running on a server device and may be used for a new employee training service as well as a payroll service. Thus, if the server device is taken out of service for maintenance, the employee training service and the payroll service will obviously be affected. Similarly, dependencies and relationships between configuration items may represent services that are affected if a particular router fails.

[0095] Typically, dependencies and relationships between configuration items may be displayed in a web-based interface and represented as a hierarchy, so that adding, modifying, or deleting such dependencies and relationships may be accomplished through this interface.

[0096] Additionally, users of managed network 300 can develop workflows that allow for the execution of specific coordinated actions across multiple discovered devices. For example, an IT workflow could allow a user to change a common administrator password for all discovered LINUX devices in a single operation.

[0097] To allow such discovery to occur, the proxy server 312, the CMDB 500, and / or one or more credential stores may be configured with credentials for one or more of the devices to be discovered. The credentials may include any type of information required to access the devices. These may include user ID / password pairs, certificates, etc. In some embodiments, these credentials may be stored in encrypted fields in the CMDB 500. The proxy server 312 may include decryption keys for these credentials so that the credentials can be used to log on to or access the devices to be discovered.

[0098] FIG. 5B illustrates the discovery process as a flow chart. In block 520, a task list in the computing instance is populated with, for example, various IP addresses. In block 522, a scanning phase occurs, whereby the proxy server probes the devices using these IP addresses by IP address and attempts to determine the operating system running on these devices. In block 524, a classification phase occurs, whereby the proxy server attempts to determine the operating system version of the detected devices. In block 526, an identification phase occurs, whereby the proxy server attempts to determine the hardware and / or software configuration of the detected devices. In block 526, a discovery phase occurs, whereby the proxy server attempts to determine the operational state and applications running on the detected devices. In block 530, further editing of configuration items representing the detected devices and applications can occur. This editing can be automated and / or manual in nature.

[0099] The blocks depicted in Figure 5B are examples. Detection may be a highly configurable procedure, with more or fewer stages possible, and each stage may operate differently. In some cases, one or more stages may be customized or may deviate from the exemplary description above.

[0100] In this manner, the remote network management platform can discover and inventory the hardware, software, and services deployed and provided on the managed network. As described above, this data may be stored as configuration items in the CMDB of the associated computing instance. For example, individual hardware components (e.g., computing devices, virtual servers, databases, routers, etc.) may be represented as hardware configuration items, while applications installed and / or executed thereon may be represented as software configuration items.

[0101] The relationships of software configuration items installed or executed on a hardware configuration item may be in various forms, such as hosting, executing, or depending. Thus, a database application installed on a server device may have a "hosting" relationship with the server device to indicate that the database application is hosted on the server device. In some embodiments, a server device may have a "using" mutual relationship with the database application to indicate that the server device is used by the database application. While these relationships may be discovered automatically using the discovery procedures described above, the relationships may also be configured manually.

[0102] Also, the relationship between a service and one or more software configuration items may take various forms. As an example, a web service may include a web server software configuration item and a database application software configuration item, each installed on a different hardware configuration item. The web service may have a "depends" relationship with these software configuration items, while the software configuration items have a "uses" interrelationship with the web service. Services may not be fully determined by a discovery procedure, but instead may rely on service mapping (e.g., examining configuration files and / or performing network traffic analysis to determine service level relationships between configuration items) and possibly some degree of manual configuration.

[0103] Regardless of how it is obtained, relationship information can be beneficial to the operation of a managed network. Among other things, IT personnel can quickly determine where specific software applications are deployed and the configuration items that make up the services. This allows for quick identification of the root cause of a service outage or degradation. For example, if two different services have slow response times, a CMDB query can determine (among other possible actions) that the root cause is high processor utilization in a database application used by both services. IT personnel can then address the database application without wasting time considering the health and performance of other configuration items that make up the services.

[0104] V. Example Database Schema for Multi-Type Users As described above, a computing instance may facilitate the use of numerous software applications by a large number of users. Each user may have a unique identifier (e.g., a user ID) that can be used to log on to the computing instance to access these software applications. User records may be stored as entries in one or more database tables that define information about the users and their respective capabilities. Each user may be assigned a particular type or class, such as a customer (if a customer of the entity that manages the computing instance), a vendor (if a vendor of the entity that manages the computing instance), or a citizen (if a national or resident of the country or jurisdiction that manages the computing instance).

[0105] The computing instances (and possibly the entire remote network management platform) may be designed to operate in a table-per-class (TPC) model (sometimes referred to as an extension model) that allows for an object-oriented, hierarchical definition of data. In the case of a user application, the relevant embodiment may be in the form of a parent table that contains information about all users, as well as a designation of each user's type. In addition, each type of user may have its own table (child table), which defines information specific to users of that class. Thus, while a type (class) of user may possibly have a one-to-one mapping to a child table, such a relationship is not required. These child tables may have their own additional child tables that designate additional subtypes of users.

[0106] As used herein, the terms "type" and "class" may be used interchangeably unless the context indicates otherwise. The term "class" reflects the object-oriented hierarchy that can be employed, while the term "type" is often preferred because it is more descriptive.

[0107] Figure 6 illustrates one possible implementation of the TPC model for users. A database schema 600 defines four tables: a users table 602 (parent), as well as a customers table 604, a vendors table 606, and a citizens table 608 (children). Notably, this is only one possible arrangement of users into classes. Other kinds of classes (e.g., employees and contractors) are also possible.

[0108] The users table 602 provides columns for ID (a unique identifier for each entry in the users table 602 (e.g., a user ID)), name (the name of the individual associated with the entry), email (the email address of the individual associated with the entry), and other fields that may include any type of information related to the user, such as a mailing address, a hashed password, single sign-on (SSO) data, default user interface display options, etc.

[0109] Each type (class) of user represented in User table 602 has its own child table, each of which stores additional information about users of that type. In Figure 6, the relationships between entries in User table 602 and entries in Customer table 604, Vendor table 606, and Citizen table 608 are shown as dotted lines with arrows.

[0110] For example, the first entry in User table 602 has an ID of 00001 and a class of Customer. Therefore, an entry for this user exists in Customer table 604. That entry has the same ID of 00001, and fields in Customer table 604 define other customer-specific information for the user, such as a customer account number. Similarly, the second entry in User table 602 has an ID of 00002 and a class of Vendor. Therefore, an entry for this user exists in Vendor table 606. That entry has the same ID of 00002, and fields in Vendor table 606 define other vendor-specific information for the user, such as the vendor name.

[0111] This hierarchical organization works well for many systems, except that it supports only one parent class per user. However, there are many types of systems in which some users can exist in multiple classes. For example, a customer of an entity can also be a vendor of that entity. Similarly, a citizen of a governmental entity can also be a vendor of that governmental entity. The traditional TPC model is not extensible to reflect such configurations.

[0112] As a workaround, a user with multiple types may be given multiple user IDs in the system, one for each type. This is reflected in Figure 6, where user Jan Smith has two entries in User table 602, as a customer (ID 00001) and as a citizen (ID 00003). Thus, an entry for Jan Smith (as ID 00003) exists in Citizen table 608. Fields in Citizen table 608 define other citizen-specific information for Jan Smith, such as an administrative number (e.g., Social Security number, driver's license number, or some other type of number). Each of Jan Smith's two entries in User table 602 specifies a different email address, and other fields in the two entries may differ as well.

[0113] While this configuration allows a multi-type user to access all information associated with each type, it can become cumbersome: a user must keep track of their role (defined by type) whenever they log on to a compute instance. If a user needs to access information associated with a different one of their roles, they must log out and re-login to the compute instance using the set of credentials associated with the other role (e.g., Jan Smith may need to log out and then re-login to her customer account to access data from her citizen account).

[0114] In this case, a multi-type user would need to remember or track multiple login credentials, one for each type. This can be cumbersome, especially since some users may have more than two types. Furthermore, each entry in the user table 602 for the same user may contain some duplicate information about that user, occupying additional storage space in the database. Thus, from a storage perspective, the technique for supporting such multi-type users is inefficient.

[0115] In some circumstances, an improved model may be possible in which some or all of the user types are aggregated in a parent table (e.g., user table 602). This may eliminate child tables and even hierarchies of tables. For example, all fields from all child tables may be moved to user table 602, and filter fields may be used to specify the type to which the user belongs. If a type's filter field indicates that the user is of that type, then the type-specific fields are assumed to be valid. If a type's filter field indicates that the user is not of that type, then the type-specific fields are assumed to be invalid. Thus, although in some cases there may be a one-to-one relationship between type-specific filter fields and types, such a one-to-one relationship is not required. In some implementations, more than one field may be used as a filter field for a particular type (e.g., the information for determining whether a user is of a particular type may be split across multiple fields).

[0116] Figure 7 shows a database schema 700 that uses such a single table structure. In the Users table 702, each entry is associated with a single user who may have multiple types. There are three Boolean filter fields for types: customer, vendor, and citizen. If the user is a member of one of the associated types, the filter field for that type is set to "Yes." Otherwise, the filter field is set to "No."

[0117] Continuing with the previous example, user Jan Smith is a customer and citizen type, so the customer and citizen filter fields in his entry in users table 702 are set to "yes." Jan Smith is not a vendor type, so the vendor filter field in his entry is set to "no." Conversely, user Rob Jones is not a customer or citizen type, so the customer and citizen filter fields in his entry in users table 702 are set to "no." Rob Jones is a vendor type, so the vendor filter field in his entry is set to "yes."

[0118] If the filter field is set to "Yes," one or more additional fields may be enabled. In the User table 702, the Customer filter field is set to "Yes" to indicate that the Customer Account field is enabled, the Vendor filter field is set to "Yes" to indicate that the Vendor Name field is enabled, and the Citizen filter field is set to "Yes" to indicate that the Administrative Number field is enabled. If any of these additional fields are not enabled, this is indicated by the notation "N / A" and may be represented in the database by an empty string or null value.

[0119] Thus, a software application wanting to determine Jan Smith's customer account would first verify that the customer filter field is "yes" and then read the value from the customer account field. Similarly, a software application wanting to determine Jan Smith's administrative number would first verify that the citizen filter field is "yes" and then read the value from the administrative number field.

[0120] In general, there may be other fields in the Users table 702, including one or more additional fields that are only valid if a particular filter field is set to "Yes." The Users table 702 is intended for illustrative purposes to be a simplified illustration of one implementation of a single table.

[0121] Although the database structure and associated operations described in the background of Figure 7 are an effective way to support multiple types of users, their usefulness is limited by the fact that the installed base of user entries in computing instances is often large. For example, a deployed remote network management platform may support a large number of computing instances, each supporting hundreds, thousands, or tens of thousands of users.

[0122] Furthermore, both out-of-the-box and customized software applications installed on a platform where user information is arranged according to Schema 600 may be written to work with the multi-table approach of that schema. Thus, when attempting to deploy a computing instance with Schema 700 or upgrading a computing instance from Schema 600 to Schema 700, a large number of software applications may be unable to locate user entries in the database. As a result, users may not be able to log on to the platform, making it effectively unusable. Thus, a more sophisticated approach is needed.

[0123] 8 shows a database schema 800 that supports multiple type users that are backward compatible with the TPC model of schema 600 through the use of a combined single-table and multi-table structure. In particular, schema 800 includes a user table 802 that has all the fields of user tables 602 and 702. Thus, user table 802 includes a class field, a customer filter field, a vendor filter field, and a citizen field, as well as any additional fields that are also specified in customer table 804, vendor table 806, and citizen table 808. With respect to these three child tables, customer table 804 includes customer-specific fields, vendor table 806 includes vendor-specific fields, and citizen table 808 includes citizen-specific fields. Thus, these tables can be the same as the corresponding tables in FIG. 6. Furthermore, in some but not all embodiments, there may be a one-to-one relationship between a type-specific filter field and the child table of that type.

[0124] Type-specific information related to a user may appear in the Users table 802 or in a child table associated with the type. This distinction is based on whether the class field in the Users table 802 is populated. If this is true, then the type-specific information related to the class is in the associated child table. If this is not true, but the type-specific filter for the type is set to "Yes," then type-specific information related to the class may appear in an additional field for the type in the Users table 802. If the class field in the Users table 802 is not populated and the type-specific filter for the type is set to "No," then there is no type-specific information for the type (and therefore the user is not of that type).

[0125] As an example, the entry for Jan Smith in the Users table 802 has Customer populated in the Type of class field. This indicates that an entry exists for Jan Smith in the Customers table 804. This entry provides additional customer-specific information related to Jan Smith (e.g., her customer account). Therefore, the Customer filter for Jan Smith is set to "No" and the Customer Account field in the Users table 802 is not valid.

[0126] Jan Smith's vendor filter field is also set to "No," indicating that her vendor name field in Users table 802 is also invalid. Note that because Jan Smith's class field in Users table 802 has a value of Customer, there is likely no entry for her in Vendors table 806.

[0127] Jan Smith's Citizen Filter field is set to "Yes", indicating that her Administrative Number field in Users table 802 is valid, and therefore is populated in Users table 802. Again, because Jan Smith's Class field in Users table 802 has a value of Customer, there would not be an entry for her in Citizen table 808.

[0128] Thus, Jan Smith's information is split between users table 802 and customers table 804. This configuration supports an environment where a traditional database schema (e.g., schema 600) is used to specify her customer specific information, and therefore that data should remain for backward compatibility with legacy software applications. However, her citizen specific information is maintained in users table 802. This effectively makes Jan Smith multi-type for new applications.

[0129] In contrast, Rob Jones is only one type, vendor, so all of his vendor-specific information is stored in the Users table 802. In that table, his class field is set to null or a default value, indicating that his entry does not exist in the child tables and that his type can be determined by looking at the values ​​of his customer filter, vendor filter, and citizen filter fields. Naturally, only his vendor filter field is set to "Yes." Thus, while the values ​​of his customer-specific and citizen-specific fields are valid, the value of his vendor-specific field is valid. More types can be added for any user by using the appropriate additional fields in the Users table 802.

[0130] Although schema 800 shows the user table 802 or a child table being used to store all information specific to a given type of user, other configurations for splitting information between tables are possible. Additionally, multiple type users may have all of their type-specific information stored in user table 802. Other configurations are also possible.

[0131] Given that schema 800 is backward compatible with legacy software applications, such legacy applications do not need to be modified to continue working with schema 800, so long as all type-specific information for a particular type of interest to the application resides in the child tables. However, non-legacy software applications need to be able to check both the parent table and the type-specific child tables for this information. Figures 9A and 9B show how this is done for reads and writes, respectively.

[0132] 9A is a flow chart illustrating the processing performed by a computing instance in response to a read request. In particular, at step 900, a type-specific read request arrives at a computing instance. The read request seeks to obtain type-specific information of type T for a user U.

[0133] In step 902, the compute instance determines whether user U exists in the parent table (eg, user table 802). If not, in step 904, the compute instance returns an error because user U does not exist in the system.

[0134] If user U exists in the parent table, then in step 906 the computation instance determines whether type T is specified in the class field of the parent table. If this is true, then in step 908 the computation instance reads type-specific information for user U from the child table associated with type T.

[0135] If type T is not specified in the class field of the parent table, then in step 910 the compute instance determines whether a filter field of type T in the parent table is set (e.g., has a value of "yes"). If not, then in step 912 the compute instance returns an error because user U is not of type T. If so, then in step 914 the compute instance reads type-specific information from an additional field in the parent table that is associated with type T.

[0136] 9B is a flow chart illustrating the processing performed by a compute instance in response to a write request. In particular, at step 950, a type-specific write request arrives at a compute instance. The write request seeks to store type-specific information of type T for a user U.

[0137] In step 952, the compute instance determines whether user U exists in the parent table (eg, user table 802). If not, in step 954, the compute instance returns an error because user U does not exist in the system.

[0138] If user U exists in the parent table, then in step 956 the compute instance determines whether type T is specified in the class field of the parent table. If this is true, then in step 958 the compute instance writes type-specific information for user U to the child table associated with type T.

[0139] If type T is not specified in the class field of the parent table, then in step 960 the compute instance determines whether a filter field of type T is set in the parent table. If not, then in step 962 the compute instance returns an error because user U is not of type T. If so, then in step 964 the compute instance writes type-specific information to an additional field in the parent table associated with type T.

[0140] Notably, the procedures of Figures 9A and 9B may differ to some extent with respect to the order in which some of the conditions are checked, as well as the location of the information in the schema. Thus, these procedures are provided for illustrative purposes. Furthermore, the use of these procedures and other disclosures herein can support multi-type data, not just for users, but also other forms of data. For example, implementations similar to those herein can be employed to support multiple types with backward compatibility for any data item modeled using hierarchical object-oriented and / or TPC frameworks.

[0141] VI. Exemplary Operations Figure 10A is a flow chart illustrating one exemplary embodiment. The process illustrated by Figure 10A may be performed by a computing device, such as computing device 100, and / or a cluster of computing devices, such as server cluster 200. However, the process may also be performed by other types of devices or device subsystems. For example, the process may be performed by a computing instance of a remote network management platform or a portable computer, such as a laptop or tablet device.

[0142] The embodiments of Figure 10A may be simplified by removing any one or more of the features shown therein. Additionally, these embodiments may be combined with features, aspects, and / or implementations of any of the previous figures or described herein.

[0143] Block 1000 may include receiving a first request to read first type-specific information of a first type for a first entity from persistent storage, the persistent storage including a parent table and one or more child tables, the parent table including (i) a class field that specifies a type, and (ii) one or more type-specific filter fields, each of the types associated with a different table from the one or more child tables, and each of the one or more type-specific filter fields associated with one or more of the types.

[0144] Block 1002 may include determining that in a first entry in a parent table for a first entity, a first type is specified in a class field.

[0145] Block 1004 may include obtaining first type-specific information from a particular child table of the one or more child tables, the particular child table being associated with the first type.

[0146] Block 1006 may include providing the first type-specific information in response to the first request.

[0147] Block 1008 may include receiving a second request to retrieve second type-specific information of a second type regarding a second entity from persistent storage.

[0148] Block 1010 may include determining that in a second entry in the parent table for the second entity, the second type is indicated as present by a particular type-specific filter field associated with the second type.

[0149] Block 1012 may include obtaining second type-specific information from a set of additional fields in a second entry of the parent table, the set of additional fields being associated with the particular type-specific filter field.

[0150] Block 1014 may include providing the second type-specific information in response to the second request.

[0151] Some embodiments may further include receiving a third request to read third type-specific information of the second type for the first entity from persistent storage, determining that the second type is indicated as present by a particular type-specific filter field in the first entry of the parent table, obtaining the third type-specific information from a set of additional fields in the first entry of the parent table, and providing the third type-specific information in response to the third request.

[0152] Some embodiments may further include searching a parent table for the first entity and determining that the first entry is associated with the first entity.

[0153] In some embodiments, one or more type-specific filter fields are each associated with one or more additional fields in the parent table.

[0154] In some embodiments, the first entity is a first user and the second entity is a second user, and the first type-specific information and the second type-specific information each relate to one or more of logging on, granting access to a particular data unit in persistent storage, or presenting material on a graphical user interface.

[0155] In some embodiments, obtaining the first type-specific information includes reading the first type-specific information from a field of an entry of a particular child table associated with the first entity.

[0156] In some embodiments, the first entity is associated with a unique identifier, a first entry in a parent table includes the unique identifier and an entry in a particular child table includes the unique identifier, and retrieving the first type-specific information includes searching the entry in the particular child table for the unique identifier and identifying the unique identifier in the entry in the particular child table.

[0157] Some embodiments may further include determining that in a second entry of the parent table, the second type is not specified in the class field, and certain type-specific filter fields are considered based on the second type being not specified in the class field.

[0158] Some embodiments may further include receiving a third request to write a third type-specific information of the first type for the first entity to persistent storage, determining that in a first entry in the parent table, the first type is specified in a class field, writing the third type-specific information to the particular child table, receiving a fourth request to write a fourth type-specific information of the second type for the second entity to persistent storage, determining that in a second entry in the parent table, the second type is indicated as present by a particular type-specific filter field associated with the second type, and writing the fourth type-specific information to a set of additional fields in the parent table.

[0159] In some embodiments, obtaining the first type-specific information occurs in response to determining that in a first entry in the parent table for the first entity, the first type is specified in a class field, and obtaining the second type-specific information occurs in response to determining that in a second entry in the parent table for the second entity, the second type is indicated as present by a particular type-specific filter field associated with the second type.

[0160] Figure 10B is a flow chart illustrating one exemplary embodiment. The process illustrated by Figure 10B may be performed by a computing device, such as computing device 100, and / or a cluster of computing devices, such as server cluster 200. However, the process may also be performed by other types of devices or device subsystems. For example, the process may be performed by a computing instance of a remote network management platform or a portable computer, such as a laptop or tablet device.

[0161] The embodiments of Figure 10B may be simplified by removing any one or more of the features shown therein. Additionally, these embodiments may be combined with features, aspects, and / or implementations of any of the previous figures or described herein.

[0162] Block 1050 may include receiving a first request to write first type-specific information of a first type for a first entity to persistent storage, the persistent storage including a parent table and one or more child tables, the parent table including (i) a class field that specifies a type, and (ii) one or more type-specific filter fields, each of the types associated with a different table from the one or more child tables, and each of the one or more type-specific filter fields associated with one or more of the types.

[0163] Block 1052 may also include determining that in a first entry in the parent table, the first type is specified in the class field.

[0164] Block 1054 may also include writing the first type-specific information to a particular child table of the one or more child tables, the particular child table being associated with the first type.

[0165] Block 1056 may also include receiving a second request to write the second type-specific information of the second type regarding the second entity to persistent storage.

[0166] Block 1058 may include determining that in a second entry in the parent table for the second entity, the second type is indicated as present by a particular type-specific filter field associated with the second type.

[0167] Block 1060 may include writing the second type-specific information to a set of additional fields in a second entry of the parent table, the set of additional fields being associated with the particular type-specific filter field.

[0168] Some embodiments may further include receiving a third request to write third type-specific information of a second type for the first entity to persistent storage, determining that the second type is indicated as present by a particular type-specific filter field in the first entry of the parent table, and writing the third type-specific information to a set of additional fields in the first entry of the parent table.

[0169] Some embodiments may include searching a parent table for a first entity and determining that a first entry is associated with the first entity.

[0170] In some embodiments, writing the first type-specific information includes writing the first type-specific information to a field of an entry for a particular child table associated with the first entity.

[0171] In some embodiments, the first entity is associated with a unique identifier, a first entry in a parent table includes the unique identifier and an entry in a particular child table includes the unique identifier, and writing the first type-specific information includes searching the entry in the particular child table for the unique identifier and identifying the unique identifier in the entry in the particular child table.

[0172] In some embodiments, one or more type-specific filter fields are each associated with one or more additional fields in the parent table.

[0173] In some embodiments, the first entity is a first user and the second entity is a second user, and the first type-specific information and the second type-specific information each relate to one or more of logging on, granting access to a particular data unit in persistent storage, or presenting material on a graphical user interface.

[0174] VII. Conclusion The present disclosure is not limited in terms of the specific embodiments described herein, which are intended to illustrate various aspects. As will be apparent to those skilled in the art, many modifications and variations are possible without departing from the scope thereof. From the foregoing description, functionally equivalent methods and apparatuses within the scope of the present disclosure, in addition to those described herein, will be apparent to those skilled in the art. Such modifications and variations are also intended to fall within the scope of the appended claims.

[0175] In the above detailed description, various features and operations of the disclosed system, apparatus, and method are described with reference to the accompanying drawings. The exemplary embodiments described herein and in the drawings are not meant to be limiting in any way. Other embodiments may be utilized and other changes may be made without departing from the scope of the subject matter presented herein. It will be readily understood that the aspects of the present disclosure as described throughout this specification and illustrated in the drawings can be arranged, substituted, combined, separated, and designed in a wide variety of different configurations.

[0176] With respect to any or all of the message flow diagrams, scenarios, and flowcharts in the figures, each step, block, and / or communication may represent information processing and / or information transmission according to an exemplary embodiment, as discussed herein. The scope of these exemplary embodiments includes alternative embodiments. In these alternative embodiments, for example, operations described as steps, blocks, transmissions, communications, requests, responses, and / or messages may be performed out of the order shown or described (including substantially simultaneously or in reverse order), depending on the functionality involved. Furthermore, any of the message flow diagrams, scenarios, and flowcharts discussed herein may use more or fewer blocks and / or operations, and some or all of these message flow diagrams, scenarios, and flowcharts may be combined with each other.

[0177] The steps or blocks representing the processing of information may correspond to circuitry that may be configured to perform certain logical functions of the methods or techniques described herein. Alternatively or additionally, the steps or blocks representing the processing of information may correspond to modules, segments, or portions of program code (including associated data). The program code may include one or more instructions executable by a processor to perform certain logical operations or actions in the methods or techniques. The program code and / or associated data may be stored in any type of computer-readable medium, such as a storage device, including a RAM, a disk drive, a solid-state drive, or another storage medium.

[0178] Computer readable media may also include non-transitory computer readable media, such as non-transitory computer readable media that store data for a short period of time, such as register memory and processor cache. Non-transitory computer readable media may further include non-transitory computer readable media that store program code and / or data for a long period of time. Thus, non-transitory computer readable media may include secondary or permanent long-term storage, such as, for example, ROM, optical or magnetic disks, solid-state drives, or compact disk read-only memories (CD-ROMs). Non-transitory computer readable media may also be any other volatile or non-volatile storage system. Non-transitory computer readable media may be considered, for example, computer readable storage media or tangible storage devices.

[0179] Furthermore, steps or blocks depicting one or more information transfers may correspond to information transfers between software and / or hardware modules in the same physical device, although other information transfers are possible between software and / or hardware modules in different physical devices.

[0180] The particular arrangement depicted in the figures should not be construed as limiting in any way. It is understood that other embodiments may show more or fewer elements in a given figure. Further, some of the depicted elements may be combined or omitted. Additionally, an example embodiment may include elements that are not shown in the figures.

[0181] Various aspects and embodiments are disclosed herein, and other aspects and embodiments will be apparent to those of ordinary skill in the art. The various aspects and embodiments disclosed herein are intended to be illustrative and not limiting, with the true scope being indicated by the following claims. [Explanation of symbols]

[0182] 100 Computer Equipment 102 processors 104 Memory 104A Firmware 104B Kernel 104C Application 106 Network Interface 108 Input / Output Unit 110 System Bus 200 Server Cluster 202 Server equipment 204 Data Storage 206 Router 208 Local Cluster Network 210 Communication Links 212 Network 300 Managed Networks 302 Client Device 304 Server Equipment 306 Router 308 Virtual Machines 310 Firewall 312 Proxy Server 320 Remote Network Management Platform 322 Computing Instances 324 Computing Instances 326 Computing Instances 328 Compute Instances 340 Public Cloud Network 350 Internet 400A Data Center 400B Data Center 402A VPN Gateway 402B VPN Gateway 404A Firewall 404B Firewall 406A load balancer 406B Load Balancer 410 Setting items 412 VPN Gateways 414 users 416 Remote User 500 CMDB 502 Task List 600 Database Schema 602 User Table 604 Customer Table 606 Vendor Table 608 Citizen Table 700 Database Schema 702 User Table 800 Database Schema 802 User Table 804 Customer Table 806 Vendor Table 808 Citizen Table

Claims

1. a persistent storage including a parent table and one or more child tables, the parent table including (i) a class field that specifies a type, and (ii) one or more type-specific filter fields, each of the types being associated with a different table from the one or more child tables, each of the one or more type-specific filter fields being associated with one or more of the types; receiving a first request to read first type-specific information of a first type relating to a first entity from the persistent storage; determining that in a first entry in the parent table for the first entity, the first type is specified in the class field; obtaining the first type-specific information from a particular child table of the one or more child tables, the particular child table being associated with the first type; and providing the first type-specific information in response to the first request; receiving a second request to read second type-specific information of a second type relating to a second entity from the persistent storage; determining that the second type is indicated as present by a particular type-specific filter field associated with the second type in a second entry of the parent table for the second entity; obtaining the second type-specific information from a set of additional fields in the second entry of the parent table, the set of additional fields being associated with the particular type-specific filter field; and providing the second type-specific information in response to the second request; and one or more processors configured to: A system comprising:

2. the one or more processors: receiving a third request to read third type-specific information of the second type regarding the first entity from the persistent storage; determining that the second type is indicated as present by the particular type-specific filter field in the first entry of the parent table; obtaining the third type-specific information from the set of additional fields in the first entry of the parent table; providing the third type-specific information in response to the third request; and The system of claim 1 , further configured to:

3. the one or more processors: searching the parent table for the first entity; determining that the first entry is associated with the first entity; The system of claim 1 , further configured to:

4. The system of claim 1 , wherein the one or more type-specific filter fields are each associated with one or more additional fields in the parent table.

5. 2. The system of claim 1, wherein the first entity is a first user and the second entity is a second user, and the first type-specific information and the second type-specific information each relate to one or more of logging on to the system, granting access to a particular data unit in the persistent storage, or presenting material on a graphical user interface.

6. 2. The system of claim 1, wherein obtaining the first type-specific information comprises reading the first type-specific information from a field of an entry of the particular child table associated with the first entity.

7. the first entity is associated with a unique identifier, the first entry in the parent table includes the unique identifier, the entry in the particular child table includes the unique identifier, and retrieving the first type-specific information comprises: searching for an entry in the particular child table for the unique identifier; Identifying the unique identifier in the entry of the particular child table; The system of claim 6 , comprising:

8. 2. The system of claim 1, wherein the one or more processors are further configured to: determine that in the second entry of the parent table, the second type is not specified in the class field; and the particular type-specific filter field is considered based on the second type being not specified in the class field.

9. the one or more processors: receiving a third request to write third type-specific information of the first type regarding the first entity to the persistent storage; determining that in the first entry of the parent table, the first type is specified in the class field; writing the third type specific information to the particular child table; receiving a fourth request to write fourth type-specific information of the second type regarding the second entity to the persistent storage; determining that the second type is indicated as present by the particular type-specific filter field associated with the second type in the second entry of the parent table; writing said fourth type specific information into said set of additional fields in said parent table; The system of claim 1 , further configured to:

10. 2. The system of claim 1, wherein obtaining the first type-specific information occurs in response to determining that in a first entry in the parent table for the first entity, the first type is specified in the class field, and obtaining the second type-specific information occurs in response to determining that in a second entry in the parent table for the second entity, the second type is indicated as present by the particular type-specific filter field associated with the second type.

11. receiving a first request to retrieve first type-specific information of a first type relating to a first entity from persistent storage, the persistent storage including a parent table and one or more child tables, the parent table including (i) a class field that specifies a type, and (ii) one or more type-specific filter fields, each of the types associated with a different table from the one or more child tables, each of the one or more type-specific filter fields associated with one or more of the types; determining that in a first entry in the parent table for the first entity, the first type is specified in the class field; obtaining the first type-specific information from a particular child table of the one or more child tables, the particular child table being associated with the first type; and providing the first type-specific information in response to the first request; receiving a second request to read second type-specific information of a second type relating to a second entity from the persistent storage; determining that the second type is indicated as present by a particular type-specific filter field associated with the second type in a second entry of the parent table for the second entity; obtaining the second type-specific information from a set of additional fields in the second entry of the parent table, the set of additional fields being associated with the particular type-specific filter field; and providing the second type-specific information in response to the second request; and 4. A computer-implemented method comprising:

12. receiving a third request to read third type-specific information of the second type regarding the first entity from the persistent storage; determining that the second type is indicated as present by the particular type-specific filter field in the first entry of the parent table; obtaining the third type-specific information from the set of additional fields in the first entry of the parent table; providing the third type-specific information in response to the third request; and The computer-implemented method of claim 11 , further comprising:

13. searching the parent table for the first entity; determining that the first entry is associated with the first entity; The computer-implemented method of claim 11 , further comprising:

14. 12. The computer-implemented method of claim 11, wherein obtaining the first type-specific information comprises reading the first type-specific information from a field of an entry of the particular child table associated with the first entity.

15. the first entity is associated with a unique identifier, the first entry in the parent table includes the unique identifier, the entry in the particular child table includes the unique identifier, and retrieving the first type-specific information comprises: searching for an entry in the particular child table for the unique identifier; Identifying the unique identifier in the entry of the particular child table; 15. The computer-implemented method of claim 14, comprising:

16. receiving a first request to write first type-specific information of a first type regarding a first entity to persistent storage, the persistent storage including a parent table and one or more child tables, the parent table including (i) a class field that specifies a type, and (ii) one or more type-specific filter fields, each of the types associated with a different table from the one or more child tables, each of the one or more type-specific filter fields associated with one or more of the types; determining in a first entry of the parent table that the first type is specified in the class field; writing the first type-specific information to a particular child table of the one or more child tables, the particular child table being associated with the first type; and receiving a second request to write second type-specific information of a second type regarding a second entity to the persistent storage; determining that the second type is indicated as present by a particular type-specific filter field associated with the second type in a second entry of the parent table for the second entity; writing the second type-specific information into a set of additional fields in the second entry of the parent table, the set of additional fields being associated with the particular type-specific filter field; 4. A computer-implemented method comprising:

17. receiving a third request to write third type-specific information of the second type regarding the first entity to the persistent storage; determining that the second type is indicated as present by the particular type-specific filter field in the first entry of the parent table; writing the third type specific information into the set of additional fields in the first entry of the parent table; 20. The computer-implemented method of claim 16, further comprising:

18. searching the parent table for the first entity; determining that the first entry is associated with the first entity; 20. The computer-implemented method of claim 16, further comprising:

19. 17. The computer-implemented method of claim 16, wherein writing the first type-specific information comprises writing the first type-specific information to a field of an entry for the particular child table associated with the first entity.

20. the first entity is associated with a unique identifier, the first entry in the parent table includes the unique identifier, the entry in the particular child table includes the unique identifier, and writing the first type-specific information; searching for an entry in the particular child table for the unique identifier; Identifying the unique identifier in the entry of the particular child table; 20. The computer-implemented method of claim 19, comprising:

Images