Cross-business system micro-service processing method and system oriented to business scene collaboration

Abstract

The invention provides a service scene collaboration-oriented cross-service system micro-service processing method and system, and the method comprises the steps: firstly obtaining an initial interaction data set with a service scene label of a cross-power service system in a preset time period, and then carrying out the scene feature analysis of the initial interaction data set; obtaining electric power business scene features and interactive behavior features corresponding to each interactive data unit, then calling a pre-constructed business collaborative analysis model to perform collaborative correlation analysis on the features, and generating a collaborative processing strategy containing micro-service calling priorities and data interactive format specifications; and determining a business process adjustment scheme of each business system in the target power business scene according to the cooperative processing strategy, and finally generating a cooperative execution instruction containing a micro-service calling instruction sequence based on the business process adjustment scheme, and sending the cooperative execution instruction to the target business system to trigger a cross-system cooperative processing operation. Therefore, barriers among power business systems can be effectively broken, the cooperative processing efficiency and flexibility are improved, and the reliability of power supply is guaranteed.

Description

Technical Field

[0001] The present invention relates to the technical field of power business microservice optimization, and in particular to a cross-business system microservice processing method and system for business scenario collaboration. Background Art

[0002] With the continuous advancement of smart grid construction and the deepening of power market reforms in the power industry, power business scenarios are becoming increasingly complex and diverse, covering every aspect of power generation, transmission, transformation, distribution, and consumption, and involving multiple different business systems, such as energy management systems (EMS), distribution management systems (DMS), power marketing systems, and equipment monitoring systems. These business systems are often developed by different vendors and utilize different technical architectures, data models, and communication protocols, leading to serious information silos between systems.

[0003] At present, the interaction between cross-business systems in the power business mainly relies on traditional interface docking methods, which lack a deep understanding of and dynamic adaptability to complex power business scenarios. When faced with dynamic business scenarios such as rapid changes in power load, large-scale access to new energy, and emergency repairs of power equipment failures, traditional methods find it difficult to flexibly adjust cross-system collaboration strategies based on real-time business needs. For example, when a sudden failure occurs in a regional power grid, multiple systems such as the energy management system, distribution management system, and equipment monitoring system need to collaborate quickly to locate the fault, isolate it, and restore power supply. However, existing technologies often have low collaboration efficiency, resulting in extended fault handling time, which affects the reliability and stability of power supply. Therefore, there is an urgent need for a microservice processing method that is suitable for power business scenarios and can achieve efficient collaborative processing across business systems. Summary of the Invention

[0004] In view of the above-mentioned problems, in combination with the first aspect of the present invention, an embodiment of the present invention provides a cross-business system microservice processing method for business scenario collaboration, the method comprising: Acquire an initial interaction data set across business systems, the initial interaction data set comprising interaction data units with business scenario tags generated by multiple business systems within a preset time period; Performing scenario feature analysis on the initial interaction data set to obtain business scenario features and interaction behavior features corresponding to each interaction data unit, wherein the business scenario features include scenario function description information and scenario process node association relationships, and the interaction behavior features include interaction operation types and operation timing sequences; Calling a pre-built business collaboration analysis model to perform collaborative correlation analysis on the business scenario characteristics and the interaction behavior characteristics, and generating a collaborative processing strategy for each interactive data unit, the collaborative processing strategy including microservice call priority and data interaction format specification; Determine a business process adjustment plan for each business system in a target business scenario based on the collaborative processing strategy, wherein the business process adjustment plan includes a process node execution sequence and data transmission rules between nodes; A collaborative execution instruction including a microservice call instruction sequence is generated based on the business process adjustment plan, and the collaborative execution instruction is sent to the target business system to trigger a cross-system collaborative processing operation.

[0005] On the other hand, an embodiment of the present invention also provides a cross-business system microservice processing system for business scenario collaboration, including a processor and a machine-readable storage medium, the machine-readable storage medium is connected to the processor, the machine-readable storage medium is used to store programs, instructions or codes, and the processor is used to execute the programs, instructions or codes in the machine-readable storage medium to implement the above method.

[0006] Based on the above aspects, by obtaining the initial interaction data set across business systems, the interaction data generated by the power business in various links such as power generation, transmission, transformation, distribution, and power consumption are comprehensively covered. The initial interaction data set is processed through scenario feature analysis, which can accurately extract the power business scenario characteristics and interaction behavior characteristics corresponding to each interaction data unit, deeply understand the functional requirements, process node associations, and interaction operation rules of the power business scenario, call the pre-built business collaboration analysis model to perform collaboration correlation analysis, and generate a collaboration processing strategy for each interaction data unit. This realizes intelligent decision-making for cross-system collaboration of power business, and can dynamically adjust the microservice call priority and data interaction format specifications according to different power business scenarios and interaction behaviors, thereby improving the pertinence and effectiveness of collaboration processing. According to the collaboration processing strategy, the business process adjustment plan of each business system in the target power business scenario is determined, and collaboration execution instructions are generated to trigger cross-system collaboration processing operations. This enables each power business system to work collaboratively according to the optimized processes and rules, effectively breaking down system barriers and significantly improving the efficiency, flexibility, and accuracy of cross-system collaboration processing, thereby better adapting to the dynamic changes of power business scenarios and ensuring the reliability and stability of power supply. BRIEF DESCRIPTION OF THE DRAWINGS

[0007] Figure 1 This is a schematic diagram of the execution flow of a cross-business system microservice processing method for business scenario collaboration provided by an embodiment of the present invention.

[0008] Figure 2This is a schematic diagram of exemplary hardware and software components of a cross-business system microservice processing system for business scenario collaboration provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0009] The present invention will be described in detail below with reference to the accompanying drawings. Figure 1 This is a flow chart of a cross-business system microservice processing method for business scenario collaboration provided by an embodiment of the present invention. The cross-business system microservice processing method for business scenario collaboration is introduced in detail below.

[0010] Step S110: Acquire an initial interaction data set across business systems, where the initial interaction data set includes interaction data units with business scenario tags generated by multiple business systems within a preset time period.

[0011] In the power business scenario, multiple different business systems work together, such as power generation, transmission, distribution, and power service systems. The preset time period can be set to a specific time period. During this time period, the various business systems continuously interact with each other, generating a large amount of data.

[0012] The power generation system is primarily responsible for electricity production. Its interactive data can include generator start-up and shutdown operations, power generation adjustments during different time periods, and maintenance records of power generation equipment. For example, when the power demand of the power grid changes, the power generation system needs to adjust the output power of the generator according to the dispatch instructions. These operations will generate corresponding interactive data.

[0013] The transmission system is responsible for delivering electricity generated by the power generation system to various distribution nodes. Its interactive data includes real-time monitoring of transmission line parameters such as current, voltage, and power, as well as alarm and handling records of transmission line faults. When a transmission line fault occurs, information such as the time, location, and type of fault is recorded, and the corresponding fault handling process is initiated.

[0014] The distribution system distributes electricity from the transmission system to various users. This interactive data includes the operating status of distribution transformers, the load on each distribution line, and user power outage and restoration records. For example, during peak hours, the distribution system must allocate power based on load conditions in each area to ensure a stable power supply. This process generates a large amount of interactive data.

[0015] The electricity service system is primarily responsible for interacting with users, processing electricity applications, payments, and fault repair reports. Interaction data includes basic user information, electricity contract information, payment records, and repair work orders. For example, after a user submits an electricity application, information such as the application time and requested capacity can be recorded, and the application will be approved and processed according to business processes.

[0016] Each interaction data unit is labeled with a business scenario. These labels can be categorized according to different business stages and functions, such as "power generation scheduling scenario," "transmission fault repair scenario," "distribution load adjustment scenario," and "user electricity application scenario." By collecting these business scenario-labeled interaction data units from data sources such as databases, log files, and monitoring systems across various business systems, an initial cross-system interaction data set can be generated. During the collection process, preliminary data screening and cleaning are required to remove duplicate, erroneous, or invalid data to ensure data quality.

[0017] Step S120: Perform scenario feature analysis on the initial interaction data set to obtain business scenario features and interaction behavior features corresponding to each interaction data unit. The business scenario features include scenario function description information and scenario process node association relationships, and the interaction behavior features include interaction operation types and operation timing sequences.

[0018] Step S121: performing data format standardization processing on each interactive data unit in the initial interactive data set, unifying the naming rules and data type definitions of data fields, wherein the data fields include a business operation identification field, a data generation time field, and an associated system identification field.

[0019] Different power business systems may use different data formats to record interactive data. For example, the power generation system may use a set encoding method to represent generator operations, while the transmission system may use another encoding method. To facilitate subsequent processing and analysis, the format of this interactive data needs to be standardized.

[0020] Different systems may use different names for the same business operation identification field. For example, a power generation system might use "generator operation code," while a transmission system might use "transmission equipment operation number." These different names need to be standardized into a single name, such as "business operation identification field," and the value of this field must be unique to accurately identify each business operation.

[0021] The data generation time field also needs to be formatted in a unified format. Different systems may use different time representations, such as "year-month-day hour:minute:second" or "month / day / year hour:minute." These need to be standardized into a standard time format, such as "year-month-day hour:minute:second," to facilitate chronological sorting and analysis of data.

[0022] The associated system identifier field indicates which system generated the interaction data and which systems it interacted with. Different systems may use different identifiers, such as system names or system numbers. These identifiers need to be standardized to clearly identify the source and destination of each interaction data unit. For example, a unique system number can be used to identify the associated system, thus avoiding confusion caused by different system names.

