A cloud integration enterprise service processing method and system

Abstract

The application relates to the technical field of enterprise service processing and automatic deployment, in particular to a cloud integrated enterprise service processing method and system. The method comprises the following steps: obtaining a customer identifier of a target customer associated with an automatic deployment process, the customer identifier being associated with a preset business management entity; obtaining a preset business state marker used for indicating whether the target customer is in a business sensitive period according to the customer identifier; when the business state marker indicates that the target customer is in the business sensitive period, stopping the execution of the automatic deployment process; and transferring a deployment decision right related to the automatic deployment process to the corresponding business management entity. The method has the advantages that the automatic deployment can be dynamically adjusted, and the interference on the business activities of the customer is reduced.

Description

Technical Field

[0001] This application relates to the technical field of enterprise service processing and automated deployment, and more specifically, to a cloud-integrated enterprise service processing method and system. Background Technology

[0002] Existing enterprise software services typically rely on automated deployment processes to improve efficiency and responsiveness. However, in complex cloud-integrated service architectures, automated deployment systems often operate independently of business management systems (such as customer relationship management systems), lacking awareness of the customer's current business status. For example, when a customer is in the midst of important business negotiations or a commercially sensitive period, the automated deployment system may still execute software updates or patch deployments according to preset procedures. This purely technology-driven automation fails to consider the customer's business sensitivities and may trigger technical notifications or service changes at inappropriate times, thereby interfering with or even damaging ongoing business activities and negatively impacting customer relationships and business interests. Existing technologies fail to provide an effective method for automated deployment processes to perceive and respond to the customer's commercially sensitive state, resulting in a disconnect between technical execution and business needs.

[0003] To address the aforementioned issues, existing technologies urgently need improvement. Summary of the Invention

[0004] To address the shortcomings of existing technologies, this application provides a cloud-integrated enterprise service processing method and system, which has the advantages of dynamically adjusting automated deployment and reducing interference with customers' business activities.

[0005] This application provides a cloud-integrated enterprise service processing method, the method including:

[0006] Obtain the customer identifier of the target customer associated with the automated deployment process; the customer identifier is associated with a pre-defined business management entity.

[0007] Based on the customer identifier, obtain a preset business status marker that indicates whether the target customer is in a business-sensitive period;

[0008] When a business status flag indicates that the target customer is in a business-sensitive period, the execution of the automated deployment process is suspended.

[0009] Delegate deployment decision-making authority related to automated deployment processes to the corresponding business management entities.

[0010] The above solutions can help us understand the client's business sensitivities, avoid inappropriate automation deployments, and reduce interference with the client's business activities.

[0011] To further address the issue, this application also proposes transferring deployment decision-making authority related to automated deployment processes to the corresponding business management entities, including:

[0012] When software components related to automated deployment processes are shared by multiple business entities, all business entities sharing the software components are identified based on the customer identifier.

[0013] Send deployment decision requests, which characterize the execution of the automated deployment process, to all business entities to obtain decision input from each business entity;

[0014] Based on the preset weights associated with each business entity, the decision inputs are processed to generate a set of decision results;

[0015] When the aggregate decision results meet the preset conflict conditions, the aggregate decision results and the decision inputs of each business entity are submitted to the business management entity to complete the transfer of deployment decision-making authority.

[0016] The above solution provides a more refined decision-making power transfer mechanism, takes into account the situation where multiple business entities share software components, and improves the rationality and coordination of decision-making through collective decision-making and conflict resolution.

[0017] To improve the solution, this application also proposes processing the decision inputs according to preset weights associated with each business entity to generate aggregate decision results, including:

[0018] Obtain the details of the changes to the software components related to the automated deployment process;

[0019] Based on the content of this change, determine the level of business impact of this change on each business entity;

[0020] Based on the business status markers and business impact levels of each business entity, the weighted decision weights of each business entity are calculated as preset weights.

[0021] The decision inputs are aggregated according to preset weights to generate a set of decision results.

[0022] The above solution provides a method for calculating weighted decision weights based on the content of the change, the business status, and the level of business impact, making the decision weights more objective and in line with actual business needs.

[0023] To improve the solution, this application also proposes determining the business impact level of each business entity on the changes, including:

[0024] Based on the function call information of the software components involved in this change, identify the dependencies of each business entity in the process of using the software components;

[0025] Based on the preset importance of dependencies, a corresponding business impact level is generated.

[0026] The above approach provides a specific method for determining the level of business impact, and improves the accuracy of impact assessment based on function call information and dependencies.

[0027] To improve the solution, this application also proposes that, after processing the decision inputs according to preset weights associated with each business entity and generating a set of decision results, the solution further includes:

[0028] When the aggregate decision result does not meet the conflict condition, and the aggregate decision result indicates that the automated deployment process should continue to be executed, the automated deployment process is triggered to resume based on the aggregate decision result;

[0029] Generate status record information that includes process identifiers for automated deployment processes, customer identifiers, and execution status indicators of the set decision results;

[0030] The status log information is associated with the operation logs related to the automated deployment process and stored together.

[0031] The above solution provides a mechanism for process recovery and status recording in non-conflict situations, improves the entire decision-making process, and facilitates traceability and management.

[0032] To improve the solution, this application also proposes that the method further includes:

[0033] For each business entity, obtain historical decision-making information related to that business entity;

[0034] Based on historical decision-making information, calculate historical decision-making impact indicators that characterize the historical business demand satisfaction of business entities;

[0035] By combining historical decision impact indicators, business status markers, and business impact levels, the weighted decision weights of the corresponding business entities are updated.

[0036] The above scheme introduces historical decision-making information to dynamically adjust the weighted decision-making weights, enabling the decision-making process to learn and adapt to the historical needs and preferences of business entities, thereby improving the intelligence and satisfaction of decision-making.

[0037] To improve the solution, this application also proposes to calculate historical decision impact indicators, based on historical decision information, representing the historical business demand fulfillment status of business entities, including:

[0038] For each historical deployment event recorded in the historical decision-making information, determine the historical business impact level associated with the business entity and used to characterize the business value of the historical deployment event;

[0039] Based on the historical business impact level and the corresponding historical deployment event results, a historical event impact score is generated for the historical deployment event.

[0040] The historical event impact scores of all historical deployment events are accumulated to generate historical decision impact indicators.

[0041] The above scheme provides a specific method for calculating the impact indicators of historical decisions. By evaluating the business value and results of historical deployment events, it quantifies the impact of historical decisions on the fulfillment of business needs.

[0042] To improve the solution, this application also proposes to accumulate the historical event impact scores of all historical deployment events to generate historical decision impact indicators, including:

[0043] Obtain the occurrence time of historical deployment events, and determine the preset time impact weight value to represent the time impact based on the occurrence time;

[0044] For each historical deployment event, a weighted historical event impact score is generated based on the corresponding historical event impact score and the time impact weight value.

