Abstraction across multiple cloud-native data stores

Abstract

A unified data model is obtained, wherein the unified data model provides a logical view of multiple data structures of a computing platform, wherein the computing platform communicates with multiple cloud service providers, each providing corresponding storage services to the computing platform. An abstraction layer is provided, wherein the abstraction layer maps corresponding attributes of the unified data model to corresponding attributes of each of the multiple cloud service providers. A first storage scheme of a first cloud service provider among the multiple cloud service providers is selected through the abstraction layer. A first input is received from the user. Responding to the first input and based on the mapping between the corresponding attributes of the unified data model and the corresponding attributes of the first cloud service provider, the first input is converted into a first storage instruction set native to the first cloud service provider, wherein execution of the first storage instruction set results in a first logical view of the data structures of the computing platform. The abstraction layer seamlessly and dynamically switches from the first storage scheme to a second storage scheme of a second cloud service provider among the multiple different cloud service providers without notifying the user. A second input is received from the user, wherein the second input is the same as the first input. The abstraction layer responds to the second input and, based on the mapping between the corresponding attributes of the unified data model and the corresponding attributes of the second cloud service provider, converts the second input into a second storage instruction set native to the second cloud service provider. Execution of the second storage instruction set causes a second result logical view of the corresponding data structure of the computing platform, wherein the second result logical view is the same as the first result logical view.

Description

Background Technology

[0001] Computing systems routinely store and process massive amounts of data. Processing such large amounts of data consumes significant computing resources (e.g., memory, processing speed, and network bandwidth). Computing systems are also typically very inefficient and wasteful of computing resources when processing such large amounts of data. Cloud service providers can provide and manage massive amounts of storage. However, traditional computing systems are configured to work with only a single cloud service provider, which can limit the functionality of the computing system and / or reduce its computational efficiency. Attached Figure Description

[0002] Figure 1 The connected data platform is described.

[0003] Figure 2 The environment for integrating the central nervous system is described.

[0004] Figure 3 A three-layer model is depicted in some embodiments.

[0005] Figure 4 This is a diagram showing some examples of entity types, relationship types, and event metadata.

[0006] Figure 5 A flowchart facilitating dynamic matching is depicted.

[0007] Figure 6 Depicting Figure 5 A graphical representation of the Data Change Request (DCR) workflow review process.

[0008] Figure 7 and Figure 8 This is a sample data change request review panel for the user interface (UI).

[0009] Figure 9 The Additional Details tab in the Data Change Request Review panel is described.

[0010] Figure 10 The interface for creating new characters is described.

[0011] Figure 11 The interface for editing users is described.

[0012] Figure 12 The interface for requesting data changes is described.

[0013] Figure 13 The interface for data change requests, including the "Cancel Reject" option, is described.

[0014] Figure 14The interface for reviewing data change requests that describe the state of a relationship is described.

[0015] Figure 15 The interface for requesting data changes is described.

[0016] Figure 16 , Figure 17 and Figure 18 It describes changes to relationships and their attributes, or the creation or deletion of relationships.

[0017] Figure 19 A schematic diagram of an example system that implements an abstraction across multiple cloud-native data stores is depicted.

[0018] Figure 20 A schematic diagram of the example abstraction layer system is depicted.

[0019] Figure 21 A flowchart is drawn illustrating an example approach to dynamically and seamlessly switching cloud-native service providers by hooking into an abstraction layer in a unified data model for multi-tenant computing platforms.

[0020] Figure 22 A flowchart is drawn illustrating an example approach to dynamically and seamlessly switching cloud-native service providers by hooking into an abstraction layer in a unified data model for multi-tenant computing platforms.

[0021] Figure 23 A flowchart is drawn illustrating an example approach to dynamically and seamlessly switching cloud-native service providers by hooking into an abstraction layer in a unified data model for multi-tenant computing platforms. Detailed Implementation

[0022] The claimed solution, rooted in computer technology, overcomes problems particularly prevalent in the field of computer technology. In various embodiments, regardless of the platform's backend technology, the abstraction layer enables a multi-tenant platform to provide a consistent frontend to tenants. Furthermore, the abstraction allows the platform to seamlessly, dynamically, and transparently switch backend services without affecting any tenant interaction with the frontend.

[0023] More specifically, the computing system is configured to access a multi-tenant computing platform that includes various data structures and applications. Each tenant can be associated with some data structures (e.g., a subset of data structures), and the multi-tenant computing platform can communicate with different cloud service providers (e.g., AWS, and Azure, etc.), each providing storage and / or other backend services to the tenants of the multi-tenant computing platform. More specifically, the computing system can provide a unified data model for the multi-tenant computing platform. The unified data model can provide each tenant of the platform with a logical view of a subset of data structures associated with that tenant. In some embodiments, an abstraction layer (e.g., the computing system) maps attributes of the various cloud service providers to corresponding attributes in the unified data model.

[0024] The abstraction layer can select a storage solution from a cloud service provider (e.g., AWS) for a specific tenant. The computing system can receive input from the tenant, and based on the input, the abstraction layer can transform the first input into a storage instruction set native to the cloud service provider using a mapping. Execution of the storage instruction set can result in a logical view of the corresponding data structure. In some embodiments, the abstraction layer can seamlessly, dynamically, and / or transparently switch tenants from storage solutions to other storage solutions from different cloud service providers (e.g., Azure). The computing system can receive additional input from the tenant that is consistent with another input, and transform this additional input into another storage instruction set native to another cloud service provider based on a mapping. Execution of this other storage instruction set can result in another logical view of the corresponding data structure for the specific tenant, which is identical to the first logical view (e.g., they may be consistent).

[0025] In various embodiments, the unique architecture enables efficient modeling of the entities, relationships, and interactions that typically form the basis of a business. These models provide insights, scalability, and management capabilities previously unavailable in existing technologies. It should be understood that, using the information models discussed herein, there is no need to consider any low-level physicalities of tables, foreign keys, or how data is stored.

[0026] The information model can be used as part of a multi-tenant platform. In a specific implementation, the configuration resides in RELTIO. TM In the layer above the platform, and natively enjoying the capabilities provided by the platform, such as matching, merging, cleansing, standardization, and workflows, entities established within tenants can be associated with the platform's custom and / or standard interactions. The platform's ability to maintain and link three types of data (i.e., entities, relationships, and interactions) and leverage their convergence in one place provides businesses with the power to model and understand.

[0027] Entities established within tenants can be associated with custom and / or standard interactions on the platform. The ability to maintain and link these three types of data (i.e., entities, relationships, and interactions) within the platform and leverage their convergence in one place provides businesses with limitless power for modeling and understanding.

[0028] In various embodiments, metadata configuration is based on an n-tier model. One example is a 3-tier model (e.g., the default layout). In some embodiments, each tier is represented by a JSON file (however, it should be understood that many different file structures, such as BSON or YAML, can be utilized).

[0029] Information models can be used as part of the connected multi-tenant systems. Figure 1 Platform 102 is described. Platform 102 enables seamless scaling across a wide range of operational or analytical use cases. Platform 102 can serve as the foundation for Master Data Management (MDM). A variety of integration options, including low-code / no-code solutions, allow for rapid deployment and time-to-value realization.

[0030] Figure 1 These are examples of the functionality of Platform 102 in some embodiments. Platform 102 can support best-in-class MDM capabilities, including identity resolution, data quality, dynamic survivability for context profiles, universal IDs across all your operational applications and tiers, a knowledge graph for managing relationships, progressive stitching for creating richer profiles, and governance capabilities. Furthermore, Platform 102 can support high-volume transactions, high-volume API calls, complex analytics, and backend jobs for automatically scaling any workload in a cloud environment. Accordingly, Platform 102 can leverage built-in NoSQL databases, Elasticsearch, Spark, and another AWS and GCP service across multiple regions to support high redundancy, fault tolerance, and availability.

[0031] In various embodiments, platform 102 is multi-domain and enables seamless integration of many types of data from many sources to create master profiles for any data entity (individual, organization, product, location). Users can create master profiles for consumers, B2B clients, products, assets, and sites, and connect them to view the full picture.

