Software computing platform as an extensible 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 to Related Applications This application claims the benefit and priority of U.S. Patent Application No. 17 / 944,907, filed on September 14, 2022, and U.S. Patent Application No. 17 / 944,906, filed on September 14, 2022, both of which claim the benefit and priority of U.S. Provisional Patent Application No. 63 / 347,422, filed on May 31, 2022, the contents of which are hereby incorporated by reference in their entirety.

Background Art

[0002] In a software model as a service for accessing the functionality provided by software, a computing platform hosts a version of software that is common among end - user devices accessing the functionality via the computing platform. Access to the functionality can be referred to as multi - tenant access, and the end - user devices are associated with various different entities that are permitted access to the software. Each of those entities can be referred to as a tenant. In addition to accessing the functionality provided by the software, the end - user devices associated with a tenant can also access the storage infrastructure and other computing resources of the computing platform.

[0003] The SaaS (Software as a Service) model provides easy access to software functionality without the burden of software maintenance, but the codebase corresponding to the software version is common among tenants. Such a codebase can be referred to as a platform. In some existing SaaS systems, the tenant experience on the platform can be customized through restricted registration of tenant-specific logic, and such customization can rely on certain extensibility already built into the platform. That is, these existing SaaS systems can provide a limited form of customizability, and expanding such 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 alone using a codebase configured and adjusted to provide functionality closely related to a particular tenant. However, customizing the codebase in this way 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 such a manner is time-consuming, rather cumbersome, and may continuously increase the complexity of maintenance by growing isolated and customized codebases. In addition, since there may be no guarantee that the codebase conforms to a defined set of functions, it may be impossible to handle such codebases collectively.

[0005] Therefore, the ease of access to software in a SaaS multi-tenant platform and the rich tenant-specific customization of that software appear to be strongly opposed from a design and implementation perspective. Thus, existing computing platforms that provide easy access to software for multiple tenants tend to lack rich and fine-grained extensibility, and vice versa. Therefore, there are many things left to be improved in existing technologies that provide multi-tenant access to software and tenant-specific customization of software. SUMMARY OF THE INVENTION

[0006] It should be understood that both the following summary and the following detailed description of the invention are merely illustrative and explanatory and are not restrictive.

[0007] In one embodiment, the present disclosure provides a computing system. The computing system includes at least one processor that executes computer-executable components stored in at least one memory device. The computer-executable components 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 among the plurality of core modules, and a first extension point among 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.

[0008] Additional elements or advantages of the present disclosure will be described in part in the following specification, will be in part apparent from the specification, or may be learned by practice of the invention. The advantages of the present disclosure may be realized and attained by means of the elements and combinations particularly pointed out in the appended claims.

[0009] This summary is not intended to identify key or essential features of the present disclosure, but is merely intended to summarize certain features and variations thereof. Other details and features will be described in the following sections. Further, both the foregoing summary and the following detailed description of the invention are merely illustrative and explanatory and are not restrictive of the embodiments of the present disclosure.

[0010] The accompanying drawings, which are incorporated herein and constitute a part of this specification, illustrate exemplary embodiments of the present disclosure and, together with the description, serve to explain at least in part various principles, elements, or aspects of the present disclosure. Embodiments of the present disclosure will be described more fully hereinafter with reference to the accompanying drawings. However, the various elements of the present disclosure can be implemented in many different forms and should not be construed as limited to the embodiments described herein. Like numbers refer to like elements throughout.

Brief Description of the Drawings

[0011]

Figure 1

Figure 2A

Figure 2B

Figure 3

Figure 4A

Figure 4B

Figure 4C

Figure 4D

Figure 4E

Figure 5

Figure 6

Figure 7A

Figure 7B

Figure 8

Figure 9

Figure 10

Figure 11

Figure 12

Figure 13

Figure 14

MODE FOR CARRYING OUT THE INVENTION

[0012] Among other technical problems, the present disclosure recognizes and addresses the scalability issues of software as a service (SaaS) computing platforms. As described in more detail below, embodiments of the present disclosure provide an extensible SaaS computing platform that hosts single-tenant, tenant-specific services and includes APIs that permit access to those services in a multi-tenant fashion. Embodiments of the present disclosure build each service by integrating, individually or in combination, a group of one or more tenant-specific extension modules into a collection of core modules that are common among tenants, thereby enabling a collection of customized single-tenant services to be treated as a single multi-tenant system. 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. The customized core platform can have a superset of a common core API 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 to client devices communicating with the router as a multi-tenant platform. The client devices can communicate with the router component to access the common core API of the multi-tenant platform and can selectively target each API function (or extension) of an individual customized core platform. Further, some embodiments can uniquely and systematically enhance the core functionality of a group of core module(s) in situations where the extension points present in the core module(s) may not be sufficient to provide the desired customization.Specifically, embodiments of the present disclosure can temporarily fork the version of the core platform to enable incorporation of additional extension point(s) into the core platform. After it is proven that the operation integrity of the added extension point(s) is sufficient, embodiments of the present disclosure can then safely reintroduce (or fold) the extension point(s) into the upgraded common core. Each existing customized single-tenant platform can be safely upgraded to the new core platform in terms of sufficient performance using such an approach.

[0013] In some embodiments, a computing system includes computer-executable components that include a plurality of core modules that provide defined services. The plurality of core modules also define a core API. The plurality of core modules includes at least one extension point corresponding to a first core module of the plurality of core modules. Each extension point of the at least one extension point can be formed by program code within the first core module, and the program code defines logic associated with the registration of one or more functions from another module. After 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 module as part of the core logic. A 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 results, at least in part, from the registration of one or more defined functions within the tenant-specific module, and the defined function(s) can be called by the first core module. Thus, the customized defined service is a tenant-specific service. The computer-executable component can also include both an API and a data model corresponding to a defined tenant. The tenant-specific extension module mapped to the at least one extension point can customize the core API to generate an API 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 a logical space. Since the tenant-specific extension module can be maintained separately from the core module, the tenant-specific service can be upgraded to a new core by pointing to the upgraded core module.

[0014] Referring to the drawings, FIG. 1 illustrates an example of a computing system 100 that provides extensible functionality customized for a single tenant according to one or more embodiments of the present disclosure. The computing system 100 includes an API router component 110 and a plurality of executable package components for each tenant, including an executable package component 120(J) for tenant J and an executable package component 120(K) for tenant K. The plurality of executable package components provide respective single-tenant services, and each of those single-tenant services can be customized for a respective specific tenant. In one example, the single-tenant services include clinical trial services. Each executable package component of the plurality of 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 can have respective data models associated with the single-tenant services. The single-tenant service provided by the executable package component J 120(J) can have a data model J 160(J) associated with the executable package component J 120(J), and another single-tenant service provided by the executable package component K 120(K) can have a data model K 160(K) associated with the executable package component K 120(K). For illustrative purposes, in the present disclosure, a data model represents the form of service data owned, generated, and accessed by a service and the relationships between the service data. The service can be a tenant-specific service or a core service. The data model can include data entities and associations between at least some of the data entities, and the associations embody such relationships. The data entity includes a data structure having one or more fields. In one example, the data entity can be a table, and the fields can correspond to respective columns within the table.Thus, a data model can include a group of tables and associations between two or more tables, where an association logically links a field in a first table within the group to another field in another table within the group.

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

[0016] The API router component 110 exposes an API that permits access to multiple single-tenant services as if the computing system 100 were a multi-tenant computing platform. To provide access in such a manner, the API router component 110 can receive a message that initiates a function call to a customized service for a particular tenant (e.g., Tenant J or Tenant K), the message including an attribute that identifies the particular tenant. The message can be received from a client computing device (not depicted in FIG. 1) via a communication network 114 that operatively couples the client computing device and the API router component 110. The communication network 114 or another communication network can, in some cases, operatively couple the API router component 114 to other components such as the executable package component J 120(J) and the executable package component K 120(K). The API router component 110 can then redirect the function call to the customized defined service based on the attribute. The API router component 110 can be embodied, for example, as an API gateway. The API exposed by the API router component 110 can be one of various types of APIs such as a Representational 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 can be either an authentication token or a REST parameter. In other cases, the attribute can be a tenant identifier (ID) that uniquely identifies the defined tenant. The tenant ID can be, for example, a Universally Unique Identifier (UUID).

[0017] As described above, each single-tenant service can be customized for a specific tenant. For that purpose, the executable package components for a specific tenant can include a service core having a plurality of core modules that provide a defined service. The service core also defines and exposes an API (referred to as a core API or a common core API) and further defines a data model (referred to as a core data model or a common core data model). The API exposed by the service core can be one of various types of APIs such as a REST API, a GraphQL service, a SOAP service, or an RPC API. Note that the core API exposed by the service core can 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 include the combination of the APIs exposed by each customized single-tenant instance of a collection of customized single-tenant instances. For example, the API exposed by the API router component 110 can expose the combination of API J130 (J) and API K130 (K). The first core module of the plurality of core modules can provide at least one first element to the data model, and the second core module of the plurality of core modules can provide at least one second element to the data model. Additionally, or in some cases, the first core module can provide at least one first function to the API, and the second core module can provide at least one second function to the API. The API and the data model can result from changes composed by one or more core modules. For example, the first core module can change 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] The plurality of core modules have at least one extension point. A first extension point of the at least one extension point may correspond to a first core module of the plurality of core modules. For illustrative purposes, an extension point identifies a function that can be initiated by a core module having the extension point and refers to program code that calls an optional module for implementation of the function. Thus, the optional module can define a function (or its logic) and, in so doing, add logic to the core module and / or adjust the logic within the core module. Instead of defining the extension logic, the program code identifies the signature of the desired function and also serves as a placeholder for the function (or logic) defined in the optional module.

[0019] The service core is common among a plurality of executable package components within the computing system 100. That is, a plurality of core modules, at least one extension point, API, and data model are common among the plurality of 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 point(s) present in the service core. The mapping refers to assigning the functionality provided by the extension module to program code at the extension point within the core module that can activate that functionality. The program code is configured to serve as a placeholder for the functionality. The functionality can be assigned to the program code by reference, for example, by passing a reference to the functionality (or an object representing the functionality). In other words, the mapping refers to obtaining a function from an extension module and registering that function with the core module, and the core module is configured to activate that function. The function is registered (or assigned) by reference via an extension point within the core module. By registering the function with the core module, the customization indicated by the function can be achieved. The mapping is described with respect to core modules and extension modules, but the present disclosure is not limited thereto. In fact, a module (core module or extension module) that defines a function can be mapped to another module (core module or extension module) that has an extension point that enables registering the function. By way of example, a module that defines functionality can be mapped to a module 210 (FIG. 2A) having extension points 220(1) to 220(Q), and one of these extension points has program code that can receive the functionality by reference.

[0020] Tenant-specific extension module(s) can non-destructively modify the core API and core data model to yield a customized API and / or customized data model for a specific tenant. That is, the first tenant-specific extension module preserves the multiple core functions that make up the core API and also preserves the multiple core elements that make up the core data model. Thus, the non-destructive modification can be additive. In other words, the addition is an example of a non-destructive mechanism for modifying the core API and core data model. More specifically, the first tenant-specific extension module can provide at least one element to the core data model or a function to the core API, or can provide at least one element to the core data model and a function to the core API. At least one element that can be provided to the core data model can include a field in a table or a measure in that table or another table. Providing such element(s) can result in the addition of column(s) to one or more tables existing in the core data model. Additionally, or in some non-destructive modifications, at least one element that can be provided to the core data model can include a table.

[0021] In some cases, breaking changes to the core API may be desired. For example, a tenant-specific service may no longer support a particular core function among the multiple functions that make up the core API. In such cases, a first tenant-specific extension module can remove that particular core function while preserving the multiple core elements that make up the core data model. By removing the particular core function that is not supported, the tenant-specific service can be configured in a manner that aligns with the actual capabilities of the tenant-specific service. As an illustration, if the tenant-specific service is a clinical trial, the particular core function that is removed could be the function to determine drug dosage. As another illustration, rather than completely removing a particular core function, a breaking change could involve adding parameters for determining drug dosage to the function, which could result in a lack of compatibility with the existing function being replaced. Such breaking changes can reduce the involvement of that single break-customized instance from the common core API. In other words, that single break-customized instance supports a smaller subset of the common core API. Breaking changes can also reduce the size of the union of the APIs exposed by each customized single-tenant instance in the collection of customized single-tenant instances. Breaking changes are not limited to breaking changes to the core API. In some exemplary scenarios, breaking changes can also be applied to the core data model, and a first tenant-specific extension module can remove a particular core element among the multiple core elements that make up the data model while preserving the multiple core functions that make up the core API. The particular core element can be removed because the tenant-specific service does not rely on that particular element. As an illustration, if the tenant-specific service is a clinical trial, the core element that is removed could be the weight or country of birth of the 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. Merely by way of illustration, a particular core element could be a field in a table or the entire table.In another exemplary scenario, the first tenant-specific extension module can remove specific core elements from the data model and can also remove specific core functions from the core API.

[0022] Accordingly, the selected tenant-specific extension module(s) can cause destructive modifications to the core API or the core data model, or both, in response to being mapped to each extension point present in the core module(s) that provide the defined service. As a result, the selected tenant-specific module(s) can cause a break in backward compatibility with the defined service that is customized. The customized defined service results from such mapping.

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

[0024] Referring further to FIG. 2A, an exemplary architecture of module 210, according to one or more embodiments of the present disclosure, is schematically illustrated. Module 210 can represent a core module or an extension module. Regardless of its type, module 210 has program code that provides the defined functionality of module 210, and also has other program code that defines a group of extension points including a first extension point 220(1) up to a (Q - 1)th extension point 220(Q - 1) and a Qth extension point 230(Q), where Q is a natural number greater than 1. Although Q is illustrated as being greater than 1, the present disclosure is not limited in that regard, and in some cases, a single extension point can exist within module 210. As part of defining the extension points of the 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 is mapped to the 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. Thus, the defined functionality of module 210 is extended to include additional functionality provided by such function(s).

[0025] Accordingly, each extension point of the group of extension points enables the defined functionality of module 210 to be extended by receiving one other module, or a collection of two or more other modules. In other words, the extension point 220(j), where j = 1, 2,..., Q - 1, or Q, can be associated with a single extension module or a plurality of extension modules. Here, Q is a natural number that defines the number of extension points and can be 1 or more. In some cases, depending on the desired functionality of module 210, one or more extension points can be empty. That is, each of those extension point(s) may not be associated with an extension module.

[0026] Figure 2B illustrates an exemplary architecture of service core 140 that includes customizations provided by a plurality of extension modules. The illustrated service core 140 constitutes an example of core module 144 (FIG. 1) and can include a plurality of 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 plurality of core modules can provide core functionality that is common to all tenants accessing computing system 100 as described herein. The specific services provided by those core modules within the illustrated service core 140 can be customized by mapping a plurality of extension modules to respective extension points present in core modules 250(1)-250(4). Such mapping is depicted as an arrow from one module to an extension point of another module. For purposes of illustration, in FIG. 2B, the extension points are represented by respective small rectangles. The plurality of extension modules includes extension module 1 260(1), extension module 2 260(2), and extension module 3 260(3). Such extension modules can be associated with a first source file system (represented as "VP1" in FIG. 2B). The plurality of extension modules also includes extension module 1 270(1) and extension module 2 270(2), each of which is associated with a second source file system (represented as "VP2"). As described herein, each extension module of those extension modules constitutes additional custom functionality for the illustrated service core 140 and results in a customized service for a particular tenant.

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