[0045] The weighted scores of all historical events are accumulated to form the final historical decision-making impact index.

[0046] The above scheme introduces a time-based weighting into the calculation of historical impact indicators, making recent events more impactful and better reflecting current business needs and trends.

[0047] To improve the solution, this application also proposes obtaining the occurrence time of historical deployment events and determining a preset time impact weight value representing the time impact based on the occurrence time, including:

[0048] For historical deployment events, obtain the corresponding occurrence time, the types of software components involved, and the characteristics of the associated business entities;

[0049] The time impact weight value is calculated according to the occurrence time, software component type, and business entity characteristics, following preset time calculation rules.

[0050] The above scheme provides specific rules for calculating the weight of time impact, taking into account the occurrence time, software component type, and business entity characteristics, making the calculation of time weight more refined and reasonable.

[0051] To improve the solution, this application also proposes a cloud-integrated enterprise service processing system, the key technical points of which are:

[0052] include:

[0053] The data acquisition unit is used to obtain the customer identifier of the target customer associated with the automated deployment process and associate it with a pre-defined business management entity;

[0054] The status tag acquisition unit is used to acquire a business status tag that indicates whether the target customer is in a business-sensitive period, based on the customer identifier.

[0055] The control unit is used to abort the automated deployment process when a business status flag indicates that the target customer is in a business-sensitive period.

[0056] The control unit is also used to transfer deployment decision-making authority related to automated deployment processes to the corresponding business management entities.

[0057] The above scheme provides a system for implementing the above method, which is easy to implement and deploy through modular unit design.

[0058] In summary, the cloud-integrated enterprise service processing method and system provided in this application effectively solves the problem that the automated deployment process cannot perceive and flexibly handle the client's business-sensitive state by sensing the client's business-sensitive state and suspending automated deployment and transferring decision-making power during sensitive periods. It has the advantages of being able to sense the client's business-sensitive state, dynamically adjust automated deployment, and reduce interference with the client's business activities. Attached Figure Description

[0059] Figure 1 This is a flowchart illustrating a cloud-integrated enterprise service processing method provided in one embodiment of this application.

[0060] Figure 2 This is one of the flowcharts illustrating a cloud-integrated enterprise service processing method provided in another embodiment of this application.

[0061] Figure 3 This is a second flowchart illustrating a cloud-integrated enterprise service processing method according to another embodiment of this application.

[0062] Figure 4 This is a third flowchart illustrating a cloud-integrated enterprise service processing method provided in another embodiment of this application.

[0063] Figure 5 This is a fourth flowchart illustrating a cloud-integrated enterprise service processing method provided for another embodiment of this application.

[0064] Figure 6 This is the fifth flowchart illustrating a cloud-integrated enterprise service processing method provided in another embodiment of this application.

[0065] Figure 7This is a sixth flowchart illustrating a cloud-integrated enterprise service processing method provided for another embodiment of this application.

[0066] Figure 8 This is the seventh flowchart illustrating a cloud-integrated enterprise service processing method according to another embodiment of this application.

[0067] Figure 9 This is the eighth flowchart illustrating a cloud-integrated enterprise service processing method provided in another embodiment of this application.

[0068] Figure 10 A flowchart of a cloud-integrated enterprise service processing system provided for another embodiment of this application.

[0069] In the diagram: 1. Acquisition unit; 2. Status flag acquisition unit; 3. Control unit. Detailed Implementation

[0070] The technical solutions of this application will now be clearly and completely described with reference to the accompanying drawings. Obviously, the described embodiments are merely some embodiments of this application, and not all embodiments. The components of this application described and shown in the accompanying drawings can generally be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of this application provided in the accompanying drawings is not intended to limit the scope of the claimed application, but merely to illustrate selected embodiments of this application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.

[0071] It should be noted that similar reference numerals and letters in the following figures indicate similar items; therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures. Furthermore, in the description of this application, terms such as "first," "second," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0072] Traditional cloud-based integrated enterprise service systems suffer from a disconnect between technical operations and business objectives when executing automated deployment processes. Automated deployment systems operate independently based on technical processes, failing to perceive the customer's current business status. This is particularly problematic during critical business cycles (such as contract renewal negotiations), where purely technical deployment actions may conflict with business strategies, negatively impacting customer relationships and business progress. This information silo prevents the efficiency of technical processes from translating into overall business effectiveness.

[0073] To illustrate this issue more clearly, consider a cloud-based supply chain collaboration platform provider. Internally, it includes a Customer Relationship Management (CRM) system, a code version control system, and a Continuous Integration and Deployment (CI / CD) pipeline. When a specific customer reports a fault in a particular module, the development team completes the fix and merges the code in the CRM system, automatically triggering deployment via the CI / CD pipeline. At this point, the customer is in a specific phase of annual contract renewal negotiations with the provider. The customer success manager has recorded the customer's concerns about platform stability and the sensitive state of the negotiations in the CRM system. After completing testing, the CI / CD pipeline prepares to automatically deploy the patch to the customer's production environment and sends an automated notification according to a pre-set process. This automated notification bypasses the customer success manager and is sent directly to the customer's technical contact, who then passes this information to the business decision-making level in the negotiations. The customer's business decision-making level interprets this fault and the automated deployment as evidence of platform instability, interrupts negotiations, and demands a halt to all renewal discussions. In this scenario, the automated deployment process failed to recognize the customer's business sensitivity recorded in the CRM system, causing the technical fix to impact specific business activities.

[0074] Reference Figure 1 In response, this application proposes a cloud-integrated enterprise service processing method, including:

[0075] S1000: Obtain the customer identifier of the target customer associated with the automated deployment process. The customer identifier is associated with a pre-defined business management entity.

[0076] S2000: Based on the customer identifier, obtain a preset business status marker that indicates whether the target customer is in a business-sensitive period;

[0077] S3000: When a business status flag indicates that the target customer is in a business-sensitive period, the execution of the automated deployment process is suspended;

[0078] S4000: Transfer deployment decision-making authority related to automated deployment processes to the corresponding business management entity.

[0079] In this embodiment, the customer identifier refers to a tag used to uniquely identify the target customer, which can be implemented using the customer's unique ID in the system, contract number, or company name, etc. The business management entity refers to the system of the business department or personnel responsible for the target customer.

[0080] Among them, business status markers refer to indicators used to characterize the current business stage or status of a target customer, which can be implemented using Boolean values, enumeration values, or text descriptions. Business sensitive periods refer to business stages in which customers are highly sensitive to service stability, changes, or interruptions within a specific time period, which may include renewal negotiation periods, major project launch periods, and key business activity periods.

