Software Computing Platform as a Scalable Service

Abstract

Techniques for a SaaS computing platform are provided. A computing system includes computer-executable components that include a plurality of core modules that provide defined services. The plurality of core modules include at least one extension point corresponding to a first core module of the plurality of core modules, and a first extension point of the at least one extension point is mapped to a tenant-specific extension module that customizes the defined service. The computer-executable components can also include an application programming interface (API) corresponding to a defined tenant. The computing system also includes a data model corresponding to a defined tenant. The tenant-specific extension module mapped to the at least one extension point can customize the API and / or the data model.

Description

[Technical Field]

[0001] Cross-reference of related applications This application claims the interests and priority of U.S. Patent Application No. 17 / 944,907 and U.S. Patent Application No. 17 / 944,906, both filed on September 14, 2022, which in turn claim the interests and priority of U.S. Provisional Patent Application No. 63 / 347,422, filed on May 31, 2022, the contents of which are incorporated herein by reference in their entirety. [Background technology]

[0002] In the software-as-a-service model, where access to software-provided functionality is a shared experience, the computing platform hosts a version of the software common to end-user devices accessing the functionality through the platform. This access to functionality may be referred to as multi-tenant access, where end-user devices are associated with various different entities authorized to access the software. Each of these entities may be referred to as a tenant. Beyond accessing software-provided functionality, end-user devices associated with a tenant may also access the computing platform's storage infrastructure and other computing resources.

[0003] The SaaS (Software as a Service) model provides easy access to the functionality of software without the burden of maintaining that software, but the codebase corresponding to the software version is common across tenants. Such a codebase may be referred to as a platform. In some existing SaaS systems, the tenant experience on the platform may be customized through limited registration of tenant-specific logic, and such customization may rely on a certain extensibility already built into the platform. In other words, these existing SaaS systems can offer a limited form of customizability, and expanding that customizability may involve adding new extensibility across the entire platform rather than focusing on the individual functionality needs of each tenant accessing the platform.

[0004] In fact, greater flexibility in customization can be more easily achieved on its own by using a codebase configured and tuned to provide functionality closely tailored to a particular tenant. However, customizing a codebase in this manner typically relies on modifying a monolithic and rather complex arrangement of program code. Modifying such an arrangement of program code can enable comprehensive customization. However, customization in this manner is time-consuming, rather cumbersome, and can continuously increase maintenance complexity by proliferating isolated customized codebases. In addition, dealing with such codebases collectively can be impractical because there may be no guarantee that the codebase conforms to a defined set of features.

[0005] Therefore, the ease of access to software on a SaaS multi-tenant platform and the rich tenant-specific customization of that software appear to be in stark conflict from a design and implementation standpoint. Consequently, existing computing platforms that provide easy access to software for multiple tenants tend to lack rich, fine-grained scalability, and vice versa. Thus, there is still much room for improvement in existing technologies that provide both multi-tenant access to software and tenant-specific customization of that software. [Overview of the project]

[0006] Please understand that both the following summary and the embodiments for carrying out the invention described below are merely illustrative and explanatory, and not limiting.

[0007] In one embodiment, the disclosure provides a computing system. The computing system includes at least one processor that runs a computer executable component stored in at least one memory device. The computer executable component includes a plurality of core modules that provide defined services. The plurality of core modules include at least one extension point corresponding to a first core module among the plurality of core modules, the first extension point among the at least one extension point is mapped to a tenant-specific extension module that customizes the defined services. The computer executable component may also include an application programming interface (API) corresponding to a defined tenant. The computing system also includes a data model corresponding to a defined tenant. The tenant-specific extension module mapped to at least one extension point can customize the API and / or the data model.

[0008] Additional elements or advantages of this disclosure are described in part in the subsequent specification, are evident from the specification, or can be learned through the practice of the invention. The advantages of this disclosure may be achieved by elements and combinations specifically indicated in the appended claims.

[0009] This summary is not intended to identify any significant or essential features of the Disclosure, but merely to summarize its specific features and variations. Further details and features are described in the following sections. Furthermore, both the above summary and the following embodiments for carrying out the invention are merely illustrative and descriptive and do not limit the embodiments of the Disclosure.

[0010] The accompanying drawings are an integral part of this disclosure and are incorporated herein by reference. The drawings illustrate exemplary embodiments of this disclosure and, together with the specification and claims, help to illustrate various principles, elements, or aspects of this disclosure, at least partially. Embodiments of this disclosure are described below in full with reference to the accompanying drawings. However, various elements of this disclosure can be implemented in many different forms and should not be construed as being limited to the implementations described herein. Throughout, similar figures refer to similar elements. [Brief explanation of the drawing]

[0011] [Figure 1] This disclosure illustrates an example of a computing system that implements an extensible SaaS platform providing customized services to each single tenant, according to one or more embodiments of this disclosure. [Figure 2A] This disclosure schematically illustrates exemplary architectures of modules (core modules or extension modules) according to one or more embodiments of this disclosure. [Figure 2B] One or more embodiments of this disclosure illustrate an example of a service core architecture extended by tenant-dependent extension modules. [Figure 3]This disclosure illustrates an example of virtual partition (VP) data storage that helps configure a single-tenant customized service, based on one or more embodiments of this disclosure. [Figure 4A] This disclosure illustrates a user interface representing an example of a VP for a specific tenant, based on one or more embodiments of this disclosure. [Figure 4B] This disclosure illustrates a user interface representing another example of a VP for a particular tenant, based on one or more embodiments of this disclosure. [Figure 4C] One or more embodiments of this disclosure illustrate an example of a tenant-specific VP and another virtual partition containing reusable customizable components. [Figure 4D] One or more embodiments of this disclosure illustrate an example of a hierarchical structure that logically associates a tenant-specific VP with several other virtual partitions, including reusable customizable components. [Figure 4E] One or more embodiments of this disclosure illustrate another example of a hierarchical structure that logically relates a tenant-specific VP to several other virtual partitions, including reusable customizable components. [Figure 5] One or more embodiments of this disclosure illustrate another computing system that provides an extensible SaaS platform with customized services for each single tenant. [Figure 6] An example of yet another computing system for building extension modules according to one or more embodiments of the present disclosure is illustrated. [Figure 7A] This disclosure illustrates an example of a process for extending the scalability of a service core associated with a service, according to one or more embodiments of this disclosure. [Figure 7B] This disclosure illustrates an example of a computing system that upgrades a common core service to a newer, more scalable version of the common core service, according to one or more embodiments of this disclosure. [Figure 8]Illustrate an example of a computing system for upgrading a service core according to one or more embodiments of the present disclosure. [Figure 9] Illustrate an example of a method for providing an extensible service customized for a single tenant according to one or more embodiments of the present disclosure. [Figure 10] A flowchart of an exemplary method for providing an extensible service customized for a single tenant according to one or more embodiments of the present disclosure. [Figure 11] Illustrate an example of a method for expanding the scalability of a service core associated with a service according to one or more embodiments of the present disclosure. [Figure 12] A flowchart of another exemplary method for upgrading the functionality of a service core associated with a service according to one or more embodiments of the present disclosure. [Figure 13] Illustrate an example of a computing system that can implement an extensible SaaS platform for providing services customized for each single tenant according to one or more embodiments of the present disclosure. [Figure 14] Illustrate an example of a computing system according to one or more embodiments of the present disclosure.

Mode for Carrying Out the Invention

[0012] This disclosure recognizes and addresses, among other technical challenges, the issue of scalability in Software as a Service (SaaS) computing platforms. As described in more detail below, embodiments of this disclosure provide an extensible SaaS computing platform that includes APIs for hosting single-tenant, tenant-specific services and allowing access to those services in a multi-tenant configuration. Embodiments of this disclosure enable a collection of customized single-tenant services to be treated as a single multi-tenant system by integrating one or more groups of tenant-specific extension modules, individually or in combination, into a collection of core modules that are common across tenants, thereby building each service. The collection of core modules may itself be referred to as a core platform and can be customized by mapping extension modules to extension points exposed by the collection of core modules, and in some cases by providing configuration information. A customized core platform may have a superset of common core APIs and a common core data model. An API router component can be functionally coupled to one or more customized core platforms. The API router component can present a group of customized core platforms as a multi-tenant platform to client devices communicating with the router. Client devices can communicate with router components to access the common core APIs of the multitenant platform, and can selectively target individual API functions (or extensions) of individual customized core platforms. Furthermore, some embodiments can uniquely and systematically enhance the core functionality of a group of core modules in situations where the extension points present in the core module are insufficient to provide the desired customization.Specifically, embodiments of the present disclosure can temporarily fork a version of the core platform to enable the incorporation of additional extensions(or extensions) into the core platform. After the operational integrity of the added extensions(or extensions) is proven to be sufficient, embodiments of the present disclosure can then securely reintroduce (or fold) the extensions(or extensions) into the upgraded common core. Each existing customized single-tenant platform can be securely upgraded to the new core platform with sufficient performance using such an approach.

[0013] In some embodiments, the computing system includes a computer executable component that includes a plurality of core modules that provide defined services. The plurality of core modules also define a core API. The plurality of core modules include at least one extension point corresponding to a first core module among the plurality of core modules. Each extension point of the at least one extension point can be formed by program code in the first core module, which defines logic associated with the registration of one or more functions from another module. After the other modules are mapped to the extension points, the core logic associated with the first core module can then call the function(s) provided by the other modules as part of the core logic. The first extension point of the at least one extension point corresponding to the first core module is mapped to a tenant-specific extension module that customizes the defined service. The customization is at least in part obtained from the registration of one or more defined functions in the tenant-specific module, which can be called by the first core module. Thus, the customized defined service is a tenant-specific service. The computer executable component may also include both an API and a data model corresponding to a defined tenant. Tenant-specific extension modules mapped to at least one extension point can customize the core API to generate APIs corresponding to the defined tenant. The data model is customized in a similar manner. A collection of tenant-specific services can be treated as a single SaaS platform with a common core API by deploying an API router component that overlays the collection of tenant-specific services in logical space. Since tenant-specific extension modules can be maintained separately from the core module, tenant-specific services can be upgraded to a new core by pointing to the upgraded core module.

[0014] Referring to the drawings, Figure 1 illustrates an example of a computing system 100 that provides single-tenant customized and extensible functionality according to one or more embodiments of the present disclosure. The computing system 100 includes an API router component 110 for each tenant and multiple executable package components, including an executable package component 120(J) for tenant J and an executable package component 120(K) for tenant K. The multiple executable package components provide their respective single-tenant services, and each of those single-tenant services can be customized for each specific tenant. In one example, the single-tenant services include a clinical trial service. Each executable package component of the multiple executable package components can be embodied, for example, in a container (such as a Docker container), an executable binary file, or the like. The single-tenant services may have their own data models associated with them. A single-tenant service provided by executable package component J 120(J) may have a data model J 160(J) associated with executable package component J 120(J), and another single-tenant service provided by executable package component K 120(K) may have a data model K 160(K) associated with executable package component K 120(K). For illustrative purposes, in this disclosure, a data model represents the form of service data owned, generated, and accessed by a service and the relationships between the service data. A service may be a tenant-specific service or a core service. A data model may include data entities and associations between at least some of the data entities, where the associations embody such relationships. A data entity includes a data structure having one or more fields. In one example, a data entity may be a table, and the fields may correspond to each column in the table.Therefore, a data model can include groups of tables and associations between two or more tables, where associations logically link a field in the first table within the group with another field in the other table within the group.

[0015] Furthermore, a data model can be defined before service data becomes available to a service. After a data model is defined, service data can be stored in data storage according to that model. In other words, a data model dictates how service data should be organized within the data repository. For naming purposes only, a data model corresponding to a core service may be called a core data model, while a data model corresponding to a tenant-specific service may simply be called a data model.

[0016] The API router component 110 exposes APIs that allow access to multiple single-tenant services, as if the computing system 100 were a multi-tenant computing platform. To provide access in this manner, the API router component 110 can receive messages that invoke function calls to customized services for a particular tenant (e.g., tenant J or tenant K), and the messages include attributes that identify the particular tenant. Messages can be received from a client computing device (not shown in Figure 1) via a communication network 114 that functionally connects the client computing device and the API router component 110. The communication network 114 or another communication network can, in some cases, functionally connect the API router component 114 with other components such as executable package component J 120(J) and executable package component K 120(K). The API router component 110 can then redirect function calls to customized defined services based on the attributes. The API router component 110 can be embodied, for example, in an API gateway. The API exposed by the API router component 110 may be one of several types of APIs, such as a Representation State Transfer (REST) ​​API, a GraphQL service, a Simple Object Access Protocol (SOAP) service, or a Remote Procedure Call (RPC) API. If the exposed API is a REST API, the attribute that identifies a particular tenant may be either an authentication token or a REST parameter. In other cases, the attribute may be a tenant identifier (ID) that uniquely identifies the defined tenant. The tenant ID may be, for example, a universally unique identifier (UUID).

[0017] As stated, each single-tenant service can be customized for a specific tenant. For this purpose, an executable package component for a specific tenant may include a service core having multiple core modules that provide defined services. The service core also defines and exposes APIs (referred to as core APIs or common core APIs) and further defines a data model (referred to as a core data model or common core data model). The APIs exposed by the service core may be one of various types of APIs, such as a REST API, GraphQL service, SOAP service, or RPC API. Note that the core APIs exposed by the service core may be a subset of the APIs exposed by the API router component 110. More specifically, the APIs exposed by the API router component 110 each contain a combination of the APIs exposed by each customized single-tenant instance in the collection of customized single-tenant instances. For example, the APIs exposed by the API router component 110 may expose a combination of API J130(J) and API K130(K). A first core module of a group of core modules may provide at least one first element to the data model, and a second core module of a group of core modules may provide at least one second element to the data model. In addition, or in some cases, a first core module may provide at least one first function to the API, and a second core module may provide at least one second function to the API. The API and data model may result from changes made by one or more core modules. For example, a first core module may modify at least one of an existing data model or an existing API, resulting in at least a portion of the API or at least a portion of the data model associated with the service core.

[0018] Multiple core modules have at least one extension point. The first of the at least one extension point may correspond to the first core module among the multiple core modules. For illustrative purposes, an extension point refers to program code that (i) identifies a function that can be invoked by the core module having the extension point, and (ii) calls an optional module for the implementation of the function. Thus, the optional module can define a function (or its logic) and thus add logic to a core module and / or adjust the logic within the core module. Rather than defining extension logic, the program code identifies the signature of the desired function and also acts as a placeholder for the function (or logic) defined in the optional module.

[0019] The service core is common among multiple executable package components within the computing system 100. That is, multiple core modules and at least one extension point, API, and data model are common among multiple executable package components. A defined service for a particular tenant can be customized by mapping one or more tenant-specific extension modules to each of the extension points present in the service core. Mapping refers to assigning functionality provided by an extension module to program code in an extension point within a core module that can invoke that functionality. The program code is configured to act as a placeholder for the functionality. Functionality is assigned to program code by reference, for example, by passing a reference to the functionality (or an object representing the functionality). In other words, mapping refers to retrieving functionality from an extension module and registering that functionality with a core module, which is configured to invoke that functionality. Functionality is registered (or assigned) by reference via an extension point within a core module. By registering the functionality with a core module, the customization indicated by the functionality can be achieved. While mapping has been described in relation to core modules and extension modules, this disclosure is not limited to that. In fact, a module that defines a function (a core module or an extension module) can be mapped to another module (a core module or an extension module) that has extension points that allow the function to be registered. For example, a module that defines a functionality can be mapped to module 210 (Figure 2A) which has extension points 220(1) to 220(Q), one of which has program code that can receive the functionality by reference.

[0020] Tenant-specific extension modules can non-destructively modify the core API and core data model to provide a customized API and / or data model for a particular tenant. That is, a first tenant-specific extension module stores several core functions that make up the core API, and several core elements that make up the core data model. Therefore, non-destructive modifications can be additive. In other words, additive modification is an example of a non-destructive mechanism for modifying the core API and core data model. More specifically, a first tenant-specific extension module can provide at least one element to the core data model, or functionality to the core API, or it can provide at least one element to the core data model and functionality to the core API. The at least one element that can be provided to the core data model may include a field in a table, or a measure in that table or another table. Providing such an element may result in the addition of a column to one or more tables existing in the core data model. Additionally, or in some non-destructive modifications, the at least one element that can be provided to the core data model may include a table.

[0021] In some cases, breaking modifications to the core API may be desirable. For example, a tenant-specific service may no longer support a particular core function of several functions that make up the core API. In such cases, the first tenant-specific extension module can remove that particular core function while preserving several core elements that make up the core data model. By removing the unsupported particular core function, the tenant-specific service can be configured in a manner that matches the actual capabilities of the tenant-specific service. As an example, if the tenant-specific service is a clinical trial, the particular core function to be removed might be the function to determine drug dosage. As another example, rather than completely removing the particular core function, the breaking modification may involve adding a parameter to the function for determining drug dosage, resulting in a lack of compatibility with the existing function being replaced. Such a breaking modification may reduce the involvement of that single breakingly customized instance from the common core API. In other words, that single breakingly customized instance supports a smaller subset of the common core API. Breaking modifications also reduce the size of the API coupling exposed by each customized single-tenant instance in the collection of customized single-tenant instances. Breaking modifications are not limited to breaking changes to the core API. In some exemplary scenarios, breaking modifications may also be applied to the core data model, allowing a first tenant-specific extension module to remove a particular core element of the data model while preserving several core functionalities that make up the core API. A particular core element may be removed because the tenant-specific service does not depend on that particular element. For example, if the tenant-specific service is a clinical trial, the core element to be removed might be the weight or country of birth of subjects participating in the clinical trial. Such removals can result in various efficiencies, such as more efficient use of memory resources and / or processing resources. For illustrative purposes only, a particular core element might be a field in a table or an entire table.In other exemplary scenarios, the first tenant-specific extension module may remove certain core elements from the data model and certain core functions from the core API.

[0022] Therefore, a selected tenant-specific extension module(s) may cause breaking modifications to the core API and / or core data model in response to mapping to each extension point present in the core module that provides the defined service. As a result, a selected tenant-specific module(s) may cause a breakdown of backward compatibility between the customized defined service and the defined service. The customized defined service is a result of such mapping.

[0023] As shown in Figure 1, both executable package component J 120(J) and executable package component K 120(K) can include a service core 140 having multiple core modules 144 and multiple extension points 148. Since each of these executable package components can provide a customized single-tenant service to its respective tenant, executable package component J 120(J) can include one or more extension modules 150(J) that extend the functionality of the core module 144, providing a customized API J 130(J) and a customized data model J 160(J). In addition, executable package component K 120(K) can include one or more extension modules 150(K) that extend the functionality of the core module 144, providing a customized API J 130(K) and a customized data model J 160(K).