[0028] Since the extension modules and the core modules share the same program code architecture principle, the development of tenant-specific services can be carried out significantly more computationally efficiently than existing technologies. The extensibility mechanism provided by the mapping of each of the core modules and the extension modules to their respective extension points offers excellent customization flexibility. Compared with existing technologies, such flexibility can be utilized across individual single-tenant services and, when combined with the API router component 110, can enable the implementation of a SaaS multi-tenant computing platform with a highly customized single-tenant system.

[0029] Figure 3 illustrates an exemplary data storage 302 for the configuration of services customized for a single tenant, 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 separation guarantees for tenant-specific services for a particular tenant. The separation guarantee can include permission 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 depicted in Figure 3 for simplicity). The computing device can execute an application that can cause the computing device to present a user interface for receiving the input data to be transmitted to the data storage 302. The application can be, for example, a web browser, an integrated development environment (IDE) application, or the like. The computing device can be operatively coupled to the data storage 302 via a network interface. In some cases, the computing device can have the data storage 302 integrated therein, and the input data can be transmitted to the data storage 302 via a bus architecture. At least some of the information held in the data storage 302 can include a file system structure having a plurality of file systems 304, each file system being dedicated to a respective one of a plurality of tenants. Thus, for a tenant, the information in the data storage 302 can be arranged in a file system 306 dedicated to the tenant. The information can include program code, data, and / or metadata corresponding to a defined version of the available customizations for the tenant. The defined version corresponds to a persistent unique identifier indicating the immutable content that forms the available customizations at a particular point in time.In some cases, the available customizations can be embodied in the definition data resulting from modifications (such as additional modifications) to the definition data existing in the service core. Thus, the customization options existing in the data storage 302 can be an adjusted instance of the configuration existing in the service core. The present disclosure, of course, is not limited to a particular type of non-transitory memory structure (such as a file system), and other non-transitory memory structures can embody virtual partitions. Those other non-transitory memory structures can be held in the data storage 302 and can include, for example, file folders on a disk, git repositories, tables in a database or another type of entry, combinations thereof, or the like. Regardless of the type, a non-transitory memory structure that holds program code and configuration information dedicated to a tenant can 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 file system can include program code 308a that defines extended logic. In some cases, the program code 308a can include a plurality of class objects that define respective extended logics. Additionally, or in some cases, each file system can include one or more extension modules 308b that define other extended logics. Further, or in other cases, each file system can also include a plurality of configuration attributes. A subset of the plurality of configuration attributes can configure resources related to a particular tenant. Some resources can be held within respective files in the file system for that particular tenant. As illustrated in FIG. 3, a first resource can include a workflow definition 312. The workflow definition is a type of configuration that specifies the number of operations that make up a workflow for a tenant. In one example, the operations can constitute a subject capture workflow that enables 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 can cause a client device to present one or a series of UIs or questions to obtain such input data. In some cases, the workflow definition among the workflow definitions 312 can be generated by modifying an existing workflow definition within the service core, e.g., by adding elements. Modifying an existing workflow can include, 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 that exist in an existing workflow definition, or combinations thereof, and thus can result in a workflow definition included in the workflow definition 312. A workflow definition generated in such a manner can serve as a local replacement workflow associated with the service core.

[0031] Other resources can include verification test 316. The verification test can be, for example, an individual automated test operation. Still other resources can include service configuration 322. The service configuration can specify one or more characteristics of the service, such as tables, REST resources, logic, and UI elements, combinations thereof, etc. In some cases, the service configuration can be defined in terms of abstract data (e.g., menu options or response entries in a survey or another type of questionnaire, and associated actions that the values of the menu options or response entries can trigger) that indicates the desired custom configuration of the service. In some cases, the abstract data can indicate 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 the manner in which the service is extended or otherwise changed. Such customization can be referred to as NOCODE customization or NOCODE abstraction. In other cases, the service configuration can be defined in terms of other types of abstract data that indicate human-readable content that includes a limited amount of custom program code. Such human-readable content can also define the manner in which the service is extended or otherwise modified. The limited amount of custom program code (e.g., custom code snippets) enables, for example, the introduction of simple but customized logic. The limited amount of program code also enables the customization to be maintained as a service configuration rather than being elevated to one of program code 308a or extension module 308b. Such a customization approach can be referred to as LOWCODE customization or LOWCODE abstraction. Other resources can include user interface (UI) configuration 326. Other global resources can include tenant configuration 332. Other resources can include metadata definition 336. The metadata definition is in the form of a configuration that can define a data model for a particular tenant. For example, one or more of the metadata definitions 336 are tenant IDsK A data model K 160(K) for can be defined.

[0032] An example of a user interface 410 that includes visual elements representing a file system 415 (or an exemplary virtual partition) for a particular tenant is shown in FIG. 4A. According to aspects described herein, the file system 415 includes several file folders corresponding to configuration files, extension files, extended metadata files, module files, verification test files, and workflow files. As shown in FIG. 4A, the user interface 410 can also include a section 416 that can present at least a preview of a file (README.md) within the file system 415. FIG. 4B illustrates an example of a user interface 418 that includes visual elements representing another example of the file system 415 such that its exemplary VP can be accessed in an IDE. The IDE and the user interface 418 can be presented on a computing device that can receive input data via an interaction with the IDE to configure or otherwise operate on elements of the file system 415. In FIG. 4B, an exemplary JavaScript Object Notation (JSON) definition of the 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 of the compatibility attributes can identify components that can be functionally coupled to the virtual partition (e.g., by reference). In particular, as shown in FIG. 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 version of the core platform corresponds to a persistent unique identifier that indicates the immutable content that forms the core platform at a particular point in time. Thus, the first compatibility attribute can be, for example, a tag (e.g., concatenated) associated with a persistent unique identifier that identifies the version of the core platform. In one example, as shown in FIG. 4B, the 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 set having extension points, and the group of multiple core modules may be available in a computer-executable form within a repository. Thus, for a version of the core platform, the invariant content that forms the core platform at a particular point includes a group of multiple core modules. The group of multiple core modules provides defined services that are common among tenants and defines shared resources including a core API and a core data model. By way of example, the shared resources are composed of contributions from each module (core module or extension module) within the group of modules, but from the perspective of the overall service, they can be used and viewed as an overall atomic resource. Additionally, in some cases, in the core data model, each core module can contribute to the definition and links, but the overall data model (or in some cases, partially) can be used to create a database. Further, in the core API, each core module adds functionality(ies) and endpoint(s), but from the client's perspective, this is the API of the overall service. Shared resources arising from extension modules can have a structure and functionality similar to the shared core resources.

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

[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 another type of metadata) that can control the number of functionality available when executing the services resulting from building the core platform. For that purpose, in some cases, a first control attribute 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 be provided with functionality that is restricted to the functionality of a previous service built against a previous version of the core platform. The first control attribute can 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 FIG. 4B, the tag 426 corresponding to an 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, and the functionality of the previous version of the core platform can be provided and the upgraded functionality of the current version of the core platform can be suppressed so that the package components can be built. More specifically, the codebase forming the current version of the core platform can include program code that can read the VP definition including the first control attribute in response to being compiled. Then, the compiler subsystem can generate an executable package component for the current version of the service such that the package component constrains the functionality of the service to the functionality of the previous version of the core platform.

[0037] Therefore, the introduction of a control attribute in the VP definition that identifies the previous version of the core platform can make it possible to upgrade the current version of the service to the next version of the service without forcing the operation of the upgraded service to conform to the next version of the service. Therefore, the frequency of upgrades to the service can be maintained while exposing the desired legacy functionality to the end user in the upgraded service. As a result, the legacy functionality of the service can be flexibly selected and exposed without causing an interruption in the implementation of the upgrade to the service and / or forcing changes to the tenant.

[0038] At least some of the resources existing in the tenant-specific virtual partition may be reusable across different tenants. For example, some customization components defined from the perspective of comprehensive functionality can be applied across different clinical trials. Thus, in some embodiments, as shown in FIG. 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 be referred to as the "base virtual partition" for naming purposes only. The second virtual partition 445 can be referenced in the VP definition of the first virtual partition 440 via a customization attribute, and the customization attribute has a value defined by data that identifies the second virtual partition. As an example, the customization attribute can be a tag 428, and the data can include a character string 430a. The first virtual partition 440 can include various types of customized 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. Additionally, or in some embodiments, the first virtual partition 440 can include customization components such as an extension module that customizes tenant-specific services. Further, or in other embodiments, the first virtual partition 440 can 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 includes data that identifies the domain of the first extension point, data that identifies the functionality corresponding to the first extension point, a description of the first extension point that identifies one or more methods, the input parameters of the first extension point corresponding to the first extension point, and the output corresponding to the first extension point. Here, the term "domain" refers to the topic of the subject matter related to tenant-specific services.For example, if the tenant-specific service is a clinical trial, an example of a domain can be subject onboarding, subject management, drug management, supply management, or the like. Still further, in still other embodiments, the first virtual partition 440 can also include one or more abstractions that define at least one of an extension logic or an extension parameter that characterizes the manner in which the functionality of the tenant-specific service is extended or otherwise modified. The one or more abstractions can include, for example, at least one NOCODE abstraction, at least one LOWCODE abstraction, or a combination thereof. Thus, each of the abstractions can include a human-readable that defines the manner in which the tenant-specific service is extended or otherwise modified.

[0039] Since the tenant-specific service can be customized by a combination of tenant-specific customization components and reusable customization components, the first virtual partition 440 can reference (or point to) a 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). The reference to the second virtual partition 445 is represented by a white-headed arrow in FIG. 4C. Such a reference can include a unique location identifier that indicates the location of the second virtual partition 445 within the computer network and data that identifies the version of the second virtual partition 445. As described, in the present disclosure, a version corresponds to a persistent unique identifier that indicates the immutable content that forms the virtual partition at a particular point in time. The unique location identifier can include, for example, a URL, and the persistent unique identifier can be, for example, a character string. Each character in the character string can have a meaning defined, for example, by a versioning schema. Merely by way of illustration, the character string can be "2.3.1".

[0040] In some cases, a first virtual partition can reference (or point to) one or more second virtual partitions, and each reference to a virtual partition of the second virtual partition(s) includes data that identifies a version of the virtual partition. Similarly, since a reusable customization component can depend on another reusable customization component, a base virtual partition can reference (or point to) another base virtual partition. Again, a virtual partition that references another virtual partition can inherit reusable customization resources (e.g., configuration files) or customization components, or both, that exist in that other virtual partition. Reusable customization assets that are inherited can be modified in the virtual partition that inherits the reusable customization component. For that purpose, a virtual partition can define modifications applicable to the reusable customization assets. Modifications can be defined via primitives or another type of code segment that specifies directives in the virtual partition. By way of illustration, a reusable customization component can be a workflow definition, and a virtual partition can, in response to being implemented, define modifications to that workflow definition such that the modifications cause the generation of a new workflow definition that includes additional operation(s). Modifications to a reusable customization component can include, for example, adding an element to the reusable customization component, deleting an element from the reusable customization component, replacing an element of the reusable customization component, or combinations thereof. Such modifications can generally be referred to as configuration modifications and can be defined, for example, in terms of program code that indicates modifications such as "add," "delete," "replace," etc.

[0041] A reference from the first virtual partition 440 to the second virtual partition 445 can cause the selection of reusable customization components to be incorporated (or otherwise used) into the first virtual partition 440 by reference. In some cases, such a selection can be wholesale, thereby incorporating (by reference) all 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 to be incorporated into the first virtual partition 440.

[0042] Figure 4D illustrates an example of a hierarchical structure that logically associates tenant-specific virtual partition 460 with several other virtual partitions including reusable customization components. Some of the other virtual partitions may be referred to as "base virtual partitions" for naming purposes only. The base virtual partitions include a first base VP 470(1), a second based VP 470(2), a third base VP 470(3), a fourth based VP 470(4), and a fifth base VP 470(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) - 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, the hierarchical structure can be embodied as a directed graph having a first node representing the tenant-specific virtual partition 460 and one or more second nodes representing each of the base virtual partitions. To illustrate that point, in Figure 4E, the directed graph is illustrated as a directed graph 480 where the root node represents the tenant-specific virtual partition 460 and the other nodes within the directed graph 480 represent each of the base virtual partitions 470(1) - 470(3). Regardless of the specific type of hierarchical structure (tree structure or another type of graph), the edges within the hierarchical structure represent a reference from a first virtual partition to a second virtual partition. In one example, the first virtual partition can be the root virtual partition or a base virtual partition, and the second virtual partition can be another base virtual partition. Such a reference identifies the second virtual partition in terms of its location within the computer network and the version of the second virtual partition.The reference can also include data that defines one or more configuration flags, each of which controls the selection of a customization asset (e.g., either a customization resource or a customization component) within a second virtual partition for inclusion within a first virtual partition. A configuration flag can indicate the selection or deselection of a customization asset. In some cases, a single configuration flag can indicate the selection or deselection of a group of customization assets. For example, the group that is selected or deselected can be the entire set of customization assets that exist within the second virtual partition. Thus, the customization assets of the second virtual partition can be selected individually or as a group for inclusion within the first virtual partition. FIG. 4E illustrates an example.

[0043] To customize services for a particular tenant, a tenant-specific virtual partition for the particular tenant can be selected. Specifically, program code, configuration attributes, and / or other configuration resources within the tenant-specific virtual partition (e.g., file system) can be selected as a whole. The tenant-specific virtual partition constitutes a root node within 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 a tree structure (such as tree structure 450 in FIG. 4D) or a directed graph (such as directed graph 480 in FIG. 4E). Regardless of its type, the hierarchical structure represents a system of memory devices that includes tenant-specific virtual partitions and other virtual partitions, either individually or in specific combinations. Again, regardless of whether the hierarchical structure is a tree structure or a directed graph, the association between the tenant-specific virtual partition and other virtual partitions is represented by each edge of the graph corresponding to the hierarchical structure. Each edge of each edge represents a reference that identifies a particular virtual partition of another virtual partition in terms of a location within a computer network and a version of a particular virtual partition. One or more configuration flags corresponding to such a reference define a selection of one or more customization assets to include in the tenant-specific virtual partition. Thus, references associated with the hierarchical structure can collectively define a complete selection of customization assets (e.g., customization resources, customization components, or combinations thereof) to include in the tenant-specific virtual partition.