[0081] Suspending the execution of an automated deployment process refers to pausing or terminating the originally planned automated software deployment operation. This can be achieved by sending a pause command to the CI / CD pipeline, canceling the deployment task, or preventing the deployment script from running. Transferring deployment decision-making authority related to the automated deployment process to the corresponding business management entity means transferring the decision-making power regarding whether to continue the deployment, when to execute it, or how to execute it from the automated system to the system responsible for the business department or personnel of that customer. This can be achieved by sending decision requests, creating pending approval work orders, or triggering manual approval processes. Its main purpose is to ensure that deployment decisions, during commercially sensitive periods, comprehensively consider both technical feasibility and business impact.

[0082] The core innovation of this application lies in resolving the conflict between automated technology operations and customers' business-sensitive cycles in cloud-integrated enterprise services by associating automated deployment processes with customers' business status information and introducing business status-based process suspension and decision-making power transfer mechanisms. This achieves the effect of avoiding negative impacts of technological actions on key business processes.

[0083] This application's solution achieves synergy between technical execution and business needs by establishing a linkage between automated deployment processes and customer business status. Specifically, when an automated deployment process is triggered and associated with a target customer, the system first obtains the customer's identifier. Based on this identifier, the system can further obtain a pre-defined business status marker indicating whether the customer is in a business-sensitive period. Because of this business status marker, the system can make a judgment before automated deployment execution. If the judgment indicates that the customer is in a business-sensitive period, the system will immediately suspend the execution of the current automated deployment process. This effectively prevents technical changes that might disrupt the customer during sensitive periods. Subsequently, to ensure that necessary deployments (such as emergency fixes) are carried out in a way that minimizes business impact, the system transfers the deployment decision-making authority related to the automated deployment process to a pre-defined business management entity associated with the customer identifier. Through this series of steps, this application's solution ensures that during a customer's business-sensitive period, technical deployment is no longer an isolated automated behavior, but is subject to business-level review and control, thereby avoiding conflicts between technical operations and business objectives.

[0084] In some preferred embodiments, this application is implemented as follows: When the CI / CD pipeline completes software building and testing and is ready to deploy a patch to the customer's production environment, the pipeline triggers a processing request. This request contains the customer identifier associated with this deployment, such as the customer's unique ID in the CRM system. Upon receiving the request, the system queries the CRM system or other business management systems based on the customer ID to obtain information about the business management entity associated with that customer ID, such as the identifier of the customer success manager or sales team responsible for that customer. Simultaneously, the system also queries the customer's preset business status flag in the CRM system. Assuming the CRM system has a field used to mark whether the customer is in a "renewal negotiation period" or a "major event period," the value of this field is the business status flag. The system checks the business status flag; if the flag indicates that the customer is currently in a business-sensitive period, such as marked as "renewal negotiation period," the system sends a stop command to the CI / CD pipeline, pausing the current automated deployment task. The system then generates a decision request containing detailed information about the deployment (such as the scope of repairs and the extent of impact) and sends it to the previously acquired business management entity (e.g., the customer success manager) via an internal messaging system or a ticketing system. Upon receiving the request, the customer success manager can decide whether to approve the deployment, postpone it, or negotiate a deployment time with the customer based on the current business situation, thereby shifting deployment decision-making power from the automated system to business personnel.

[0085] Reference Figure 2 Furthermore, in another embodiment of this application, step S4000 includes:

[0086] S4100: When software components related to an automated deployment process are shared by multiple business entities, identify all business entities sharing the software components based on the customer identifier;

[0087] S4200: Sends deployment decision requests to all business entities to characterize the execution of automated deployment processes in order to obtain decision inputs from each business entity;

[0088] S4300: Process the decision inputs according to the preset weights associated with each business entity and generate a set of decision results;

[0089] S4400: When the aggregate decision result meets the preset conflict conditions, the aggregate decision result and the decision input of each business entity are submitted to the business management entity to complete the transfer of deployment decision-making authority.

[0090] In this embodiment, a business entity refers to a system of an organizational unit or department that operates independently or has independent decision-making power within the enterprise service system. It can be implemented by different departments within the customer or different teams within the service provider. Its purpose is to distinguish and identify different stakeholders who have the right to use or manage shared software components.

[0091] A deployment decision request is a communication or notification used to solicit opinions from business entities on whether to continue the automated deployment process. It can be sent in the form of email, system notification, to-do list, or API call, and contains relevant information about the deployment. Decision input refers to the response of each business entity to the deployment decision request, which can be an explicit "agree to deployment", "reject deployment", or conditional opinion.

[0092] Preset weights refer to the numerical values ​​or priorities assigned to each business entity according to specific rules or standards. These weights measure the importance or influence of the entity in the current deployment decision. They can be determined based on the business entity's hierarchy within the enterprise, its dependence on shared software components, its historical performance, or the impact of the current change on its business. This reflects the differentiated importance of different business entities during comprehensive decision-making. The aggregate decision result refers to the overall decision conclusion reached after comprehensively processing the decision inputs from each business entity and considering the preset weights. This can be "continue deployment," "abort deployment," or "human intervention required." Conflict conditions refer to the criteria used to determine whether the aggregate decision result reflects disagreements or differing opinions among the business entities. This could be when a certain percentage of the received decision inputs contain "reject deployment" opinions, or when the weighted aggregate result does not reach a preset agreement threshold. The purpose is to identify situations requiring higher-level intervention for a final decision.

[0093] In this embodiment, after identifying that the customer is in a business-sensitive period and suspending the automated deployment process, the system further determines whether the deployment involves software components shared by multiple business entities. If so, the system identifies all business entities using the shared software component based on the customer's identifier. Subsequently, the system proactively sends deployment decision requests to these business entities, detailing the content and potential impact of the deployment to obtain their respective decision inputs. These decision inputs reflect the attitudes and opinions of each business entity towards the deployment. To fairly and effectively integrate these opinions, the system processes the collected decision inputs according to preset weights. These preset weights reflect the importance of each business entity in the overall business or its sensitivity to the change, ensuring that the opinions of business entities with higher weights are given more consideration. After weighted processing, the system generates a aggregate decision result, representing a preliminary conclusion after integrating the opinions of all parties. However, considering that different business entities may have different interests and positions, if this aggregate decision result meets preset conflict conditions, such as significant differences of opinion or a certain degree of opposition, the system will not directly execute the result. Instead, it will submit the aggregate decision result along with all the original decision inputs to a preset business management entity. In this way, the business management entity can fully understand the opinions and conflicts of all parties, make the final weighing and adjudication, and thus complete the reasonable transfer of deployment decision-making power. This ensures that, in cases involving shared resources among multiple parties and when customers are in a sensitive period, the deployment decision takes into account both technology and the business needs and risk aversion of each business entity, avoiding the negative impact that a single decision may bring.

