Business-scene-oriented cross-business-system micro-service processing method and system

Abstract

The application provides a cross-service system micro-service processing method and system facing business scene cooperation, first acquires an initial interaction data set with a business scene label within a preset time period of a cross-power business system, then performs scene feature analysis on the initial interaction data set to obtain power business scene features and interaction behavior features corresponding to each interaction data unit, then calls a pre-constructed business cooperation analysis model to perform cooperative correlation analysis on the features, generates a cooperative processing strategy containing micro-service call priority and data interaction format specification, determines a business process adjustment scheme of each business system under a target power business scene according to the cooperative processing strategy, and finally generates a cooperative execution instruction containing a micro-service call instruction sequence based on the business process adjustment scheme and sends it to the target business system to trigger cross-system cooperative processing operations, thereby effectively breaking down the barriers between power business systems, improving the cooperative processing efficiency and flexibility, and ensuring the reliability of power supply.

Description

Technical Field

[0001] This invention relates to the field of microservice optimization technology in the power business, and more specifically, to a cross-business system microservice processing method and system for business scenario collaboration. Background Technology

[0002] In the power industry's business operations, with the continuous advancement of smart grid construction and the deepening of power market reforms, power business scenarios are becoming increasingly complex and diverse, covering all aspects of power generation, transmission, substation, distribution, and consumption, and involving multiple different types of business systems, such as energy management systems (EMS), distribution management systems (DMS), power marketing systems, and equipment monitoring systems. These business systems are typically developed by different vendors, employing varying technical architectures, data models, and communication protocols, resulting in severe information silos between systems.

[0003] Currently, cross-system interactions in the power industry primarily rely on traditional interface-based methods. These methods lack a deep understanding and dynamic adaptability to complex power business scenarios. When facing dynamic business scenarios such as rapid changes in power load, large-scale integration of renewable energy sources, and emergency repairs of power equipment failures, traditional methods struggle to flexibly adjust cross-system collaboration strategies according to real-time business needs. For example, when a sudden fault occurs in a regional power grid, multiple systems, including energy management systems, distribution management systems, and equipment monitoring systems, need to collaborate rapidly to locate, isolate, and restore power supply. However, existing technologies often suffer from low collaboration efficiency, leading to prolonged fault handling times and impacting the reliability and stability of power supply. Therefore, there is an urgent need for a microservice processing method suitable for power business scenarios that enables efficient cross-system collaboration. Summary of the Invention

[0004] In view of the aforementioned problems, and in conjunction with the first aspect of the present invention, embodiments of the present invention provide a cross-business system microservice processing method for business scenario collaboration, the method comprising:

[0005] Obtain an initial interaction data set across business systems, the initial interaction data set containing interaction data units with business scenario tags generated by multiple business systems within a preset time period;

[0006] The initial interactive data set is subjected to scene feature parsing processing to obtain the business scene features and interactive behavior features corresponding to each interactive data unit. The business scene features include scene function description information and scene process node association relationship. The interactive behavior features include interactive operation type and operation time sequence.

[0007] The pre-built business collaboration analysis model is invoked to perform collaborative correlation analysis on the business scenario features and the interaction behavior features, and a collaborative processing strategy for each interactive data unit is generated. The collaborative processing strategy includes microservice call priority and data interaction format specification.

[0008] Based on the collaborative processing strategy, a business process adjustment plan for each business system is determined under the target business scenario. The business process adjustment plan includes the execution order of process nodes and the data transfer rules between nodes.

[0009] Based on the business process adjustment plan, a collaborative execution instruction containing a sequence of microservice call instructions is generated, and the collaborative execution instruction is sent to the target business system to trigger cross-system collaborative processing operations.

[0010] In another aspect, embodiments of the present invention also provide 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 code. The processor is used to execute the programs, instructions or code in the machine-readable storage medium to implement the above-mentioned method.

[0011] Based on the above, by acquiring the initial interaction data set across business systems, this approach comprehensively covers the interaction data generated in all stages of power business, including generation, transmission, transformation, distribution, and consumption. Scenario feature analysis of the initial interaction data set allows for the accurate extraction of power business scenario characteristics and interaction behavior characteristics corresponding to each interaction data unit. This leads to a deeper understanding of the functional requirements, process node relationships, and interaction operation patterns of power business scenarios. A pre-built business collaboration analysis model is invoked to perform collaborative correlation analysis, generating collaborative processing strategies for each interaction data unit. This achieves intelligent decision-making for cross-system collaboration in power business, dynamically adjusting microservice call priorities and data interaction format specifications according to different power business scenarios and interaction behaviors, improving the targeting and effectiveness of collaborative processing. Based on the collaborative processing strategy, business process adjustment schemes for each business system under the target power business scenario are determined, and collaborative execution instructions are generated to trigger cross-system collaborative processing operations. This enables each power business system to work collaboratively according to optimized processes and rules, effectively breaking down system barriers and significantly improving the efficiency, flexibility, and accuracy of cross-power business system collaborative processing. This better adapts to the dynamic changes in power business scenarios, ensuring the reliability and stability of power supply. Attached Figure Description

[0012] Figure 1 This is a schematic diagram of the execution flow of the cross-business system microservice processing method for business scenario collaboration provided in the embodiments of the present invention.

[0013] Figure 2 This is a schematic diagram of exemplary hardware and software components of a cross-business system microservice processing system for business scenario collaboration provided in an embodiment of the present invention. Detailed Implementation

[0014] The present invention will now be described in detail with reference to the accompanying drawings. Figure 1 This is a flowchart illustrating a cross-business system microservice processing method for business scenario collaboration provided by an embodiment of the present invention. The following is a detailed description of this cross-business system microservice processing method for business scenario collaboration.

[0015] Step S110: Obtain an initial interaction data set across business systems, wherein the initial interaction data set contains interaction data units with business scenario tags generated by multiple business systems within a preset time period.

[0016] In the power business scenario, multiple different business systems work together, such as power generation systems, transmission systems, distribution systems, and electricity service systems. A preset time period can be set to a specific time interval during which the various business systems continuously interact, generating a large amount of data.

[0017] The power generation system is primarily responsible for electricity production. Its interactive data can include generator start-up and shutdown operations, power generation adjustments at different times, and maintenance records of power generation equipment. For example, when the power grid's demand changes, the power generation system needs to adjust the generator's output power according to dispatch instructions; all of these operations will generate corresponding interactive data.

[0018] The power 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 parameters such as current, voltage, and power of transmission lines, 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 can be recorded, and the corresponding fault handling procedures can be initiated.

[0019] The power distribution system distributes electricity from the transmission system to various users. Its interactive data includes the operating status of distribution transformers, the load status of each distribution line, and records of power outages and restorations for users. For example, during peak electricity consumption periods, the distribution system needs to rationally allocate power according to the load conditions of different areas to ensure a stable power supply, generating a large amount of interactive data in this process.

[0020] The electricity service system is primarily responsible for interacting with users and processing their electricity applications, payments, and fault reports. Its interactive data includes basic user information, electricity contract information, payment records, and repair work orders. For example, after a user submits an electricity application, the system can record the application time, the requested electricity capacity, and other information, and process the application according to the established workflow.

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

[0022] Step S120: Perform scene feature parsing processing on the initial interaction data set to obtain the business scene features and interaction behavior features corresponding to each interaction data unit. The business scene features include scene function description information and scene process node associations. The interaction behavior features include interaction operation type and operation timing sequence.

[0023] Step S121: Perform data format standardization processing on each interactive data unit in the initial interactive data set, and unify the naming rules and data type definitions of the data fields. The data fields include business operation identifier field, data generation time field and associated system identifier field.

