Data congestion on application platforms

Abstract

Disclosed are systems, methods, and computer-readable media for data blocking for an application platform. The application platform may include multiple systems. The systems may store data having a residency period. Upon expiration of the residency period, the data may be blocked from further processing. The multiple systems may include multiple master systems. Each master system may have at least one slave system. The multiple systems may be grouped into system groups including a master system and at least one slave system. For each system group, data blocking may be triggered from the master system to the slave systems. A mid-term blocking mode may be provided for determining which systems have data that needs to be blocked, as well as a full-scale blocking mode for performing data blocking.

Description

Technical Field

[0001] Various embodiments generally relate to electronic data processing methods for application platforms. More specifically, various embodiments relate to blocking data for application platforms having multiple master systems using a system group. Background Art

[0002] In recent years, data privacy and protection have become significant issues for providers of electronic data systems. Recent laws, such as the European Union's General Data Protection Regulation (GDPR), require electronic data processors to implement data blocking of personal data after the data's retention period expires. When data is blocked, it becomes unavailable for further processing and inaccessible to most users. Blocked data can be stored for extended periods of time and used for audit purposes. Thereafter, all blocked data is electronically erased from the digital storage medium. Failure to comply with these requirements can have significant negative consequences for electronic data processors.

[0003] Typical approaches to data blocking in application platforms are limited to blocking data for a single master system with multiple subordinate systems. However, application platforms are often composed of multiple master systems, and there may not be a clearly defined hierarchy between systems in an application platform. For example, a first master system may have a first subordinate system, where the first subordinate system includes a second master system. The second master system may also have a second subordinate system. When blocking data in a multi-master system environment, all master and subordinate systems should be evaluated for data blocking. Therefore, there is a need for data blocking in application platforms with multiple master systems. Summary of the Invention

[0004] The disclosed embodiments solve the above-mentioned data blocking problem with multiple dominant systems by organizing systems into system groups. A blocking request to block data in an application platform can be received from a user. The application platform can include multiple systems. After receiving the blocking request, the multiple systems can be grouped into system groups. Each system group can include a dominant system and zero or more subordinate systems. A system can exist in multiple system groups, and a system can be a dominant system in a first system group and a subordinate system in a second system group. For each system in a system group, it can be determined whether the system's residency period has expired. If the residency period has expired, the system's data may be blocked. The residency period can be a defined period of time, after which the system's data will be blocked from further processing. The blocking process can be triggered from the dominant system to the subordinate systems within the system group.

[0005] Various embodiments are directed to one or more non-transitory computer-readable media storing computer-executable instructions that, when executed by a processor, perform a method for data blocking in an application platform, comprising: receiving a blocking request from a user to block data in the application platform, the application platform comprising a plurality of systems; in response to receiving the blocking request, grouping the plurality of systems into at least one system group; determining, for each system in the at least one system group, whether a retention period has expired; and in response to determining that the retention period has expired, blocking data in the system. Each system in the plurality of systems may be associated with at least one electronic master data entity.

[0006] This summary is provided to introduce some concepts that will be further described in the following detailed description in a simplified form. This summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter. Other aspects and advantages of the present teachings will become apparent from the following detailed description of the embodiments and accompanying drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0007] The following describes various embodiments in detail with reference to the accompanying drawings, in which:

[0008] Figure 1 An overview of data blocking is shown for some embodiments;

[0009] Figure 2 shows the user interface of some embodiments;

[0010] Figure 3 shows an exemplary flow chart for generating an electronic packet coverage report according to some embodiments;

[0011] Figure 4 illustrates an exemplary flow chart for generating an electronic packet exclusion report according to some embodiments;

[0012] Figure 5 An exemplary flow chart illustrating data blocking of some embodiments; and

[0013] Figure 6 An exemplary hardware platform for some embodiments is depicted.

[0014] The drawings do not limit the present teachings to the specific embodiments disclosed and described herein.The drawings are not necessarily to scale, emphasis instead being placed upon clearly illustrating the principles of the present disclosure. DETAILED DESCRIPTION

[0015] The subject matter of the present disclosure is described in detail below to meet statutory requirements; however, the description itself is not intended to limit the scope of the claims. Rather, the claimed subject matter may be implemented in other ways, to include different steps or combinations of steps similar to those described herein, in conjunction with other present or future technologies. Those skilled in the art will understand minor variations from the following description, and such variations are intended to be encompassed by the scope of the present claims. Terms should not be interpreted as implying any particular order of the various steps described unless the order of the individual steps is explicitly described.

