Service change orchestration method and apparatus, electronic device, storage medium, and program product

Abstract

This disclosure provides a business change orchestration method, apparatus, electronic device, storage medium, and program product, which can be applied to computer technology, business processing technology, intelligent operation and maintenance, and fintech fields. The business change orchestration method includes: in response to receiving a change request, determining time window information and associated system information for performing the business change based on the business information to be changed indicated in the change request; wherein the time window information includes change sub-windows corresponding to multiple system types, and the associated system information includes system types, current change information, and resource information corresponding to each of the multiple associated systems; and determining the change orchestration result corresponding to the business to be changed based on the change sub-windows corresponding to each of the multiple system types, the current change information, and resource information corresponding to each of the multiple associated systems.

Description

Technical Field

[0001] This disclosure relates to the fields of computer technology, business processing technology, intelligent operation and maintenance, and financial technology, and more specifically, to a business change orchestration method, apparatus, electronic device, storage medium, and program product. Background Technology

[0002] With the development of computer technology, online business adopts a modular and multi-layered design, so the business update process needs to be implemented collaboratively by various systems related to the business.

[0003] In one example, change orchestration methods include time-based and time-zone-based methods. Time-based methods select non-service days for business systems as change times, assigning fixed change time periods to each system to avoid conflicts by staggering implementation times. Time-zone-based methods divide server groups by time zone and perform changes during off-peak business hours in the corresponding time zone to maintain service continuity.

[0004] In realizing the concept disclosed herein, the inventors discovered at least the following problems in the related technologies: due to the differences in the service scope and service time of various systems, the change arrangement methods in the related technologies are difficult to effectively guarantee the accuracy and flexibility of business change arrangement. Summary of the Invention

[0005] In view of this, this application provides a business change orchestration method, apparatus, electronic device, storage medium, and program product.

[0006] According to one aspect of this application, a business change orchestration method is provided, characterized in that the method includes: in response to receiving a change request, determining time window information and associated system information for performing the business change based on the business information to be changed indicated by the change request, wherein the time window information includes change sub-windows corresponding to multiple system types, and the associated system information includes system types, current change information, and resource information corresponding to multiple associated systems; and determining a change orchestration result corresponding to the business to be changed based on the change sub-windows corresponding to the multiple system types, the current change information, and the resource information corresponding to the multiple associated systems.

[0007] According to another aspect of this application, a business change orchestration apparatus is provided, characterized in that the apparatus comprises: a first determining module, configured to, in response to receiving a change request, determine time window information and associated system information for performing the business change based on the business information to be changed indicated by the change request, wherein the time window information includes change sub-windows corresponding to each of multiple system types, and the associated system information includes system type, current change information, and resource information corresponding to each of the multiple associated systems; and a second determining module, configured to determine a change orchestration result corresponding to the business to be changed based on the change sub-windows corresponding to each of the multiple system types, the current change information, and resource information corresponding to each of the multiple associated systems.

[0008] According to another aspect of this application, an electronic device is provided, comprising: one or more processors; and a memory for storing one or more instructions, wherein, when the one or more instructions are executed by the one or more processors, the one or more processors cause the one or more processors to perform the method as described above.

[0009] According to another aspect of this application, a computer-readable storage medium is provided having executable instructions stored thereon, which, when executed by a processor, cause the processor to implement the method described above.

[0010] According to another aspect of this application, a computer program product is provided, the computer program product including computer-executable instructions, which, when executed, are used to implement the method described above.

[0011] According to the embodiments of this application, by dynamically determining time window information and associated system information, and combining conflict detection and integration, the inflexibility of traditional fixed time windows is overcome, the risk of conflict caused by changes by region is avoided, and by integrating the change tasks of associated systems, resource waste is reduced, and flexible, efficient and secure orchestration of business changes is achieved, ensuring the stable operation of the system. Attached Figure Description

[0012] The above and other objects, features and advantages of this application will become clearer from the following description of embodiments with reference to the accompanying drawings, in which:

[0013] Figure 1 This illustration schematically shows a system architecture to which a service change orchestration method can be applied according to an embodiment of the present disclosure;

[0014] Figure 2 A flowchart illustrating a service change orchestration method according to an embodiment of this disclosure is shown schematically.

[0015] Figure 3This illustration shows an example diagram illustrating the process of determining time window information and associated system information for performing a service change based on the service information to be changed indicated by a change request, according to an embodiment of this disclosure.

[0016] Figure 4 This illustration shows an example of a process for determining the change orchestration result corresponding to the service to be changed based on change sub-windows corresponding to multiple system types, current change information corresponding to multiple associated systems, and resource information, according to an embodiment of this disclosure.

[0017] Figure 5 A block diagram of a service change orchestration apparatus according to an embodiment of the present disclosure is schematically shown; and

[0018] Figure 6 A block diagram of an electronic device suitable for implementing a service change orchestration method according to an embodiment of the present disclosure is shown schematically. Detailed Implementation

[0019] The embodiments of this application will now be described with reference to the accompanying drawings. However, it should be understood that these descriptions are exemplary only and are not intended to limit the scope of this application. In the following detailed description, numerous specific details are set forth to provide a thorough understanding of the embodiments of this application for ease of explanation. However, it will be apparent that one or more embodiments may be implemented without these specific details. Furthermore, descriptions of well-known structures and technologies are omitted in the following description to avoid unnecessarily obscuring the concepts of this application.

[0020] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the scope of this application. The terms “comprising,” “including,” etc., as used herein indicate the presence of the stated features, steps, operations, and / or components, but do not exclude the presence or addition of one or more other features, steps, operations, or components.

[0021] All terms used herein (including technical and scientific terms) have the meanings commonly understood by those skilled in the art, unless otherwise defined. It should be noted that the terms used herein are to be interpreted in a manner consistent with the context of this specification, and not in an idealized or overly rigid way.

[0022] When using expressions such as "at least one of A, B and C", they should generally be interpreted in accordance with the meaning that is commonly understood by those skilled in the art (e.g., "a system having at least one of A, B and C" should include, but is not limited to, a system having A alone, a system having B alone, a system having C alone, a system having A and B, a system having A and C, a system having B and C, and / or a system having A, B and C, etc.).

[0023] In the technical solution of this invention, the user information (including but not limited to user personal information, user image information, user device information, such as location information) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, storage, use, processing, transmission, provision, disclosure, and application of related data all comply with relevant laws, regulations, and standards, take necessary confidentiality measures, do not violate public order and good morals, and provide corresponding operation entry points for users to choose to authorize or refuse.

[0024] In scenarios involving automated decision-making using personal information, the methods, devices, and systems provided in this invention offer users corresponding entry points for choosing to agree to or reject the automated decision-making results. If the user chooses to reject, the process proceeds to the expert decision-making stage. Here, "automated decision-making" refers to the activity of automatically analyzing and evaluating an individual's behavioral habits, interests, or economic, health, and credit status through computer programs, and then making a decision. Here, "expert decision-making" refers to the activity of making decisions by personnel who specialize in a particular field, possess specialized experience, knowledge, and skills, and have reached a certain level of professional expertise.

