Data record correlation and migration

Abstract

To provide a method, a system and a program that enable correlation and sharing of a data record across different cloud-service instances.SOLUTION: A method that correlates data records with each other between cloud-service instances to share such records includes: receiving a request for correlating the data records with each other at a source cloud-service instance; detecting a change in the data record by a data record monitoring service; deciding a data record correlation; and providing the version of the corrected data record to an approved receiving side. The corrected data record is provided only after an outbound processing step is executed to create a new version of the data record.SELECTED DRAWING: Figure 3

Description

Background Art

[0001] With cloud-based solutions, companies can access services (such as various business workflows and management services) without necessarily implementing or hosting the services themselves. These services often rely on various data sources, such as data provided by customers and third parties. By leveraging data sharing, services can be provided access to additional data sources (particularly test data sets, production data sets, third-party data sets, and their own customer data sets, etc.). In some configurations, data sharing enables data to be shared across different services and by different groups, where groups can correspond to different departments within a company (such as the human resources department and the legal department) or different companies.

Brief Description of the Drawings

[0002] In the following detailed description and the accompanying drawings, various embodiments of the present invention are disclosed.

[0003] [Figure 1] A block diagram showing an embodiment of a data record correlation and sharing system.

[0004] [Figure 2] A block diagram showing an embodiment of a cloud service instance that supports data record correlation and sharing.

[0005] [Figure 3] A flowchart showing an embodiment of a process for correlating and sharing data records between cloud service instances.

[0006] [Figure 4] A flowchart showing an embodiment of a process for processing a request to correlate and share data records between cloud service instances.

[0007] [Figure 5] A flowchart illustrating one embodiment of the process for sharing correlated data records between cloud service instances.

[0008] [Figure 6] A flowchart illustrating one embodiment of the process for handling the receipt of updated correlated data records provided by a source cloud service instance.

[0009] [Figure 7] A flowchart illustrating one embodiment of the process for migrating correlation configurations between cloud service instances.

[0010] [Figure 8] A flowchart illustrating one embodiment of the process for migrating a correlated configuration to a new target cloud service instance.

[0011] [Figure 9] A functional diagram illustrating a computer system programmed to perform data record correlation and sharing.

[0012] [Figure 10] A diagram illustrating one embodiment of a user interface for viewing correlation requests.

[0013] [Figure 11] A diagram illustrating one embodiment of a user interface for displaying target instances related to a correlation request.

[0014] [Figure 12] A diagram illustrating one embodiment of a user interface for displaying a correlation index used to capture a portion of the correlation structure.

[0015] [Figure 13]A diagram illustrating one embodiment of a user interface for configuring capture events related to sharing correlated data records.

[0016] [Figure 14] A diagram illustrating one embodiment of a user interface for displaying outbound processing configurations related to correlation requests. [Modes for carrying out the invention]

[0017] The present invention can be implemented in various forms, including processes, apparatus, systems, compositions of materials, computer program products embodied on computer-readable storage media, and / or processors (processors configured to execute instructions stored and / or provided by memory attached to the processor). In this specification, these embodiments or any other forms the present invention may take may be referred to as "technologies." Generally, the order of the processes of the disclosed processes may be modified within the scope of the invention. Unless otherwise specified, components such as processors or memory described as configured to perform a task may be implemented as general components temporarily configured to perform a task at a given time, or as specific components manufactured to perform a task. As used herein, the term "processor" refers to one or more devices, circuits, and / or processing cores configured to process data such as computer program instructions.

[0018] Hereinafter, while referring to the drawings showing the principles of the present invention, a detailed description of one or more embodiments of the present invention will be given. The present invention is described in relation to such embodiments, but is not limited to any embodiment. The scope of the present invention is limited only by the claims, and the present invention includes many alternatives, modifications, and equivalents. In the following description, many specific details are set forth in order to provide a thorough understanding of the present invention. These details are for purposes of illustration only, and the present invention can be practiced without some or all of these specific details in accordance with the claims. For the sake of simplicity, well-known technical matters related to the technical field of the present invention are not described in detail so that the present invention is not made unnecessarily difficult to understand.

[0019] The correlation and migration of application-level data are disclosed. Using the disclosed technology, correlation and sharing of data records across different cloud service instances are enabled by correlating data records between a source instance and a target instance. Further, the correlation and sharing of data records can be configured as a cascading chain in which the target instance can also function as a source instance together with a second target instance. In various embodiments, the instances sharing data can be on the same application server (such as under different application instances), or on different application servers remote from each other (such as on different network domains). In the disclosed embodiments, data correlation is performed at the application layer, enabling correlated data to be modified on the fly when shared between instances. For example, the correlation and sharing of data can be configured to share only a portion of the fields of a data record from a source instance to a target instance. Further, when data is correlated, data transformation, complementation, and / or enhancement can be performed on the source instance, the target instance, or both instances, along with other data processing steps.

[0020] In various embodiments, data record correlation and sharing processes perform inbound and / or outbound processing on correlated data records. For example, data records corresponding to company assets may be correlated and shared between a source application instance and a target application instance. If the shared asset data record is modified in the source application instance, outbound data processing is performed on the modified data record before the modified data record is identified and a version of the data is provided to the target application instance. In various embodiments, as part of the data record correlation and sharing process, some fields of the correlated asset data record may be shared, and some fields may be excluded from sharing. For example, the fields asset identifier, asset description, asset owner, and asset assignment location may be configured for sharing, while the fields asset owner home address and asset owner home phone number may be excluded. Furthermore, as part of outbound data processing, one or more records (such as the asset assignment location field) may be modified to remove potentially personally identifiable information before the relevant data fields are provided to the target instance. In the target instance, data correlation and sharing processes can handle all input data records and perform further inbound data processing (transformation, completion, enhancement, or other data processing). For example, an input correlated asset data record may have a value automatically assigned to its delegate owner field based on the asset description and modified asset assignment location field values. Furthermore, external sources may be accessed via databases, the web, the internet, and / or API queries to enhance the input data. For example, a list of recent software updates for the assets referenced by the input asset data records may be retrieved and stored in the target instance along with modified versions of the input asset data records.Once inbound data processing is complete for the input data record at the target instance, the data correlation and sharing process is repeated to provide the second target instance with the corrected version of the correlated data record if the corrected data record is correlated to the second target instance. In various embodiments, loops or cycles are detected during the data correlation and sharing process to prevent infinite loops of chained updates. For example, updates may be tracked by using version numbers to prevent loops, and / or by tracking the nodes and / or edges traversed during correlated data record event updates.

[0021] In various embodiments, correlated data records between two instances can be migrated from an original target instance to a new (potentially) different target instance. For example, a source application instance can be configured to approve sharing of correlated data records with a first target application instance. If the first target instance is invalidated or deactivated, the correlation between the source instance and the first target instance is invalidated and saved for potential future migration. In various embodiments, the correlation is stored in a correlation index, and the correlation index is updated when the first target instance is no longer reachable and / or when the correlation is invalidated, e.g., by an administrator. When previously correlated records are migrated, e.g., when prompting an administrator to migrate the correlation to a second target application instance, the correlation index is updated to assign the correlation of the appropriate data records to the second target instance. In some embodiments, the second target instance can be the first target instance, e.g., if the first target instance is reactivated or re-enabled. In some embodiments, the second target instance can be an application instance on the same application server as the source application instance, or an application instance associated with a different application server (such as a remote application server connected via a network).

[0022] In some embodiments, as part of the migration process, data records from the source application instance and the new target application instance are correlated, the correlated data records are compared, and the records in the appropriate instance are updated. For example, based on the migration configuration, as part of the initial migration event, depending on which instance is configured as the authoritative source during the migration event, the source instance can update the target instance, or conversely, the target instance can update the source instance. In various embodiments, during the initial migration, certain migration configurations allow the target instance to update the source instance, rather than the source instance updating the target instance. Once the migration is complete, the modifications to the records in the source instance are used to update the target instance, based on the original correlation configuration. In various embodiments, the updated correlations to the data records are reflected in the directional correlation entries in the correlation index.