[0024] Referring further to Figure 2A, an exemplary architecture of module 210 according to one or more embodiments of the present disclosure is schematically illustrated. Module 210 may represent a core module or an extension module. Regardless of its type, module 210 has program code that provides defined functionality for module 210, and other program code that defines a group of extension points, including a first extension point 220(1), up to the Q-1th extension point 220(Q-1) and the Qth extension point 230(Q), where Q is a natural number greater than 1. Although Q is illustrated as greater than 1, the present disclosure is not limited thereto, and in some cases a single extension point may exist within module 210. As part of defining the extension points of a group of extension points, the other program code defines logic associated with the registration of one or more functions from another module (core module or extension module). After the other module has been mapped to an extension point, the logic associated with module 210 can then call the function(s) provided by the other module as part of the logic of module 210. Therefore, the defined functionality of module 210 is extended to include additional functionality provided by such functionality(s).

[0025] Therefore, each extension point in the group of extension points enables the extension of the defined functionality of module 210 by receiving one other module or a collection of two or more other modules. In other words, an extension point 220(j) where j=1, 2…, Q-1, or Q can be associated with a single extension module or multiple extension modules, where Q is a natural number defining the number of extension points and can be 1 or greater. In some cases, depending on the desired functionality of module 210, one or more extension points may be empty; that is, each of those extension points may not be associated with an extension module.

[0026] Figure 2B illustrates an exemplary architecture of a service core 140, including customization provided by multiple expansion modules. The exemplary service core 140 constitutes an example of a core module 144 (Figure 1) and may include multiple core modules, including core module 1 250(1), core module 2 250(2), core module 3 250(3), and core module 4 250(4). The multiple core modules can provide core functionality common to all tenants accessing the computing system 100, as described herein. Specific services provided by those core modules within the exemplary service core 140 can be customized by mapping the multiple expansion modules to their respective expansion points located in core modules 250(1) to 250(4). Such mappings are drawn as arrows from one module to the expansion points of another. For illustrative purposes, in Figure 2B, the expansion points are represented by their respective small rectangles. The multiple expansion modules include expansion module 1 260(1), expansion module 2 260(2), and expansion module 3 260(3). Such expansion modules may be associated with a first source file system (represented as "VP1" in Figure 2B). The multiple expansion modules also include expansion module 1 270(1) and expansion module 2 270(2), each associated with a second source file system (represented as "VP2"). As described herein, each of these expansion modules constitutes additional custom functionality for the illustrated service core 140, resulting in customized services for a particular tenant.

[0027] The configuration of additional custom functionality can be based on logical relationships between core modules and various extension modules. For example, core modules 250(1) to 250(4) can constitute a first layer in a hierarchical structure that defines logical relationships. As illustrated in Figure 2B, core modules in the first layer can be mapped to extension points of other core modules in that first layer, for example, core module 4 250(4) can be mapped to an extension point of core module 3 250(3). As a result, a single extension point can receive two or more modules, for example, core module 3 260(3) and extension module 260(2). Extension modules 260(1) to 260(3) can constitute a second layer in the hierarchical structure and can be mapped to extension points present in core modules 250(1) to 250(4) in the first layer and / or extension modules forming the second layer. However, core modules in the first layer cannot be mapped to extension points in the second layer. The expansion modules 270(1) and 270(2) can constitute a third layer in the hierarchical structure and can be mapped to core modules in the first layer and expansion points in other expansion modules in the second layer.

[0028] Because the extension modules and core modules share the same program code architecture principles, the development of tenant-specific services can be performed with significantly greater computational efficiency than with existing technologies. The scalability mechanism provided by the mapping of the core modules and extension modules to their respective extension points offers superior customization flexibility. Compared to existing technologies, such flexibility can be leveraged across individual single-tenant services and, when combined with the API router component 110, enables the implementation of a SaaS multi-tenant computing platform with richly customizable single-tenant systems.

[0029] Figure 3 illustrates an exemplary data storage 302 for configuring a single-tenant customized service according to one or more embodiments of the present disclosure. The data storage 302 includes one or more memory devices having various types of information representing customization options and sources of isolation assurance for tenant-specific services for a particular tenant. Isolation assurance may include authorization parameters configured to grant a particular tenant exclusive access to tenant-specific services. The various types of information are configurable, and the data storage 302 can receive input data defining the various types of information from a computing device (not shown in Figure 3 for simplicity). The computing device can run an application which causes the computing device to present a user interface that can receive input data sent to the data storage 302. The application may be, for example, a web browser, an integrated development environment (IDE) application, or similar. The computing device may be functionally coupled to the data storage 302 via a network interface. In some cases, the computing device may have the data storage 302 integrated therein, and input data can be sent to the data storage 302 via a bus architecture. At least some of the information held in data storage 302 may include a file system structure having multiple file systems 304, where each file system is dedicated to each of the multiple tenants. Thus, for a tenant, the information in data storage 302 can be placed in a file system 306 dedicated to that tenant. The information may include program code, data, and / or metadata corresponding to defined versions of available customizations for the tenant. A defined version corresponds to a persistent unique identifier that indicates immutable content forming the customizations available at a particular point in time.In some cases, available customizations can be embodied in definition data resulting from modifications (such as additional modifications) to definition data present in the service core. Therefore, customization options present in data storage 302 may be adjusted instances of configurations present in the service core. This disclosure is, of course, not limited to specific types of non-temporary storage structures (such as file systems), but other non-temporary storage structures can embody virtual partitions. These other non-temporary storage structures can be held in data storage 302 and may include, for example, file folders on disk, git repositories, tables or other types of entries in a database, combinations thereof, or similar. Regardless of its type, any non-temporary storage structure that holds tenant-specific program code and configuration information may be referred to as a virtual partition. A virtual partition can be identified by a defined version of the customizations available to the tenant.

[0030] Each filesystem can include program code 308a that defines extension logic. In some cases, program code 308a can include multiple class objects that define their respective extension logic. In addition, or in some cases, each filesystem can include one or more extension modules 308b that define other extension logic. Furthermore, or in other cases, each filesystem can also include multiple configuration attributes. A subset of multiple configuration attributes can constitute resources associated with a particular tenant. Some resources can be held within their respective files in the filesystem for that particular tenant. As illustrated in Figure 3, a first resource can include a workflow definition 312. A workflow definition is a type of configuration that specifies the number of operations that constitute a workflow for a tenant. In one example, the operations can constitute a subject capture workflow that allows a subject in a clinical trial, or another type of end-user, to provide input data that defines various subject attributes (e.g., date of birth, gender, weight, etc.). In some cases, the subject capture workflow causes a client device to be presented with one or a set of UIs or questions to acquire such input data. In some cases, the workflow definitions in workflow definition 312 can be generated by modifying existing workflow definitions within the service core, for example, by adding elements. Modifying an existing workflow includes, for example, adding one or more operations to an existing workflow definition, removing one or more operations from an existing workflow definition, replacing one or more operations present in an existing workflow definition, or a combination thereof, and thus resulting in the workflow definitions contained in workflow definition 312. Workflow definitions generated in such a manner can serve as local replacement workflows associated with the service core.

[0031] Other resources may include validation tests 316. These validation tests may, for example, be individual automated test operations. Further resources may include service configurations 322. A service configuration can specify one or more features of a service, such as tables, REST resources, logic, and UI elements, or combinations thereof. In some cases, a service configuration can be defined in terms of abstract data that represents a desired custom configuration of the service (e.g., menu options or response entries in a survey or other type of questionnaire, and associated actions that can be triggered by the values ​​of the menu options or response entries). In some cases, the abstract data may represent human-readable content without program code, and the human-readable content forms the definition of the desired custom configuration. Thus, the human-readable content can define ways to extend or otherwise modify the service. Such customizations may be referred to as no-code customizations or no-code abstractions. In other cases, a service configuration can be defined in terms of other types of abstract data that may represent human-readable content containing a limited amount of custom program code. Such human-readable content can also define ways to extend or otherwise modify the service. A limited amount of custom program code (e.g., a custom code snippet) allows for the introduction of, for example, simple but customized logic. The limited amount of program code also allows the customization to be maintained as a service configuration rather than being promoted to one of the program code 308a or extension module 308b. Such a customization approach may be referred to as low-code customization or low-code abstraction. Other resources may include a user interface (UI) configuration 326. Other global resources may include a tenant configuration 332. Other resources may include a metadata definition 336. A metadata definition is a form of configuration that can define a data model for a particular tenant. For example, one or more of the metadata definitions 336 may include the tenant ID.K A data model K 160(K) can be defined for this purpose.

[0032] An example of a user interface 410 including visual elements representing a file system 415 (or exemplary virtual partition) for a specific tenant is shown in Figure 4A. According to embodiments described herein, the file system 415 includes several file folders corresponding to configuration files, extension files, extension metadata files, module files, validation test files, and workflow files. As shown in Figure 4A, the user interface 410 may also include a section 416 that can present at least a preview of a file (README.md) within the file system 415. Figure 4B illustrates an example of a user interface 418 including visual elements representing another example of the file system 415, so that its exemplary VP can be accessed in an IDE, according to one or more embodiments of the present disclosure. The IDE and the user interface 418 may be presented on a computing device that can receive input data via interaction with the IDE in order to configure or otherwise manipulate elements of the file system 415. In Figure 4B, the JavaScript object notation (JSON) definition of the exemplary VP is shown in pane 420. In fact, each virtual partition described herein includes a VP definition that identifies one or more compatibility attributes. Each compatibility attribute(s) identifies a component that can be functionally coupled to the virtual partition (e.g., by reference). In particular, as shown in Figure 4B, the VP definition includes a first compatibility attribute that identifies the version of the core platform on which the virtual partition is configured to operate. The core platform version corresponds to a persistent unique identifier that indicates the immutable content that makes up the core platform at a particular point in time. Thus, the first compatibility attribute can be, for example, a tag associated with (e.g., concatenated with) the persistent unique identifier that identifies the core platform version. In one example, as shown in Figure 4B, tag 424 corresponding to the exemplary first compatibility attribute is "use-platform-version:", and the persistent unique identifier is the string "2.8.0".

[0033] As described herein, the core platform refers to a group of multiple core modules, each having a set of extension points, and a group of multiple core modules may be available in a computer-executable form within the repository. Therefore, for any version of the core platform, the immutable content that forms the core platform at a particular point in time includes a group of multiple core modules. A group of multiple core modules provides defined services common to tenants and defines shared resources, including the core API and the core data model. For illustrative purposes, a shared resource may consist of contributions from each module (core module or extension module) within the group of modules, but from the perspective of the overall service, it may be used and viewed as a single, atomic resource. In addition, in some cases, within the core data model, each core module may contribute to the definition and linking, but the entire data model (or in some cases, partially) may be used to create the database. Furthermore, within the core API, each core module adds functions and endpoints, but from the client's perspective, this is the API for the entire service. Shared resources arising from extension modules may have a similar structure and functionality to shared core resources.

[0034] A VP definition also includes a second compatibility attribute that defines a reference to another VP (or, in some cases, multiple other VPs). The reference may include a unique locator identifier indicating the location of the other VP within the computer network, and data identifying a version of the other VP. Thus, the unique location identifier may, for example, be a Uniform Resource Locator (URL). The data may be a persistent unique identifier indicating the immutable content that constitutes the other VP at a particular point in time. Therefore, a version of the other VP corresponds to a persistent unique identifier. The second compatibility attribute may be, for example, a tag associated with one or more strings of characters. Each string may include a unique location identifier indicating the location of the VP within the computer network, and data identifying a version of the VP. In one example, as shown in Figure 4B, tag 428 corresponding to the exemplary second compatibility attribute is "use-base-virtual-partitions:", the first string 430a contains the unique location identifier "https: / / bitbucket001.company.cloud / projects / platform-tests" and "1.9.3" as persistent unique identifiers, and the second string 430b contains the unique location identifier "https: / / bitbucket001.company.cloud / projects / sponsorX-common-standards" and "1.7.1" as persistent unique identifiers.

[0035] As described herein, virtual partitions can be used to customize the core platform to build tenant-specific services. Thus, the VP definition can also include one or more control attributes (or other type of metadata) that can control the number of functionalities available when running services resulting from building the core platform. For that purpose, in some cases, a first of the one or more control attributes can identify a previous version of the core platform. The first control attribute can also cause a service built against the current version of the core platform to provide functionalities that are constrained by the functionalities of a previous service built against a previous version of the core platform. The first control attribute may be, for example, a tag (e.g., concatenated) associated with a persistent unique identifier that identifies a previous version of the core platform. As shown in Figure 4B, the tag 426 corresponding to the exemplary first control attribute is "release-feature-optin:", and the persistent unique identifier is the string "2.8.0".

[0036] Since the current version of the core platform can be built using tenant-specific VPs, such a first control attribute may exist in the VP definition of the tenant-specific VP. The first control attribute (such as the attribute exemplified by tag 426) can be accessed during the build time of the current version of the core platform, causing package components to be built so that the functionality of the previous version of the core platform is provided and the upgraded functionality of the current version of the core platform may be suppressed. More specifically, the codebase forming the current version of the core platform may contain program code that, in response to being compiled, can read a VP definition containing the first control attribute. The compiler subsystem can then generate an executable package component for the current version of the service such that this package component restricts the functionality of the service to the functionality of the previous version of the core platform.

[0037] Therefore, introducing a control attribute within the VP definition that identifies previous versions of the core platform makes it possible to upgrade the current version of a service to the next version without forcing the upgraded service to behave according to the next version. Thus, the frequency of service upgrades can be maintained while exposing desired legacy functionality to end users in the upgraded service. As a result, legacy functionality of a service can be flexibly selected and exposed without causing a disruption to the implementation of service upgrades and / or forcing changes on tenants.

[0038] At least some of the resources residing in a tenant-specific virtual partition may be reusable across different tenants. For example, some customization components defined in terms of comprehensive functionality can be applied across different clinical trials. Thus, in some embodiments, as shown in Figure 4C, a first virtual partition 440 (e.g., a file system) can be configured to hold tenant-specific customization components, and a second virtual partition 445 (e.g., another file system) can be configured to hold reusable customization components. The second virtual partition 445 may simply be referred to as the "base virtual partition" for naming purposes. The second virtual partition 445 can be referenced in the VP definition of the first virtual partition 440 via a customization attribute, where the customization attribute has a value defined by data that identifies the second virtual partition. As an example, the customization attribute may be a tag 428, and the data may include a string 430a. The first virtual partition 440 may contain various types of customization resources, such as definition data that identifies tenant-specific services, configuration data corresponding to tenant-specific services, and / or metadata corresponding to tenant-specific services. In addition, or in some embodiments, the first virtual partition 440 may include customization components, such as extension modules that customize tenant-specific services. Furthermore, or in other embodiments, the first virtual partition 440 may also include catalog data that identifies a catalog of extension points. The catalog data is first data that identifies a first extension point, and the first data may include first data that includes data identifying the domain of the first extension point, data identifying the functionality corresponding to the first extension point, a description of the first extension point that identifies one or more methods, input parameters for the first extension point corresponding to the first extension point, and outputs corresponding to the first extension point. Here, the term domain refers to a subject topic related to tenant-specific services.For example, if the tenant-specific service is a clinical trial, an example of a domain could be subject onboarding, subject management, drug management, supply management, or similar. Furthermore, in yet another embodiment, the first virtual partition 440 may also include one or more abstractions that define at least one of extension logic or extension parameters that characterize a manner of extending or otherwise modifying the functionality of the tenant-specific service. One or more abstractions may include, for example, at least one NOCODE abstraction, at least one LOWCODE abstraction, or a combination thereof. Thus, each abstraction of the abstraction may include human-readable code that defines a manner of extending or otherwise modifying the tenant-specific service.

[0039] Tenant-specific services can be customized through a combination of tenant-specific and reusable customization components, so that the first virtual partition 440 can reference (or point to) the second virtual partition 445. By referencing the second virtual partition 445, the first virtual partition 440 can inherit reusable customization components (e.g., configuration files). A reference to the second virtual partition 445 is represented by a white head arrow in Figure 4C. Such a reference may include a unique location identifier indicating the location of the second virtual partition 445 within the computer network, and data identifying the version of the second virtual partition 445. As stated, in this disclosure, the version corresponds to a persistent unique identifier indicating immutable content that forms the virtual partition at a particular point in time. The unique location identifier may include, for example, a URL, and the persistent unique identifier may be, for example, a string. Each character in the string may have a meaning defined, for example, in the versioning schema. For illustrative purposes only, the string may be "2.3.1".

[0040] In some cases, a first virtual partition may reference (or point to) one or more second virtual partitions, and each reference of a second virtual partition(s) to a virtual partition contains data identifying the version of the virtual partition. Similarly, a base virtual partition may reference (or point to) another base virtual partition, as reusable customization components may depend on other reusable customization components. Again, a virtual partition that references another virtual partition may inherit reusable customization resources (e.g., configuration files) or customization components, or both, that reside in that other virtual partition. Inherited reusable customization assets can be modified in the virtual partition that inherits the reusable customization component. For this purpose, a virtual partition can define modifications that are applicable to the reusable customization asset. Modifications can be defined via primitives or other types of code segments that specify directives in the virtual partition. For example, a reusable customization component could be a workflow definition, and a virtual partition may, in response to implementation, define modifications to that workflow definition such that these modifications trigger the generation of a new workflow definition containing additional operations. Modifications to reusable customizable components may include, for example, adding elements to a reusable customizable component, removing elements from a reusable customizable component, replacing elements in a reusable customizable component, or a combination thereof. Such modifications may generally be referred to as configuration modifications and may be defined, for example, in terms of program code that directs the modifications such as “add,” “delete,” or “replace.”

[0041] A reference from the first virtual partition 440 to the second virtual partition 445 can, by reference, integrate (or otherwise utilize) a selection of reusable customization components into the first virtual partition 440. In some cases, such a selection can be whole, thereby integrating (by reference) the entirety of the reusable customization components present in the second virtual partition 445 into the first virtual partition 440. In other cases, the selection can be partial, thereby identifying a subset of the reusable customization components and integrating it into the first virtual partition 440.

[0042] Figure 4D illustrates an example of a hierarchical structure that logically associates a tenant-specific virtual partition 460 with several other virtual partitions containing reusable customizable components, according to one or more embodiments of the present disclosure. The several other virtual partitions may be referred to simply as “base virtual partitions” for naming purposes. The base virtual partitions include a first base VP470(1), a second base VP470(2), a third base VP470(3), a fourth base VP470(4), and a fifth base VP470(5). The illustrated hierarchical structure is a tree structure 450 where the root node represents the tenant-specific virtual partition 460, and the leaf nodes represent each of the base virtual partitions 470(1) through 470(5). Other hierarchical structures can be used to represent the logical association between the tenant-specific virtual partition 460 and one or more base virtual partitions. For example, a hierarchical structure can be embodied in a directed graph having a first node representing a tenant-specific virtual partition 460 and one or more second nodes representing each of its base virtual partitions. To illustrate this point, Figure 4E illustrates the directed graph as directed graph 480, where the root node represents the tenant-specific virtual partition 460, and the other nodes in the directed graph 480 represent each of the base virtual partitions 470(1) to 470(3). Regardless of the specific type of hierarchical structure (tree structure or another type of graph), edges within the hierarchical structure represent references from the first virtual partition to the second virtual partitions. In one example, the first virtual partition could be the root virtual partition or a base virtual partition, and the second virtual partition could be another base virtual partition. Such references identify the second virtual partition in terms of its location within the computer network and its version.A reference can also contain data defining one or more configuration flags, each controlling the selection of customized assets (e.g., customized resources or customized components) in the second virtual partition to be included in the first virtual partition. Configuration flags can indicate the selection or deselection of customized assets. In some cases, a single configuration flag can indicate the selection or deselection of a group of customized assets. For example, the group being selected or deselected could be the entire set of customized assets present in the second virtual partition. Thus, customized assets in the second virtual partition can be selected individually or as a group to be included in the first virtual partition. Figure 4E illustrates an example.