[0025] For change methods based on time periods, since the time period for the change is fixed, it is difficult to adapt to the time zone differences of specific regions when facing business changes in some overseas regions, and it is difficult to support the flexible update needs of regionally specific businesses.

[0026] For time zone-based change methods, the complex interactions of related systems and the difficulty in identifying the scope of changes can easily lead to overlapping time windows and conflicts of critical resources, failing to meet the requirements for stable services. Furthermore, the need for related systems to implement multiple changes to meet different needs can easily result in resource waste.

[0027] In summary, due to the differences in service scope and service time among various systems, the change orchestration methods in related technologies are difficult to effectively guarantee the accuracy and flexibility of business change orchestration.

[0028] To at least partially address the technical problems existing in related technologies, this disclosure provides a business change orchestration method, apparatus, electronic device, storage medium, and program product, which can be applied to computer technology, business processing technology, intelligent operation and maintenance, and fintech fields. The business change orchestration method includes: in response to receiving a change request, determining time window information and associated system information for performing the business change based on the business information to be changed indicated in the change request, wherein the time window information includes change sub-windows corresponding to multiple system types, and the associated system information includes system types, current change information, and resource information corresponding to multiple associated systems; and determining the change orchestration result corresponding to the business to be changed based on the change sub-windows corresponding to the multiple system types, the current change information, and resource information corresponding to the multiple associated systems.

[0029] It should be noted that the business change orchestration method and apparatus provided in this application embodiment can be used in the fields of computer technology, business processing technology, and intelligent operation and maintenance. The business change orchestration method and apparatus provided in this application embodiment can also be used in any field other than computer technology, business processing technology, and intelligent operation and maintenance, such as in the field of fintech. The application fields of the business change orchestration method and apparatus provided in this application embodiment are not limited.

[0030] Figure 1 The illustration schematically depicts a system architecture to which a service change orchestration method can be applied according to embodiments of this disclosure. It should be noted that... Figure 1 The examples shown are merely examples of system architectures that can be applied to the embodiments of this disclosure, in order to help those skilled in the art understand the technical content of this disclosure, but do not mean that the embodiments of this disclosure cannot be used in other devices, systems, environments or scenarios.

[0031] like Figure 1 As shown, the system architecture 100 according to this embodiment may include a first terminal device 101, a second terminal device 102, a third terminal device 103, a network 104, and a server 105. The network 104 serves as a medium for providing communication links between different devices.

[0032] It should be noted that the service change orchestration method provided in this embodiment can generally be executed by the server 105. Accordingly, the service change orchestration device provided in this embodiment can generally be located in the server 105.

[0033] Alternatively, the service change orchestration method provided in this embodiment of the present disclosure can also be executed by the first terminal device 101, the second terminal device 102, or the third terminal device 103. Correspondingly, the service change orchestration device provided in this embodiment of the present disclosure can also be disposed in the first terminal device 101, the second terminal device 102, or the third terminal device 103.

[0034] It should be understood that Figure 1 The number of terminal devices, networks, and servers shown is merely illustrative. Depending on implementation needs, any number of terminal devices, networks, and servers can be included.

[0035] It should be noted that the sequence numbers of the operations in the following methods are for descriptive purposes only and should not be considered as indicating the execution order of the operations. Unless explicitly stated otherwise, the method does not need to be executed in the exact order shown.

[0036] The foregoing section described the system architecture for which business change orchestration methods can be applied, as disclosed in this publication. The following section will use... Figure 2 As an example, the business change orchestration process disclosed herein will be further explained.

[0037] Figure 2 A flowchart illustrating a service change orchestration method according to an embodiment of this disclosure is shown schematically.

[0038] like Figure 2 As shown, the business change orchestration method 200 includes operations S210~S220.

[0039] In operation S210, in response to receiving a change request, based on the change request indicating the change information of the service to be changed, the time window information and associated system information for performing the service change are determined. The time window information includes change sub-windows corresponding to each of the multiple system types, and the associated system information includes the system type, current change information and resource information corresponding to each of the multiple associated systems.

[0040] In operation S220, based on the change sub-windows corresponding to each of the multiple system types, the current change information and resource information corresponding to each of the multiple associated systems, the change orchestration result corresponding to the business to be changed is determined.

[0041] A change request is a request initiated by a user or system to modify, upgrade, or update existing services. A change request may include information about the service to be changed, such as the expected change date, the system to which it belongs, and the region to which it belongs. For example, if a bank plans to modify its deposit system in overseas region X on April 1st, the system to which it belongs is the deposit system, the region to which it belongs is overseas region X, and the expected change date is April 1st.

[0042] Upon receiving a change request, the time window and related system information for implementing the change can be determined based on the business information to be changed indicated in the request. The time window refers to the time frame for implementing the change based on the business information to be changed. Related system information refers to information about other systems that interact with or depend on the business to be changed.

[0043] The time window information can include change sub-windows for each of the multiple system types. For example, the time window information is: real-time systems can be changed from 0:00 to 4:00 on April 1st, real-time interactive systems can be changed from 1:00 to 10:00 on April 1st, and non-real-time interactive systems can be changed from 1:00 to 23:00 on April 1st. This indicates that the change sub-window corresponding to the real-time system is "0:00 to 4:00 on April 1st", the change sub-window corresponding to the real-time interactive system is "1:00 to 10:00 on April 1st", and the change sub-window corresponding to the non-real-time interactive system is "1:00 to 23:00 on April 1st".

[0044] The associated system information can include system type, current change information, and resource information. For example, if the associated systems corresponding to the business to be changed (1) include the mobile banking system, the branch counter system, and the statistical reporting system, then the associated system information can be: Mobile banking system (real-time system, no current change information, key resource is program A); Branch counter system (real-time system, no current change information, key resource is program A); Statistical reporting system (non-real-time system, no current change information, key resource is program B).

[0045] The methods for determining time window information and associated system information can be configured according to actual business needs and are not limited here. For example, time window information can be determined based on the time zone and business characteristics of the business to be changed; at the same time, other systems that interact with or depend on the business system to be changed can be scanned to determine associated system information. Alternatively, the corresponding time window information and associated system information can be directly matched based on the business type and time zone using a pre-defined rule base.

[0046] After determining the time window information and related system information, the change orchestration result corresponding to the business to be changed can be determined based on the change sub-windows corresponding to each of the multiple system types included in the time window information, the system types corresponding to each of the multiple related systems included in the related system information, the current change information, and resource information. The change orchestration result refers to the final change implementation plan determined after conflict detection and integration based on the time window information and related system information. For example, the change orchestration result could be: the deposit system will be changed from 0:00 to 4:00 on April 1st; the mobile banking system will be changed from 1:00 to 2:00 on April 1st; and the statistical reporting system will be changed from 1:00 to 3:00 on April 1st.