[0032] Platform 102 enables an API-first approach for data integration and orchestration. Users (e.g., tenants) can use APIs and various application-specific connectors to simplify integration. Additionally, in some embodiments, users can stream data to analytics or data science platforms for instant insights.

[0033] Figure 2The environment for the integration hub 202 is described. The integration hub 202 can connect to various data sources and downstream consumers. In some embodiments, the integration hub 202 has over 1000 connectors to properly build data pipelines. The integration hub 202 may include an intuitive drag-and-drop graphical interface to create simple, replicable pipelines for complex data extraction and transformation tasks. Utilizing pre-built community recipes for common use cases, users can establish integration workflows in just a few clicks.

[0034] Along with its built-in data loader, event streaming capabilities, data API, and partner connectors, Integration Hub 202 enables rapid linking to user systems using Platform 102. Integration Hub 202 allows users to build automated workflows within hours or days to exchange data with any number of SaaS applications relative to Platform 102. Faster integration enables quicker access to unified, trusted data to drive real-time business operations.

[0035] Figure 3 A three-tier model is depicted in some embodiments. In this three-tier model, only tier 3 (e.g., the top tier in an n-tier model) 302 (referred to as "L3") is accessible to clients. This tier is part of a tenant. Information associated with tier L3 302 can be retrieved from the tenant, edited, and applied back to the tenant using a configuration API.

[0036] Layer 302 typically inherits from Layer 304 (industry-centric layer), which in turn inherits from Layer 306 (industry-agnostic layer). Generally, Layer 302 references the Layer 304 container and inherits all data items (or "objects") from it. However, Layer 302 is not required to reference the Layer 304 container; it can exist independently.

[0037] L2 layer 304 can inherit objects from L1 layer. Although there is only a single set of L1 layer 306 objects, objects at L2 layer 304 can be grouped into industry-specific containers. Similar to L1 layer 306, the containers at L2 layer 304 can be controlled by product management and may not be accessible to customers.

[0038] Life Sciences is a good example of an L2-level 304 container. The L2-level 304 container 304 can inherit the Organization Entity Type (discussed further in this paper) from the L1-level 306 and extend it to the Health Care Organization (HCO) type required in Life Sciences. Therefore, the HCO type enjoys all the attributes and other characteristics of the Organization type, but defines the additional attributes and characteristics required by the HCO.

[0039] L1 layer 306 may contain entities such as participants (abstract types) and locations. In some embodiments, L1 layer 306 contains a basic relationship type called HasAddress that links participant types to location types. L1 layer 306 also extends participant types to organizations and individuals (both non-abstract types).

[0040] There can be only one L1 layer 306, and its role is to define industry-agnostic objects that can be inherited and utilized by industry-specific layers located at L2 layer 304. This allows for the enhancement of objects in L1 layer 306, potentially impacting all clients. For example, if an additional attribute is added to the HasAddress relationship type, it will typically be immediately available to any client of the platform.

[0041] Any object can be defined in any layer. Often referred to as tenant configuration or metadata configuration, it is a merged configuration derived from inheritance across the three layers. In a particular implementation, metadata configuration merges simple, nested, and reference properties from all relevant layers. Values ​​described in higher layers provide overriding control over values ​​from lower layers. The number of layers does not affect inheritance.

[0042] In a given implementation, metadata configuration merges simple, nested, and reference properties from all relevant layers. Values ​​described in higher layers provide overriding control over values ​​from lower layers. The number of layers does not affect inheritance.

[0043] Figure 4 This is a diagram showing some examples of entity types, relationship types, and event metadata. Platform 102 enables object types to be entities, relationships, and interactions. Entity type 402 can be a category of entities. For example, "individual" is entity type 402, and "Alyssa" represents a specific instance of that entity type. Other common examples of entity types include "organization," "location," and "product."

[0044] Typically, entity types can be materialized in a single instance (such as the "Alyssa" example above). In other examples, the L1 layer could define an abstract "Participant" entity type with a small set of attributes. The L1 layer could then be configured to define "Individual" and "Organization" entity types, both inheriting from "Participant," both non-abstract, and both adding additional attributes specific to their type and business functionality. Continuing with the concept of inheritance, in the L2 life science container, an HCP entity (to represent a doctor) could be defined, inheriting from the "Individual" type but also defining a small set of attributes specific to the HCP concept. Thus, there are entity classifications "Participant," "Individual," or "HCP," and the resulting HCP entity type provides developers and users with aggregated attributes of "Participant," "Individual," and "HCP."

[0045] Once entity types are defined, users can link entities together in the data model using relationship types. Once entity types are defined, they can be linked by defining relationships between them. For example, a user can independently publish a relationship to link two entities together, or a client can mention the relationship in JSON, and then the JSON publishes the relationship and both entities at once.

[0046] Relationship type 404 describes a link or connection between two specific entities (e.g., entities 406 and 408). Relationship type 404, together with the described entity types 406 and 408, forms a graph. Some common relationship types are organization to organization, affiliate of, partner of, individual to individual, parent of / child of, report to, individual to organization / organization to individual, associated with, employee of / contractor of.

[0047] Once users define entity types, they can link them by defining relationships between them. For example, a user can publish a relationship independently to link two entities together, or a client can mention the relationship in JSON, and then the JSON publishes the relationship and both entities at once.

[0048] Platform 102 allows users to define metadata attributes and properties specific to relation types. Users can define any number of metadata attributes. Users can also define several properties specific to a relation type, such as name, description, direction (undirected, directed, bidirectional), start and end entities, etc. Properties of one relation type can be inherited from another relation type.

[0049] Hierarchies can be defined through the definition of relation subtypes. For example, if a user defines "Family" as a relation type, then the user can define "Parents" as a subtype. A hierarchy contains one or more relation types; all entities connected by these relations form the hierarchy. Entity A > HasChild(Entity B) > HasChild(Entity C). Then A, B, and C form the hierarchy. Within the same hierarchy, a user can add dependents as relations, and if entity D is a dependent of entity C, then A, B, C, and D all become part of a single hierarchy.

[0050] Interaction 410 is a lightweight object representing any kind of interaction or transaction. In a broader sense, interaction 410 represents an event that occurs at a specific moment (such as a retail purchase or measurement). It can also represent facts over a period of time, such as sales figures for June.

[0051] Interaction 410 can have multiple participants (entities) and can have different record lengths, columns, and formats. Attribute types can be used to define the data model. Therefore, users can build logical data models instead of relying on physical tables and foreign keys; define entities, relationships, and interactions with granular detail; make detailed data available to content and interaction designers; and provide business users with rich yet fluid search and navigation experiences.

[0052] In various embodiments, the four representations of attribute types include simple, nested, referenced, and analytic. A simple attribute type represents a single characteristic of an entity, relationship, or interaction. Nested, referenced, and analytic attribute types represent combinations or collections of simple sub-attribute types.

[0053] Nested property types are used to create collections of simple properties. For example, a phone number is a nested property. Sub-properties of a phone number typically include the number, type, area code, and extension. In the phone number example, the sub-properties are only meaningful when held together as a collection. When published as a nested property, the entire collection represents a single instance or value of the nested property. Publishing additional collections is also valid and is used to accumulate additional nested properties within entity, relational, or interaction data types.

[0054] Referencing attribute types makes it easy to define relationships between entity types in a data model.

[0055] When a user needs an entity to use an attribute of another entity, the user can leverage reference attribute types instead of defining the attributes natively for both. For example, the L1 layer in an information model defines the use of the AffiliatedWith relationship type to link organizations and individuals. The AffiliatedWith relationship type defines the organization entity type as a reference attribute of the individual entity type. This approach to data modeling makes navigation between entities easier and allows for more refined searches.

[0056] Easier navigation between entities: In the example where organizational and individual entities are related using a relationship type, specifying the previous employer attribute for the individual entity type allows that attribute to be displayed as a hyperlink in the individual's profile panel. This allows users to easily navigate to the individual's previous employers.