[0043] To customize services for a specific tenant, tenant-specific virtual partitions can be selected for that tenant. Specifically, program code, configuration attributes, and / or other configuration resources within a tenant-specific virtual partition (e.g., a file system) can be selected as a whole. A tenant-specific virtual partition constitutes the root node in a hierarchical structure that logically associates that tenant-specific virtual partition with other virtual partitions (e.g., a base virtual partition). As described herein, examples of hierarchical structures include tree structures (e.g., tree structure 450 in Figure 4D) or directed graphs (e.g., directed graph 480 in Figure 4E). Regardless of its type, a hierarchical structure represents a system of memory devices containing tenant-specific virtual partitions and other virtual partitions, individually or in specific combinations. Again, whether the hierarchical structure is a tree or a directed graph, the association between tenant-specific virtual partitions and other virtual partitions is represented by the respective edges of the graph corresponding to the hierarchical structure. Each edge of each edge represents a reference that identifies a particular virtual partition of the other virtual partition in terms of its location within the computer network and the version of that particular virtual partition. One or more configuration flags corresponding to such references define the selection of one or more customization assets to be included in a tenant-specific virtual partition. Thus, references related to the hierarchical structure can collectively define the complete selection of customization assets (e.g., customization resources, customization components, or combinations thereof) to be included in a tenant-specific virtual partition.

[0044] Such selections can define a service in terms of components that can be built into executable package components (e.g., containers (such as Docker containers), executable binary files, or similar). In short, the service definition resulting from the selections can be sent to the build subsystem 510 (Figure 5). In some cases, the service definition can be sent in response to a one-click interaction or similar gesture interaction with a user interface presented to a computing device (not shown) functionally coupled to the build subsystem 510 (Figure 5). Based on the service definition, the build subsystem 510 can generate an executable package component 520. More specifically, the build subsystem 510 can translate the service definition into an executable package component 520. Like other executable package components disclosed herein, the executable package component 530 includes a service core 540, a number of core modules 544 (also referred to as feature modules), and tenant-specific extension modules 550 mapped to extension points 546. The service core 540 defines and exposes an API 530 (such as a REST API) for the service. In fact, a collection of multiple core modules 544 and tenant-specific modules 550 define and expose API 530.

[0045] To convert a service definition into an executable package 520, the build subsystem 510 may include multiple sets of rules within one or more memory devices (e.g., mass storage devices). These sets of rules can, for example, map service element configurations, metadata, and / or program code (such as extension classes or extension modules, or both) identified in the service definition to a format that matches the package type used to provide the service core 540. The package type enables the distribution of the executable package component 520 and may be a container, an executable binary file, or similar. The build subsystem 510 can apply the multiple sets of rules individually or in specific combinations to build the service definition into an executable package component 520.

[0046] Configuration attributes that form part of the service definition can, in some cases, be communicated as one or more configuration files in a selected tenant-specific virtual partition or a base virtual partition that directly or indirectly depends on that selected tenant-specific virtual partition. In some cases, at least one of the one or more configuration files may be a JSON definition file. Each configuration file may define a no-code (or no-code) abstraction that identifies a desired customized configuration of the service for a particular tenant. Such an abstraction can be embodied in human-readable content without program code, and the human-readable content forms the definition of the desired customized configuration. Thus, the human-readable content can define a form that extends or otherwise modifies the tenant-specific service. A set of rules applied by the build subsystem 510 may include a code template that can translate the abstraction into program code (such as C# code or C++ code). The build subsystem 510 can apply the code template to build the extension module and package the extension module into a container as part of a package component 520. The container is tenant-specific and can be built on top of a base container having a service core 540 (including core module 544).

[0047] The build system 510 manipulates service definitions configured in a file system (or virtual partition) within the data storage 302. Therefore, the build subsystem 510 can adapt to changes that may occur in the runtime subsystem 560 while isolating the data storage 302 from such changes. Thus, by separating the development of service elements from the generation of executable package components, greater computational efficiency can be achieved compared to existing technologies.

[0048] Furthermore, the build subsystem 510 can upgrade customized single-tenant package components (e.g., package component K 120(K)) by rebuilding the VP against source program code that defines a new version of the service core that provides services common across single-tenants. Thus, existing instances of configuration and extension modules can be upgraded to a new version of the common service core (or core platform) that allows those existing instances to run on the same updated core platform. In this way, the build subsystem 510 can also implement backward compatibility against the updated core modules by rebuilding the extension modules from the source program code. Because the build subsystem 510 can rebuild from the source program code, it can detect and correct changes that break backward compatibility at the source program code level and the binary level. As a result, the build subsystem 510 is more reliable and robust than existing technologies that rely solely on binary backward compatibility. Note that in some cases, the build subsystem 510 is flexible and can also leverage binary backward compatibility by building extension modules against existing pre-built extension modules. Building extension modules in this manner enables faster development. Therefore, the build subsystem 510 can flexibly transition between build modalities, namely building from source program code and building from pre-built modules, and thus select a build modality that provides speed that outweighs the strictness of backward compatibility, and vice versa.

[0049] In some embodiments, as shown in Figure 6, the build system 510 may include one or more parsing components 640 that can identify groups of one or more references to each of the first virtual partitions 620 (e.g., base virtual partitions) individually or in combination. For this purpose, the parsing components 640 may access (e.g., read) VP definition files that may be held (e.g., stored or stored in a manner that makes them available for later use) in a second virtual partition 610 (e.g., trial-specific virtual partitions). For illustrative purposes only, the VP definition file may be, for example, a JSON file illustrated in Figure 4B. At least one reference in a group of references (e.g., a single reference, two references, three or more references, or each reference) may include (i) a unique location identifier indicating the location of a particular virtual partition among the first virtual partitions 620 in a computer network, and (ii) data identifying the version of a particular virtual partition. Again, such a version corresponds to a persistent unique identifier that indicates immutable content forming a particular virtual partition at a specific point in time. The unique location identifier may include, for example, a URL, and the persistent unique identifier may be, for example, a string. Each character in the string (e.g., "2.3.1") may have a meaning defined in, for example, the versioning schema. The first virtual partition 620 and the second virtual partition 610 may be part of the VP subsystem 604. The VP subsystem 604 may include one or more memory devices, individually or in combination, that form one or more data repositories.

[0050] As described herein, in some cases, one or more groups of references define a graph representing the logical organization of each first virtual partition 620 and the second virtual partition 610. The graph includes nodes and edges, where the first node of each first virtual partition represents the first first virtual partition, and the second node of each first virtual partition represents the second first virtual partition. An example of a graph may be a tree structure 450 (Figure 4D).

[0051] A parsing component(s) 640 can determine, individually or in combination, whether a group of references meets a consistency criterion. For this purpose, the parsing module 640 can traverse a graph and compare references that point to the same virtual partition in the first virtual partition 620. The consistency criterion can indicate that such references must identify the same instance or version of the same virtual partition in order to maintain consistency.

[0052] If the group of references meets consistency criteria, one or more merge components 650 included in the build system 510 can individually or in combination generate a centrally managed virtual partition 632 (which may be referred to as a workspace or workspace storage) in the data storage 630. The centrally managed virtual partition 632 may contain one or more computer-readable components present in each of the virtual partitions of the first virtual partition 620 and the second virtual partition 610. In some cases, at least one of the computer-readable components may be a binary (or computer-executable) component. One or more merge components 650 can generate the centrally managed virtual partition 632 by flattening a graph (e.g., a directed graph or tree structure) representing the logical organization of the first virtual partition 620 and the second virtual partition 610. As an example, flattening a graph may include generating copies of all customization components and customization resources within the first virtual partition 620 and the second virtual partition 610, and retaining such copies within a centrally managed virtual partition 632. The copies may be generated and retained in the order of the graph, according to the logical organization provided by the graph. More specifically, the order of the graph is the order in which references between virtual partitions in the graph are made. In addition, or in some cases, flattening a graph may include applying one or more primitives (or other types of directives) present in the first virtual partition 620 and the second virtual partition 610. One or more primitives may be applied in the order of the graph. As described herein, such primitives may define one or more modifications applicable to customization resources or customization components.Therefore, as part of flattening the graph, at least one of the merge component(s) 650 can apply one or more primitives individually or in combination.

[0053] Before retaining each copy, at least one of the merge component(s) 650 can collect information identifying one or more conflicts that may exist between the two or more copies of each customized asset. An example of a conflict is a file collision (or conflict) involving two or more files, where each file corresponds to the same customized resource but has different identifying attributes to the other files(s) in the two or more files. At least one of the merge component(s) 650 can collect such information in response to detecting one or more conflicts as part of flattening the graph. In other words, as part of flattening the graph, at least one of the merge component(s) 650 can determine that a conflict exists between a first copy of a customized asset and a second copy of the customized asset. Such copies may be contained in the respective virtual partitions of the first virtual partition 620 (e.g., base VP) and the second virtual partition 610 (e.g., tenant-specific VP). Determining that such a conflict exists allows at least one of the merge component(s) 650 to collect information indicating the conflict. As the graph flattening process progresses, at least one of the merge component(s) 650 may detect one or more other conflicts and, in the response, collect additional information indicating such other conflict(s). Additionally, or in some cases, at least one of the merge component(s) 650 may provide a report identifying one or more conflicts detected as part of the graph flattening process. Providing a report may include holding the data constituting the report in data storage, transmitting such data to a computing device (not shown in Figure 6), and / or presenting the data constituting the report on a display device.For example, a display device can be integrated into or functionally coupled to a computing device.

[0054] In addition, or in some cases, at least one component of the merge component(s) 650 may receive input data that defines a solution to one or more conflicts detected. At least one component of the merge component(s) 650 may resolve one or more conflicts by applying such a solution. The input data may be referred to as solution data for naming purposes only. Furthermore, or in other cases, at least one component of such merge component(s) 650 may resolve one or more conflicts at least partially. For that purpose, at least one component of the merge component(s) 650 may determine a solution to at least one of the conflicts by applying a conflict resolution process, and in some cases, may also implement one. In some situations, at least one component of the merge component(s) 650 may use the solution data as part of applying a conflict resolution process. As an example, in an exemplary scenario where a conflict exists in a file, a component of the merge component(s) 650 may resolve the conflict by overriding the use of that file with another file in its place. The other file can then be stored in a centrally managed virtual partition 632. As another example, in an exemplary scenario where one or more conflicts exist, a component of the merge component(s) 650 can resolve the conflict by selecting one of the two or more conflicting files. Such a selection may be policy-based. For example, the two or more conflicting files may each have their own associated parameters (e.g., priority values), and the policy may stipulate that the conflicting file with the highest associated parameters among the two or more conflicting files should be selected.In situations where multiple conflicting files have the same related parameter, and that parameter is the most related parameter, the policy can instruct that an error message should be provided, or the policy can trigger the application of a defined deambiguation process.

[0055] The build subsystem 510 can generate one or more computer-executable components based on one or more computer-readable components contained in a centrally managed virtual partition 632. A computer-executable component(s) may include one or more tenant-specific extension modules 636. Generating a computer-executable component(s) may include building (e.g., linking and / or compiling) computer-readable components(s). Therefore, the build subsystem 510 may include one or more build components 670 that can build computer-readable components(s) individually or in combination.

[0056] In some cases, generating a computer-executable component(s) may involve translating at least one computer-readable component from one or more computer-readable components into a respective program code artifact 634. To that end, as illustrated in Figure 6, the build subsystem 510 may, individually or in combination, retrieve at least one computer-readable component from a centrally managed virtual partition 632, and then include one or more translation components 660 that can use at least one computer-readable component to generate a specific code artifact that can be compiled or otherwise built. The at least one computer-readable component may be based on abstraction data configured using a no-code or low-code approach. In a no-code approach, the abstraction data may be configured in terms of human-readable content without program code. In a low-code approach, the abstraction data may be configured in terms of human-readable content containing a limited amount of custom program code (e.g., a snippet of custom program code). That limited amount may be a small number of lines of custom program code, such as 5 lines, 10 lines, 15 lines, 20 lines, or similar. To generate a specific code artifact, at least one of the transformation component(s) 660 can access a code template (or transformation template) from a second virtual partition 610, or in some cases, from a natively available set of code templates, and apply the accessed code template to at least one computer-readable component to produce the specific code artifact. Additionally, generating a computer-executable component based on a specific code artifact may also include building a computer-executable component using the respective program code artifacts.At least one of the 670 build components can build a specific program code artifact.

[0057] More specifically, as a simple example, generating a computer executable component(s) (e.g., extension module(s) 636) may include accessing abstract data contained in one or more computer-readable components from a centrally managed virtual partition 632. Again, the abstract data can define human-readable content that demonstrates a manner of extending tenant-specific services, and the human-readable content may contain no program code, or the human-readable content may contain a limited amount of custom program code. At least one of the transformation component(s) 660 may have access to the abstract data. For example, the abstract data may be formatted according to JSON, as residing in a centrally managed virtual partition 632, and may be held in a configuration file or another type of data structure. Additionally, generating a computer executable component(s) may also include accessing code templates (or transformation templates) that may reside in a second virtual partition 610. For example, at least one of the transformation component(s) 660 may also have access to code templates. In another example, at least one second component of the transformation component(s) 660 may have access to the code template. Furthermore, generating a computer executable component(s) may also include generating a first computer executable component of one or more computer executable components via one or a combination of build components(s) 670, based on the abstracted data and the code template.

[0058] As part of generating a computer executable component(s), build component(s) 670 can access computer-readable components that define customized components, such as tenant-specific extension modules, individually or in combination, and from a centrally managed virtual partition 632. Build component(s) 670 can build such computer-readable components (e.g., tenant-specific extension modules) individually or in combination against a core codebase 680 containing multiple core modules. As described above, a computer executable component(s) built in this manner may contain at least one of the tenant-specific extension modules(s) 636.

[0059] The build system 510 can build program code that defines multiple core modules associated with a particular version of the core platform, either through one or more build components 670 or a combination of build components 670. This version can be identified, for example, in a VP definition located in a second virtual partition 610. The program code can form a codebase 680. In this way, the build system 510 can generate a build core module 688, which can be stored in one or more memory devices 686 (commonly referred to as data storage 686).

[0060] Next, the build subsystem 510 can build an executable package component 694 (for example, one of package components 1 to N580 (Figure 5)) by combining the built core module 688 with tenant-specific extension modules that are built as described herein. The executable package component 694 is specific to a particular tenant corresponding to a second virtual partition 610. The executable package component 694 can be embodied, for example, as a container, an executable binary file, or the like. The executable package component 694 can be held in one or more memory devices 690 (generally referred to as data storage 690). The data storage 690 may be part of a distributed storage system, such as a network of storage server devices. In some cases, the data storage 690 may be part of a computing device (such as a server device) that hosts the build subsystem 510. For example, in such a case, the data storage 690 may be embodied in mass storage present on the computing device.

[0061] In some embodiments, the build subsystem 510 can generate program code 684 from a second virtual partition 610 and pass the generated program code 684 to the core codebase 680. For this purpose, in such embodiments, a conversion component among the conversion component(s) 660 can generate program code 684 from a customization component held (or, in some cases, referenced) in the second virtual partition 610. Such a conversion component can hold the generated program code 684 in a defined section of the core codebase 680. That section may be, for example, an empty directory within the core codebase 680. In such embodiments, the core codebase 680 may be a replica of the core codebase corresponding to a particular version of the service core. By relying on such a replica, at least one of the build component(s) 670 can combine the program code 684 with one or more other components already present in the core codebase 680 at build time. Such combinations allow for the extension or customization of one or more components without duplicating one or more components to one or more of the second virtual partitions 610 or 620. As a mere example, a component residing in the core codebase 680 could be a class that can be extended by adding fields or other types of attributes via the generated program code 684. Fields (or attributes) could be the subject's height, date of birth, age, or similar. Therefore, instead of adding all desired fields of a class within a customized component (e.g., one of the extension modules 308b) in the second virtual partition 610, all desired fields could be added as a single file and then combined with the class using the build logic of a build component 670.

[0062] Therefore, at least one of the build component(s) 670 can determine whether the core codebase 680 has been modified before generating the executable package component 694. If the core codebase 680 has been modified, one of the build component(s) 670 or a combination of build component(s) 670 can use the modified core codebase 680 to generate a new instance of the build core module 688. Then, at least one of the build component(s) 670 can generate the executable package component 694 by combining it with computer executable components(s) that form the new instance of the build core module 688.

[0063] Referring further to Figure 5, the build subsystem 510 can deploy executable package components 520 to a runtime subsystem 560 which includes a cluster of compute server devices (not shown in Figure 5). The runtime subsystem 560 can receive tenant-specific single-instance services (or, in some cases, multi-tenant services) packaged as executable package components q (k=1, 2..., N), and can deploy such components within the cluster of compute server devices. The index q represents a particular tenant. In some embodiments, the cluster includes a SaaS Kubernetes cluster and a Kubernetes container orchestration subsystem, where executable package component q is a container or constitutes a container. As shown in Figure 5, the runtime subsystem 560 can deploy multiple executable package components 580, including executable package component 1, executable package component 2, and up to executable package component N. Thus, the runtime subsystem 560 can host N mutually isolated tenant-specific services (e.g., clinical trials). The runtime subsystem 560 can handle any configuration of the API router component 570 (e.g., an API gateway). The runtime subsystem 560 can also allocate resource quotas to each tenant. Quotas may apply to processing time and / or storage resources.

[0064] The runtime subsystem 560 may also include one or more database server devices 590. In some cases, one of the database server devices 590 hosts a database that holds a data model q for a particular tenant, or for a tenant-specific service of that particular tenant. That database may be isolated (e.g., logically isolated) from another database that holds a data model q' for another tenant. The database server devices may be embodied in or include an SQL Server or a NoSQL Server. In some cases, a database instance for a first tenant may be physically isolated from a database instance for a second tenant. Specifically, a first database service device among multiple database server devices 590 may correspond to a first tenant, and a second database server device among multiple server devices 590 may correspond to a second tenant.

[0065] As illustrated in Figure 6, the build subsystem can generate executable package components by relying on customizations developed in a first development environment and a core codebase developed in a second development environment. As described herein, customizations can be defined by one or more virtual partitions, for example, a group of first virtual partitions 620 and second virtual partitions 610. The core codebase can be defined, at least in part, by a core codebase 680. The first and second development environments can be decoupled and therefore operated or managed separately by different entities. For example, an entity can develop a core codebase for providing service cores, and customizations can be developed by a third party. Such decoupling between the first and second development environments can enable upgrading the core codebase independently of the development of customizations applicable to a particular tenant. Thus, as described herein, tenant-specific services can migrate to an upgraded service core by updating the appropriate virtual partition(s) to refer to (sometimes colloquially referred to as "pointing to") the upgraded service core. A virtual partition can reference an upgraded service core, for example, through a VP definition that includes the compatibility attribute "use-platform-version:" and a persistent, unique identifier that identifies the upgraded service core version. Therefore, customizing tenant-specific services and upgrading those services can be simplified, potentially leading to more efficient use of computing resources and time.

[0066] This disclosure describes how the service core (or core platform) can be upgraded in at least two ways. One method involves adding one or more enhancements to the core modules that make up the current version of the service core. Such additions result in a core codebase that embodies the next version of the service core. The other method involves changing the functionality, user interface, and / or other elements of the current version of the service core. These changes may include the removal of existing functionality, revisions to existing functionality, additions or new functionality, or a combination thereof. Such changes also result in a core codebase that embodies the next version of the service core. Regardless of how the upgrade is achieved, the resulting core codebase (e.g., core codebase 680) can be used to migrate existing tenant-specific services to the next version of the service core.

[0067] In relation to adding extension points to a service core (or core platform), Figure 7A is a schematic diagram illustrating an exemplary process 700 for expanding the scalability of a service core. The scalability of a service core (e.g., service core 140 (Figure 1)) is provided by one or more extension points. Therefore, adding extension points expands its scalability. The services provided by the service core are common across single tenants as described herein and can be customized into tenant-specific custom services by mapping one or more extension modules to each of the extension points of multiple extension points. The exemplary process 700 embodies a scalability approach in which additional extension points are introduced into a fork of the service core and then folded into the service core at a suitable time after the fork has been created. That suitable time may be after the integrity / stability of the fork has been tested and yielded sufficient results. The scalability approach may be referred to simply as Just-In-Time Scalability (JITX) for naming purposes. The scalability approach can be implemented by computing system 760 (Figure 7B), which may be referred to simply as JITX subsystem 760 for naming purposes. JITX subsystem 760 is part of computing system 750.

[0068] Process 700 can be implemented during the service core development timeline 710. During the development timeline 710, the service core can be maintained periodically at defined consecutive maintenance intervals Δt (e.g., 4 weeks, 1 month, 6 weeks, or similar). Thus, starting from version V0, after n maintenance intervals have elapsed, version V n A new version of the service core is created. After a defined number of maintenance intervals have elapsed, a new version of the service core can be released. In Figure 7A, as just one example, a new version of the service core is released after n=4 maintenance intervals have elapsed. JPEG0007888755000001.jpg64 is released.

[0069] The functional requirements of a particular tenant may not be known in advance after the initial configuration of the service core extension points. Therefore, in JITX, in response to the determination that one or more additional extension points are needed for that particular tenant, a copy of the source program code corresponding to the service core can be generated. As illustrated in Figure 7A, just as an example, time t f In this process, a copy of the source program code corresponding to version V1 of the service core is generated. The generator component 762 (Figure 7B) can generate a copy using core codebase A 770(A) containing the source program code corresponding to version V1. The generated copy may be referred to as a fork, and the generator component 762 may hold the fork in the forked codebase 782. The repository 780 may hold the forked codebase 782. During a time interval 720 (which may be referred to as the fork duration), one or more extension points can be added to an existing set of modules (e.g., core modules), thereby enhancing the initial configuration of the extension points. One or more extension points are specific to a particular tenant. Despite being tenant-specific, in some cases, extension points may be generated to have a broader scope when inserted into a service core release. The existing set of extension points includes a first existing extension point corresponding to a first core module among a group of core modules that form version V1 of the service core. The time interval span of 720 can be based, for example, on the complexity of the additional extension points and the time required to implement and probe the extension points. As shown in Figure 7B, the generator component 762 can generate, for example, extension points and store extension points in one or more configuration files 784. Other types of data structures can also contain extension points.

[0070] By creating such a copy of the program code and adding tenant-specific extension points (or extensions) to version V1 of the service core, an updated version 730 of the service core can be created for a specific tenant to which unexpected functionality should be added to the service core. 1-X (referred to as) is applicable to a specific tenant and can be operated outside of the development timeline 710. As stated, the updated version 730 can be kept within the forked codebase 782. In this way, V 1-X It serves as a software testbed for added tenant-specific extensions and for improving the scalability of the service core. Therefore, the forked version of the service core (e.g., version V1) and subsequent versions of the service core remain common and available to other tenants. In some cases, a copy of the source program code with additional tenant-specific extensions can be manipulated to probe the integrity of that copy. In short, one or more automated tests can be applied to the modified copy of the source program code. The automated tests can probe the integrity of the modified copy individually or in combination. In some cases, applying automated tests involves determining, based on control flow analysis, whether there have been any changes to the control flow of the copy of the source program code with the added extensions.

[0071] After sufficient results from applied automated tests, a copy of the source program code with the added extension(s) can be merged with the current version of the service core to produce a next version of the service core with the added extension(s). In some embodiments, the merger component 764 can merge the copy of the source program code with the current version. The current version can be retained in the core codebase 770(B), and the next version of the service core can be retained in the candidate codebase 790. The next version of the service core can then be built into an executable package component. For this purpose, in some embodiments, the compiler subsystem 796 can build the executable package component. In one example, the next version of the service core may be a maintenance release for the service core. The executable package component (e.g., package component K 120(K) (Figure 1)) includes several core modules containing the added extension(s) and also includes an API (e.g., API K 130(K) (Figure 1)). In some cases, at least one of the added extension points may have tenant-specific extension modules mapped to at least one extension point.

[0072] There are several methods for merging a copy of the source program code with the added extension(s) with the current version of the service core. In one exemplary scenario, see Figure 7A, V 1-XThe added extension(s) in V2 are clearly distinguishable from other program code; for example, they can be commented out or marked differently. Therefore, the added extension(s) can be isolated and incorporated into V2 (e.g., the current version) to form V3 (the next version). Such incorporation is represented by lines and arrows from the updated version 730 to V3. In addition to the added extension(s), other safeguard code can also be incorporated into V3 to ensure that existing logic arising from V2 remains unaltered by the presence of the added extension(s) in V3. Such an approach to generating the next version of the service core provides complete backward compatibility by build. In another exemplary scenario, V 1-X The source program code in V1 and the source program code in V2 can be combined, for example, directly using standard merge techniques to form V3. While this approach is simple and efficient, the merge of source program code may have the potential to incorporate logic or other elements beyond the added extension point(s). Therefore, in some cases, there may be a likelihood of unintended partial backward compatibility.

[0073] As illustrated in Figure 7A, the next version of the service core with added extensions(s) may be a maintenance release and, as stated, may be retained in, for example, candidate codebase 790. Therefore, the source program code resulting from the mergers above, and the executable package component obtained from having added extensions(s), can be released as part of a maintenance release for the service core. That is, the service core resulting from the addition of one or more extensions may be available and common to other tenants other than the specific tenant in which the added functionality is configured. During the intermediate time between the initial release of the executable package component and subsequent releases of the service core, process 700 may include a test stage 740 in which the executable package component may be subjected to multiple automated verification tests. The number of automated verification tests may depend on the added functionality. In some cases, instead of subjecting the executable package component to multiple automated verification tests, a single automated verification test may be applied. Such an automated verification test(s) may be tenant-specific and can probe the integrity of the executable package component. The integrity of the executable package component can be probed for any tenant using previous versions of the service core. Automated verification tests (multiple) may be part of a previous version of the service core and can be extended by virtual partitions. The automated verification tests (multiple) included in test 740 can be based on control flow analysis, individually or in combination, and can probe for changes to the control flow in the executable package component relative to the service core before the addition of extension points (multiple). For illustrative purposes only, as shown in Figure 7A, the executable package component may be released as version V3 of the service core, and the automated tests will be version V3 of the service core. This can be applied during the interim period prior to the release of TIFF0007888755000002.tif64. In some embodiments, the promotion component 766 (Figure 7B) can implement automated verification tests. In response to sufficient test results (e.g., no broken backward compatibility), the promotion component 766 will update the program code in the candidate codebase to the service core version. The core codebase 794 corresponding to TIFF0007888755000003.tif64 can be promoted. Promoting program code may include keeping the program code in the repository and assigning a persistent unique identifier that defines version V3 (or another appropriate version) of the service core.

[0074] The terminal computing device (not shown in Figure 7A) can cause the promotion component 766 (Figure 7B) to implement or otherwise instruct the test stage 740 via the API router component 110 (Figure 1) and the API corresponding to the service core. To this end, the terminal computing device can execute program code, such as a script, which applies one or more automated verification tests to an executable package component obtained from building a copy of the source program code with added extension points(s). The automated verification tests(s) can be applied by invoking one or more function calls to the API via the API router component 110 (Figure 1). In response to executing the program code, the terminal computing device can retrieve the automated verification tests(s) from a virtual partition in the data storage 302 (Figure 3). The automated verification tests(s) may be a subset of the verification tests 316 (Figure 3).

[0075] At least some of the automated validation tests (or multiple tests) may include their respective workflows, each containing a defined collection of test stages. Thus, automated validation tests can be applied computationally efficiently and, therefore, accelerated in performance, by selectively executing subsets of test stages rather than the entire collection. For example, automated validation tests (or multiple tests) can be applied in an order that reduces the risk of consequences brought about by potential errors in operation / logic, with the first test logic producing a catastrophic outcome (e.g., harm to the health of clinical trial subjects) if incorrect, and then continuing to test other logics that, if incorrect, produce less catastrophic outcomes. As another example, automated validation tests (or multiple tests) can be applied to a modified part of logic without testing other logics that remain unchanged and are known to be sufficiently effective. Additionally, or in some cases, computational efficiency can also be achieved by generating synthetic data that avoids human intervention in testing various operation vectors. For illustrative purposes, the vector could be that a given clinical trial sets up outpatient visits rather than home visits. Therefore, the home visit logic does not need to be tested or otherwise probed, for example.

[0076] In relation to updates to the functionality of a service provided by a service core (or core platform), Figure 8 illustrates an exemplary computing system 800 for upgrading a service core based on the updated functionality of that service, according to one or more embodiments of the present disclosure. As stated, this service is common across single tenants. The exemplary computing system 800 includes a generator component 812 that can generate a copy of the source program code corresponding to the service core. The source program code can form a core codebase 820 corresponding to the current version of the service core. That version is shown in Figure 8, simply for naming purposes, as V nIt is represented by. The service core includes a plurality of core modules that provide services, and the source program code corresponds to the plurality of core modules and encodes the defined functionality of the service. The defined functionality is specific to version V n Generated copies may be referred to as forks, and the generator component 812 can hold the forks within the forked codebase 832. The repository 830 can hold the forked codebase 832. In some embodiments, the repository 830 can be the same as the repository 780 (FIG. 7).

[0077] The generator component 812 can modify a copy (fork) of the source program code in the forked codebase 832. The modified copy of the source program code updates the defined functionality of the service. The generator component 812 can modify the copy of the source program code by adding program code that defines new functionality, revising existing program code that defines existing functionality, or removing existing functionality (which may be called deprecating). In some cases, in order to modify the copy of the source program code, the generator component 812 can receive input data 804a that defines the program code and / or signaling 804b that modifies the available program code. Such signaling may include, for example, instructions for editing a piece of program code. The input data 804a and signaling 804b can be received from a computing device (not shown in Figure 8), for example, via a user interface functionally coupled to the upgrade subsystem 810. Additionally, the generator component 812 can integrate the added program code and changes to the program code into the forked codebase 832. Therefore, the computing system can evolve the forked codebase 832 based on the input data 804a and / or signaling 804b until one or more desired changes to the copy of the source program code are implemented. Such evolution is represented by an arc with a white arrowhead.

[0078] To probe the integrity of the modified copy, the modified copy of the source program code can be manipulated. In short, the upgrade subsystem may include a test component 814 that can apply one or more automated tests to its modified copy of the source program code. The automated tests(s) can probe the integrity of the modified copy individually or in combination. In some cases, applying the automated tests(s) involves determining, based on control flow analysis, whether there have been any changes to the control flow of the modified copy of the source program code.

[0079] After sufficient results from the applied test(s), the test component 814 can generate the next version of the service core based on a modified copy of the source program code. The next version of the service core forms candidate codebase 840 and includes updated defined functionality. The next version of the service core constitutes an upgrade of the service core in terms of functionality. The upgraded service core provides services according to the updated defined functionality. The next version of the service core is simply named V in Figure 8. k+1 It is represented by the next version (V) of the service core. In some embodiments, the next version (V) of the service core k+1 ) generating the current version of the service core (V k To ensure that existing logic arising from ) remains unaltered by the updated defined functionality, this may include incorporating safeguard code into the modified copy of the source program code.