[0047] According to embodiments of this disclosure, by dynamically determining time window information and associated system information, and combining conflict detection and integration, the inflexibility of traditional fixed time windows is overcome, the risk of conflict caused by changes by region is avoided, and by integrating change tasks of associated systems, resource waste is reduced, and flexible, efficient and secure orchestration of business changes is achieved, ensuring the stable operation of the system.

[0048] The following is for reference. Figure 3 and Figure 4 The following is a further explanation of the business change orchestration method 200 according to an embodiment of the present invention.

[0049] According to an embodiment of this disclosure, operation S210 may include the following operations: determining time window information based on the expected change time and the regional time zone of the home region; scanning systems that have data interaction or business calls with the home system to obtain associated system information.

[0050] The information regarding the business to be changed includes the expected change time, the system to which the change is made, and the region to which the change is made. Before sending the information to the server, the validity of the parameters for the expected change time, the system to which the change is made, and the region to which the change is made can be checked separately to ensure the validity of the input parameters.

[0051] The expected change time refers to the specific time when the change operation is planned, providing a time range constraint for the change integration. For example, the expected change time is from 1:00 AM to 4:00 AM on April 1st. The system to which the change belongs refers to the specific business system to which the business to be changed belongs, i.e., the core system of this change integration. For example, the system to which the change belongs is the mobile banking system. The region to which the change belongs refers to the geographical area or time zone to which the business to be changed belongs, determining the specific time zone that this change needs to match. For example, the region to which the change belongs is overseas region X.

[0052] Upon receiving a change request, the specific time period for the change operation can be determined based on the expected change time and the time zone of the user's region in the business information to be changed, thus obtaining time window information. That is, based on the input parameters and the time zone of the product's location, time windows are formed for different types of related systems to coordinate with changes to the core system. For example, if the expected change time is from 1:00 AM to 4:00 AM on April 1st, and the user's region is overseas region X with a time zone of UTC+8, then the time window information can be determined to be from 1:00 AM to 4:00 AM on April 1st.

[0053] After receiving a change request, the system can also scan for systems that interact with or make business calls to the parent system to obtain related system information. This involves scanning a list of related systems that have changed within the core system, recording the association type and key program resources of each system. For example, if the parent system is a mobile banking system, the scan might reveal systems that interact with it, such as branch counter systems and statistical reporting systems. Recording the system type, current change information, and key resource information of these systems yields the related system information.

[0054] According to embodiments of this disclosure, by combining the expected change time and the time zone of the home region to determine the time window information, it is possible to flexibly respond to change requirements in different regions; by scanning and obtaining related system information, it is possible to fully understand the dependencies of change operations and effectively avoid potential conflicts during the change process. Based on this, not only is the efficiency of change management improved and the accuracy and efficiency of change operations ensured, but the stability and reliability of the system are also enhanced.

[0055] According to embodiments of this disclosure, determining time window information based on the expected change time and the local time zone of the home region may include the following operations: using the local time zone of the home region as a reference, removing the non-service periods of the local time zone within the expected change time to obtain the change window range; and within the change window range, determining change sub-windows corresponding to each of the multiple system types.

[0056] The regional time zone of the originating region refers to the time zone of the region where the business to be changed belongs, used to determine the time base for the change operation. For example, if the originating region is overseas region X, its time zone is UTC+8. After determining the regional time zone of the originating region, the non-service hours of that region can be removed based on the region's time zone and the expected change time to determine the time range available for the change operation. The change window range refers to the time range available for the change operation after removing non-service hours within the expected change time. For example, if the expected change time is from 1:00 AM to 4:00 AM on April 1st, and the non-service hours of overseas region X are from 1:00 AM to 4:00 AM, then the change window range is from 1:00 AM to 4:00 AM. Alternatively, a time zone conversion tool can be used to automatically calculate and remove non-service hours to determine the change window range.

[0057] After determining the scope of the change window, specific time periods within that window can be used for change operations, based on system type, can be identified, resulting in multiple sub-windows for each system type. For example, the change window for real-time systems (such as mobile banking systems) is from 1:00 AM to 2:00 AM, while for non-real-time systems (such as statistical reporting systems) it is from 2:00 AM to 4:00 AM. Alternatively, automated scheduling algorithms can be used to dynamically allocate change sub-windows based on system type and resource dependencies.

[0058] According to embodiments of this disclosure, by using the home region time zone as a reference, removing non-service periods, accurately determining the range of change windows, and allocating change sub-windows for different system types within this range, not only is the impact of change operations on the normal operation of the system reduced, but resource utilization efficiency is also optimized, effectively improving the flexibility and security of change management.

[0059] According to embodiments of this disclosure, within the scope of the change window, determining the change sub-windows corresponding to each of the multiple system types may include the following operations: within the scope of the change window, allocating a first priority time period to systems belonging to the real-time interaction type and allocating a second priority time period to systems belonging to the non-real-time interaction type, thereby obtaining change sub-windows corresponding to each of the multiple system types, wherein the second priority time period covers the first priority time period.

[0060] Based on their interactive characteristics in business operations, systems can be categorized into real-time interaction types and non-real-time interaction types. Real-time interaction systems require immediate responses to user actions and typically have strict requirements on response time. For example, real-time interaction systems might include mobile banking systems, where immediate feedback is needed after a user initiates a transfer. Non-real-time interaction systems do not require immediate responses to user actions and typically have lower requirements on response time. For example, non-real-time interaction systems might include statistical reporting systems, where reports are typically generated in the background and displayed directly to the user when querying them.

[0061] For real-time interactive systems, a first-priority time slot can be assigned. This first-priority time slot refers to a high-priority change period to ensure that these systems can smoothly perform change operations when immediate responses are required. For example, within the change window, 1:00 AM to 2:00 AM might be allocated to real-time interactive systems. Alternatively, the Earliest Deadline First (EDF) scheduling algorithm can be used to dynamically allocate priority time slots based on task deadlines.

[0062] For non-real-time interactive systems, a second-priority time slot can be assigned. This second-priority time slot is a lower-priority change period that overrides the first-priority time slot, ensuring that these systems perform change operations after the real-time interactive systems have completed their changes. For example, within the change window, 1 AM to 4 AM is allocated to non-real-time interactive systems. Alternatively, an explicit priority allocation method can be used, assigning priorities based on the importance and urgency of the tasks.

[0063] According to embodiments of this disclosure, by reasonably allocating change time periods with different priorities for different system types, the priority of real-time interactive systems in change operations is ensured, while also taking into account the change needs of non-real-time interactive systems. This not only improves the flexibility and efficiency of change management and reduces the impact of change operations on users, but also ensures the stability and reliability of the system and optimizes resource utilization efficiency.

[0064] Figure 3 The illustration shows an example diagram illustrating the process of determining time window information and associated system information for performing a service change based on the service information to be changed indicated by the change request according to an embodiment of the present disclosure.

[0065] like Figure 3 As shown in Figure 300, the business information to be changed 310 includes the region of origin 311, the expected change time 312, and the system of origin corresponding to the business to be changed.