[0044] Such a selection 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 the like). In short, the service definition resulting from the selection can be sent to the build subsystem 510 (FIG. 5). In some cases, the service definition can be sent in response to a one-click interaction or a similar gesture interaction with a user interface presented on a computing device (not shown) that is functionally coupled to the build subsystem 510 (FIG. 5). The build subsystem 510 can generate an executable package component 520 based on the service definition. More specifically, the build subsystem 510 can convert the service definition into an executable package component 520. Similar to other executable package components disclosed herein, the executable package component 530 includes a service core 540, a plurality of core modules 544 (also referred to as feature modules), and a tenant-specific extension module 550 mapped to an extension point 546. The service core 540 defines and exposes an API 530 (such as a REST API) for the service. In fact, a collection of the plurality of core modules 544 and the tenant-specific module 550 defines and exposes the API 530.

[0045] To convert the service definition into an executable package 520, the build subsystem 510 can include a set of multiple rules in one or more memory devices (e.g., a mass storage device). The set of multiple rules can map, for example, service element configuration(s), metadata, and / or program code (such as extension class(es) or extension module(s), or both) identified in the service definition into a format that matches the package type used to provide the service core 540. The package type can enable the distribution of the executable package component 520 and can be a container, an executable binary file, or the like. The build subsystem 510 can apply the set of multiple rules individually or in specific combination(s) to build the service definition into the executable package component 520.

[0046] The configuration attributes that form part of the service definition can, in some cases, be transmitted as one or more configuration files within a selected tenant-specific virtual partition or a base virtual partition that directly or indirectly depends on the selected tenant-specific virtual partition. In some cases, at least one of the one or more configuration files can be a JSON definition file. Each configuration file can define a NOCODE (or code-free) abstraction that identifies the 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 manner in which to extend or otherwise modify tenant-specific services. The set of multiple rules applied by the build subsystem 510 can include a code template that can convert the abstraction into program code (such as C# code or C++ code). The build subsystem 510 can apply the code template to build an extension module and package the extension module into a container as part of the package component 520. The container can be tenant-specific and can be built on top of a base container having a service core 540 (including a core module 544).

[0047] The build system 510 operates on a service definition composed of a file system (or virtual partition) within the data storage 302. Thus, 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 over 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 the source program code that defines a new version of the service core that is common across single tenants. Thus, existing instances of configuration and extension modules can be upgraded to a new version of a common service core (or core platform) that operates those existing instances on the same updated core platform. In this way, the build subsystem 510 can also implement backward compatibility by rebuilding the extension modules from the source program code against the updated core modules. Since the build subsystem 510 can be rebuilt from the source program code, it can detect and correct changes that break backward compatibility at the source program code level and at 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. In some cases, note that the build subsystem 510 can be flexible and also leverage binary backward compatibility by building extension modules against existing pre-built extension modules. Building extension modules in such a manner enables faster development. Thus, the build subsystem 510 can flexibly transition between build modalities, namely building from source program code and building from pre-built modules, and thus can select a build modality that gives a speed that exceeds the strictness of backward compatibility, and vice versa.

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

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

[0051] The parse component(s) 640 can determine, individually or in combination, whether one or more groups of references meet the consistency criteria. For that purpose, the parse module 640 can traverse the graph and compare references that point to the same virtual partition of the first virtual partition 620. The consistency criteria can indicate that such references must identify the same instance or the same version of the same virtual partition in order to maintain consistency.

[0052] If the reference groups meet the consistency criteria, one or more merge components 650 included in the build system 510 can generate the centrally managed virtual partitions 632 (which may be referred to as workspaces or workspace storage) within the data storage 630, either individually or in combination. The centrally managed virtual partition 632 can include one or more computer-readable components present in each of the first virtual partition 620 and the second virtual partition 610. In some cases, at least one of the computer-readable component(s) can 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 a tree structure) representing the logical organization of the first virtual partition 620 and the second virtual partition 610. As an example, flattening the graph can include generating a respective copy of all the customization components and customization resources within the first virtual partition 620 and the second virtual partition 610, and holding such respective copies within the centrally managed virtual partition 632. The copies can be generated and held in the order of the graph according to the logical compilation provided by the graph. More specifically, the order of the graph is the order in which references are made between the virtual partitions within the graph. Additionally, or in some cases, flattening the graph can include applying one or more primitives (or other types of directives) present in the first virtual partition 620 and the second virtual partition 610. The one or more primitives can be applied in the order of the graph. As described herein, such primitive(s) can define one or more modifications applicable to the customization resources or customization components.Thus, as part of flattening the graph, at least one of the merge component(s) 650 can apply one or more primitives, either 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 two or more copies of each customization asset. An example of a conflict is a file collision (or clash) involving two or more files, where each file of the two or more files corresponds to the same customization resource but has different identifying attributes with respect to the other file(s) of 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 customization asset and a second copy of the customization asset. Such copies can be included in respective virtual partitions of a first virtual partition 620 (e.g., base VP) and a second virtual partition 610 (e.g., tenant-specific VP). Determining that such a conflict exists can cause at least one of the merge component(s) 650 to collect information indicating the conflict. As the graph flattening progresses, at least one of the merge component(s) 650 can detect one or more other conflicts and, in response, collect additional information indicating such other conflict(s). Additionally, or in some cases, at least one of the merge component(s) 650 can provide a report identifying one or more conflicts detected as part of flattening the graph. Providing a report can include holding data constituting the report in data storage, transmitting such data to a computing device (not depicted in FIG. 6), and / or causing data constituting the report to be presented on a display device.In one example, the display device can be integrated with or operatively coupled to the computing device.

[0054] Additionally, or in some cases, at least one of the merge component(s) 650 can receive input data that defines a solution to one or more detected conflicts. At least one of the merge component(s) 650 can resolve one or more conflicts by applying such a solution. The input data can be referred to as resolution data, simply for naming purposes. Further, or in other cases, at least one of such merge component(s) 650 can resolve one or more conflicts, at least in part. For that purpose, at least one of the merge component(s) 650 can determine, and in some cases also implement, a solution to at least one of the conflict(s) by applying a conflict resolution process. In some situations, at least one of the merge component(s) 650 can use the resolution data as part of applying the conflict resolution process. As an example solution, in an exemplary scenario where there is a conflict within a file, a component of the merge component(s) 650 can resolve the conflict by overriding the use of that file in favor of another file. The other file can then be held in the centrally managed virtual partition 632. As another example, in an exemplary scenario where there is one or more collision, a component of the merge component(s) 650 can resolve the collision by selecting one of the two or more colliding files. Such a selection can be policy-based. For example, the two or more colliding files can each have respective associated parameters (e.g., priority values), and the policy can indicate that the colliding file having the maximum associated parameter among the two or more colliding files should be selected.In a situation where multiple colliding files have the same associated parameter and that parameter is the maximum associated parameter, the policy can indicate that an error message should be supplied, or the policy can cause the application of a defined disambiguation process.

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

[0056] In some cases, generating computer-executable component(s) can include converting at least one computer-readable component out of one or more computer-readable components into respective program code artifacts 634. For that purpose, as illustrated in FIG. 6, build subsystem 510 can obtain at least one computer-readable component from a centrally managed virtual partition 632, individually or in combination, and then can include one or more conversion components 660 that can use the at least one computer-readable component to generate specific code artifacts that can be compiled or otherwise built. The at least one computer-readable component can be based on abstracted data configured using a NOCODE approach or a LOWCODE approach. In the NOCODE approach, the abstracted data can be configured in terms of human-readable content without program code. In the LOWCODE approach, the abstracted data can be configured in terms of human-readable content that includes a limited amount of custom program code (e.g., snippets of custom program code). The limited amount can be a small number of lines of custom program code, such as, for example, 5 lines, 10 lines, 15 lines, 20 lines, or the like. To generate specific code artifacts, at least one of the conversion component(s) 660 can access a code template (or conversion template) from a second virtual partition 610 or, in some cases, from a set of code templates natively available, and apply the accessed code template to the at least one computer-readable component to result in specific code artifacts. Additionally, generating computer-executable components based on specific code artifacts can also include building computer-executable components using respective program code artifacts.At least one of the build component(s) 670 can build a specific program code artifact.

[0057] More specifically, by way of example only, generating computer-executable component(s) (e.g., extension module(s) 636) can include accessing abstracted data included in one or more computer-readable components from the centrally managed virtual partition 632. Again, the abstracted data can define human-readable content that indicates a manner of extending tenant-specific services, and the human-readable content has no program code or the human-readable content includes a limited amount of custom program code. At least one component of the transformation component(s) 660 can access the abstracted data. As an example, the abstracted data can be formatted according to JSON and held in a configuration file or another type of data structure so as to be present in the centrally managed virtual partition 632. Additionally, generating computer-executable component(s) can also include accessing a code template (or transformation template) that may be present in the second virtual partition 610. In one example, at least one component of the transformation component(s) 660 can also access the code template. In another example, at least a second component of the transformation component(s) 660 can access the code template. Further, generating computer-executable component(s) can also include generating a first computer-executable component of the one or more computer-executable components via one of the build component(s) 670 or a combination of build components 670 based on the abstracted data and the code template.

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

[0059] Build system 510 can build program code that defines a plurality of core modules related to a particular version of the core platform, via one or a combination of build component(s) 670. That version can be identified, for example, in the VP definition present in the second virtual partition 610. The program code can form a code codebase 680. In this way, build system 510 can generate a build core module 688 and hold the build core module 688 in one or more memory devices 686 (commonly referred to as data storage 686).

[0060] Next, build subsystem 510 can build an executable package component 694 (e.g., one of package components 1 to N 580 (Figure 5)) by combining the built core module 688 with tenant-specific extension modules being built as described herein. The executable package component 694 is specific to a particular tenant corresponding to the 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 can be part of a distributed storage system such as a network of storage server devices. In some cases, the data storage 690 can be part of a computing device (such as a server device) hosting the build subsystem 510. For example, in such a case, the data storage 690 can be embodied as a mass storage present in the computing device.