[0080] The upgraded service core continues to provide services that are common across single-tenants, albeit according to updated defined functionality, so the operational integrity of the upgraded service core can be probed. Therefore, computing system 800 can build a second source program code corresponding to the next version of the service core. The second source program code may be candidate codebase 840. For that purpose, computing system 800 may include a compiler subsystem 850. In one example, compiler subsystem 850 may be compiler subsystem 796 (Figure 7). Building candidate codebase 840 results in an executable package component (e.g., a container, an executable binary file, or similar). The executable package component may include multiple core modules that have been built and provide upgraded services with updated defined functionality, individually or in combination. The executable package component may also include a common core API. Additionally, computing system 800 may include an elevation component 816 that can operate the executable package component by applying one or more automated verification tests. Automated verification tests (multiple) can probe the integrity of the operation of executable package components, individually or in combination. Applying a second automated test (multiple) may include determining, based on control flow analysis, whether there are any changes to control the flow of executable package components to the service core before the defined functionality of the service is updated.

[0081] A terminal computing device (not shown in Figure 8) can either have the promotion component 816 apply automated verification tests(s), or can otherwise instruct it to apply automated verification tests(s). In some cases, the terminal computing device can apply automated verification tests(s) via the API router component 110 (Figure 1) and a common core API exposed by the service core. To that end, the terminal computing device can execute program code, such as a script, which applies one or more automated verification tests to an executable package component obtained from building a candidate codebase 840 with updated functionality. Automated verification tests(s) can be applied by invoking one or more function calls of the common core API via the API router component 110 (Figure 1). In response to executing such program code, the terminal computing device can retrieve automated verification tests(s) from a virtual partition in data storage 302 (Figure 3). Automated verification tests(s) may be, for example, a subset of verification tests 316 (Figure 3).

[0082] As described herein, at least some of the automated verification tests may include their respective workflows, each containing a defined collection of test stages. Thus, automated verification tests can be applied computationally efficient by selectively executing subsets of test stages rather than the entire collection, and therefore their performance can be accelerated. For example, automated verification tests may be applied in a sequence that reduces the risk of consequences resulting from potential errors in the operation and / or logic of an upgraded service core with updated functionality, with the first test logic producing catastrophic consequences (e.g., harm to the health of clinical trial subjects) if incorrect, followed by other operations and / or logic producing less catastrophic consequences if incorrect. As another example, automated verification tests may be applied to the updated functionality (or modified logic) without testing other functionality that remains unchanged and is known to function effectively. Additionally, as described herein, computational efficiency can also be achieved by generating synthetic data that avoids human intervention in testing various operation vectors. For illustrative purposes, the vector could be that a given clinical trial is set up as an outpatient visit rather than a home visit. Therefore, the home visit logic does not need to be tested or otherwise probed, for example.

[0083] In response to sufficient test results (multiple results possible) (e.g., no broken backward compatibility), the promoted component 816 will deploy the second source program code in the candidate codebase 840 to version V of the service core. n+1 It can be promoted to the corresponding core codebase 860. Promoting program code means keeping the program code in the repository and the service core version V n+1 This may include assigning a persistent unique identifier that defines it.

[0084] The JITX subsystem 760 (Figure 7B) and the upgrade subsystem 810 (Figure 8), along with the various repositories coupled to them, can form a computing system that embodies a development environment that can be used to develop the core codebase. Such a computing system may be referred to as an evolutionary system. Compared to existing technologies, its evolutionary system can offer greater upgrade flexibility and superior capacity to mitigate errors resulting from changes in the structure and / or logic of the service core. Such improvements over existing technologies are achieved by systematically testing and verifying changes to the service core before promoting it to an upgraded service core.

[0085] Considering the embodiments described herein, exemplary methods that may be implemented in accordance with this disclosure can be better understood by referring, for example, to the flowcharts in Figures 9 to 12. For the sake of simplicity, the exemplary methods disclosed herein are presented and described as a series of blocks (for example, each block represents an action or operation in the method). However, exemplary methods are not limited by the order of the blocks and their associated actions or operations, and some blocks may be performed in a different order and / or simultaneously with other blocks than those shown and described herein. Furthermore, not all illustrated blocks and associated actions may be required to implement an exemplary method according to one or more embodiments of this disclosure. Two or more exemplary methods (and any other methods disclosed herein) may be implemented in combination with each other. Note that exemplary methods (and any other methods disclosed herein) may alternatively be represented as a series of interrelated states or events, such as in a state diagram.

[0086] Figure 9 is a flowchart of an exemplary method 900 for providing a single-tenant customized and extensible service, according to one or more embodiments of the present disclosure. A system of computing devices may implement exemplary method 900 in whole or in part. For that purpose, each computing device of the computing device includes computing resources that can implement at least one of the blocks included in exemplary method 900. Computing resources include, for example, a central processing unit (CPU), a graphics processing unit (GPU), a tensor processing unit (TPU), memory, disk space, incoming bandwidth and / or outgoing bandwidth, interfaces (I / O interfaces or APIs or both), controller devices (may), power supplies, combinations thereof, and / or similar resources. In one example, a system of computing devices may include programming interfaces (may), an operating system, software, firmware, and similar resources for configuring and / or controlling a virtualization environment. A system of computing devices may be referred to as a computing system.

[0087] In block 910, the computing system can configure a defined service based on multiple core modules, including at least one extension point corresponding to a first core module among the multiple core modules.

[0088] In block 920, the computing system can configure an API corresponding to a defined tenant. For example, the API may be API J 130(J) (Figure 1). The API can be configured by tenant-specific virtual partitions (and, in some cases, associated base virtual partitions) as part of building an executable package component that includes multiple core modules and mapped extension modules(s).

[0089] In block 930, the computing system can configure an API router component that exposes APIs. The API router component may be an API gateway. For example, the API router component may be API router component 110 (Figure 1). As described herein, the API router component can expose a collection of single-tenant APIs as a multi-tenant deployment, according to a SaaS model for accessing services.

[0090] In block 940, the computing system can receive messages via the API router component that initiate function calls to defined services. These messages may include attributes that identify a defined tenant. In some cases, the attribute identifying a particular tenant may be either an authentication token or a REST parameter. In other cases, the attribute may be a tenant ID that uniquely identifies the defined tenant. The tenant ID may be, for example, a UUID.