[0023] Data format standardization can be achieved using data conversion tools or custom scripts. First, analyze the data structure of each data source to determine the fields that need to be standardized and the corresponding conversion rules. Then, convert and cleanse the data according to these conversion rules to ensure data consistency and accuracy.

[0024] Step S122: Extract the scenario identification information in the standardized interaction data unit, associate the preset business scenario knowledge base according to the scenario identification information, obtain the corresponding scenario function description information and scenario process node association relationship as the business scenario feature, and the scenario identification information includes the business module name and operation type combination code.

[0025] Step S1221: performing keyword extraction processing on the standardized interaction data unit to obtain a scenario keyword set including a business module name and an operation purpose description, wherein the business module name corresponds to the functional division of a specific business system.

[0026] In the power business scenario, natural language processing technology is used to extract keywords from standardized interaction data units. For interaction data related to power generation systems, possible keywords include "generator," "start," "power adjustment," and "generation plan." "Generator" corresponds to the business module name of the power generation system, while "start," "power adjustment," and "generation plan" describe the purpose of the operation.

[0027] For interactive data on the power transmission system, keywords might include "transmission line," "fault detection," "load distribution," and "line maintenance." "Transmission line" is the name of the business module in the power transmission system, and "fault detection," "load distribution," and "line maintenance" describe the purpose of the operation.

[0028] For interactive data on the distribution system, keywords can include "distribution transformer," "load monitoring," "power outage restoration," and "distribution optimization." "Distribution transformer" is the name of the distribution system's business module, and "load monitoring," "power outage restoration," and "distribution optimization" describe the purpose of the operation.

[0029] For interactive data in the electricity service system, keywords might include "user," "electricity application," "payment," and "fault repair." "User" is the name of the service module in the electricity service system, and "electricity application," "payment," and "fault repair" describe the purpose of the operation.

[0030] By extracting the above keywords, we can preliminarily determine the business module and operation type to which the interaction data belongs.

[0031] Step S1222: Match the scenario keyword set with the scenario identification tags in the preset business scenario knowledge base through a semantic similarity calculation algorithm to determine the target business scenario type to which the interaction data unit belongs. The semantic similarity calculation algorithm is based on word vector space distance measurement.

[0032] The pre-set business scenario knowledge base stores identification tags for various power business scenarios, along with the feature descriptions and business rules associated with these tags. For example, the identification tag for a "generation scheduling scenario" might be associated with feature descriptions such as "adjusting generator power according to grid load demand" and "developing a power generation plan." The identification tag for a "transmission fault repair scenario" might be associated with feature descriptions such as "detecting transmission line faults," "isolating the faulty line," and "restoring power."

[0033] The extracted scenario keyword set is converted into word vectors and then compared with the word vectors of the scenario identification tags in the business scenario knowledge base. Semantic similarity calculation algorithms are based on distance metrics in the word vector space. Common methods include cosine similarity. Cosine similarity measures the similarity between two word vectors by calculating the cosine value of the angle between them. The closer the cosine value is to 1, the more similar the two vectors are.

[0034] For a scenario keyword set containing keywords such as "generator," "power adjustment," and "generation plan," convert them into word vectors and then perform cosine similarity calculations with the word vectors of each scenario identification label in the business scenario knowledge base. If the word vector similarity with "power generation scheduling scenario" is the highest, then the target business scenario type for this interaction data unit is determined to be "power generation scheduling scenario."

[0035] In practical applications, to improve matching accuracy, word vectors can be preprocessed, such as removing stop words and performing stemming, to reduce the impact of noise on similarity calculations. A similarity threshold can also be set; a match is considered successful only when the similarity exceeds the threshold; otherwise, further inspection or manual intervention is required.

[0036] Step S1223: extracting scenario function description information corresponding to the target business scenario type from the business scenario knowledge base, wherein the scenario function description information includes input data requirements and output result standards of the business process, and the input data requirements include data field integrity and format standardization requirements.

[0037] Once the target business scenario type is determined, the corresponding scenario function description information can be extracted from the business scenario knowledge base. Taking the "power generation scheduling scenario" as an example, its scenario function description information is as follows: In terms of input data requirements, relevant data about the power generation system must be collected, including real-time generator status information, such as its operating status (started, stopped, running), its current power output, and its adjustable power range; grid load demand information, such as forecasted and real-time loads for each time period; and information related to power generation plans, such as established power generation plans and their adjustment rules. These data fields must be complete and formatted in a standardized manner. For example, generator power output must be expressed in a defined unit (such as megawatts) and with a defined accuracy, and time information must use a standardized time format.

[0038] In terms of output standards, the output of the power generation scheduling scenario includes the generation of power generation scheduling instructions, which must clearly indicate the power adjustment target and adjustment time for each generator; the power generation plan adjustment plan, including the adjusted power distribution and power generation schedule; and feedback on the scheduling results, such as the execution status of the scheduling instructions and the effect of the power generation plan adjustment. These output results must meet the specified format and content requirements to ensure that they can be correctly understood and executed by the relevant business systems.

[0039] For the "power transmission fault repair scenario," input data requirements include real-time transmission line parameter monitoring data, such as current, voltage, and power; fault alarm information, such as the time, location, and type of fault; and transmission line topology information. Output standards include a fault diagnosis report, clearly identifying the fault's location and cause; a fault resolution plan, including the steps for isolating the faulty line and the sequence for restoring power; and a time record and effectiveness evaluation of the fault resolution.

[0040] Step S1224: parse the business process diagram corresponding to the target business scenario type, extract the forward and backward dependencies and data transfer paths between the scenario process nodes, and generate the scenario process node association relationship. The scenario process node association relationship includes node execution conditions and data mapping rules between nodes. The node execution conditions include the completion status of the predecessor node and the validity of the input data.

[0041] For each target business scenario type, the corresponding business process diagram describes the execution steps and sequence of the business process within that scenario. Taking the business process diagram for the "power generation scheduling scenario" as an example, process nodes may include "collecting power generation data," "analyzing grid load demand," "developing a power generation scheduling plan," "issuing power generation scheduling instructions," "executing power generation scheduling instructions," and "feeding back scheduling results."

[0042] The "Collect Power Generation Data" node is a prerequisite for subsequent nodes. The "Analyze Grid Load Demand" node can only be processed after this node completes and the collected data is valid. The data transfer path between nodes indicates the direction of data flow between different nodes. For example, the generator status information and grid load demand information collected by the "Collect Power Generation Data" node is passed to the "Analyze Grid Load Demand" node for processing.

[0043] Node execution conditions include the completion status of the preceding node and the validity of the input data. For example, the execution condition for the "Develop Generation Scheduling Plan" node is that the "Analyze Grid Load Demand" node has completed and the input load analysis result data is valid. Inter-node data mapping rules define the conversion and correspondence between data between different nodes. For example, the load forecast data output by the "Analyze Grid Load Demand" node must be converted according to the set rules into input data that can be used by the "Develop Generation Scheduling Plan" node, such as converting the load forecast data into the power adjustment requirements of the generator.

[0044] For the "power transmission fault repair scenario," the business process diagram nodes may include "detecting transmission line faults," "locating the fault location," "isolating the faulted line," "repairing the faulted line," and "restoring power." The "detecting transmission line faults" node is a prerequisite for subsequent nodes. Only after the fault is detected and its type determined can the "locating the fault location" node be executed. The data transmission path between nodes includes the transmission of fault detection data from the detection node to the location node, and the transmission of location results from the location node to the isolation node. Node execution conditions and inter-node data mapping rules are also defined according to the business process logic to ensure the smooth progress of the fault repair process.

[0045] Step S1225: Structurally integrate the scenario function description information and the scenario process node association relationship to generate a business scenario feature descriptor with a hierarchical structure, wherein the hierarchical structure includes a business process level, a node level, and a data interaction level.

[0046] The scenario function description information and the scenario process node association relationship are integrated to form a business scenario feature descriptor with a hierarchical structure.

[0047] At the business process level, the overall objectives and functions of the entire business process are described. For example, the overall goal of the "generation scheduling scenario" is to rationally arrange power generation resources based on grid load demand to ensure stable and economic power supply. This level also includes an overview of the main stages and steps of the business process, such as power generation data collection, load analysis, scheduling plan development, command issuance, and execution.

[0048] At the node level, each process node's function, execution conditions, and input and output data are described in detail. For example, the "Collect Power Generation Data" node collects generator data and grid load demand information; its execution conditions require the normal operation of the system and the data acquisition equipment; its input data is real-time monitoring data from generators and grid load forecast data; and its output data is the consolidated power generation and load data. Each node's description also includes its dependencies with other nodes and the data transfer path.

[0049] At the data interaction level, the data transfer and mapping rules between different nodes, as well as the data format and quality requirements, are described. For example, the data transfer path between the "Analyze Grid Load Demand" node and the "Develop Generation Dispatch Plan" node represents how the load analysis results are transmitted to the dispatch plan formulation node; the data mapping rules define how the load analysis results are converted into the input data required for dispatch plan formulation; data format requirements stipulate that the transmitted data must adopt a specified format, such as numeric type or text type; and data quality requirements specify the accuracy, completeness, and timeliness of the data.

[0050] The above hierarchical structure can effectively represent the characteristics and internal logic of business scenarios.

[0051] Step S123: Identify the operation instruction code in the interactive data unit, parse the interactive operation type according to the operation instruction code, and generate an operation timing sequence as an interactive behavior feature in the order of timestamps. The operation instruction code includes a system interface call instruction and a data processing instruction.