[0094] The following is a concrete example: Suppose a cloud service platform provides services to a client with multiple business departments, such as e-commerce, finance, and risk control. These departments share a common software component on the platform, such as a payment processing module. When the client is in a business-sensitive period and needs to automate the deployment and update of the payment processing module, the system first identifies the e-commerce, finance, and risk control departments as the shared business entities sharing the module based on the client's identifier. Next, the system sends a deployment decision request to designated contacts in these three business departments. The request includes the content of the deployment update, a suggested deployment time window, and requests their decision input. Suppose the e-commerce department replies "reject"; the finance department replies "agree"; and the risk control department replies "agree," requesting deployment during off-peak hours. The system processes these decision inputs according to preset weights; for example, the weight for the e-commerce department is set to 5, the finance department to 3, and the risk control department to 2. The processing rules could be weighted summation (+1 for "agree" and -1 for "reject"), or simply a weighted average of the agree / reject ratio. If the weighted aggregate decision result meets the preset conflict conditions, the system will submit this aggregate decision result, along with the original decision inputs from the e-commerce department, finance department, and risk control department, to the preset business management entity, such as the system of the client's IT director or operations manager. The business management entity will then conduct the final review and decision, thereby completing the transfer of deployment decision-making authority.

[0095] Reference Figure 3 Furthermore, in another embodiment of this application, step S4300 includes:

[0096] S4310: Obtain the details of the changes to software components related to the automated deployment process;

[0097] S4320: Based on the content of this change, determine the level of business impact of this change on each business entity;

[0098] S4330: Combine the business status markers and business impact levels of each business entity to calculate the weighted decision weight of each business entity as a preset weight;

[0099] S4340: Summarize the decision inputs according to preset weights and generate a set decision result.

[0100] In this embodiment, the "change content" refers to the specific changes made to the software components related to the automated deployment process during this deployment. These changes may include code modifications, configuration file updates, database structure adjustments, or data migrations. The purpose is to clarify the technical essence of this deployment and provide foundational information for subsequent assessment of its potential impact on various business entities. The "business impact level" is a quantitative or graded representation of the potential impact of the change content on the normal business operations or key business indicators of each business entity. This can be determined by analyzing the correlation between the technical details of the change content and the functions of the business entities. Its purpose is to assess the importance and potential risks of this technical change at the business level. The "weighted decision weight" refers to the numerical value assigned to each business entity during the deployment decision-making process, after comprehensively considering the business status marker and the business impact level, to influence the collective decision-making result. This weight value can be calculated using a preset calculation model or rule, taking the business status marker and business impact level as input. Its purpose is to dynamically and more accurately reflect the current business importance and the degree of impact of this change on the voice or influence of each business entity in the collective decision-making process.

[0101] This application's solution obtains the details of changes to software components related to the automated deployment process and determines the business impact level of each business entity on these changes. This allows for the assessment of the differentiated impact on different business entities for a specific deployment activity. Furthermore, by combining the business status markers and business impact levels of each business entity, a weighted decision weight is calculated for each business entity. This weight, based on the actual impact of the change and the current state of the business entities, more accurately reflects the importance and risk exposure of each business entity in this specific decision. Finally, the decision inputs are aggregated according to the preset weights to generate a collective decision result. By using these dynamically adjusted weights, the collective decision result can more reasonably balance the interests and risks of each business entity, avoiding decision biases caused by using fixed weights or neglecting the characteristics of the change. This method of dynamically adjusting weights based on the content of the change and the business status enables the mechanism of summarizing decision inputs based on preset weights to operate more flexibly and accurately. This allows for a better transfer of deployment decision-making power to business management entities and joint decision-making by multiple business entities within a limited business-sensitive period. It effectively solves the problem of how to reasonably determine weights to avoid distortion of decision results and improves the decision quality and reliability of automated deployment processes in complex business scenarios.

[0102] In some preferred embodiments, a specific example is given below. Assume an automated deployment process is preparing to deploy an emergency patch for an MRP module shared by the production planning, purchasing, and sales departments. First, the content of the change is obtained; for example, this change fixes a code defect in the MRP module that causes data overflow when processing specific order data. Next, based on the change content, the business impact level of each business entity on this change is determined. Analysis reveals that the defect directly affects the MRP calculation function of the production planning department, therefore its business impact level for the production planning department is determined to be "high"; the defect indirectly affects the purchasing department's generation of purchase orders based on MRP results, therefore its business impact level is determined to be "medium"; the defect has a relatively small impact on the sales department, therefore its business impact level is determined to be "low". Simultaneously, the business status markers of each business entity are obtained. Assume the production planning department is currently in a critical production cycle, with its business status marker indicating "urgent," while the purchasing and sales departments' business status markers indicate "normal". Then, combining the business status markers and business impact levels of each business entity, a weighted decision weight for each business entity is calculated using a preset weight. For example, based on preset rules, a higher weighting coefficient can be assigned to "high" impact levels, and an additional weighting can be given to "urgent" states. This results in the production planning department having the highest weighted decision-making weight, followed by the purchasing department, and then the sales department. Finally, the decision inputs of each business entity are aggregated based on the calculated preset weights. For example, if the production planning department enters "reject" due to concerns about impacting current production, while the purchasing and sales departments enter "agree," the system will weight and aggregate these inputs according to the calculated weighted decision-making weights, such as through weighted voting, to ultimately generate a collective decision result.

[0103] Reference Figure 4 Furthermore, in another embodiment of this application, step S4320 includes:

[0104] S4321: Based on the function call information of the software components involved in this change, identify the dependencies of each business entity in the process of using the software components;

[0105] S4322: Generate the corresponding business impact level based on the preset importance of the dependency relationship.

[0106] In this embodiment, function call information refers to records or descriptions of mutual calls to functions or services between software components. Specifically, it can be function call relationships at the code level, interface call logs between modules, API request records between services, or dependency pointers reflected in configuration information. Its purpose is to reveal the actual interaction methods of software components at runtime or during design. Dependency relationship refers to the function call or data interaction relationship of a business entity to a specific software component. Specifically, it can be a business process step calling a service provided by a certain software component, or business data being stored in a database managed by a certain software component. Its purpose is to clarify which business entities used the software components involved in this change to what extent. Preset importance refers to the indicators that are pre-set to measure the criticality of different types of dependency relationships or different call patterns. Specifically, it can be divided into high, medium, and low levels based on factors such as the frequency of dependency, whether the dependent function is core, and whether the dependency is a single point of dependency. Its purpose is to quantify the potential impact of different dependency relationships on business continuity or functional integrity. Business impact level refers to the classification or scoring of the degree of negative impact that this software component change may have on a specific business entity. Specifically, it can be defined as multiple levels such as critical, major, minor, or no impact. Its purpose is to intuitively represent the magnitude of the change risk and provide a basis for subsequent decision-making.