[0061] In some embodiments, the build subsystem 510 can generate program code 684 from the second virtual partition 610 and can pass the generated program code 684 to the core codebase 680. For purposes of illustration, in such embodiments, a conversion component of 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 within a defined section of the core codebase 680. Such a section can be, for example, an empty directory within the core codebase 680. In such embodiments, the core codebase 680 can 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, at build time, combine the program code 684 with one or more other components already present in the core codebase 680. Such a combination can extend or customize one or more components without replicating the one or more components to the second virtual partition 610 or one or more of the second virtual partitions 620. By way of example only, a component present in the core codebase 680 can be a class that can be extended by adding a field or another type of attribute via the generated program code 684. The field (or attribute can be the height of the subject, the date of birth of the subject, the age of the subject, or the like. Thus, instead of adding all desired fields of a class within a customization component (e.g., one of the extension modules 308b) within the second virtual partition 610, all desired fields can be added as a single file and then combined with the class using the build logic of the build component(s) 670.

[0062] Accordingly, 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 or a combination of the build component(s) 670 can generate a new instance of the build core module 688 using the modified core codebase 680. Then, at least one of the build component(s) 670 can generate the executable package component 694 by combining the computer-executable component(s) that form the new instance of the build core module 688.

[0063] Referring further to FIG. 5, the build subsystem 510 can deploy the executable package component 520 to a runtime subsystem 560 that includes a cluster of compute server devices (not depicted in FIG. 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 a 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, and the executable package component q is a container or constitutes a container. As shown in FIG. 5, the runtime subsystem 560 can deploy a plurality of 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 separate 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 assign resource quotas to each tenant. The quotas can be applied to processing time and / or memory resources.

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

[0065] As illustrated in FIG. 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, the customizations can be defined by a group of one or more virtual partitions, such as a first virtual partition 620 and a second virtual partition 610. The core codebase can be defined, at least in part, by a core codebase 680. The first development environment and the second development environment can be decoupled and thus can be operated or otherwise managed by different respective entities. For example, an entity can develop a core codebase for providing a service core, and the customizations can be developed by a third party. Such decoupling between the first development environment and the second development environment can enable the core codebase to be upgraded 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 reference (sometimes colloquially referred to as “point to”) the upgraded service core. The virtual partition can reference the upgraded service core via a VP definition that includes, for example, a compatibility attribute “use-platform-version:” and a persistent unique identifier identifying the version of the upgraded service core. Thus, the customization of tenant-specific services and the upgrade to those services can be simplified and can result in a more efficient use of computing resources and time.

[0066] In the present disclosure, a service core (or core platform) can be upgraded in at least two ways. One way involves adding one or more extension points to core modules that make up the current version of the service core. Such an addition results in a core codebase that embodies the next version of the service core. Another way involves making changes to the functionality, user interface, and / or other elements of the current version of the service core. Those changes can include removal of existing functionality, revision of existing functionality, addition or new functionality, or combinations 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 connection with adding extension points to a service core (or core platform), FIG. 7A is a schematic diagram illustrating an exemplary process 700 for expanding the extensibility of the service core. The extensibility of the service core (e.g., service core 140 (FIG. 1)) is provided by one or more extension points. Thus, adding extension point(s) expands its extensibility. The services provided by the service core are common among single tenants according to the aspects described herein, and can be customized to tenant-specific custom services by mapping one or more extension modules to each of the plurality of extension points. The exemplary process 700 embodies an extensibility approach that introduces additional extension point(s) into a fork of the service core and then folds the additional extension point(s) into the service core at a suitable time after the fork is created. The suitable time can be after the integrity / stability of the fork has been tested and sufficient results have been produced. The extensibility approach may be referred to as just-in-time extensibility (JITX) for merely naming purposes. The extensibility approach can be implemented by a computing system 760 (FIG. 7B), which may be referred to as a JITX subsystem 760 for merely naming purposes. The JITX subsystem 760 is part of the computing system 750.

[0068] Process 700 can be implemented during the development timeline 710 of the service core. In 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 the like). Thus, starting from version V0, after n maintenance intervals have elapsed, version V n is created. After a defined number of maintenance intervals have elapsed, a new version of the service core can be released. In FIG. 7A, as merely an example, after n = 4 maintenance intervals have elapsed, a new version JPEG2025520161000002.jpg64 of the service core is released.

[0069] The functional requirements of a particular tenant may not be known in advance after the initial configuration of the service core's extension points. Thus, in JITX, in response to a 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 FIG. 7A, merely by way of example, at time t f a copy of the source program code corresponding to version V1 of the service core is generated. The generator component 762 (FIG. 7B) can generate the copy using the core code base A 770 (A) that includes the source program code corresponding to version V1. The generated copy can be referred to as a fork, and the generator component 762 can hold the fork within the forked code base 782. The repository 780 can hold the forked code base 782. During the time interval 720 (which can 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), and thus the initial configuration of the extension points can be enhanced. The one or more extension points are specific to a particular tenant. Despite being tenant-specific, in some cases, the extension point(s) can be generated to have a broader scope of application upon insertion into the service core release. The existing set of extension points includes a first existing extension point corresponding to the first core module among the plurality of core modules that form version V1 of the service core. The span of the time interval 720 can be based on, for example, the complexity of the additional extension point(s) and the time for implementing and probing the extension point(s). As shown in FIG. 7B, the generator component 762 can, for example, generate the extension point(s) and hold the extension point(s) in one or more configuration files 784. Other types of data structures can also include the extension point(s).

[0070] By creating such a copy of the program code and adding tenant-specific extension point(s) to version V1 of the service core, an updated version 730 of the service core can be created for a particular tenant for which unexpected functionality should be added to the service core. The updated version 730 (referred to as V 1-X for naming purposes) is applicable to a particular tenant and can be operated outside of the development timeline 710. As described, the updated version 730 can be held within the forked codebase 782. In that way, V 1-X serves as a software test bed for the added tenant-specific extension point(s) and also for improving the extensibility of the service core. Thus, the forked version of the service core (e.g., version V1) and subsequent versions of the service core remain common and usable for other tenants. In some cases, a copy of the source program code with additional tenant-specific extension point(s) can be operated to probe the integrity of that copy. In short, one or more automated tests can be applied to that modified copy of the source program code. The automated test(s) can probe the integrity of the modified copy, individually or in combination. In some cases, applying the automated test(s) includes determining whether there are changes to the control flow of the copy of the source program code with the added extension point, based on control flow analysis.

[0071] After sufficient results of the applied automated test(s), a copy of the source program code with the added extension point(s) can be merged with the current version of the service core to yield the next version of the service core with the added extension point(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 held in the core code base 770(B), and the next version of the service core can be held in the candidate code base 790. The next version of the service core can then be built into an executable package component. For that purpose, in some embodiments, the compiler subsystem 796 can build the executable package component. In one example, the next version of the service core can be a maintenance release for the service core. The executable package component (e.g., package component K 120(K) (FIG. 1)) includes a plurality of core modules including the added extension point(s), and also includes an API (e.g., API K 130(K) (FIG. 1)). In some cases, at least one of the added extension point(s) can have a respective tenant-specific extension module mapped to the at least one extension point.

[0072] There are multiple ways to merge a copy of the source program code with the added extension point(s) and the current version of the service core. In one exemplary scenario, referring to FIG. 7A, V 1-XThe added extension point(s) in [V2] are clearly distinguishable from other program codes. For example, the added extension point(s) can be commented or marked otherwise. Thus, the added extension point(s) can be separated and incorporated into V2 (e.g., the current version) to form V3. Such incorporation is represented by the line and arrow from the updated version 730 to V3. In addition to the added extension point(s), other safeguard code can also be incorporated into V3 to ensure that the existing logic resulting from V2 remains unmodified by the presence of the added extension point(s) in V3. Such an approach to generating the next version of the service core provides complete backward compatibility by construction. In another exemplary scenario, V 1-X The source program code in [V2] and the source program code in V2 can be combined, for example, by directly using normal merge techniques, to form V3. This approach is simple and efficient, but the source program code merger may have the potential to incorporate logic or other elements beyond the added extension point(s). Thus, in some cases, there may be a likelihood of unintended partial backward compatibility.

[0073] As illustrated in FIG. 7A, the next version of the service core with the added extension point(s) can be a maintenance release and, as described, can be held, for example, in candidate codebase 790. Thus, the source program code resulting from the above merge is built, and the executable package component obtained from having the added extension point(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 extension points can be available and common to other tenants than the particular tenant for which the added functionality is configured. During the intermediate time between the initial release of the executable package component and a subsequent release of the service core, process 700 can include a test stage 740 in which the executable package component can be subjected to a plurality of automated verification tests. The number of the plurality of automated verification tests can be based on the added functionality. In some cases, instead of subjecting the executable package component to a plurality of automated verification tests, a single automated verification test can be applied. Such automated verification test(s) can be tenant-specific and can probe the integrity of the executable package component. The integrity of the executable package component can be probed for every tenant using a previous version of the service core. The automated verification test(s) can be part of a previous version of the service core and can be extended by a virtual partition. The automated verification test(s) included in test 740 can be based on control flow analysis, individually or in combination, and can probe for the presence or absence of changes to the control flow in the executable package component with respect to the service core prior to the addition of the extension point(s). Merely by way of illustration, as shown in FIG. 7A, the executable package component can be released as version V3 of the service core and the automated test can be for version It can be applied during the intermediate period before the release of TIFF2025520161000003.tif64. In some embodiments, the upgrade component 766 (FIG. 7B) can implement an automatic verification test(s). In response to sufficient results of the test(s) (e.g., backward compatibility is not broken), the upgrade component 766 can upgrade the program code in the candidate codebase to the core codebase 794 corresponding to the service core version of TIFF2025520161000004.tif64. Upgrading the program code can include storing the program code in a repository and assigning a persistent unique identifier that defines the service core version V3 (or another appropriate version).

[0074] A terminal computing device (not depicted in FIG. 7A) can cause the upgrade component 766 (FIG. 7B) to implement the test stage 740 via the API router component 110 (FIG. 1) and the API corresponding to the service core, or otherwise instruct it to do so. For that purpose, the terminal computing device can execute program code, such as a script, that applies one or more automatic verification tests to an executable package component obtained from building a copy of the source program code having the added extension point(s). The automatic verification test(s) can be applied by initiating one or more function calls of the API via the API router component 110 (FIG. 1). The terminal computing device can obtain the automatic verification test(s) from a virtual partition within the data storage 302 (FIG. 3) in response to executing the program code. The automatic verification test(s) can be a subset of the verification test 316 (FIG. 3).

[0075] At least some of the automated verification tests (plural) can each include a respective workflow that includes a collection of defined test stages. Thus, the automated verification tests can be applied computationally efficiently by selectively executing a subset of the test stages rather than the entire collection, and thus the performance of the automated verification tests can be accelerated. For example, the automated verification tests (plural) can be applied in an order that reduces the result risk posed by potential errors in the operations / logic, where the first test logic, if incorrect, results in a catastrophic result (e.g., harm to the health of a clinical trial subject), and then, if incorrect, can continue to test other logic that results in a less catastrophic result. As another example, the automated verification tests (plural) can be applied to the changed portion of the logic without testing other logic that remains unchanged and is known to be fully effective. Additionally, or in some cases, computational efficiency can also be achieved by generating synthetic data that can avoid human intervention in testing various operation vectors. For illustrative purposes, a vector can be that a given clinical trial is set to be an in-clinic visit rather than a home visit. Thus, the home visit logic, for example, does not need to be tested or otherwise probed.

[0076] In connection with updates to the functionality of the services provided by the service core (or core platform), FIG. 8 illustrates an exemplary computing system 800 for upgrading the service core based on the updated functionality of the service according to one or more embodiments of the present disclosure. As described, this service is common among 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 code base 820 corresponding to the current version of the service core. That version is simply for naming purposes and is V in FIG. 8 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 within 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 (which may be referred to as deprecated) existing functionality. In some cases, 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 can include, for example, instructions for editing a fragment of the program code. The input data 804a and the signaling 804b can be received from a computing device (not depicted in FIG. 8) via a user interface that is functionally coupled to the upgrade subsystem 810. Additionally, the generator component 812 can integrate the added program code and the changes to the program code into the forked codebase 832. Thus, the computing system can evolve the forked codebase 832 until one or more desired changes to the copy of the source program code are implemented based on the input data 804a and / or the signaling 804b. Such evolution is depicted by an arc with an unfilled 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 can include a test component 814 that can apply one or more automated tests to that modified copy of the source program code. The automated test(s) can probe the integrity of the modified copy, either individually or in combination. In some cases, applying the automated test(s) includes determining whether there are changes to the control flow of the modified copy of the source program code based on control flow analysis.

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

[0080] The upgraded service core continues to provide services that are common among single tenants, albeit according to updated defined functionality, and thus it is possible to probe the integrity of the operation of the upgraded service core. Accordingly, computing system 800 can build a second source program code corresponding to the next version of the service core. The second source program code can be the candidate code base 840. For that purpose, computing system 800 can include a compiler subsystem 850. In one example, compiler subsystem 850 can be compiler subsystem 796 (FIG. 7). Building candidate code base 840 results in executable package components (e.g., containers, executable binary files, or the like). The executable package components can include a plurality of core modules that are built and that individually or in combination provide an upgraded service with updated defined functionality. The executable package components can also include a common core API. Additionally, computing system 800 can include an elevation component 816 that can operate the executable package components by applying one or more automated verification tests. The automated verification test(s) can probe the integrity of the operation of the executable package components individually or in combination. Applying a second automated test(s) can include, based on control flow analysis, determining, for example, whether there are changes to control the flow of the executable package components to the service core before the defined functionality of the service is updated.

[0081] The terminal computing device (not shown in FIG. 8) can cause the upgrade component 816 to apply one or more automated verification tests, or can otherwise instruct the application of one or more automated verification tests. In some cases, the terminal computing device can apply one or more automated verification tests via the API router component 110 (FIG. 1) and a common core API exposed by the service core. For that purpose, the terminal computing device can execute program code, such as a script, that applies one or more automated verification tests to executable package components obtained from building a candidate codebase 840 having updated functionality. The one or more automated verification tests can be applied by initiating one or more function calls of the common core API via the API router component 110 (FIG. 1). In response to executing such program code, the terminal computing device can obtain one or more automated verification tests from a virtual partition within the data storage 302 (FIG. 3). The one or more automated verification tests can be, for example, a subset of the verification tests 316 (FIG. 3).

[0082] As described herein, at least some of the automated verification test(s) can each include a respective workflow that includes a collection of defined test stages. Thus, the automated verification test can be applied computationally efficiently by selectively executing a subset of the test stages rather than the entire collection, and thus the performance of the automated verification test can be accelerated. For example, the automated verification test(s) can be applied in an order that reduces the result risk caused by potential errors in the operation and / or logic of an upgraded service core having updated functionality, where the first test logic, if incorrect, results in a catastrophic result (e.g., damage to the health of a clinical trial subject), and then, if incorrect, can continue to test other operations and / or logic that result in less catastrophic results. As another example, the automated verification test(s) can be applied to the portion of the updated functionality (or changed logic) without testing other functionality that remains unchanged and is known to perform adequately. Additionally, as described herein, computational efficiency can also be achieved by generating synthetic data that can avoid human intervention in the testing of various operation vectors. For illustrative purposes, a vector can be that a given clinical trial is set to an in-clinic visit rather than a home visit. Thus, the home visit logic, for example, need not be tested or otherwise probed.

[0083] In response to sufficient result(s) of the test (e.g., backward compatibility is not broken), the upgrade component 816 can upgrade the second source program code within the candidate codebase 840 to the core codebase 860 corresponding to version V of the service core. Upgrading the program code can include persisting the program code in a repository and assigning a persistent unique identifier that defines version V of the service core. n+1 As described herein, at least some of the automated verification test(s) can each include a respective workflow that includes a collection of defined test stages. Thus, the automated verification test can be applied computationally efficiently by selectively executing a subset of the test stages rather than the entire collection, and thus the performance of the automated verification test can be accelerated. For example, the automated verification test(s) can be applied in an order that reduces the result risk caused by potential errors in the operation and / or logic of an upgraded service core having updated functionality, where the first test logic, if incorrect, results in a catastrophic result (e.g., damage to the health of a clinical trial subject), and then, if incorrect, can continue to test other operations and / or logic that result in less catastrophic results. As another example, the automated verification test(s) can be applied to the portion of the updated functionality (or changed logic) without testing other functionality that remains unchanged and is known to perform adequately. Additionally, as described herein, computational efficiency can also be achieved by generating synthetic data that can avoid human intervention in the testing of various operation vectors. For illustrative purposes, a vector can be that a given clinical trial is set to an in-clinic visit rather than a home visit. Thus, the home visit logic, for example, need not be tested or otherwise probed. n+1 As described herein, at least some of the automated verification test(s) can each include a respective workflow that includes a collection of defined test stages. Thus, the automated verification test can be applied computationally efficiently by selectively executing a subset of the test stages rather than the entire collection, and thus the performance of the automated verification test can be accelerated. For example, the automated verification test(s) can be applied in an order that reduces the result risk caused by potential errors in the operation and / or logic of an upgraded service core having updated functionality, where the first test logic, if incorrect, results in a catastrophic result (e.g., damage to the health of a clinical trial subject), and then, if incorrect, can continue to test other operations and / or logic that result in less catastrophic results. As another example, the automated verification test(s) can be applied to the portion of the updated functionality (or changed logic) without testing other functionality that remains unchanged and is known to perform adequately. Additionally, as described herein, computational efficiency can also be achieved by generating synthetic data that can avoid human intervention in the testing of various operation vectors. For illustrative purposes, a vector can be that a given clinical trial is set to an in-clinic visit rather than a home visit. Thus, the home visit logic, for example, need not be tested or otherwise probed.

[0084] The JITX subsystem 760 (FIG. 7B) and the upgrade subsystem 810 (FIG. 8), as well as the various repositories coupled thereto, can form a computing system that embodies a development environment that can be used to develop a core codebase. Such a computing system may be referred to as an evolutionary system. Compared to existing technologies, the evolutionary system can provide greater upgrade flexibility and excellent capacity for reducing 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 validating changes to the service core before elevating the service core to an upgraded service core.

[0085] In view of the aspects described herein, exemplary methods that may be implemented in accordance with the present disclosure can be better understood, for example, with reference to the flowcharts in FIGS. 9-12. For the sake of simplicity of explanation, the exemplary methods disclosed herein are presented and described as a series of blocks (e.g., each block represents an action or operation in the method). However, the exemplary methods are not limited by the order of the blocks and the associated actions or operations, and some blocks may be performed in a different order than shown and described herein and / or concurrently with other blocks. Further, not all of the illustrated blocks and associated actions (s) may be required to implement an exemplary method according to one or more aspects of the present disclosure. Two or more of the exemplary methods (and any other methods disclosed herein) may be implemented in combination with each other. Note that the exemplary methods (and any other methods disclosed herein) may alternatively be represented as a series of interrelated states or events in a state diagram or the like.

[0086] FIG. 9 is a flowchart of an exemplary method 900 for providing an extensible service customized for a single tenant according to one or more embodiments of the present disclosure. A system of computing devices can implement the exemplary method 900 in whole or in part. For that purpose, each computing device of the system of computing devices includes computing resources that can implement at least one of the blocks included in the 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, an interface(s) (e.g., an I / O interface or an API or both), a controller device(s), a power supply, combinations of the above, and / or similar resources. In one example, a system of computing devices can include programming interface(s), an operating system, software for configuring and / or controlling a virtualized environment, firmware, and similar resources. A system of computing devices can be referred to as a computing system.

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

[0088] At block 920, a computing system can configure an API corresponding to a defined tenant. For example, the API can be API J 130(J) (FIG. 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 a plurality of core modules and mapped extension module(s).

[0089] In block 930, the computing system can configure an API router component that publishes an API. The API router component can be an API gateway. In one example, the API router component can be API router component 110 (FIG. 1). As described herein, the API router component can publish a collection of single-tenant APIs as a multi-tenant deployment according to the SaaS model of access to services.

[0090] In block 940, the computing system can receive a message that initiates a function call to a defined service via the API router component. The message can include an attribute indicating the defined tenant. In some cases, the attribute that identifies a particular tenant can be either an authentication token or a REST parameter. In other cases, the attribute can be a tenant ID that uniquely identifies the defined tenant. The tenant ID can be, for example, a UUID.

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

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

[0093] In some cases, a computing system implementing the exemplary method 1000 can host, among software modules, parsing component(s) 640, merging component 650, conversion component(s) 660, and build component(s) 670 (FIG. 6). The computing system can implement the exemplary method 1000, for example, by executing one or more instances of parsing component(s) 640, merging component(s) 650, conversion component(s) 660, and build component(s) 670. Thus, in response to execution, parsing component(s) 640, merging component(s) 650, conversion component(s) 660, and build component(s) 670 can perform, individually or in combination, operations corresponding to the blocks of the 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 (e.g., core codebase 680 (FIG. 6)) can include program code defining one or more core modules. The computer-executable component(s) can be generated by building that program code. The program code can be built, for example, via build component(s) 670. In some cases, each component can generate multiple computer-executable components corresponding to computer-executable core modules. The multiple computer-executable components can be the built core module 688 (FIG. 6).

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

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

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

[0098] In block 1030, the computing system can generate a second virtual partition that includes one or more computer-readable components present in each first virtual partition. The generated second virtual partition is a centrally managed virtual partition. For example, the second virtual partition can be the centrally managed virtual partition 632 (FIG. 6), which is not shown in FIG. 10, but the computing system can hold the second virtual partition in a second data repository. If the graph represents the logical composition of each first virtual partition, generating the second virtual partition includes flattening the graph. As described herein, flattening the graph can include applying one or more primitives (or other types of directives) present in the first virtual partition. The one or more primitives can 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] Additionally, or in some cases, flattening the graph can include generating a respective copy of each of all the customized assets, such as customized components or customized resources, or combinations thereof, within each of the respective first virtual partitions, and further holding such respective copies within a centrally managed virtual partition. The copies can be generated and held in the order of the graph, i.e., in the order in which references are made between virtual partitions within the graph, 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 holding such respective copies, the computing system can collect information identifying one or more conflicts that may exist between two or more copies of each customized asset. Thus, flattening the graph can include determining that a conflict exists between a first copy of each of the copies and a second copy of each of the copies. In response to such a determination, flattening the graph can also include determining a resolution to the conflict by applying a defined process based on one or more policies, as described herein. Further, or in other cases, before holding such respective copies, flattening the graph can also include determining that a conflict exists between a first copy of each of the copies and a second copy of each of the copies. In response to such a determination, flattening the graph can also include sending a report indicating the conflict. The report can be sent to a computing device or component that is functionally coupled to the computing system. Additionally, flattening the graph can include receiving resolution data defining a resolution to the conflict (e.g., from a computing device or component).

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

[0101] Additionally, or in other cases, generating one or more second computer-executable components can include accessing, from a second virtual partition, the abstraction data included in one or more computer-readable components. As described, the abstraction data can define human-readable content that indicates a manner of extending tenant-specific services, where the human-readable content has no program code or the human-readable content includes a limited amount of custom program code. In one example, the abstraction data can be formatted according to JavaScript object notation and held in a file or another type of data structure. Additionally, generating one or more second computer-executable components can also include accessing a code template. Further, generating one or more second computer-executable components can also include generating, based on the abstraction data and the code template, a first computer-executable component of the one or more second computer-executable components.

[0102] In block 1040, the computing system can hold one or more computer-executable components within a second data repository (e.g., data storage 630 (FIG. 6)) that can include the second virtual partition generated in block 1030. Note that the second data repository can be different from one or more other data repositories that each include a respective first virtual partition.

[0103] Implementing blocks 1020, 1025, 1030, 1035, and in some cases block 1040 together enables generating an extension module to customize a core codebase and a core platform associated with the first computer-executable component(s).

[0104] In some cases, as described herein, the generation of the second virtual partition may result in one or more modifications to the core codebase. The modifications can be, for example, the addition of program code (e.g., program code 684 (FIG. 6)) from one of the first virtual partitions. Thus, at block 1045, the computing system can determine whether the core codebase has been modified. In response to a negative determination (the "no" branch), the flow of the exemplary method 1000 can continue 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 can be specific to a particular tenant and can be, for example, the executable package component 694 (FIG. 6). The particular tenant can correspond to at least one of the first virtual partitions. The executable package component can be deployed as one of the package components 580 to a runtime subsystem (e.g., the runtime subsystem 560 (FIG. 5)) according to the aspects described herein. Alternatively, in response to an affirmative determination (the "yes" branch), the flow of the exemplary method 1000 can be directed to block 1055, where the computing system can generate one or more third computer-executable components using the modified core codebase. Then, at 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 can be specific to a particular tenant and can be, for example, the executable package component 694 (FIG. 6).

[0105] FIG. 11 is a flowchart of an exemplary method 1100 for expanding 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 can implement the exemplary method 1100 in whole or in part. For that purpose, each computing device of the computing devices includes computing resources that can implement at least one of the blocks included in the exemplary method 1100. Computing resources include, for example, a CPU, GPU, TPU, memory, disk space, incoming bandwidth, and / or outgoing bandwidth, interface(s) (e.g., I / O interface or API or both), controller device(s), power supply, combinations of the above, and / or similar resources. In one example, a system of computing devices can include programming interface(s), an operating system, software for configuring and / or controlling a virtualized environment, firmware, and similar resources. A system of computing devices can be referred to as a computing system.

[0106] In some cases, a computing system implementing the exemplary method 1100 can host, among other software modules, a generator component 762, a merger component 764, and a promotion component 766 (FIG. 7B). The computing system can implement the exemplary method 1100 by executing one or more instances of, for example, 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 can individually or in combination execute operations corresponding to the blocks of the exemplary method 1100, individually or in combination.

[0107] In block 1110, the computing system can generate a copy of the 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 services. The plurality of core modules individually or collectively have a set of extension points. 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 can 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 can apply an automated test to probe the integrity of the copy of the source program code having the added second extension point. Applying the automated test can include determining, based on control flow analysis, whether there are changes to the control flow of the program code that forms the copy of the source program code having at least one added second extension point. Note that exemplary method 1100 is not limited to a single automated test. In fact, in some cases, the computing system can apply multiple automated tests to probe the integrity of the modified copy of the source program code, either individually or in a specific combination.

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

[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 that purpose, in some embodiments, the computing system can include a compiler subsystem. In one example, the compiler subsystem can be embodied as, or can include, the compiler subsystem 796 (FIG. 7B). Building that second program code results in an executable package component. The executable package component includes a plurality of core modules including 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 extended extensibility. The executable package component provides a new service (or its functionality) that is common among 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 can apply a second automated test to probe the integrity of the operation of the executable package component. Applying the second automated test can include determining, based on control flow analysis, whether there are changes to control the flow of the executable package component with respect 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 can apply multiple second automated tests to probe the integrity of the modified copy of the source program code, individually or in a particular combination.

[0113] FIG. 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 a 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 the exemplary method 1200 in whole or in part. For that purpose, each computing device of the computing devices includes computing resources that may implement at least one of the blocks included in the exemplary method 1200. Computing resources include, for example, a CPU, a GPU, a TPU, memory, disk space, incoming bandwidth, and / or outgoing bandwidth, interface(s) (e.g., I / O interface or API or both), controller device(s), power supply, combinations of the above, and / or similar resources. In one example, a system of computing devices may include programming interface(s), an operating system, software for configuring and / or controlling a virtualized environment, firmware, and similar resources. The system of computing devices may be referred to as a computing system.

[0114] In some cases, a computing system implementing the exemplary method 1200 can host, among other software modules, a generator component 812, a test component 814, and a promotion component 816 (FIG. 8). The computing system can implement the exemplary method 1200, for example, by executing 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 can individually or in combination perform operations corresponding to the blocks of the exemplary method 1200, either individually or in combination.

[0115] In block 1210, the computing system can generate a copy of source program code corresponding to a service core that provides services common among single tenants. As described, the service can be referred to as a common service. The generated copy can be referred to as a fork, and the computing system can hold the fork in the forked codebase within the repository. The service core includes a plurality of core modules that provide defined services. The source program code corresponds to the plurality of 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 can include adding program code that defines new functionality, revising existing program code that defines existing functionality, or removing existing functionality (which may be referred to as deprecated). To modify a copy of the source program code, the computing system can 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 the program code). Additionally, the computing system can integrate the added program code and the 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 can apply an automated test to probe the integrity of the modified copy of the source program code. Applying the automated test can include determining, based on control flow analysis, whether there are changes to the control flow of the program code that forms the modified copy of the source program code. Exemplary method 1200 is not limited to a single automated test, and it should be noted that in some cases, the computing system can apply multiple automated tests that probe the integrity of the modified copy of the source program code, either individually or in a particular combination.

[0118] In some cases, the results of the automated tests may not be sufficient. In response, the computing system can implement one or more exception handling processes (not depicted in FIG. 12). In other cases, as illustrated in FIG. 12, one or more of the results of the automated tests are sufficient. In response, the flow of the exemplary method 1200 proceeds to block 1240, where the computing system 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 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 in accordance with the updated defined functionality. In some embodiments, generating the next version of the service core can include persisting the source program code corresponding to the next version of the service core as the core codebase and assigning a permanent unique identifier to the core base. The permanent unique identifier identifies the next version of the service core. Additionally, or in some embodiments, generating the next version of the service core can include incorporating safeguard code into the modified copy of the source program code to ensure that the existing logic resulting from the current (or otherwise previous) version of the service core remains unmodified by the updated defined functionality.

[0119] The upgraded service core continues to provide services that are common among single tenants, albeit according to updated defined functionality, and thus the integrity of the operation of the upgraded service core can be probed. Accordingly, in block 1250, the computing system can build a second source program code corresponding to the next version of the service core. For that purpose, in some embodiments, the computing system can include a compiler subsystem. In one example, the compiler subsystem can be embodied as, or include, compiler subsystem 796 (FIG. 8). Building that second program code results in an executable package component (e.g., a container, an executable binary file, or the like). The executable package component can include a plurality of core modules that are built and that individually or in combination provide the updated defined functionality. The executable package component can also include an API.

[0120] In addition, in block 1260, the computing system can apply a second automated test to probe the integrity of the operation of the executable package component. Applying the second automated test can include determining, based on control flow analysis, whether there are changes to the control flow of the executable package component with respect to the service core before the defined functionality of the service is updated. Again, exemplary method 1200 is not limited to a single automated test, and in some cases, the computing system can apply multiple second automated tests to probe the integrity of the operation of the executable package component, either individually or in a particular combination.

[0121] FIG. 13 illustrates an example of a computing system 1300 that can implement an extensible SaaS platform that provides services customized for each single tenant, according to an aspect of the present disclosure. The computing system 1300 includes examples of a plurality of compute server devices 1302 that are functionally coupled to each other by 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 in accordance with 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 the build subsystem 510 (FIG. 5). Additionally, or in some embodiments, at least another portion of the computing system 1300 can embody or include the runtime subsystem 560 (FIG. 5). Other portions of the computing system 1300 can embody or include the computing system 100 (FIG. 1). Further, or in still other embodiments, the computing system 1300 can also include the JITX subsystem 760 (FIG. 7B). Further, or in still other embodiments, the computing system 1300 can also include the upgrade subsystem 810 (FIG. 8).

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

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

[0124] Each compute server device of the compute server device 1302 can be a digital computer that, from a hardware architecture perspective, can include 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 can be implemented as, or include, one or more bus architectures, or other wired or wireless connections. The bus architecture(s) can be implemented as, or include, one or more of several 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 a variety of bus architectures. By way of example, such architectures can include an ISA bus, an MCA bus, an EISA bus, a VESA local bus, an AGP bus, a PCI bus, a PCI-Express bus, a PCMCIA bus, a USB, combinations thereof, and the like.

[0125] Additionally, or in some embodiments, communication interface 1313 can include additional elements, such as a controller device(s), buffer device(s) (e.g., cache), driver, repeater, transmitter device(s), and receiver device(s), which are omitted for simplicity to enable communication. Further, communication interface 1313 can include address, control, and / or data connections to enable proper communication among the aforementioned components.

[0126] Processor 1308 can be a hardware device that includes a processing circuit capable of executing software, particularly software 1317 stored in one or more memory devices 1316 (referred to as memory 1316). Additionally, or alternatively, the processing circuit can execute defined operations other than those defined by the software. Processor 1308 can be any custom-made or commercially available processor, an auxiliary processor among several processors associated with compute server device 1306, a semiconductor-based microprocessor (in the form of a microchip or chipset), or generally any device for executing software instructions or performing defined operations. By way of example, the processor can refer to a single-core processor, a single processor with software multithreading execution capability, a multi-core processor, a multi-core processor with software multithreading execution 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 compute server device 1306 is in operation, processor 1308 can execute software 1317 stored in memory 1316 to communicate data with, for example, memory 1316, and can be configured to generally control the operation of compute server device 1306 in accordance with software 1317 and aspects of the present disclosure.

[0128] I / O interface 1312 can be used to receive input data from and / or provide system output to one or more devices or components. The input data can be provided, for example, via a keyboard, touch screen display device, microphone, and / or mouse. The system output can be provided, for example, via a touch screen display device or another type of display device. I / O interface 1312 can 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, several, or all of the compute server devices 1302 that are external to the compute server device 1306 and are on one or more of the network(s) 1304. The network interface 1314 can also be used to transmit and receive data, metadata, and / or signaling from other types of devices that are external to the compute server device 1306 and are on one or more of the network(s) 1304. The network interface 1314 can 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 can include addresses, controls, and / or data connections to enable proper communication on the network(s) 1304.

[0130] The memory 1316 can include either 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, CDROM, DVDROM, etc.). The memory 1316 can also incorporate electronic, magnetic, optical, solid state, and / or other types of storage media. In some embodiments, the compute server device 1306 can access one or many of the storage server devices 1330.

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

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

[0133] Application programs, and other executable program components such as O / S 1319, are illustrated herein as separate blocks, but it is recognized that such programs and components may exist at various times in different storage components of computing server device 1306. The implementation of software 1315 can be stored in or transmitted via some form of computer-readable storage medium. At least a subset of computing server nodes 1302 can execute one or more instances of software 1315 by a processor 1308 present in each of computing server nodes 1302 to provide various functionalities described herein, for example, according to one or more embodiments of the present disclosure.

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

[0135] Client device 1346 can include one or more memory devices 1356 (referred to as memory 1346). Memory 1346 can have processor-accessible instructions encoded thereon. Processor-accessible instructions can include, for example, program instructions that are computer-readable and computer-executable.

[0136] The client device 1346 can also include one or more input / output (I / O) interfaces 1352 and a network interface 1354. The communication interface 1353 can functionally couple two or more of those functional elements of the client device 1346. The communication interface 1353 can 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 that uses any of a variety of bus architectures. By way of example, such architectures can comprise an ISA bus, an MCA bus, an EISA bus, a VESA local bus, an AGP bus, and buses such as PCI, PCI-Express bus, PCMCIA bus, USB bus, etc.

[0137] The functionality of the client device 1346 can be configured by computer-executable instructions (e.g., program instructions or program modules) executable by at least one of one or more processors 1348. A subset of the computer-executable instructions can embody a software application, such as a client application or another type of software application (e.g., an IDE, etc.). Such a subset can be arranged in a group of software components. The software components of the group of software components can include computer code, routines, objects, components, data structures (e.g., metadata objects, data objects, control objects), combinations thereof, etc., which can be configured (e.g., programmed) to perform a particular action or implement a particular 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 held in a processor-executable form within the memory 1355 or another type of machine-accessible non-transitory storage medium. The software application in processor-executable form can, for example, among other functional purposes, make the client device 1346 a particular machine for configuring or otherwise customizing tenant-specific services as described herein. The group of built software components that make up the processor-executable version of the software application can be accessed individually or in a particular combination and executed by at least one of the processor(s) 1348. In response to execution, the software application can provide the functionality described herein in relation to the configuration or other customization of tenant-specific services. Accordingly, the execution of the group of built software components held in the memory 1356 can cause the client device 1346 to operate in accordance with the manner described herein.

[0139] Data and processor-accessible instructions associated with particular functionality of the client device 1346 can be held in the memory 1356 within the functionality information 1358. In one aspect, the processor-accessible instructions can embody any number of components (such as program instructions and / or program modules) that provide particular functionality in response to execution by at least one of the processor(s) 1348. Although memory elements are illustrated herein as separate blocks, such memory elements as well as associated processor-accessible instructions and data can exist at various times in different storage elements (such as registers, files, memory addresses, etc., not shown) within the memory 1356.

[0140] Functional information 1358 can include a variety of data, metadata, or both, associated with the configuration of tenant-specific services or otherwise customized, according to the aspects described herein.

[0141] Memory 1356 can be embodied in a variety of computer-readable media. Examples of computer-readable media are accessible by a processor (such as one of the processors (plural) 1348) within a computing device and can be any available media, including, for example, volatile media, non-volatile media, removable media, non-removable media, or combinations of the above. As an example, computer-readable media can include "computer storage media" or "computer-readable storage media" and "communication media." Such storage media can be non-transitory storage media. "Computer storage media" includes volatile and non-volatile, removable and non-removable media implemented in any method or technology for storage of information such as computer-readable instructions, data structures, program modules, or other data. Exemplary computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory, or other memory technologies, CD-ROM, DVD, or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage devices, or other magnetic storage devices, or any other media that can be used to store the desired information and that can be accessed by a computer, or a processor within a computer, or a processor functionally coupled to the computer.

[0142] Memory 1356 can include a computer-readable non-transitory storage medium in the form of a volatile memory such as a RAM or an EEPROM, or in the form of a non-volatile memory such as a ROM. In one aspect, memory 1356 can be partitioned into a system memory (not shown) that can include data and / or program modules that enable the essential operation and control of computing device 1346. Such program modules can be implemented (e.g., compiled and stored) in memory element 1359, referred to as operating system 1359, whereas such data can be system data (not depicted in FIG. 13) held within system data storage. Operating system 1359 and system data storage can be made immediately accessible to and / or currently operable by at least one of processors (s) 1348. Operating system 1359 embodies an operating system for client device 1346. Such an O / S's specific implementation manner can depend partially on the complexity of the architecture of client device 1346. The higher the complexity, the higher level of O / S becomes possible. Exemplary operating systems can include iOS, Android, Windows operating systems.

[0143] Memory 1356 can include a removable / non-removable, volatile / non-volatile computer-readable non-transitory storage medium. As an example, memory 1356 can include a mass storage unit (not shown) that can provide non-volatile storage of computer code, computer-readable instructions, data structures, program modules, and other data for client device 1346. The particular implementation of such a mass storage unit (not shown) can 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) can 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), and the like.