[0016] The following detailed description of the embodiments refers to the accompanying drawings, which illustrate specific embodiments in which the present teachings may be practiced. The described embodiments are intended to illustrate aspects of the disclosed embodiments in sufficient detail to enable those skilled in the art to practice the present teachings. Other embodiments may be utilized and changes may be made without departing from the scope of the claims. Therefore, the following detailed description should not be taken in a limiting sense. The scope of the embodiments is limited only by the appended claims and the full scope of equivalents to such claims.

[0017] References in this specification to "one embodiment," "an embodiment," or "embodiments" mean that the referenced feature or features are included in at least one embodiment of the technology. Separate references in this specification to "one embodiment," "an embodiment," or "embodiments" do not necessarily refer to the same embodiment, and are not mutually exclusive unless so stated and / or unless readily apparent to one skilled in the art from the specification. For example, a feature, structure, or act described in one embodiment may also be included in other embodiments, but is not required to be included. Thus, the technology may include various combinations and / or integrations of the embodiments described herein.

[0018] This document discloses a system and method for data blocking within an application platform. Data maintained by an application system may have a residency period, during which the data can be used for various processing purposes. Once the residency period expires, the data may transition to a retention period, during which the data remains within the application platform but is blocked from further processing. To achieve regulatory compliance, such data should be inaccessible (i.e., blocked) to general users while remaining accessible for specific use cases (e.g., auditing). The residency period varies depending on the type of data and the purpose of the data. For example, the HR department may need to store employee addresses for three years, while the payroll department may need to store addresses for five years. Therefore, after three years, the data should be blocked by the HR department but not by the payroll department; and after five years, the data should also be blocked by the payroll department. Data blocking within the application platform can be achieved by blocking the display of the blocked data, blocking modification of the blocked data, blocking the creation of objects containing the blocked data, blocking copying or subsequent actions on the blocked data, blocking searching of the blocked data, or any combination thereof. In some embodiments, users with special authorization may have read-only access to the blocked data, but may be restricted from performing any of the above-described actions on the blocked data.

[0019] An application platform may include multiple systems. These systems may be enterprise resource planning systems, customer relationship management systems, supplier relationship management systems, or any other data management systems, and may include cloud-based systems and / or local systems. Such systems may be categorized as dominant systems and subordinate systems. A dominant system may include one or more electronic master data entities. A subordinate system may include copies of data entities from a dominant system. A subordinate system may include multiple data entities, and may include data entities that have dependencies on different dominant systems. Additionally, subordinate systems may also include dominant master data entities that have their own subordinate systems. Therefore, problems may arise when data is blocked in an application system with multiple dominant systems.

[0020] Typically, application platforms implement data blocking by assuming a dominant system, with the remaining systems being considered subordinate systems. Data blocking then begins with the dominant system and traverses downward through the subordinate systems. However, in an application platform environment, as previously mentioned, multiple dominant systems and multiple subordinate systems may coexist. Therefore, blocking data in this manner may result in the loss of master data entities and / or a poorly optimized data blocking system. Furthermore, data blocking is typically performed in an order determined by the connection type. For example, systems connected via the TCP / IP protocol may be evaluated for data blocking first. For example, if a system that might be prevented from data blocking uses a different type of network service to connect, such a system may be evaluated at a later stage in the data blocking process, resulting in poorly optimized data blocking, as evaluating the TCP / IP system first may waste a significant amount of resources.

[0021] To overcome these limitations, systems within the application platform can be grouped into one or more system groups. Each system group can include a dominant system and its subordinate systems. A dominant system and subordinate systems may exist in more than one system group. Once grouped, the system group can be evaluated for data blocking by determining whether the system's end-of-purpose has been reached. If a system in the system group has not yet reached its end-of-purpose, data blocking can be prevented for all systems in the system group. Data blocking can be triggered from the dominant system to the subordinate systems.

[0022] Figure 1 A system overview 100 of data blocking in an application platform in some embodiments is shown. A user 102 can be an administrator user 102 of the application platform, which has higher privileges than a regular user, or can be any other user. In some embodiments, the user 102 is a data privacy officer responsible for maintaining the privacy of the data and ensuring compliance with all legal and corporate rules and regulations. The user 102 can manage an electronic blocking report 104 to initiate the data blocking process. The electronic blocking report 104 can include various processes 106 that can be configured for data blocking. The processes 106 can include an end of purpose (EoP) check 108, an interim check 110, a comprehensive check 112, a start of retention time (SoRT) 114, a blocking flag 116, or any combination thereof. The processes 106 can include a data blocking assessment performed for the application platform.