[0052] Step S1231: Perform syntax parsing on the operation instruction code in the interactive data unit, identify the operation verbs and operation objects in the operation instruction code, and determine the interactive operation type according to the preset operation type classification rules. The interactive operation types include data query, data writing, service call and process jump, and the operation verbs correspond to different interactive operation types.

[0053] In power business scenarios, the operation instruction codes in interactive data units may use complex encoding methods, requiring detailed syntax parsing. For example, the operation instruction code "CALL_SERVICE(GET_GENERATOR_STATUS,PARAMS=[GENERATOR_ID=123])" can be identified through syntax parsing as the operation verb "CALL_SERVICE", the operation object "GET_GENERATOR_STATUS", and the parameter list "PARAMS=[GENERATOR_ID=123]".

[0054] According to the preset operation type classification rules, if the operation verb is "CALL_SERVICE", the corresponding interaction operation type is "service call"; if the operation verb is "SELECT", it indicates a query operation, and the corresponding interaction operation type is "data query"; if the operation verb is "INSERT" or "UPDATE", it indicates a data insertion or update operation, and the corresponding interaction operation type is "data write"; if the operation verb is "JUMP_TO", it indicates a process jump operation, and the corresponding interaction operation type is "process jump".

[0055] In practice, operation instruction codes may contain multiple nested operations and complex parameter structures. For example, the operation instruction code "CALL_SERVICE(UPDATE_GENERATOR_STATUS,PARAMS=[GENERATOR_ID=123,STATUS=RUNNING,CALLBACK=CALL_SERVICE(GET_GENERATOR_POWER,PARAMS=[GENERATOR_ID=123]))" requires recursive parsing to identify multiple operation verbs and operation objects, and determine the interaction type of each operation.

[0056] Step S1232: extracting the timestamp information of the interaction data unit, sorting the interaction data units in the same business scenario according to the order of the timestamps, and generating a continuous operation sequence.

[0057] Each interaction data unit contains timestamp information, recording the time when the data unit was generated. For interaction data units in the same business scenario, they are sorted according to the chronological order of timestamps. For example, in the "power generation scheduling scenario", there are multiple interaction data units that record operation instructions at different times, as follows: Interaction data unit 1: The timestamp is T1, and the operation instruction code is "CALL_SERVICE(GET_GENERATOR_STATUS,PARAMS=[GENERATOR_ID=123])" Interaction data unit 2: The timestamp is T2, and the operation instruction code is "CALL_SERVICE(UPDATE_GENERATOR_STATUS,PARAMS=[GENERATOR_ID=123,STATUS=RUNNING])" Interaction data unit 3: The timestamp is T3, and the operation instruction code is "CALL_SERVICE(GET_GENERATOR_POWER,PARAMS=[GENERATOR_ID=123])" Assume T1 < T2 < T3. After sorting by timestamp, the generated consecutive operation sequence is: Operation sequence: "CALL_SERVICE(GET_GENERATOR_STATUS,PARAMS=[GENERATOR_ID=123])" -> "CALL_SERVICE(UPDATE_GENERATOR_STATUS,PARAMS=[GENERATOR_ID=123,STATUS=RUNNING])" -> "CALL_SERVICE(GET_GENERATOR_POWER,PARAMS=[GENERATOR_ID=123])" The above operation sequence reflects the execution order of operations in this business scenario.

[0058] Step S1233: Analyze the parameter passing relationship between the operation instruction codes in adjacent operation sequences, determine the dependency relationship and execution order constraint between operations, and generate an operation timing sequence containing dependency relationship identifiers, where the parameter passing relationship includes the source of input parameters and the destination of output parameters.

[0059] In a continuous operation sequence, analyze the parameter transfer relationship between adjacent operation instruction codes. For example, in the above operation sequence, the output of "CALL_SERVICE(GET_GENERATOR_STATUS,PARAMS=[GENERATOR_ID=123])" may be used as the input parameter of "CALL_SERVICE(UPDATE_GENERATOR_STATUS,PARAMS=[GENERATOR_ID=123,STATUS=RUNNING])". Specifically, the generator status information returned by the "GET_GENERATOR_STATUS" service call may be used to determine whether the generator status can be updated to "RUNNING".

[0060] By analyzing the above parameter transfer relationship, we can determine the dependencies and execution order constraints between operations. If the "CALL_SERVICE(UPDATE_GENERATOR_STATUS,PARAMS=[GENERATOR_ID=123,STATUS=RUNNING])" operation depends on the result of the "CALL_SERVICE(GET_GENERATOR_STATUS,PARAMS=[GENERATOR_ID=123])" operation, then the "CALL_SERVICE(GET_GENERATOR_STATUS,PARAMS=[GENERATOR_ID=123])" operation must be executed first. Add dependencies for each operation. Identification generates an operation sequence with dependency identifiers, effectively indicating the order and dependency relationships between operations. For example, in an operation sequence, the "CALL_SERVICE(GET_GENERATOR_STATUS,PARAMS=[GENERATOR_ID=123])" operation can be marked as operation 1, and the "CALL_SERVICE(UPDATE_GENERATOR_STATUS,PARAMS=[GENERATOR_ID=123,STATUS=RUNNING])" operation can be marked as operation 2. The description of operation 2 also states that it depends on the result of operation 1.

[0061] Step S1234: performing time interval analysis on the operation timing sequence, calculating the time interval between adjacent operations, and generating a time interval feature vector reflecting the operation execution frequency and time distribution characteristics.

[0062] After obtaining the operation sequence containing dependency identifiers, the time intervals between adjacent operations are analyzed. Time interval analysis can reflect the frequency and time distribution characteristics of operation execution, which is of great significance for optimizing business processes and improving system efficiency.

[0063] Taking the previous operation timing sequence as an example, the "CALL_SERVICE(GET_GENERATOR_STATUS,PARAMS=[GENERATOR_ID=123])" operation is executed at time T1, and the "CALL_SERVICE(UPDATE_GENERATOR_STATUS,PARAMS=[GENERATOR_ID=123,STATUS=RUNNING])" operation is executed at time T2. The time interval between these two operations is T2-T1. Similarly, calculate the time interval between the "CALL_SERVICE(UPDATE_GENERATOR_STATUS,PARAMS=[GENERATOR_ID=123,STATUS=RUNNING])" operation and the "CALL_SERVICE(GET_GENERATOR_POWER,PARAMS=[GENERATOR_ID=123])" operation as T3-T2.

[0064] By counting the duration of these time intervals, we can derive the frequency and temporal distribution characteristics of the operations. For example, short intervals between operations indicate a high frequency of execution; large fluctuations in the intervals indicate an unstable temporal distribution of the operations. These characteristics are represented as a time interval feature vector, which contains information about the frequency and temporal distribution of the operations, such as the average interval between operations and the fluctuation range of the intervals.

[0065] In practical applications, time intervals can also be categorized and analyzed based on the characteristics of the business scenario. For example, in a power generation scheduling scenario, operations can be divided into routine operations and emergency operations, and the time interval characteristics of these two types of operations can be statistically analyzed to better understand the operation of the business process.

[0066] Step S1235: Associating and integrating the interaction operation type and the operation timing sequence including the dependency identifier to generate a complete interaction behavior feature description set.

[0067] Associate the identified interaction operation type with the operation sequence containing the dependency identifier. For each operation in the operation sequence, associate its corresponding interaction operation type. For example, the interaction operation type of the "CALL_SERVICE(GET_GENERATOR_STATUS,PARAMS=[GENERATOR_ID=123])" operation is "Service Call." Associate this information with the operation's position in the operation sequence and its dependencies.

[0068] At the same time, the time interval feature vector is also incorporated into the integration process. The time interval feature vector reflects the temporal characteristics of the operation execution and, together with the interaction operation type and operation timing sequence, can more comprehensively describe the characteristics of the interaction behavior.

[0069] Through this integration, a complete set of interaction behavior feature descriptions is generated. This set includes information such as the interaction operation type, execution order, dependencies, and time distribution, comprehensively describing the characteristics of the interaction behavior. This set of interaction behavior feature descriptions can serve as input for subsequent collaborative correlation analysis, helping to identify interaction patterns and collaborative relationships between different business systems.

[0070] Step S124: performing dimension unification processing on the business scenario features and interaction behavior features generated by different business systems to generate a scenario behavior feature set with the same feature dimension. The dimension unification processing includes feature field mapping and data type conversion.

[0071] The business scenario characteristics and interaction behavior characteristics generated by different business systems may have different dimensions and data types. For example, the business scenario characteristics of a power generation system may focus on the operating parameters of the generator, such as power, temperature, and speed; while the business scenario characteristics of a transmission system may focus on the status parameters of the transmission line, such as current, voltage, and power factor. The representation and data types of these characteristics may vary across different systems, requiring dimensionality unification.

[0072] Feature field mapping aligns fields representing the same or similar characteristics across different systems. For example, the "generator power" field in a power generation system and the "transmission power" field in a power transmission system, while named differently, both relate to power. They can be mapped to maintain dimensional consistency. When mapping feature fields, consider the semantics and business implications of the fields to ensure accurate mapping.

[0073] Data type conversion ensures that data with the same characteristics in different systems are of the same data type. For example, generator power data in a power generation system is represented as integers, while transmission power data in a power transmission system is represented as floating-point numbers. The integer data in the power generation system needs to be converted to floating-point representation to ensure data type consistency.

[0074] Dimensional unification can be achieved using a data dictionary and mapping rules. The data dictionary records the definitions and meanings of each feature field in different systems, while the mapping rules specify how to map feature fields and convert data types. By applying these data dictionaries and mapping rules, the business scenario features and interaction behavior features generated by different business systems are processed to generate a set of scenario behavior features with the same feature dimensions.