[0057] Easier granular searching: Business users can more easily refine their search queries when the attributes and relationship types of the referenced entities are available for indexing (as if they were native to the referenced entities). For example, in a search of a dataset containing 100 John Smith records, entering "John Smith" in the search box will return 100 John Smith records. Adding "Acme" to the search criteria will only return John Smith records that have references containing the word "Acme" (and therefore, attributes).

[0058] Analysis attribute types are lightweight. In various embodiments, analysis attributes are not managed in the same way as other attributes when records are aggregated during a merge operation. Analysis attribute types can be used to receive and retain values ​​delivered by the analysis solution.

[0059] Users can use analytics property types when they want values ​​from your analytics solutions, such as Reltio Insights, to be available to business users or other applications using the Reltio REST API. For example, if an analytics implementation calculates a customer's lifetime value and users need that value to be available to them when they view a customer profile, users can define an analytics property to retain that value and provide instructions to pass the calculation results to that property.

[0060] In a specific implementation, platform 102 assigns entity IDs (EIDs) to each data item entering the platform. Therefore, the platform can be appropriately characterized as including an EID allocation engine. Importantly, even when data is merged and / or assigned new EIDs, the lineage persistent relational database management system (RDBMS) retains the EID for each data item. Therefore, the platform can be appropriately characterized as including an old EID retention engine, whose task is to ensure that old EIDs are retained in the old EID data store when new EIDs are assigned. The old EID retention engine can be at least conceptually divided into an old EID survival sub-engine responsible for retaining all EIDs that have not been promoted to primary EIDs as old EIDs, and a lineage EID promotion sub-engine responsible for promoting the EID of the first data item merged with the second data item to the primary EID of the merged data item. The engine responsible for modifying data items can be characterized as a data item update engine, which includes merging data items and unmerging (previously merged) data items. Cross-tenant persistence also becomes possible when old EIDs are retained. In certain implementations, cross-tenant persistent EID lineage persistent RDBMS has an n-tier architecture, such as a 3-tier architecture.

[0061] Data can come from multiple sources. The processing of receiving data items can be referred to as "loading," and therefore, platform 102 can be characterized as including a new dataset loading engine. Data sources are registered, and in a particular implementation, all data ultimately loaded into a tenant will be associated with a data source. If no source is specified when creating a data item (or "object"), the source can have a default value. Therefore, the platform can be characterized as including an object registration engine that registers data items in association with their respective sources.

[0062] A crosswalk can represent a data provider or a non-data provider. The data provider supplies attribute values ​​for objects, and these attributes are associated with the crosswalk. The non-data provider is associated with the entire entity (or relationship); it can be used to link L1 (or L2) objects to objects in other systems. Crosswalks are not necessarily limited to the entity level; each supplied attribute can be associated with a data provider crosswalk. Crosswalks are similar to primary keys or unique identifiers in the RDBMS industry.

[0063] The engine and data storage of platform 102 can be connected using a computer-readable medium (CRM). CRM is intended to represent a computer system or a network of computer systems. As used herein, "computer system" can include or be implemented as a dedicated computer system for performing the functions described herein. Typically, a computer system will include a processor, memory, non-volatile storage devices, and interfaces. A typical computer system will typically include at least a processor, memory, and means for coupling the memory to the processor (e.g., a bus). The processor can be, for example, a general-purpose central processing unit (CPU) such as a microprocessor, or a dedicated processor such as a microcontroller.

[0064] By way of example and not limitation, the memory of a computer system includes random access memory (RAM), such as dynamic RAM (DRAM) and static RAM (SRAM). Memory can be local, remote, or distributed. Non-volatile storage devices are typically floppy disks or hard disks, magneto-optical disks, optical disks, read-only memory (ROM) (such as CD-ROM, EPROM, or EEPROM), magnetic cards or optical cards, or other forms of storage devices for large amounts of data. During software execution, some of this data is typically written to memory via a bus coupled to the non-volatile storage device, through direct memory access processing. Non-volatile storage devices can be local, remote, or distributed, but this is optional, as it allows for the creation of systems where all applicable data is available in memory.

[0065] Software in a computer system is typically stored in non-volatile storage. In fact, for large programs, it is not even possible to store the entire program in memory. For software to be run, it is moved, if necessary, to a computer-readable location suitable for processing, and this location is referred to as memory for illustrative purposes herein. Even when software is moved to memory for execution, the processor typically utilizes hardware registers to store values ​​associated with the software, as well as a local cache ideally used to speed up execution. As used herein, when a software program is referred to as "implemented in a computer-readable storage medium," it is assumed that the software program is stored in an applicable, known, or convenient location (from non-volatile storage to hardware registers). The processor is considered "configured to execute the program" when at least one value associated with the program is stored in a processor-readable register.

[0066] In one example of operation, the computer system can be controlled by operating system software, which is a software program that includes a file management system, such as a disk operating system. An example of operating system software and associated file management system software is the Windows family of operating systems from Microsoft Corporation in Redmond, Washington, and its associated file management system. Other examples of operating system software and associated file management system software are the Linux operating system and its associated file management system. The file management system typically stores data in non-volatile storage and enables the processor to perform various actions required for the operating system to input and output data and store data in memory (including storing files on non-volatile storage).

[0067] A computer system's bus couples the processor to an interface. The interface facilitates coupling between devices and the computer system. The interface can be used for input and / or output (I / O) devices, modems, or networks. By way of example, and not limitation, I / O devices can include keyboards, mice or other pointing devices, disk drives, printers, scanners, and other I / O devices including display devices. By way of example, and not limitation, display devices can include cathode ray tube (CRT), liquid crystal displays (LCDs), or some other suitable, known, or convenient display devices. By way of example, and not limitation, modems can include analog modems, IDSN modems, wired modems, and other modems. By way of example, and not limitation, network interfaces can include ring network interfaces, satellite transmission interfaces (e.g., "direct PC"), or other network interfaces used to couple a first computer system to a second computer system. An interface can be considered part of a device or a computer system.

[0068] Computer systems may be compatible with, or be part of, or implemented through, a cloud-based computing system. As used herein, a cloud-based computing system is a system that provides virtualized computing resources, software, and / or information to client devices. Computing resources, software, and / or information can be virtualized by maintaining centralized services and resources accessible to edge devices through communication interfaces such as networks. "Cloud" can be a marketing term and, for the purposes of this document, may include any network described herein. Cloud-based computing systems may involve subscription-based or usage-based pricing models for services. Users can access protocols for cloud-based computing systems through web browsers or other containerized applications located on their client devices.

[0069] A computer system can be implemented as an engine, a part of an engine, or through multiple engines. As used herein, an engine includes at least two components: 1) a dedicated or shared processor or a part of such a dedicated or shared processor; and 2) hardware, firmware, and / or software modules executed by the processor. A part of one or more processors may include portions of hardware less than all the hardware including any given one or more processors, such as a subset of registers, a portion of the processor dedicated to one or more threads of a multithreaded processor, a time slice of the processor dedicated entirely or partially to executing a portion of the functionality of the engine, etc. Thus, a first engine and a second engine may have one or more dedicated processors, or the first engine and the second engine may share one or more processors with each other or with other engines. Depending on implementation-specific or other considerations, an engine may be centralized or its functionality may be distributed. An engine may include hardware, firmware, or software embodied in a computer-readable medium for execution by a processor. As described with reference to the accompanying figures, the processor uses implemented data structures and methods to transform data into new data.

[0070] The engine described herein, or the engine used by the systems and apparatus described herein, can be implemented as a cloud-based engine. As used herein, a cloud-based engine is an engine that can use a cloud-based computing system to run applications and / or functionalities. All or part of the applications and / or functionalities can be distributed across multiple computing devices and are not required to be limited to a single computing device. In some embodiments, a cloud-based engine can execute functionalities and / or modules accessible to end users through a web browser or container application without requiring the functionalities and / or modules to be locally installed on the end user's computing device.