[0107] This application's solution analyzes the function call information of software components associated with the changed content to identify which business entities actually call or use these components, thus clarifying the technical dependencies between business entities and the changed components. It is precisely this dependency identification based on function call information that allows this application to penetrate complex system architectures and accurately locate affected business entities. Based on this, this application further transforms the identified dependencies into specific business impact levels according to pre-defined dependency importance rules. The reason for generating corresponding business impact levels is that different dependency methods and degrees have different levels of importance to the business; by pre-setting importance and mapping, the potential impact of the change on the business can be objectively assessed. It is precisely this method combining technical dependency analysis and importance assessment that allows this application to determine the business impact level of each business entity on the changed content more accurately than relying solely on business status or simple judgments. This provides a more refined and reliable input for subsequent calculation of weighted decision weights, enabling the aggregate decision results to more realistically reflect the interests and risks of all parties, and improving the scientific nature and effectiveness of deployment decisions.

[0108] In some preferred embodiments, specifically, when it is necessary to determine the business impact level of a certain business entity (e.g., an inventory management system) on the content of this change (e.g., an update to a shared database access component), the system can first analyze the function call information of the database access component involved in this change. This can include checking the codebase of the inventory management system to find its call records for specific functions or interfaces provided by the database access component; or analyzing runtime logs to track the database operation requests issued by the inventory management system to the component. Through this analysis, it can be identified that the inventory management system has a dependency on the database access component, for example, it frequently calls the component's "write inventory record" and "query inventory quantity" functions. Next, according to preset dependency importance rules, the importance of these dependencies can be evaluated. For example, the "write inventory record" function may be preset as a high-importance dependency because it directly affects the accuracy of core business data; while the "query inventory quantity" function may be preset as a medium-importance dependency. Based on these identified dependencies and their preset importance, the system can generate corresponding business impact levels. For example, due to the existence of the high-importance "write inventory record" dependency, the system can determine the business impact level of the inventory management system on this change as "critical" or "major".

[0109] Reference Figure 5 Furthermore, in another embodiment of this application, after step S4300, the method further includes:

[0110] S4500: When the aggregate decision result does not meet the conflict condition, and the aggregate decision result indicates that the automated deployment process should continue to be executed, the automated deployment process is triggered to resume based on the aggregate decision result;

[0111] S4600: Generates status record information that includes process identifiers, customer identifiers, and execution status indications of the set decision results for the automated deployment process;

[0112] S4700: Associates and stores status log information with operation logs related to automated deployment processes.

[0113] In this embodiment, the recovery of the automated deployment process refers to the process of returning the automated deployment process from the aborted state to the executable state and continuing execution from the aborted point or a specified point. This can be achieved by calling the recovery interface of the process engine or sending a recovery command to the process. The process identifier is a mark used to uniquely identify an automated deployment process, which can be represented by a globally unique identifier (GUID), a sequence number, or a combination of codes. The execution status refers to the current state of the automated deployment process, which can be represented by an enumeration value (such as "continue execution", "aborted", "failed", "completed", etc.) or a status code. Record information refers to structured information containing data such as process identifiers, customer identifiers, and execution status, which can be represented in the form of data objects, record entries, or message bodies; operation logs refer to a collection of records that record events, operations, errors, timestamps, and other information that occur during the execution of automated deployment processes, which can be stored in the form of text files, database records, or log streams; associated storage refers to establishing a logical or physical link between status record information and the corresponding operation logs and saving them, which can be achieved by referencing log identifiers in status record information, referencing status record identifiers in logs, or storing both in the same database table.

[0114] This application's solution adds judgment and subsequent processing to the generated set decision result. Specifically, when the set decision result indicates that the preset conflict conditions are not met, and the result clearly indicates that the automated deployment process can continue, the system will trigger the resumption of the process based on this decision result. This decision-based triggering mechanism ensures that the process resumption is a business-considered action, rather than a simple continuation of automation. Simultaneously, to ensure the traceability of the entire process, the system generates a status record containing key identifiers of this automated deployment process (process identifier, customer identifier) ​​and the execution status indicated by the decision (i.e., "continue execution"). This status record is a structured record of the decision and its direct results. To closely link this decision result with the actual process execution, this status record is associated with the operation logs related to this automated deployment process. It is precisely because of this weighted decision-based process resumption triggering mechanism and the status record mechanism associated with detailed operation logs that, after the automated deployment process is suspended due to a sensitive period and undergoes business decision-making, execution can be smoothly and accurately resumed based on the decision result, and all key aspects of the decision and execution are effectively and traceably recorded. This contrasts sharply with the basic approach, which only makes decisions but lacks subsequent automated recovery control and status logging, significantly improving the reliability and transparency of the entire cloud-integrated enterprise service processing method.

[0115] In some preferred embodiments, specifically, assuming the automated deployment process is suspended due to the customer being in a business-sensitive period, a process of soliciting decision inputs from relevant business entities is triggered. After collecting and weighting the decision inputs from each business entity, a collective decision result is generated. If the collective decision result is "continue execution," and this result does not meet preset conflict conditions (e.g., no business entity explicitly objects, and the weighted score is higher than the threshold for continuing execution), the system will send a recovery command to the control module of the automated deployment process based on this "continue execution" collective decision result, triggering the process to resume execution from the suspension point. Simultaneously, the system generates a status record containing a unique identifier for this automated deployment process (e.g., a system-generated serial number), the target customer's customer number, and the execution status "continue execution" indicated by the collective decision result. This status record is written to a dedicated status database table, and the record includes a link or index to the operation log of this automated deployment process stored in the log system. Conversely, the identifier of this status record is also recorded in the operation log generated by the automated deployment process, thereby establishing a connection between the two data sources.

[0116] Reference Figure 6 Furthermore, in another embodiment of this application, the method further includes:

[0117] S5000: For each business entity, obtain historical decision information related to that business entity;

[0118] S6000: Based on historical decision-making information, calculate historical decision-making impact indicators that characterize the historical business demand satisfaction of business entities;

[0119] S7000: Combines historical decision impact indicators, business status markers, and business impact levels to update the weighted decision weights of the corresponding business entities.

[0120] In this embodiment, historical decision information refers to records related to the decisions made by a specific business entity in the past regarding automated deployment processes. These records can be stored and managed using structured databases, log files, or dedicated historical record modules. Their purpose is to provide a data foundation for subsequent evaluation of the business entity's needs being met during the historical decision-making process. The historical decision impact index is a quantitative value used to characterize the degree to which the business entity's business needs were met or the impact it suffered during a series of historical decision-making events. It can be calculated based on historical decision information by analyzing factors such as the consistency between the business entity's decision inputs and final results, and the actual impact of historical deployment events on the business entity.