[0023] The EoP check 108 may include a test to determine whether the system's data can be blocked. As described above, data may have a defined residency period after which the data will be blocked. The EoP check 108 may be configured by the user 102 to scan the system manually, on a periodic basis, or based on any other triggering event. In some embodiments, the EoP check 108 may be configured to scan the system at different levels of the application platform. For example, for a hierarchical database system, the EoP check 108 may begin scanning at the third level of the hierarchy, without scanning the first and second levels. Alternatively or additionally, the EoP check 108 may scan the application platform for specific systems specified by the user 102. The EoP check 108 may mark any system that has reached the end of its defined residency period. In some embodiments, the EoP check 108 marks any system that will reach the end of its defined residency period before the next scheduled EoP check 108.

[0024] When determining whether a system may be blocked, the EoP check 108 can utilize a SoRT 114. The SoRT 114 can specify the end of processing of data in the system. For example, the completion of a document can be the end of processing of the data and, therefore, the start of the retention period 114. The SoRT 114 can be stored in a database or table and retrieved by the end-of-purpose check 108 when determining whether a residency period has expired. In some embodiments, the SoRT 114 is sent to the leader system of the system group so that the leader system can only block data from those subordinate systems that have reached their end-of-purpose as determined by the SoRT 114. For systems determined to have expired residency periods, a blocking flag 116 can be set to indicate that data for that system should be blocked.

[0025] The interim check 110 may include an interim blocking mode for the electronic blocking report 104. The interim check 110 may be performed after the systems have been grouped into system groups. The interim check 110 may be performed locally on a designated slave system. The interim check 110 may include evaluating blocking on the slave system by performing an EoP check 108. Thereafter, a SoRT result 118 may be sent to the master system of the slave system, as described below. The blocking result may indicate whether the system should have blocking data for it. In some embodiments, a blocking flag 116 is set to indicate that the associated system should be blocked. In some embodiments, the interim check 110 is iteratively performed on all system groups in the application platform. Alternatively or additionally, the interim check 110 may be performed on selected system groups. Figure 5 Performing an interim check 110 is discussed in more detail.

[0026] The electronic blocking report 104 may also include a comprehensive check 112. The comprehensive check 112 may be performed after the system group is created and may include operating in a comprehensive mode, where actual data blocking is performed. Figure 5 Performing a comprehensive check 112 is discussed in more detail.

[0027] Once the process 106 has been executed and data blocking is complete, the electronic blocking report 104 can store the SoRT results 118 and / or the blocking indicator 120. As described above, the SoRT results 118 can include SoRT data stored in the database. The blocking indicator 120 can include the blocking flag 116 and can be stored with the SoRT results 118 or separately from the SoRT results 118. In some embodiments, the blocking indicator 120 includes an identifier of the lead system of the system group.

[0028] The electronic blocking report 104 may also be communicatively coupled to one or more rule engines 122. The rule engine 122 may include an API for defining and processing rules. Rules may be implemented as expressions assigned to functions. As described above, system groups may be created to facilitate data blocking for the application platform. System groups may be based on predefined and / or user-defined rules. Rules may be defined to indicate which system should be the dominant system and which system should be its subordinate systems. In some embodiments, after a system is designated as the dominant system, a master data entity is created for it. Rules may be defined based on various system properties associated with the systems in the application platform. In some embodiments, the user 102 creates custom code extensions to define rules for the rule engine 122.

[0029] Systems can include system attributes such as identifiers, categories, groups, data controllers, data sources, codes, and more. User 102 can specify various other custom attributes. System attributes can be dynamic, and grouping rules can use system attributes at runtime to generate system groups. In some embodiments, the system identifier attribute includes a textual, numeric, or alphanumeric identifier or name of the system. In some embodiments, the system grouping attribute includes groupings categorized by their systems. In some embodiments, systems can be grouped by their identifiers. Thus, for example, systems with identifiers 2-10 can be placed in a first group, while systems with identifiers 12-20 can be placed in a second group. Thus, user 102 can use rules engine 122 to define a rule that the system with identifier '1' is the dominant system among systems with identifiers 2-10, thereby forming a system group. Similarly, a second system group can consist of the system with identifier '11' as the dominant system among systems with identifiers 12-20. It should be noted that grouping is not limited to numeric grouping and can be based on various other attributes, such as system category.

[0030] In some embodiments, the system category attribute indicates the type of system. For example, in an order processing database system, the system category may indicate whether the system is for an individual, an organization, or a group of organizations or individuals. In some embodiments, the system code attribute may be any predefined (e.g., by a software vendor) or user-defined code for the system. For example, the system code may be a country, a company code, or any other identifier.