[0024] Different power business systems may use different data formats to record interactive data. For example, a generation system may use one set encoding method to represent generator operation, while a transmission system may use another encoding method. To facilitate subsequent processing and analysis, it is necessary to standardize the format of these interactive data.

[0025] For the business operation identification field, different systems may use different names to represent the same business operation. 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, uniform name, such as "business operation identification field," and the value of this field must be unique to accurately identify each business operation.

[0026] The time field of the data also needs to be formatted uniformly. 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 single time format, such as "year-month-day hour:minute:second", which will facilitate the sorting and analysis of the data in chronological order.

[0027] The associated system identifier field indicates which system generated the interactive data and with which other systems it interacted. Different systems may use different identifiers, such as system name or system number. These identifiers need to be standardized to clearly define the source and destination of each interactive data unit. For example, a unique system number can be used to represent the associated system, thereby avoiding confusion caused by differences in system names.

[0028] Data format standardization can be achieved using data transformation tools or by writing custom scripts. First, the data structure of each data source needs to be analyzed to determine the fields requiring standardization and the corresponding transformation rules. Then, the data is transformed and cleaned according to these rules to ensure consistency and accuracy.

[0029] Step S122: Extract scene identification information from the standardized interactive data unit, associate the scene identification information with a preset business scenario knowledge base, and obtain the corresponding scene function description information and scene process node association relationship as business scenario features. The scene identification information includes the business module name and operation type combination code.

[0030] Step S1221: Perform keyword extraction processing on the standardized interactive data units to obtain a set of scenario keywords containing business module names and operation purpose descriptions, wherein the business module names correspond to the functional division of specific business systems.

[0031] In power business scenarios, natural language processing (NLP) technology is used to extract keywords from standardized interactive data units. For interactive data from power generation systems, possible extracted keywords include "generator," "startup," "power adjustment," and "power generation plan." Among these, "generator" corresponds to the business module name of the power generation system, while "startup," "power adjustment," and "power generation plan" describe the purpose of the operation.

[0032] For interactive data in power transmission systems, keywords may include "transmission line," "fault detection," "load allocation," and "line maintenance." "Transmission line" is the name of the business module in the power transmission system, while "fault detection," "load allocation," and "line maintenance" describe the purpose of the operation.

[0033] For interactive data in a power distribution system, keywords can include "distribution transformer," "load monitoring," "power outage restoration," and "power distribution optimization." "Distribution transformer" is the name of the business module in the power distribution system, while "load monitoring," "power outage restoration," and "power distribution optimization" describe the purpose of the operation.

[0034] For interactive data in the electricity service system, keywords may include "user," "electricity application," "payment," and "fault reporting." "User" is the name of the business module in the electricity service system, while "electricity application," "payment," and "fault reporting" describe the purpose of the operation.

[0035] By extracting the keywords mentioned above, we can make a preliminary judgment on the business module and operation type to which the interactive data belongs.

[0036] Step S1222: Match the set of scene keywords with scene identifier tags in the preset business scene knowledge base using a semantic similarity calculation algorithm to determine the target business scene type to which the interactive data unit belongs. The semantic similarity calculation algorithm is based on word vector space distance measurement.

[0037] The pre-defined business scenario knowledge base stores identification tags for various power business scenarios, as well as feature descriptions and business rules related to these tags. For example, the identification tag for "generation dispatching scenario" may be associated with feature descriptions such as "adjusting generator power according to grid load demand" and "formulating generation plans"; the identification tag for "transmission line fault repair scenario" may be associated with feature descriptions such as "detecting transmission line faults", "isolating faulty lines", and "restoring power supply".

[0038] The extracted set of scenario keywords is converted into word vectors, which are then compared with the word vectors of scenario identifiers in the business scenario knowledge base. Semantic similarity calculation algorithms are based on word vector spatial distance metrics, with common methods such as cosine similarity. Cosine similarity measures the similarity between two word vectors by calculating the cosine of the angle between them; the closer the cosine value is to 1, the more similar the two vectors are.

[0039] For a set of scenario keywords containing terms such as "generator," "power adjustment," and "power generation plan," these keywords are converted into word vectors and then their cosine similarity is calculated with the word vectors of various scenario identifiers in the business scenario knowledge base. If the word vector has the highest similarity with the word vector of "power generation dispatch scenario," then the target business scenario type to which this interactive data unit belongs is determined to be "power generation dispatch scenario."

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

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

[0042] 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 dispatch scenario" as an example, its scenario function description information is as follows:

[0043] Regarding input data requirements, relevant data from the power generation system needs to be collected, including real-time generator status information such as generator operating status (start-up, shutdown, running), current generator power output, and adjustable power range; grid load demand information such as predicted load and real-time load for each time period; and relevant information about the power generation plan, such as established power generation plans and adjustment rules. These data fields need to be complete and formatted correctly. For example, generator power output needs to be expressed in a defined unit (e.g., megawatts) and with specified precision, and time information needs to use a uniform time format.

[0044] Regarding output standards, the outputs of a power generation dispatch scenario include the generation of power generation dispatch instructions, which need to clearly indicate the power adjustment target and adjustment time for each generator; the adjustment scheme for the power generation plan, including the adjusted power allocation and power generation schedule; and feedback information on dispatch results, such as the execution status of dispatch instructions and the effect of power generation plan adjustments. These outputs need to meet the set format and content requirements to ensure that they can be correctly understood and executed by the relevant business systems.

[0045] For the "transmission line fault repair scenario," the input data requirements include real-time parameter monitoring data of the transmission line, such as current, voltage, and power; fault alarm information, such as the time, location, and type of the fault; and the topology information of the transmission line. The output results standards include a fault diagnosis report, clearly stating the specific location and cause of the fault; a fault handling plan, including the operational steps for isolating the faulty line and the sequence of power restoration; and a record of the fault handling time and an evaluation of its effectiveness.

[0046] Step S1224: Analyze the business process diagram corresponding to the target business scenario type, extract the dependencies and data transmission paths between scenario process nodes, and generate scenario process node associations. The scenario process node associations include node execution conditions and data mapping rules between nodes. The node execution conditions include the completion status of the preceding node and the validity of the input data.

[0047] For each target business scenario type, the corresponding business process diagram describes the execution steps and sequence of the business processes within that scenario. Taking the business process diagram for the "power generation dispatch scenario" as an example, process nodes may include "collecting power generation data," "analyzing grid load demand," "formulating power generation dispatch plans," "issuing power generation dispatch instructions," "executing power generation dispatch instructions," and "feedback of dispatch results," etc.

[0048] The "Collect Generation Data" node is a prerequisite for subsequent nodes. The "Analyze Grid Load Demand" node can only proceed after this node completes its task and the collected data is valid. The data transmission 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 Generation Data" node will be transmitted to the "Analyze Grid Load Demand" node for processing.

[0049] Node execution conditions include the completion status of preceding nodes and the validity of input data. For example, the execution condition for the "Formulate Generation Dispatch Plan" node is that the "Analyze Grid Load Demand" node has been completed, and the input load analysis results are valid. Data mapping rules between nodes define the conversion and correspondence between data from different nodes. For instance, the load forecast data output by the "Analyze Grid Load Demand" node needs to be converted into input data usable by the "Formulate Generation Dispatch Plan" node according to set rules, such as converting the load forecast data into generator power adjustment requirements.

[0050] For a "transmission line fault repair scenario," the business process diagram nodes can include "detecting transmission line faults," "locating fault locations," "isolating faulty lines," "repairing faulty lines," and "restoring power supply." The "detecting transmission line faults" node is a prerequisite for subsequent nodes; the "locating fault locations" node can only proceed after a fault is detected and its type determined. Data transfer paths between nodes include fault detection data being transferred from the detection node to the location node, and location results being transferred 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 operation of the fault repair process.