[0075] Step S125: Based on the information entropy calculation results of each feature dimension in the scenario behavior feature set, determine the feature contribution parameters of the business scenario features and interactive behavior features in the collaborative correlation analysis. The information entropy calculation results reflect the information richness and distribution uniformity of the feature dimensions.

[0076] Information entropy is a metric used to measure the uncertainty and richness of information. For each feature dimension in the scene behavior feature set, its information entropy is calculated. The calculation of information entropy can be understood as analyzing the distribution of data along that feature dimension. If the data distribution along a feature dimension is relatively even, it indicates that the information richness of that feature dimension is low, and the information entropy is low. Conversely, if the data distribution is uneven, with some values ​​appearing more frequently than others, it indicates that the information richness of that feature dimension is high, and the information entropy is high.

[0077] Taking the "generator power" feature dimension in the power generation system as an example, if the values ​​of generator power are concentrated in a small range over a period of time, it means that the data distribution of this feature dimension is relatively uniform and the information entropy is small; if the values ​​of generator power fluctuate greatly and cover a wide range, it means that the data distribution of this feature dimension is uneven and the information entropy is large.

[0078] Based on the information entropy calculation results, determine the feature contribution parameters for business scenario characteristics and interactive behavior characteristics in collaborative correlation analysis. Feature dimensions with higher information entropy may have higher feature contributions in collaborative correlation analysis because they contain more useful information and can better reflect the characteristics of business scenarios and interactive behaviors. Feature dimensions with lower information entropy may have relatively lower feature contributions.

[0079] When determining the feature contribution parameter, a normalization method can be used to convert the information entropy value into a feature contribution parameter within a set range, ensuring that the contribution parameters of each feature dimension are comparable. In this way, a reasonable feature contribution parameter is assigned to each feature dimension, allowing the importance of different features to be more accurately considered in subsequent collaborative correlation analysis.

[0080] Step S130: calling a pre-built business collaboration analysis model to perform collaborative correlation analysis on the business scenario characteristics and the interaction behavior characteristics, and generating a collaborative processing strategy for each interaction data unit, wherein the collaborative processing strategy includes microservice call priority and data interaction format specification.

[0081] Step S131: Input the business scenario features and interactive behavior features into the feature fusion network of the business collaboration analysis model, perform weighted fusion processing in combination with feature contribution parameters, and generate a fusion feature vector containing scenario behavior association information. The feature contribution parameters are determined based on the information entropy calculation results.

[0082] The feature fusion network of the business collaboration analysis model receives business scenario features and interaction behavior features as input. The function of the feature fusion network is to organically combine these two types of features and extract the relevant information.

[0083] During the fusion process, weighted fusion is performed based on the previously determined feature contribution parameters. Feature dimensions with higher contribution are assigned larger weights, while those with lower contribution are assigned smaller weights. For example, in business scenario features, the "generator power" feature dimension has a higher contribution, so during weighted fusion, this feature dimension will have a relatively higher weight. Conversely, in interactive behavior features, the feature dimension of a less important operation may have a lower contribution and therefore a relatively smaller weight.

[0084] Through weighted fusion, business scenario features and interaction behavior features are combined into a fused feature vector containing scenario-behavior correlation information. This fused feature vector integrates information about business scenarios and interaction behaviors, better reflecting the collaborative relationships between different business systems. For example, the fused feature vector may include information on the correlation between generator operating status and business operations, or between transmission line status and interaction processes.

[0085] Step S132: performing node relationship analysis and dependency evaluation on the fused feature vector using a business collaboration analysis model to identify process node interaction points of different business systems in the target business scenario.

[0086] The business collaboration analysis model analyzes node relationships and evaluates dependencies within the fused feature vector. In the power business scenario, complex relationships and dependencies exist between process nodes in different business systems. For example, the "generator power adjustment" node in the power generation system may interact with the "transmission line load distribution" node in the transmission system, as generator power adjustments affect the load on the transmission lines.

[0087] By analyzing the fused feature vectors, the model identifies process node interaction points between different business systems in the target business scenario. These interaction points represent locations where data exchange and collaborative operations are required between different business systems. When resolving node relationships, the model analyzes the input-output relationships between process nodes to determine which nodes have data transfer and business collaboration. For example, the output data of the "Generator Power Adjustment" node may serve as input data for the "Transmission Line Load Distribution" node, thus forming an interaction point.

[0088] Dependency assessment determines the execution order and dependencies between nodes. For example, the execution of the "Transmission Line Load Distribution" node may depend on the completion of the "Generator Power Adjustment" node, which requires the input of valid generator power adjustment data. Through this assessment, the model can accurately identify the process node interaction points between different business systems.

[0089] Step S133: Based on the functional interface description and resource occupancy of the microservice, perform a microservice call adaptability analysis on the process node interaction points to determine the microservice call priority corresponding to each process node interaction point. The microservice call adaptability analysis includes functional interface matching and performance stability evaluation.

[0090] Establish a microservice information knowledge base, which contains information such as each microservice's functional interface description, service response time threshold, and resource usage peak parameters. The functional interface description details the microservice's input parameter requirements, output result format, and service functionality. For example, a microservice for generator power calculation might have a functional interface description that includes the input parameter as real-time generator operating data, the output result as the calculated generator power value, and the service function as performing power calculation based on the input data.

[0091] For each process node interaction point, extract the data processing functions and data transmission requirements required by that interaction point. For example, the "generator power adjustment" process node interaction point may require power calculation and adjustment control, as well as the transmission of adjusted power data to related systems.

[0092] The microservice information knowledge base is used to match candidate microservices with identical or similar functional interfaces. Based on the data processing and data transmission requirements required at process node interaction points, microservices that meet these requirements are selected. For example, if a process node interaction point requires generator power calculation, the microservice information knowledge base is searched for microservices with power calculation capabilities as candidate microservices.

[0093] We obtain historical call records for each microservice in the candidate set and analyze its service response time and resource usage over different time periods to generate microservice performance stability evaluation metrics. Service response time reflects the speed at which a microservice processes requests, while resource usage reflects the microservice's use of system resources during operation. We assess microservice performance stability by analyzing the microservice's average response time, response time fluctuation range, and peak and average resource usage.

[0094] Based on the functional interface matching and microservice performance stability evaluation indicators, a compatibility score is calculated for each microservice candidate. The higher the functional interface matching and the better the performance stability, the higher the compatibility score. The set of microservice candidates is sorted from high to low based on their compatibility scores. The microservice call priority for each process node interaction point is determined based on pre-set prioritization rules. For example, the microservice with the highest compatibility score has the highest call priority and is selected first when a process node interaction point needs to call a microservice.

[0095] Step S134: Based on the data format of the interactive data unit and the data processing requirements of the business scenario, a data interaction format specification including field mapping rules and data verification logic is generated, wherein the data interaction format specification includes a mapping relationship between the source system data structure and the target system data structure.

[0096] Generate a data interaction format specification based on the data format of the interactive data unit and the data processing requirements of the business scenario. In the power business scenario, the data formats of different business systems may be different. For example, the data format of the power generation system may differ from the data format of the power service system.

[0097] Field mapping rules define the correspondence between source system data structures and target system data structures. For example, the "Generator Number" field in the power generation system needs to be mapped to the "Associated Generator Equipment Number" field in the power consumption system. When developing field mapping rules, it's important to consider the semantics and business implications of the fields to ensure accurate mapping.

[0098] Data validation logic is used to ensure data accuracy and integrity. For example, it verifies the range and format of input data. For generator power data, data validation logic can specify that the power value must be within a reasonable range and that the data format must meet set requirements.

[0099] By generating data exchange format specifications, different business systems can accurately exchange data and avoid errors during data transmission and processing. Data exchange format specifications can serve as a standard for data exchange, guiding data transmission and processing operations between different systems.

[0100] Step S135: The microservice call priority and data interaction format specification are grouped and integrated according to the business scenario label of the interaction data unit to generate a collaborative processing strategy set for each interaction data unit. The grouping and integration processing includes feature classification and rule encapsulation.

[0101] The determined microservice call priorities and data interaction format specifications are grouped according to the business scenario label of the interaction data unit. For example, for the interaction data unit in the "power generation scheduling scenario", the corresponding microservice call priorities and data interaction format specifications are grouped together; for the interaction data unit in the "transmission fault repair scenario", the corresponding microservice call priorities and data interaction format specifications are grouped together.

[0102] Based on the grouping, feature classification and rule encapsulation are performed. Feature classification involves categorizing and organizing different types of information. For example, microservice call priority information and data exchange format specification information can be categorized separately. Rule encapsulation involves encapsulating related rules and logic to form an independent processing unit. For example, the microservice call priority rules and data exchange format specification rules in the "power generation scheduling scenario" can be encapsulated together to form a coordinated processing strategy for that scenario.

[0103] Through grouping and integration processing, a collaborative processing strategy set is generated for each interactive data unit. This collaborative processing strategy set includes microservice call priorities and data interaction format specifications in different business scenarios.

[0104] Step S140: determining a business process adjustment plan for each business system in a target business scenario according to the collaborative processing strategy, wherein the business process adjustment plan includes a process node execution sequence and data transmission rules between nodes.

[0105] Step S141: parse the collaborative processing strategy of each interactive data unit, extract the microservice call priority and data interaction format specification, and classify and aggregate them according to the business scenario label. The classification and aggregation processing includes data statistics and rule integration.