[0031] In some embodiments, the system data controller attribute indicates the user 102 responsible for the system. Alternatively or additionally, the system data controller can be the organization responsible for the system. Thus, for example, a rule can be created to ensure that all systems controlled by a particular data controller are processed for data blocking. In some embodiments, the system data source attribute indicates where the system data originates. A system and / or its data can be received from various third-party or external sources. A rule can be created so that all systems with data originating from a particular source can be allowed to check the incoming data to ensure that the data is available for processing.

[0032] Figure 2 A user interface 200 of some embodiments is shown. The user interface 200 can be presented to a user 102 managing data for an application platform. In some embodiments, the user interface 200 includes a system list 202 containing various systems 204. The systems 204 can be grouped into system groups 206, where a system group 206 can include a leader system 208 and zero or more subordinate systems 210. Each system 204 in the application platform can be listed in the system list 202. As shown, a system 204 can be a leader system 208 in one system group 206 within the application platform and a subordinate system 210 in a second system group 206.

[0033] In some embodiments, user 102 can edit system groups 206 via user interface 200. Each system group 206 can have an associated modification control 212 for modifying system group 206. Modification control 212 can allow user 102 to add, delete, upgrade, or downgrade systems 204 within system group 206. In some embodiments, user interface 200 is configured with a drag-and-drop function or other similar gestures for modifying systems 204 in system group 206.

[0034] As described above, the slave system 210 may include a copy of a master data entity stored in the dominant system 208. In some embodiments, the creation of a master data entity results in the creation of associated data entities. For example, in a customer resource management system, a master data entity representing a company may be created. When a company master data entity is created, associated data entities representing the company's suppliers may also be created. When a company master data entity is copied for use in the slave system 210, the associated data entities may also be copied. In some embodiments, the company master data entity may be copied without copying the associated data entities. In some embodiments, the associated data entities are created and copied in the slave system 210 and omitted from the dominant system 208. The associated data objects may include the role of their master data entities. In some embodiments, the associated data objects may be created in the dominant system 208, and the master data entities may be created in its slave system 210, which is referred to here as a client-vendor (CV) based dominant system.

[0035] As described above, system groups 206 can be formed based on rules defined via rules engine 122. In some embodiments, user 102 indicates a priority order for the master system 208 to connect to its slave systems 210. User 102 can set the priority order so that slave systems 210 with a higher chance of vetoing data blocking are evaluated earlier in the data blocking process, thereby preventing the master system 208 from having to connect to each of its slave systems 210. In some embodiments, user 102 can assign numbers to systems 204 so that the priority order follows the numerical order of the numbers. For example, user 102 may know that a first system 204 is likely to have a longer residency period than any other system 204 in system list 202. Thus, user 102 may assign the number "1" to first system 204. When first system 204 is a slave system 210 in system group 206, EoP check 108 will be performed on it first based on the priority order. Therefore, if a data blocking request is executed before the residency period of the first system 204 expires, the data blocking request may be denied because the data of the first system 204 is still available for further processing. In some embodiments, a denial by a system 204 in the system group 206 stops the data blocking evaluation for all other systems 204 in the system group 206. In some embodiments, if a system 204 fails to block after data from other systems 204 in the system group 206 has been blocked, the blocked data is rolled back to an unblocked state.

[0036] In some embodiments, customizable data for system 204 is stored in a central system, allowing the customizable data to be distributed to systems 204 for reuse. In some embodiments, a process switch is provided for implementing data blocking for multiple master systems. When the process switch is on, a system group 206 can be formed for data blocking. When the process switch is off, a standard data blocking process can be employed, assuming a single master system 208 and all other systems 204 are slave systems 210. The position of the process switch can be stored as customizable data.

[0037] Various data about system 204 may also be stored as customizable data. For example, the name, description, identifier, attributes, or any combination thereof of system 204 may be customizable data. Similarly, data about system group 206 may be stored as customizable data. In some embodiments, customizable data for system group 206 includes its subordinate systems 210, group identifier, group description, default and / or specific connection types for connecting subordinate systems 210 to master system 208, the type of master system 208, the connection type from master system 208 to each subordinate system 210, the priority order / sequence number for invoking subordinate systems 210, or any combination thereof. Furthermore, the rules defined in rules engine 122 for grouping systems 204 may be stored as customizable data. In some embodiments, the central system is system 204 in system list 202. Alternatively or additionally, the central system is a system separate from system 204. In some embodiments, customizable data is read-only for systems 204 other than the central system.