[0071] As used herein, data storage is intended to include repositories with any applicable data organization, including tables, comma-separated value (CSV) files, traditional databases (e.g., SQL), or other applicable known or convenient organizational formats. Data storage can be implemented, for example, in physical computer-readable media on a general-purpose or special-purpose machine, in firmware, in hardware, in a combination of physical computer-readable media, firmware, and hardware, or as software embodied in applicable known or convenient devices or systems. Data storage-related components (such as database interfaces) can be considered as “part” of the data storage, part of some other system components, or a combination of the data storage and other system components; however, the physical location and other characteristics of the data storage-related components are not critical to understanding the techniques described herein.

[0072] Data storage can include data structures. As used herein, a data structure is associated with how data is stored and organized in a computer, enabling it to be used effectively within a given context. Data structures are typically based on a computer's ability to retrieve and store data at any location in its memory, specified by an address—a bit string that can itself be stored in memory and manipulated by a program. Thus, some data structures are based on calculating the address of a data item using arithmetic operations, while others are based on storing the address of the data item within the structure itself. Many data structures use both principles, sometimes combined in a non-trivial way. Implementing a data structure typically requires writing a set of procedures for creating and manipulating instances of that structure. The data storage described in this paper can be a cloud-based data storage. Cloud-based data storage is data storage compatible with cloud-based computing systems and engines.

[0073] Assuming CRM includes a network, the network can be a suitable communication network, such as the Internet or an infrastructure network. As used herein, the term "Internet" refers to a network using certain protocols (such as TCP / IP) and possibly others (such as Hypertext Transfer Protocol (HTTP) used to construct Hypertext Markup Language (HTML) documents for the World Wide Web ("web"). More generally, a network can include, for example, a Wide Area Network (WAN), a Metropolitan Area Network (MAN), a Campus Network (CAN), or a Local Area Network (LAN), but a network can have at least a suitable size in theory or be characterized in some other way (several alternatives are such as Personal Area Networks (PANs) or Home Area Networks (HANs)). Networks can include enterprise-specific networks and Virtual Private Networks (VPCs) (collectively, private networks). As the name suggests, a private network is controlled by a single entity. Private networks can include headquarters offices and optional regional offices (collectively, offices). Many offices enable remote users to connect to private network offices via some other network, such as the Internet.

[0074] Matching is a powerful functional domain and can be leveraged in various ways to support different needs. A classic scenario is matching and merging entity (profile) relationships. Within the architecture discussed in this article, relationships between linked entities can also, and often do, match and merge into a single relationship. This can happen automatically and is discussed in this article.

[0075] You can use matching to deduplicate profiles within a tenant. You can use matching on records in a file outside the tenant to identify records in that file that match profiles within the tenant. You can also use matching to match profiles stored within a data tenant with profiles within the tenant.

[0076] Figure 5 A flowchart illustrating the dynamic matching process is provided. The matching architecture is responsible for identifying profiles within a tenant that are considered semantically identical or similar. Users can use the matching configuration framework to build matching schemes. In some embodiments, users can leverage machine learning techniques to match profiles. In step 502, users can create matching rules. In step 504, users can identify attributes from the entity types they wish to use for matching. In step 506, users can write comparison formulas within each matching rule, which are responsible for the actual work of comparing one profile with other profiles. In step 508, users can map the lexical generator categories that will be responsible for creating matching candidates.

[0077] Unlike other systems, this architecture is designed for real-time operation in various embodiments. Each profile created or updated can be cleaned up instantly by a profile-level cleaner before the matching and merging processes occur. Therefore, the three-step sequence of cleanup, matching, and merging can be designed to occur in real-time at any time a profile is created or updated. This behavior makes platform 102 ideal for real-time operation within a customer ecosystem.

[0078] Finally, the survival architecture is responsible for creating the classic "golden record," but in a particular implementation, it is an on-the-fly materialized view. It is returned to any API call that retrieves the profile and contains a set of "operation values" from the profile, which are selected in real time based on survival rules defined for the entity type.

[0079] In various implementations, matching can be performed continuously and in real time. For example, when a user creates or updates a record in a tenant, the platform cleans and processes that record to find a match within the existing record set.

[0080] Each entity type (e.g., contact, organization, product) can have its own set of matching groups. In some embodiments, each matching group maintains a single rule and other properties that instruct the behavior of the rules within that group. Comparison operators (e.g., Exact, ExactOrNull, and Fuzzy) and attributes can include individual rules.

[0081] Matching terms can be used to help the matching engine quickly find candidate matching values. The comparison formula within the matching rule can be used to adjudicate candidate matching pairs and will evaluate TRUE or FALSE (or a score if the match is based on relevance).

[0082] In some embodiments, the matching function can perform one of three things with a pair of records: none (if the comparison formula determines that no match exists); issue an instruction to merge the pair; or issue an instruction to queue the pair for data administrator review. In some embodiments, the schema may include the following:

[0083] 1) Entities and relationships each have configurable attribute capabilities.

[0084] 2) The values ​​found in the attributes are associated with cross-mappings maintained within the entity or relational object. Each profile can have multiple cross-mappings, each contributing one or more values. Data can come from multiple sources. Sources can be registered, and all data loaded into a tenant will be associated with a data source. The provided attributes can be associated with data provider cross-mappings. Cross-mappings are similar to primary keys or unique identifiers in a relational database management system (RDBMS). Cross-mappings can represent data providers or non-data providers.

[0085] 3) The data provider supplies the attribute values ​​of the object, and the attributes are associated with cross-mapping.

[0086] 4) The non-data provider is associated with the overall entity (or relationship). In this case, it is only used to link Reltio objects with objects in other systems. The provided attributes may not be associated with this cross-mapping.

[0087] 5) Profiles can be matched and merged, but so can relationships. While users can develop matching rules to manage profile matching and merging, relationship merging is automatic and platform-inherent. Any two relationships of the same type, each having entity A at one endpoint and entity B at the other endpoint, will be automatically merged.

[0088] 6) Attributes are inherently multi-valued, meaning they can hold multiple values. This means any attribute can collect and store multiple values ​​from contributing sources or generated through merging with additional cross-mapping. Therefore, if a matching rule utilizes a name attribute, the matching engine will by default compare all values ​​held within the name attribute of record A with all values ​​held within the name attribute of record B to find matches between the values. If needed, the user can choose to match only the operation value.

[0089] 7) When two profiles are merged, the resulting profile contains an aggregation of all cross-mappings from the two contributing profiles, and therefore includes the associated attributes and values ​​from those cross-mappings. The arrays following the attributes are also naturally merged, producing an array for each attribute that holds the aggregations of all values ​​from the contributing attributes. Relationships benefit from the same schema and are represented in the same way as described for the merged entity. The surviving entity ID (or relationship ID) for the merged profile (or relationship) is the ID of the older of the two contributors. Beyond this, there is actually no concept of winner and loser objects.

[0090] 8) When two profiles are merged, the resulting profile contains references to all interactions previously associated with the contributing profile. (Note that interactions do not reference relationships.)

[0091] 9) If profile B is unmerged from a previous merge of A and B, B will be restored with its original entity ID. All attributes (and associated values), relationships, and interactions brought into the merged profile from profile B will be removed from the merged profile and returned to profile B.

[0092] A matchgroups construct is a collection of match groups containing the rules and operators required for correct matching. If a user needs to enable matching for a specific entity type within a tenant, they can include matchgroup sections within the entity type definition in the tenant's metadata configuration. A matchgroup section will contain one or more match groups, each containing a single rule and other elements that support that rule.

[0093] When viewing a match group in a JSON editor, users can easily see its advanced, classic elements. Rules can define Boolean formulas (see the "and" operator used to anchor Boolean formulas in this example) to evaluate the similarity of a pair of profiles given to the match group for evaluation. Within the rule element, four other very common elements can also be held: ignoreInToken (optional), Cleanse (optional), matchTokenClasses (required), and comparatorClasses (required). The remaining visible elements (URIs, tags, etc.), along with some elements not shown in the snapshot, surround the rule and provide additional statements that affect the behavior of the group and essentially influence the rule itself.