[0023] In some embodiments, a correlation request for data records of a first application instance is received by the first application instance from a second application instance. For example, the second application instance (such as a second cloud service instance) requests to receive updates to data records managed by the first application instance (such as the first cloud service instance). In some embodiments, upon determination that the correlation request has been approved, the correlation index is updated with a directional correlation entry. For example, an administrator of the first application instance may approve the correlation request. As another example, an access configuration and / or access rule installed and / or configured on the first application instance is used to approve the correlation request. Once the correlation request is approved, a directional correlation entry referencing the data records managed by the first application instance is inserted into the correlation index used to track correlated data records and their target instances. In some embodiments, the correlated data records of the first application instance may not (yet) exist in the first instance, and the established correlation lies among potential data records of the first instance that satisfy the correlation requirements. For example, the first and second application instances can be correlated prior to the existence of a correlated data record in the first instance, and sharing can be automatically triggered when a version of the correlated data record is created in the first instance.

[0024] In some embodiments, upon determining that a data record has been modified, the updated correlation index is used to determine whether the modified data record should be provided to a second application instance for correlation. For example, when a data record tracked by the correlation index is modified (or created), a version of the modified data record is provided to the second application instance. In some embodiments, a new version of the modified data record is provided to the second application instance. For example, outbound data processing on the modified data record may be performed to create a new version of the modified data record to be provided to the second application instance. The modification may include filtering, correction, completion, transformation, and / or other outbound data processing steps to create a new version of the modified data record for the second application instance. In some embodiments, the second application instance receives its version of the modified data record for storage in the second application instance. As part of inbound data processing performed in the second application instance, the input data record may be further manipulated to create a new version of the data record provided by the first application instance for storage in the second application instance. In various embodiments, the correlation index of the second application instance is used to determine whether further correlation and sharing processing for other target instances is required for the modified records of the version managed by the second application instance.

[0025] Figure 1 is a block diagram illustrating one embodiment of a data record correlation and sharing system. In the example shown, a client (e.g., client 101) accesses one or more cloud services hosted by cloud service instances 111, 121, and 131. In some embodiments, client 101 is an example of a management client used to manage the correlation and sharing of data records and the migration of configured data record correlations. In various embodiments, there are multiple clients (e.g., client 101) to access and / or manage different cloud service instances (e.g., cloud service instances 111, 121, and 131). Each of the cloud service instances 111, 121, and 131 utilizes a data store (e.g., data stores 113, 123, and 133). Client 101 and each of the cloud service instances 111, 121, and 131 are communicated via a network 151. Network 151 may be a public or private network. In some embodiments, network 151 is a public network such as the Internet. The services hosted by cloud service instances 111, 121, and / or 131 may be a variety of cloud-based services, such as services that manage digital workflows for enterprise operations, and may depend on the ability to correlate and share data records between different cloud instances. For example, cloud service instances 111, 121, and 131 correlate and share data records that they each store on data stores 113, 123, and 133, respectively.

[0026] In some embodiments, client 101 is a network client for accessing and / or managing the cloud services of cloud service instances 111, 121, and 131. For example, using a web browser client, client 101 can access web services hosted by cloud service instances 111, 121, and / or 131. In some embodiments, client 101 corresponds to a specific customer and / or account, and each cloud service instance is associated with a specific customer and / or account. In some embodiments, client 101 is a desktop computer, laptop, mobile device, tablet, kiosk, voice assistant, wearable device, or another network computer device. In various embodiments, client 101 may be used to manage the correlation and sharing of data records managed by cloud instances (such as cloud service instances 111, 121, and 131). For example, client 101 may be used to configure the correlation and sharing of data records and the migration of correlation configurations between cloud service instances.

[0027] In some embodiments, cloud service instances 111, 121, and / or 131 are application instances that provide one or more application services (such as cloud-based services). For example, each of the cloud service instances 111, 121, and 131 can provide application services for managing and executing digital workflows, such as enterprise business workflows. In some embodiments, each instance represents an instance accessible by a specific entity (such as a user account or a corporate account). In some embodiments, each entity may correspond to a different company, customer, department within an organization, or another logically isolated unit. Although shown as separate components in Figure 1, one or more of the cloud service instances 111, 121, and / or 131 may reside on and / or be implemented using the same computer instance. For example, in some embodiments, the cloud service instances 111, 121, and / or 131 may be hosted by the same application server with logical boundaries to isolate the different instances. From the perspective of different user clients, each of these cloud service instances may appear to reside on a functionally different computer system.

[0028] In various embodiments, cloud service instances 111, 121, and / or 131 utilize data records to support the cloud-based services they provide. For example, each cloud instance can utilize data records (such as data records hosted by a data store or database) to support the cloud services it provides. In some embodiments, data records can be correlated between different cloud instances, such as between cloud service instances 111, 121, and / or 131. For example, an administrator of one cloud service instance can request correlation of data records managed by another cloud service instance. If approved, a data record correlation and sharing process is initiated, which allows the requesting cloud instance to receive the modified version of the correlated data record upon modification or update of the correlated data record. In various embodiments, the configured correlations can be further migrated from one cloud service instance to another. For example, correlations between development instances can be migrated to a production instance. As another example, correlations between instances of a first third-party vendor can be migrated to instances of a second third-party vendor. In various embodiments, cloud service instances 111, 121, and / or 131 can each utilize a data correlation module (not shown in Figure 1) to perform correlation and sharing of data records and migration of correlation configurations.

[0029] In some embodiments, cloud service instances 111, 121, and 131 utilize data stores 113, 123, and 133, respectively, to manage data containing data records. For example, cloud service instances 111, 121, and 131 store and retrieve data records on data stores 113, 123, and 133, respectively. Unless specifically configured to correlate or share data records, data stores 113, 123, and 133 are accessible only by their respective cloud service instances. However, using the disclosed technology, data records stored in each data store can be correlated and shared among cloud instances by correlating and sharing data records between different cloud service instances. In various embodiments, data correlation and sharing configurations for cloud instances may be stored in the cloud instance's configured data store. For example, cloud service instances 111, 121, and 131 can utilize data stores 113, 123, and 133, respectively, to store data record correlation and sharing configurations. In some embodiments, each of the data stores 113, 123, and / or 133 is implemented using one or more data stores (such as one or more distributed data store servers). For example, although shown as a single entity in Figure 1, data store 113 may be implemented as one or more distributed data store components connected to the cloud service instance 111 via the network 151.

[0030] For the sake of simplification, some components are illustrated individually in Figure 1, but additional components shown in Figure 1 may exist. For example, cloud service instances 111, 121, and / or 131 may comprise one or more servers and / or share servers. Similarly, data stores 113, 123, and / or 133 may each comprise one or more data store servers. In some embodiments, data stores 113, 123, and / or 133 may not be directly connected to cloud service instances 111, 121, and / or 131, respectively. For example, data stores 113, 123, and / or 133 and their components may be replicated and / or distributed across multiple servers and / or components. In various embodiments, client 101 is merely an example of a potential client to a cloud service instance. In some embodiments, components not shown in Figure 1 may exist.

[0031] Figure 2 is a block diagram illustrating one embodiment of a cloud service instance that supports data record correlation and sharing. In the example shown, the cloud service instance 201 is an application instance that supports and implements a cloud service (such as an application service for managing and implementing digital workflows, such as workflows for business operations). The cloud service instance 201 comprises many different components not shown, but two components are shown: a data correlation module 211 and a network communication layer 251. In various embodiments, these two components are used to support data record correlation and sharing. The data correlation module 211 is communicatively connected to the network communication layer 251, which is connected to and / or interfaces with a network connection 253. The cloud service instance 201 is communicatively connected to one or more networks (such as the Internet) via the network connection 253, and accordingly, the cloud service instance 201 is communicatively connected to other network components not shown. In some embodiments, the cloud service instance 201 is an application instance (such as the cloud service instances 111, 121, and / or 131 in Figure 1), the network connection 253 is connected to the network 151 in Figure 1, and / or the cloud service instance 201 is connected to a data store (such as the data stores 113, 123, or 133 in Figure 1) and is communicated to the data store.