[0038] In some embodiments, configuration data for the systems 204 is maintained in each system 204, and the configuration data can vary between systems 204. In some embodiments, the configuration data includes various technical parameters for data blocking. As an example, the configuration data can include an indicator indicating which system 204 is the central system for maintaining customizable data. Connection details for connecting the master system 208 to its slave systems 210 can also be stored. In some embodiments, the systems 204 are connected to each other via function calls. The function call can include a target that defines which system 204 to call. Alternatively or additionally, the systems 204 can be connected via a data network protocol such as TCP / IP, and service port information can be maintained as configuration data on all systems 204. By utilizing a priority order as described above, the blocking process can be optimized because data blocking evaluation can be performed based on priority rather than connection type.

[0039] In some embodiments, the configuration data depends on whether data blocking is performed in an interim check 110 or a full check 112. When operating in an interim check 110, the configuration data of system 204 may indicate whether system 204 is a slave system 210 of the current system group 206 being processed. When operating in a full check 112, the configuration data of system 204 may indicate whether system 204 is a master system 208 of the current system group 206 being processed. The customizable and / or configuration data described above may be used to present and maintain user interface 200. If either the customizable data or the configuration data is modified, the modification may be reflected in user interface 200.

[0040] Figure 3 An exemplary method 300 for generating an electronic group coverage report in some embodiments is shown. An electronic group coverage report can be generated to determine whether each system 204 and / or master data entity in an application platform has been assigned to at least one system group 206. In some embodiments, the electronic group coverage report can be automatically generated by a data processing system associated with one or more application platforms on a predefined basis. In some embodiments, the electronic group coverage report is generated in response to a user 102 requesting data blocking for the application platform. The electronic group coverage report can be displayed in the user interface 200.

[0041] At step 302, grouping rules may be retrieved. As described above, the systems 204 may be grouped based on rules defined in the rules engine 122. The grouping rules may define which systems 204 should be grouped together based on attributes of the systems 204. In some embodiments, the attributes include a system identifier, code, system category, system group, system data controller, system data source, and the like of the system 204.

[0042] Next, at step 304, system groups 206 may be determined for the systems 204 in the application platform. At test 306, it may be checked whether the determination of the system groups 206 for the application platform was successful. If the determination was successful, processing may proceed to step 308. If the determination was unsuccessful, processing may proceed to step 310. A successful determination may be indicated by assigning each master data entity to at least one system group 206.

[0043] At step 308, for successful determination of the system group 206 for the application platform, a list of master data entities and their associated system groups 206 may be generated for the user 102. At step 310, for unsuccessful determination of the system group 206 for the application platform, a list of master data entities that cannot be added to the system group 206 may be generated for the user 102. In this way, the user 102 can edit the rules in the rules engine 122 to ensure that all master data entities can be added to the system group 206. Thereafter, the user 102 can run the electronic group coverage report again to ensure that the new rules correctly group all master data entities.

[0044] Now refer to Figure 4 , illustrates an exemplary method 400 for generating an electronic group exclusion report in some embodiments. The electronic group exclusion report can summarize which (if any) systems 204 and / or master data entities can be skipped for data blocking due to missing and / or non-unique determination of the system group 206. In some embodiments, the electronic group exclusion report can be performed to ensure that any skipped master data entities are properly handled when evaluated for data blocking. The electronic group exclusion report can be presented to the user 102 via the user interface 200.

[0045] At step 402, system grouping may be performed based on the rules described above. Once the system group 206 is obtained, at step 404, it may be determined whether all master data entities have been added to the system group 206. If all master data entities are correctly grouped, then processing may proceed to step 406. At step 406, data blocking may be performed as described below. Figure 5 Proceed as outlined.

[0046] If at least one master data entity is not correctly added to the system group 206, then at step 408, a determination may be made as to whether an instruction has been received to connect the incorrectly grouped master data entity to all dependent systems 210 in the application platform. In some embodiments, the user 102 is prompted (e.g., via the user interface 200) to confirm that the master data entity should be connected to all dependent systems 210 in the application platform. If no instruction has been received, processing may proceed to step 410. At step 410, the user 102 may be warned of non-compliance because there may be master data entities that have not yet been evaluated for data blocking and there may be data with expired residency periods.

[0047] If an instruction is received at step 412, data blocking may be performed as follows: Figure 5 Performing data blocking by connecting an incorrectly grouped master data entity to all slave systems 210 may be less efficient than performing data blocking by correctly forming a system group 206, but may still be considered consistent with data blocking.