[0094] Each matching group can be specified as one of four types: Automatic, Suspicious, <Custom>, and Relevance-Based, as described below. The user-selected type allows the user to develop either Boolean or arithmetic expressions for the comparison rules. The types are described below.

[0095] Automatic type behavior: With this type set, the comparison formula is a pure Boolean, and if it evaluates to TRUE, the matching group will issue a merge instruction. Unless overridden by priority, the merge instruction will cause candidate pairs to merge.

[0096] Suspicious type behavior: In this type setting, the comparison formula is a pure Boolean, and if it evaluates to TRUE, the matching group will issue an instruction to queue for review. Unless overridden by priority, the instruction to queue for review will cause candidate pairs to appear in the "Potential Matches View" of the MDM UI.

[0097] Relevance-based type behavior: Unlike the aforementioned rules which are entirely based on Boolean constructions of rule formulas, relevance-based type expects the user to define an arithmetic scoring algorithm. The range of matching scores determines whether records are automatically merged or potential matches are created.

[0098] If a negation rule exists in the matching group and evaluates to true, any merge indications from other rules are downgraded to queueing for review. Therefore, automatic merging does not occur in this case. The Scope parameter of the matching group defines whether the rule should be used for internal matching, external matching, or both. External matching occurs non-intrusively, and the results of the matching job are written to an output file for user review. Values ​​for Scope are: ALL - Enables matching groups for both internal and external matching (default setting). NONE - Disables matching for matching groups. INTERNAL - Enables matching groups only for matching records within the tenant. EXTERNAL - Enables matching groups only for matching records from external files to records within the tenant; in certain implementations, external matching is supported programmatically via the external matching API and through the console (such as RELTIO). TM External matching applications found within consoles, etc., are available.

[0099] If set to TRUE, only the OVs of each attribute will be used for lexicalization and comparison. For example, if the name attribute contains "Bill", "William", and "Billy", but "William" is an OV, only "William" will be cleansed, lexicalized, and compared.

[0100] Rules are the main components within a matching group. They contain the following key elements, each described in detail: ignoreInToken, cleanse, matchTokenClasses, comparatorClasses, and comparison formula.

[0101] Negation rules allow users to prevent any other rules from merging records. Matching groups can have either rules or negation rules. Negation rules have the same architecture as rules but with special behavior: if they evaluate to true, they degrade any merge instructions from other matching groups to a queue for review. It's safe to say that most matching groups across most customer configurations use rules for most matching goals. However, in some cases, it may be advantageous to additionally dedicate one or more matching groups to supporting negation rules, for the purpose of typically stopping merging based on a single condition. And when the condition is met, negation rules prevent any other rules from merging records. Therefore, in practice, a user might have seven matching groups each using rules, and an eighth group using negation rules.

[0102] Platform 102 may include a mechanism for proactively monitoring matching rules across tenants in all environments. In some embodiments, after data is loaded into a tenant, the proactive monitoring system examines each rule in the tenant over a period of time and logs its findings. Based on the percentage of entities that fail to be examined, the proactive monitoring system detects and bypasses matching rules that may cause performance issues and may notify the client. Bypassed matching rules will not participate in the matching process.

[0103] In various embodiments, the user receives a notification when the proactive monitoring system detects a matching rule that requires review. The `scoreStandalone` and `scoreIncremental` elements can be used to calculate a matching score for a profile designated as a potential match and can assist data administrators when reviewing potential matches.

[0104] Relevance-based matching is primarily designed as an alternative to strategies using automatic and suspicious rule types. With relevance-based matching, clients can create scoring algorithms of their own design. The advantage is that, in most cases, a relevance-based matching strategy can reduce complexity and the overall number of rules. This is because the instructions to merge and queue for review—which typically require separate rules (automatic and suspicious, respectively)—can often be represented by a single relevance-based rule.

[0105] A workflow is a series of sequential steps or tasks performed based on user-defined rules or conditions to execute business processes. Workflows allow users to manage complex business processes through a series of predetermined steps or tasks. Platform 102 can utilize workflows to implement processing and task management, including task assignment and tracking. Workflow processing can support creators, creation dates, deadlines, assignees, steps, and comments. In various embodiments, workflow business processes are configurable. In some embodiments, the various participants and triggers in a workflow are: participants, the people and processes involved in the workflow are participants, such as reviewers, workflow engines, hubs, and APIs; reviewers, users will be assigned the role ROLE_REVIEWER; triggers, which are used to scan activity logs to initiate scheduled processing of review workflows, for example, using a UI, where you can initiate a data change request workflow to review updates or changes to entity or profile data in your tenant. Workflow features allow users to manage business processes through a series of predetermined steps or tasks, enabling you to plan and coordinate user tasks, validate, review, and approve for multiple records.

[0106] A Data Change Request (DCR) is a collection of proposed data changes. Users without the authority to update objects, such as customer sales representatives, can suggest changes. These suggested changes are accumulated in DCRs, which are then queued for review and approval by someone with approval privileges, such as a data administrator. Examples of suggested data changes include adding new attribute values, updating attribute values, deleting attribute values, and creating new objects and referenced objects. DCRs can be initiated using a web browser-based user interface for desktop or mobile use. An example of the steps could be a user task assigned to a user to review and approve DCRs. In this example, the workflow for a Data Change Request (DCR) includes... Figure 5 The flowchart shows the sequence of the following steps.

[0107] In step 502, on the profile page in the central hub, the user can initiate DCR workflow processing in suggestion mode.

[0108] In step 504, the reviewer can approve or reject the DCR. In the UI's Data Change Request review panel, sub-properties within nested, referenced, or complex properties, as well as parent nested properties, have labels with attribute values.

[0109] In step 506, if the reviewer approves the DCR, the change request is accepted using the API, and the task is marked as complete.

[0110] In alternative step 508, if the reviewer rejects the DCR, the change request is rejected using the API, and the task is marked as complete. In the inbox, you have the option to partially reject changes from the DCR. In various embodiments, the reviewer can selectively reject attributes and partially approve the DCR.

[0111] Figure 6 Depicting Figure 5 A graphical representation of the Data Change Request (DCR) workflow review process.

[0112] From the business user's perspective, workflows can be initiated for one or more profiles (manually or automatically). As the user assigning the task, the approver can review the proposed changes or enter comments.

[0113] Figure 7 These are sample data change request review panels for the UI in some embodiments. Figure 8 These are other example data change request review panels for the UI in some embodiments. As shown in these examples, in the example data change request review panel, there are labels for sub-properties within nested, referenced, or complex properties, as well as parent nested properties, that have property values.

[0114] To ensure that data administrators can make informed decisions about approving or rejecting DCRs, an additional details tab is available in the Data Change Request Review panel. Figure 9 The image depicts an additional details tab in the Data Change Request (DCR) review panel of some embodiments. This additional details tab displays external information stored by the user related to the DCR for the activity task. This can be any information that can assist the data administrator during the approval process. This external information may be available in JSON format.

[0115] Partial denial can be enabled automatically for users with a deletion permission on the MDM:data.changeRequests role. Out of the box, workflow processing works with the system role ROLE_REVTEWER, which does not have this permission. Therefore, existing customers can automatically enable this feature based on the permissions they have already assigned to their data administrators (workflow reviewers). Otherwise, customers must enable partial denial by using the user management console application.

[0116] Figure 10 Interfaces for creating new characters in some embodiments are depicted. Figure 10 In this example, a new role with exact permissions (deletion) is created.

[0117] Figure 11 The interface for editing users is described. Figure 11 In this example, roles are assigned to one user / multiple users / user groups on the relevant tenant. Users can partially refuse attributes in data change requests for entities and relationships. This includes nested attributes and sub-attributes of nested attributes. Furthermore, you can refuse entire DCRs used to prevent the creation of new entities or relationships.

[0118] Figure 12 An interface for requesting data change is depicted in some embodiments. Figure 12 In the described interface, users can select tasks by clicking the "Tasks" tab in the Inbox and view details in the right panel. A "Reject" option appears when you hover your mouse over the task.