[0032] As shown in the example in Figure 2, the data correlation module 211 of the cloud service instance 201 comprises several components that support the correlation and sharing of data records, including a request approval module 221, an event capture module 223, a correlation index 225, an outbound capture queue 231, an outbound processing module 233, an inbound processing module 243, and an inbound capture queue 241. In various embodiments, the components of the data correlation module 211 may be fewer or more, and / or some of the components shown in the figure may be implemented as fewer or more components. In the example in the figure, the request approval module 221 manages the approval of data correlation requests, such as data record correlation requests and migration requests. For example, an incoming or requested data record correlation request is managed by the request approval module 221. Similarly, an incoming or requested data record correlation migration request is managed by the request approval module 221. In some embodiments, requests are managed and tracked by both the party generating the request and the party receiving the request. For example, the requesting party can track the status of the request, such as whether the request was approved or rejected. In contrast, the receiving party must first approve the request before it can be granted. In some embodiments, the approval process is a manual process that requires human intervention (such as an authorized administrator) to initiate and / or approve requests, including data correlation requests and migration requests. In some embodiments, the approval process is an automated or semi-automated process. For example, requests may be approved based on configured permissions and / or access rights, such as granted sharing permissions / authorities that specify which accounts and / or cloud service instances are allowed access to particular data records and their fields.

[0033] In some embodiments, the event capture module 223 is used to manage events related to correlated data records. For example, a modified data record may match a configured data record correlation configuration. This modification is identified and processed by the event capture module. For example, the event capture module monitors for modifications to data records to identify records that have a correlation configuration. A capture event is created for the modified record that has a matching correlation configuration. In some embodiments, the modification required to trigger an event includes specific trigger event requirements. For example, a modification to a related data record must match a configured event requirement trigger to create an event. If the trigger requirement is met, the created event may be used to process the modified data record for sharing. In various embodiments, once an event is captured, it is processed using the outbound capture queue 231. For example, captured events are inserted into the outbound capture queue 231, where they may be processed within the resource limits and requirements of the cloud service instance 201.

[0034] In some embodiments, data record correlations are stored and managed using a correlation index 225. For example, the correlation index 225 is used to manage and track data records and their correlation and sharing requirements between different cloud service instances (e.g., between different application instances). In some embodiments, the correlation index 225 stores a correlation identifier used to uniquely identify a data record correlation configuration, the data records and database tables to which the correlation applies, identifiers of the source cloud instance and / or target cloud instance, and the state of the correlation configuration. In various embodiments, the state of a correlation configuration can be active or inactive. Other potential values ​​for the state may include pending approval or request, rejected, pending migration, or another appropriate state. In some embodiments, each correlation configuration is a correlation entry stored in a correlation database table. Other parameters related to the correlation configuration may also be appropriate, such as domain parameters, access credentials (e.g., credentials required for sharing / accessing data records), and correlation history, including data record migration history. In some embodiments, the correlation index 225 includes configurations for inbound and / or outbound processing performed on shared versions of the correlation data records.

[0035] In some embodiments, the data correlation module 211 includes an outbound pipeline comprising at least outbound components, namely an outbound capture queue 231 and an outbound processing module 233. These outbound components are used to process the correlation and sharing of output data records based on capture events corresponding to the modified correlation data records. Using the outbound capture queue 231 and the outbound processing module 233, the modified version of the correlation data record is provided to the target cloud service instance defined by the correlation configuration. For example, an event stored in the outbound capture queue 231 may be processed and removed from the outbound capture queue 231 at an appropriate time, based on scheduling and / or resource availability, etc. Once an event is removed from the outbound capture queue 231, it may be processed by the outbound processing module 233 to perform any configured outbound processing steps. For example, the outbound processing module 233 may be used to modify correlated data records by determining which fields of the correlated data records are shared, correcting the values ​​of specific fields in the data records, and / or supplementing the data records with additional information (such as additional fields). In some embodiments, the outbound processing module 233 may retrieve additional information from third-party sources, etc., to supplement the information provided by the correlated data records. Once the outbound processing is complete, the processed version of the correlated data records is provided to the target cloud service instance. For example, the processed version of the data records may be packaged as part of an update and provided to the network communication layer 251 for transfer to the appropriate target cloud service instance via the network connection 253.

[0036] In various embodiments, the inbound pipeline of the data correlation module 211 for processing updated data records is similar to the outbound pipeline. In some embodiments, the data correlation module 211 includes an inbound pipeline for receiving data record updates, which includes at least inbound components, namely an inbound capture queue 241 and an inbound processing module 243. When an update is received via the network connection 253 and forwarded to the data correlation module 211 by the network communication layer 251, the update event is stored in the inbound capture queue 241. In various embodiments, the inbound capture queue 241 may be used to suppress updates so that updates can be processed without becoming excessive for the resources of the cloud service instance 201. For example, events stored in the inbound capture queue 241 may be processed and removed from the inbound capture queue 241 at an appropriate time, based on scheduling and / or resource availability, etc. Once an event is removed from the inbound capture queue 241, it may be processed by the inbound processing module 243 to perform any configured inbound processing steps. For example, the inbound processing module 243 may be used to modify the received version of the correlated data record by determining which fields of the received correlated data record to store, correcting the values ​​of specific fields in the received data record, and / or supplementing the received data record with further information (such as additional fields). In some embodiments, the inbound processing module 243 may retrieve further information from a third-party source, for example, to supplement the information provided by the received correlated data record. Once the inbound processing steps are complete, the processed version of the received correlated data record may be stored by the cloud service instance 201, for example, in the associated data store.In some embodiments, data records are written to the associated database of the cloud service instance 201 via the network communication layer 251 and the network connection 253. In some embodiments, the inbound processing step may decide not to store the received correlation data record and / or to update other associated records about the target instance in place of or in addition to the correlation data record. For example, the inbound processing module 243 may determine that the received correlation data record does not match an entry in the correlation index 225.

[0037] In some embodiments, the network communication layer 251 is a network interface component for managing input and output network communications. For example, an output version of a data record for sharing is provided to the network communication layer 251 by the data correlation module 211 for transfer to a target cloud service instance via the network connection 253. Similarly, an updated version of a correlated data record received via the network connection 253 is provided to the data correlation module 211 by the network communication layer 251. In some embodiments, the network communication layer 251 may be used as an interface for retrieving and / or storing data records from an associated data store or database. For example, a correlated data record identified for sharing may be retrieved from the associated database via the network communication layer 251 and the network connection 253. Similarly, the received data record may be stored in the associated database by the target cloud service instance via the network communication layer 251 and the network connection 253.

[0038] Figure 3 is a flowchart illustrating one embodiment of a process for correlating and sharing data records between cloud service instances. For example, using the process in Figure 3, a source cloud service instance may be configured to correlate one or more data records and share them with a target cloud service instance. When the correlated data records in the source cloud service instance are modified, the modified version of the data records is shared with the target cloud service instance. In various embodiments, the correlation configuration is managed by a data correlation module on the source cloud service instance and / or the target cloud service instance. For example, both the source instance and / or the target instance may track data record correlations using their respective data correlation modules, each containing its own correlation index. In some embodiments, the process in Figure 3 is executed on the source cloud service instance in response to a correlation request from the target cloud service instance. Although the process in Figure 3 describes the correlation of a single data record, the process is applicable to the correlation and sharing of multiple data records or groups of data records. In some embodiments, the source cloud service instance and the target cloud service instance are different application instances within the cloud service instances 111, 121, and 131 in Figure 1. In some embodiments, correlation data records are stored in a data store associated with the source cloud service instance (such as data stores 113, 123, or 133 in Figure 1). In some embodiments, the data correlation module used to manage the correlation configuration is the data correlation module 211 in Figure 2.