[0048] Now refer to Figure 5 In some embodiments, an exemplary method 500 for data blocking of an application platform is shown. Processing may begin at step 502, where an electronic blocking report 104 is received. As described above, the electronic blocking report 104 may include various processes 106, such as an end-of-purpose check 108, an interim check 110, a full check 112, SoRT 114, a blocking flag 116, or any combination thereof. In some embodiments, a user 102 may select a process 106 for data blocking. For example, the user 102 may select to perform a full check 112 via the electronic blocking report 104. In some embodiments, only one of the interim check 110 or the full check 112 may be selected for use in the electronic blocking report 104.

[0049] At step 504, a check may be performed to see if multi-lead is active. As described above, the application platform may have multiple lead systems 208, or it may have a single lead system with multiple slave systems 210 replicated from it. The process switch described above may be used to determine if multi-lead is active. If multi-lead is active, processing may proceed to step 506. If multi-lead is not active, processing may proceed to step 508.

[0050] When multi-leadership is inactive, a standard blocking solution may be employed at step 506. The standard blocking solution may assume that the application platform has a single leader system 208, with all other systems 204 being slave systems 210. Blocking may then be performed starting from the single leader system 208 and traversing its slave systems 210. In some embodiments, the leader system 208 in the standard blocking solution may call the slave systems 210 according to a priority list.

[0051] When multiple masters are active, at step 508, system groups 206 may be determined. In some embodiments, this determination is based on rules defined by the user 102 and / or provided by the software vendor via the rules engine 122. As described above, the user 102 may provide custom extensions to determine the system groups 206 for the electronic master data entities. Each system group 206 may include a single master system 208 and zero or more subordinate systems 210. In some embodiments, a system 204 may exist in multiple system groups 206. In some embodiments, a system 204 may be a master system 208 for a first system group 206 and a subordinate system 210 for a second system group 206. At step 510, as described below, a first system group 206 of the multiple system groups may be iterated in either an interim mode or a comprehensive mode.

[0052] Thereafter, at step 512, the blocking mode may be checked. Figure 1As described above, blocking can be performed in either mid-term mode or comprehensive mode. In some embodiments, mid-term mode is used as a test mode to determine which systems 204 need to have their data blocked, i.e., which systems 204 have expired residency periods. Comprehensive mode can include actual blocking of systems 204. It should be noted that comprehensive mode can be run without first executing mid-term mode. If the blocking mode is mid-term mode, processing can proceed to step 514. If the blocking mode is comprehensive mode, processing can proceed to step 520.

[0053] At step 514, after performing the EoP check 108, data blocking can be performed in the interim mode. In some embodiments, the EoP check 108 is a local EoP check 108, such that the EoP check 108 is performed only on non-remote systems 204. Thereafter, at step 516, the leader system 208 of the system group 206 can be retrieved. In some embodiments, the slave system 210 stores the identifier of the leader system 208 as customizable data. Additionally, as described above, the connection information for connecting to the leader system 208 can be stored by the slave system 210. Thus, the slave system 210 can use the identifier and connection information to connect to the leader system 208. At step 518, the SoRT results 118 can be sent to the leader system 208. Thus, once data blocking is performed in the comprehensive mode, the leader system 208 can know which slave systems 210 should have their data blocked. Processing can then return to step 510 to process the next system group 206.

[0054] When executing in full mode, processing may proceed from step 512 to step 520. At step 520, a check may be performed to determine whether system 204 in system group 206 is operating in a CV-based master system. A CV-based master system may be a system group 206 in which a master data entity is a slave system 210 of an associated data entity. The creation of an associated data entity in master system 208 may result in the creation of a master data entity in slave system 210. In a CV-based master system, a master data entity may be replicated from an associated data entity. If system group 206 is operating in a CV-based master system, processing may return to step 512 until master system 208 is no longer operating in a CV-based master system. In some embodiments, grouping rules may be modified to ensure that master system 208 is not a CV-based master system in order to operate in full mode. If system 204 is not operating in a CV-based master system, processing may proceed to step 522.

[0055] At step 522, it may be determined that the current system 204 is the leader system 208 of the system group 206. As described above, data blocking may be triggered from the leader system 208 to the subordinate systems 210 according to a priority order. Furthermore, it may be checked that no redundant calls have been made to the system 204 to prevent the system 204 from being evaluated multiple times for data blocking. If the current system 204 is not the leader system 208 of the system group 206 and / or a redundant call has been made, processing may return to step 512. If the conditions of step 522 are met, processing may proceed to step 524.

[0056] At step 524, the subordinate systems 210 of the system group 206 can be retrieved. Thereafter, at step 526, the system group 206 can be iterated and the EoP check 108 can be performed. In some embodiments, the EoP check 108 is performed on both the remote and local systems 204. Thereafter, for systems 204 with expired residency periods, data can be blocked at step 528. Furthermore, blocking information for the blocked data can be exported and stored. In some embodiments, the blocking information includes a blocking indicator 120 and / or an identifier of the master system 208. In some embodiments, the blocking information is stored in a persistence layer of the application platform.