[0051] Step S1225: The scenario function description information and the scenario process node association relationship are structurally integrated to generate a business scenario feature descriptor with a hierarchical structure, which includes a business process level, a node level and a data interaction level.

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

[0053] At the business process level, the overall goals and functions of the entire business process are described. For example, the overall goal of the "power generation dispatch scenario" is to rationally allocate power generation resources according to grid load demand to meet the stability and economic requirements of 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, dispatch scheme formulation, instruction issuance and execution, etc.

[0054] At the node level, each process node is described in detail, including its function, execution conditions, and input / output data. For example, the "Collect Generation Data" node collects relevant data from generators and load demand information from the power grid; its execution conditions are normal system operation and normal operation of data acquisition equipment; its input data consists of real-time monitoring data from generators and load forecast data from the power grid; and its output data consists of processed generation and load data. The description of each node also includes its dependencies on other nodes and data transmission paths.

[0055] At the data interaction level, the rules for data transfer and mapping between different nodes are described, as well as the data format and quality requirements. For example, the data transfer path between the "analyze grid load demand" node and the "formulate generation dispatch plan" node indicates how the load analysis results are transmitted to the dispatch plan formulation node; the data mapping rules define how to convert the load analysis results into the input data required for dispatch plan formulation; the data format requirements specify that the transmitted data must adopt a set format, such as numerical type, text type, etc.; and the data quality requirements specify the accuracy, completeness, and timeliness requirements of the data.

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

[0057] 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 according to the timestamp order. The operation instruction code includes system interface call instructions and data processing instructions.

[0058] 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 type includes data query, data writing, service call and process jump, and the operation verbs correspond to different interactive operation types.

[0059] In power business scenarios, the operation instruction codes in interactive data units may employ complex encoding methods, requiring detailed syntax parsing. For example, an 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]".

[0060] 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".

[0061] In practical applications, operation instruction codes may contain multiple nested operations and complex parameter structures. For example, an operation instruction code "CALL_SERVICE(UPDATE_GENERATOR_STATUS,PARAMS=[GENERATOR_ID=123,STATUS=RUNNING,CALLBACK=CALL_SERVICE(GET_GENERATOR_POWER,PARAMS=[GENERATOR_ID=123]))" needs to be recursively parsed to identify multiple operation verbs and operation objects, and to determine the interaction type of each operation.

[0062] Step S1232: Extract the timestamp information of the interactive data units, sort the interactive data units in the same business scenario according to the order of the timestamps, and generate a continuous operation sequence.

[0063] 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 respectively recording operation instructions at different times, as follows:

[0064] Interaction data unit 1: The timestamp is T1, and the operation instruction code is "CALL_SERVICE(GET_GENERATOR_STATUS,PARAMS=[GENERATOR_ID=123])"

[0065] 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])"

[0066] Interaction data unit 3: The timestamp is T3, and the operation instruction code is "CALL_SERVICE(GET_GENERATOR_POWER,PARAMS=[GENERATOR_ID=123])"

[0067] Assuming T1 < T2 < T3, after sorting by timestamp, the generated consecutive operation sequence is:

[0068] 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])"

[0069] The above operation sequence reflects the execution order of operations in this business scenario.

[0070] 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 including dependency relationship identifiers. The parameter passing relationship includes the source of input parameters and the destination of output parameters.

[0071] In a continuous sequence of operations, the parameter passing relationships between adjacent operation instruction codes are analyzed. For example, in the above operation sequence, the output of "CALL_SERVICE(GET_GENERATOR_STATUS,PARAMS=[GENERATOR_ID=123])" might be used as the input parameter for "CALL_SERVICE(UPDATE_GENERATOR_STATUS,PARAMS=[GENERATOR_ID=123,STATUS=RUNNING])". Specifically, the generator status information returned by the "GET_GENERATOR_STATUS" service call might be used to determine whether the generator status can be updated to "RUNNING".

[0072] By analyzing the parameter passing relationships described above, the dependencies between operations and execution order constraints can be determined. If the operation "CALL_SERVICE(UPDATE_GENERATOR_STATUS,PARAMS=[GENERATOR_ID=123,STATUS=RUNNING])" depends on the result of the operation "CALL_SERVICE(GET_GENERATOR_STATUS,PARAMS=[GENERATOR_ID=123])", then the operation "CALL_SERVICE(GET_GENERATOR_STATUS,PARAMS=[GENERATOR_ID=123])" must be executed first. Add dependencies for each operation. The identifier generates an operation sequence containing dependency identifiers, effectively representing the order and dependencies between operations. For example, in the operation sequence, the operation "CALL_SERVICE(GET_GENERATOR_STATUS,PARAMS=[GENERATOR_ID=123])" can be labeled as operation 1, and the operation "CALL_SERVICE(UPDATE_GENERATOR_STATUS,PARAMS=[GENERATOR_ID=123,STATUS=RUNNING])" can be labeled as operation 2, and the description of operation 2 indicates that it depends on the result of operation 1.

[0073] Step S1234: Perform time interval analysis on the operation time sequence, calculate the time interval between adjacent operations, and generate a time interval feature vector that reflects the operation execution frequency and time distribution characteristics.

[0074] 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.

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

[0076] By statistically analyzing the duration of these time intervals, we can obtain the frequency and temporal distribution characteristics of operation execution. For example, if the time interval between adjacent operations is short, it indicates a high frequency of operation execution; if the time interval fluctuates significantly, it indicates an unstable temporal distribution of operation execution. These characteristics can be represented as a time interval feature vector, which contains relevant information about the frequency and temporal distribution of operation execution, such as the average time interval of operation execution and the range of time interval fluctuations.

[0077] 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 dispatching 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.

[0078] Step S1235: Associate and integrate the interaction operation type and the operation sequence containing dependency identifiers to generate a complete set of interaction behavior feature descriptions.

[0079] The identified interaction operation types are associated and integrated with the operation sequence containing dependency identifiers. For each operation in the operation sequence, its corresponding interaction operation type is associated with it. For example, the interaction operation type of the operation "CALL_SERVICE(GET_GENERATOR_STATUS,PARAMS=[GENERATOR_ID=123])" is "service call", and this information is associated with the operation's position and dependencies in the operation sequence.

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

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

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

[0083] 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 the generator's power, temperature, and speed; while the business scenario characteristics of a power transmission system may focus on the state parameters of the transmission line, such as the transmission line's current, voltage, and power factor. The representation and data types of these characteristics may differ across different systems, requiring dimensional standardization.

[0084] Feature field mapping maps fields representing the same or similar features across different systems. For example, the "generator power" field in a power generation system and the "transmission power" field in a power transmission system, although different in name, are both related to power and can be mapped to ensure consistency in dimensionality. When performing feature field mapping, the semantics and business implications of the fields must be considered to ensure the accuracy of the mapping.

[0085] Data type conversion ensures that data types with the same characteristics are consistent across different systems. For example, generator power data in a power generation system is represented as integers, while transmission power data in a 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 guarantee data type consistency.

[0086] When performing dimensional unification, data dictionaries and mapping rules can be used. The data dictionary records the definitions and meanings of various feature fields from different systems, while the mapping rules specify how to map feature fields and convert data types. By applying the data dictionary and mapping rules, business scenario features and interaction behavior features generated by different business systems can be processed to generate a set of scenario behavior features with the same feature dimensions.

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

[0088] Information entropy is a metric used to measure the uncertainty and richness of information. For each feature dimension in the set of scene behavior features, its information entropy is calculated. The calculation process 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 uniform, it indicates that the information richness of that feature dimension is low, and the information entropy is small; 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 large.