[0091] In block 950, the computing system can redirect function calls to customized, defined services via the API router component.

[0092] Figure 10 is a flowchart of exemplary method 1000 for providing a single-tenant customized and extensible service, according to one or more embodiments of the present disclosure. A computing device or a system of computing devices may implement exemplary method 1000 in whole or in part. For that purpose, each computing device of a computing device includes computing resources that can implement at least one of the blocks included in exemplary method 1000. Computing resources include, for example, a CPU, GPU, TPU, memory, disk space, incoming bandwidth and / or outgoing bandwidth, interfaces (I / O interfaces or APIs or both), controller devices (may), power supplies, combinations thereof, and / or similar resources. In one example, a system of computing devices may include programming interfaces (may), an operating system, software, firmware, and similar resources for configuring and / or controlling a virtualization environment. A system of computing devices may be referred to as a computing system.

[0093] In some cases, a computing system implementing Exemplary Method 1000 may host, among its software modules, a parsing component(s) 640, a merge component(s) 650, a transform component(s) 660, and a build component(s) 670 (Figure 6). The computing system may implement Exemplary Method 1000, for example, by executing one or more instances of the parsing component(s) 640, the merge component(s) 650, the transform component(s) 660, and the build component(s) 670. Thus, in response to execution, the parsing component(s) 640, the merge component(s) 650, the transform component(s) 660, and the build component(s) 670 may individually or in combination perform operations corresponding to blocks of Exemplary Method 1000, individually or in combination.

[0094] In block 1010, the computing system can generate one or more computer executable components based on a core codebase. The core codebase (for example, core codebase 680 (Figure 6)) can contain program code that defines one or more core modules. Computer executable components can be generated by building their program code. The program code can be built, for example, via build component 670. In some cases, each component can generate multiple computer executable components corresponding to computer executable core modules. Multiple computer executable components may be built core modules 688 (Figure 6).

[0095] In block 1015, the computing system may hold one or more computer executable components in a first data repository (e.g., data storage 686 (Figure 6)).

[0096] In block 1020, a computing system can identify a group of one or more references to each of the first virtual partitions. At least one reference in the group of references may include (i) a unique location identifier indicating the location of a particular virtual partition among the first virtual partitions within the computer network, and (ii) data identifying a version of a particular virtual partition. The unique location identifier may include, for example, a URL, and the persistent unique identifier may be, for example, a string. Each character in the string may have a meaning defined in the versioning schema. An example of a string is "2.3.1". Regardless of its format, as stated, the persistent unique identifier indicates the immutable content that forms a particular virtual partition at a particular point in time. That immutable content constitutes a version of a particular virtual partition, and therefore the version is identified by the persistent unique identifier. In some cases, a group of one or more references defines a graph (such as a directed graph) representing the logical organization of each of the first virtual partitions. The graph includes nodes and edges, where the first node represents the first first virtual partition of each first virtual partition, and the second node represents the second first virtual partition of each first virtual partition. As an example, one or more groups of references define a tree structure, where the first virtual partitions constitute each node in the tree structure, and each node in each virtual partition may depend on the root node (in some cases directly, indirectly, and in other cases). In short, the tree structure may be the exemplary tree structure 450 shown in Figure 4D. Thus, the first virtual partitions may include base VP 470(1), base VP 470(2), base VP 470(3), base VP 470(4), and base VP 470(5), and the root node may be virtual partition 460.

[0097] In block 1025, the computing system can determine that one or more groups of references satisfy the consistency criterion. As stated, the consistency criterion can indicate that, in order to maintain consistency, the reference(s) must identify the same instance or the same version of the same first virtual partition.

[0098] In block 1030, the computing system may generate a second virtual partition containing one or more computer-readable components present in each of the first virtual partitions. The generated second virtual partition is a centrally managed virtual partition. For example, the second virtual partition may be a centrally managed virtual partition 632 (Figure 6), which is not shown in Figure 10, but the computing system may hold the second virtual partition in a second data repository. If the graph represents the logical organization of each of the first virtual partitions, generating the second virtual partition includes flattening the graph. Flattening the graph, as described herein, may include applying one or more primitives (or other types of directives) present in the first virtual partitions. The one or more primitives may be applied in the order of the graph, i.e., in the order in which references between virtual partitions in the graph are made. Such an order is referred to as the order of the graph.

[0099] In addition, or in some cases, flattening a graph may include generating a copy of each of all customized assets, e.g., customized components or customized resources, or combinations thereof, within each first virtual partition, and further, maintaining each such copy within a centrally managed virtual partition. The copies may be generated and maintained in the order of the graph, i.e., in the order in which references between virtual partitions within the graph are made, according to the logical organization provided by the graph. Again, such an order is referred to as the order of the graph. In some cases, before maintaining each such copy, the computing system may collect information to identify one or more conflicts that may exist between two or more copies of each customized asset. Thus, flattening a graph may include determining that a conflict exists between the first copy of each copy and between the second copy of each copy. In response to such determination, flattening a graph may also include determining a solution to the conflict by applying a defined process based on one or more policies, as described herein. Furthermore, or otherwise, before retaining each such copy, flattening the graph may also include determining if a conflict exists between the first copy of each copy and the second copy of each copy. In response to such determination, flattening the graph may also include sending a report indicating the conflict. The report may be sent to a computing device or component functionally coupled to the computing system. Additionally, flattening the graph may include receiving resolution data (e.g., from a computing device or component) that defines a solution to the conflict.

[0100] In block 1035, a computing system can generate one or more computer-executable components based on one or more second computer-readable components. One or more second computer-executable components may include at least one tenant-specific extension module. Generating one or more second computer-executable components may include building (e.g., linking and / or compiling) one or more computer-readable components. In some cases, generating one or more second computer-executable components may include translating at least one of the one or more computer-readable components into its respective program code artifact. Additionally, generating one or more second computer-executable components may also include using its respective program code artifact to build at least one specific computer-executable component from the one or more second computer-executable components.

[0101] In addition, or in other cases, generating one or more second computer executable components may include accessing abstracted data contained in one or more computer-readable components from the second virtual partition. As stated, the abstracted data may define human-readable content that represents a mode expression extending tenant-specific services, and the human-readable content may contain no program code, or the human-readable content may contain a limited amount of custom program code. For example, the abstracted data may be formatted according to JavaScript object notation and may be held in a file or another type of data structure. Additionally, generating one or more second computer executable components may also include accessing code templates. Furthermore, generating one or more second computer executable components may also include generating one or more second computer executable components of the first computer executable component based on the abstracted data and code templates.

[0102] In block 1040, the computing system may hold one or more computer executable components in a second data repository (e.g., data storage 630 (Figure 6)) which may contain the second virtual partition generated in block 1030. Note that the second data repository may differ from one or more other data repositories, each containing a first virtual partition.

[0103] The combined implementation of blocks 1020, 1025, 1030, 1035, and in some cases, 1040, generates extension modules that allow for customization of the core platform associated with the core codebase and the first computer executable component(s).

[0104] In some cases, as described herein, the creation of a second virtual partition may result in one or more modifications to the core codebase. The modifications may, for example, be the addition of program code from one of the first virtual partitions (e.g., program code 684 (Figure 6)). Thus, in block 1045, the computing system can determine whether the core codebase has been modified. In response to a negative determination ("no" branch), the flow of exemplary method 1000 may proceed to block 1050, where the computing system can generate an executable package component by combining the first computer executable component(s) and the second computer executable component(s). The executable package component may be specific to a particular tenant and may, for example, be executable package component 694 (Figure 6). A particular tenant may correspond to at least one of the first virtual partitions. The executable package component may be deployed to a runtime subsystem (e.g., runtime subsystem 560 (Figure 5)) as one of the package components 580, according to the embodiments described herein. Alternatively, in response to an affirmative decision ("yes" branch), the flow of exemplary method 1000 may be directed to block 1055, where the computing system can generate one or more third computer executable components using the modified core codebase. Then, in block 1060, the computing system can generate an executable package component by combining the third computer executable component(s) and the second computer executable component(s). The executable package component may be specific to a particular tenant and could be, for example, executable package component 694 (Figure 6).

[0105] Figure 11 is a flowchart of exemplary method 1100 for extending the scalability of a service core associated with a service, according to one or more embodiments of the present disclosure. A computing device or a system of computing devices may implement exemplary method 1100 in whole or in part. For that purpose, each computing device of a computing device includes computing resources that can implement at least one of the blocks included in exemplary method 1100. Computing resources include, for example, a CPU, GPU, TPU, memory, disk space, incoming bandwidth and / or outgoing bandwidth, interfaces (I / O interfaces or APIs or both), controller devices (may), power supplies, combinations thereof, and / or similar resources. In one example, a system of computing devices may include programming interfaces (may), an operating system, software for configuring and / or controlling a virtualization environment, firmware, and similar resources. A system of computing devices may be referred to as a computing system.

[0106] In some cases, a computing system implementing exemplary method 1100 may host, among other things, a generator component 762, a merger component 764, and a promotion component 766 (Figure 7B) as software modules. The computing system may implement exemplary method 1100 by, for example, running one or more instances of the generator component 762, the merger component 764, and the promotion component 766. Thus, in response to execution, the generator component 762, the merger component 764, and the promotion component 766 may individually or in combination perform operations corresponding to blocks of exemplary method 1100, individually or in combination.

[0107] In block 1110, the computing system can generate copies of source program code corresponding to a service core that provides services common among single tenants. Such services may be referred to as common services. The service core includes a plurality of core modules that provide the services. The plurality of core modules have a set of extension points, individually or collectively. The set of extension points includes a first extension point corresponding to a first core module among the plurality of core modules.

[0108] In block 1120, the computing system may add at least one second extension point to the set of extension points in the copy of the source program code. The second extension point is specific to a defined tenant.

[0109] In block 1130, the computing system may apply automated tests to probe the integrity of a copy of the source program code having an added second extension point. Applying automated tests may include determining, based on control flow analysis, whether there are any changes to the control flow of the program code that form the copy of the source program code having at least one added second extension point. It should be noted that exemplary method 1100 is not limited to a single automated test. In fact, in some cases, the computing system may apply multiple automated tests, individually or in specific combinations, to probe the integrity of a modified copy of the source program code.

[0110] In some cases, the results of automated tests may be insufficient. In response, the computing system may implement one or more exception handling processes (not shown in Figure 11). In other cases, as illustrated in Figure 11, the results of one or more automated tests are sufficient. In response, the flow of exemplary method 1100 proceeds to block 1140, where the computing system can generate a next version of the multiple core modules based on the current version of the multiple core modules and a copy of the source program code having at least one added second extension point. The next version of the multiple core modules includes the added second extension point. In some embodiments, generating such a next version may include merging the current version of the multiple core modules and a copy of the source program code having at least one added second extension point. Such merging may include identifying the added second extension point in the copy of the source program and incorporating the second extension point into the current version of the multiple core modules. As described herein, in addition to the added second extension(s), other safeguard code may also be incorporated into the current versions of the core modules to ensure that the presence of the added second extension(s) does not alter the existing logic arising from the current versions of the core modules.

[0111] In block 1150, the computing system can build a second source program code corresponding to at least the next version of a plurality of core modules having at least one additional second extension point. For this purpose, in some embodiments, the computing system can include a compiler subsystem. In one example, the compiler subsystem can be embodied in compiler subsystem 796 (Figure 7B), or may include compiler subsystem 796 (Figure 7B). Building the second program code results in an executable package component. The executable package component includes a plurality of core modules, each having at least one additional second extension point and a core API defined by the service core. Thus, the executable package component corresponds to a service core with expanded extensibility. The executable package component provides a new service (or its functionality) that is common across single tenants in response to being executed. The new service has greater extensibility than the common service, taking into account the addition of at least one second extension point.

[0112] In block 1160, the computing system may apply a second automated test to probe the integrity of the operation of the executable package component. Applying the second automated test may include determining, based on control flow analysis, whether there have been any changes to control the flow of the executable package component to the service core prior to the addition of at least one second extension point. Again, the exemplary method 1100 is not limited to a single automated test, and in some cases, the computing system may apply multiple second automated tests, individually or in specific combinations, to probe the integrity of modified copies of the source program code.

[0113] Figure 12 is a flowchart of another exemplary method 1200 for upgrading the functionality of a service core according to one or more embodiments of the present disclosure. The service core may also be referred to as a common core or core platform. As described herein, the service core (e.g., service core 140) is common across single tenants. A computing device or a system of computing devices may implement exemplary method 1200 in whole or in part. For that purpose, each computing device of a computing device includes computing resources that can implement at least one of the blocks included in exemplary method 1200. Computing resources include, for example, a CPU, GPU, TPU, memory, disk space, incoming bandwidth and / or outgoing bandwidth, interfaces (I / O interfaces or APIs or both), controller devices (may be multiple), power supplies, combinations thereof, and / or similar resources. In one example, a system of computing devices may include programming interfaces (may be multiple), an operating system, software, firmware, and similar resources for configuring and / or controlling a virtualization environment. A system of computing devices may be referred to as a computing system.

[0114] In some cases, a computing system implementing Exemplary Method 1200 may host, among other things, the generator component 812, the test component 814, and the promotion component 816 (Figure 8) as software modules. The computing system may implement Exemplary Method 1200 by, for example, running one or more instances of the generator component 812, the test component 814, and the promotion component 816. Thus, in response to execution, the generator component 812, the test component 814, and the promotion component 816 may individually or in combination perform operations corresponding to blocks of Exemplary Method 1200, individually or in combination.

[0115] In block 1210, the computing system can generate a copy of the source program code corresponding to a service core that provides a service common to single tenants. As mentioned, that service may be called a common service. The generated copy may be called a fork, and the computing system may keep the fork in a forked codebase in a repository. The service core contains multiple core modules that provide a defined service. The source program code corresponds to the multiple core modules and encodes the defined functionality of the service.

[0116] In block 1220, the computing system can modify a copy of the source program code. The modified copy of the source program code updates the defined functionality of the service. Modifying a copy of the source program code may include adding program code that defines new functionality, revising existing program code that defines existing functionality, or removing existing functionality (which may be called deprecation). To modify a copy of the source program code, the computing system may receive input data that defines the program code and / or signaling that modifies the available program code (such as instructions for editing a fragment of program code). Additionally, the computing system may integrate the added program code and changes to the program code into the forked codebase. Thus, the computing system can evolve the forked codebase until one or more desired changes to the copy of the source program code are implemented.

[0117] In block 1230, the computing system may apply automated tests to probe the integrity of a modified copy of the source program code. Applying automated tests may include determining, based on control flow analysis, whether there are any changes to the control flow of the program code that make up the modified copy of the source program code. Note that the exemplary method 1200 is not limited to a single automated test, and in some cases, the computing system may apply multiple automated tests to probe the integrity of a modified copy of the source program code, individually or in specific combinations.

[0118] In some cases, the results of automated tests may be insufficient. In response, the computing system may implement one or more exception handling processes (not shown in Figure 12). In other cases, one or more results of automated tests are sufficient, as illustrated in Figure 12. In response, the flow of exemplary method 1200 proceeds to block 1240, where the computing system can generate a next version of the service core based on a modified copy of the source program code. The next version of the service core includes updated defined functionality and constitutes an upgrade in terms of functionality, rather than an extension point of the service core. The upgraded service core provides services according to the updated defined functionality. In some embodiments, generating a next version of the service core may include persisting the source program code corresponding to the next version of the service core as a core codebase and assigning a persistent unique identifier to the core base. The persistent unique identifier identifies the next version of the service core. In addition, or in some embodiments, generating the next version of the service core may include incorporating safeguard code into the modified copy of the source program code to ensure that existing logic arising from the current version (or otherwise previous version) of the service core remains unaltered by the updated defined functionality.

[0119] The upgraded service core continues to provide services common across single tenants, albeit according to updated defined functionality, allowing for the probe of operational integrity of the upgraded service core. Therefore, in block 1250, the computing system can build a second source program code corresponding to the next version of the service core. For this purpose, in some embodiments, the computing system can include a compiler subsystem. In one example, the compiler subsystem is embodied in compiler subsystem 796 (Figure 8) or can include compiler subsystem 796 (Figure 8). Building the second program code results in an executable package component (e.g., a container, an executable binary file, or similar). The executable package component can include multiple core modules that are built and, individually or in combination, provide updated defined functionality. The executable package component can also include an API.

[0120] In addition, in block 1260, the computing system may apply a second automated test to probe the integrity of the operation of the executable package components. Applying the second automated test may include determining, based on control flow analysis, whether there have been any changes to the control flow of the executable package components to the service core before the defined functionality of the service is updated. Again, the exemplary method 1200 is not limited to a single automated test, and in some cases, the computing system may apply multiple second automated tests to probe the integrity of the operation of the executable package components, individually or in specific combinations.

[0121] Figure 13 illustrates an example of a computing system 1300 that can implement an extensible SaaS platform providing customized services to each single tenant, according to aspects of this disclosure. The computing system 1300 includes an example of a plurality of compute server devices 1302 functionally coupled to one or more networks 1304, such as the Internet or any wired or wireless connection. More specifically, the exemplary computing system 1300 includes two types of server devices: compute server devices 1302 and storage server devices 1330. At least one subset of the compute server devices 1302 can operate according to the functionality described herein in relation to extensible tenant-specific services (such as clinical trials). At least a portion of the computing system 1300 can embody or include a build subsystem 510 (Figure 5). In addition, or in some embodiments, at least another portion of the computing system 1300 can embody or include a runtime subsystem 560 (Figure 5). Other parts of the computing system 1300 may embody or include the computing system 100 (Figure 1). Furthermore, or in yet another embodiment, the computing system 1300 may also include a JITX subsystem 760 (Figure 7B). Furthermore, or in yet another embodiment, the computing system 1300 may also include an upgrade subsystem 810 (Figure 8).

[0122] At least a subset of compute server devices 1302 can be functionally coupled to one or more storage server devices 1330. This coupling can be direct or mediated by at least one of the gateway devices 1320. The storage server devices 1330 include data and metadata that can be used to implement the functionality described herein in relation to extensible tenant-specific services (such as clinical trials). The storage server devices 1330 can embody at least one database server that can provide a database to each tenant-specific service. Each database holds service data for a particular tenant-specific service. This data is held according to a data model for that particular tenant-specific service. The storage server devices 1330 can include database server devices 590 (Figure 5). At least some of the storage server devices 1330 can embody data storage including one or more virtual partitions (tenant-specific VPs and / or base VPs). The combination of storage server devices 1330 can also embody their respective data storage, including the core codebase, executable package components, and other types of information. At least some of the storage server devices can embody the various data storage described herein. For example, at least some of the storage service devices can embody the data storage described herein in relation to the build subsystem 510 (Figure 6), the JITX subsystem 760 (Figure 7B), and the upgrade subsystem 810 (Figure 8).