[0066] In one embodiment, the time window information 307 may be determined based on the home region 311 and the expected change time 312. For example, the change window range 302 may be obtained by removing the non-service periods of the home region 311's time zone 301 within the expected change time 312. Within the change window range 302, a first priority time period 305 is allocated to systems belonging to the real-time interaction type 303, and a second priority time period 306 is allocated to systems belonging to the non-real-time interaction type 304. The resulting change sub-windows corresponding to each of the multiple system types are then used as the time window information 307.

[0067] In another embodiment, the associated system information 308 may be determined based on the home system 313. For example, the associated system information 308 may be obtained by scanning systems that have data interactions or business calls with the home system 313.

[0068] According to an embodiment of this disclosure, operation S220 may include the following operations: based on the change sub-windows corresponding to each of the multiple system types, detecting the current change information and resource information corresponding to each of the multiple associated systems to obtain detection results; in response to the intermediate orchestration information obtained by processing each change sub-window based on the detection results being verified, using the intermediate orchestration information as the change orchestration result.

[0069] The current change information and resource information of each associated system refers to the change task information and key resource information of other systems that have interaction or dependency with the business system to be changed. For example, the current change information of the mobile banking system is "none", and the key resource is program A; the current change information of the statistical reporting system is "change scheduled for April 1", and the key resource is program B.

[0070] For the current change and resource information of each associated system, you can check the current change tasks and resource usage of the associated systems through the change sub-window for each system type to determine whether there are conflicts or resource unavailability, and obtain the detection results. The detection results refer to the results obtained after checking the current change and resource information of the associated systems, including whether there are conflicts and whether resources are available. For example, the detection results may show that the mobile banking system has no conflicts, but the statistical reporting system has resource conflicts.

[0071] For example, the change sub-window for the deposit system (real-time system) is from 00:00 to 04:00 on April 1st, while the change sub-window for the statistical reporting system (non-real-time system) is from 01:00 to 23:00 on April 1st. Detection revealed that the statistical reporting system already had change tasks from 01:00 to 03:00 on April 1st, and that critical resource B had a conflict. Alternatively, machine learning algorithms can be used to predict the resource usage of related systems based on historical data, thus identifying potential conflicts in advance.

[0072] After obtaining the test results, intermediate arrangement information can be obtained by processing each change sub-window based on the test results. Intermediate arrangement information refers to the preliminary change plan generated after processing the change sub-windows based on the test results. For example, the intermediate arrangement information could be that the change time for the mobile banking system is from 1:00 AM to 2:00 AM on April 1st, and the change time for the statistical report system is from 1:00 AM to 3:00 AM on April 1st. If the intermediate arrangement information passes verification, it can be used as the change arrangement result. The change arrangement result refers to the final change plan after verification and confirmation that it is correct.

[0073] According to embodiments of this disclosure, by dynamically detecting and adjusting the change sub-windows, combined with the verification of intermediate orchestration information, change failures caused by resource conflicts or improper timing can be effectively avoided. At the same time, by identifying potential problems in advance, efficient, flexible and secure orchestration of business changes is achieved, which helps to improve the success rate of change implementation and the stability of the system.

[0074] According to embodiments of this disclosure, based on change sub-windows corresponding to multiple system types, current change information and resource information corresponding to multiple associated systems are detected to obtain detection results. This can include the following operations: determining a change background window based on the change sub-windows corresponding to multiple system types and the current change information corresponding to multiple associated systems; and performing at least one of resource conflict detection and time conflict detection on the current change information and resource information corresponding to multiple associated systems based on the change background window to obtain detection results.

[0075] For the current change information and resource information of each related system, a comprehensive time range can be determined by combining the change sub-windows for each system type and the current change information of the related systems, thus obtaining the change background window. The change background window refers to the time range that can be used for changes, determined based on the change sub-windows for each system type and the current change information of the related systems.

[0076] For example, the change sub-window for the deposit system (real-time system) is from 00:00 to 04:00 on April 1st, while the change sub-window for the statistical reporting system (non-real-time system) is from 01:00 to 23:00 on April 1st. Current change information shows that the statistical reporting system already had change tasks from 01:00 to 03:00 on April 1st. Based on this, the change background window can be determined to be from 01:00 to 04:00 on April 1st. Alternatively, time series analysis techniques can be used to predict the optimal change background window based on historical change data to reduce potential conflicts.

[0077] After identifying the change background window, you can check the current change tasks and resource usage of related systems within it to determine if there are any resource or time conflicts. For example, in the change background window from 1 AM to 4 AM on April 1st, the mobile banking system was found to have no conflicts, while the statistical reporting system had a resource conflict (critical resource B was occupied). Therefore, the detection result is that the mobile banking system has no conflicts, while the statistical reporting system has a resource conflict. Alternatively, a multi-task resource conflict segmentation detection method can be introduced, which can accurately detect resource and time conflicts by constructing a time interval model of resource usage.

[0078] In the embodiments of this disclosure, by receiving time window information and associated system information, change implementation window preprocessing is performed according to system type, and integrated evaluation is performed in combination with the existing change situation of associated systems to determine the conflict of use of key resources and the overlap of change windows.

[0079] For example, mobile banking and branch counters are real-time systems, while statistical reports are non-real-time systems, and time windows are preset. On the same day, other system products are modified in mobile banking and statistical reports. Mobile banking involves key program resource C, which does not involve change conflicts, while statistical reports involve key program resource B, which has conflicts. During the scheduling, the mobile banking system will connect the time of the two changes to ensure that two requirements are completed in one change to eliminate waste. The reporting system will merge the two changes into one time window to eliminate conflicts.

[0080] According to embodiments of this disclosure, by dynamically determining the change background window and performing resource conflict detection and time conflict detection within that window, change failures caused by resource conflicts or improper timing can be effectively avoided. At the same time, by identifying potential problems in advance, the success rate of change implementation and system stability are improved, which helps to achieve efficient, flexible and secure orchestration of business changes.

[0081] According to embodiments of this disclosure, determining a change background window based on change sub-windows corresponding to multiple system types and current change information corresponding to multiple associated systems may include the following operations: for each associated system, configuring a time window for which changes can be implemented based on the change sub-window of the system type and the window corresponding to non-peak business hours; and determining a change background window based on the time window for which changes can be implemented and the current change information.

[0082] When it's necessary to determine the window for a change in the background, the time period with lower business load on the related system during the day can be identified as the window corresponding to the non-peak business period for that system. For example, by analyzing system logs or traffic data, it can be found that the mobile banking system has the lowest business load between 1 AM and 4 AM every day, thus identifying this time period as the window corresponding to the non-peak business period. Alternatively, machine learning algorithms can be used to analyze historical traffic data and automatically predict the window corresponding to the non-peak business period.

[0083] According to embodiments of this disclosure, the change background window is determined by accurately calculating the intersection of the window corresponding to the non-peak business period and the current change window. This allows for flexible responses to different business needs and system states, thereby providing the best time arrangement for change operations. This not only reduces the impact of change operations on the normal operation of the system, but also improves the efficiency and security of change management.