[0089] Taking the "generator power" feature dimension in a power generation system as an example, if the generator power value is concentrated in a relatively small range over a period of time, it indicates that the data distribution of this feature dimension is relatively uniform and the information entropy is small; if the generator power value fluctuates greatly and covers a wide range, it indicates that the data distribution of this feature dimension is uneven and the information entropy is large.

[0090] Based on the information entropy calculation results, the feature contribution parameters of business scenario features and interaction behavior features in collaborative correlation analysis are determined. For feature dimensions with higher information entropy, they may have a higher feature contribution in collaborative correlation analysis because they contain more useful information and can better reflect the characteristics of business scenarios and interaction behaviors; while for feature dimensions with lower information entropy, their feature contribution may be relatively lower.

[0091] When determining feature contribution parameters, a normalization method can be used to convert the information entropy value into a feature contribution parameter within a set range, ensuring the comparability of contribution parameters for each feature dimension. By assigning a reasonable feature contribution parameter to each feature dimension in this way, the importance of different features can be considered more accurately in subsequent synergistic correlation analysis.

[0092] Step S130: Invoke the pre-built business collaboration analysis model to perform collaborative correlation analysis on the business scenario features and the interaction behavior features, and generate a collaborative processing strategy for each interactive data unit. The collaborative processing strategy includes microservice call priority and data interaction format specification.

[0093] Step S131: Input the business scenario features and interaction behavior features into the feature fusion network of the business collaboration analysis model, and perform weighted fusion processing in combination with the feature contribution parameter to generate a fusion feature vector containing scenario behavior association information. The feature contribution parameter is determined based on the information entropy calculation result.

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

[0095] During the fusion process, a weighted fusion process is performed based on the previously determined feature contribution parameters. Feature dimensions with higher contribution are assigned larger weights, while feature dimensions with lower contribution are assigned smaller weights. For example, in business scenario features, the "generator power" feature dimension has a high feature contribution, so its weight is relatively large during weighted fusion; while in interaction behavior features, the feature dimension of a less important operation has a low feature contribution, so its weight is relatively small.

[0096] Through weighted fusion processing, business scenario features and interaction behavior features are combined into a fused feature vector that includes information related to scenario behavior. This fused feature vector integrates information from business scenarios and interaction behaviors, and can better reflect the collaborative relationships between different business systems. For example, the fused feature vector may contain information related to the relationship between generator operating status and business operations, as well as information related to the relationship between transmission line status and interaction processes.

[0097] Step S132: The fusion feature vector is analyzed for node relationships and evaluated for dependencies using a business collaboration analysis model to identify the process node interaction points of different business systems in the target business scenario.

[0098] The business collaboration analysis model analyzes node relationships and evaluates dependencies in the fused feature vectors. In the power business scenario, there are complex relationships and dependencies between process nodes of different business systems. For example, the "generator power adjustment" node of the generation system may interact with the "transmission line load allocation" node of the transmission system, because the adjustment of generator power will affect the load of the transmission line.

[0099] The model identifies process node interaction points between different business systems in a target business scenario by analyzing the fused feature vectors. 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 might serve as the input data for the "transmission line load allocation" node, thus forming an interaction point.

[0100] Dependency assessment determines the execution order and dependencies between nodes. For example, the execution of the "transmission line load allocation" node may depend on the completion of the "generator power adjustment" node and requires valid generator power adjustment data. Through this assessment, the model can accurately identify the interaction points between process nodes in different business systems.

[0101] Step S133: Based on the functional interface description and resource usage of the microservices, perform microservice call adaptability analysis on the interaction points of the process nodes 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.

[0102] Establish a microservice information knowledge base, which includes information such as the functional interface description, service response time threshold, and peak resource consumption parameters for each microservice. The functional interface description details the input parameter requirements, output result format, and service functions provided by the microservice. For example, a microservice for generator power calculation might have a functional interface description that includes real-time generator operating data as input parameters, the calculated generator power value as output, and the service function of calculating power based on the input data.

[0103] For each process node interaction point, extract the data processing functions and data transmission requirements needed for that interaction point. For example, the "generator power adjustment" process node interaction point may require power calculation and adjustment control, as well as transmitting the adjusted power data to the relevant system.

[0104] The system matches a candidate set of microservices with the same or similar functional interfaces within the microservice information knowledge base. Based on the data processing functions and data transmission requirements of the process node interaction points, it selects microservices that can meet these requirements. For example, if a process node interaction point needs to perform generator power calculation, then the system searches the microservice information knowledge base for microservices with power calculation capabilities as a candidate set.

[0105] The system retrieves historical call records for each microservice in the candidate microservice set, analyzes its service response time and resource consumption over different time periods, and generates microservice performance stability evaluation metrics. Service response time reflects the speed at which a microservice processes requests, while resource consumption reflects how well a microservice uses system resources during operation. By statistically analyzing the average response time, the range of response time fluctuations, and the peak and average resource consumption of each microservice, the system assesses its performance stability.

[0106] Based on functional interface matching and microservice performance stability evaluation metrics, an adaptability score is calculated for each microservice candidate. Higher functional interface matching and better performance stability result in a higher adaptability score. The microservice candidate set is sorted from highest to lowest adaptability score, and the microservice call priority for each process node interaction point is determined according to a preset priority division rule. For example, the microservice with the highest adaptability score has the highest call priority, and this microservice is selected first when a process node interaction point needs to call a microservice.

[0107] Step S134: Based on the data format of the interactive data unit and the data processing requirements of the business scenario, generate a data interaction format specification that includes field mapping rules and data verification logic. The data interaction format specification includes the mapping relationship between the source system data structure and the target system data structure.

[0108] Based on the data format of the interactive data units and the data processing requirements of the business scenario, a data interaction format specification is generated. In the power business scenario, the data formats of different business systems may differ; for example, the data format of the power generation system may differ from that of the power consumption service system.

[0109] Field mapping rules define the correspondence between data structures in the source system and data structures in the target system. For example, the "generator number" field in the power generation system needs to be mapped to the "associated power generation equipment number" field in the electricity service system. When formulating field mapping rules, the semantics and business implications of the fields need to be considered to ensure the accuracy of the mapping.

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

[0111] By generating data interaction format specifications, different business systems can accurately exchange data, avoiding errors in data transmission and processing. These specifications serve as standards for data interaction, guiding data transmission and processing operations between different systems.

[0112] Step S135: The microservice call priority and data interaction format specifications are grouped and integrated according to the business scenario tags of the interaction data units to generate a set of collaborative processing strategies for each interaction data unit. The grouping and integration process includes feature classification and rule encapsulation.

[0113] The determined microservice call priorities and data interaction format specifications are grouped according to the business scenario labels of the interactive data units. For example, for interactive data units under the "power generation dispatch scenario", the related microservice call priorities and data interaction format specifications are grouped into one group; for interactive data units under the "transmission fault repair scenario", the corresponding microservice call priorities and data interaction format specifications are grouped into another group.

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

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

[0116] Step S140: Determine the business process adjustment plan for each business system under the target business scenario based on the collaborative processing strategy. The business process adjustment plan includes the execution order of process nodes and the data transfer rules between nodes.

[0117] Step S141: Analyze the collaborative processing strategy of each interactive data unit, extract the microservice call priority and data interaction format specifications, and classify and summarize them according to business scenario tags. The classification and summary processing includes data statistics and rule integration.

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

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