[0123] Each gateway device of gateway device 1320 may include one or more processors functionally coupled to one or more memory devices, which can hold application programming interfaces and / or other types of program code for accessing compute server device 1302 and storage server device 1330. Such access may be programmatic, for example, through appropriate function calls.

[0124] Each compute server device 1302 may be a digital computer in terms of hardware architecture, including one or more processors 1308 (commonly referred to as processor 1308), one or more memory devices 1310 (commonly referred to as memory 1310), an input / output (I / O) interface 1312, and a network interface 1314. These components (1308, 1310, 1312, and 1314) are functionally coupled via a communication interface 1313. The communication interface 1313 may be implemented by or include one or more bus architectures or other wired or wireless connections. The bus architecture(s) may be implemented by or include one or more types of bus structures, including a memory bus or memory controller, a peripheral bus, an accelerated graphics port, and a processor bus or local bus using any of the various bus architectures. For example, such architectures could include ISA bus, MCA bus, EISA bus, VESA local bus, AGP bus, PCI bus, PCI-Express bus, PCMCIA bus, USB, or combinations thereof.

[0125] In addition, or in some embodiments, the communication interface 1313 may include additional elements omitted for simplification, such as controller devices (or multiple devices), buffer devices (or multiple devices) (e.g., caches), drivers, repeaters, transmitter devices (or multiple devices), and receiver devices (or multiple devices), for enabling communication. Furthermore, the communication interface 1313 may include address, control, and / or data connections for enabling appropriate communication between the aforementioned components.

[0126] The processor 1308 may be a hardware device comprising processing circuits capable of executing software, in particular software 1317 stored in one or more memory devices 1316 (referred to as memory 1316). In addition, or alternatively, the processing circuits may perform defined operations other than those defined by the software. The processor 1308 may be any custom-made or commercially available processor, a CPU, GPU, TPU, an auxiliary processor between several processors associated with a compute server device 1306, a semiconductor-based microprocessor (in the form of a microchip or chipset), or any device in general for executing software instructions or performing defined operations. For illustrative purposes, a processor may refer to a single-core processor, a single processor with software multithreading capability, a multi-core processor, a multi-core processor with software multithreading capability, a multi-core processor with hardware multithreading technology, a parallel processing (or computing) platform, and a parallel computing platform with distributed shared memory.

[0127] When the compute server device 1306 is operating, the processor 1308 may be configured to execute software 1317 stored in memory 1316 in order to communicate data with memory 1316, and to generally control the operation of the compute server device 1306 in accordance with the software 1317 and aspects of this disclosure.

[0128] The I / O interface 1312 can be used to receive input data from one or more devices or components and / or to provide system output to them. Input data can be provided, for example, via a keyboard, touchscreen display device, microphone, and / or mouse. System output can be provided, for example, via a touchscreen display device or another type of display device. The I / O interface 1312 may include, for example, a serial port, parallel port, Small Computer System Interface (SCSI), infrared (IR) interface, radio frequency (RF) interface, and / or Universal Serial Bus (USB) interface.

[0129] The network interface 1314 can be used to transmit and receive data, metadata, and / or signaling from one, some, or all of the compute server devices 1302 located outside of the compute server device 1306 on one or more of the networks 1304. The network interface 1314 can also be used to transmit and receive data, metadata, and / or signaling from other types of devices located outside of the compute server device 1306 on one or more of the networks 1304. The network interface 1314 may include, for example, a 10BaseT Ethernet adapter, a 100BaseT Ethernet adapter, a LAN PHY Ethernet adapter, a Token Ring adapter, a wireless network adapter (e.g., WiFi), or any other suitable network interface device. The network interface 1314 may include address, control, and / or data connections to enable appropriate communication on the network 1304.

[0130] Memory 1316 may include one or a combination of volatile memory elements (e.g., random access memory (RAM such as DRAM, SRAM, SDRAM, etc.)) and non-volatile memory elements (e.g., ROM, hard drive, tape, CD-ROM, DVD-ROM, etc.). Memory 1316 may also incorporate electronic, magnetic, optical, solid-state, and / or other types of storage media. In some embodiments, the compute server device 1306 may have access to one or more of the storage server devices 1330.

[0131] The software 1317 held in memory 1316 may include one or more software components. Each of these software components may include, for example, processor-accessible instructions encoded on the software component to implement a logical function according to an aspect of this disclosure. Processor-accessible instructions may include, for example, computer-readable and computer-executable program instructions. The software 1317 in memory 1316 of the compute server device 1306 may include one or more modules and components described herein. As illustrated in Figure 13, memory 1316 also includes an operating system 1319 (O / S 1319). O / S 1319 essentially controls the execution of other computer programs and provides functions such as scheduling, input / output control, file and data management, memory management, and communication control, as well as related services. The specific implementation of such an O / S may depend in part on the complexity of the architecture of the compute server device 1306. Exemplary operating systems may include Unix, Linux, and Windows operating systems.

[0132] Memory 1316 also holds functional information 1318 (e.g., data, metadata, or a combination of both) that, in combination with software 1317, can provide the functionality described herein in relation to the computing system 100 (Figure 1), and / or the build subsystem 510 (Figure 5) and runtime subsystem 560 (Figure 5). Thus, in some cases, software 1317 may include various components that form part of the build subsystem 510 (Figure 6), such as parse components 640, merge components 650, transform components 660, and build components 670. In addition, or in some embodiments, software 1317 may include components that form part of the JITX subsystem 760 (Figure 7), such as generator component 762, merger component 764, and promotion component 766. Furthermore, or in yet another embodiment, the software 1317 may include components that form part of the upgrade subsystem 810 (Figure 8), such as a generator component 812, a test component 814, and a promotion component 816. Various functionalities provided by the software can be provided in response to being performed by the processor 1308.

[0133] Application programs and other executable program components, such as OS 1319, are illustrated herein as separate blocks, but it is recognized that such programs and components may reside at different times in different storage components of the compute server device 1306. Implementations of the software 1315 can be stored in or transmitted through any form of computer-readable storage medium. At least a subset of compute server nodes 1302 may run one or more instances of the software 1315 by processors 1308 present in each of the compute server nodes 1302, for example, to provide various functionalities described herein in one or more embodiments of this disclosure.

[0134] The computing system 1300 may also include one or more client devices 1340. Each client device 1340 may access at least some of the functionalities described herein by a gateway among the gateways 1320 and by a software application (such as a client application) hosted on each client device 1340. Each client device is a computing device illustrated with reference to client device 1346 and having the general structure described below.

[0135] The client device 1346 may include one or more memory devices 1356 (referred to as memory 1346). Memory 1346 may have processor-accessible instructions encoded on memory 1346. Processor-accessible instructions may include, for example, computer-readable and computer-executable program instructions.

[0136] The client device 1346 may also include one or more input / output (I / O) interfaces 1352 and a network interface 1354. The communication interface 1353 can functionally connect two or more of those functional elements of the client device 1346. The communication interface 1353 may include one or more of several types of bus architectures, including a memory bus or memory controller, a peripheral bus, an accelerated graphics port, and a processor bus or local bus using any of the various bus architectures. For example, such architectures may include ISA bus, MCA bus, EISA bus, VESA local bus, AGP bus, and PCI, PCI-Express bus, PCMCIA bus, USB bus, etc.

[0137] The functionality of the client device 1346 may consist of computer executable instructions (e.g., program instructions or program modules) that can be executed by at least one of the one or more processors 1348. A subset of computer executable instructions can embody a software application, such as a client application or another type of software application (e.g., an IDE). Such a subset may be arranged into a group of software components. The software components of the group of software components may include computer code, routines, objects, components, data structures (e.g., metadata objects, data objects, control objects), and combinations thereof, which may be configured (e.g., programmed) to perform a specific action or implement a specific abstract data type in response to execution by at least one processor.

[0138] Accordingly, the software application can be built (e.g., linked and compiled) and stored in memory 1355 or another type of machine-accessible non-temporary storage medium in a processor-executable form. The processor-executable form of the software application can, for example, make the client device 1346 a specific machine for configuring or otherwise customizing tenant-specific services, such as those described herein, particularly for functional purposes. The group of built software components constituting the processor-executable version of the software application can be accessed individually or in specific combinations and can be executed by at least one of the processors 1348. In response to execution, the software application can provide the functionality described herein in relation to configuring or otherwise customizing tenant-specific services. Thus, the execution of the group of built software components stored in memory 1356 can cause the client device 1346 to operate according to the embodiments described herein.

[0139] Data and processor-accessible instructions associated with a specific functionality of the client device 1346 can be stored in memory 1356 within the functionality information 1358. In one embodiment, the processor-accessible instructions can embody any number of components (such as program instructions and / or program modules) that provide a specific functionality in response to execution by at least one of the processors 1348. In this specification and the accompanying drawings, memory elements are illustrated as separate blocks, but such memory elements and associated processor-accessible instructions and data may reside in different storage elements (such as registers, files, and memory addresses, not shown) within memory 1356 at different times.

[0140] Functional information 1358 may include a variety of data, metadata, or both, associated with the configuration or otherwise customization of tenant-specific services, as described herein.

[0141] Memory 1356 can be embodied in a variety of computer-readable media. Examples of computer-readable media include any available media accessible by a processor (such as one of the processors 1348) within a computing device, including, for example, volatile media, non-volatile media, removable media, non-removable media, or any combination thereof. As an example, computer-readable media may include “computer storage media,” or “computer-readable storage media” and “communication media.” Such storage media may be non-temporary storage media. “Computer storage media” includes volatile and non-volatile, removable and non-removable media implemented in any way or technique for storing information such as computer-readable instructions, data structures, program modules, or other data. Exemplary computer storage media include, but are not limited to, RAM, ROM, EEPROM, flash memory, or other memory technologies, CD-ROM, DVD, or other optical storage, magnetic cassette, magnetic tape, magnetic disk storage device, or other magnetic storage device, or any other medium that can be used to store desired information and can be accessed by a computer or a processor located in or functionally coupled to a computer.

[0142] The memory 1356 may include a computer-readable non-temporary storage medium in the form of volatile memory such as RAM or EEPROM, or in the form of non-volatile memory such as ROM. In one embodiment, the memory 1356 may be divided into system memory (not shown) which may include data and / or program modules that enable the essential operation and control of the computing device 1346. Such program modules may be implemented (e.g., compiled and stored) in a memory element 1359 (referred to as the operating system 1359), while such data may be system data (not shown in Figure 13) held in system data storage. The operating system 1359 and the system data storage may be immediately accessible and / or currently operable by at least one of the processors 1348. The operating system 1359 embodies an operating system for the client device 1346. The specific implementation of such an O / S may depend in part on the complexity of the architecture of the client device 1346. Higher complexity allows for a higher level of O / S. Exemplary operating systems may include iOS, Android, and Windows operating systems.

[0143] Memory 1356 may include removable / non-removable, volatile / non-volatile computer-readable non-temporary storage media. For example, memory 1356 may include a mass storage unit (not shown) capable of providing non-volatile storage of computer code, computer-readable instructions, data structures, program modules, and other data for client device 1346. Specific implementations of such a mass storage unit (not shown) may depend on the desired form factor and space available for integration into client device 1346. For a suitable form factor and size of client device 1346, the mass storage unit (not shown) may be a hard disk, removable magnetic disk, removable optical disk, magnetic cassette or other magnetic storage device, flash memory card, CD-ROM, digital versatile disk (DVD) or other optical storage, random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), etc.

[0144] Generally, one or more processors 1348 can refer to any computing unit or processing device, including single-core processors, single-core processors with software multithreading capability, multi-core processors, multi-core processors with software multithreading capability, multi-core processors with hardware multithreading technology, parallel platforms, and parallel platforms with distributed shared memory (e.g., cache). In addition, or alternatively, a group of one or more processors 1348 can refer to an integrated circuit with a specific functionality, such as an ASIC, DSP, FPGA, CPLD, discrete gate or transistor logic, discrete hardware component, or any combination thereof designed to perform the functions described herein. In one embodiment, the processors referred to herein can leverage nanoscale architectures such as molecular and quantum dot transistors, switches, and gates to optimize the use of space in a computing device that can implement various embodiments of this disclosure (e.g., improve the form factor) or to enhance performance. In another embodiment, one or more processors 1348 can be implemented as a combination of computing units.

[0145] The client device may include, or be functionally coupled to, a display device (not shown in Figure 13) that can display various user interfaces in relation to the configuration or other customization of tenant-specific services, at least in part, provided by the software application included in software 1355.

[0146] One or more I / O interfaces 1352 can functionally couple (e.g., communicatively couple) the client device 1346 to another functional element (component, unit, server, gateway node, repository, device, or similar). The functionality of the client device 1346 associated with data I / O or signaling I / O can be performed in response to the execution of at least one I / O interface that can be held in memory 1356 by a processor(s) 1348. In some embodiments, at least one I / O interface embodies an API that enables the exchange of data or signaling, or both, through the I / O interface. In some embodiments, one or more I / O interfaces 1352 may include at least one port that can enable the client device 1346 to connect to another device or functional element. In one or more scenarios, at least one port may include one or more of the following: parallel ports (e.g., GPIB, IEEE-1284), serial ports (e.g., RS-232, Universal Serial Bus (USB), FireWire, or IEEE-1394), Ethernet ports, V.35 ports, Small Computer System Interface (SCSI) ports, etc.

[0147] At least one of the one or more I / O interfaces 1352 can enable the delivery of outputs (e.g., output data or output signaling, or both) to such devices or functional elements. Such outputs may represent the results of specific operations or one or more operations described herein, such as operations performed in the exemplary manner described herein.

[0148] Although not shown in Figure 13, the client device 1346 may include a battery that can power components or functional elements within the client device 1346. The battery may be rechargeable and can be formed by stacking active elements (e.g., cathode, anode, separator material, and electrolyte) or by winding a multilayer roll of such elements. In addition to the battery, the client device 1346 may include one or more transformers (not shown) and / or other circuits (not shown) to achieve a power level suitable for the operation of the client device 1346 and the components, functional elements, and associated circuits within the client device 1346.

[0149] To provide additional context, the computer implementations and systems of this disclosure can be implemented on the computing system 1400 illustrated in Figure 14 and described below. Similarly, the computer implementations and systems disclosed herein can utilize one or more computing devices to perform one or more functions at one or more locations. Figure 14 is a block diagram illustrating an example of a computing system 1400 for performing the disclosed methods and / or implementing the disclosed systems. The computing system 1400 shown in Figure 14 is merely an example of an operating environment and is not intended to imply any limitation on the scope of use or functionality of the operating environment architecture. Nor should the operating environment be construed as having any dependencies or requirements relating to any one or combination of components of the components illustrated in the exemplary operating environment.

[0150] The computer implementations and systems described herein can operate in a number of other general-purpose or dedicated computing system environments or configurations. Examples of well-known computing systems, environments, and / or configurations that may be suitable for use with the systems and methods include, but are not limited to, personal computers, server computers, laptop devices, and multiprocessor systems. Additional examples include set-top boxes, programmable consumer electronics, network PCs, minicomputers, mainframe computers, and distributed computing environments that include any of the systems or devices described above.

[0151] The computer implementations and systems disclosed may be executed by software components. The disclosed systems and computer implementations may be described in a general context in which computer executable instructions are executed by one or more computers or other processing devices. Generally, program modules may include program code, routines, objects, components, data structures, etc., that perform a specific task or implement a specific abstract data type. The disclosed computer implementations may also be implemented in a grid-based distributed computing system in which tasks are executed by remote computing devices linked through a communication network. In a distributed computing system, program modules may reside in both local computer storage media, including memory storage devices, and remote computer storage media.

[0152] Furthermore, the systems and computer implementation methods disclosed herein can be implemented via a general-purpose computing device in the form of a computing device 1401. The components of the computing device 1401 may include one or more processors 1403, a system memory 1412, and a system bus 1413 that functionally connects various system components, including one or more processors 1403, to the system memory 1412. In some cases, the system can utilize parallel computing.

[0153] The system bus 1413 represents one or more of several possible types of bus structures, including a memory bus or memory controller, peripheral bus, accelerated graphics port, or local bus, using any of a variety of bus architectures. The system bus 1413, and all buses specified herein, can be implemented via wired or wireless network connections, and each subsystem, including one or more processors 1403, one or more mass storage devices 1404 (referred to as mass storage 1404), an operating system 1405, software 1406, data 1407, a network adapter 1408, system memory 1412, input / output interface 1410, a display adapter 1409, a display device 1411, and a human-machine interface 1402, may be contained within one or more remote computing devices 1414a, b, c, which are physically separated locations, connected through this form of bus, and effectively implement a fully distributed system.

[0154] The computing device 1401 typically comprises a variety of computer-readable media. Examples of readable media may be any available media accessible by the computing device 1401, and may include, for example, both volatile and non-volatile media, removable and non-removable media. The system memory 1412 includes computer-readable media in the form of volatile memory, such as random access memory (RAM), and / or non-volatile memory, such as read-only memory (ROM). The system memory 1412 typically includes data, such as data 1407, and / or program modules, such as the operating system 1405 and software 1406, and software that is immediately accessible and / or currently being operated by one or more processors 1403.

[0155] The computing device 1401 may also be equipped with other removable / non-removable, volatile / non-volatile computer storage media. As an example, Figure 14 illustrates a mass storage 1404 that can provide non-volatile storage for computer code, computer-readable instructions, data structures, program modules, and other data for the computing device 1401. For example, the mass storage 1404 can be embodied in, or may include, a hard disk, removable magnetic disk, removable optical disk, magnetic cassette or other magnetic storage device, flash memory card, CD-ROM, digital versatile disk (DVD) or other optical storage, random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), etc.

[0156] Optionally, any number of program modules, including, for example, operating system 1405 and software 1406, can be stored in the mass storage 1404. Each of operating system 1405 and software 1406 (or several combinations thereof) may include elements of programming and software 1406. Data 1407 can also be stored in the mass storage 1404. Data 1407 can be stored in one or more databases. Examples of such databases include DB2®, Microsoft® Access, Microsoft® SQL Server, Oracle®, MySQL, PostgreSQL, etc. Databases can be centralized or distributed across multiple systems. In some cases, computing device 1401 can host one or more of the various subsystems described herein. For example, in some cases, computing device 1401 can host the JITX subsystem 760 (Figure 7B), and software 1406 may include components that form the JITX subsystem 760. In addition, or otherwise, the computing device 1401 may host a build subsystem 510, and the software 1406 may include components that form the build subsystem 510. Furthermore, or still otherwise, the computing device 1401 may host an upgrade subsystem 810 (Figure 8), and the software 1406 may include components that form the upgrade subsystem 810. The execution of the software 1406 by the processor(s) 1403 may cause the computing device 1401 to provide at least some of the functionalities described herein in relation to extending the functionality and / or extensions of the core platform, and / or building code modules and extension modules, and creating executable package components.