[0084] According to embodiments of this disclosure, based on the change background window, at least one of resource conflict detection and time conflict detection is performed on the current change information and resource information corresponding to each of the multiple associated systems to obtain a detection result. This can include the following operations: based on the change background window, resource conflict detection is performed on the resource information corresponding to each of the multiple associated systems to obtain a resource conflict detection result; if the resource conflict detection result indicates that there is no conflict in resource calls, time overlap detection is performed on the current change information corresponding to each of the multiple associated systems based on the change background window to obtain a time overlap detection result.

[0085] Resource information of related systems refers to the usage of critical resources in other systems that interact with or depend on the business system to be changed. For example, the critical resource of the mobile banking system is program A, and the critical resource of the statistical reporting system is program B. In the change background window, check whether the critical resources of related systems are occupied by other tasks to determine if there are resource conflicts and obtain the resource conflict detection results. The resource conflict detection results are the results obtained after checking the resource information of related systems, indicating whether resource conflicts exist. For example, the resource conflict detection results show that the mobile banking system has no resource conflicts, but the statistical reporting system has resource conflicts.

[0086] For example, during the background change window (1 AM to 3 AM), it was detected that the critical resource program A of the mobile banking system was not occupied, while the critical resource program B of the statistical reporting system was occupied. Therefore, the resource conflict detection result showed that there was no conflict in the mobile banking system, but a conflict existed in the statistical reporting system. Alternatively, machine learning algorithms can be used to predict resource conflicts based on historical resource usage data and adjust resource allocation in advance.

[0087] If the resource conflict detection results indicate no resource conflict, the current change information of related systems is further examined to determine if there is any time overlap, resulting in a time overlap detection result. The current change information of related systems refers to the existing change task information of other systems that interact with or depend on the system to be changed. The time overlap detection result is the result obtained after detecting the current change information of related systems, indicating whether time overlap exists. For example, the time overlap detection result shows that the time window of the mobile banking system overlaps with the time window of the statistical reporting system.

[0088] For example, resource conflict detection results show no conflict in the mobile banking system. Further examination of its current change information reveals that the mobile banking system's time window is from 1:00 AM to 2:00 AM, while the statistical reporting system's time window is from 1:00 AM to 3:00 AM, indicating time overlap. Therefore, the time overlap detection results show a conflict. Alternatively, time series analysis tools can be used to automatically calculate the time windows of multiple related systems and detect any overlap.

[0089] According to embodiments of this disclosure, by performing resource conflict detection and time overlap detection within the change background window, resource conflict detection ensures the availability of critical resources during the change process, while time overlap detection further optimizes the timing of change tasks, effectively avoiding resource and time conflicts in change operations and improving the efficiency and security of change management.

[0090] According to embodiments of this disclosure, resource conflict detection is performed on resource information corresponding to multiple associated systems based on the change background window to obtain resource conflict detection results. This can include the following operations: for each associated system, detecting whether the resource information meets resource conflict conditions, wherein the resource conflict conditions include at least one of the following: the resource is simultaneously invoked by the business to be changed and other change businesses within the change background window, and the resource has overlapping modification periods within the change background window; in response to the resource information meeting the resource conflict conditions, determining a resource conflict detection result that indicates a conflict in resource invocation.

[0091] Resource conflict refers to a competitive state that occurs in a concurrent environment when multiple processes or threads attempt to access the same resource simultaneously. For example, within a change background window, program A is simultaneously invoked by two different change tasks, leading to a resource conflict. The critical program resources of each related system are checked to determine if they meet any of the following conflict conditions: the critical program resource is simultaneously invoked by the business to be changed and other change businesses within the change background window; or the critical program resource has overlapping modification periods within the change background window.

[0092] Detecting whether critical program resources are being accessed simultaneously can be achieved by scanning resource information of related systems and checking the access status of critical program resources within the background window. Alternatively, concurrency control mechanisms, such as mutexes or semaphores, can be used to detect whether resources are being accessed by multiple tasks simultaneously.

[0093] Detecting overlapping modification periods for critical program resources can be achieved by analyzing change plans of related systems to check for overlaps. Alternatively, time series analysis tools can be used to automatically calculate the modification periods for critical program resources and detect any overlaps.

[0094] If any of the critical program resources meet the conflict conditions, a resource conflict is determined, and a resource conflict detection result indicating a conflict in resource calls is established. If none of the conditions are met, a resource conflict detection result indicating no conflict in resource calls is established. For example, if program A is called by two tasks simultaneously within a background change window, meeting the conflict conditions, a resource conflict detection result indicating a conflict in resource calls can be established. If program B is not called by any other task within the background change window, a resource conflict detection result indicating no conflict in resource calls can be established.

[0095] According to embodiments of this disclosure, by accurately detecting whether the critical program resources of the associated system meet the conflict conditions, complex change scenarios can be flexibly addressed. This not only improves the efficiency and security of change management, but also reduces the risk of system instability and change failure caused by resource conflicts, thus helping to ensure the stable operation of the system.

[0096] According to embodiments of this disclosure, based on the change background window, time overlap detection is performed on the current change information corresponding to each of multiple associated systems to obtain time overlap detection results. This can include the following operations: for each associated system, the change sub-window corresponding to the system type of the associated system is taken as the window to be changed; based on at least one existing window and a candidate window corresponding to non-peak business periods, a target window for which changes can be implemented is determined; and based on the window to be changed and the target window of the associated system, time window overlap detection is performed to obtain time overlap detection results.

[0097] Current change information includes at least one existing window. An existing window refers to a time period during which a change operation has been scheduled by the associated system within a specific change date. For example, the statistical reporting system has scheduled a change operation from 1:00 AM to 3:00 AM on April 1st. A candidate window refers to a time period corresponding to a non-peak business period, serving as a potential time period for change operations. For example, the non-peak business period is from 1:00 AM to 4:00 AM, therefore the candidate window is also from 1:00 AM to 4:00 AM.

[0098] The target window refers to the time period during which changes can ultimately be implemented, determined based on existing windows and candidate windows. For example, if the existing window is from 1 a.m. to 3 a.m. and the candidate window is from 1 a.m. to 4 a.m., the target window could be from 1 a.m. to 3 a.m. (if the existing window takes priority) or from 3 a.m. to 4 a.m. (if conflicts need to be avoided).

[0099] For each related system, the time period during which changes can be implemented can be determined by combining existing windows and candidate windows. For example, if the statistical reporting system has an existing window from 1:00 AM to 3:00 AM and a candidate window from 1:00 AM to 4:00 AM, the target window is 1:00 AM to 3:00 AM if the existing window takes priority; otherwise, the target window is 3:00 AM to 4:00 AM if conflicts need to be avoided. Alternatively, time series analysis tools can be used to automatically calculate the intersection or union of existing and candidate windows to determine the target window.

[0100] After determining the target windows of each associated system, it's possible to detect whether there's a time overlap between the window to be changed and the target window in the associated system, thus obtaining a time overlap detection result. The time overlap detection result refers to the result indicating whether there is a time overlap between the window to be changed and the target window in the associated system. For example, the detection result shows that the window to be changed in the mobile banking system (1 AM to 4 AM) overlaps with the target window in the statistical report system (1 AM to 3 AM). Alternatively, a time interval algorithm can be used to automatically detect the intersection of two time periods to determine if there is overlap.