[0144] Generally, a processor among one or more processors 1348 can refer to any computing processing unit or processing device including a single-core processor, a single-core processor with software multithreading execution ability, a multi-core processor, a multi-core processor with software multithreading execution ability, a multi-core processor with hardware multithreading technology, a parallel platform, and a parallel platform with distributed shared memory (e.g., cache). Additionally, or alternatively, a group of processors among one or more processors 1348 can refer to an integrated circuit with dedicated functionality such as an ASIC, a DSP, an FPGA, a CPLD, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. In one aspect, a processor referred to herein can optimize the spatial use of a computing device (e.g., improve the form factor) capable of implementing various aspects of the present disclosure, or utilize nanoscale architectures such as molecular and quantum dot-based transistors, switches, and gates to enhance performance. In another aspect, one or more processors 1348 can be implemented as a combination of computing processing units.

[0145] The client device can include, or be functionally coupled to, a display device (not depicted in FIG. 13) capable of displaying various user interfaces, at least partially in connection with the configuration of tenant-specific services or other customizations provided by software applications included in the 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 the like). 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 held in the memory 1356 by a processor (s) among the processor(s) 1348. In some embodiments, at least one I / O interface embodies an API that enables the exchange of data and / or signaling, or both, via the I / O interface. In some embodiments, one or more I / O interfaces 1352 can include at least one port that can enable a connection to another device or functional element of the client device 1346. In one or more scenarios, at least one port can include one or more of a parallel port (e.g., GPIB, IEEE-1284), a serial port (e.g., RS-232, Universal Serial Bus (USB), FireWire, or IEEE-1394), an Ethernet port, a V.35 port, a Small Computer System Interface (SCSI) port, and the like.