[0157] In some configurations, one or more of the subsystems described herein can be hosted in a distributed manner. Thus, software 1406 can be replicated among such computing devices. In other configurations, some components of software 1406 can be localized to a specific computing device among the computing devices, and other components of software 1406 can be localized to a second specific computing device among the computing devices. In such a distributed embodiment, the computing system can embody or configure the query resolution subsystem 1414. In such embodiments, the execution of software 1406 by at least one processor present in a combination of computing device 1401 and remote computing devices 1414a, b, c can cause such a computing system to provide at least some of the functionalities described herein in relation to extending the functionality and / or extensions of the core platform, and / or building code modules and extension modules, and creating executable package components, as described herein.

[0158] In another embodiment, an end user may input commands and data to the computing device 1401 via an input device (not shown). Examples of such input devices include, but are not limited to, a keyboard, a pointing device (e.g., a “mouse”), a microphone, a joystick, a scanner, a glove, and other tactile input devices such as other body covers. These and other input devices may be connected to one or more processors 1403 via a human-machine interface 1402 coupled to a system bus 1413, or they may be connected by other interfaces and bus structures such as a parallel port, a game port, an IEEE 1394 port (also known as a Firewire port), a serial port, or a Universal Serial Bus (USB).

[0159] In another embodiment, the display device 1411 may also be connected to the system bus 1413 via an interface such as a display adapter 1409. In some configurations, the computing device 1401 may have two or more display adapters 1409, and the computing device 1401 may have two or more display devices 1411. For example, the display device 1411 may be a monitor, an LCD (liquid crystal display), or a projector. In addition to the display device 1411, other output peripheral devices may include components such as a speaker (not shown) and a printer (not shown) that can be connected to the computing device 1401 via an input / output interface 1410. Any operation and / or results of this method may be output to an output device in any form. Such output may be any form of visual representation, including but not limited to text, graphics, animations, audio, and haptics. Thus, the display device 1411 may present various user interfaces and other information (data, metadata, and / or configuration attributes) related to tenant-specific services. For example, a display device can present a user interface, particularly the UI shown in Figures 4A and 4B. The display device 1411 and the computing device 1401 may be part of a single device or separate devices.

[0160] The computing device 1401 can operate in a network environment using logical connections to one or more remote computing devices 1414a, b, c and / or one or more storage server devices 1420. For example, the remote computing devices may be personal computers, portable computers, smartphones, servers, routers, network computers, peer devices, or other common network nodes. In some cases, one or more storage server devices 1420 can embody or constitute a storage server device 1330 (Figure 13). The logical connections between the computing device 1401 and the remote computing devices 1414a, b, c and the server storage devices among the server storage devices 1420 may be made via a network 1415, such as a local area network (LAN) and / or a general wide area network (WAN). Such network connections may be made through a network adapter 1408. The network adapter 1408 can be implemented in both wired and wireless environments.

[0161] For illustrative purposes, application programs and other executable program components, such as the operating system 1405, are illustrated herein as separate blocks, but such programs and components are recognized to reside at different times in different storage components of the computing device 1401 and to be executed by one or more processors 1403 of the computer. Implementations of the software 1406 can be stored in or transmitted through any form of computer-readable medium. Any of the disclosed methods can be executed by computer-readable instructions embodied on the computer-readable medium. The computer-readable medium can be any available medium accessible by the computer. As described herein, “computer storage medium” includes volatile and non-volatile, removable and non-removable media implemented in any way or technique for storing information such as computer-readable instructions, data structures, program modules, or other data.

[0162] Many other embodiments arise from the above detailed description and the accompanying drawings. Embodiment 1 of those embodiments includes a computing system including at least one processor running a computer executable component stored in at least one memory device, the computer executable component comprising a plurality of core modules configured to provide defined services, the plurality of core modules including at least one extension point corresponding to a first core module of the plurality of core modules, the first extension point of the at least one extension point being mapped to a tenant-specific extension module that customizes the defined services. The computer executable component also includes an application programming interface API corresponding to a defined tenant and a data model corresponding to a defined tenant.

[0163] Many embodiments of Example 2 include the computing system described in Example 1, wherein the computer executable component further comprises an API router component configured to receive messages that include attributes that invoke function calls to a customized defined service and identify a defined tenant, the API router component redirects the function calls to the customized defined service based on the attributes, and the API component exposes the API.

[0164] Many embodiments of Example 3 include the computing system described in Example 1, wherein a first core module is configured to provide at least one first element to the data model, and a second core module among a plurality of core modules is configured to provide at least one second element to the data model.

[0165] Many embodiments of Example 4 include the computing system described in Example 1, wherein a first core module is configured to provide at least one first function to the API, and a second core module among a plurality of core modules is configured to provide at least one second function to the API.

[0166] Many embodiments of Example 5 include the computing system described in Example 1, wherein the first core module is configured to modify at least one of the existing data models or existing APIs to bring about at least one of the APIs or at least one of the data models.

[0167] Many embodiments of Example 6 include the computing system described in Example 1, wherein a tenant-specific extension module is configured to provide at least one element to the data model, or to provide functionality to the API, or to provide at least one element to the data model and functionality to the API.

[0168] Many embodiments of Example 7 include the computing system described in Example 1, wherein a tenant-specific extension module is configured to store multiple core functions that constitute an API, and further to store multiple core elements that constitute a data model.

[0169] Many embodiments, including Example 8, include the computing system described in Example 1, in which a tenant-specific extension module is configured to remove a specific core function from among several core functions that constitute the API and to preserve several core elements that constitute the data model.

[0170] Many embodiments, including Example 9, include the computing system described in Example 1, in which tenant-specific extension modules are configured to store multiple core functions that constitute an API and to remove specific core elements from multiple core elements that constitute a data model.

[0171] Many embodiments include the computing system described in Embodiment 1, further comprising at least one second memory device storing a non-temporary storage structure dedicated to a defined tenant, wherein the non-temporary storage structure comprises one or more of the following: configuration attributes, program code defining extension logic, or a plurality of tenant-specific extension modules.

[0172] Many embodiments, including Example 11, include the computing system described in Example 10, wherein the non-temporary storage structure includes one of a file system, file folders, database, or table.

[0173] Many embodiments include Example 12, which includes the computing system described in Example 10, in which each tenant-specific extension module of a plurality of tenant-specific modules stores core elements that constitute a data model and further stores a plurality of core functions that constitute an API.

[0174] Many embodiments of Example 13 include the computing system described in Example 10, wherein a selected tenant-specific module among several tenant-specific modules causes a breaking modification to one or more of the core APIs corresponding to defined services or the core data model corresponding to data models, resulting in a breakdown of backward compatibility between the customized defined services and the defined services.

[0175] Many embodiments, including Example 14, include the computing system of Example 10, wherein the non-temporary storage structure further includes definition data that identifies tenant-specific services, configuration data corresponding to tenant-specific services, and metadata corresponding to tenant-specific services.

[0176] Many embodiments include an example 15 of the computing system described in Example 10, wherein the non-temporary memory structure further includes definition data that identifies an extension point, the definition data including first data that identifies the domain of the extension point, second data that identifies the functionality corresponding to the extension point, and a description of the extension point that identifies one or more methods corresponding to the extension point, input parameters of the extension point, and output types corresponding to the extension point.

[0177] Many embodiments include an example 16 of the computing system described in Example 10, in which the non-temporary storage structure further includes abstraction data that defines human-readable content that exhibits a manner of extending tenant-specific services, and the human-readable content is either free of program code or contains snippets of custom program code.

[0178] Many embodiments include an example 17 of the computing system described in Example 10, wherein at least one second memory device further stores a second non-temporary storage structure associated with one or more tenants, the second non-temporary storage structure includes one or more of the following: a second configuration attribute, a second program code defining extension logic, or a plurality of extension modules.

[0179] Many embodiments include the computing system described in Embodiment 17, wherein the non-temporary memory structure and the second non-temporary memory structure are logically configured in a hierarchical structure.

[0180] Many embodiments include the computing system described in Embodiment 19, which includes the computing system described in Embodiment 18, wherein the hierarchical structure includes a graph having a first node representing a non-temporary memory structure and a second node representing a second non-temporary memory structure.

[0181] Many embodiments, including Example 20, include the computing system described in Example 18, wherein the hierarchical structure includes a tree structure, where a first node representing a non-temporary memory structure is the root node, and a second node representing a second non-temporary memory structure is the leaf node.

[0182] Many embodiments, such as Example 21, include the computing system described in Example 10, wherein at least one memory device includes a permission attribute configured to grant a defined tenant exclusive access to a customized, defined service.

[0183] One embodiment 22 of many embodiments is a computer implementation method which includes generating copies of source program code corresponding to a plurality of core modules that provide defined services, wherein the plurality of core modules include at least one first extension point corresponding to a first core module among the plurality of core modules. The computer implementation method also includes adding at least one second extension point to at least one first extension point in the copy of source program code, wherein the at least one second extension point is specific to a defined tenant.

[0184] Many embodiments include the computer implementation method described in Embodiment 22, further comprising applying an automated test to probe the integrity of a copy of source program code having at least one additional second extension point.

[0185] Many embodiments include an example 24 of the computer implementation method described in Example 23, which includes applying an automated test to determine, based on control flow analysis, whether there are any changes to the control flow of the program code that form a copy of the source program code having at least one additional second extension point.

[0186] Example 25 of many embodiments includes the computer implementation method described in Example 22, further comprising generating a next version of the multiple core modules based on the current version of the multiple core modules and a copy of the source program code having at least one additional second extension point.

[0187] Many embodiments include an example 26 of the computer implementation method described in Example 25, wherein generating a next version of the multiple core modules involves integrating at least one added second extension point into the current version of the multiple core modules.

[0188] Many embodiments include the computer implementation method described in Embodiment 25, which further includes building a second program code corresponding to at least a subsequent version of a plurality of core modules having at least one additional second extension point, and yielding an executable package component comprising the plurality of core modules including the additional at least one second extension point.

[0189] Many embodiments include the computer implementation method described in Embodiment 27, further comprising applying automated tests to probe the integrity of the executable package components.

[0190] One embodiment 29 of many embodiments includes a computing system comprising one or more processors and one or more memory devices storing computer executable instructions, which, in response to execution by one or more processors, cause the computing system to generate copies of source program code corresponding to a plurality of core modules that provide defined services, each copy including at least one first extension point corresponding to a first core module among the plurality of core modules, and cause the computing system to add at least one second extension point specific to a defined tenant to at least one first extension point in the copy of source program code.

[0191] Many embodiments include the computing system described in Embodiment 29, wherein one or more memory devices store additional computer-executable instructions, which, in response to further execution by one or more processors, cause the computing system to further apply automated tests to probe the integrity of a copy of source program code having at least one additional second extension point.

[0192] Many embodiments include the computing system described in Embodiment 29, wherein the application of automated testing includes determining, based on control flow analysis, whether there are any changes to the control flow of the program code that form a copy of the source program code having at least one additional second extension point.

[0193] Many embodiments include the computing system described in Embodiment 29, wherein one or more memory devices store further computer-executable instructions that cause the computing system to generate a next version of the multiple core modules based on the current version of the multiple core modules and a copy of the source program code having at least one additional second extension point.

[0194] Many embodiments include the computing system described in Embodiment 29, wherein one or more memory devices store further computer executable instructions that cause the computing system to build a second program code corresponding to at least subsequent versions of a plurality of core modules having at least one additional second extension point, in response to further execution by one or more processors, resulting in an executable package component comprising a plurality of core modules including the additional at least one second extension point.

[0195] Many embodiments, including Example 34, include the computing system described in Example 29, wherein one or more memory devices store further computer executable instructions that cause the computing system to further apply automated tests to probe the integrity of executable package components in response to further execution by one or more processors.

[0196] One embodiment 35 of many embodiments includes at least one non-temporary computer-readable storage medium having encoded processor-executable instructions that causes an operation to be performed on one or more computing devices in response to execution, which includes generating copies of source program code corresponding to a plurality of core modules that provide defined services, wherein the plurality of core modules include at least one first extension point corresponding to a first core module among the plurality of core modules, and adding at least one second extension point to at least one first extension point in the copy of source program code, wherein the at least one second extension point is specific to a defined tenant.

[0197] Many embodiments include at least one non-temporary computer-readable storage medium as in Embodiment 35, the operation further includes applying an automated test to probe the integrity of a copy of source program code having at least one additional second extension point.

[0198] Many embodiments include at least one non-temporary computer-readable storage medium as in Embodiment 36, wherein the application of an automated test includes determining, based on control flow analysis, whether there are any changes to the control flow of the program code that form a copy of the source program code having at least one additional second extension point.

[0199] Many embodiments include at least one non-temporary computer-readable storage medium as in Embodiment 35, further comprising generating a next version of the multiple core modules based on the current version of the multiple core modules and a copy of the source program code having at least one additional second extension point.

[0200] Many embodiments include an example 39 of which includes at least one non-temporary computer-readable storage medium as described in Example 38, wherein generating a next version of the multiple core modules involves integrating at least one added second extension point into the current version of the multiple core modules.

[0201] Many embodiments include at least one non-temporary computer-readable storage medium as described in Embodiment 38, the operation further includes building a second program code corresponding to at least a subsequent version of a plurality of core modules having at least one added second extension point, and yielding an executable package component comprising the plurality of core modules including the added at least one second extension point.

[0202] Many embodiments include at least one non-temporary computer-readable storage medium as described in Embodiment 40, the operation further includes applying an automated test to probe the integrity of the executable package components.

[0203] 42 of many embodiments is a computer implementation method which includes identifying a group of one or more references to each of the first virtual partitions, wherein the group of one or more references defines a graph representing the logical organization of each of the first virtual partitions, and the graph includes a first node representing a first first virtual partition of each of the first virtual partitions, and a second node representing a second first virtual partition of each of the first virtual partitions. The computer implementation method also includes determining that the group of one or more references satisfies a consistency criterion. The computer implementation method further includes generating a second virtual partition by flattening the graph, wherein the second virtual partition includes one or more computer-readable components present in each of the first virtual partitions. Flattening includes applying one or more primitives present in at least one of the first virtual partitions in the order of the graph. The computer implementation method still further includes generating one or more computer-executable components based on one or more computer-readable components.

[0204] Many embodiments include the computer implementation method described in Embodiment 42, further comprising generating an executable package component by combining one or more computer-readable components with a second computer-executable component corresponding to a group of core modules.

[0205] Many embodiments of the computer implementation include the computer implementation method described in Embodiment 42, further comprising holding one or more computer executable components in a data repository, wherein the one or more computer executable components include at least one tenant-specific extension module.

[0206] Many embodiments include an example 45 which includes the computer implementation method described in Example 42, wherein one or more computer-readable components include abstract data that defines human-readable content that defines a manner in which tenant-specific services are extended, and the human-readable content either contains no program code or contains snippets of program code.

[0207] Many embodiments of the computer implementation method, Example 46, include generating one or more computer executable components based on one or more computer-readable components, which includes translating human-readable content into at least one program code artifact, and using at least one program code artifact to build at least one specific computer executable component from among the one or more computer executable components, as described in Example 45.

[0208] Many embodiments include an example 47 of the computer implementation method described in Example 42, which includes generating one or more computer executable components based on one or more computer-readable components, accessing abstraction data from a second virtual partition, accessing code templates, and generating a first computer executable component from one or more computer executable components based on the abstraction data and code templates.

[0209] Many embodiments, including Example 48, include the computer implementation method described in Example 44, in which a second virtual partition forms part of a data repository, and each first virtual partition forms part of the second data repository.

[0210] Many embodiments, including Example 49, include the computer implementation method described in Example 42, wherein the first reference in the group of references includes a unique location identifier indicating the location of a particular virtual partition among the respective first virtual partitions in a computer network, and further includes data identifying a version of the particular virtual partition.

[0211] Many embodiments include the computer implementation method described in Embodiment 49, wherein the unique location identifier includes a uniform resource locator (URL), and the version corresponds to a persistent unique identifier that indicates immutable content forming a particular virtual partition at a defined time.

[0212] Many embodiments include the computer implementation method described in Embodiment 42, which includes flattening to generate a copy of each component asset in each first virtual partition and to retain each copy in a second virtual partition in the order of the graph.

[0213] Many embodiments include the computer implementation method described in Embodiment 51, further comprising determining that a conflict exists between a first copy of each copy and a second copy of each copy, and determining a solution to the conflict by applying one or more policy-based defined processes.

[0214] Many embodiments include a computer implementation method as described in Embodiment 51, further comprising: determining that a conflict exists between a first copy of each copy and a second copy of each copy; sending a report indicating the conflict (e.g., to a computing device or component); receiving resolution data defining a solution to the conflict (e.g., from the computing device or component); and resolving the conflict by applying the solution.

[0215] Embodiment 54 of many embodiments includes a computing system comprising one or more processors and one or more memory devices, wherein the one or more memory devices store computer executable instructions that, in response to execution by the one or more processors, cause the computing system to identify one or more groups of references to each of the first virtual partitions, which define a graph representing the logical organization of each of the first virtual partitions, wherein the graph includes a first node representing a first first virtual partition of each of the first virtual partitions, and a second node representing a second first virtual partition of each of the first virtual partitions, and cause the computing system to determine that one or more groups of references satisfy a consistency criterion, and flatten the graph to generate a second virtual partition containing one or more computer-readable components present in each of the first virtual partitions, wherein flattening includes applying one or more primitives present in at least one of the first virtual partitions in the order of the graph, and causing one or more computer-executable components to be generated based on one or more computer-readable components.

[0216] Many embodiments include the computing system described in Embodiment 55, in which one or more memory devices store further computer-executable instructions that cause the computing system to generate further executable package components by combining one or more computer-readable components with a second computer-executable component corresponding to a group of core modules, in response to further execution by one or more processors.

[0217] Many embodiments of the system include the computing system described in Embodiment 54, wherein one or more memory devices store further computer executable instructions that cause the computing system to hold one or more computer executable components, including at least one tenant-specific expansion module, in a data repository in response to further execution by one or more processors.

[0218] Many embodiments include an example 57 of the computing system described in Example 54, in which one or more computer-readable components include abstract data that defines human-readable content that defines a manner in which tenant-specific services are extended, and the human-readable content either contains no program code or contains snippets of program code.

[0219] Many embodiments include an example 58 of the computing system described in Example 57, which generates one or more computer executable components based on one or more computer-readable components, which includes translating human-readable content into at least one program code artifact, and using at least one program code artifact to build at least one specific computer executable component from among the one or more computer executable components.

[0220] Many embodiments of Example 59 include the computing system described in Example 54, which includes generating one or more computer executable components based on one or more computer-readable components, accessing abstraction data from a second virtual partition, accessing code templates, and generating a first computer executable component from one or more computer executable components based on the abstraction data and code templates.

[0221] Many embodiments, including Example 60, include the computing system described in Example 56, in which a second virtual partition forms part of a data repository, and each first virtual partition forms part of the second data repository.

[0222] Many embodiments include the computing system described in Embodiment 54, which further includes flattening to generate a copy of each component asset in each first virtual partition and to retain each copy in a second virtual partition in the order of the graph.

[0223] Many embodiments include the computing system described in Embodiment 62, which further includes determining whether a conflict exists between a first copy of each copy and a second copy of each copy, and determining a solution to the conflict by applying one or more policy-based defined processes.