[0101] According to embodiments of this disclosure, by accurately determining the window to be changed and the target window of the associated system and performing time overlap detection, time conflicts in change operations are effectively avoided. This not only improves the efficiency and security of change management but also reduces the risk of change failure due to improper time scheduling. By dynamically adjusting the target window, different business needs and system states can be flexibly addressed, ensuring the stable operation of the system.

[0102] According to embodiments of this disclosure, the business change orchestration method 200 may further include the following operations: when the resource conflict detection result indicates that there is a conflict in resource calls, or when the time overlap detection result indicates that there is an overlap in change windows, the current change and the existing change that occupies the same resource are merged into the same time window for execution; when the time overlap detection result indicates that there is no overlap in change windows, the current change is executed after the existing change window.

[0103] If resource conflicts or time overlaps are detected, the current change task and existing change tasks are merged into the same time window for execution to avoid conflicts. This involves analyzing whether there are program resource change conflicts; if so, the existing change window is used. Merging execution means scheduling the current change task and existing change tasks that consume the same resources to execute within the same time window.

[0104] For example, critical program resource B of the statistical reporting system is simultaneously invoked by two different change tasks within the change background window (1 AM to 3 AM), resulting in a resource conflict. Therefore, the current change in the mobile banking system and the existing change in the statistical reporting system are merged into the 1 AM to 3 AM time window for execution. Alternatively, time series analysis tools can be used to automatically calculate the merged time window to ensure maximum resource utilization efficiency.

[0105] If no time overlap is detected between the current change window and existing change windows, the current change task is scheduled to execute within the time window following the existing change task. This involves analyzing whether there is overlap with other change windows; if there is overlap, the existing window is used; otherwise, the existing change window is expanded. Seamless execution refers to scheduling the current change task to execute within the time window following the existing change task.

[0106] For example, if the current change window for the statistical reporting system is from 1:00 AM to 3:00 AM, and the current change window for the mobile banking system is from 1:00 AM to 4:00 AM, and there is no time overlap, then the change for the mobile banking system will be scheduled to be executed between 3:00 AM and 4:00 AM. Alternatively, scheduling algorithms, such as the Earliest Start Time (EST) algorithm, can be used to automatically schedule the current change task to be executed within the time window following the existing change task.

[0107] According to embodiments of this disclosure, by dynamically detecting resource conflicts and time overlaps and flexibly adjusting the execution method of change tasks based on the detection results, resource conflicts and time conflicts in change operations are effectively avoided. This not only improves the efficiency and security of change management but also reduces the risk of change failure due to resource conflicts or improper time scheduling. Based on this, by intelligently scheduling and merging change tasks, the stable operation of the system is ensured, while optimizing resource utilization efficiency.

[0108] Figure 4The illustration shows an example of a process for determining the change orchestration result corresponding to the service to be changed based on change sub-windows corresponding to multiple system types, current change information corresponding to multiple associated systems, and resource information, according to an embodiment of the present disclosure.

[0109] like Figure 4 As shown in section 400, for each associated system, a time window 403 for implementing changes can be configured based on the system type change sub-window 401 and the window 402 corresponding to non-peak business periods. Based on this, a change background window 405 can be determined according to the time window 403 for implementing changes and the current change information 404.

[0110] Based on the background change window 405, resource conflict detection is performed on the resource information 406 corresponding to each of the multiple associated systems to obtain the resource conflict detection results. After obtaining the resource conflict detection results, operation S410 can be executed.

[0111] In operation S410, are there any resource allocation conflicts? If so, the current change and existing changes that occupy the same resources can be merged and executed in the same time window 407. If not, operation S420 can be executed.

[0112] When operating S420, are there any overlapping change windows? If so, the current change and existing changes that consume the same resources can be merged into the same time window 407 for execution. If not, the current change can be executed after the existing change window 408.

[0113] In the embodiments of this disclosure, a change window is generated based on the non-service time period corresponding to the time zone of the region to be changed, and the change window is divided into sub-windows based on the system type to obtain time window information. This avoids the problem that the change method with a fixed time period is difficult to adapt to the time zone differences of specific regions, and helps to achieve rapid response and flexible adjustment of cross-time zone changes.

[0114] By evaluating changes based on time window information and related system information associated with the core system of the product to be changed, the risk of inter-system dependencies can be eliminated within the change window while maintaining time flexibility, ensuring accurate interaction between the core system and the changed product. Furthermore, since related system information can be summarized and checked according to changes on specific dates for each related system, the risk of systemic service anomalies caused by setting windows for individual changes and lacking an overall perspective between changes can be avoided. On this basis, by performing resource usage conflict detection and / or time window overlap detection based on the change windows and target windows of each related system, changes to related systems can be integrated. This achieves information aggregation of multiple changes at the system level, ensuring efficient resource utilization for changes to a single system on the same date and avoiding system instability and resource waste introduced when changes are implemented over multiple time periods.

[0115] The above are merely exemplary embodiments, but are not limited thereto. Other business change orchestration methods known in the art may also be included, as long as they can achieve flexible, efficient, and secure orchestration of business changes.

[0116] Based on the above-described business change orchestration method, this invention also provides a business change orchestration apparatus. The following will be combined with... Figure 5 The device is described in detail.

[0117] Figure 5 A block diagram of a service change orchestration apparatus according to an embodiment of the present disclosure is shown schematically.

[0118] like Figure 5 As shown, the business change orchestration device 500 may include a first determining module 510 and a second determining module 520.

[0119] The first determining module 510 is used to respond to receiving a change request and determine the time window information and associated system information for performing the business change based on the business information to be changed indicated in the change request. The time window information includes change sub-windows corresponding to each of the multiple system types, and the associated system information includes the system type, current change information and resource information corresponding to each of the multiple associated systems.

[0120] The second determining module 520 is used to determine the change orchestration result corresponding to the business to be changed based on the change sub-windows corresponding to each of the multiple system types, the current change information and resource information corresponding to each of the multiple associated systems.

[0121] According to embodiments of this disclosure, the second determining module 520 may include a detection submodule and a first determining submodule.

[0122] The detection submodule is used to detect the current change information and resource information corresponding to multiple associated systems based on the change sub-windows corresponding to multiple system types, and obtain the detection results.

[0123] The first determination submodule is used to respond to the intermediate arrangement information obtained by processing each change sub-window according to the detection results, and to use the intermediate arrangement information as the change arrangement result after verification.

[0124] According to embodiments of this disclosure, the detection submodule may include a first determining unit and a detection unit.

[0125] The first determining unit is used to determine the change background window based on the change sub-windows corresponding to each of the multiple system types and the current change information corresponding to each of the multiple associated systems.

[0126] The detection unit is used to perform at least one of resource conflict detection and time conflict detection on the current change information and resource information corresponding to multiple associated systems based on the change background window, and obtain the detection result.