[0120] For data interaction format specifications, rules are integrated. Data interaction format specifications under the same business scenario are merged and unified to eliminate conflicts and inconsistencies between rules. For example, for the data interaction format specifications of different interactive data units under the "power generation dispatch scenario", the field mapping rules and data validation logic are integrated to form a unified data interaction format specification.

[0121] By classifying and summarizing the data, we can obtain statistical information on the microservice call priority and a unified data interaction format specification for each business scenario.

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

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

[0124] 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 an adaptability score higher than this threshold are defined as target priority microservices.

[0125] From the grouped collaborative processing strategy, extract the set of process nodes corresponding to the target priority microservice. These process nodes are associated with the target priority microservice and play an important role in the business process. For example, in the "power generation scheduling scenario", the target priority microservice may be a microservice used for generator power calculation and scheduling, and the corresponding process nodes may include "generator power data collection" and "power generation scheduling scheme formulation", etc.

[0126] Step S1422: Perform dependency analysis on the set of process nodes, identify the predecessor and successor nodes, and construct a dependency graph of the process nodes. The dependency graph includes the dependency relationships and data transmission paths between process nodes.

[0127] Dependency analysis is performed on the extracted set of process nodes. By analyzing the input-output relationships and business logic between nodes, it is determined which nodes are prerequisites and which are successors. For example, the "generator power data collection" node is a prerequisite node for the "generation dispatch plan formulation" node, because a reasonable generation dispatch plan can only be formulated after accurate generator power data is collected.

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

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

[0130] In the constructed process node dependency graph, it is necessary to find the critical path from the start to the end of the process. The critical path is the longest path in the entire business process, which determines the total execution time of the business process. The process of finding the critical path can be achieved by traversing and analyzing all possible paths in the dependency graph.

[0131] Starting from the beginning of the process, traverse each node sequentially along the edges of the dependency graph, recording the nodes traversed and the time required for each path. For each path, sum the execution times of each node on the path to obtain the total time for that path. By comparing the total times of all paths, find the longest path, which is the critical path.

[0132] In the "power generation dispatch scenario," the process starts at the "generator power data collection" node and ends at the "power generation dispatch instruction execution completion" node. Multiple paths may connect these two nodes. For example, path 1 could be "generator power data collection -> power generation demand analysis -> power generation dispatch scheme formulation -> power generation dispatch instruction issuance -> power generation dispatch instruction execution completion"; path 2 could be "generator power data collection -> generator status assessment -> power generation dispatch scheme formulation -> power generation dispatch instruction issuance -> power generation dispatch instruction execution completion".

[0133] Time analysis is performed on these two paths, calculating the total execution time of each node on each path. Assuming path 1 has the longer total time, then path 1 is the critical path. The process nodes on the critical path, such as "generator power data collection," "power generation demand analysis," "power generation dispatch plan formulation," "power generation dispatch instruction issuance," and "power generation dispatch instruction execution completion," are critical process nodes. The execution status of these nodes directly affects the execution time and efficiency of the entire business process, and therefore requires close attention during business process adjustments.

[0134] 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 specification requirements.

[0135] After identifying the key process nodes, it is necessary to analyze the input and output data requirements of these nodes in detail. For each key process node, the required input data and the generated output data should be clearly defined. Taking the "power generation dispatch scheme formulation" node as an example, its input data may include real-time power data of generators, power generation demand forecast data, and the adjustable power range of generators; the output data may be the formulated power generation dispatch scheme, including the power allocation of each generator and the power generation time arrangement.

[0136] These input and output data must meet the set requirements for data field integrity and format standardization. Data field integrity requires that the input data must contain all necessary fields. For example, power generation demand forecast data must include information such as the forecast load value for each time period and the load growth trend. Format standardization requires that the data representation conforms to the set specifications. For example, generator power data must be represented in the set units and precision.

[0137] Based on 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 validation logic to ensure accurate data exchange between different business systems. For example, in the "Power Generation Dispatch Scheme 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 dispatch scheme formulation module. By using the field mapping rules in the data interaction format specifications, the generator power data fields from the power generation system are mapped to the fields required by the dispatch scheme formulation module. Simultaneously, data validation logic verifies the data to ensure its accuracy and integrity.

[0138] If it is found that the input and output data requirements of key process nodes do not match the existing data interaction format specifications, the data interaction format specifications need to be adjusted and optimized, or the input and output data of key process nodes need to be preprocessed to ensure that the data can be effectively transmitted.

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

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

[0141] The node name clearly identifies the node within the business process, such as "Generator Power Data Collection" or "Generation Dispatch Scheme Formulation." The node function description details the specific functions and roles of the node. For example, the "Generator Power Data Collection" node collects real-time power data and operating status information of generators; the "Generation Dispatch Scheme Formulation" node formulates a reasonable generation dispatch scheme based on the input generation demand and generator status information.

[0142] Execution priority ranking is determined based on critical path analysis results and microservice call priorities. Nodes on the critical path typically have higher execution priorities because they significantly impact the execution time of business processes. Simultaneously, nodes associated with high-priority microservices also have higher execution priorities. For example, in the "power generation scheduling scenario," the "power generation scheduling plan formulation" node is located on the critical path and is associated with a high-priority microservice, therefore it has a high execution priority in the list of critical process nodes.

[0143] The above information is compiled into a list of key process nodes. This list can identify which nodes are the key links in the business process, as well as the execution order and importance of these nodes, thereby enabling targeted optimization and adjustment of the business process.

[0144] Step S143: According to the data interaction format specification, establish a data field mapping relationship table between different business systems. 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 the conversion between different data formats.

[0145] Based on existing data interaction format specifications, a data field mapping 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 consumption service systems, may have different data fields, requiring a data field mapping table to achieve effective data interaction.

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

[0147] Determining the correspondence between data fields in the source and target systems requires in-depth analysis of the data structures and business logic of different business systems. For example, when data exchange occurs between a power generation system and a transmission system, the "power generation" field in the power generation system corresponds to the "received power generation" field in the transmission system. After determining the correspondence, an appropriate data conversion function needs to be selected based on the actual data conditions. If the data types of the source and target systems are different, data type conversion is required; if the data representation methods are different, such as different date formats or units, corresponding conversion operations are necessary.

[0148] Data conversion functions can range from simple mathematical operations, such as unit conversions, to complex logical processing, such as data cleaning and format conversion. For example, generator power data in a power generation system, measured in kilowatts, needs to be converted to megawatts for transmission. In this case, a simple division operation can be used as the data conversion function. For data containing special characters or with irregular formats, more complex string processing functions may need to be written for cleaning and conversion.

[0149] By establishing a data field mapping table, it can be ensured that data between different business systems can be exchanged accurately and efficiently.

[0150] Step S144: Based on the mapping relationship table between key process nodes and data fields, reorganize the existing business processes of each business system, adjust the execution order of process nodes, and insert data conversion and verification steps.

[0151] After identifying key process nodes and establishing data field mapping tables, it is necessary to restructure the existing business processes of each business system. The purpose of business process reengineering is to optimize business processes, improve business execution efficiency and collaboration, and ensure that key process nodes can be executed smoothly and data can be transmitted accurately.

[0152] First, adjust the execution order of process nodes based on their execution priority. Place key process nodes in critical positions within the business process to ensure they are executed first. For example, in the "power generation scheduling scenario," adjust the "power generation scheduling plan formulation" node to a suitable position so that it can be executed promptly after obtaining accurate input data.

[0153] Secondly, based on the data field mapping table, data transformation and validation steps are inserted into the business process. During the data transmission from the source system to the target system, data transformation is required to meet the target system's requirements. Data transformation functions are inserted at the input and output points of key process nodes to ensure that the data format and content meet the requirements. For example, a data transformation step is inserted between the "Generator Power Data Collection" node and the "Generation Dispatch Scheme Formulation" node to transform the collected generator power data according to the data field mapping table, enabling it to be correctly processed by the dispatch scheme formulation module.