[0119] Figure 13 The interface for data change requests, including a "Cancel Reject" option, is described. Users can select a task by clicking the Tasks tab in the Inbox and view details in the right panel. The Reject option appears when the user hovers the mouse over the change.

[0120] In this example, users can click the reject option corresponding to the changes they want to reject. Rejected changes appear as if they are knocked out, but are not removed from the DCR until the task is approved. If a user moves to any other tab without approving the task, they may cancel all rejections. If a user chooses not to reject changes from the DCR, they can click the cancel reject button.

[0121] In some embodiments, rejection of start / end dates, roles, and tags for new entities / relationships has no effect. There may be no validation of dependencies on the rejected new entity. If there are reference attributes for that entity, the entity can continue to exist without modification.

[0122] In some embodiments, when a relationship is changed, the old relationship is removed and the new relationship is added. Therefore, by rejecting changes to a relationship, one can reject both the removal and addition of the relationship.

[0123] Figure 14 An interface for reviewing data change requests describing relationship states is depicted in some embodiments. If neither action is rejected, the following changes may occur: if the added relationship is rejected and the removed relationship is applied, the relationship may not exist; and if the added relationship is applied and the removed relationship is rejected, two relationships may exist.

[0124] Figure 15 An interface for requesting data change is depicted in some embodiments. In some embodiments, such as Figure 16 As depicted in the interface, changes to relationships and their attributes, or new or deleted relationships, can be displayed in the right panel.

[0125] If a new relationship has been added and attributes have been provided, a drop-down menu (caret) icon will appear near the relationship's title. Click the drop-down menu icon to view the added attributes.

[0126] Figure 16 , Figure 17 and Figure 18 It describes changes to the relationship and its attributes, or the creation or deletion of the relationship. For example... Figure 16 The depicted attributes, if already added to an existing relationship, are immediately visible, indicated by dashed lines from the relationship's header to the individual attributes. The same behavior occurs for attributes that have been modified. In some embodiments, such as... Figure 17 As depicted in the interface, if a relationship is deleted, its attributes may not be displayed. If the user changes or deletes any attributes of the relationship, those attributes are displayed similarly to other attributes. Attributes that have not been changed remain unaffected.

[0127] When a Data Change Request (DCR) is assigned to a user for review, the user can receive an email notification. When a DCR is approved or rejected, the DCR initiator can receive an email notification with the approval status, the name of the approver, and comments from the person who made the approval. Partial rejection can be automatically enabled for users with deletion permissions on the MDM:data.changeRequests role. Out-of-the-box workflow processing works with the system role ROLE_REVTEWER, which does not have this permission. Therefore, existing customers can automatically enable this feature based on the permissions they have already assigned to their data administrators (workflow reviewers). Otherwise, customers must enable partial rejection by creating a new role with the exact permissions (deletion) using the user management console application, assigning that role to one / multiple users / user groups on the relevant tenant, or performing a task action that must be assigned to your user account.

[0128] Reviewers can partially reject attributes in a data change request for entities and relationships. This includes nested attributes and sub-attributes of nested attributes. Additionally, reviewers can reject an entire DCR used to prevent the creation of a new entity or relationship. To partially reject a change, you first select the task by clicking the Task in the Inbox tab and viewing the details in the right panel; the Reject option appears when you hover your mouse over the change. You then click the Reject option corresponding to the change the reviewer wants to reject. Rejected changes may appear as knocked out but not removed from the DCR until the task is approved. If you move to any other tab without approving the task, all rejections are canceled. If you choose not to reject changes from the DCR, click the Cancel Reject button.

[0129] In some embodiments, example limitations on the rejection attribute include that rejection has no effect on start / end dates, roles, and tags for new entities / relationships; and there is no validation of dependencies on the rejected new entity. If there are reference attributes for that entity, the entity will continue to exist without modification.

[0130] When a relationship is changed, the old relationship is removed and the new relationship is added. Therefore, while refusing to change a relationship, one can also refuse the actions of removal and addition. If neither action is refused, the following changes may occur: 1) If the added relationship is refused and the removed relationship is applied, the relationship may not exist; 2) If the added relationship is applied and the removed relationship is refused, two relationships may exist.

[0131] Changes to relationships and their attributes, or new or deleted relationships, can be displayed in the UI. In some embodiments, if a new relationship has been added and attributes have been provided, a dropdown menu icon appears near the relationship's title. Clicking the dropdown menu icon displays the added attributes. If attributes have been added to an existing relationship, they are immediately visible, indicated by dashed lines from the relationship's title to the individual attributes. The same behavior occurs for attributes that have been changed.

[0132] If a user changes or deletes any attributes of a relationship, those attributes are displayed similarly to other attributes. Attributes that have not been changed remain unaffected. If the relationship is deleted, the attributes may not be displayed.

[0133] When a Designated Review Request (DCR) is assigned to a user for review, the user can receive an email notification. When a DCR is approved or rejected, the DCR initiator receives an email notification with the approval status, the name of the approver, and comments from the person who made the approval.

[0134] Platform 102 provides the ability to centrally manage various data entities. A profile is a collection of all data associated with an entity. A profile contains the entity's attributes, relationships to the entity, and the sources of all attributes. Entity attributes may have multiple sources and multiple values. As defined by the attribute's lifecycle rules, the Operation Value (OV) is the current value for a given attribute. The profile page allows you to view and manage details of each entity within your tenant.

[0135] In various embodiments, the inbox enables users to efficiently view, manage, and process business tasks assigned to them or their teams. The inbox has filtering capabilities. Furthermore, users can create workflow tasks and take actions to review potential matches. As the assignee, you can take the desired actions on the workflow task. Platform 102 provides a simple way to review potential matches from the search view. Each workflow task can have variables associated with the overall workflow process or specific to a step. These variables typically contain internal information that can be used in customized workflows.

[0136] Users may want to access their inbox from your mobile device, such as a smartphone or tablet. Optimize the mobile experience for smaller shape factors that support gestures.

[0137] Inbox: Lists tasks and displays information such as the creator's name, task status, creation date, and due date. Task icons indicate the process to which the task belongs. More than one process can be represented in the list, and the process can vary depending on factors such as approving expense reports or matching tasks.

[0138] Team: Lists tasks assigned to team members of the user. Team members can perform any task, reassign any task, or simply view any task.

[0139] Send: List the tasks you have sent for approval.

[0140] All: Lists all open and closed tasks. Users with the necessary permissions will be able to access closed or resolved tasks. By default, closed tasks will be available in the inbox for a period of one year from the date they were resolved or closed.

[0141] Figure 19 A schematic diagram (1900) depicts an example system that implements an abstraction across multiple cloud-native data stores. Figure 19 In the example, the system includes platform 102, cloud provider systems 1902-1 to 1902-N (referred to individually as cloud provider systems 1902, or collectively as cloud provider systems 1902), client systems 1904-1 to 1904-N (referred to individually as client systems 1904, or collectively as client systems 1904), unified data model 1906, and abstraction layer system 1908.

[0142] exist Figure 19 In the example, platform 102 is a multi-domain and / or multi-tenant computing platform that enables seamless integration of many types of data from many sources. The platform may include various data structures with different formats, structures, and / or data types. Platform 102 may include some or all of the functionalities and components of platform 102 as described elsewhere herein.

[0143] exist Figure 19 In the example, cloud-native service provider system 1902 includes various backend service provider systems. Although system 1902 is depicted as a cloud-native service provider (e.g., AWS, Azure), it should be understood that in some embodiments, system 1902 may more generally include backend service providers (e.g., cloud-native service providers and / or managed service providers). Cloud-native service provider system 1902 can provide storage services and / or other backend services for the platform and its clients (e.g., tenants).

[0144] exist Figure 19 In the example, client system 1904 includes a client of platform 102. A client system can be a client of platform 102 and can be associated with one or more tenants and / or domains of platform 102.