[0127] According to embodiments of this disclosure, the first determining unit may include a configuration subunit and a first determining subunit.

[0128] The configuration subunit is used to configure the time window for implementing changes for each associated system, based on the system type change sub-window and the window corresponding to the non-peak business period.

[0129] The first determining sub-unit is used to determine the change background window based on the time window in which changes can be implemented and the current change information.

[0130] According to embodiments of this disclosure, the detection unit may include a first detection subunit and a second detection subunit.

[0131] The first detection subunit is used to perform resource conflict detection on the resource information corresponding to multiple associated systems based on the changed background window, and obtain the resource conflict detection results.

[0132] The second detection subunit is used to perform time overlap detection on the current change information corresponding to multiple associated systems based on the change background window, when the resource conflict detection result indicates that there is no conflict in resource calls, and obtain the time overlap detection result.

[0133] According to an embodiment of this disclosure, the first detection subunit is configured to: for each associated system, detect whether the resource information meets the resource conflict conditions, wherein the resource conflict conditions include at least one of the following: the resource is simultaneously invoked by the service to be changed and other services to be changed within the change background window, and the resource has overlapping modification periods within the change background window; in response to the resource information meeting the resource conflict conditions, determine a resource conflict detection result that indicates a conflict in the resource invocation.

[0134] According to embodiments of this disclosure, the current change information includes at least one existing window, and the second detection subunit is used to: for each associated system, take the change sub-window corresponding to the system type of the associated system as the window to be changed; determine the target window that can be changed based on at least one existing window and the candidate window corresponding to the non-peak business period; and perform time window overlap detection based on the window to be changed and the target window of the associated system to obtain the time overlap detection result.

[0135] According to embodiments of this disclosure, the detection unit may include a first execution subunit and a second execution subunit.

[0136] The first execution subunit is used to merge the current change and existing changes that occupy the same resources into the same time window for execution when the resource conflict detection result indicates that there is a conflict in resource calls, or the time overlap detection result indicates that there is an overlap in change windows.

[0137] The second execution subunit is used to execute the current change after the existing change window if the time overlap detection result indicates that the change window does not overlap.

[0138] According to embodiments of this disclosure, the information to be changed includes the expected change time, system of origin, and region of origin corresponding to the service to be changed. The first determining module 510 may include a second determining submodule and a scanning submodule.

[0139] The second determination submodule is used to determine the time window information based on the expected change time and the regional time zone of the region.

[0140] The scanning submodule is used to scan systems that have data interactions or business calls with the parent system to obtain information about the associated systems.

[0141] According to embodiments of this disclosure, the second determining submodule may include a second determining unit and a third determining unit.

[0142] The second determining unit is used to remove the non-service periods of the regional time zone within the expected change time, based on the regional time zone of the home region, to obtain the change window range.

[0143] The third determining unit is used to determine the change sub-windows corresponding to each of the multiple system types within the change window range.

[0144] According to embodiments of this disclosure, the system type includes a real-time interactive type or a non-real-time interactive type, and the third determining unit may include a second determining subunit.

[0145] The second determining sub-unit is used to allocate a first priority time period for systems belonging to the real-time interaction type and a second priority time period for systems belonging to the non-real-time interaction type within the scope of the change window, thereby obtaining change sub-windows corresponding to each of the multiple system types, wherein the second priority time period covers the first priority time period.

[0146] Any one or more of the modules, submodules, units, and subunits according to embodiments of the present disclosure, or at least part of the functions of any one or more of them, can be implemented in one module. Any one or more of the modules, submodules, units, and subunits according to embodiments of the present disclosure can be implemented by dividing them into multiple modules. Any one or more of the modules, submodules, units, and subunits according to embodiments of the present disclosure can be at least partially implemented as hardware circuitry, such as a Field-Programmable Gate Array (FPGA), a Programmable Logic Array (PLA), a System-on-Chip, a System-on-a-Substrate, a System-on-Package, an Application-Specific Integrated Circuit (ASIC), or implemented in hardware or firmware by any other reasonable means of integrating or packaging circuitry, or implemented in software, hardware, or firmware, or in any suitable combination of any of these three implementation methods. Alternatively, one or more of the modules, submodules, units, and subunits according to embodiments of the present disclosure can be at least partially implemented as computer program modules, which, when run, can perform corresponding functions.

[0147] It should be noted that the service change orchestration device part in the embodiments of this disclosure corresponds to the service change orchestration method part in the embodiments of this disclosure. For a detailed description of the service change orchestration device part, please refer to the service change orchestration method part, which will not be repeated here.

[0148] Figure 6 A block diagram of an electronic device suitable for implementing a service change orchestration method according to an embodiment of the present disclosure is shown schematically. Figure 6 The electronic device shown is merely an example and should not be construed as limiting the functionality and scope of the embodiments disclosed herein.

[0149] like Figure 6As shown, a computer electronic device 600 according to an embodiment of the present disclosure includes a processor 601, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 602 or a program loaded from a storage portion 609 into a random access memory (RAM) 603. The processor 601 may include, for example, a general-purpose microprocessor (e.g., a CPU), an instruction set processor and / or an associated chipset and / or a special-purpose microprocessor (e.g., an application-specific integrated circuit (ASIC)), etc. The processor 601 may also include onboard memory for caching purposes. The processor 601 may include a single processing unit or multiple processing units for performing different actions of the method flow according to an embodiment of the present disclosure.

[0150] RAM 603 stores various programs and data required for the operation of electronic device 600. Processor 601, ROM 602, and RAM 603 are interconnected via bus 604.

[0151] According to embodiments of this disclosure, the electronic device 600 may further include an input / output (I / O) interface 605, which is also connected to a bus 604. The electronic device 600 may also include one or more of the following components connected to the input / output (I / O) interface 605: an input section 606 including a keyboard, mouse, etc.; an output section 607 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and a speaker, etc.; a storage section 608 including a hard disk, etc.; and a communication section 609 including a network interface card such as a LAN card, modem, etc. The communication section 609 performs communication processing via a network such as the Internet. A drive 610 is also connected to the input / output (I / O) interface 605 as needed. A removable medium 611, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., is installed on the drive 610 as needed so that computer programs read from it can be installed into the storage section 608 as needed.

[0152] This disclosure also provides a computer-readable storage medium, which may be included in the device / apparatus / system described in the above embodiments; or it may exist independently and not assembled into the device / apparatus / system. The computer-readable storage medium carries one or more programs, which, when executed, implement the service change orchestration method according to the embodiments of this disclosure.

[0153] In this disclosure, a computer-readable storage medium can be any tangible medium that contains or stores a program that can be used by or in conjunction with an instruction execution system, apparatus, or device.

[0154] Embodiments of this disclosure also include a computer program product comprising a computer program containing program code for performing the methods provided in the embodiments of this disclosure. When the computer program product is run on an electronic device, the program code is used to enable the electronic device to implement the service change orchestration method provided in the embodiments of this disclosure.

[0155] When the computer program is executed by the processor 601, it performs the functions defined in the system / apparatus of this disclosure embodiments. According to embodiments of this disclosure, the systems, apparatuses, modules, units, etc., described above can be implemented by computer program modules.