[0154] Meanwhile, to ensure data accuracy and integrity, a data validation step needs to be inserted into the business process. This step checks the validity of input data, such as whether data fields are complete, whether the data format is standardized, and whether data values ​​are within a reasonable range. If data validation fails, error handling can be implemented promptly, such as returning error messages or re-acquiring data. For example, inserting a data validation step before the "Power Generation Dispatch Instruction Issuance" node verifies the power generation dispatch plan, ensuring that the power allocation and timing arrangements in the plan are reasonable and effective.

[0155] By reengineering business processes, the business processes of each business system become more rational and efficient, and better able to adapt to the needs of business collaboration.

[0156] Step S145: Generate a business process adjustment plan document containing records of process node execution order adjustments 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 preceding nodes and data validity check rules.

[0157] After completing the business process reengineering, 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 records of the adjusted execution order of process nodes, data transfer rules between nodes, input and output data specifications for each process node, and explanations of execution conditions.

[0158] The process node execution order adjustment log details the adjustments made to the execution order of each node in the business process. For example, it records which nodes were moved forward or backward, along with the reasons and basis for the adjustments. In the "Power Generation Dispatch Scenario," the execution order of the "Power Generation Dispatch Scheme Formulation" node was changed from third to second because this node is crucial for the issuance and execution of subsequent power generation dispatch instructions, requiring accurate input data to be obtained as quickly as possible for scheme formulation.

[0159] The data transfer rules between nodes clearly define the methods and requirements for data transfer between different process nodes. Based on the data field mapping table and data conversion functions, the data transmission path, data format, and data conversion rules are specified. For example, it specifies how the data collected by the "generator power data collection" node should be transferred to the "generation dispatch scheme formulation" node after data conversion, as well as the format and verification rules that must be followed during the transmission process.

[0160] The input and output data specifications for each process node detail the specific requirements for the input and output data needed for that node. This includes the names, types, value ranges, and formats of data fields. For example, the input data specifications for the "Power Generation Dispatch Scheme Formulation" node require real-time generator power data and power generation demand forecast data, and the data format must conform to the set standards. The output data specifications require the power generation dispatch scheme to include the power allocation of each generator, power generation time arrangements, etc., and it must be stored and transmitted in the specified format.

[0161] The execution conditions description includes the status of preceding nodes and data validity check rules. The preceding node status describes the state that preceding nodes must reach before this node can execute. For example, before the "Generation Dispatch Scheme Formulation" node executes, the "Generator Power Data Collection" node must complete and the collected data must be valid. The data validity check rules specify the standards and methods for checking input data, such as checking 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.

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

[0163] Step S150: Generate a collaborative execution instruction containing a sequence of microservice call instructions based on the business process adjustment scheme, and send the collaborative execution instruction to the target business system to trigger cross-system collaborative processing operations.

[0164] For example, step S151: Analyze the execution order of process nodes and the data transfer rules between nodes in the business process adjustment plan, and determine the microservice call operation corresponding to each process node. The microservice call operation includes the name of the microservice to be called and the required input parameters.

[0165] The business process adjustment plan is analyzed to extract the execution order of process nodes and the data transfer rules between nodes. Based on this information, the microservice call operation corresponding to each process node is determined.

[0166] Each process node may need to call one or more microservices to complete a specific task during execution. For example, in the "Power Generation Scheduling Scenario," the "Power Generation Demand Analysis" node may need to call a microservice named "Power Generation Demand Forecasting Microservice" to complete the demand analysis task. For each process node, the name of the microservice to be called and the required input parameters need to be explicitly specified.

[0167] The name of the microservice to be called is the identifier of the specific microservice to be invoked, which uniquely identifies the microservice to be called. The required input parameters refer to the data that needs to be provided when calling the microservice. This data usually comes from the output of the previous process node or other relevant data sources. For example, when calling the "generation demand forecasting microservice," the input parameters may include historical electricity consumption data, current grid load data, etc.

[0168] When determining microservice call operations, input parameters need to be processed based on the data field mapping table and data conversion functions. It is crucial to ensure that the format and content of the input parameters conform to the microservice's requirements. For example, if the microservice requires historical electricity consumption data to be represented in a defined time-series format, but the data obtained from the process nodes has a different format, appropriate data conversion is necessary.

[0169] By analyzing the business process adjustment plan, the microservice call operation corresponding to each process node is determined.

[0170] Step S152: According to the execution order of the process nodes, convert the microservice call operation into a sequence of instructions with time order. The instruction sequence includes the unique identifier of the microservice, the call parameters and the execution time window. The execution time window is determined according to the execution time requirements of the process nodes.

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

[0172] Each instruction in the instruction sequence contains a unique identifier for the microservice, invocation parameters, and an execution time window. The unique identifier of the microservice is used to uniquely identify the microservice to be invoked, ensuring that the instruction is accurately sent to the target microservice. The invocation parameters are the data that needs to be passed when invoking the microservice; these parameters have already been processed in previous steps based on the data field mapping table and data transformation functions.

[0173] The execution time window is determined based on the execution time requirements of each process node. Each process node has its own set execution time requirements. For example, in the "power generation scheduling scenario," the "power generation scheduling instruction issuance" node needs to be executed as soon as possible after the power generation scheduling plan is formulated. Therefore, the execution time window of its corresponding microservice call instruction needs to be set relatively compactly. The execution time window specifies the time range within which the microservice call instruction can be executed, ensuring that the microservice can be executed at the appropriate time and avoiding execution that is too early or too late, which could affect the overall progress of the business process.

[0174] For example, for the microservice call operation corresponding to the "Power Generation Demand Analysis" node, after it is converted into an instruction, the instruction may be as follows: the microservice unique identifier is "Power Generation Demand Prediction 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".

[0175] These instructions are generated sequentially according to the execution order of the process nodes, forming a chronological instruction sequence. This instruction sequence reflects the order and timing of microservice calls within the business process.

[0176] Step S153: According to the data interaction format specification, perform data type conversion and field name mapping on the microservice call parameters so that the format of the microservice call parameters conforms to the input requirements of the target microservice.

[0177] After generating the instruction sequence, the microservice call parameters need to be further processed according to the data interaction format specification. Different microservices may have different input requirements, including data type and field name specifications. Therefore, it is necessary to perform data type conversion and field name mapping on the call parameters to ensure that the parameter format conforms to the input requirements of the target microservice.

[0178] Data type conversion involves converting 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, then data type conversion is needed to convert the integer data to floating-point data. Data type conversion can be implemented using simple type conversion functions, or it can involve complex logic processing depending on the specific situation.

[0179] Field name mapping is the process of converting the field names of call parameters into the field names used by the target microservice. Different business systems and microservices may use different field names for the same data. For example, the business process may use the "generator power" field, while the target microservice may use the "input power" field. In this case, field name mapping is required to map the "generator power" field to the "input power" field.

[0180] The microservice call parameters are processed according to the field mapping rules and data transformation functions in the data interaction format specification. During processing, it is crucial to ensure the accuracy and integrity of the data, avoiding data loss or errors. For example, for complex data structures containing multiple fields, each field needs to be processed individually to ensure that all fields are correctly transformed and mapped.

[0181] 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 a guarantee for the collaborative execution of business processes.

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

[0183] In actual microservice calls, various errors may occur, such as network failures, microservice failures, and incorrect input parameters. To ensure the stability and reliability of business processes, error handling logic needs to be added to each microservice call command.