[0106] The collaborative processing strategy of each interactive data unit is parsed to extract the microservice call priority and data interaction format specification information. Since collaborative processing strategies are grouped and integrated according to business scenario tags, this information can be classified according to business scenario tags during the parsing process.

[0107] Collect data statistics on the call priority information of microservices under the same business scenario tag. This includes statistics on the call frequency and priority distribution of different microservices in that business scenario. For example, in the "power generation scheduling scenario," count the number of times each microservice is called, as well as the proportion of microservices with different priorities.

[0108] For data interaction format specification information, rule integration is performed. Data interaction format specifications within the same business scenario are merged and unified to eliminate conflicts and inconsistencies between rules. For example, for the data interaction format specifications for different interactive data units in the "power generation scheduling scenario," field mapping rules and data validation logic are integrated to form a unified data interaction format specification.

[0109] Through classification and aggregation, we can obtain the microservice call priority statistics and unified data interaction format specifications for each business scenario.

[0110] Step S142: Analyze the execution order of process nodes corresponding to different microservice call priorities for the target business scenario, and determine the key process nodes corresponding to the microservices that need to be called first.

[0111] Step S1421: Group all collaborative processing strategies under the target business scenario according to the microservice call priority, and extract the process node set corresponding to the target priority microservice, where the adaptability score of the target priority microservice is higher than the preset priority threshold.

[0112] For the target business scenario, all collaborative processing strategies are grouped according to the microservice call priority. A priority threshold is preset, and microservices with adaptability scores higher than the threshold are defined as target priority microservices.

[0113] From the grouped collaborative processing strategies, extract the set of process nodes corresponding to the target priority microservice. These process nodes are associated with the target priority microservice and play a key role in the business process. For example, in the "power generation scheduling scenario," the target priority microservice might be a microservice for generator power calculation and scheduling. The corresponding process nodes might include "generator power data collection" and "generation scheduling plan formulation."

[0114] Step S1422: performing dependency analysis on the process node set, identifying the preceding nodes and succeeding nodes therein, and constructing a dependency graph of the process nodes, wherein the dependency graph includes the dependency relationships and data transfer paths between the process nodes.

[0115] Perform dependency analysis on the extracted process node set. By analyzing the input-output relationships and business logic between nodes, determine which nodes are predecessor nodes and which nodes are successor nodes. For example, the "Generator Power Data Collection" node is a predecessor node of the "Generation Scheduling Plan Development" node because only after collecting accurate generator power data can a reasonable generation scheduling plan be developed.

[0116] Based on the dependencies between nodes, a dependency graph is constructed for the process nodes. This graph graphically represents the dependencies and data transfer paths between process nodes. In the graph, nodes represent process nodes, and edges represent the dependencies and data transfer directions between nodes. For example, an edge from the "Generator Power Data Collection" node to the "Generation Scheduling Plan Development" node indicates that power data is transferred from the collection node to the development node, and that the development node depends on the completion of the collection node.

[0117] Step S1423: Find the critical path from the process start point to the process end point in the dependency graph, and determine the process nodes on the implementation critical path as key process nodes. The critical path refers to the longest path that determines the execution time of the business process.

[0118] Within the constructed process node dependency graph, we need to find the critical path from the process's starting point to its end point. The critical path is the longest path in the entire business process and determines the total execution time of the business process. This process can be achieved by traversing and analyzing all possible paths in the dependency graph.

[0119] Starting from the process's starting point, traverse each node along the edges of the dependency graph, recording the nodes and time taken for each path. For each path, add up the execution time of each node along the path to obtain the total execution time for that path. By comparing the total times of all paths, find the longest path, which is the critical path.

[0120] In the "Generation Scheduling Scenario," assume the process starts at the "Generator Power Data Collection" node and ends at the "Generation Scheduling Instruction Execution Completed" node. Multiple paths may connect these two nodes. For example, Path 1 could be "Generator Power Data Collection -> Generation Demand Analysis -> Generation Scheduling Plan Development -> Generation Scheduling Instruction Issuance -> Generation Scheduling Instruction Execution Completed"; Path 2 could be "Generator Power Data Collection -> Generator Status Assessment -> Generation Scheduling Plan Development -> Generation Scheduling Instruction Issuance -> Generation Scheduling Instruction Execution Completed."

[0121] Perform a time analysis on these two paths, calculating the sum of the execution time for each node on each path. Assuming that Path 1 takes longer, Path 1 is the critical path. Process nodes on the critical path, such as "Generator Power Data Collection," "Generation Demand Analysis," "Generation Scheduling Plan Development," "Generation Scheduling Instruction Issuance," and "Generation Scheduling Instruction Execution Completion," are considered key process nodes. The execution of these nodes directly impacts the execution time and efficiency of the entire business process, and therefore warrants special attention during business process adjustments.

[0122] Step S1424: Analyze the input and output data requirements of key process nodes so that the data required by the key process nodes can be effectively transmitted through existing data interaction format specifications. The input and output data requirements include data field integrity and format standardization requirements.

[0123] After identifying key process nodes, it's necessary to analyze their input and output data requirements in detail. For each key process node, clearly define the required input data and the generated output data. For example, for the "Generation Scheduling Plan" node, input data might include real-time generator power data, generation demand forecasts, and the generator's adjustable power range. Output data might include a pre-defined generation scheduling plan, including power allocations for each generator and generation schedules.

[0124] These input and output data must meet specified requirements for data field integrity and format compliance. Data field integrity requires that input data contain all necessary fields. For example, power generation demand forecast data must include information such as the predicted load value for each time period and load growth trends. Format compliance requires that data representation conform to specified specifications. For example, generator power data must be expressed in the specified units and with the specified accuracy.

[0125] According to the existing data interaction format specifications, check whether the input and output data of key process nodes can be effectively transmitted. The data interaction format specifications include field mapping rules and data verification logic to ensure that data between different business systems can interact accurately. For example, in the "Power Generation Scheduling Plan Formulation" node, the input generator power data may come from the power generation system, and the data format of the power generation system may differ from the data format required by the scheduling plan formulation module. Through the field mapping rules in the data interaction format specifications, the generator power data field in the power generation system is mapped to the field required by the scheduling plan formulation module, and the data verification logic is used to verify the data to ensure its accuracy and completeness.

[0126] If it is found that the input and output data requirements of key process nodes do not match the existing data interaction format specifications, it is necessary to adjust and optimize the data interaction format specifications, or pre-process the input and output data of key process nodes to ensure that the data can be effectively transmitted.

[0127] Step S1425: Generate a list of key process nodes, which includes node names, node function descriptions, and execution priority rankings in target business scenarios. The execution priority rankings are determined based on the critical path analysis results and microservice call priorities.

[0128] Based on the critical path analysis results and microservice call priorities, a list of key process nodes is generated. The list includes the name, function description, and execution priority of each key process node.

[0129] The node name clearly identifies the node in the business process, such as "Generator Power Data Collection" and "Generation Scheduling Plan Development." The node function description details the specific function and role of the node. For example, the "Generator Power Data Collection" node collects real-time generator power data, operating status, and other information; the "Generation Scheduling Plan Development" node develops a reasonable generation scheduling plan based on the input power demand and generator status information.

[0130] Execution priority is determined based on the results of critical path analysis and the priority of microservice calls. Nodes on the critical path typically have a higher execution priority because they significantly impact the execution time of the business process. Nodes associated with high-priority microservices also receive a correspondingly higher execution priority. For example, in the "Power Generation Scheduling Scenario," the "Power Generation Scheduling Plan Development" node is on the critical path and associated with a high-priority microservice, thus receiving a higher execution priority in the list of critical process nodes.

[0131] The above information is organized into a list of key process nodes. Through this list, it is possible to clearly identify which nodes are key links in the business process, as well as the execution order and importance of these nodes, so as to optimize and adjust the business process in a targeted manner.

[0132] Step S143: According to the data interaction format specification, a data field mapping relationship table between different business systems is established. The data field mapping relationship table includes source system data fields, target system data fields and data conversion functions. The data conversion function is used to realize conversion between different data formats.

[0133] Based on existing data exchange format specifications, a data field mapping relationship table is established between different business systems. In the power business scenario, different business systems such as power generation systems, transmission systems, distribution systems, and power service systems may have different data fields, and a data field mapping relationship table is needed to achieve effective data exchange.

[0134] The data field mapping table consists of three main components: source system data fields, target system data fields, and data conversion functions. Source system data fields refer to the field names in the system where the data originates, such as the "generator power" field in the power generation system. Target system data fields refer to the field names in the system to which the data is transferred, such as the "input generator power" field in the dispatching system. Data conversion functions are used to convert between different data formats, for example, converting generator power data represented as integers in the power generation system to floating-point numbers in the dispatching system.

[0135] Determining the correspondence between source and target system data fields requires in-depth analysis of the data structures and business logic of different business systems. For example, when exchanging data between a power generation system and a transmission system, the "generated power" field in the power generation system corresponds to the "received generated power" field in the transmission system. After determining the correspondence, appropriate data conversion functions must be selected based on the actual data. If the data types in the source and target systems differ, data type conversion is required. If the data representation differs, such as in date format or units, appropriate conversion operations are also required.

[0136] Data conversion functions can range from simple mathematical operations, such as unit conversion, to complex logical processing, such as data cleansing and format conversion. For example, if generator power data in kilowatts in a power generation system needs to be converted to megawatts for transmission to the transmission system, a simple division operation can be used as the data conversion function. However, for data containing special characters or irregular formats, complex string processing functions may be required for cleansing and conversion.