[0057] Now refer to Figure 6, which depicts an exemplary hardware platform for certain embodiments. Computer 602 can be a desktop computer, a laptop computer, a server computer, a mobile device such as a smartphone or tablet, or any other form factor of a general-purpose or special-purpose computing device that includes at least one processor. For illustrative purposes, several components are depicted with computer 602. In some embodiments, some components may be arranged differently or not present. Additional components may also be present. Computer 602 includes a system bus 604, through which the other components of computer 602 can communicate with each other. In some embodiments, there may be multiple buses or components that can communicate directly with each other. A central processing unit (CPU) 606 is connected to system bus 604. One or more random access memory (RAM) modules 608 are also attached to system bus 604. A graphics card 610 is also attached to system bus 604. In some embodiments, graphics card 610 may not be a physically separate card, but may be integrated into the motherboard or CPU 606. In some embodiments, graphics card 610 has a separate graphics processing unit (GPU) 612, which can be used for graphics processing or general-purpose computing (GPGPU). Additionally, on the graphics card 610 is GPU memory 614. A display 616 for user interaction is connected (directly or indirectly) to the graphics card 610. In some embodiments, the display is not present, while in other embodiments, it is integrated into the computer 602. Similarly, peripheral devices such as a keyboard 618 and a mouse 620 are connected to the system bus 604. Like the display 616, these peripheral devices may be integrated into the computer 602 or not present. Also attached to the system bus 604 is local storage 622, which may be any form of computer-readable media, such as non-transitory computer-readable media, and may be internally installed in the computer 602 or removably attached externally.

[0058] Computer-readable media includes volatile and non-volatile media, removable and non-removable media, and contemplates database-readable media. For example, computer-readable media include (but are not limited to) RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile discs (DVDs), holographic media or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage and other magnetic storage devices. These technologies can store data temporarily or permanently. However, unless expressly stated otherwise, the term "computer-readable medium" should not be construed to include physical but temporary forms of signal transmission, such as radio broadcasts, electrical signals through wires, or light pulses through fiber optic cables. Examples of stored information include computer-usable instructions, data structures, program modules, and other data representations.

[0059] Finally, a network interface card (NIC) 624 is also attached to system bus 604 and allows computer 602 to communicate over a network, such as network 626. NIC 624 can be any form of network interface known in the art, such as Ethernet, ATM, fiber optic, Bluetooth, or Wi-Fi (i.e., the Institute of Electrical and Electronics Engineers (IEEE) 802.11 family of standards). NIC 624 connects computer 602 to local network 626, which can also include one or more other computers, such as computer 628, as well as network storage, such as data store 630. Generally speaking, a data store, such as data store 630, can be any repository from which information can be stored and retrieved as needed. Examples of data stores include relational or object-oriented databases, spreadsheets, file systems, flat files, directory services (such as LDAP and Active Directory), or email storage systems. Data stores can be accessed via complex APIs (e.g., Structured Query Language), simple APIs that only provide read, write, and search operations, or any level of complexity in between. Some data stores can also provide management functions for the data sets stored therein, such as backup or version control. The data store may be local to a single computer, such as computer 628, accessible on a local network, such as local network 626, or remotely accessible via the public internet 632. Local network 626, in turn, is connected to the public internet 632, which connects many networks, such as local network 626, remote networks 634, or directly attached computers, such as computer 636. In some embodiments, computer 602 itself may be directly connected to the public internet 632.

[0060] Many different arrangements of the various components depicted, as well as components not shown, are possible without departing from the scope of the appended claims. Embodiments have been described with the intent to be illustrative and not restrictive. Alternative embodiments will become apparent to the reader of this disclosure after and because of reading this disclosure. Alternative means of achieving the foregoing may be accomplished without departing from the scope of the following claims. Certain features and subcombinations are useful and may be used without reference to other features and subcombinations and are considered to be within the scope of the claims. Although the present teachings have been described with reference to the embodiments shown in the drawings, it should be noted that equivalents and substitutions may be employed herein without departing from the scope of the claims.

[0061] Having described various embodiments, what is new and desired protected by Letters Patent are claimed including what is shown.

Claims