[0039] In step 301, a request to correlate data records is received. For example, a data record correlation request is received by the source cloud service instance. In some embodiments, the request is initiated by the target cloud service instance. For example, the administrator of the target cloud service instance may configure a data record correlation request and send it to the source cloud service instance. In various embodiments, the correlation request specifies the data records of the source cloud service instance. In some embodiments, the request includes an identifier of the requesting party (e.g., the target cloud service instance) and an identifier used by the target instance to refer to the correlation request. In some embodiments, the request may include access credentials to the target cloud service instance. For example, access credentials provided in the request may be used by the target cloud service instance to authenticate and / or authorize the version of the data records provided by the source cloud service instance. In some embodiments, the correlation request is a migration request. For example, a migration request includes migrating data records previously correlated from another target cloud service instance to the current point in time from the source cloud service instance to the target cloud service instance requesting the migration. In some embodiments, the requested correlation data record for a source cloud service instance may not yet exist in the source cloud service, and the requested correlation is based on potential data records in the source instance that satisfy the correlation requirements. For example, if a correlation request is approved, the source application instance and the target application instance may be correlated prior to the existence or creation of a correlation data record in the source cloud service instance.

[0040] In various embodiments, once a correlation request is considered and approved, a correlation configuration is created for the requested data record. Once the correlation configuration is created, modifications to the correlated data record may be monitored to detect changes or updates to the data record. Any updates to the data record, such as creating or deleting a data record that meets the correlation requirements, may result in sharing a modified version of the data record with the target cloud service instance. In some embodiments, the initial approval of the correlation request triggers detected modifications, leading to the provision of a version of the data record to the target cloud service instance.

[0041] In step 303, modifications to data records are detected. For example, changes to data records are detected by the data record monitoring service. In various embodiments, any changes to data records in the source cloud service instance are detected. Changes may include any updates to any field in any data record, and the creation or deletion of data records. In some embodiments, only a portion of the data records may be monitored, and the ability to correlate data across cloud service instances is limited to the data records that can be monitored.

[0042] In step 305, data record correlations are determined. For example, changes to a data record detected in step 303 are compared to the configured correlations. If the change matches the configured correlation, the data record change triggers an update to the associated target cloud service instance. In some embodiments, the update reflects the deletion of the correlated data record in the source instance. In various embodiments, a set of one or more trigger event requirements that must be met to trigger the sharing of a data record may be configured. For example, a data record may be configured to update only a specific target cloud service instance when certain trigger event requirements are met (e.g., a specific field of the data record is updated, the update is performed by a specific user, and the update is performed within a specific time window). Based on the configured requirements, simply updating a field in a correlated data record may not satisfy the configured requirements for sharing the data record. If the configured sharing requirements are met, the data record is marked for sharing to the appropriate target cloud instance. In some embodiments, a correlation index is used to determine the appropriate data record correlations, including the approved target cloud service instances.

[0043] In step 307, the modified version of the data record is provided to the approved recipient. For example, a version of the data record with the modifications detected in step 303 and the correlation determined in step 305 is provided to the approved target cloud service instance. In some embodiments, the modified data record is provided only after the outbound processing step has been performed to create a new version of the data record. The new version of the data record shared with one or more target instances may include modified values ​​for the data record fields and fewer or more fields. For example, some fields may be removed from the data record before it is shared, and additional fields may be added and incorporated into the shared version of the data record. The new version of the data record is provided to the approved cloud service instance using the correlation results determined in step 305.

[0044] Figure 4 is a flowchart illustrating one embodiment of a process for handling requests to correlate and share data records between cloud service instances. For example, using the process in Figure 4, a source cloud service instance processes a correlation request received from a target cloud service instance. If the request is approved, a correlation configuration is created that allows the target instance to receive updates to the correlated data records. In some embodiments, the process in Figure 4 is performed in step 301 of Figure 3. In some embodiments, the source and target cloud service instances are different application instances within the cloud service instances 111, 121, and 131 in Figure 1. In some embodiments, the correlated data records are stored in a data store associated with the source cloud service instance (such as data stores 113, 123, or 133 in Figure 1). In some embodiments, the data correlation module used to manage the correlation configuration is the data correlation module 211 in Figure 2.

[0045] In step 401, the received data record correlation request is decoded. For example, a correlation request is received and decoded to determine the request parameters. In various embodiments, the data record for which correlation is requested and its associated database table are decoded and identified. For example, once the requested data record and table are identified, the request may be matched with existing database tables and potential data records (if any). In some embodiments, the requested correlated data record may not (yet) exist in the source cloud service, and the requested correlation lies among potential data records of the source instance that satisfy the correlation requirement. In some embodiments, further information is decoded from the correlation request (e.g., the target cloud service instance requesting correlation among other parameters of the request). In some embodiments, the request includes access credentials or authorization credentials. For example, the request may provide access credentials, such as an access token that helps validate messages from the source instance to the target instance or from the target instance to the source instance.

[0046] In step 403, the approval status of the correlation request is determined. For example, once the correlation request is decrypted, the correlation request is either approved or rejected. The decision to approve or reject the request determines the approval status of the request. In various embodiments, approval of a correlation request is provided by the administrator of the source cloud service instance. For example, the administrator is provided with a prompt requesting that the correlation request be approved or rejected. In certain embodiments, the prompt may include information describing the correlation request, such as the table related to the requested data record, a description of the data record, the parameters of the correlation request, and the target instance requesting the correlation. In some embodiments, approval is automated or semi-automated based on configured approval rules. For example, approval rules may be configured to allow a particular target instance to access a particular database table and record. Configured permissions may be applied to approve or reject the correlation request. In various embodiments, the approval status corresponds to whether the correlation request has been approved or not.

[0047] In step 405, it is determined whether the request has been approved or not. If the request has been approved, the process proceeds to step 407. If the request has not been approved, the process is completed. Although not shown in Figure 4, in some embodiments, if the request has not been approved or has been rejected, a rejection response is provided to the requesting cloud service instance to notify that instance of the rejection.

[0048] In step 407, the correlation index is updated with a directional correlation entry. For example, the correlation index of the data correlation module of a cloud service instance is updated to reflect an approved data record correlation request. In various embodiments, a directional correlation entry is inserted into the correlation index, referencing two application instances, such as from a source cloud service instance to a target cloud service instance. In some embodiments, the correlation entry includes a unique correlation identifier for the data record correlation, an identifier for the correlated data record, an identifier for the table of correlated data records, a unique identifier for the corresponding correlation entry stored in the target instance, an identifier or reference to the target instance, the state of the correlation entry, and the domain associated with the correlation entry. In some embodiments, the correlation entry may include further correlation configuration information, particularly outbound processing steps to be performed when the data record is shared, requirements that must be met to trigger the sharing of the data record, and access authentication information. For example, the correlation entry may be updated with the access authentication information associated with the correlation entry and a target instance that may be used to provide updates to the target instance when the data record for which the correlation has been approved is modified. In some embodiments, a response is provided to the requesting cloud service instance, notifying that instance of the approved correlated request.

[0049] Figure 5 is a flowchart illustrating one embodiment of a process for sharing correlated data records between cloud service instances. For example, using the process in Figure 5, a modified version of a data record is shared between a source cloud service instance and a target cloud service instance. In various embodiments, the process in Figure 5 is performed by the source cloud service or application instance in response to detection of modifications to correlated data records. Depending on the correlation configuration, a target cloud service instance that receives updated data for correlated data records may also function as a source cloud service instance for another target cloud service. For example, data record correlation can form a cascading chain where modifications to data records in an upstream cloud service instance trigger modifications along a chain of downstream cloud service instances, such that each instance in the chain is updated, and the next dependent instance is updated in turn.

[0050] In some embodiments, a data correlation module of the source cloud instance (such as the data correlation module 211 of the cloud service instance 201 in Figure 2) is used in the process of Figure 5 to handle the correlation and sharing of correlated data records. For example, a correlation index (such as the correlation index 225 in Figure 2) may be used to identify the modified data records in the correlation configuration or correlation entry. Capture events may then be identified and created using the event capture module 223 in Figure 2, and outbound events may be inserted into the outbound capture queue 231. As events are processed, the outbound processing module 233 may perform outbound processing steps to prepare the modified version of the data record for sharing with the authorized target cloud service instance. In some embodiments, the process of Figure 5 is performed in steps 303, 305, and / or 307 in Figure 3. In some embodiments, the source cloud service instance and the target cloud service instance are different application instances within the cloud service instances 111, 121, and 131 in Figure 1. In some embodiments, the correlated data records are stored in a data store associated with the source cloud service instance (such as data stores 113, 123, or 133 in Figure 1).