[0137] By establishing a data field mapping relationship table, you can ensure that data between different business systems can interact accurately and efficiently.

[0138] Step S144: Based on the key process nodes and data field mapping relationship table, the existing business processes of each business system are reorganized, the execution order of the process nodes is adjusted, and data conversion and verification links are inserted.

[0139] After identifying key process nodes and establishing data field mapping tables, it's time to restructure the existing business processes within each business system. The goal of business process restructuring is to optimize business processes, improve execution efficiency and collaboration, and ensure smooth execution of key process nodes and accurate data transmission.

[0140] First, adjust the execution order of key process nodes based on their execution priority. Place key process nodes at key locations within the business process to ensure they are prioritized for execution. For example, in the "Power Generation Scheduling Scenario," adjust the "Power Generation Scheduling Plan Development" node to an appropriate location so that it can be executed promptly after receiving accurate input data.

[0141] Secondly, based on the data field mapping table, data conversion and validation steps are inserted into the business process. During data transfer from the source system to the target system, data conversion is required to meet the requirements of the target system. Data conversion functions are inserted at the input and output of key process nodes to ensure that the data format and content meet the requirements. For example, a data conversion step is inserted between the "Generator Power Data Collection" node and the "Generation Scheduling Plan Development" node to convert the collected generator power data according to the data field mapping table so that it can be correctly processed by the scheduling plan development module.

[0142] At the same time, to ensure data accuracy and completeness, a data validation step needs to be incorporated into the business process. This step verifies the legitimacy of input data, such as whether data fields are complete, data formats are standardized, and data values ​​are within a reasonable range. If data validation fails, timely error handling can be implemented, such as returning an error message or retrieving data. For example, a data validation step can be inserted before the "Generation Dispatch Instruction Issued" node to verify the generation dispatch plan and ensure that the power allocation and time schedule in the plan are reasonable and effective.

[0143] Through the reorganization of business processes, the business processes of each business system can be made more reasonable and efficient, and can better adapt to the needs of business collaboration.

[0144] Step S145: Generate a business process adjustment plan document containing process node execution order adjustment records and data transfer rules between nodes. The business process adjustment plan document contains input and output data specifications and execution condition descriptions for each process node. The execution condition descriptions include the status of the predecessor node and data validity check rules.

[0145] After completing the business process reorganization, a business process adjustment plan document needs to be generated. This document is a detailed record and guidance document for the business process adjustment, including the adjustment record of the execution order of process nodes, the data transmission rules between nodes, the input and output data specifications for each process node, and the execution conditions.

[0146] The process node execution order adjustment record details adjustments to the execution order of each node in the business process. For example, it records which nodes' execution order was advanced or postponed, along with the reasons and rationale for the adjustments. In the "Power Generation Dispatch Scenario," the "Power Generation Dispatch Plan Development" node's execution order was adjusted from third to second because this node is crucial for the subsequent issuance and execution of power generation dispatch instructions, requiring rapid acquisition of accurate input data for plan development.

[0147] Inter-node data transfer rules define the methods and requirements for data transfer between different process nodes. Based on data field mapping tables and data conversion functions, they specify data transfer paths, data formats, and data conversion rules. For example, they define how data collected by the "Generator Power Data Collection" node is transferred to the "Generation Scheduling Plan Development" node after data conversion, as well as the format and validation rules that must be followed during the transfer process.

[0148] The input and output data specifications for each process node detail the specific requirements for the input data required and the output data generated by that node. This includes the name, type, value range, and format of the data fields. For example, the input data specification for the "Generation Scheduling Plan Formulation" node requires the inclusion of real-time generator power data, generation demand forecast data, and other data formats that conform to established standards. The output data specification requires the generation scheduling plan to include the power allocation and generation schedule for each generator, and to be stored and transmitted in a specified format.

[0149] Execution conditions include the status of the preceding node and data validation rules. The preceding node status describes the state that the preceding node must reach before the node can execute. For example, before the "Generation Scheduling Plan Development" node can execute, the "Generator Power Data Collection" node must complete and the collected data must be valid. Data validation rules specify the standards and methods for checking input data, such as whether data fields are complete and whether data values ​​are within a reasonable range. If the input data does not meet the execution conditions, the node will not execute or will perform appropriate error handling.

[0150] The business process adjustment plan document provides a detailed reference for the operation and maintenance personnel and developers of the business system, ensuring that they can accurately understand and implement the adjustments to the business processes and ensure the smooth execution of the business processes.

[0151] Step S150: Generate a collaborative execution instruction containing a microservice call instruction sequence based on the business process adjustment plan, and send the collaborative execution instruction to the target business system to trigger a cross-system collaborative processing operation.

[0152] For example, step S151: parse the process node execution order and inter-node data transfer rules in the business process adjustment plan, and determine the microservice call operation corresponding to each process node, where the microservice call operation includes the name of the called microservice and the required input parameters.

[0153] Analyze the business process adjustment plan to extract the execution order of process nodes and the data transmission rules between nodes. Based on this information, determine the microservice call operation corresponding to each process node.

[0154] During execution, each process node may call one or more microservices to complete specific tasks. For example, in the "Power Generation Scheduling Scenario," the "Power Generation Demand Analysis" node may call a microservice called the "Power Generation Demand Forecasting Microservice" to complete demand analysis. For each process node, the name of the microservice to be called and the required input parameters must be clearly specified.

[0155] The microservice name to be called uniquely identifies the specific microservice to be called. Required input parameters refer to the data required to call the microservice. These data typically come from the output of the previous process node or other relevant data sources. For example, when calling the "Generation Demand Forecasting Microservice," input parameters might include historical electricity usage data and current grid load data.

[0156] When determining a microservice call operation, you need to process the input parameters based on the data field mapping table and data conversion functions. Ensure that the format and content of the input parameters meet the microservice's requirements. For example, if the microservice requires input historical electricity consumption data to be presented in a specified time series format, but the data received from the process node is in a different format, appropriate data conversion is required.

[0157] By analyzing the business process adjustment plan, determine the microservice call operation corresponding to each process node.

[0158] Step S152: According to the execution order of the process nodes, the microservice call operation is converted into an instruction sequence with a time sequence. The instruction sequence includes the unique identifier of the microservice, call parameters and an execution time window. The execution time window is determined according to the execution time requirement of the process node.

[0159] After determining the microservice call operations corresponding to each process node, these operations are converted into a time-ordered instruction sequence according to the execution order of the process nodes. The instruction sequence is generated to ensure that microservices can be executed sequentially according to the requirements of the business process and achieve cross-system collaborative processing.

[0160] Each instruction in the instruction sequence contains the microservice's unique identifier, call parameters, and an execution time window. The microservice's unique identifier uniquely identifies the microservice to be called, ensuring that the instruction is accurately delivered to the target microservice. Call parameters are the data required to call the microservice. These parameters have been processed in the previous steps based on the data field mapping table and data conversion functions.

[0161] The execution time window is determined by the execution time requirements of the process node. Each process node has its own set execution time requirement. For example, in the "Power Generation Scheduling Scenario," the "Power Generation Scheduling Instruction Issue" node must be executed as soon as the power generation scheduling plan is finalized. Therefore, the execution time window for the corresponding microservice call instruction must be set relatively tightly. The execution time window specifies the time range within which microservice call instructions can be executed, ensuring that microservices execute at the appropriate time and preventing premature or late execution from impacting the overall progress of the business process.

[0162] For example, for the microservice call operation corresponding to the "Power Generation Demand Analysis" node, after converting it into instructions, the instructions may be as follows: the microservice unique identifier is "Power Generation Demand Forecast Microservice-ID123", the call parameters are "historical electricity consumption data, current grid load data", and the execution time window is "within 10 minutes after obtaining complete historical electricity consumption data and current grid load data."

[0163] These instructions are generated in sequence according to the execution order of the process nodes, forming a time-ordered instruction sequence that reflects the order and timing of microservice calls in the business process.

[0164] Step S153: performing data type conversion and field name mapping on the microservice call parameters according to the data interaction format specification, so that the format of the microservice call parameters meets the input requirements of the target microservice.

[0165] After generating the instruction sequence, the microservice call parameters need to be further processed according to the data exchange format specification. Different microservices may have different input requirements, including data type and field name specifications. Therefore, data type conversion and field name mapping are required to ensure that the parameter format meets the input requirements of the target microservice.

[0166] Data type conversion converts the data type of a call parameter to the data type required by the target microservice. For example, if the target microservice requires the input generator power data to be a floating-point number, but the generator power data obtained from the business process is an integer, data type conversion is required to convert the integer data into a floating-point number. Data type conversion can be implemented using simple type conversion functions or complex logic processing depending on the specific situation.

[0167] Field name mapping converts the field names of call parameters to the field names used by the target microservice. Different business systems and microservices may use different field names for the same data. For example, if a business process uses the "Generator Power" field, while the target microservice uses the "Input Power" field, field name mapping is required to map the "Generator Power" field to the "Input Power" field.

[0168] Microservice call parameters are processed according to the field mapping rules and data conversion functions in the data interaction format specification. During processing, data accuracy and integrity must be ensured to avoid data loss or errors. For example, for complex data structures containing multiple fields, each field must be processed separately to ensure that all fields are correctly converted and mapped.

[0169] By performing data type conversion and field name mapping on microservice call parameters, the success rate of microservice calls can be improved, ensuring that microservices can correctly process input data and providing guarantees for the collaborative execution of business processes.