[0121] This application's solution further optimizes the decision-making mechanism in the automated deployment process based on existing technologies. Specifically, when making deployment decisions involving multiple business entities sharing software components, in addition to considering the current business status markers of the business entities and the business impact level brought about by the change, this solution also proactively acquires and analyzes historical decision information related to each business entity. Based on this historical information, the system calculates a historical decision impact index, which quantitatively reflects the degree to which the business entity's business needs were met in similar decisions it participated in in the past. Subsequently, this historical decision impact index is combined with the current business status markers and business impact level to update the weighted decision weights of the corresponding business entities. This means that a business entity's "encounter" in historical decisions (whether its needs were met) will affect its "voice" (weight) in the current decision. If the historical need satisfaction level is low, its weight may be increased, and vice versa. In this way, this solution can more comprehensively assess the importance and priority of each business entity in the current deployment decision, avoiding the one-sidedness that may result from judging solely based on the current status. This weighting adjustment mechanism, which takes historical factors into account, ensures that the final aggregate decision, generated based on weighted decision weights, better balances the long-term and short-term interests of various business entities, improving the fairness and accuracy of the decision-making process. These weighted decision weights, optimized with historical information, are then used to process the decision inputs of each business entity, generate the aggregate decision result, and trigger subsequent processes based on this result. This ensures that the automated deployment process can make decisions that better align with the overall interests in complex business scenarios.

[0122] In some preferred embodiments, for example, suppose business entity A and business entity B share a software component, and a deployment change decision is needed for this component. The system first retrieves historical decision information related to business entities A and B, such as querying deployment decision records related to the software component that they participated in over the past year. These records may include the type of each deployment, the decision inputs of A and B, the final decision results, and the actual business impact after deployment. Based on this historical decision information, the system calculates a historical decision impact index characterizing the historical business requirement satisfaction of the business entities. For example, a score can be calculated based on the consistency between the business entity's decision inputs and final results in historical decisions, and the actual impact (positive or negative) of historical deployment events on its business. This score accumulates to form the historical decision impact index. Suppose the calculated historical decision impact index for business entity A is negative (indicating low historical requirement satisfaction or significant negative impact), and the historical decision impact index for business entity B is positive (indicating high historical requirement satisfaction or significant positive impact). Subsequently, the system combines the business status markers of business entities A and B obtained during this deployment decision (e.g., A is in a non-sensitive period, B is in a sensitive period) and the business impact level of this change on them respectively (e.g., moderate impact on A, high impact on B), and introduces calculated historical decision impact indicators, all of which are used to update the weighted decision weights of business entities A and B. For example, a weight update rule can be designed so that the weight of business entities with negative historical decision impact indicators (such as A) is increased from the base weight, while the weight of business entities with positive historical decision impact indicators (such as B) is decreased from the base weight. The final updated weighted decision weights are obtained; for example, A's weight is slightly increased, and B's weight is slightly decreased. These updated weights will be used to subsequently aggregate the decision inputs of business entities A and B to generate a set decision result.

[0123] Reference Figure 7 Furthermore, in another embodiment of this application, step S6000 includes:

[0124] S6100: For each historical deployment event recorded in the historical decision information, determine the historical business impact level associated with the business entity and used to characterize the business value of the historical deployment event;

[0125] S6200: Generate historical event impact scores for historical deployment events based on historical business impact levels and corresponding historical deployment event results;

[0126] S6300: Accumulates the historical event impact scores of all historical deployment events to generate historical decision impact indicators.

[0127] In this embodiment, a historical deployment event refers to each specific software deployment, update, or configuration change operation recorded in historical decision information. Its purpose is to record the impact of each technical change on the business entity. The historical business impact level refers to the classification of the degree of impact of historical deployment events on the business entity's operations or value according to preset evaluation criteria. It can be characterized using a grading system (e.g., high, medium, low) or a scoring system, aiming to distinguish the business importance of different historical events to the business entity. The historical deployment event result refers to the state or effect after the actual execution of the historical deployment event. It can be characterized by states such as success, failure, partial success, or introduction of new problems, aiming to reflect the actual execution of the historical event. The historical event impact score is a numerical value calculated based on the historical business impact level and the historical deployment event result, quantifying the degree of impact of a single historical deployment event on the business entity. It can use positive or negative values ​​to represent positive or negative impacts, aiming to quantify the impact of historical events.

[0128] Cumulative processing refers to the process of summarizing and calculating the impact scores of multiple historical events. This can be achieved through simple summation, weighted summation, or averaging, with the aim of obtaining a comprehensive historical impact assessment.

[0129] This application's solution quantifies the impact of historical decisions on the fulfillment of business needs by conducting a refined analysis of the historical decision-making information of business entities. Specifically, for each historical deployment event recorded in the historical decision-making information, the degree of business value of the event to the business entity, i.e., the historical business impact level, is first determined. This level is determined considering the nature of the event itself and its close relationship with the business entity. Next, a historical event impact score is generated by combining the historical business impact level with the actual execution result of the historical deployment event. This score comprehensively reflects the actual impact of the historical event on the business entity; successful and high-impact events receive higher scores, while unsuccessful or low-impact events receive lower or negative scores. Finally, the historical event impact scores of all historical deployment events are accumulated to obtain a comprehensive historical decision impact index. This index comprehensively reflects the overall fulfillment of business needs by the business entity across all relevant past deployment events. It is precisely this step-by-step, refined quantification process that allows the calculated historical decision impact index to more accurately represent the true value of historical decisions, overcoming the shortcomings of simple accumulation. This historical decision impact indicator can then be combined with the current business status flag of the business entity and the business impact level of this change to dynamically adjust the weighted decision weight of the business entity in the collective decision-making process. This allows the final collective decision result to more fully consider the historical experience and actual needs of the business entity, improving the scientific nature and effectiveness of the decision.

[0130] In some preferred embodiments, this application is implemented as follows: Assume that for a certain business entity, there are three historical deployment events recorded in historical decision information. The first record shows that a deployment event was to fix a serious defect in a core function used by the business entity, and its historical business impact level was determined to be "high". The result of this event is recorded as "success". According to preset rules, for example, setting the score corresponding to "high" level to 3 and the score corresponding to "success" result to 1, the historical event impact score of this historical deployment event is 3*1=3. The second record shows that a deployment event was to optimize the interface of a non-core function used by the business entity, and its historical business impact level was determined to be "low". The result of this event is recorded as "success". According to preset rules, for example, setting the score corresponding to "low" level to 1 and the score corresponding to "success" result to 1, the historical event impact score of this historical deployment event is 1*1=1. The third record shows that a deployment event was to add a minor function, and its historical business impact level was determined to be "medium". The result of this event is recorded as "failure". According to preset rules, for example, setting the score for "Medium" level to 2 and the score for "Failure" to -1, the historical event impact score for this historical deployment event is 2 * -1 = -2. Finally, the historical event impact scores of all three historical deployment events are accumulated, for example, by simple summation, resulting in the historical decision impact index for this business entity being 3 + 1 + (-2) = 2. This value of 2 represents the overall business requirement satisfaction of this business entity in these historical deployment events.

[0131] Reference Figure 8 Furthermore, in another embodiment of this application, step S6300 includes:

[0132] S6310: Obtain the occurrence time of historical deployment events and determine the preset time impact weight value representing the time impact based on the occurrence time;