[0156] According to embodiments of this disclosure, program code for executing computer programs provided in embodiments of this disclosure can be written in any combination of one or more programming languages.

[0157] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this disclosure. It should also be noted that in some alternative implementations, the functions indicated in the boxes may occur in a different order than those shown in the drawings.

[0158] The embodiments of this disclosure have been described above. However, these embodiments are for illustrative purposes only and are not intended to limit the scope of this disclosure. Although various embodiments have been described above, this does not mean that the measures in the various embodiments cannot be used advantageously in combination. The scope of this disclosure is defined by the appended claims and their equivalents. Various substitutions and modifications can be made by those skilled in the art without departing from the scope of this disclosure, and all such substitutions and modifications should fall within the scope of this disclosure.

Claims

1. A method for orchestrating business changes, characterized in that, The method includes: In response to receiving a change request, based on the change request's indication of the change-to-be-changed service information, time window information and associated system information for performing the service change are determined. The time window information includes change sub-windows corresponding to multiple system types, and the associated system information includes the system type, current change information, and resource information corresponding to each of the multiple associated systems. Based on the change sub-windows corresponding to each of the multiple system types, the current change information and resource information corresponding to each of the multiple associated systems, the change orchestration result corresponding to the service to be changed is determined.

2. The method according to claim 1, characterized in that, The step of determining the change orchestration result corresponding to the service to be changed based on the change sub-windows corresponding to each of the multiple system types, the current change information and resource information corresponding to each of the multiple associated systems, includes: Based on the change sub-windows corresponding to each of the multiple system types, the current change information and resource information corresponding to each of the multiple associated systems are detected, and the detection results are obtained; and In response to the intermediate arrangement information obtained by processing each of the modified sub-windows according to the detection results passing the verification, the intermediate arrangement information is used as the modified arrangement result.

3. The method according to claim 2, characterized in that, The step involves detecting the current change information and resource information corresponding to each of the multiple associated systems based on the change sub-windows corresponding to each of the multiple system types, and obtaining the detection results, including: Based on the change sub-windows corresponding to each of the multiple system types and the current change information corresponding to each of the multiple associated systems, a change background window is determined; and Based on the changed background window, at least one of resource conflict detection and time conflict detection is performed on the current change information and resource information corresponding to each of the multiple associated systems to obtain the detection result.

4. The method according to claim 3, characterized in that, The step of determining the change background window based on the change sub-windows corresponding to each of the multiple system types and the current change information corresponding to each of the multiple associated systems includes: For each of the aforementioned associated systems Configure a time window for implementing changes for the associated system based on the change sub-window of the system type and the window corresponding to non-peak business periods; The change background window is determined based on the time window in which the change can be implemented and the current change information.

5. The method according to claim 3, characterized in that, The step involves performing at least one of resource conflict detection and time conflict detection on the current change information and resource information corresponding to each of the multiple associated systems based on the changed background window, to obtain the detection result, including: Based on the changed background window, resource conflict detection is performed on the resource information corresponding to each of the multiple associated systems to obtain resource conflict detection results; and If the resource conflict detection result indicates that there is no conflict in resource calls, then according to the change background window, time overlap detection is performed on the current change information corresponding to each of the multiple associated systems to obtain the time overlap detection result.

6. The method according to claim 5, characterized in that, The step of performing resource conflict detection on the resource information corresponding to each of the multiple associated systems based on the changed background window, and obtaining resource conflict detection results, includes: For each of the associated systems, it is detected whether the resource information meets the resource conflict conditions, wherein the resource conflict conditions include at least one of the following: the resource is simultaneously invoked by the service to be changed and other services to be changed within the change background window, and the resource has overlapping modification periods within the change background window; In response to the resource information satisfying the resource conflict condition, a resource conflict detection result indicating a conflict in resource calls is determined.

7. The method according to claim 5, characterized in that, The current change information includes at least one existing window; The step of performing time overlap detection on the current change information corresponding to each of the multiple associated systems based on the changed background window, and obtaining the time overlap detection result, includes: For each of the aforementioned associated systems The sub-window corresponding to the system type of the associated system will be used as the window to be changed. Based on at least one existing window and candidate windows corresponding to off-peak business periods, determine the target window for which changes can be implemented; and Based on the window to be changed and the target window of the associated system, time window overlap detection is performed to obtain the time overlap detection result.

8. The method according to claim 5, further comprising: If the resource conflict detection result indicates that there is a conflict in resource calls, or if the time overlap detection result indicates that there is an overlap in change windows, the current change and the existing change that occupies the same resource will be merged into the same time window for execution. as well as If the time overlap detection results indicate that there is no overlap in the change windows, the current change will be executed after the existing change window.

9. The method according to any one of claims 1 to 8, characterized in that, The information about the business to be changed includes the expected change time, system to which it belongs, and region to which it belongs. The step of determining the time window information and associated system information for performing the service change based on the service information to be changed indicated by the change request includes: The time window information is determined based on the expected change time and the local time zone of the region of origin; and Scan the systems that have data interaction or business calls with the home system to obtain the information of the associated systems.

10. The method according to claim 9, characterized in that, The step of determining the time window information based on the expected change time and the regional time zone of the home region includes: Based on the local time zone of the region, the non-service periods of the local time zone are removed from the expected change time to obtain the change window range; and Within the scope of the change window, determine the change sub-windows corresponding to each of the multiple system types.

11. The method according to claim 10, characterized in that, The system type includes real-time interactive type or non-real-time interactive type; The step of determining change sub-windows corresponding to each of the multiple system types within the scope of the change window includes: Within the scope of the change window, a first priority time period is assigned to the system belonging to the real-time interaction type, and a second priority time period is assigned to the system belonging to the non-real-time interaction type, resulting in change sub-windows corresponding to each of the multiple system types, wherein the second priority time period covers the first priority time period.

12. A business change orchestration device, characterized in that, The device includes: The first determining module is configured to, in response to receiving a change request, determine, based on the change request's indication of the change-to-be-changed service information, a time window for performing the service change and associated system information, wherein the time window information includes change sub-windows corresponding to multiple system types, and the associated system information includes the system type, current change information, and resource information corresponding to each of the multiple associated systems; and The second determining module is used to determine the change orchestration result corresponding to the service to be changed based on the change sub-windows corresponding to each of the multiple system types, the current change information and resource information corresponding to each of the multiple associated systems.

13. An electronic device, comprising: One or more processors; Memory, used to store one or more computer programs. The characteristic feature is that the one or more processors execute the one or more computer programs to implement the steps of the method according to any one of claims 1 to 11.

14. A computer-readable storage medium having a computer program or instructions stored thereon, characterized in that, When the computer program or instructions are executed by a processor, they implement the steps of the method according to any one of claims 1 to 11.

15. A computer program product, comprising a computer program or instructions, characterized in that, When the computer program or instructions are executed by a processor, they implement the steps of the method according to any one of claims 1 to 11.

Images