[0051] In step 501, a correlation entry for the modified data record is determined. For example, a correlation index is used to identify a directional correlation entry for the modified data record based on the data record and its database table. In some embodiments, the directional correlation entry includes solution information, including the relevant target and source application instances or cloud service instances. In some embodiments, the directional correlation entry is used, at least in part, to determine that the detected modification does not create an unnecessary loop. For example, the directional correlation entry may include version information to determine whether this version update has been processed previously. As another example, by tracking edges circulated between a graph of cloud service instances, the directional correlation entry may be used to determine whether the update has been seen previously by this cloud service instance. Loop detection can be performed in step 501, but in some embodiments, loop detection and prevention operations are performed in a separate step when processing the correlation and sharing of data records.

[0052] In step 503, the appropriate capture event is determined. For example, the appropriate capture event is determined using the correlation configuration associated with the modified data record. In various embodiments, the correlated data record is shared only when the configuration requirements for sharing are met. These requirements are met when an event that satisfies the requirements is encountered. For example, a data record may be configured to update only a specific target cloud service instance when a specific field of the data record is updated, the update is performed by a specific user, and the update is performed within a specific time window. Based on the configured requirements, simply updating a field of the correlated data record may not satisfy the configured requirements for sharing the data record. In various embodiments, the appropriate capture event is identified only when the configured sharing requirements are met.

[0053] In step 505, the capture event is processed using a capture queue. For example, the capture event is inserted into an outbound capture queue and retrieved from the queue when a cloud service instance is available to process the event. In various embodiments, the capture queue is used to suppress the sharing of correlated data records on the source instance until the appropriate resources are available to process the pending capture event. In various embodiments, the capture queue enables the source cloud service instance to effectively manage the sharing of correlated data records.

[0054] In step 507, outbound data record processing is performed. For example, one or more processing steps are performed to modify the data record to create a version suitable for sharing. In some embodiments, a new version of the modified data record is created as a result. For example, one or more fields of the data record may be removed to prevent the sharing of sensitive, irrelevant, or unnecessary information. Similarly, one or more fields may be added to complement the data record with additional information. In some embodiments, existing fields may be further modified, for example, to convert the values ​​in the fields to values ​​or formats suitable for the target cloud service instance. In some embodiments, one or more data sources, such as external data sources, may be queried as part of the outbound processing steps. For example, a web query may be performed as part of the outbound processing performed in step 507 to retrieve information to modify existing ones and / or populate new fields in the data record.

[0055] In step 509, the corrected data record version is provided to the target cloud service instance. For example, the corrected data record version created in step 507 is packaged and provided to the target cloud service instance identified by the correlation entry determined in step 501. In some embodiments, the data record update is provided with access credentials (such as an access token) to improve security aspects related to the transfer of record data between cloud service instances. In some embodiments, once the provided version of the corrected data record is received by the target cloud service instance, the received data is further processed before being stored in the target instance's data store. In some scenarios, the provided data record update triggers a chain of updates based on the correlation in the target cloud service instance. In some embodiments, loops are prevented in the inbound pipeline of the target cloud service instance. For example, the corrected data record version provided in step 509 may include a version number used to detect duplicate or repeated updates.

[0056] Figure 6 is a flowchart illustrating one embodiment of a process for handling the reception of updated correlated data records provided by a source cloud service instance. For example, using the process in Figure 6, a version of a shared and modified data record provided by a source cloud service instance is received by a target cloud service instance. In various embodiments, the process in Figure 6 is performed by the target cloud service instance upon receiving the updated correlated data record. Depending on the correlation configuration, the target cloud service instance may modify the data record received during its inbound pipeline and store the new, modified version in the associated data store. In some embodiments, the data record update by the target cloud service instance may trigger further downstream updates if the updated data record is correlated with another target cloud service.

[0057] In some embodiments, a data correlation module of the target cloud instance (such as the data correlation module 211 of the cloud service instance 201 in Figure 2) is used in the process of Figure 6 to process the sharing of received correlated and shared data records. For example, a correlation index (such as the correlation index 225 in Figure 2) may be used to identify correlated and shared data records in a correlation configuration or correlation entry. The received data records are associated with capture events using the event capture module 223 in Figure 2, and inbound events may be inserted into the inbound capture queue 241. When an event is processed, the inbound processing module 243 can perform an inbound processing step to prepare a version of the shared data record stored in the relevant data store of the target cloud service instance. In some embodiments, the process of Figure 6 is performed in step 307 in Figure 3. In some embodiments, the source cloud service instance and the target cloud service instance are different application instances within the cloud service instances 111, 121, and 131 in Figure 1. In some embodiments, the correlated data records are stored in a data store associated with the target cloud service instance (such as data stores 113, 123, or 133 in Figure 1).

[0058] In step 601, a shared data record is received. For example, a source cloud service instance provides a data record for sharing with a target instance. In various embodiments, the shared data record is a recently modified version of a correlated data record. Based on the modification to the correlated data record, the target instance now receives the modified version of the data record prepared by the source instance. In some embodiments, correlated entries are identified in a correlated index to ensure that the received data record conforms to an approved correlated configuration. For example, the source instance and the data record and / or received metadata are matched to identify the corresponding correlated entry. In some embodiments, an event capture module is further used to match input data records to update events. For example, the characteristics of a data record update may be used to match configured update events that include an update requirement to update a version of the data record stored in the target cloud service instance.

[0059] In some embodiments, loops between instances are prevented in the inbound pipeline of the target cloud service instance. For example, a shared data record received in step 601 may include a version number used to detect duplicate or repeated updates. If an update causes a loop, the received data record does not need to be processed, and the version of the data record managed by the target instance is not updated.

[0060] In step 603, shared data records are processed using a capture queue. For example, an incoming data record can trigger the detection of an update event, which is captured as a capture event. For example, each incoming shared data record may be processed as a capture event using the capture queue. In some embodiments, a capture event is inserted into an inbound capture queue and retrieved from the queue when a cloud service instance is available to process the event. In various embodiments, the capture queue is used to suppress the sharing of correlated data records on a target instance until the appropriate resources are available to process the pending capture events. In various embodiments, the capture queue enables the target cloud service instance to effectively manage the sharing of correlated data records.

[0061] In step 605, inbound data record processing is performed. For example, one or more processing steps are performed to modify the received data record, such as creating a version for the target cloud service instance. In some embodiments, a new version of the received shared data record is created as a result. For example, one or more fields of the data record may be removed to filter out sensitive, irrelevant, or unnecessary information. Similarly, one or more fields may be added to complement the received data record with further information. In some embodiments, existing fields may be further modified, for example, to convert the values ​​in the fields to values ​​or formats appropriate for the target cloud service instance. In some embodiments, one or more data sources, such as external data sources, may be queried as part of the inbound processing steps. For example, a web query may be performed as part of the inbound processing performed in step 605 to retrieve information to modify existing ones and / or populate new fields in the received data record.

[0062] In some embodiments, the inbound processing step may decide not to store the received correlation data record and / or to update other relevant records about the target instance in place of or in addition to the correlation data record. For example, the inbound processing module 243 may determine that the received correlation data record does not match an entry in the correlation index, and the correlation data record is not stored in step 607. In some embodiments, the inbound processing step may result in updates, such as the deletion or deactivation of several data records managed by the target instance. If further data records are processed by the inbound processing step of step 605, the modified records may also be stored in step 607, if appropriate.

[0063] In step 607, the processed data records are stored. For example, the version of the shared-correlated data record received in step 601 is stored by the target cloud service instance in the data store associated with the target instance. In various embodiments, the revised data record version updated by the inbound processing performed in step 605 is stored along with any other processed data records affected by the determined correlation. In certain embodiments, the updated changes are also reflected in the correlation index. For example, in some embodiments, the correlation index of the data correlation module is updated to track which version of the data record is stored, allowing instances to prevent duplicate or repeated updates. In some embodiments, a list of cyclic instances related to data record updates is maintained to track previously updated cloud service instances as another or additional technique to prevent duplicate or repeated updates.