[0170] Step S154: Add error handling logic for each microservice call instruction. The error handling logic includes a retry mechanism and an exception information capture rule. The retry mechanism is used to handle call failures, and the exception information capture rule is used to record exception information during the call process.

[0171] In the actual microservice call process, various errors may occur, such as network failure, microservice failure, input parameter error, etc. In order to ensure the stability and reliability of the business process, error handling logic needs to be added to each microservice call instruction.

[0172] Error handling logic includes a retry mechanism and exception information capture rules. The retry mechanism is used to handle call failures. When a microservice call fails, the retry mechanism retries according to preset rules. Retry rules can include the number of retries and the retry interval. For example, when a microservice call fails, set the number of retries to 3, with a 5-second interval between each retry. After the first call fails, wait 5 seconds before retrying again. If the second retry still fails, wait another 5 seconds before retrying again. If all three retries fail, the call is considered a failure, and further error handling is required.

[0173] Exception information capture rules are used to record exception information during the call process. When a microservice call exception occurs, the exception information capture rule captures the exception information, such as the exception type, exception message, the name of the called microservice, and the call parameters. This exception information helps developers and operations personnel quickly locate the problem, analyze the cause, and take appropriate remedial measures. Exception information can be recorded in log files or sent to the monitoring system via a message queue for timely processing.

[0174] When adding error handling logic to microservice call instructions, you need to customize it based on the specific microservice and business scenario. For some critical microservice calls, you may need to set up stricter retry mechanisms and detailed exception information capture rules; for some non-critical microservice calls, you can appropriately relax the requirements for retry times and exception information logging.

[0175] For example, in the "Power Generation Dispatch" scenario, the call to the "Power Generation Dispatch Instruction Issuance" microservice requires a high retry count and detailed exception information capture rules, as this operation directly affects the operation of power generation equipment and power supply. If a call fails, multiple retries are performed, and detailed exception information for each call is recorded, including the time the exception occurred, the exception type, and the call parameters, allowing for rapid troubleshooting and resolution.

[0176] Step S155: Encapsulate the processed microservice call instruction sequence with the business scenario label and timestamp information to generate a collaborative execution instruction with a unified format. The format of the collaborative execution instruction includes instruction header information, instruction body content and instruction check code. The instruction check code is used to verify the integrity and correctness of the collaborative execution instruction.

[0177] After completing the addition of error handling logic for the microservice call instructions, it is necessary to encapsulate the processed microservice call instruction sequence with the business scenario label and timestamp information to generate collaborative execution instructions with a unified format.

[0178] The instruction header contains basic information related to the instruction, such as the instruction version number, business scenario tag, and sender and receiver identifiers. The business scenario tag identifies the business scenario to which the instruction belongs, such as "power generation scheduling scenario" or "transmission fault repair scenario," allowing the recipient to process the instruction accordingly. The sender and receiver identifiers clarify the source and destination of the instruction, ensuring that the instruction is accurately transmitted to the target business system.

[0179] The instruction body is the core of collaborative execution instructions, containing the processed sequence of microservice call instructions. This sequence is arranged according to the execution order of the process nodes. Each instruction contains information such as the microservice's unique identifier, call parameters, execution time window, and error handling logic. The instruction body details the call sequence and requirements of each microservice in the business process and is key to achieving cross-system collaborative processing.

[0180] The instruction checksum is used to verify the integrity and correctness of collaboratively executed instructions. When encapsulating an instruction, a checksum is generated based on the instruction header and body. Upon receiving the instruction, the receiver can recalculate the checksum and compare it with the received checksum. If the two checksums match, the instruction has not been tampered with during transmission and is complete and correct. If they differ, there may be a problem with the instruction, requiring further inspection and processing.

[0181] Timestamp information records the time when the instruction was generated, ensuring the timeliness of the instruction. In business processes, some instructions may have strict time requirements, such as power generation scheduling instructions that need to be issued at a specific time. Timestamp information can help the recipient determine whether the instruction is within the valid time range and avoid executing outdated instructions.

[0182] By encapsulating the processed microservice call instruction sequence with business scenario tags and timestamp information, collaborative execution instructions with a unified format are generated, so that the instructions can be accurately and securely transmitted and executed between different business systems, realizing cross-system collaborative processing operations.

[0183] The generated collaborative execution instructions are sent to the target business system. Upon receiving the collaborative execution instructions, the target business system can perform appropriate processing based on the instructions' contents. First, the target business system verifies the instructions for integrity and correctness. If the verification passes, the corresponding microservices are called sequentially based on the business scenario tags and microservice call instruction sequence in the instructions to perform the corresponding business operations. During execution, possible errors can be handled according to the error handling logic in the instructions to ensure the smooth progress of the business process. Furthermore, the execution status of the instructions and related log information can be recorded for subsequent monitoring and analysis.

[0184] In summary, by acquiring an initial set of interaction data across business systems, analyzing its scenario characteristics, invoking a pre-built business collaboration analysis model for collaborative relevance analysis, determining business process adjustment plans, and generating and issuing collaborative execution instructions, we achieve cross-business system microservice processing for business scenario collaboration. This approach can improve the collaboration and efficiency between business systems, optimize business processes, and provide an effective solution for complex business scenarios such as the power sector.

[0185] Figure 2 A schematic diagram illustrates exemplary hardware and software components of a cross-business system microservice processing system 100 for business scenario collaboration, provided in some embodiments of the present application, that can implement the concepts of the present application. For example, the processor 120 can be used in the cross-business system microservice processing system 100 for business scenario collaboration and to perform the functions of the present application.

[0186] The cross-business system microservice processing system 100 for business scenario collaboration can be a general-purpose server or a special-purpose server, both of which can be used to implement the cross-business system microservice processing method for business scenario collaboration of this application. Although only one server is shown in this application, for convenience, the functions described in this application can be implemented in a distributed manner on multiple similar platforms to balance the processing load.

[0187] For example, the cross-business system microservice processing system 100 for business scenario collaboration may include a network port 110 connected to the network, one or more processors 120 for executing program instructions, a communication bus 130, and storage media 140 in different forms, such as a disk, ROM, or RAM, or any combination thereof. Exemplarily, the cross-business system microservice processing system 100 for business scenario collaboration may also include program instructions stored in ROM, RAM, or other types of non-transitory storage media, or any combination thereof. The method of the present application can be implemented according to these program instructions. The cross-business system microservice processing system 100 for business scenario collaboration also includes an I / O interface 150 between the computer and other input and output devices.

[0188] For ease of explanation, only one processor is described in the cross-business system microservice processing system 100 for business scenario collaboration. However, it should be noted that the cross-business system microservice processing system 100 for business scenario collaboration in this application may also include multiple processors, so the steps performed by one processor described in this application may also be performed jointly or individually by multiple processors. For example, if the processor of the cross-business system microservice processing system 100 for business scenario collaboration executes step A and step B, it should be understood that step A and step B may also be performed jointly by two different processors or individually in one processor. For example, the first processor executes step A, the second processor executes step B, or the first processor and the second processor execute steps A and B together.

[0189] In addition, an embodiment of the present invention also provides a readable storage medium, which has computer-executable instructions preset in the readable storage medium. When the processor executes the computer-executable instructions, the above-mentioned cross-business system microservice processing method for business scenario collaboration is implemented.

[0190] It should be noted that in order to simplify the description of the present invention and thus help understand one or more embodiments of the invention, in the foregoing description of the embodiments of the present invention, multiple features are sometimes combined into one embodiment, figure or description thereof.

Claims

1. A cross-business system microservice processing method for business scenario collaboration, characterized by: The method comprises: Acquire an initial interaction data set across business systems, the initial interaction data set comprising interaction data units with business scenario tags generated by multiple business systems within a preset time period; Performing scenario feature analysis on the initial interaction data set to obtain business scenario features and interaction behavior features corresponding to each interaction data unit, wherein the business scenario features include scenario function description information and scenario process node association relationships, and the interaction behavior features include interaction operation types and operation timing sequences; Calling a pre-built business collaboration analysis model to perform collaborative correlation analysis on the business scenario characteristics and the interaction behavior characteristics, and generating a collaborative processing strategy for each interactive data unit, the collaborative processing strategy including microservice call priority and data interaction format specification; Determine a business process adjustment plan for each business system in a target business scenario based on the collaborative processing strategy, wherein the business process adjustment plan includes a process node execution sequence and data transmission rules between nodes; A collaborative execution instruction including a microservice call instruction sequence is generated based on the business process adjustment plan, and the collaborative execution instruction is sent to the target business system to trigger a cross-system collaborative processing operation.

2. The cross-business system microservice processing method for business scenario collaboration according to claim 1 is characterized in that: The performing scenario feature analysis on the initial interaction data set to obtain business scenario features and interaction behavior features corresponding to each interaction data unit includes: Performing data format standardization on each interactive data unit in the initial interactive data set, unifying the naming rules and data type definitions of data fields, wherein the data fields include a business operation identification field, a data generation time field, and an associated system identification field; Extracting scenario identification information from the standardized interaction data unit, associating the scenario identification information with a preset business scenario knowledge base, and obtaining corresponding scenario function description information and scenario process node association relationships as business scenario features. The scenario identification information includes a business module name and an operation type combination code. Identify the operation instruction code in the interactive data unit, parse the interactive operation type according to the operation instruction code, and generate an operation timing sequence as an interactive behavior feature in the order of timestamps, wherein the operation instruction code includes a system interface call instruction and a data processing instruction; Performing dimensional unification processing on the business scenario features and interaction behavior features generated by different business systems to generate a scenario behavior feature set with the same feature dimension, wherein the dimensional unification processing includes feature field mapping and data type conversion; Based on the information entropy calculation results of each feature dimension in the scenario behavior feature set, the feature contribution parameters of the business scenario features and interactive behavior features in the collaborative correlation analysis are determined. The information entropy calculation results reflect the information richness and distribution uniformity of the feature dimensions.