[0184] Error handling logic includes a retry mechanism and exception information capture rules. The retry mechanism handles call failures. When a microservice call fails, the retry mechanism retryes according to preset rules. These rules can include the number of retries and the retry interval. For example, if a microservice call fails, the retry count is set to 3, with a 5-second interval between each retry. After the first call fails, a second retry is performed after a 5-second wait. If the second retry also fails, a third retry is performed after a 5-second wait. If all three retries fail, the call is considered to have failed, and further error handling is required.

[0185] Exception capture rules are used to record exception information during the call process. When an exception occurs during a microservice call, the exception capture rules will capture exception information such as the exception type, exception message, the name of the called microservice, and the call parameters. This exception information can help developers and operations personnel quickly locate the problem, analyze its cause, and take appropriate solutions. Exception information can be logged to log files or sent to a monitoring system via a message queue for timely processing.

[0186] When adding error handling logic to microservice call commands, customized settings are required based on different microservices and business scenarios. For some critical microservice calls, it may be necessary to set up stricter retry mechanisms and detailed exception information capture rules; for some non-critical microservice calls, the requirements for the number of retries and exception information logging can be appropriately relaxed.

[0187] For example, in the "power generation dispatch scenario," the call to the "power generation dispatch instruction issuance" microservice directly affects the operation of power generation equipment and power supply. Therefore, it is necessary to set a high number of retry attempts and detailed exception information capture rules. When the call fails, multiple retries will be performed, and detailed exception information for each call will be recorded, including the time of the exception, the exception type, and the call parameters, so that problems can be quickly investigated and resolved.

[0188] Step S155: Encapsulate the processed microservice call instruction sequence with business scenario tags 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.

[0189] After adding error handling logic to the microservice call instructions, the processed microservice call instruction sequence needs to be encapsulated with business scenario tags and timestamp information to generate collaborative execution instructions with a unified format.

[0190] 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 dispatch scenario" or "transmission fault repair scenario," facilitating appropriate processing by the receiver based on the specific business scenario. The sender and receiver identifiers clarify the source and destination of the instruction, ensuring accurate transmission to the target business system.

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

[0192] The instruction checksum is used to verify the integrity and correctness of collaboratively executed instructions. When encapsulating the instruction, a checksum can be generated based on the instruction header information and the instruction body content. Upon receiving the instruction, the receiver can recalculate the checksum and compare it with the received checksum. If the two checksums match, it means the instruction has not been tampered with during transmission and its content is complete and correct; if they do not match, it indicates that the instruction may have a problem and requires further inspection and processing.

[0193] Timestamp information records the time when an instruction was generated, ensuring its timeliness. In business processes, some instructions may have strict time requirements; for example, power generation dispatch instructions need to be issued at a specific time. Timestamp information helps the recipient determine whether the instruction is within the valid time frame, avoiding the execution of outdated instructions.

[0194] By encapsulating the processed microservice call instruction sequence with business scenario tags and timestamp information, a unified format of collaborative execution instructions is generated, enabling the instructions to be accurately and securely transmitted and executed between different business systems, thus achieving cross-system collaborative processing operations.

[0195] The generated collaborative execution instructions are sent to the target business system. Upon receiving the instructions, the target business system can process them accordingly. First, the target business system verifies the completeness and correctness of the instructions. If the verification passes, it can sequentially call the corresponding microservices based on the business scenario tags and microservice call instruction sequence in the instructions, executing the appropriate business operations. During execution, potential errors can be handled according to the error handling logic in the instructions to ensure the smooth operation of the business process. Simultaneously, the execution status of the instructions and related log information can be recorded for subsequent monitoring and analysis.

[0196] In summary, by acquiring the initial interaction data set across business systems, parsing and processing its scenario features, invoking a pre-built business collaboration analysis model for collaboration correlation analysis, determining business process adjustment plans, and generating and sending collaborative execution instructions, cross-business system microservice processing for business scenario collaboration is achieved. This method improves the collaboration and efficiency between business systems, optimizes business processes, and provides an effective solution for complex business scenarios such as power business.

[0197] Figure 2 The illustration shows exemplary hardware and software components of a cross-business system microservice processing system 100 for business scenario collaboration, which can implement the ideas of this application, according to some embodiments of this application. For example, processor 120 can be used in the cross-business system microservice processing system 100 for business scenario collaboration and to perform the functions in this application.

[0198] The cross-business system microservice processing system 100, designed for collaborative business scenarios, can be a general-purpose server or a special-purpose server. Both can be used to implement the cross-business system microservice processing method for collaborative business scenarios described in 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.

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

[0200] 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. Therefore, the steps executed by one processor as described in this application may also be executed jointly by multiple processors or individually. For example, if the processor of the cross-business system microservice processing system 100 for business scenario collaboration executes steps A and B, it should be understood that steps A and B may also be executed jointly by two different processors or individually by one processor. For example, the first processor executes step A, the second processor executes step B, or the first processor and the second processor jointly execute steps A and B.

[0201] Furthermore, this embodiment of the invention also provides a readable storage medium, wherein computer-executable instructions are preset in the readable storage medium, and when the processor executes the computer-executable instructions, the above-mentioned cross-business system microservice processing method for business scenario collaboration is implemented.

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

Claims

1. A cross-business system microservice processing method for collaborative business scenarios, characterized in that, The method includes: Obtain an initial interaction data set across business systems, the initial interaction data set containing interaction data units with business scenario tags generated by multiple business systems within a preset time period; The initial interaction data set is subjected to scene feature parsing processing to obtain the business scene features and interaction behavior features corresponding to each interaction data unit. The business scene features include scene function description information and scene process node association relationship. The interaction behavior features include interaction operation type and operation time sequence. The pre-built business collaboration analysis model is invoked to perform collaborative correlation analysis on the business scenario features and the interaction behavior features, and a collaborative processing strategy for each interactive data unit is generated. The collaborative processing strategy includes microservice call priority and data interaction format specification. Based on the collaborative processing strategy, a business process adjustment plan for each business system is determined under the target business scenario. The business process adjustment plan includes the execution order of process nodes and the data transfer rules between nodes. Based on the business process adjustment plan, a collaborative execution instruction containing a sequence of microservice call instructions is generated, and the collaborative execution instruction is sent to the target business system to trigger cross-system collaborative processing operations; The pre-built business collaboration analysis model is invoked to perform collaborative correlation analysis on the business scenario features and the interaction behavior features, generating a collaborative processing strategy for each interaction data unit, including: The business scenario features and interaction behavior features are input into the feature fusion network of the business collaboration analysis model, and weighted fusion processing is performed in combination with the feature contribution parameter to generate a fusion feature vector containing scenario behavior association information. The feature contribution parameter is determined based on the information entropy calculation result. The fusion feature vector is analyzed by a business collaboration analysis model to resolve node relationships and evaluate dependencies, thereby identifying the process node interaction points of different business systems in the target business scenario. Based on the functional interface descriptions and resource consumption of the microservices, a microservice call adaptability analysis is performed on the interaction points of the process nodes 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. Based on the data format of interactive data units and the data processing requirements of business scenarios, a data interaction format specification containing field mapping rules and data validation logic is generated. 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 specifications are grouped and integrated according to the business scenario tags of the interaction data units to generate a set of collaborative processing strategies for each interaction data unit. The grouping and integration process includes feature classification and rule encapsulation.