[0064] In some embodiments, storing the processed data records triggers the detection of modifications to the correlated data records. For example, if the processed data records are correlated as a source for another target instance, the step of storing the processed data records may trigger an update of the downstream target instance. In various embodiments, the downstream target instance is updated using the processing shown in Figures 3, 4, and / or 5.

[0065] Figure 7 is a flowchart illustrating one embodiment of the process for migrating correlation configurations between cloud service instances. For example, using the process in Figure 7, an approved data record correlation configuration between a first source cloud service instance and a first target cloud service instance may be migrated to link the correlation between the first source cloud service and a second target cloud service. In various embodiments, the process in Figure 7 is performed by the source cloud service instance in response to detecting that the first target cloud service instance has been deactivated or is no longer reachable, and further in response to receiving a migration request from the second target cloud service instance. In some embodiments, the process in Figure 7 is performed in step 301 of Figure 3. In some embodiments, the first source, first target, and second target cloud service instances are different application instances within the cloud service instances 111, 121, and 131 in Figure 1. In some embodiments, the correlation data records are stored in a data store associated with the source cloud service instance (such as data stores 113, 123, or 133 in Figure 1).

[0066] In step 701, it is determined that the target instance is no longer reachable. For example, the target instance of a correlation configuration may be deactivated and / or disabled and may no longer be reachable from the source instance. The source instance detects that the target instance is no longer available for sharing correlation data records and disables sharing of correlation data records with the target instance. In various embodiments, the correlation index in the source instance is updated for correlation entries that refer to the unreachable target instance. Once the appropriate correlation entry is disabled, updates to the correlation data record do not result in updates to the unreachable target instance. Although the data record is no longer provided to the unreachable target instance, the configuration for the previously approved correlation data record is not removed from the correlation index, but is instead simply disabled. In various embodiments, each correlation entry includes a history and / or log of changes, allowing administrators to track the status and changes to the entry over time.

[0067] In some embodiments, step 701 is optional, and the migration request may be processed without first detecting that the original target instance is unreachable. In various embodiments, the deactivation of the corresponding correlation entry may instead be initiated by an administrator (such as the administrator of the source instance and / or target instance). For example, the target instance may provide the source instance with a request to disable the data record correlation. As another example, the administrator of the source instance may disable the correlation with the target instance, regardless of whether the target instance is active, reachable, and / or has agreed to the disabled correlation.

[0068] In step 703, a migration request for a new target instance is received. For example, a request is received to migrate configured correlations from the previous target instance to the new target instance. In some embodiments, the migration request is provided by the new target instance. Alternatively, the migration request may be provided by the source instance, such as by the source instance's administrator. In some embodiments, the migration request is provided by the old target instance. In some embodiments, the migration request is made automatically or semi-automatically. For example, the migration request may be automatically initiated by one or more failover configurations.

[0069] In various embodiments, a migration request is a type of correlation request, specifying, among other migration parameters, at least the data records for correlation and the new target instance. In some embodiments, the migration request includes access authentication information, an identifier for the database table of the correlation data records, one or more correlation entry identifiers, and / or an identifier for the old target instance.

[0070] In step 705, the approval status of the migration request is determined. For example, when a migration request is received, the request is either approved or rejected. The decision to approve or reject the request determines the approval status of the request. In various embodiments, approval of a migration request is provided by the administrator of the source cloud service instance. For example, the administrator is provided with a prompt requesting that the migration request be approved or rejected. In certain embodiments, the prompt may include information describing the migration request, such as the database tables related to the correlated data records, a description of the correlated data records, the parameters of the migration request, and the new and / or old target instances to be included in the migration. In some embodiments, approval is automated or semi-automated based on configured approval rules. For example, approval rules may be configured to allow a particular target instance to access a particular database table and record. Configured permissions may be applied to approve or reject the migration request. In some embodiments, approval and migration rules may be configured to automatically initiate and approve migration requests based on events (such as detected failures or scheduled migration events). In various embodiments, the approval status is based on whether or not the migration request has been approved.

[0071] In step 707, it is determined whether the request has been approved or not. If the request has been approved, the process proceeds to step 709. If the request has not been approved, the process is completed and the migration is not performed. Although not shown in Figure 7, in some embodiments, if the request has not been approved or has been rejected, a rejection response is provided to the requesting cloud service instance to notify that instance of the rejection.

[0072] In step 709, the relevant correlation configuration is migrated, and the source instance and the new target instance are synchronized. For example, an approved migration migrates the correlation configuration from using the old target instance to using the new target instance, and synchronizes the newly correlated data records. In some embodiments, as part of the migration process, once the data records of the source application instance and the new target application instance are correlated, the correlated data records are compared, and the records in the appropriate instance are updated. For example, depending on which instance is configured as the authoritative source during the migration event, based on the migration configuration, the source instance can update the target instance, or conversely, the target instance can update the source instance. In various embodiments, during the initial migration, certain migration configurations allow the target instance to update the source instance, rather than the source instance updating the target instance. Once the migration is complete, the modifications to the records in the source instance are used to update the target instance, based on the original correlation configuration. In various embodiments, the updated correlations to the data records are reflected in the directional correlation entries in the correlation index.

[0073] Figure 8 is a flowchart illustrating one embodiment of the process for migrating correlation configurations to a new target cloud service instance. For example, using the process in Figure 8, the source cloud service instance processes an approved migration request by updating its correlation index to identify the appropriate configured correlations and migrate them from the old target instance to the new target instance. In various embodiments, both the source and target instance correlation indexes are updated to reflect the migration. In some embodiments, the process in Figure 8 is performed in step 709 of Figure 7. In some embodiments, the source, old target, and new target cloud service instances are different application instances within the cloud service instances 111, 121, and 131 in Figure 1. In some embodiments, correlation data records are stored in a data store associated with the source cloud service instance (e.g., data stores 113, 123, or 133 in Figure 1). In some embodiments, the data correlation module used to manage the migration is the data correlation module 211 in Figure 2.

[0074] In step 801, matching correlation entries are identified. For example, correlation entries that match the migration parameters of an approved migration request are identified. In some embodiments, matching is based on identifying correlation entries that refer to the old target cloud service instance and further match the correlation requirements of the new target cloud service instance. For example, a migration request may require that only a portion of the configured correlations that point to the old target instance (e.g., only data records belonging to a specific database table) be migrated. In various embodiments, in step 801, only the correlation entries of the correlation index that satisfy the migration requirements are identified for migration.

[0075] In step 803, the conformance correlation entries are updated to refer to the new target instance. For example, for each of the correlation entries identified in step 801, each conformance correlation entry is updated to refer to the new target cloud service instance. In some embodiments, the direction correlation entries are updated with the identifier of the new target application instance. In various embodiments, the updates are recorded and added to the history stored for the correlation entries. For example, when a correlation entry and / or correlation index is updated, the changes are tracked and recorded to maintain a revision history. In various embodiments, tracking the history of changes allows administrators to review the changes and to undo migration and correlation updates.

[0076] In step 805, the data record migration policy is determined. In some embodiments, as part of the initial migration event, data records are correlated between the source instance and the new target instance. The correlated data records are compared, and the records in the appropriate instance are updated. For example, based on the configured migration policy, as part of the execution of the initial migration, the source instance can update the target instance, or conversely, the target instance can update the source instance, depending on which instance is configured as the authoritative source during the migration event. In step 805, the migration policy is determined, including which instance is the authoritative source during the migration. In some embodiments, the authoritative source can be determined at the data record, database table, and / or at a different level of granularity. For example, some database tables can use the source instance as the authoritative source during the migration to update the corresponding correlated records in the target instance, while other database tables can use the target instance as the authoritative source during the migration to update the corresponding correlated records in the source instance. In various embodiments, the migration policy allows the new target to initially override certain values ​​of correlated data records in the source instance as part of the migration process. Once the migration process is complete, the directional correlation entry indicates the direction in which the data records are shared.