[0145] exist Figure 19In the example, the unified data model 1906 enables platform 102 to provide a logical view (e.g., a single logical view) of the data structure of platform 102. For example, the unified data model 1906 can enable platform 102 to provide a corresponding logical view of the data structure associated with a specific tenant. In some embodiments, the unified data model 1906 maps different attribute fields (e.g., application fields) to a single logical view. For example, client system 1904 may not know which cloud provider 1902 platform 102 is using to store and manage its data. Therefore, customers do not need to worry about database design and can use the unified data model across the entire enterprise.

[0146] exist Figure 19 In the example, the abstraction layer system 1908 collaborates with the unified data model 1906 to provide a single front-end across all back-end service providers 1902. This provides the scaling benefit of being transparently managed by the service providers 1902. For example, the abstraction layer system can "hook" into the unified data model to map attributes of cloud service providers 1902 to corresponding attributes of the unified data model 1906. This allows the abstraction layer system 1906 to seamlessly, dynamically, and / or transparently switch cloud service providers 1902.

[0147] In some embodiments, the unified data model 1906 and / or the abstraction layer system 1908 are components of platform 102. In some embodiments, the unified data model 1906 and / or the abstraction layer system 1908 are different from platform 102. In some embodiments, the unified data model 1906 and / or the abstraction layer system 1908 may be part of the same system and / or different systems.

[0148] Figure 20 A schematic diagram of the example abstraction layer system 1908 is depicted in 2000. Figure 20 In the example, the abstraction layer system 1908 includes a unified data model engine 2002, a mapping engine 2004, a selection engine 2006, a transformation engine 2008, a back-end exchange engine 2010, an interface engine 2012, and an abstraction layer system data storage 2020.

[0149] The Unified Data Model Engine 2002 is intended to represent an engine for generating, obtaining, managing, and / or accessing a unified data model (e.g., Unified Data Model 1906). For example, the unified data model can provide a logical view of the data structures associated with a particular tenant for platform 102.

[0150] Mapping Engine 2004 is intended to represent an engine that maps attributes of a backend service provider (e.g., a cloud service provider) to corresponding attributes in a unified data model (e.g., Unified Data Model 1906). Attributes may include applications (and associated identifiers), data structures (and associated identifiers), communication protocols (and associated identifiers), and / or interfaces (and associated identifiers), etc.

[0151] The Selection Engine 2006 is intended to represent an engine used to identify and / or select various storage solutions and / or backend service providers. The Selection Engine 2006 can select storage solutions and / or backend service providers based on a unified data model, tenant requirements, and / or design specifications.

[0152] The Transformation Engine 2008 is intended to represent an engine for translating instructions received through the front end of Platform 102 into appropriate storage instructions for one or more associated backend service providers. For example, the transformation may map a unified data model and the specifications or interfaces of the backend service providers for transformation.

[0153] Backend Switching Engine 2010 is intended to represent an engine for seamless, transparent, and / or dynamic switching from one storage solution and / or backend service provider to one or more other backend service providers.

[0154] Interface Engine 2012 is intended to represent an engine that presents visual, audio, and / or tactile information. In some implementations, Interface Engine 2012 generates graphical user interface components (e.g., server-side graphical user interface components) that can be rendered as a complete graphical user interface on various systems (e.g., client systems). Interface Engine 2012 can be used to present interactive graphical user interfaces for displaying and receiving information.

[0155] Figure 21 A flowchart 2100 illustrates an example approach to dynamically and seamlessly switching cloud-native service providers by hooking into an abstraction layer in a unified data model for computing platforms. In this flowchart, flow diagrams, and / or sequence diagrams, as well as other flowcharts, flow diagrams, and / or sequence diagrams, the flow diagrams exemplify sequences of modules by way of example. It should be understood that modules can be reorganized for parallel execution or reordered where applicable. Furthermore, for clarity, some modules may have been removed to avoid providing excessive information, and some included modules may have been removed but may have been included for clarity.

[0156] In module 2102, the computing platform (e.g., platform 102) obtains and / or accesses a unified data model (e.g., unified data model 1906). The unified data model can provide a logical view of multiple data structures for the computing platform and / or other computing systems and platforms. The computing platform can communicate with multiple cloud-native service providers, each of which provides corresponding storage services and / or other backend services to the computing platform.

[0157] In module 2104, an abstraction layer system (e.g., abstraction layer system 1908) provides an abstraction layer for mapping corresponding attributes of a unified data model to corresponding attributes of each cloud service provider among multiple cloud service providers. Attributes may include applications (and associated identifiers), data structures (and associated identifiers), communication protocols (and associated identifiers), and / or interfaces (and associated identifiers), etc.

[0158] In module 2106, the abstraction layer system selects a first storage scheme for the first cloud service provider (e.g., cloud provider system 1902-1) among a plurality of cloud service providers (e.g., cloud service provider 1902).

[0159] In module 2108, the computing platform receives the first input from the user.

[0160] In module 2110, the abstraction layer system, in response to the first input and based on the mapping between the corresponding attributes of the unified data model and the corresponding attributes of the first cloud service provider, converts the first input into a first storage instruction set native to the first cloud service provider. (For example, by the computing platform) Execution of the first storage instruction set can cause a first logical view of the data structure of the computing platform.

[0161] In module 2112, the abstraction layer system seamlessly and dynamically switches from the first storage solution to the second storage solution of a second cloud service provider (e.g., cloud provider system 1902-2) among multiple different cloud service providers without notifying the user.

[0162] In module 2114, the computing platform receives a second input from the user. The second input may be the same as the first input (e.g., the second input is identical to the first input).

[0163] In module 2116, the abstraction layer system, in response to the second input and based on the mapping between the corresponding attributes of the unified data model and the corresponding attributes of the second cloud service provider, converts the second input into a second storage instruction set native to the second cloud service provider. (E.g., by the computing platform) Execution of the second storage instruction set results in a second logical view of the corresponding data structure of the computing platform, wherein the second logical view of the result is identical to the first logical view.

[0164] Figure 22 A flowchart 2200 depicts an example approach to dynamically and seamlessly switching cloud-native service providers (e.g., cloud provider system 1902) using hooks to an abstraction layer (e.g., provided abstraction layer system 1908) within a unified data model (e.g., unified data model 1906) for a multi-tenant computing platform (e.g., platform 102). In this flowchart, the diagram of processes and / or sequence diagrams, and other flowcharts, diagrams of other processes and / or other sequence diagrams, the flowcharts exemplify sequences of modules by way of example. It should be understood that modules can be reorganized for parallel execution or reordered where applicable. Furthermore, for clarity, some modules may have been removed to avoid providing excessive information, and some included modules may have been removed but may have been included for clarity of illustration.

[0165] In module 2202, computing systems (e.g., client system 1904, abstraction layer system 1908, and / or platform 102) access a multi-tenant computing platform (e.g., platform 102). The multi-tenant computing platform may include multiple different data structures, and each tenant may be associated with a corresponding subset of these different data structures. The multi-tenant computing platform may communicate with multiple different cloud service providers (e.g., AWS, Azure), each providing appropriate storage services and / or other backend services to the tenants of the multi-tenant computing platform.

[0166] In module 2204, the computing system obtains and / or accesses a unified data model (e.g., unified data model 1906) for the multi-tenant computing platform. The unified data model can provide each tenant of the platform with a corresponding logical view of a subset of the data structures associated with that tenant.

[0167] In module 2206, the abstraction layer system (e.g., abstraction layer system 1908) maps the corresponding attributes of each cloud service provider to the corresponding attributes of the unified data model.

[0168] In module 2208, the abstraction layer selects a first storage scheme from a first cloud service provider among multiple different cloud service providers (e.g., cloud provider system 1902) for a specific tenant.

[0169] In module 2210, the computing system receives a first input from the first tenant.

[0170] In module 2212, the abstraction layer system, based on the mapping between the corresponding attributes of the first cloud service provider (e.g., AWS) and the corresponding attributes of the unified data model, transforms the first input into a first storage instruction set that may be native to the first cloud service provider. Execution of the first storage instruction set can elicit a first logical view of the corresponding data structure for a specific tenant.