3. The cross-business system microservice processing method for business scenario collaboration according to claim 2 is characterized in that: The extracting of the scenario identification information from the standardized interaction data unit, associating the scenario identification information with a preset business scenario knowledge base, and obtaining corresponding scenario function description information and scenario process node association relationships as business scenario features includes: Perform keyword extraction on the standardized interaction data unit to obtain a scenario keyword set containing the business module name and the description of the operation purpose. The business module name corresponds to the functional division of the specific business system; Matching the scenario keyword set with scenario identification tags in a preset business scenario knowledge base through a semantic similarity calculation algorithm to determine the target business scenario type to which the interaction data unit belongs, wherein the semantic similarity calculation algorithm is based on a word vector space distance metric; Extracting scenario function description information corresponding to the target business scenario type from the business scenario knowledge base, wherein the scenario function description information includes input data requirements and output result standards of the business process, wherein the input data requirements include data field integrity and format standardization requirements; Parse the business process diagram corresponding to the target business scenario type, extract the forward and backward dependencies and data transfer paths between scenario process nodes, and generate scenario process node association relationships. The scenario process node association relationships include node execution conditions and inter-node data mapping rules. The node execution conditions include the completion status of the predecessor node and the validity of the input data. The scenario function description information and the scenario process node association relationship are structured and integrated to generate a business scenario feature descriptor with a hierarchical structure, wherein the hierarchical structure includes a business process level, a node level and a data interaction level.

4. The cross-business system microservice processing method for business scenario collaboration according to claim 2 is characterized in that: The step of identifying the operation instruction code in the interaction data unit, parsing the interaction operation type according to the operation instruction code, and generating an operation timing sequence as an interaction behavior feature in a timestamp order includes: Performing syntax parsing on the operation instruction code in the interactive data unit, identifying the operation verbs and operation objects in the operation instruction code, and determining the interactive operation type according to the preset operation type classification rules. The interactive operation types include data query, data write, service call and process jump, and the operation verbs correspond to different interactive operation types; Extract the timestamp information of the interaction data unit, sort the interaction data units under the same business scenario according to the order of the timestamps, and generate a continuous operation sequence; Analyze the parameter transfer relationship between the operation instruction codes in adjacent operation sequences, determine the dependency relationship and execution order constraints between the operations, and generate an operation timing sequence containing dependency identifiers. The parameter transfer relationship includes the source of input parameters and the destination of output parameters. Performing time interval analysis on the operation timing sequence, calculating the time interval between adjacent operations, and generating a time interval feature vector reflecting the operation execution frequency and time distribution characteristics; The interaction operation type and the operation time sequence containing the dependency identifier are associated and integrated to generate a complete interaction behavior feature description set.

5. The cross-business system microservice processing method for business scenario collaboration according to claim 1 is characterized in that: The calling of the pre-built business collaboration analysis model to perform collaborative correlation analysis on the business scenario characteristics and the interaction behavior characteristics, and generating a collaborative processing strategy for each interaction data unit, includes: Inputting the business scenario features and interactive behavior features into the feature fusion network of the business collaboration analysis model, performing weighted fusion processing in combination with feature contribution parameters, and generating a fused feature vector containing scenario behavior association information, wherein the feature contribution parameters are determined based on the information entropy calculation result; Performing node relationship analysis and dependency evaluation on the fused feature vector using a business collaboration analysis model to identify process node interaction points of different business systems in target business scenarios; Based on the functional interface description and resource usage of the microservice, perform microservice call adaptability analysis on the process node interaction points to determine the microservice call priority corresponding to each process node interaction point. The microservice call adaptability analysis includes functional interface matching and performance stability evaluation; Generate a data interaction format specification containing field mapping rules and data validation logic based on the data format of the interaction data unit and the data processing requirements of the business scenario. The data interaction format specification includes the mapping relationship between the source system data structure and the target system data structure. The microservice call priority and data interaction format specification are grouped and integrated according to the business scenario label of the interaction data unit to generate a collaborative processing strategy set for each interaction data unit. The grouping and integration processing includes feature classification and rule encapsulation.

6. The cross-business system microservice processing method for business scenario collaboration according to claim 5 is characterized in that: The process node dependency mining process is performed on the fusion feature vector by using the business collaboration analysis model to identify the process node interaction points of different business systems in the target business scenario, including: Performing hierarchical decomposition of the scene process node associations to extract the input and output data parameters and execution conditions of each process node. The hierarchical decomposition includes process node level division and data parameter analysis. Analyze the matching of input and output data parameters between process nodes of different business systems, and identify node pairs whose data parameters are completely consistent or can be converted through preset conversion rules, which include data type conversion rules and field semantic mapping rules; Performing a compatibility analysis on the execution conditions of the node pair to determine whether there is an execution order dependency between the two nodes in the target business scenario, and generating a node dependency matrix including dependency types and dependency strengths, wherein the dependency types include data dependency and control dependency; Determine process node interaction points between process nodes of different business systems according to the node dependency matrix, wherein the process node interaction points include an initiating node and a receiving node of data interaction and corresponding interaction data fields, wherein the interaction data fields include business-critical information and data format descriptions; The process node interaction points are clustered based on the similarity of business meanings, and the process node interaction points are divided into data sharing interaction points and process collaboration interaction points according to the business meanings of the interaction data fields, and corresponding interaction point feature descriptors are generated respectively.

7. The cross-business system microservice processing method for business scenario collaboration according to claim 5 is characterized in that: The microservice call adaptability analysis is performed on the process node interaction points according to the functional interface description and resource occupancy of the microservice, and the microservice call priority corresponding to each process node interaction point is determined, including: Establish a microservice information knowledge base, which contains the functional interface description, service response time threshold and resource occupancy peak parameters of each microservice. The functional interface description includes input parameter requirements and output result format; For each process node interaction point, extract the data processing functions and data transmission requirements required by the process node interaction point, and match the candidate set of microservices with the same or similar functional interfaces in the microservice information knowledge base. The data processing functions include data conversion, data calculation, and data verification; Obtain historical call records for each microservice in the microservice candidate set, analyze its service response time and resource usage in different time periods, and generate microservice performance stability evaluation indicators; the historical call records include call time, input parameters, and response results; Calculate the adaptability score of each microservice candidate based on the functional interface matching degree and microservice performance stability evaluation index; The microservice candidate set is sorted in descending order of adaptability scores, and the microservice call priority corresponding to each process node interaction point is determined according to a preset priority division rule, wherein the priority division rule includes a correspondence between the score interval and the priority level.

8. The cross-business system microservice processing method for business scenario collaboration according to claim 1 is characterized in that: Determining the business process adjustment plan of each business system in the target business scenario according to the collaborative processing strategy includes: Analyze the collaborative processing strategy of each interactive data unit, extract the microservice call priority and data interaction format specifications, and classify and aggregate them according to business scenario tags. The classification and aggregation processing includes data statistics and rule integration; Analyze the execution order of process nodes corresponding to different microservice call priorities for the target business scenario, and determine the key process nodes corresponding to the microservices that need to be called first; According to the data exchange format specification, a data field mapping relationship table between different business systems is established. The data field mapping relationship table includes source system data fields, target system data fields and data conversion functions. The data conversion functions are used to realize conversion between different data formats. Based on the mapping relationship table between key process nodes and data fields, the existing business processes of each business system are reorganized, the execution order of process nodes is adjusted, and data conversion and verification links are inserted; Generate a business process adjustment plan document containing process node execution order adjustment records and data transfer rules between nodes. The business process adjustment plan document contains input and output data specifications and execution condition descriptions for each process node. The execution condition descriptions include the status of the preceding node and data validity check rules.

9. The cross-business system microservice processing method for business scenario collaboration according to claim 8 is characterized in that: The process node execution order corresponding to different microservice call priorities is analyzed for the target business scenario, and the key process nodes corresponding to the microservices that need to be called first are determined, including: Grouping all collaborative processing strategies in the target business scenario according to the microservice call priority, extracting the set of process nodes corresponding to the target priority microservice, where the adaptability score of the target priority microservice is higher than the preset priority threshold; Performing dependency analysis on the process node set, identifying the preceding nodes and the succeeding nodes therein, and constructing a dependency graph of the process nodes, wherein the dependency graph includes dependency relationships and data transfer paths between the process nodes; Finding a critical path from the process start point to the process end point in the dependency graph, and determining a process node on the critical path as a key process node. The critical path refers to the longest path that determines the execution time of the business process; Analyze the input and output data requirements of key process nodes to ensure that the data required by key process nodes can be effectively transmitted through existing data exchange format specifications. The input and output data requirements include data field integrity and format standardization requirements; Generate a list of key process nodes, which includes node names, node function descriptions, and execution priority rankings in target business scenarios. The execution priority rankings are determined based on critical path analysis results and microservice call priorities.

10. A cross-business system microservice processing system for business scenario collaboration, characterized by: The cross-business system microservice processing system for business scenario collaboration includes a processor and a memory, the memory is connected to the processor, the memory is used to store programs, instructions or codes, and the processor is used to execute the programs, instructions or codes in the memory to implement the cross-business system microservice processing method for business scenario collaboration as described in any one of claims 1 to 9 above.

Images