[0077] In step 807, the correlated data records are updated based on the determined migration policy. For example, the newly correlated data records are updated using the migration policy determined in step 805 and the authorized sources determined for each correlated data record. Depending on the migration policy, the data records of the target instance and / or source instance are updated. In various embodiments, the update step can utilize the same or similar processing and pipelines used when the correlated data records are modified. For example, both outbound and inbound processing may be performed to create a modified version of each correlated data record appropriate for a specified receiving application instance. In some embodiments, the migration processing may utilize customized inbound and outbound migration processing specific to the migration event, and future updates to the correlated data records revert to the configured inbound and outbound processing defined by the correlation configuration.

[0078] Figure 9 is a functional diagram showing a computer system programmed to perform correlation and sharing of data records. Obviously, other computer system architectures and configurations may be used to maintain order in the obfuscation of protected datasets and / or to perform comparative queries on the obfuscated data. An example of computer system 900 includes one or more computers of client 101, cloud service instances 111, 121, and 131 in Figure 1, one or more computers of data stores 113, 123, and 133 in Figure 1, and one or more computers of cloud service instance 201 in Figure 2. Computer system 900, with various subsystems as described below, comprises at least one microprocessor subsystem (also called a processor or central processing unit (CPU)) 902. For example, the processor 902 may be implemented as a single-chip processor or a multiprocessor. In some embodiments, the processor 902 is a general-purpose digital processor that controls the operation of computer system 900. Using instructions retrieved from memory 910, processor 902 controls the reception and manipulation of input data, as well as the output and display of data on an output device (e.g., display 918). In various embodiments, one or more instances of computer system 900 may be used to perform at least some of the processing shown in Figures 3 to 8.

[0079] The processor 902 is bidirectionally connected to the memory 910, which may include a first primary storage (typically random access memory (RAM)) and a second primary storage area (typically read-only memory (ROM)). As is well known to those skilled in the art, the primary storage can be used as a general storage area and as scratchpad memory, and can also be used to store input data and processed data. The primary storage can further store programming instructions and data in the form of data objects and text objects, in addition to other data and instructions for processing performed on the processor 902. Also as is well known to those skilled in the art, the primary storage typically comprises basic operation instructions, program code, data, and objects used by the processor 902 to perform functions (e.g., programmed instructions). For example, the memory 910 may include any suitable computer-readable storage medium, as described later, depending on whether data access needs to be bidirectional or unidirectional. For example, the processor 902 can store and retrieve frequently needed data directly and very quickly in a cache memory (not shown).

[0080] A removable mass storage device 912 provides additional data storage capacity to the computer system 900 and is connected to the processor 902 in a bidirectional (read / write) or unidirectional (read only) manner. For example, storage 912 may also include computer-readable media such as magnetic tape, flash memory, PC cards, portable mass storage devices, holographic storage devices, and other storage devices. Fixed mass storage 920 may also provide additional data storage capacity, for example. The most common example of mass storage 920 is a hard disk drive. Mass storage 912 and 920 generally store additional programming instructions, data, etc., that are not typically used by the processor 902. It is understood that the information held in mass storage 912 and 920 may, if necessary, be incorporated in a standard manner into a portion of memory 910 as virtual memory (e.g., RAM).

[0081] In addition to allowing the processor 902 to access the storage subsystem, the bus 914 may also be used to enable access to other subsystems and devices. As shown in the figure, these may include a display monitor 918, a network interface 916, a keyboard 904, and a pointing device 906, as well as, optionally, auxiliary input / output device interfaces, a sound card, speakers, and other subsystems. For example, the pointing device 906 may be a mouse, stylus, trackball, or tablet, which is useful for interacting with a graphical user interface.

[0082] The network interface 916, as shown in the figure, enables the processor 902 to be connected to another computer, computer network, or telecommunications network using a network connection. For example, through the network interface 916, the processor 902 can receive information (e.g., data objects or program instructions) from another network or output information to another network in the process of executing a method / processing step. The information may often be represented as a series of instructions executed on the processor, received from another network, and output to another network. Using an interface card (or similar device) and appropriate software implemented (e.g., executed / performed) by the processor 902, the computer system 900 can be connected to an external network and data can be transferred according to a standard protocol. For example, the various processing embodiments disclosed herein may be executed on the processor 902 or on a network (such as the Internet, intranet, or local area network) together with a remote processor that shares part of the processing. Further mass storage devices (not shown) may be connected to the processor 902 through the network interface 916.

[0083] An auxiliary I / O device interface (not shown) may be used with the computer system 900. The auxiliary I / O device interface may include general-purpose and customized interfaces that enable the processor 902 to transmit data and, more typically, to receive data from other devices (such as microphones, touch-sensitive displays, transducer card readers, tape readers, voice or handwriting recognition devices, biometric readers, cameras, portable mass storage devices, and other computers).

[0084] Furthermore, various embodiments disclosed herein further relate to computer storage products including computer-readable media containing program code for performing various computer-implemented operations. Computer-readable media are any data storage devices capable of storing data that can later be read by a computer system. Examples of computer-readable media include, but are not limited to, all of the media described above: magnetic media such as hard disks, floppy disks, and magnetic tapes; optical media such as CD-ROM disks; magneto-optical media such as optical disks; and specially configured hardware devices such as application-specific integrated circuits (ASICs), programmable logic devices (PLDs), and ROM / RAM devices. Examples of program code include, for example, machine code generated by a compiler, or files containing high-level code (e.g., scripts) that can be executed using an interpreter.

[0085] The computer system shown in Figure 9 is merely one example of a computer system suitable for use with the various embodiments disclosed herein. Other computer systems suitable for such use may include more or fewer subsystems. Furthermore, bus 914 is an example of any interconnection scheme that functions to connect subsystems. Other computer architectures with subsystems of different configurations may be available.

[0086] Figure 10 shows one embodiment of a user interface for viewing correlation requests. In the example shown, user interface 1000 is a user interface view of a user interface for reviewing requests to correlate and share data records. In the example shown, the correlation request was approved by the user "System Administrator". The Variables section of user interface 1000 contains details of the correlation request, such as the tenant instance name, which corresponds to the application instance name for the cloud service instance. In various embodiments, user interface 1000 is displayed to a client accessing the correlation and sharing functionality of an application instance. In some embodiments, the client is client 101 in Figure 1, and the application instance is one of the cloud service instances 111, 121, and 131 in Figure 1.

[0087] Figure 11 shows one embodiment of a user interface for displaying target instances associated with correlation requests. In the example shown, user interface 1100 is a user interface view of the user interface for viewing all correlation requests (including past and current requests) from different application instances to the source instance. In the example shown, each correlation request is associated with a "Request ID" and includes a "Status" value. The displayed "Status" value corresponds to both "Active" and "Decommissioned" correlation requests. Other values ​​for correlation status are also appropriate. For example, in some embodiments, the status value may correspond to "Requested" for requests awaiting approval and "Rejcted" for rejected requests. In the example shown, an active request is an approved correlation request that is actively providing updates to the correlation data record to the target instance, and a decommissioned request is an approved request that has been disabled and no longer updates the associated target instance. In various embodiments, both active and deactivated correlation requests, along with their corresponding correlation configurations, may be migrated to a different target instance. In various embodiments, the user interface 1100 is displayed to a client accessing the correlation and sharing capabilities of the application instance. In some embodiments, the client is client 101 in Figure 1, and the application instance is one of the cloud service instances 111, 121, and 131 in Figure 1.

[0088] Figure 12 shows one embodiment of a user interface for displaying a correlation index used to capture a portion of the correlation configuration. In the example shown, user interface 1200 is a user interface view of the user interface for viewing correlation entries in the correlation index, where the correlation index in Figure 12 corresponds to one embodiment of the correlation index used to display the correlation configuration for data records. In the example shown, each entry in the table corresponds to a directional correlation entry of a correlation data record and includes the following fields: identifier of the correlation entry, identifier of the correlation data record, identifier of the table of correlation data records, identifier of the corresponding correlation entry stored in the target (i.e., remote) instance, reference (such as the hostname of the target instance), status of the correlation entry, and domain associated with the correlation entry. Other fields not shown may exist. In various embodiments, a correlation entry shown to have an "Active" status corresponds to an approved correlation request that is actively providing updates to the correlation data record to the target instance. In various embodiments, user interface 1200 is displayed to a client accessing the correlation and sharing capabilities of an application instance. In some embodiments, the client is client 101 in Figure 1, and the application instance is one of the cloud service instances 111, 121, and 131 in Figure 1.