[0147] At least one I / O interface of one or more I / O interfaces 1352 can enable the delivery of an output (e.g., output data and / or output signaling, or both) to such a device or functional element. Such an output can represent the result of a specific operation or one or more operations described herein, such as the operation(s) performed in the exemplary methods described herein.

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

[0149] To provide additional context, the computer-implemented methods and systems of the present disclosure can be implemented on a computing system 1400 illustrated in FIG. 14 and described below. Similarly, the computer-implemented methods and systems disclosed herein can utilize one or more computing devices to perform one or more functions at one or more locations. FIG. 14 is a block diagram illustrating an example of a computing system 1400 for executing the disclosed methods and / or implementing the disclosed systems. The computing system 1400 shown in FIG. 14 is merely an example of an operating environment and is not intended to suggest any limitation as to the use or functionality scope of the operating environment architecture. Nor should the operating environment be interpreted as having any dependency or requirement related to any one or combination of components illustrated in the exemplary operating environment.

[0150] The computer-implemented methods and systems according to the present disclosure can operate in a number of other general-purpose or special-purpose computing system environments or configurations. Examples of well-known computing systems, environments, and / or configurations that may be suitable for use in 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 household appliances, network PCs, minicomputers, mainframe computers, and distributed computing environments including any of the above systems or devices.

[0151] The processing of the disclosed computer-implemented methods and systems can be performed by software components. The disclosed systems and computer-implemented methods can be described in a general context where computer-executable instructions are executed by one or more computers or other processing devices. Generally, program modules can include program code, routines, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. The disclosed computer-implemented methods can also be implemented in a grid-style distributed computing system where tasks are performed by remote computing devices linked through a communication network. In a distributed computing system, program modules can be located in both local computer storage media including memory storage devices and remote computer storage media.

[0152] Furthermore, the systems and computer-implemented 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 can include one or more processors 1403, a system memory 1412, and a system bus 1413 that functionally couples various system components including the one or more processors 1403 to the system memory 1412. The system can utilize parallel computing in some cases.

[0153] The system bus 1413 represents one or more of several possible types of bus structures, including a memory bus or memory controller, a peripheral bus, an accelerated graphics port, or a local bus, using any of a variety of bus architectures. The system bus 1413, and all buses specified herein, can be implemented via a wired or wireless network connection, and each of the subsystems including the 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, a system memory 1412, an input / output interface 1410, a display adapter 1409, a display device 1411, and a human machine interface 1402 can be physically located remotely and connected through a bus of this form, and can be included within one or more remote computing devices 1414a, b, c that effectively implement a fully distributed system.

[0154] Computing device 1401 typically includes a variety of computer-readable media. Examples of readable media can be any available media accessible by computing device 1401 and can include, for example, both volatile and non-volatile media, removable and non-removable media. 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). System memory 1412 typically includes data such as data 1407 and / or program modules such as operating system 1405 and software 1406, which are immediately accessible by and / or currently being operated on by one or more processors 1403.

[0155] Computing device 1401 can also include other removable / non-removable, volatile / non-volatile computer storage media. As an example, FIG. 14 illustrates a mass storage 1404 that can provide non-volatile storage of computer code, computer-readable instructions, data structures, program modules, and other data for computing device 1401. For example, mass storage 1404 can be embodied as or 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, by way of example, operating system 1405 and software 1406, can be stored in mass storage 1404. Each of operating system 1405 and software 1406 (or some combination thereof) can include elements of programming and software 1406. Data 1407 can also be stored in mass storage 1404. Data 1407 can be stored in any one or more databases. Examples of such databases include DB2®, Microsoft® Access, Microsoft® SQL Server, Oracle®, mySQL, PostgreSQL, and the like. The database 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 JITX subsystem 760 (FIG. 7B), and software 1406 can include components that form JITX subsystem 760. Additionally, or in other cases, computing device 1401 can host build subsystem 510, and software 1406 can include components that form build subsystem 510. Further, or in still other cases, computing device 1401 can host upgrade subsystem 810 (FIG. 8), and software 1406 can include components that form upgrade subsystem 810. Execution of software 1406 by processor(s) 1403 can cause computing device 1401 to provide at least some of the functionality described herein in connection with expanding the functionality and / or extension points 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 particular one of the computing devices, and other components of software 1406 can be localized to a second particular one of the computing devices. In such distributed embodiments, the computing system can embody or configure a query resolution subsystem 1414. In such embodiments, the execution of software 1406 by at least one processor present in the combination of computing device 1401 and remote computing devices 1414a, b, c can, as described herein, expand the functionality and / or extension points of the core platform for such a computing system, and / or build code modules and extension modules, and create executable package components, to provide at least some of the functionality described herein.

[0158] In another aspect, an end user can input commands and data into 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 haptic input device such as gloves and other body covers, and the like. These and other input devices can be connected to one or more processors 1403 via a human machine interface 1402 coupled to the system bus 1413, but can also 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 aspect, the display device 1411 can also be connected to the system bus 1413 via an interface such as the display adapter 1409. In some configurations, the computing device 1401 can have two or more display adapters 1409, and the computing device 1401 can have two or more display devices 1411. For example, the display device 1411 can be a monitor, an LCD (liquid crystal display), or a projector. In addition to the display device 1411, other output peripheral devices can include components such as a speaker (not shown) and a printer (not shown) that can be connected to the computing device 1401 via the input / output interface 1410. Any operation and / or result of the method can be output to the output device in any form. Such output can be any form of visual representation including, but not limited to, text, graphics, animation, audio, tactile, etc. Thus, the display device 1411 can present various user interfaces and other information (data, metadata, and / or configuration attributes) related to tenant-specific services. For example, the display device can present the UIs shown in FIGS. 4A and 4B, among other user interfaces. The display device 1411 and the computing device 1401 can be part of one device or separate devices.

[0160] 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 device can be a personal computer, a portable computer, a smartphone, a server, a router, a network computer, a peer device, or other common network nodes, etc. In some cases, one or more storage server devices 1420 can embody or configure storage server device 1330 (FIG. 13). The logical connection between computing device 1401 and remote computing devices 1414a, b, c and the server storage device(s) of server storage device(s) 1420 can be made via a network 1415 such as a local area network (LAN) and / or a general wide area network (WAN). Such network connections can be through network adapter 1408. 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 operating system 1405, are illustrated herein as separate blocks, but such programs and components may exist at various times in different storage components of computing device 1401 and be executed by one or more processors 1403 of the computer. Implementations of software 1406 can be stored on or transmitted via some form of computer-readable medium. Any of the disclosed methods can be implemented by computer-readable instructions embodied on a computer-readable medium. A computer-readable medium can be any available medium that can be accessed by a computer. As described herein, a "computer storage medium" includes volatile and nonvolatile, removable and nonremovable media implemented in any method or technology for storage of information such as computer-readable instructions, data structures, program modules, or other data.

[0162] Many other embodiments will occur to those of ordinary skill in the art upon considering the foregoing detailed description and the accompanying drawings. Example 1 of those embodiments includes a computing system including at least one processor executing computer-executable components stored on at least one memory device, the computer-executable components comprising a plurality of core modules configured to provide a defined service, the plurality of core modules including at least one extension point corresponding to a first core module of the plurality of core modules, a first extension point of the at least one extension point being mapped to a tenant-specific extension module that customizes the defined service. The computer-executable components also include an application programming interface API corresponding to a defined tenant and a data model corresponding to the defined tenant.

[0163] Example 2 of many embodiments further includes an API router component configured to receive a message in which a computer-executable component launches a function call for a customized defined service and includes an attribute identifying a defined tenant, the API router component redirects the function call to a customized defined service based on the attribute, and the API component publishes the API, including the computing system described in Example 1.

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

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

[0166] Example 5 of many embodiments includes the computing system described in Example 1, in which a first core module is configured to modify at least one of an existing data model or an existing API, resulting in one of at least a portion of the API or at least a portion of the data model.

[0167] Example 6 of many embodiments includes the computing system described in Example 1, in which a tenant-specific extension module is configured to provide at least one element to a data model, provide a function to an API, or provide at least one element to a data model and provide a function to an API.

[0168] Example 7 of many embodiments includes the computing system described in Example 1, wherein the tenant-specific extension module is configured to store a plurality of core functions that make up the API and further store a plurality of core elements that make up the data model.

[0169] Example 8 of many embodiments includes the computing system described in Example 1, wherein the tenant-specific extension module is configured to remove a specific core function among the plurality of core functions that make up the API and store a plurality of core elements that make up the data model.

[0170] Example 9 of many embodiments includes the computing system described in Example 1, wherein the tenant-specific extension module is configured to store a plurality of core functions that make up the API and remove a specific core element among the plurality of core elements that make up the data model.

[0171] Example 10 of many embodiments further includes at least one second memory device storing a non-transitory memory structure dedicated to a defined tenant, the non-transitory memory structure comprising one or more of configuration attributes, program code defining extension logic, or a plurality of tenant-specific extension modules, and includes the computing system described in Example 1.

[0172] Example 11 of many embodiments includes the computing system described in Example 10, wherein the non-transitory memory structure includes one of a file system, a file folder, a database, or a table.

[0173] Example 12 of many embodiments includes the computing system described in Example 10, wherein each tenant-specific extension module of the plurality of tenant-specific modules stores core elements that make up the data model and further stores a plurality of core functions that make up the API.

[0174] Example 13 of many embodiments includes the computing system described in Example 10, where a selected tenant-specific module among a plurality of tenant-specific modules causes one or more breaking modifications to either a core API corresponding to a defined service or a core data model corresponding to a data model, resulting in breaking the backward compatibility between the customized defined service and the defined service.