[0133] S6320: For each historical deployment event, generate a weighted historical event impact score based on the corresponding historical event impact score and time impact weight value;

[0134] S6330: Accumulate the weighted impact scores of all historical events to form the final historical decision impact index.

[0135] In this embodiment, the time-based impact weight value is a pre-set numerical value used to quantify the degree of attenuation of the impact of historical events on the present. It can be implemented using a time-difference-based attenuation function or a piecewise function. The weighted historical event impact score is the value obtained by multiplying the historical event impact score by the corresponding time-based impact weight value, used to reflect the influence of the historical event on the present after considering time attenuation.

[0136] This application's solution obtains the occurrence time of historical deployment events and determines a preset time impact weight value based on this time, reflecting the degree of attenuation of influence due to the time difference from the present. Then, for each historical deployment event, a weighted historical event impact score is generated based on the corresponding historical event impact score and the time impact weight value. This process effectively reduces the influence of earlier historical events and highlights the importance of recent events. Finally, all weighted historical event impact scores are accumulated to form the final historical decision impact index. In this way, the calculation of the historical decision impact index is more accurate, more precisely reflecting the current historical business needs of the business entity. Using this more accurate index to update the weighted decision weights of the business entity allows the final weighted decision weights to more reasonably balance the impact of historical performance, current status, and the current change, thus providing a more reliable basis for generating aggregate decision results and ultimately improving the accuracy and effectiveness of the entire automated deployment process's decision handover and processing.

[0137] In some preferred embodiments, the above scheme can be implemented as follows. Assume that it is necessary to calculate the historical decision impact index of a certain business entity, which has three historical deployment events. Event 1 occurred 365 days ago, with a historical event impact score of +10. Event 2 occurred 30 days ago, with a historical event impact score of -5. Event 3 occurred 7 days ago, with a historical event impact score of +8. The preset time impact weight value can be calculated based on the time difference, for example, using the function W = exp(-0.01 * Days), where Days is the number of days since the event occurred. According to this function, the time impact weight value of event 1 is approximately exp(-0.01 * 365) ≈ 0.026, and the weighted historical event impact score is 10 * 0.026 = 0.26. The time impact weight value of event 2 is approximately exp(-0.01 * 30) ≈ 0.74, and the weighted historical event impact score is -5 * 0.74 = -3.7. The time-related impact weight of Event 3 is approximately exp(-0.01*7)≈0.93, and the weighted historical event impact score is 8*0.93=7.44. The final historical decision impact index is the cumulative weighted historical event impact score: 0.26+(-3.7)+7.44=4.0. This value of 4.0 is a quantitative representation of the overall satisfaction of the historical business needs of this business entity after considering time decay.

[0138] Reference Figure 9 Furthermore, in another embodiment of this application, step S6310 includes:

[0139] S6311: For historical deployment events, obtain the corresponding occurrence time, the types of software components involved, and the characteristics of the associated business entities;

[0140] S6312: Calculate the time impact weight value according to the occurrence time, software component type, and business entity characteristics, following the preset time calculation rules.

[0141] In this embodiment, software component type refers to the classification of different modules or components that constitute the software system. For example, software can be divided into different types such as core business modules, auxiliary function modules, infrastructure components, and user interface components. These can be identified using predefined enumeration values, tags, or configuration information. Associated business entity characteristics refer to the attributes or importance markers of business departments, business lines, or customers related to the historical deployment event. For example, business entities can be divided into core business departments, non-core business departments, high-value customers, and ordinary customers. These can be obtained using the business entity's metadata, tags, or level information in the customer relationship management system. Preset time calculation rules refer to a set of rules used to comprehensively consider the occurrence time of the historical deployment event, the types of software components involved, and the associated business entity characteristics, and to calculate the time impact weight value based on a specific algorithm or model. These rules can be implemented using formulas based on time decay functions combined with type and characteristic correction factors, lookup tables, or machine learning models.

[0142] This application's solution, for each historical deployment event, goes beyond simply obtaining its occurrence time; it further acquires the types of software components involved and the characteristics of the associated business entities. This is because different types of software components and business entities with different characteristics may have varying sensitivities to deployment events and varying durations of impact. For example, a deployment event of a core business module, even if it occurred earlier, may still have a greater impact on current decisions than a recent event of a non-core module. The solution then calculates a time impact weight value based on these three dimensions of data, according to a pre-defined time calculation rule. This rule comprehensively weighs the time proximity, component importance, and business entity importance, thereby generating a weight value that more accurately reflects the current influence of historical events. This more accurate calculation of the time impact weight value provides a more reliable foundation for the cumulative calculation of subsequent historical decision impact indicators, enabling the final calculated historical decision impact indicators to more accurately represent the fulfillment of historical business needs by business entities. Updating the weighted decision weights of business entities based on more accurate historical decision impact indicators allows for more reasonable weight allocation that better reflects the actual historical performance and current importance of business entities, thereby optimizing the decision-making process in automated deployment.

[0143] In some preferred embodiments, specifically for a historical deployment event, such as a successful deployment of a core business module (software component type) serving a high-value customer (related business entity characteristics) six months ago, a preset time calculation rule can be set with a base time decay function, such as linear or exponential decay of weight over time. The rule can also include a correction factor: for the core business module, the correction factor can be set to 1.2; for the high-value customer, the correction factor can be set to 1.1. Then, the time impact weight value of this historical deployment event can be calculated as: base time decay function (six months ago) * 1.2 * 1.1. In this way, even if the event occurred earlier, because it involves a core component and a high-value customer, its time impact weight value will be higher than that of non-core component or ordinary customer events occurring at the same time, thus occupying a more important position in the accumulation of historical decision impact indicators.

[0144] Reference Figure 10 Furthermore, in another embodiment of this application, the cloud-integrated enterprise service processing system includes:

[0145] The data acquisition unit 1 is used to acquire the customer identifier of the target customer associated with the automated deployment process and associate it with a preset business management entity;

[0146] Status tag acquisition unit 2 is used to acquire a business status tag that indicates whether the target customer is in a business-sensitive period, based on the customer identifier.

[0147] Control unit 3 is used to abort the automated deployment process when a business status flag indicates that the target customer is in a business-sensitive period;

[0148] The control unit is also used to transfer deployment decision-making authority related to automated deployment processes to the corresponding business management entities.

[0149] The acquisition unit refers to the functional module used to receive or retrieve information, which can be implemented using software modules, hardware circuits, or a combination of both. The status flag acquisition unit refers to the functional module used to query or extract specific status flags, which can be implemented using database query interfaces, API call interfaces, or message queue listeners. The control unit refers to the functional module used to perform logical judgments and issue instructions based on input information, which can be implemented using processor-executed control programs, state machine logic circuits, or distributed coordination services.