[0171] In module 2214, the abstraction layer system (e.g., without notifying the tenant) seamlessly and dynamically switches a specific tenant from a first storage solution to a second storage solution of a second cloud service provider (e.g., Azure) among multiple different cloud service providers.

[0172] In module 2216, the computing system receives a second input from the first tenant, and the second input is the same as the first input (e.g., the two inputs are identical).

[0173] In module 2218, the abstraction layer, in response to the second input and based on the mapping between the corresponding attributes of the second cloud service provider and the corresponding attributes of the unified data model, transforms the second input into a second storage instruction set native to the second cloud service provider. Execution of the second storage instruction set can result in a second logical view of the corresponding data structure for a specific tenant, and the second logical view can be the same as the first logical view (e.g., the first and second logical views can be consistent).

[0174] Figure 23 A flowchart 2300 illustrates an example approach to dynamically and seamlessly switching cloud-native service providers using an abstraction layer hooked into a unified data model for multi-tenant computing platforms. In this flowchart, process diagrams and / or sequence diagrams, and other flowcharts, process diagrams and / or sequence diagrams, the flowcharts exemplify sequences of modules by way of example. It should be understood that modules can be reorganized for parallel execution or reordered where applicable. Furthermore, for clarity, some modules may have been removed to avoid providing excessive information, and some included modules may have been removed but may have been included for clarity.

[0175] In module 2302, a computing system (e.g., client system 1904, abstraction layer system 1908, and / or platform 102) accesses a multi-tenant computing platform (e.g., platform 102), wherein the multi-tenant computing platform includes multiple different data structures, and wherein each tenant is associated with a corresponding subset of the multiple different data structures, and wherein the multi-tenant computing platform communicates with multiple different cloud service providers (e.g., cloud service provider system 1902), each cloud service provider system providing corresponding storage services to the tenants of the multi-tenant computing platform.

[0176] In module 2304, the computing system and / or abstraction layer system (e.g., abstraction layer system 1908) obtain and / or access a unified data model (e.g., unified data model 1906) for the multi-tenant computing platform, wherein the unified data model provides each tenant of the platform with a corresponding logical view of a corresponding subset of the data structures associated with that tenant.

[0177] In module 2306, the abstraction layer system maps the corresponding attributes of each cloud service provider to the corresponding attributes of the unified data model.

[0178] In module 2308, the abstraction layer system selects the first storage solution from the first cloud service provider among multiple different cloud service providers for a specific tenant.

[0179] In module 2310, the abstraction layer system receives the first input from the first tenant.

[0180] In module 2312, the abstraction layer system responds to a first input and executes a first set of storage instructions based on a mapping between the corresponding attributes of the first cloud service provider and the corresponding attributes of the unified data model. This execution causes a first logical data manipulation associated with the corresponding data structure of a particular tenant and the corresponding storage service of the first cloud service provider.

[0181] In module 2314, the abstraction layer system switches a tenant from the first storage solution to the second storage solution of the second cloud service provider among multiple different cloud service providers without notifying the specific tenant.

[0182] In module 2316, the abstraction layer system receives a second input from the first tenant, wherein the second input is the same as the first input.

[0183] In module 2318, the abstraction layer system responds to the second input and executes a second set of storage instructions based on the mapping between the corresponding attributes of the second cloud service provider and the corresponding attributes of the unified data model. This execution causes a second logical data manipulation associated with the corresponding storage service of the specific tenant and the second cloud service provider, wherein the second logical data manipulation is the same as the first logical data manipulation.

Claims

1. A method comprising: A unified data model is obtained, wherein the unified data model provides a logical view of multiple data structures of the computing platform, wherein the computing platform communicates with multiple cloud service providers, and each cloud service provider provides corresponding storage services for the computing platform; An abstraction layer is provided, wherein the abstraction layer maps the corresponding attributes of the unified data model to the corresponding attributes of each of the multiple cloud service providers; The abstraction layer is used to select the first storage solution of the first cloud service provider among the plurality of cloud service providers; Receive the first input from the user; The abstraction layer responds to the first input and, based on the mapping between the corresponding attributes of the unified data model and the corresponding attributes of the first cloud service provider, converts the first input into a first storage instruction set native to the first cloud service provider, wherein execution of the first storage instruction set causes a first result logical view of the data structure of the computing platform; Through the abstraction layer, the user can seamlessly and dynamically switch from the first storage solution to the second storage solution of the second cloud service provider among the multiple cloud service providers without notifying the user; Receive a second input from the user, wherein the second input is the same as the first input; The abstraction layer responds to the second input and, based on the mapping between the corresponding attributes of the unified data model and the corresponding attributes of the second cloud service provider, converts the second input into a second storage instruction set native to the second cloud service provider. Execution of the second storage instruction set causes a second result logical view of the corresponding data structure of the computing platform, wherein the second result logical view is the same as the first result logical view.

2. A method comprising: Access a multi-tenant computing platform, wherein the multi-tenant computing platform includes multiple different data structures, and wherein each tenant of the platform is associated with a corresponding subset of the multiple different data structures, and wherein the multi-tenant computing platform communicates with multiple different cloud service providers, each cloud service provider providing corresponding storage services to the tenants of the multi-tenant computing platform. A unified data model for the multi-tenant computing platform is obtained, wherein the unified data model provides each tenant of the platform with a corresponding logical view of a corresponding subset of the data structures associated with that tenant; An abstraction layer is provided, wherein the abstraction layer maps the corresponding attributes of each cloud service provider to the corresponding attributes of the unified data model; The abstraction layer allows a specific tenant to select a first storage solution from the first cloud service provider among the multiple different cloud service providers. Receive the first input from the specific tenant; The abstraction layer responds to the first input and, based on the mapping between the corresponding attributes of the first cloud service provider and the corresponding attributes of the unified data model, converts the first input into a first storage instruction set native to the first cloud service provider, wherein execution of the first storage instruction set causes a first result logical view of the corresponding data structure of the specific tenant. Through the abstraction layer, the specific tenant can be seamlessly and dynamically switched from the first storage solution to the second storage solution of the second cloud service provider among the multiple different cloud service providers without being notified. Receive a second input from the specific tenant, wherein the second input is the same as the first input; In response to the second input and based on the mapping between the corresponding attributes of the second cloud service provider and the corresponding attributes of the unified data model, the second input is converted into a second storage instruction set native to the second cloud service provider, wherein execution of the second storage instruction set causes a second result logical view of the corresponding data structure of the particular tenant, wherein the second result logical view is the same as the first result logical view.

3. A method comprising: Access a multi-tenant computing platform, wherein the multi-tenant computing platform includes multiple different data structures, and wherein each tenant of the platform is associated with a corresponding subset of the multiple different data structures, and wherein the multi-tenant computing platform communicates with multiple different cloud service providers, each cloud service provider providing corresponding storage services to the tenants of the multi-tenant computing platform. A unified data model for the multi-tenant computing platform is obtained, wherein the unified data model provides each tenant of the platform with a corresponding logical view of a corresponding subset of the data structures associated with that tenant; An abstraction layer is provided, wherein the abstraction layer maps the corresponding attributes of each cloud service provider to the corresponding attributes of the unified data model; The abstraction layer allows a specific tenant to select a first storage solution from the first cloud service provider among the multiple different cloud service providers. Receive the first input from the specific tenant; In response to the first input and based on the mapping between the corresponding attributes of the first cloud service provider and the corresponding attributes of the unified data model, a first set of storage instructions is executed, the execution causing a first logical data manipulation associated with the corresponding data structure of the particular tenant and the corresponding storage service of the first cloud service provider; Through the abstraction layer, the specific tenant can be switched from the first storage solution to the second storage solution of the second cloud service provider among the multiple different cloud service providers without being notified; Receive a second input from the specific tenant, wherein the second input is the same as the first input; In response to the second input and based on the mapping between the corresponding attribute of the second cloud service provider and the corresponding attribute of the unified data model, a second set of storage instructions is executed, the execution causing a second logical data manipulation associated with the specific tenant and the corresponding storage service of the second cloud service provider, wherein the second logical data manipulation is the same as the first logical data manipulation.

Images