[0175] Example 14 of many embodiments includes the computing system of Example 10, where the non-transitory memory structure further includes definition data for identifying tenant-specific services, configuration data corresponding to tenant-specific services, and metadata corresponding to tenant-specific services.

[0176] Example 15 of many embodiments includes the computing system described in Example 10, where the non-transitory memory structure further includes definition data for identifying extension points, and the definition data includes first data for identifying the domain of the extension point, second data for identifying the functionality corresponding to the extension point, a description of the extension point identifying one or more methods corresponding to the extension point, input parameters of the extension point, and output types corresponding to the extension point.

[0177] Example 16 of many embodiments includes the computing system described in Example 10, where the non-transitory memory structure further includes abstraction data defining human-readable content indicating a manner in which tenant-specific services are extended, and where the human-readable content either has no program code or includes snippets of custom program code.

[0178] Example 17 of many embodiments includes the computing system described in Example 10, where at least one second memory device further stores a second non-transitory memory structure associated with one or more tenants, and the second non-transitory memory structure includes one or more of second configuration attributes, second program code defining extension logic, or a plurality of extension modules.

[0179] Example 18 of many embodiments includes the computing system described in Example 17, in which the non - transient memory structure and the second non - transient memory structure are logically configured in a hierarchical structure.

[0180] Example 19 of many embodiments includes the computing system described in Example 18, which includes a graph in which the hierarchical structure has a first node representing the non - transient memory structure and a second node representing the second non - transient memory structure.

[0181] Example 20 of many embodiments includes the computing system described in Example 18, in which the hierarchical structure includes a tree structure, the first node representing the non - transient memory structure is the root node, and the second node representing the second non - transient memory structure is a leaf node.

[0182] Example 21 of many embodiments includes the computing system described in Example 10, in which at least one memory device includes permission attributes configured to grant exclusive access to a customized defined service to a defined tenant.

[0183] Example 22 of many embodiments includes a computer - implemented method that includes generating a copy of source program code corresponding to a plurality of core modules that provide a defined service, where the plurality of core modules includes at least one first extension point corresponding to a first core module among the plurality of core modules. The computer - implemented method also includes adding at least one second extension point to at least one first extension point in the copy of the source program code, where the at least one second extension point is unique to a defined tenant.

[0184] Example 23 of many embodiments 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, and includes the computer-implemented method described in Example 22.

[0185] Example 24 of many embodiments includes the computer-implemented method described in Example 23, wherein applying an automated test includes determining whether there are changes to the control flow of program code that forms a copy of source program code having at least one additional second extension point, based on control flow analysis.

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

[0187] Example 26 of many embodiments includes the computer-implemented method described in Example 25, wherein generating a next version of a plurality of core modules includes integrating at least one additional second extension point into the current version of the plurality of core modules.

[0188] Example 27 of many embodiments further includes building second program code corresponding to at least a next version of a plurality of core modules having at least one additional second extension point, resulting in an executable package component that includes the plurality of core modules including at least one additional second extension point, and includes the computer-implemented method described in Example 25.

[0189] Example 28 of many embodiments further includes applying an automated test to probe the integrity of the executable package component, and includes the computer-implemented method described in Example 27.

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

[0191] Example 30 of many embodiments includes the computing system described in Example 29, wherein one or more memory devices store further computer-executable instructions that, in response to further execution by the one or more processors, cause the computing system to further apply an automatic test to probe the integrity of a copy of source program code having at least one added second extension point.

[0192] Example 31 of many embodiments includes the computing system described in Example 29, wherein applying the automatic test includes determining, based on control flow analysis, whether there are changes to the control flow of program code that forms a copy of source program code having at least one added second extension point.

[0193] Example 32 of many embodiments includes the computing system described in Example 29, wherein one or more memory devices store further computer-executable instructions that, in response to further execution by the one or more processors, cause the computing system to further generate a next version of the plurality of core modules based on a current version of the plurality of core modules and a copy of source program code having at least one added second extension point.

[0194] Example 33 of many embodiments includes the computing system described in Example 29, which stores further computer-executable instructions for causing one or more memory devices to, in response to further execution by one or more processors, build further second program code corresponding to at least the next version of a plurality of core modules having at least one additional second extension point for the computing system and to provide an executable package component comprising the plurality of core modules including the at least one additional second extension point.

[0195] Example 34 of many embodiments includes the computing system described in Example 29, which stores further computer-executable instructions for causing one or more memory devices to, in response to further execution by one or more processors, further apply an automated test to probe the integrity of an executable package component for the computing system.

[0196] At least one non-transitory computer-readable storage medium having encoded processor-executable instructions for causing an operation to be performed, the operation including: generating a copy of source program code corresponding to a plurality of core modules that provide a defined service to one or more computing devices in response to execution, the plurality of core modules including at least one first extension point corresponding to a first core module of the plurality of core modules; and adding at least one second extension point to the at least one first extension point in the copy of the source program code, the at least one second extension point being unique to a defined tenant.

[0197] At least one non-transitory computer-readable storage medium according to Example 35, wherein the operation further includes applying an automated test to probe the integrity of a copy of the source program code having at least one additional second extension point.

[0198] Example 37 of many embodiments includes at least one non - transitory computer - readable storage medium as described in Example 36, wherein applying an automated test includes determining whether there is a change to the control flow of the program code that forms a copy of the source program code having at least one additional second extension point based on control flow analysis.

[0199] Example 38 of many embodiments includes at least one non - transitory computer - readable storage medium as described in Example 35, wherein the operation further includes generating the next version of a plurality of core modules based on the current versions of the plurality of core modules and a copy of the source program code having at least one additional second extension point.

[0200] Example 39 of many embodiments includes at least one non - transitory computer - readable storage medium as described in Example 38, wherein generating the next version of the plurality of core modules includes integrating at least one additional second extension point into the current versions of the plurality of core modules.

[0201] Example 40 of many embodiments includes at least one non - transitory computer - readable storage medium as described in Example 38, wherein the operation further includes building second program code corresponding to at least the next version of a plurality of core modules having at least one additional second extension point, resulting in an executable package component comprising the plurality of core modules including at least one additional second extension point.

[0202] Example 41 of many embodiments includes at least one non - transitory computer - readable storage medium as described in Example 40, wherein the operation further includes applying an automated test that probes the integrity of the executable package component.

[0203] Example 42 of many embodiments is a computer-implemented method that includes identifying a group of one or more references to each first virtual partition, wherein the group of one or more references defines a graph representing the logical composition of each first virtual partition, and the graph includes a first node representing the first first virtual partition of each first virtual partition and a second node representing the second first virtual partition of each first virtual partition. The computer-implemented method also includes determining that the group of one or more references meets a consistency criterion. The computer-implemented 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 first virtual partition. Flattening includes applying one or more primitives present in at least one of each first virtual partition in the order of the graph. The computer-implemented method still further includes generating one or more computer-executable components based on the one or more computer-readable components.

[0204] Example 43 of many embodiments further includes 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, the computer-implemented method described in Example 42.

[0205] Example 44 of many embodiments further includes 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, the computer-implemented method described in Example 42.

[0206] Example 45 of many embodiments includes the computer-implemented method of Example 42, where one or more computer-readable components include abstraction data that defines human-readable content that defines a manner of extending tenant-specific services, and where the human-readable content has no program code or the human-readable content includes snippets of program code.

[0207] Example 46 of many embodiments includes the computer-implemented method of Example 45, where generating one or more computer-executable components based on one or more computer-readable components includes converting human-readable content into at least one program code artifact and building at least one specific computer-executable component of the one or more computer-executable components using the at least one program code artifact.

[0208] Example 47 of many embodiments includes the computer-implemented method of Example 42, where generating one or more computer-executable components based on one or more computer-readable components includes accessing abstraction data from a second virtual partition, accessing a code template, and generating a first computer-executable component of the one or more computer-executable components based on the abstraction data and the code template.

[0209] Example 48 of many embodiments includes the computer-implemented method of Example 44, where the second virtual partition forms part of a data repository and each first virtual partition forms part of a second data repository.

[0210] Example 49 of many embodiments includes the computer-implemented method described in Example 42, where the first reference of the reference group includes a unique location identifier indicating the location of a specific virtual partition among each of the first virtual partitions within a computer network, and further includes data identifying the version of the specific virtual partition.

[0211] Example 50 of many embodiments includes the computer-implemented method described in Example 49, where the unique location identifier includes a Uniform Resource Locator (URL), and the version corresponds to a persistent unique identifier indicating the immutable content that forms the specific virtual partition at a defined time.

[0212] Example 51 of many embodiments includes the computer-implemented method described in Example 42, where flattening includes generating a copy of each of the constituent assets within each of the first virtual partitions and retaining each copy within the second virtual partition in graph order.

[0213] Example 52 of many embodiments further includes the computer-implemented method described in Example 51, where flattening includes determining that a conflict exists between a first copy and a second copy of each of the copies, and determining a resolution to the conflict by applying a defined process based on one or more policies.

[0214] Example 53 of many embodiments further includes the computer-implemented method described in Example 51, where flattening includes determining that a conflict exists between a first copy and a second copy of each of the copies, sending a report indicating the conflict (e.g., to a computing device or component), receiving resolution data defining a resolution to the conflict (e.g., from a computing device or component), and resolving the conflict by applying the resolution.

[0215] Example 54 of many embodiments is a computing system including one or more processors and one or more memory devices, wherein the one or more memory devices, in response to execution by the one or more processors, cause the computing system to identify a group of one or more references to each of the first virtual partitions that define a graph representing the logical organization of the respective first virtual partitions, the graph including 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, determine that the group of one or more references meets a consistency criterion, and generate a second virtual partition including one or more computer-readable components present in each of the first virtual partitions by flattening the graph, where flattening includes applying one or more primitives present in at least one of each of the first virtual partitions in the order of the graph, and generate one or more computer-executable components based on the one or more computer-readable components, and includes a computing system storing computer-executable instructions.

[0216] Example 55 of many embodiments includes the computing system described in Example 54, wherein the one or more memory devices, in response to further execution by the one or more processors, cause the computing system to further generate executable package components by combining one or more computer-readable components with second computer-executable components corresponding to a group of core modules, and store further computer-executable instructions.

[0217] Example 56 of many embodiments includes the computing system described in Example 54, which stores further computer-executable instructions for causing one or more memory devices to cause a computing system to hold, in a data repository, one or more computer-executable components including at least one tenant-specific extension module in response to further execution by one or more processors.

[0218] Example 57 of many embodiments includes the computing system described in Example 54, in which one or more computer-readable components include abstraction data that defines human-readable content that defines a manner of extending tenant-specific services, where the human-readable content has no program code or the human-readable content includes snippets of program code.

[0219] Example 58 of many embodiments includes the computing system described in Example 57, in which generating one or more computer-executable components based on one or more computer-readable components includes converting human-readable content into at least one program code artifact and building at least one specific computer-executable component of the one or more computer-executable components using the at least one program code artifact.

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

[0221] Example 60 of many embodiments includes the computing system described in Example 56, where a second virtual partition forms part of a data repository and each first virtual partition forms part of a second data repository.

[0222] Example 61 of many embodiments further includes the computing system described in Example 54, where flattening includes generating a respective copy of each constituent asset within each first virtual partition and retaining each copy within the second virtual partition in graph order.

[0223] Example 62 of many embodiments further includes the computing system described in Example 61, where flattening includes determining that a conflict exists between a first copy and a second copy of each copy and determining a resolution to the conflict by applying a defined process based on one or more policies.

[0224] Example 63 of many embodiments further includes the computing system described in Example 61, where flattening includes determining that a conflict exists between a first 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 resolution to the conflict (e.g., from a computing device or component), and resolving the conflict by applying the resolution.

[0225] Example 64 of many embodiments is at least one non-transitory computer-readable storage medium that, in response to execution, causes a computing system to identify a group of one or more references to each first virtual partition that defines a graph representing the logical organization of each first virtual partition, the graph including a first node representing a first first virtual partition of each first virtual partition and a second node representing a second first virtual partition of each first virtual partition, determines that the group of one or more references meets a consistency criterion, and by flattening the graph, generates a second virtual partition including one or more computer-readable components present in each first virtual partition, flattening including applying one or more primitives present in at least one of each first virtual partition in the order of the graph, and generates one or more computer-executable components based on the one or more computer-readable components, and includes at least one non-transitory computer-readable storage medium having encoded processor-executable instructions.

[0226] Example 65 of many embodiments includes at least one non-transitory computer-readable storage medium as described in Example 64, wherein processor-executable instructions, in response to further execution, cause a computing system to further generate an executable package component by combining one or more computer-readable components with second computer-executable components corresponding to a group of core modules.

[0227] Example 66 of many embodiments includes at least one non-transitory computer-readable storage medium as described in Example 64, wherein processor-executable instructions, in response to further execution, cause a computing system to further hold one or more computer-executable components in a data repository, and the one or more computer-executable components include at least one tenant-specific extension module.

[0228] Example 67 of many embodiments includes at least one non - transitory computer - readable storage medium as described in Example 64, wherein one or more computer - readable components include abstraction data that defines human - readable content that defines a manner of extending tenant - specific services, and the human - readable content either has no program code or the human - readable content includes snippets of program code.

[0229] Example 68 of many embodiments includes at least one non - transitory computer - readable storage medium as described in Example 67, wherein generating one or more computer - executable components based on one or more computer - readable components includes converting human - readable content into at least one program - code artifact and using the at least one program - code artifact to build at least one specific computer - executable component among the one or more computer - executable components.

[0230] Example 69 of many embodiments includes at least one non - transitory computer - readable storage medium as described in Example 64, wherein generating one or more computer - executable components based on one or more computer - readable components includes accessing abstraction data from a second virtual partition, accessing a code template, and generating a first computer - executable component among the one or more computer - executable components based on the abstraction data and the code template.

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

[0232] Example 71 of many embodiments includes at least one non-transitory computer-readable storage medium as described in Example 64, wherein the first reference of the reference group includes a unique location identifier indicating the location of a specific virtual partition among each of the first virtual partitions, and further includes data identifying the version of the specific virtual partition.

[0233] Example 72 of many embodiments includes at least one non-transitory 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 the immutable content forming the specific virtual partition at a defined time.

[0234] Example 73 of many embodiments includes at least one non-transitory computer-readable storage medium as described in Example 64, wherein flattening includes generating a respective copy of the constituent assets within each of the first virtual partitions and retaining the respective copies within the second virtual partition in graph order.

[0235] Example 74 of many embodiments further includes at least one non-transitory computer-readable storage medium as described in Example 73, wherein flattening further includes determining that there is a conflict between a first copy among the respective copies and a second copy among the respective copies, and determining a resolution to the conflict by applying a defined process based on one or more policies.

[0236] Example 75 of many embodiments further includes determining that there is a conflict 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 a computing device), and resolving the conflict by applying the solution, and includes at least one non-transitory computer-readable storage medium described in Example 73.