2. The cross-business system microservice processing method for business scenario collaboration according to claim 1, characterized in that, The process of parsing the initial interaction data set to obtain the business scenario features and interaction behavior features corresponding to each interaction data unit includes: Each interactive data unit in the initial interactive data set is subjected to data format standardization processing to unify the naming rules and data type definitions of data fields. The data fields include business operation identifier fields, data generation time fields, and associated system identifier fields. Extract scene identification information from the standardized interactive data unit, associate the scene identification information with a preset business scenario knowledge base, and obtain the corresponding scene function description information and scene process node association relationship as business scenario features. The scene identification information includes business module name and operation type combination code. The operation instruction code in the interactive data unit is identified, the interactive operation type is parsed according to the operation instruction code, and an operation time sequence is generated as an interactive behavior feature according to the timestamp order. The operation instruction code includes system interface call instructions and data processing instructions. The business scenario features and interaction behavior features generated by different business systems are subjected to dimensional unification processing to generate a set of scenario behavior features with the same feature dimensions. 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 business scenario features and interaction behavior features in 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, characterized in that, The step of extracting scene identification information from standardized interactive data units, associating the scene identification information with a preset business scenario knowledge base, and obtaining corresponding scene function description information and scene process node association relationships as business scenario features includes: The standardized interactive data units are processed by keyword extraction to obtain a set of scenario keywords containing business module names and operation purpose descriptions, wherein the business module names correspond to the functional division of specific business systems. The set of scenario keywords is matched with scenario identifier tags in a preset business scenario knowledge base using a semantic similarity calculation algorithm to determine the target business scenario type to which the interactive data unit belongs. The semantic similarity calculation algorithm is based on word vector space distance measurement. Extract scenario function description information corresponding to the target business scenario type from the business scenario knowledge base. The scenario function description information includes the input data requirements and output result standards of the business process. The input data requirements include data field integrity and format standardization requirements. The business process diagram corresponding to the target business scenario type is analyzed, the dependencies between scenario process nodes and the data transmission path are extracted, and the scenario process node association relationship is generated. 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 preceding node and the validity of the input data. The scenario function description information and the association relationship of scenario process nodes are structurally integrated to generate a business scenario feature descriptor with a hierarchical structure, which 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, characterized in that, The operation instruction code in the identification interaction data unit is used to parse the interaction operation type based on the operation instruction code, and an operation time sequence is generated as an interaction behavior feature according to the timestamp order, including: The operation instruction code in the interactive data unit is parsed to identify the operation verbs and operation objects in the operation instruction code. The interactive operation type is determined according to the preset operation type classification rules. The interactive operation type includes data query, data writing, service call and process jump. The operation verbs correspond to different interactive operation types. Extract the timestamp information of the interactive data units, sort the interactive data units in the same business scenario according to the order of the timestamps, and generate a continuous operation sequence; Analyze the parameter passing relationships between operation instruction codes in adjacent operation sequences, determine the dependencies and execution order constraints between operations, and generate an operation timing sequence containing dependency identifiers. The parameter passing relationships include the source of input parameters and the destination of output parameters. The operation time sequence is subjected to time interval analysis processing to calculate the time interval between adjacent operations and generate a time interval feature vector that reflects the operation execution frequency and time distribution characteristics. The interaction operation types and the operation sequence containing dependency identifiers are associated and integrated to generate a complete set of interaction behavior feature descriptions.

5. The cross-business system microservice processing method for business scenario collaboration according to claim 1, characterized in that, The process involves parsing node relationships and evaluating dependencies using a business collaboration analysis model to identify process node interaction points between different business systems in the target business scenario, including: The hierarchical decomposition process is performed on the relationship between the nodes in the scene process, and the input and output data parameters and execution conditions of each process node are extracted. The hierarchical decomposition process includes process node hierarchy division and data parameter parsing. Analyze the matching of input and output data parameters between process nodes of different business systems, and identify node pairs with completely identical data parameters or those that can be converted through preset conversion rules. The preset conversion rules include data type conversion rules and field semantic mapping rules. A compatibility analysis is performed on the execution conditions of the node pair to determine whether there is a dependency relationship in execution order between the two nodes in the target business scenario, and a node dependency matrix containing dependency type and dependency strength is generated. The dependency type includes data dependency and control dependency. Based on the node dependency matrix, the process node interaction points between different business system process nodes are determined. The process node interaction points include the initiating node and receiving node of data interaction and the corresponding interaction data fields. The interaction data fields include key business information and data format descriptions. The process node interaction points are clustered based on the similarity of business meaning. According to the business meaning of the interaction data fields, the process node interaction points are divided into data sharing interaction points and process collaboration interaction points, and corresponding interaction point feature descriptors are generated for each.

6. The cross-business system microservice processing method for business scenario collaboration according to claim 1, characterized in that, The step involves performing microservice call adaptability analysis on the process node interaction points based on the functional interface descriptions and resource consumption of the microservices, and determining the microservice call priority corresponding to each process node interaction point, including: Establish a microservice information knowledge base, which includes the functional interface description, service response time threshold, and peak resource consumption parameters for 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 for that process node interaction point, and match a set of microservice candidates with the same or similar functional interfaces in the microservice information knowledge base. The data processing functions include data transformation, data calculation and data verification. Obtain the historical call records of each microservice in the microservice candidate set, analyze its service response time and resource consumption in different time periods, and generate microservice performance stability evaluation indicators. The historical call records include call time, input parameters and response results. Based on the functional interface matching degree and microservice performance stability evaluation index, calculate the adaptability score for each microservice candidate; The microservice candidate set is sorted in descending order of adaptability score, and the microservice call priority corresponding to each process node interaction point is determined according to the preset priority division rule, which includes the correspondence between score range and priority level.

7. The cross-business system microservice processing method for business scenario collaboration according to claim 1, characterized in that, The step of determining the business process adjustment plan for each business system under the target business scenario based on the collaborative processing strategy includes: The collaborative processing strategy of each interactive data unit is analyzed, the microservice call priority and data interaction format specifications are extracted, and the data is classified and summarized according to business scenario tags. The classification and summary processing includes data statistics and rule integration. For the target business scenario, analyze the execution order of process nodes corresponding to different microservice call priorities, and determine the key process nodes corresponding to the microservices that need to be called first; According to the data interaction format specification, a data field mapping relationship table is established between different business systems. 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 the 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 transformation and verification steps are inserted. Generate a business process adjustment plan document that includes records of process node execution order adjustments and data transfer rules between nodes. The business process adjustment plan document includes input and output data specifications and execution condition descriptions for each process node. The execution condition descriptions include the status of preceding nodes and data validity check rules.

8. The cross-business system microservice processing method for business scenario collaboration according to claim 7, characterized in that, For the target business scenario, the process node execution order corresponding to different microservice call priorities is analyzed to determine the key process nodes corresponding to the microservices that need to be called first, including: All collaborative processing strategies under the target business scenario are grouped according to the microservice call priority, and the set of process nodes corresponding to the target priority microservice is extracted. The adaptability score of the target priority microservice is higher than the preset priority threshold. Dependency analysis is performed on the set of process nodes to identify the predecessor and successor nodes, and a dependency graph of the process nodes is constructed. The dependency graph contains the dependency relationships and data transmission paths between process nodes. In the dependency graph, find the critical path from the start point of the process to the end point of the process, and determine the process nodes on the critical path as critical process nodes. 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 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 specification requirements. A list of key process nodes is generated, which includes node name, node function description and execution priority ranking in the target business scenario. The execution priority ranking is determined based on the results of critical path analysis and microservice call priority.

9. A cross-business system microservice processing system for collaborative business scenarios, characterized in that, The cross-business system microservice processing system for business scenario collaboration includes a processor and a memory, the memory and the processor are connected, the memory is used to store programs, instructions or code, and the processor is used to execute the programs, instructions or code in the memory to implement the cross-business system microservice processing method for business scenario collaboration as described in any one of claims 1-8.

Images