[0089] Figure 13 shows one embodiment of a user interface for configuring capture events related to sharing correlated data records. In the example shown, user interface 1300 is a user interface view of the user interface for configuring the requirements that must be met for correlated data records to be shared with the target instance. In the example shown, each capture event has a "Process Event" name, a State, and an Order. In various embodiments, the Process Event name is used to assign inbound and outbound processing logic to the event, the State is used to enable or disable the event, and the Order is used to prioritize that event over other events. It is also shown that each capture event has a Trigger portion and a Capture portion. The Trigger portion allows the user to define the capture event using a table name and multiple filters. The Capture portion allows the user to define the fields of the table to be captured and whether or not to include attachments. In various embodiments, user interface 1300 is displayed to clients accessing the correlation and sharing capabilities of an application instance. In some embodiments, the client is client 101 in Figure 1, and the application instance is one of the cloud service instances 111, 121, and 131 in Figure 1.

[0090] Figure 14 shows one embodiment of a user interface for displaying outbound processing configurations related to correlation requests. In the example shown, user interface 1400 is a user interface view of the user interface for displaying and configuring outbound processing logic to be executed when a capture event is detected. For example, when a correlation data record is modified and the modification satisfies the capture requirements, outbound processing is performed on the modified data record to create a version of the modified data record for sharing with the target instance. In various embodiments, the outbound processing logic is configured by restricting the outbound processing logic to capture events of correlation data records. In the example shown, the outbound processing configurations are shown based on the capture events associated with them, and each capture event is shown to have its processing event name, the target (i.e., remote) instance associated with the correlation, a name assigned to the configured outbound processing logic (labeled "Outbound Subflow"), and a domain. In various embodiments, user interface 1400 is displayed to clients accessing the correlation and sharing capabilities of an application instance. In some embodiments, the client is client 101 in Figure 1, and the application instance is one of the cloud service instances 111, 121, and 131 in Figure 1.

[0091] Although the embodiments described above have been explained in some detail for the sake of clarity, the present invention is not limited to the details provided. Many alternative methods exist for carrying out the present invention. The disclosed embodiments are illustrative and not intended to be limiting.

Claims

1. It is a method, The processor receives a correlation request from a second application instance in a first application instance, which includes a correlation configuration indicating that the data records from the first application instance are provided to the second application instance. Upon determining that the correlation request has been approved, the processor updates the correlation index, which includes multiple directional correlation entries, to include a specific directional correlation entry that includes the correlation configuration, thereby generating an updated correlation index. In response to the processor determining that the data record has been modified in order to generate a modified data record, it decides to provide the modified data record to the second application instance for correlation using the updated correlation index. The processor provides the modified data record to the second application instance. The processor receives a migration request from a third application instance, which includes a migration configuration indicating that the modified data records from the second application instance are provided to the third application instance, and which includes migration parameters. The processor identifies the particular directional correlation entry based on the fact that the particular directional correlation entry matches the migration parameters of the migration request, The processor, in response to a determination that the migration request has been approved, modifies the specific directional correlation entry to include the migration configuration. The processor provides the modified data record to the third application instance. A method that includes [a certain feature].

2. A method according to claim 1, wherein the first application instance is hosted by a first server, the second application instance is hosted by a second server, and the processor, the first server, and the second server are connected by a network.

3. A method according to claim 1, wherein the determination that the correlation request has been approved is based on approval from the administrator of the first application instance.

4. A method according to claim 1, wherein the determination that the correlation request has been approved is based on the permissions configured for the first application instance.

5. A method according to claim 1, wherein the processor providing the modified data record to the second application instance includes the processor providing a portion of the data fields of the modified data record to the second application instance.

6. A method according to claim 1, further comprising the processor identifying that the second application instance is no longer reachable, and the processor invalidating the particular directional correlation entry in the correlation index.

7. A method according to claim 1, wherein the correlation request is associated with one or more trigger event requirements, and the determination that the data record has been modified is based on the one or more trigger event requirements.

8. A method according to claim 1, wherein the processor providing the modified data record to the second application instance includes the processor manipulating the modified data record to generate an operated data record, and the processor providing the operated data record to the second application instance.

9. A method according to claim 8, wherein manipulating the modified data record includes adding a new field.

10. A method according to claim 1, wherein the processor updates the correlation index to include the particular directional correlation entry in response to the determination that the correlation request has been approved, the processor stores a correlation identifier associated with the particular directional correlation entry and access authentication information associated with the particular directional correlation entry and the second application instance.

11. It is a system, One or more processors, Memory for storing programs, Equipped with, The program is configured on one or more processors: In the first application instance, the second application instance receives a correlation request for the data records of the first application instance, which includes a correlation configuration indicating that the data records from the first application instance are provided to the second application instance. Upon determining that the correlation request has been approved, the correlation index containing multiple directional correlation entries is updated to include a specific directional correlation entry containing the correlation configuration, thereby generating an updated correlation index. In response to determining that the data record has been modified in order to generate a modified data record, the updated correlation index is used to determine that the modified data record should be provided to the second application instance for correlation. The modified data record is provided to the second application instance. Determine that the first application instance is an authorized source, The first application instance receives a migration request from the third application instance, which includes a migration configuration indicating that the modified data records from the first application instance are provided to the third application instance, and which includes migration parameters. Based on the fact that the specific directional correlation entry matches the migration parameters of the migration request, the specific directional correlation entry is identified. In response to the determination that the migration request has been approved, the specific directional correlation entry is modified to include the migration configuration. A system that provides the aforementioned modified data record to the third application instance.

12. The system according to claim 11, wherein the determination that the correlation request has been approved is based on approval from the administrator of the first application instance.

13. The system according to claim 11, wherein providing the modified data record to the second application instance includes providing a portion of the data fields of the modified data record to the second application instance.

14. The system according to claim 11, wherein the program further causes the one or more processors to determine that the second application instance is no longer reachable and to invalidate the particular directional correlation entry in the correlation index.

15. The system according to claim 11, wherein providing the modified data record to the second application instance includes manipulating the modified data record to generate an operated data record, and providing the operated data record to the second application instance.

16. The system according to claim 15, wherein manipulating the modified data record includes adding a new field.

17. On the computer, In the first application instance, the second application instance receives a correlation request for the data records of the first application instance, which includes a correlation configuration indicating that the data records from the first application instance are provided to the second application instance. Upon determining that the correlation request has been approved, the correlation index containing multiple directional correlation entries is updated to include a specific directional correlation entry containing the correlation configuration, thereby generating an updated correlation index. In response to determining that the data record has been modified in order to generate a modified data record, the updated correlation index is used to determine that the modified data record should be provided to the second application instance for correlation. The modified data record is provided to the second application instance. Determine that the second application instance is an authorized source, The third application instance receives a migration request that includes a migration configuration indicating that the modified data records from the second application instance are provided to the third application instance, and includes migration parameters. Based on the fact that the specific directional correlation entry matches the migration parameters of the migration request, the specific directional correlation entry is identified. In response to the determination that the migration request has been approved, the specific directional correlation entry is modified to include the migration configuration. A computer program that provides the modified data record to the third application instance.

18. A method according to claim 1, comprising the processor tracking a version number associated with the modified data record associated with the particular directional correlation entry, and the processor preventing the second application instance from updating the modified data record in response to detecting that the second application instance has received the version number associated with the modified data record associated with the particular directional correlation entry.

19. A method according to claim 1, comprising: the processor modifying the modified data record in response to the migration request in order to generate a second modified data record; and the processor providing the second modified data record to the third application instance.

20. A method according to claim 1, comprising the processor tracking an edge circulated by the particular directional correlation entry and, in response to detecting that the circulated edge includes the second application instance, the processor preventing the updating of the modified data record of the second application instance.

Images