[0237] It should be understood that the methods and systems described herein are not limited to the specific operations, processes, components, or structures described, nor are they limited to the order or specific combination of such operations or components as described. It should also be understood that the terms used herein are for the purpose of describing exemplary embodiments only and are not intended to be restrictive or limiting.

[0238] As used herein, the singular forms "a", "an", and "the" include both singular and plural referents unless the context clearly dictates otherwise. Values expressed as approximations by use of a preamble such as "about" or "approximately" are to include reasonable variations from the reference value. When such approximations are included in a range, not only are the endpoints considered approximations, but the magnitude of the range is also considered an approximation. Enumerations are to be considered illustrative, and the elements constituting the enumeration or the order in which the elements are enumerated are not limited or restricted unless the context explicitly dictates otherwise.

[0239] Throughout the specification and claims of this disclosure, the following terms have the meanings as described: "comprise", and variations such as "comprising" and "comprises" mean, for example, including, but not limited to, other additives, components, elements, or operations, and are not intended to exclude these. Variations such as "include" and "including" do not mean being limited or restricted to what is shown as being included, or intending to exclude what is not shown. "May" means permissive but not restrictive or limiting. "Optional" or "optionally" means that something may or may not be included without changing the result or what is described. Variations such as "prefer", "preferred" or "preferably" are illustrative and mean more ideal but not essential. "Such as" means serving merely as an example.

[0240] The operations and components described herein for use in performing the disclosed methods and constructing the disclosed systems are illustrative unless the context explicitly indicates otherwise. When combinations, subsets, interactions, groups, etc. of these operations and components are disclosed, specific references to each of their various individual and collective combinations and permutations may not be explicitly disclosed, but each is to be understood as being specifically contemplated and described herein for all methods and systems. This applies to all aspects of this application, including, but not limited to, the operations in the disclosed methods and / or the components disclosed in the systems. Thus, if there are various additional operations that can be performed or components that can be added, each of these additional operations 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 the present disclosure can take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment combining software aspects and hardware aspects. Further, the method and system can take the form of a computer program product on a computer-readable storage medium having computer-readable program instructions (e.g., computer software) embodied in a memory medium. Any suitable computer-readable storage medium, including a hard disk, CD-ROM, optical storage device, or magnetic storage device, can be utilized, whether internal, 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-implemented methods, systems, apparatuses, and computer program products. Each block of the block diagrams and flowchart illustrations, and combinations of blocks in the block diagrams and flowchart illustrations, can be implemented by processor-accessible instructions. Such instructions can include, for example, computer program instructions (e.g., processor-readable and / or processor-executable instructions). The processor-accessible instructions can be built (e.g., linked and compiled) and held in processor-executable form in one or more memory devices, or in one or more other processor-accessible non-transitory storage media. These computer program instructions (whether built or otherwise) can be loaded onto a general purpose computer, a special purpose computer, or other programmable data processing apparatus to produce a machine. The loaded computer program instructions can be accessed and executed by one or more processors or other types of processing circuitry. In response to execution, the loaded computer program instructions provide the functionality described in connection with the flowchart blocks (individually or in particular combinations) or the blocks in the block diagrams (individually or in particular combinations). Accordingly, such instructions, when executed on a computer or other programmable data processing apparatus, create means for implementing the functions specified in the flowchart blocks (individually or in particular combinations) or the blocks in the block diagrams (individually or in particular combinations).

[0243] These computer program instructions can also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, whereby the instructions stored in the computer-readable memory generate a manufactured article including processor-accessible instructions (e.g., processor-readable instructions and / or processor-executable instructions) for implementing the functions specified in the flowchart blocks (individually or in a particular combination) or in the blocks of the block diagram (individually or in a particular combination). The computer program instructions (whether built-in or otherwise) can also be loaded onto a computer or other programmable data processing apparatus to cause a series of operations to be performed on the computer or other programmable apparatus to generate a computer-implemented process. The series of operations can be executed in response to execution by one or more processors or other types of processing circuitry. Accordingly, such instructions executed on a computer or other programmable apparatus provide operations for implementing the functions specified in the flowchart blocks (individually or in a particular combination) or in the blocks of the block diagram (individually or in a particular combination).

[0244] Accordingly, the blocks in the block diagrams and flowchart illustrations support combinations of means for performing the specified functions associated with such diagrams and / or flowchart illustrations, combinations of operations for performing the specified functions, and program instruction means for implementing the specified functions. Each block of the block diagrams and flowchart illustrations, as well as combinations of blocks in the block diagrams and flowchart illustrations, can be implemented by a dedicated hardware system that performs the specified functions or operations, or combinations thereof, or by a system based on dedicated hardware and computer instructions.

[0245] As used in this specification and the accompanying drawings, terms such as "module", "component", "system", "platform", etc. can refer to a computer-related entity having one or more specific functionalities, or an entity related to an operating machine, and / or can include them. Such an entity can be any of hardware, a combination of hardware and software, software (e.g., program code or executable program code), or software in execution. In one example, a component can be a processor, a processor, an object, an executable file (e.g., binary software), an execution thread, a computer program, and / or a process executed on a computing device. By way of illustration only, a software application executed on a server device can be a component, and the server device can also be a component. One or more modules can exist within a process and / or an execution thread. One or more components can also exist within a process and / or an execution thread. Each of a module and a component can be localized on one computing device and / or can be distributed among two or more computing devices. In another example, each component (or module) can be executed 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 following a signal having one or more data packets (e.g., data from one component interacting with other systems within a local system, within a distributed system, and / or via a network such as the Internet). As another illustration, in some cases, a component can emulate electronic components via a virtual machine, for example, within a cloud computing system. The terms "module" and "component" (and plural versions thereof) can, in some cases, be used interchangeably where the context is clear.

[0246] As used in this specification and the accompanying drawings, the term "processor" can refer to substantially any computing processing unit or computing device, including a single-core processor, a single processor with software multithreading capabilities, a multi-core processor, a multi-core processor with software multithreading capabilities, a multi-core processor with hardware multithreading technology, a parallel platform, and a parallel platform with distributed shared memory. Additionally, a processor can refer to an electronic circuit designed and integrated to execute code instructions and / or manipulate data and signaling. Such an electronic circuit can be integrated, for example, into a chipset. Thus, in some cases, a processor can embody or include an application-specific integrated circuit (ASIC), a digital signal processor (DSP), a field-programmable gate array (FPGA), a complex programmable logic device (CPLD), discrete gates or transistor logic, discrete hardware components, or any combination thereof designed and integrated to perform the functionality described herein. Further, in some cases, a processor can utilize nanoscale architectures such as molecular and quantum dot-based transistors, switches, and gates to optimize space usage or enhance the performance of a 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 related to the operation and functionality of systems, subsystems, modules, and components are used to refer to an entity embodied by a "memory component", "memory", or a component that includes a memory. As described herein, the memory and / or memory component of the present disclosure can be either volatile memory or non-volatile memory, or can include both volatile memory and non-volatile memory. By way of example only, non-volatile memory can 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 can include, for example, RAM that can act as an external cache memory. By way of illustration and not limitation, RAM is available in many forms such as synchronous RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDR SDRAM), extended SDRAM (ESDRAM), synchlink DRAM (SLDRAM), direct Rambus (DRRAM), direct Rambus dynamic RAM (DRDRAM), and Rambus dynamic RAM (RDRAM). Embodiments of the present disclosure are not limited to these types of memory, and other types of memory devices can be contemplated.

[0248] Methods, apparatuses, devices, and systems can 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 inference rules generated through neural networks, or generation rules from statistical learning).

[0249] The computer-implemented methods, apparatuses, devices, and systems have been described in connection with preferred embodiments and specific examples, but the embodiments herein are intended in all respects to be illustrative rather than restrictive, and thus are not intended to limit the scope to the specific embodiments described.

[0250] Unless expressly stated otherwise, no method described herein is intended to be construed as requiring that its acts be performed in a particular order. Accordingly, where a method claim does not recite the order of acts to be followed or where it is not specifically recited in the claims or the specification that the acts are to be limited to a particular order, no inference of order is intended in any respect. This holds for any possible implicit basis for interpretation, including the arrangement of acts or act flows, the plain meaning derived from the grammatical construction or punctuation, and the logical matters related 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 be apparent to those skilled in the art from consideration of the specification and practices disclosed herein. The specification and examples are considered illustrative only, and the true scope and spirit are intended to be indicated by the following claims.

Claims

**Claim 1** A computing system comprising at least one processor for executing computer-executable components stored in at least one memory device, the computer-executable components comprising a plurality of core modules configured to provide a defined service, the plurality of core modules including at least one extension point corresponding to a first core module of the plurality of core modules, a first extension point of the at least one extension point being mapped to a tenant-specific extension module that customizes the defined service for a defined tenant, the plurality of core modules; an application programming interface (API) corresponding to the defined tenant; and a data model corresponding to the defined tenant. **Claim 2** The computing system of claim 1, wherein the computer-executable components further comprise an API router component configured to receive a message that initiates a function call to the customized defined service and includes an attribute that identifies the defined tenant, the API router component further configured to redirect the function call to the customized defined service based on the attribute, and the API component exposes the API. **Claim 3** The computing system of 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 of the plurality of core modules is configured to provide at least one second element to the data model. **Claim 4** The computing system of claim 1, wherein the first core module is configured to provide at least one first function to the API and a second core module of the plurality of core modules is configured to provide at least one second function to the API. **Claim 5** 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, resulting in one of at least a portion of the API or at least a portion of the data model.

6. 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, provide a function to the API, or provide the at least one element to the data model and the function to the API.

7. 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.

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

9. 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 remove a specific core element among a plurality of core elements constituting the data model.

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

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

12. The computing system according to claim 10, 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.

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

14. The computing system according to claim 10, wherein the non-transitory memory structure further includes definition data for identifying tenant-specific services, configuration data corresponding to the tenant-specific services, and metadata corresponding to the tenant-specific services.

15. The non-transitory memory structure further includes definition data for identifying an extension point, and the definition data includes first data for identifying the domain of the extension point, second data for identifying the functionality corresponding to the extension point, and a description of the extension point identifying one or more methods corresponding to the extension point, input parameters of the extension point, and output types corresponding to the extension point. The computing system according to claim 10.

16. The non-transitory memory structure further includes abstraction data for defining human-readable content indicating a manner of extending tenant-specific services, and the human-readable content either has no program code or includes snippets of custom program code. The computing system according to claim 10.

17. The at least one second memory device further stores a second non-transitory memory structure associated with one or more tenants, and the second non-transitory memory structure includes one or more of second configuration attributes, second program code for defining extension logic, or a plurality of extension modules. The computing system according to claim 10.

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

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

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

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

22. A computer-implemented method, comprising: generating a copy of source program code corresponding to a plurality of core modules that provide a defined service, wherein the plurality of core modules includes 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 unique to a defined tenant.

23. The computer-implemented method according to claim 22, further comprising applying an automated test to probe the integrity of the copy of the source program code having the at least one added second extension point.

24. The applying of the automated test includes, based on control flow analysis, determining whether there is a change to the control flow of the program code that forms the copy of the source program code having the at least one added second extension point, according to claim 23.

25. The computer-implemented method according to claim 22, 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 at least one added second extension point.

26. The generating of the next version of the plurality of core modules includes integrating at least the at least one added second extension point into the current version of the plurality of core modules, according to claim 25.

27. Building second program code corresponding to at least the next version of the plurality of core modules having the at least one added second extension point, and further including providing an executable package component including the plurality of core modules including the at least one added second extension point, the computer-implemented method according to claim 25.

28. The computer-implemented method according to claim 27, further including applying an automated test to probe the integrity of the executable package component.

29. A computing system comprising: One or more processors; One or more memory devices storing computer-executable instructions that, in response to execution by the one or more processors, cause the computing system to execute the method according to any one of claims 22 to 28.

30. A computer-implemented method comprising: Identifying a group of one or more references to respective first virtual partitions, the group of one or more references defining a graph representing a logical composition of the respective first virtual partitions, the graph including a first node representing a first first virtual partition of the respective first virtual partitions and a second node representing a second first virtual partition of the respective first virtual partitions; Determining that the group of one or more references meets a consistency criterion; Generating a second virtual partition by flattening the graph, the second virtual partition including one or more computer-readable components present in the respective first virtual partitions, the flattening including applying one or more primitives present in at least one of the respective first virtual partitions in graph order; Generating one or more computer-executable components based on the one or more computer-readable components.

31. The computer-implemented method of claim 30, further comprising generating an executable package component by combining the one or more computer-readable components with a second computer-executable component corresponding to a group of core modules.

32. The computer-implemented method of claim 30, further comprising holding the one or more computer-executable components in a data repository, wherein the one or more computer-executable components comprise at least one tenant-specific extension module.

33. The computer-implemented method of claim 30, wherein the one or more computer-readable components comprise abstracted data defining human-readable content defining a manner of extending tenant-specific services, and wherein the human-readable content has no program code or the human-readable content comprises snippets of program code.

34. Based on the one or more computer-readable components, generating the one or more computer-executable components comprises converting the human-readable content into at least one program code artifact, and using the at least one program code artifact to build at least one specific computer-executable component of the one or more computer-executable components.

35. Based on the one or more computer-readable components, generating the one or more computer-executable components comprises accessing the abstracted data from the second virtual partition, accessing a code template, and generating a first computer-executable component of the one or more computer-executable components based on the abstracted data and the code template.

36. The computer-implemented method of claim 32, wherein the second virtual partition forms part of the data repository and each first virtual partition forms part of a second data repository.

37. The computer-implemented method according to claim 30, wherein a first reference of the group of references includes a unique location identifier indicating a location of a specific virtual partition among the respective first virtual partitions within a computer network, and further includes data identifying a version of the specific virtual partition.

38. The computer-implemented method according to claim 37, wherein the unique location identifier includes a Uniform Resource Locator (URL), and the version corresponds to a persistent unique identifier indicating invariant content forming the specific virtual partition at a defined time.

39. Said flattening comprises generating respective copies of the constituent assets within each of said respective first virtual partitions; and holding said respective copies within said second virtual partition in graph order. The computer-implemented method according to claim 30, further comprising.

40. Said flattening comprises determining that a conflict exists between a first copy of said respective copies and a second copy of said respective copies; and determining a resolution to said conflict by applying a defined process based on one or more policies. The computer-implemented method according to claim 39, further comprising.

41. Said flattening comprises determining that a conflict exists between a first copy of said respective copies and a second copy of said respective copies; and sending a report indicating said conflict; and receiving resolution data defining a resolution to said conflict; and resolving said conflict by applying said resolution. The computer-implemented method according to claim 40, further comprising.

42. A computing system, comprising: one or more processors; and one or more memory devices storing computer-executable instructions that, in response to execution by said one or more processors, cause said computing system to execute the method according to any one of claims 30 to 41. A computing system.

43. At least one non-transitory computer-readable storage medium having processor-executable instructions encoded thereon, the processor-executable instructions, in response to execution, causing a computing system to execute the method according to any one of claims 30 to 41.

Images