[0150] The proposed solution obtains customer identifiers and associated business management entities through a data acquisition unit, which serves as the starting point of the process. A status flag acquisition unit queries business status flags based on the customer identifier to determine if the customer is in a business-sensitive period. The control unit receives the judgment result from the status flag acquisition unit. If the status flags indicate that the customer is in a business-sensitive period, the control unit immediately suspends the automated deployment process. Simultaneously, the control unit transfers deployment decision-making authority to the business management entity associated with the data acquisition unit. Through the collaborative work of these units, the entire system links the automated deployment process with the customer's business status, allowing for intervention and human decision-making at critical moments, thereby preventing automated operations from negatively impacting sensitive business operations such as business negotiations. The system, as the carrier of the method, implements the method's logic, ensuring that deployment decisions can be controlled by business personnel during business-sensitive periods, improving the accuracy of decisions and the controllability of business impact.

[0151] In some preferred embodiments, the acquisition unit can be a microservice deployed on a cloud server. It receives requests triggered by automated deployment processes via an API, and these requests include customer identifiers. Internally, this microservice maintains a mapping between customer identifiers and business management entities, such as the ID of a customer success manager or team ID. The status tag acquisition unit can be another microservice. It receives the customer identifier from the acquisition unit and queries the customer's business status tag by calling the CRM (Customer Relationship Management System) API. For example, it checks if a specific sensitive period tag or status field exists in the CRM. The control unit can be a standalone process coordinator or a logic module integrated into the acquisition unit or status tag acquisition unit. It receives the status tag returned by the status tag acquisition unit. When the status tag indicates a sensitive period, the control unit sends a stop instruction to the automated deployment pipeline and sends a notification or task to the associated business management entity via its ID. For example, it creates a pending deployment approval task in an internal collaboration platform and attaches relevant deployment information, such as changes and affected customers, to the task, thereby transferring decision-making authority.

[0152] The above description is merely an embodiment of this application and is not intended to limit the scope of protection of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of protection of this application.

Claims

1. A cloud-integrated enterprise service processing method, characterized in that, The method comprises: obtaining a customer identifier of a target customer associated with an automated deployment process, the customer identifier being associated with a preset business management entity; obtaining a preset business state marker for indicating whether the target customer is in a business sensitive period according to the customer identifier; when the business state marker indicates that the target customer is in the business sensitive period, suspending execution of the automated deployment process; transferring deployment decision-making power related to the automated deployment process to the corresponding business management entity; wherein the transferring of the deployment decision-making power related to the automated deployment process to the corresponding business management entity comprises: when a software component related to the automated deployment process is shared by multiple business entities, determining all the business entities sharing the software component according to the customer identifier; sending a deployment decision request for indicating execution of the automated deployment process to all the business entities to obtain decision input of each business entity; processing the decision input according to a preset weight associated with each business entity to generate a collective decision result; when the collective decision result meets a preset conflict condition, submitting the collective decision result and the decision input of each business entity to the business management entity to complete the transfer of the deployment decision-making power.

2. The cloud integrated enterprise service processing method of claim 1, wherein, The processing of the decision input according to the preset weight associated with each business entity to generate a collective decision result comprises: obtaining current change content of the software component related to the automated deployment process; determining a business impact level of each business entity on the current change content according to the current change content; combining the business state marker and the business impact level of each business entity to calculate a weighted decision weight of each business entity as the preset weight; according to the preset weight, the decision input is summarized to generate the collective decision result.

3. The cloud-integrated enterprise service processing method of claim 2, wherein, The determination of the business impact level of each business entity on the current change content according to the current change content comprises: according to function call information of the software component involved in the current change content, identifying a dependency relationship of each business entity in using the software component; according to a preset importance of the dependency relationship, generating a corresponding business impact level.

4. The cloud integrated enterprise service processing method of claim 3, wherein, After the processing of the decision input according to the preset weight associated with each business entity to generate a collective decision result, the method further comprises: when the collective decision result does not meet the conflict condition and the collective decision result indicates that the automated deployment process continues to execute, triggering recovery of the automated deployment process according to the collective decision result; generating state record information containing a process identifier of the automated deployment process, the customer identifier and an execution state indicated by the collective decision result; storing the state record information in association with operation logs related to the automated deployment process.

5. The cloud integrated enterprise service processing method of claim 4, wherein, The method further comprises: for each business entity, obtaining historical decision information related to the business entity; Based on the historical decision information, a historical decision impact index representing a historical business demand satisfaction situation of the business entity is calculated; In combination with the historical decision impact index, the business status marker and the business impact level, the weighted decision weight corresponding to the business entity is updated.

6. The cloud-integrated enterprise service processing method of claim 5, wherein, The calculation of the historical decision impact index representing the historical business demand satisfaction situation of the business entity based on the historical decision information comprises: For each historical deployment event recorded in the historical decision information, a historical business impact level associated with the business entity and representing the business value of the historical deployment event is determined; According to the historical business impact level and the corresponding historical deployment event result, a historical event impact score of the historical deployment event is generated; The historical event impact scores of all the historical deployment events are accumulated to generate the historical decision impact index.

7. The cloud-integrated enterprise service processing method of claim 6, wherein, The accumulation processing of the historical event impact scores of all the historical deployment events to generate the historical decision impact index comprises: An occurrence time of the historical deployment event is obtained, and a preset time impact weight value representing time impact is determined according to the occurrence time; For each historical deployment event, a weighted historical event impact score is generated according to the corresponding historical event impact score and the time impact weight value; All the weighted historical event impact scores are accumulated to form the final historical decision impact index.

8. The cloud integrated enterprise service processing method of claim 7, wherein, The obtaining of the occurrence time of the historical deployment event and the determination of the preset time impact weight value representing time impact according to the occurrence time comprises: For the historical deployment event, the corresponding occurrence time, the software component type involved and the business entity characteristics associated are obtained; According to the occurrence time, the software component type and the business entity characteristics, the time impact weight value is calculated according to a preset time calculation rule.

9. A cloud-integrated enterprise service processing system, comprising: Comprise: The acquisition unit is used for obtaining the customer identifier of the target customer associated with the automated deployment process, and associating a preset business management entity; The state marker acquisition unit is used for obtaining a business status marker representing whether the target customer is in a commercial sensitive period according to the customer identifier; The control unit is used for stopping the automated deployment process when the business status marker indicates that the target customer is in the commercial sensitive period; The control unit is also used for transferring the deployment decision right related to the automated deployment process to the corresponding business management entity; In the control unit, it is specifically used for determining all the business entities sharing the software component according to the customer identifier when the software component related to the automated deployment process is shared by multiple business entities, and is also used for sending a deployment decision request representing the execution of the automated deployment process to all the business entities to obtain the decision input of each business entity; The method further comprises: processing the decision inputs according to preset weights associated with the business entities to generate a collective decision result; and when the collective decision result satisfies a preset conflict condition, submitting the collective decision result and the decision inputs of the business entities to the business management entity to complete the handover of the deployment decision right.

Images