1. One or more non-transitory computer-readable media storing computer-executable instructions that, when executed by a processor, perform operations for data blocking of an application platform, the operations comprising: receiving a blocking request from a user to block data in an application platform, the application platform comprising a plurality of systems including at least two leader systems containing original versions of electronic master data entities and one or more subordinate systems containing copies of the electronic master data entities; In response to receiving the blocking request, grouping the plurality of systems into a plurality of system groups such that no single system group contains more than one leader system, for a first system group of the plurality of system groups, determining that a residency period has expired for a leader system in the first system group and for at least one slave system in the first system group; as well as In response to the determination, data on the leader system in the first system group and the at least one slave system in the first system group is blocked to make the data unavailable for processing.

2. The medium of claim 1, the operations further comprising: receiving at least one rule for grouping from a user, The at least one rule comprises an attribute that defines the electronic master data entity as a lead system of the first system group.

3. The medium according to claim 2, in, The attribute is the first attribute, and The at least one rule further comprises a second attribute, which defines the electronic master data entity as a subordinate system of the first system group.

4. The medium of claim 1, the operations further comprising: receiving from a user an order of priority for each of the plurality of systems, Here, determining whether the residency period has expired is performed according to a priority order.

5. The medium of claim 4, the operations further comprising: In response to determining that the residency period has not expired, blocking of data of the system group is prevented.

6. The medium of claim 1, the operations further comprising: A set of congestion data is output, the set of congestion data including congestion indicators for the plurality of systems.

7. A method for data blocking of an application platform, the method comprising: receiving a blocking request from a user to block data in an application platform, the application platform comprising a plurality of systems including at least two leader systems containing original versions of electronic master data entities and one or more subordinate systems containing copies of the electronic master data entities; In response to receiving the blocking request, grouping the plurality of systems into a plurality of system groups such that no single system group contains more than one leader system, determining, for a first system group of the plurality of system groups, an operating mode for blocking requests; in response to determining that the operating mode is the mid-term mode, performing a mid-term test check on the first system group; as well as In response to determining that the operating mode is the full mode, data blocking is performed on the leader system in the first system group and the at least one slave system in the first system group.

8. The method according to claim 7, in, The mid-term test inspection includes: performing an end-of-destination check for each slave system in the first system group; Connect each slave system to the master system; and The results of the end-of-destination check are sent from each slave system to the master system.

9. The method according to claim 7, in, The data blocking of the application platform includes: For a first system group of the plurality of system groups, determining that a residency period has expired for a leader system in the first system group and for at least one slave system in the first system group; and In response to the determination, data on the leader system in the first system group and the at least one slave system in the first system group is blocked to make the data unavailable for processing.

10. The method according to claim 7, further comprising: receiving a request from a user to generate an electronic group exclusion report for the application platform; In response to receiving the request, it is determined whether the first electronic master data entity has not been added to a system group of the plurality of system groups.

11. The method according to claim 10, further comprising: In response to determining that the first electronic master data entity has not been added to a system group of the plurality of system groups, the system is connected to each slave system in the application platform.

12. The method according to claim 7, further comprising: receiving a request from a user to generate an electronic packet coverage report for the application platform; as well as In response to receiving the request, a determination is made as to whether the first electronic master data entity is in a system group of the plurality of system groups.

13. The method according to claim 12, further comprising: In response to determining that the first electronic master data entity is not in a system group of the plurality of system groups, a user is alerted.

14. A system for data blocking of an application platform, the system comprising: Data storage; processor; as well as One or more non-transitory computer-readable media storing computer-executable instructions that, when executed by a processor, perform operations for data blocking for an application platform having multiple host systems, the operations comprising: receiving a blocking request from a user to block data in an application platform, the application platform comprising a plurality of systems including at least two leader systems containing original versions of electronic master data entities and one or more subordinate systems containing copies of the electronic master data entities; In response to receiving the blocking request, grouping the plurality of systems into a plurality of system groups such that no single system group contains more than one leader system, for a first system group of the plurality of system groups, determining that a residency period has expired for a leader system in the first system group and for at least one slave system in the first system group; as well as In response to the determination, data on the leader system in the first system group and the at least one slave system in the first system group is blocked to make the data unavailable for processing.

15. The system of claim 14, wherein the operations further comprise providing a user interface displaying the first system group.

16. The system of claim 15, wherein the operations further comprise receiving input in the user interface for editing the first system group, the input comprising adding or removing one of the subordinate systems of the first system group.

17. The system according to claim 15, in, Each system of the plurality of systems includes a set of configurable data, and The operation also includes: A user interface is generated based on the set of configurable data.

18. The system according to claim 14, in, The first system group is determined based on at least one rule, The at least one rule defines an attribute indicating that the electronic master data entity is grouped into the first system group.

19. The system according to claim 18, wherein: The attribute includes one of an electronic master data entity identifier or an electronic master data entity category.

Images