[0224] Many embodiments include an example 63 of the computing system described in Example 61, further comprising: determining that a conflict exists between a first copy of each copy and a second copy of each copy; sending a report indicating the conflict (e.g., to a computing device or component); receiving resolution data defining a solution to the conflict (e.g., from the computing device or component); and resolving the conflict by applying the solution.

[0225] Embodiment 64 of many embodiments includes at least one non-temporary computer-readable storage medium having encoded processor-executable instructions, which, in response to execution, causes a computing system to identify one or more groups of references to each of the first virtual partitions, defining a graph representing the logical organization of each of the first virtual partitions, wherein the graph includes a first node representing a first first virtual partition of each of the first virtual partitions, and a second node representing a second first virtual partition of each of the first virtual partitions, and causes the system to determine that one or more groups of references satisfy a consistency criterion, and then flatten the graph to generate a second virtual partition containing one or more computer-readable components present in each of the first virtual partitions, wherein flattening includes applying one or more primitives present in at least one of the first virtual partitions in the order of the graph, and causing the system to generate one or more computer-executable components based on one or more computer-readable components.

[0226] Many embodiments include an example 65 which includes at least one non-temporary computer-readable storage medium as in Example 64, wherein a processor-executable instruction causes the computing system to further generate executable package components by combining one or more computer-readable components with a second computer-executable component corresponding to a group of core modules, in response to further execution.

[0227] In many embodiments, Example 66 involves a processor executable instruction causing the computing system to further retain one or more computer executable components in a data repository in response to further execution, and the one or more computer executable components include at least one non-temporary computer-readable storage medium as in Example 64, which includes at least one tenant-specific extension module.

[0228] Many embodiments include an example 67 in which one or more computer-readable components include abstract data that defines human-readable content that defines a manner in which tenant-specific services are extended, and includes at least one non-temporary computer-readable storage medium as in Example 64 in which the human-readable content is either free of program code or contains snippets of program code.

[0229] Many embodiments include an example 68 of the computer-readable medium described in Example 67, which includes generating one or more computer-executable components based on one or more computer-readable components, converting human-readable content into at least one program code artifact, and using at least one program code artifact to build at least one specific computer-executable component from among the one or more computer-executable components.

[0230] Many embodiments, including Example 69, include at least one non-temporary computer-readable storage medium as described in Example 64, which includes generating one or more computer-executable components based on one or more computer-readable components, accessing abstraction data from a second virtual partition, accessing code templates, and generating a first computer-executable component among one or more computer-executable components based on the abstraction data and code templates.

[0231] Many embodiments, such as Example 70, include at least one non-temporary computer-readable storage medium as described in Example 66, wherein a second virtual partition forms part of a data repository, and each first virtual partition forms part of the second data repository.

[0232] Many embodiments include an example 71 of the same embodiment which includes at least one non-temporary computer-readable storage medium as in Example 64, wherein the first reference in the group of references includes a unique location identifier indicating the location of a particular virtual partition among the respective first virtual partitions in a computer network, and further includes data identifying a version of the particular virtual partition.

[0233] Many embodiments, such as Example 72, include at least one non-temporary computer-readable storage medium as described in Example 71, wherein the unique location identifier includes a uniform resource locator (URL), and the version corresponds to a persistent unique identifier indicating immutable content that forms a particular virtual partition at a defined time.

[0234] Many embodiments include an example 73 of the embodiment which includes flattening to generate a copy of each component asset in each first virtual partition and to hold each copy in a second virtual partition in the order of the graph, and at least one non-temporary computer-readable storage medium as described in Example 64.

[0235] Many embodiments include at least one non-temporary computer-readable storage medium as described in Embodiment 73, further comprising determining that a conflict exists between a first copy of each copy and a second copy of each copy, and determining a solution to the conflict by applying one or more policy-based defined processes.

[0236] Many embodiments of Example 75 include at least one non-temporary computer-readable storage medium as described in Example 73, further comprising: determining that a conflict exists between a first copy of each copy and a second copy of each copy; sending a report indicating the conflict (e.g., to a computing device or component); receiving resolution data defining a solution to the conflict (e.g., from the computing device); and resolving the conflict by applying the solution.

[0237] It should be understood that the methods and systems described herein are not limited to any specific operation, process, component, or structure described, nor are they limited to any sequence or specific combination of such operation or component as described. It should also be understood that the terms used herein are for illustrative purposes only and are not intended to be restrictive or limiting.

[0238] Where used herein, the singular forms “a,” “an,” and “the” include both singular and plural referents unless explicitly indicated otherwise by the context. Values ​​expressed as approximations by the use of antecedents such as “about” or “approximately” shall include a reasonable variation from the reference value. Where such an approximation is included in a range, not only the endpoints but also the size of the range shall be considered an approximation. Enumerations should be considered illustrative and shall not be limited or restricted to the elements constituting the enumeration or the order in which the elements are listed, unless explicitly indicated otherwise by the context.

[0239] Throughout the specification and claims of this disclosure, the following terms have their given meanings: “comprise,” and variations such as “comprising” and “comprises,” mean, for example, to include, but not to include, other appendices, components, elements, or actions, and are not intended to exclude them. “include,” and variations such as “including,” mean to be limited or restricted to what is indicated to be included, and are not intended to exclude what is not indicated. “may,” means permissible but not restrictive or limiting. “Optional” or “optionally,” means that may or may not be included without altering the result or what is described. “prefer,” and variations such as “preferred” or “preferably,” mean illustrative and more ideal but not required. “etc,” means that merely serve as an example.

[0240] The actions and components described herein for use in performing the disclosed methods and constructing the disclosed systems are illustrative unless the context expressly indicates otherwise. When combinations, subsets, interactions, groups, etc., of these actions and components are disclosed, specific references to each of the various individual and collective combinations and permutations of these may not be expressly disclosed, but each should be understood to be specifically intended and described herein for all methods and systems. This applies to all aspects of this application, including, but not limited to, actions in the disclosed methods and / or components disclosed in the systems. Therefore, where there are various additional actions that can be performed, or components that can be added, it should be understood that each of these additional actions can be performed, and components can be added in any particular embodiment or combination of embodiments of the disclosed systems and methods.

[0241] Embodiments of this disclosure may take the form of entirely hardware embodiments, entirely software embodiments, or embodiments combining software and hardware aspects. Furthermore, methods and systems may take the form of computer program products on a computer-readable storage medium having computer-readable program instructions (e.g., computer software) embodied on the storage medium. Any suitable computer-readable storage medium, including hard disks, CD-ROMs, optical storage devices, or magnetic storage devices, may be used internally, network-connected, or cloud-based.

[0242] Embodiments of the present disclosure have been described with reference to diagrams, flowcharts, and other illustrative diagrams of computer implementation methods, systems, devices, and computer program products. Each block in block diagrams and flowchart illustrations, and each combination of blocks in block diagrams and flowchart illustrations, can be implemented by processor-accessible instructions. Such instructions may include, for example, computer program instructions (e.g., processor-readable and / or processor-executable instructions). Processor-accessible instructions can be built (e.g., linked and compiled) and stored in a processor-executable form in one or more memory devices or one or more other processor-accessible non-temporary storage media. These computer program instructions (built or otherwise) can be loaded into a general-purpose computer, a dedicated computer, or other programmable data processing device to generate a machine. Loaded computer program instructions can be accessed and executed by one or more processors or other types of processing circuits. In response to execution, loaded computer program instructions provide functionality described in relation to flowchart blocks (individually or in specific combinations) or blocks in block diagrams (individually or in specific combinations). Therefore, such instructions executed on a computer or other programmable data processing device create means for implementing functions specified in blocks of a flowchart (individually or in specific combinations) or in blocks of a block diagram (individually or in specific combinations).

[0243] These computer program instructions may also be stored in computer-readable memory, which can instruct a computer or other programmable data processing device to function in a particular manner, thereby generating a product containing processor-accessible instructions (e.g., processor-readable instructions and / or processor-executable instructions) for performing functions specified in flowchart blocks (individually or in specific combinations) or in blocks in block diagrams (individually or in specific combinations). Computer program instructions (built or otherwise) may also be loaded into a computer or other programmable data processing device to perform a series of operations on the computer or other programmable device to generate a computer implementation process. A series of operations may be performed in response to execution by one or more processors or other types of processing circuits. Thus, such instructions executed on a computer or other programmable device provide operations for implementing functions specified in flowchart blocks (individually or in specific combinations) or in blocks in block diagrams (individually or in specific combinations).

[0244] Therefore, the blocks in block diagrams and flowchart examples support combinations of means for performing specified functions related to such diagrams and / or flowchart examples, combinations of operations for performing specified functions, and program instruction means for carrying out specified functions. Each block in block diagrams and flowchart examples, as well as combinations of blocks in block diagrams and flowchart examples, can be implemented by a dedicated hardware-based system that performs the specified functions or operations, or combinations, of dedicated hardware and computer instructions.

[0245] As used herein and in the accompanying drawings, terms such as “module,” “component,” “system,” and “platform” may refer to and / or include computer-related entities or entities related to an operating machine having one or more inherent functionalities. Such entities may be hardware, a combination of hardware and software, software (e.g., program code or executable program code), or running software. In one example, a component may be a processor, an object, an executable file (e.g., binary software), an execution thread, a computer program, and / or a process running on a computing device. For illustrative purposes only, a software application running on a server device may be a component, and the server device may also be a component. One or more modules may reside within a process and / or an execution thread. One or more components may also reside within a process and / or an execution thread. Each module and component may be localized on one computing device and / or distributed across two or more computing devices. In another example, each component (or module) may run from various computer-readable storage media having various stored data structures. A component (or module) can communicate via local and / or remote processes, such as by following a signal containing one or more data packets (for example, data from one component interacting with other systems via a signal, within a local system, within a distributed system, and / or via a network such as the Internet). As another example, in some cases, a component can emulate an electronic component via a virtual machine, for example, within a cloud computing system. The terms “module” and “component” (and their multiple versions) may be used interchangeably in some cases where the context makes it clear.

[0246] As used herein and in the accompanying drawings, the term “processor” can refer to substantially any computing processing unit or computing device, including single-core processors, single processors with software multithreading capability, multi-core processors, multi-core processors with software multithreading capability, multi-core processors with hardware multithreading technology, parallel platforms, and parallel platforms with distributed shared memory. Additionally, a processor can refer to electronic circuits designed and assembled to execute code instructions and / or manipulate data and signaling. Such electronic circuits can be assembled, for example, on a chipset. Thus, in some cases, a processor can be embodied or include application-specific integrated circuits (ASICs), digital signal processors (DSPs), field-programmable gate arrays (FPGAs), complex programmable logic devices (CPLDs), discrete gate or transistor logic, discrete hardware components, or any combination thereof designed and assembled to perform the functionalities described herein. Furthermore, in some cases, a processor can leverage nanoscale architectures, such as molecular and quantum dot-based transistors, switches, and gates, to optimize space use or enhance the performance of the computing device. A processor can also be implemented as a combination of computing processing units.

[0247] Furthermore, in this specification and the accompanying drawings, terms such as “storage,” “data storage,” “repository,” and substantially any other information storage component relating to the operation and functionality of a system, subsystem, module, and component are used to refer to entities or components containing memory that are embodied in “memory component,” “memory.” As described herein, the memory and / or memory components of this disclosure may be either volatile memory or non-volatile memory, or may include both volatile and non-volatile memory. For illustrative purposes only, non-volatile memory may include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable ROM (EEPROM), flash memory, or non-volatile random-access memory (RAM) (e.g., ferroelectric RAM (FeRAM)). Volatile memory may include RAM that can act as external cache memory, for example. As an example rather than an limitation, RAM is available in many forms, including synchronous RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDR SDRAM), extended SDRAM (ESDRAM), sync-link DRAM (SLDRAM), direct Rambus (DRRAM), direct Rambus dynamic RAM (DRDRAM), and Rambus dynamic RAM (RDRAM). Embodiments of this disclosure are not limited to these types of memory, and other types of memory devices may be envisioned.

[0248] Methods, apparatus, devices, and systems may employ artificial intelligence techniques such as machine learning and iterative learning. Examples of such techniques include, but are not limited to, expert systems, case-based reasoning, Bayesian networks, behavior-based AI, neural networks, fuzzy systems, evolutionary computation (e.g., genetic algorithms), swarm intelligence (e.g., Ant algorithms), and hybrid intelligent systems (e.g., expert reasoning rules generated through neural networks, or rules generated from statistical learning).

[0249] Computer implementations, apparatus, devices, and systems have been described in relation to preferred embodiments and specific examples, but the embodiments described herein are intended in all respects to be illustrative rather than restrictive, and therefore the scope is not intended to be limited to the specific embodiments described.

[0250] Unless otherwise expressly stated, no method described herein is ever intended to be construed as requiring its actions to be performed in a particular order. Therefore, if a claim for a method does not actually list the order in which its actions are performed, or if the claims or specification does not specifically state that the actions should be limited to a particular order, no order is ever intended to be inferred in any respect. This is reserved for any possible implicit grounds for interpretation, including the arrangement of actions or action flows, the obvious meanings arising from grammatical structure or punctuation, and logical matters relating to the number or type of embodiments described in the specification.

[0251] It will be apparent to those skilled in the art that various modifications and variations can be made without departing from the scope or spirit. Other embodiments will also be apparent to those skilled in the art from the considerations of this specification and the practices disclosed herein. The specification and examples are to be considered illustrative only, and the true scope and spirit are intended to be indicated by the following claims.

Claims

1. A computing system, A computer comprises at least one processor that executes a computer executable component stored in at least one memory device, and the computer executable component is A plurality of core modules configured to provide defined services, wherein each of the plurality of core modules includes at least one extension point corresponding to a first core module among the plurality of core modules, and the first extension point among the at least one extension point is mapped to a tenant-specific extension module that customizes the defined services for a defined tenant, The application programming interface (API) corresponding to the tenant defined above, The data model corresponding to the tenant defined above, The API router component is configured to invoke a function call to the customized defined service and to receive a message that includes an attribute identifying the defined tenant, The API router component is further configured to redirect the function call to the customized defined service based on the attribute, A computing system in which the API router component exposes the API.

2. The computing system according to claim 1, wherein the first core module is configured to provide at least one first element to the data model, and a second core module among the plurality of core modules is configured to provide at least one second element to the data model.

3. The computing system according to claim 1, wherein the first core module is configured to provide at least one first function to the API, and a second core module among the plurality of core modules is configured to provide at least one second function to the API.

4. The computing system according to claim 1, wherein the first core module is configured to modify at least one of an existing data model or an existing API to bring about at least a portion of the API or at least a portion of the data model.

5. The computing system according to claim 1, wherein the tenant-specific extension module is configured to provide at least one element to the data model, or to provide functionality to the API, or to provide the at least one element to the data model and the functionality to the API.

6. The computing system according to claim 1, wherein the tenant-specific extension module is configured to store a plurality of core functions constituting the API and further store a plurality of core elements constituting the data model.

7. The computing system according to claim 1, wherein the tenant-specific extension module is configured to remove a specific core function from among a plurality of core functions constituting the API and to store a plurality of core elements constituting the data model.

8. The computing system according to claim 1, wherein the tenant-specific extension module is configured to store a plurality of core functions constituting the API and to remove a specific core element from a plurality of core elements constituting the data model.

9. The computing system according to claim 1, further comprising at least one second memory device storing a non-temporary storage structure dedicated to the defined tenant, wherein the non-temporary storage structure includes one or more of configuration attributes, program code defining extension logic, or a plurality of tenant-specific extension modules.

10. The computing system according to claim 9, wherein the non-temporary storage structure includes one of a file system, a file folder, a database, or a table.

11. The computing system according to claim 9, wherein each tenant-specific extension module of the plurality of tenant-specific modules stores a plurality of core elements constituting the data model and further stores a plurality of core functions constituting the API.

12. The computing system according to claim 9, wherein a selected tenant-specific module among the plurality of tenant-specific modules causes a breaking modification of one or more of the core APIs corresponding to the defined service or the core data model corresponding to the data model, resulting in a breakdown of backward compatibility between the customized defined service and the defined service.

13. The computing system according to claim 9, wherein the non-temporary storage structure further includes definition data that identifies tenant-specific services, configuration data corresponding to the tenant-specific services, and metadata corresponding to the tenant-specific services.

14. The non-temporary memory structure further includes definition data that identifies an extension point, and the definition data is First data identifying the domain of the extension point, A second data that identifies the functionality corresponding to the aforementioned extension point, The computing system according to claim 9, comprising: a description of the extension point identifying one or more methods corresponding to the extension point, input parameters for the extension point, and output types corresponding to the extension point.

15. The computing system according to claim 9, wherein the non-temporary memory structure further includes abstract data defining human-readable content that shows a manner of extending tenant-specific services, wherein the human-readable content is either free of program code or includes snippets of custom program code.

16. The computing system according to claim 9, wherein the at least one second memory device further stores a second non-temporary storage structure associated with one or more tenants, the second non-temporary storage structure includes one or more of the following: a second configuration attribute, a second program code defining extension logic, or a plurality of extension modules.

17. The computing system according to claim 16, wherein the non-temporary memory structure and the second non-temporary memory structure are logically configured in a hierarchical structure.

18. The computing system according to claim 17, wherein the hierarchical structure includes a graph having a first node representing the non-temporary memory structure and a second node representing the second non-temporary memory structure.

19. The computing system according to claim 17, wherein the hierarchical structure includes a tree structure, the first node representing the non-temporary memory structure is a root node, and the second node representing the second non-temporary memory structure is a leaf node.

20. The computing system according to claim 9, wherein the at least one memory device includes a permission attribute configured to grant the defined tenant exclusive access to the customized defined service.

21. A computer implementation method, To generate copies of source program code corresponding to a plurality of core modules that provide defined services, wherein the plurality of core modules include at least one first extension point corresponding to a first core module among the plurality of core modules, Adding at least one second extension point to the at least one first extension point in the copy of the source program code, wherein the at least one second extension point is specific to a defined tenant. This includes applying an automated test to probe the integrity of the copy of the source program code having the added at least one second extension point, A computer implementation method wherein applying the automated test determines, based on control flow analysis, whether there are any changes to the control flow of the program code forming the copy of the source program code having the added at least one second extension point.

22. The computer implementation method according to claim 21, further comprising generating a next version of the plurality of core modules based on the current version of the plurality of core modules and the copy of the source program code having the added at least one second extension point.

23. The computer implementation method according to claim 22, wherein generating the next version of the plurality of core modules includes integrating at least one added second extension point into the current version of the plurality of core modules.

24. The computer implementation method according to claim 22, further comprising building a second program code corresponding to at least the next version of the plurality of core modules having the added at least one second extension point, thereby yielding an executable package component comprising the plurality of core modules including the added at least one second extension point.

25. A computing system, One or more processors, A computing system comprising: one or more memory devices storing computer executable instructions that cause the computing system to perform the method according to any one of claims 21 to 24 in response to execution by the one or more processors.

Images