End-to-end process construction and execution methods and related equipment based on standardized components

Abstract

This application relates to a method and related equipment for constructing and executing end-to-end processes based on standardized components. The method includes: acquiring process design data for an end-to-end process project of a power company, which includes value stages, key business activities, atomic operation sequences, operation subjects, and outputs; encapsulating atomic operations into standardized components, configuring execution roles for them, reserving element slots, and storing them in a process component library; responding to orchestration instructions, selecting multiple components corresponding to the target business scenario from the component library, establishing control flow logic between components, generating an end-to-end process model, and establishing metadata association relationships between each component and execution roles, digital systems, business rules, business forms, and institutional standards; and deploying the model and metadata associations to a process execution platform. This application improves the construction efficiency, component reusability, and executability of end-to-end processes.

Description

Technical Field

[0001] This application relates to the field of process construction and execution technology for power grid enterprises, and in particular to an end-to-end process construction and execution method and related equipment based on standardized components. Background Technology

[0002] In the business operations of power companies (especially county and district power supply bureaus and stations), cross-departmental collaborative scenarios such as distribution network construction, customer installation applications, and fault repair are increasingly common. These scenarios typically involve multiple departments, including marketing, operation and maintenance, infrastructure, and finance, requiring end-to-end process management from request submission to customer satisfaction. Currently, power companies generally adopt a segmented management model, where business processes are designed independently according to professional lines (such as transmission, distribution, and marketing). Each line develops process specifications based on its own management needs, lacking enterprise-level overall coordination. In the process construction process, existing methods often directly solidify business activities into process nodes without structuring and layering process design data (such as value stages, key business activities, and atomic operations), resulting in coarse process granularity and poor reusability. At the same time, the supporting elements required for process definition and execution (such as execution roles, digital systems, business rules, business forms, and institutional standards) are disconnected. The process model only describes the sequence of nodes and cannot carry executable metadata information, requiring significant manual configuration and secondary development when deployed to the process execution platform. In addition, the process components lack a standardized encapsulation mechanism, and similar operations in different business scenarios (such as on-site surveys and solution approvals) cannot be reused, resulting in low efficiency due to repetitive modeling. Summary of the Invention

[0003] To address the aforementioned shortcomings or deficiencies, this application provides an end-to-end process construction and execution method and related equipment based on standardized components.

[0004] This application provides a method for constructing an end-to-end process based on standardized components, according to a first aspect. The method includes: acquiring process design data for an end-to-end process project of a power company; the process design data includes multiple value stages, multiple key business activities contained in each value stage, atomic operation sequences corresponding to each key business activity, and operation subjects and outputs corresponding to each value stage; any atomic operation sequence includes collaborative operations between at least two departments among the power company's marketing, operation and maintenance, infrastructure, and finance departments; encapsulating each atomic operation into a standardized component, configuring an execution role corresponding to the operation subject of its associated value stage for each standardized component, and reserving space for associating it with related value stages. The output element slots of the value stage are used to obtain standardized process components; these standardized process components are stored in the process component library; in response to orchestration instructions, multiple process components corresponding to multiple value stages related to the target business scenario are selected from the process component library, starting with the customer's needs and ending with the fulfillment of those needs, to establish the control flow logic between the selected multiple process components, generating an end-to-end process model, and establishing metadata associations between each process component in the end-to-end process model and supporting elements; the end-to-end process model and metadata associations are deployed to the process execution platform; supporting elements include execution roles, digital systems, business rules, business forms, and institutional standards.

[0005] This application provides an end-to-end process execution method based on standardized components according to a second aspect. The method includes: in response to a triggering event, determining a target end-to-end process model; the target end-to-end process model is constructed according to the end-to-end process construction method based on standardized components provided in any of the above embodiments; creating a process instance based on the target end-to-end process model and its metadata association, and initializing a context data container; writing the original data carried by the triggering event into the global variable area of ​​the context data container; during the process instance advancement, determining the target execution role corresponding to the current process component according to the metadata association, and pushing the task data packet generated according to the metadata association to the terminal corresponding to the target execution role; upon receiving the operation result data returned by the terminal, updating the context data container according to the operation result data to advance to the next process component.

[0006] According to a third aspect, this application provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the methods provided in any of the above embodiments.

[0007] According to a fourth aspect, this application provides a computer device including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the methods provided in any of the above embodiments.

[0008] This application first acquires process design data that includes value stages, key business activities, atomic operations and their subjects, and outputs. It then encapsulates cross-departmental collaborative atomic operations into standardized components and configures execution roles and reserved element slots for these components. This achieves the structuring, standardization, and reusability of process components, solving the problems of coarse granularity and low efficiency of repetitive modeling in existing process construction.

[0009] Secondly, in response to orchestration instructions, components related to the target business scenario are selected from the component library. Starting with customer needs, control flow logic is established to generate an end-to-end process model. Metadata associations are established for each component with supporting elements such as execution roles, digital systems, business rules, business forms, and institutional standards. This ensures that the process model not only includes the node sequence but also carries executable metadata information.

[0010] Finally, the model and metadata are associated and deployed to the process execution platform, avoiding the problems of process definition and execution elements being separated in traditional methods, and requiring a lot of manual configuration and secondary development. Attached Figure Description

[0011] Figure 1 This is a flowchart of an end-to-end process construction method based on standardized components in one or more embodiments of this application;

[0012] Figure 2 This is a flowchart of an end-to-end process execution method based on standardized components in one or more embodiments of this application;

[0013] Figure 3 This is a schematic diagram of the internal structure of a computer device according to one or more embodiments of this application. Detailed Implementation

[0014] To make the objectives, technical solutions, and advantages of this application clearer, the embodiments of this application will be described in further detail below with reference to the accompanying drawings. It should be understood that the described embodiments are merely some embodiments of this application, and not all embodiments. All other embodiments obtained by those skilled in the art based on the embodiments of this application without creative effort are within the scope of protection of this application.

[0015] In the following description, when referring to the accompanying drawings, the same numbers in different drawings denote the same or similar elements unless otherwise indicated. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0016] In the description of this application, it should be understood that the terms "first," "second," "third," etc., are used only to distinguish similar objects and are not necessarily used to describe a specific order or sequence, nor should they be construed as indicating or implying relative importance. Those skilled in the art can understand the specific meaning of the above terms in this application according to the specific circumstances. Furthermore, in the description of this application, unless otherwise stated, "multiple" refers to two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone. The character " / " generally indicates that the preceding and following related objects have an "or" relationship.

[0017] To address the shortcomings or defects of related technologies, this application provides an end-to-end process construction method based on standardized components. This method improves the construction efficiency of end-to-end processes, the cross-scenario reusability of components, and the executability of process models by hierarchically structuring process design data, standardizing the encapsulation of components, and establishing metadata associations, thus laying a model foundation for the automated execution of processes.

[0018] In some exemplary embodiments of this application, such as Figure 1 As shown, the method includes steps S110-S120. This method can be applied to a process construction system (which can be simply referred to as the system, specifically a server or server cluster). The steps are described in detail below.

[0019] S110: Obtain the process design data for the end-to-end process project of the power company. The process design data includes multiple value stages, multiple key business activities contained in each value stage, atomic operation sequences corresponding to each key business activity, and operation subjects and outputs corresponding to each value stage. Any atomic operation sequence includes collaborative operations between at least two departments in the power company's marketing, operation and maintenance, infrastructure, and finance departments. Encapsulate each atomic operation into a standardized component, configure the execution role corresponding to the operation subject of its related value stage for each standardized component, and reserve element slots for associating with the outputs of its related value stages to obtain standardized process components. Store the standardized process components in the process component library.

[0020] An end-to-end process project refers to a process design task established for a specific enterprise-level collaborative scenario (such as power distribution network construction and customer installation). Its input is internal and external customer needs, and its output is the satisfaction of customer needs and the creation of business value.

[0021] Process design data refers to the initial definitions required to build an end-to-end process. A value stage refers to several coherent macro-level stages divided based on value creation logic, each with a clear value output, such as the "requirement acceptance and research stage." Key business activities refer to the node-type business activities that need to be completed within each value stage, such as "accepting applications" and "distributing survey work orders." An atomic operation sequence refers to the specific, executable, and verifiable operational steps obtained after decomposing each key business activity. The operating entity refers to the specific department or position responsible for executing the value stage or operation, such as "customer specialist in the marketing department." Outputs refer to the specific deliverables generated upon completion of each value stage, such as the "Distribution Network Construction Requirements Research Report." An atomic operation sequence includes multiple atomic operations. An atomic operation is the smallest, indivisible operational unit constituting a business process and is the basic action for process execution. Standardized components refer to reusable components formed by encapsulating atomic operations according to unified standards, possessing standard attributes such as unique identifiers, execution roles, preconditions and / or postconditions, and interface protocols. An execution role refers to a specific job selected from the company's unified job directory, responsible for executing the standardized component, such as "emergency repair team leader," defining the component's "owner." An element slot refers to a standardized interface reserved within the standardized component for subsequent association with business elements (such as forms, rules, and policies). The process component library is an enterprise-level repository for storing and managing all standardized components, supporting indexing and retrieval by multiple dimensions such as profession, role, and system.

[0022] This step begins by acquiring process design data from the power company's end-to-end process projects. This data defines the value stages required to build the process, the key business activities under each stage, and the atomic operation sequence involving multi-departmental collaboration for each activity, along with the corresponding operational entities and outputs.

[0023] Subsequently, the process building system encapsulates each atomic operation into a standardized component. The encapsulation process for atomic operations includes: generating a unique identifier for the component, binding its execution role, and reserving element slots for it for subsequent association with outputs and other elements. After encapsulation, the standardized components are stored in the process component library as basic building blocks for subsequent process assembly.

[0024] This step encapsulates atomic operations into standardized components and stores them in a component library. This creates the basic building blocks for enterprise-level processes, enabling subsequent process design to be assembled based on these standardized components, thus improving the standardization and efficiency of process design. Simultaneously, by pre-setting execution roles and element slots for the components, a structured data foundation is laid for subsequent cross-departmental collaboration and the deep integration of processes and business elements, enhancing the maintainability and scalability of the processes.

[0025] S120: In response to orchestration instructions, select multiple process components from the process component library that correspond to multiple value stages related to the target business scenario. Starting with the customer's needs and ending with the fulfillment of those needs, establish control flow logic between the selected multiple process components, generate an end-to-end process model, and establish metadata associations between each process component in the end-to-end process model and supporting elements. Deploy the end-to-end process model and metadata associations to the process execution platform.

[0026] Supporting elements include execution roles, digital systems, business rules, business forms, and institutional standards. Orchestration instructions are operational commands issued by process architects or designers using process modeling tools (such as tools supporting BPMN) to select and connect components to build a complete process. The target business scenario refers to the specific business problem that the process to be designed aims to solve, such as "new low-voltage residential electricity installation" or "distribution network construction project." Control flow logic refers to the logical relationships connecting various process components, used to achieve intelligent routing and concurrent processing of business processes. It defines the order and direction of business execution, specifically including sequential flow and logical relationships, which can be configured through parallel gateways (AND), exclusive gateways (OR / XOR), etc. An end-to-end process model is a machine-readable and executable full-chain business blueprint generated by connecting and orchestrating selected process components according to control flow logic through a visual method (such as a BPMN diagram), starting with customer requirements and ending with requirement fulfillment. Metadata association refers to the mapping and binding relationship established between each process component in an end-to-end process model and the core elements supporting its operation (i.e., supporting elements: execution roles, digital systems, business rules, business forms, and institutional standards). This transforms components from "blueprints" into executable "instructions." Supporting elements ensure the smooth execution of process components. Each process component's supporting elements include execution roles (the specific positions responsible for the process component), digital systems (the core IT systems or tools supporting the process component's completion), business rules (the conditions and judgments that control the execution logic of the process component), business forms (structured data generated, used, or filled in by the process component), and institutional standards (the rules, regulations, or work instructions that the process component must follow). The process execution platform is a unified business process management and execution system used to deploy process models and automatically drive task generation, push, and flow based on model definitions and associated elements, achieving automated execution of business processes.

[0027] Upon receiving the orchestration instructions, this step first selects relevant process components from the process component library based on the target business scenario. Then, taking "customer requirement proposal" as the starting point and "customer requirement fulfillment" as the ending point, it connects these components into a complete, visual end-to-end process model by defining control flow logic such as sequence, parallelism, and conditional branching between components.

[0028] After generating the end-to-end process model, metadata associations are established between each process component and its supporting elements, ensuring that each component possesses all the supporting information required for runtime. Finally, the completed end-to-end process model and its associated metadata are deployed to the process execution platform, making it a digital engine capable of driving actual business operations.

[0029] By assembling standardized components and associating supporting elements, a full-chain enterprise-level end-to-end view from customer needs to value creation is constructed, breaking down the departmental silos that traditionally fragment processes along professional lines. The model is now not merely a visualized flowchart, but an executable blueprint integrating metadata such as roles, rules, and systems, providing a complete definition for automated process flow and digital execution. Deploying the model to the execution platform enables intelligent task driving and precise task delivery, fundamentally changing the inefficient model that relies on manual information transmission and faces difficulties in cross-departmental collaboration, laying the foundation for seamless, transparent, and efficient business process operation.

[0030] In some embodiments, starting with the customer's demand and ending with the fulfillment of that demand, control flow logic is established between selected process components to generate an end-to-end process model. This includes: acquiring multiple value stages corresponding to the target business scenario, where each value stage starts with the customer's demand and ends with the fulfillment of that demand; establishing swimlanes for each value stage using a process modeling tool, and dividing role bands within each swimlane based on the operating entity corresponding to each value stage; selecting process components corresponding to each value stage from a process component library, placing the selected process components into the role bands of the corresponding swimlanes, establishing sequential flow, parallel gateway, and exclusive gateway logical relationships for the selected process components, and generating an end-to-end process model with full-chain logic that meets customer needs.

[0031] The value stage refers to a series of coherent macro-level stages based on the logic of value creation, with each stage corresponding to a specific value output. In this step, the value stage should begin with "customer demand being raised" and end with "customer demand being met," forming a complete end-to-end value chain.

[0032] Process modeling tools refer to visual modeling software that supports the BPMN (Business Process Model and Notation) standard, such as Camunda or Signavio. These tools can create executable process models, providing graphical elements such as swimlanes, role bands, and control flow logic, and ultimately generate machine-readable BPMN XML files for subsequent process execution platforms to load and run.

[0033] Swimlanes are horizontal or vertical partitions used in process modeling tools to distinguish different responsible parties or organizational units. In this embodiment, each value stage corresponds to an independent horizontal swimlane, which visually breaks down complex cross-stage processes into a hierarchical structure divided by stages, facilitating understanding and maintenance.

[0034] Role bands are further subdivided areas within swimlanes to distinguish different execution roles or positions within a given value phase. For example, a "Customer Service Representative" role band could be set up within the "Business Processing" swimlane; a "Site Investigator" role band could be set up within the "Site Investigation" swimlane. Role band divisions ensure that each operational component can be accurately assigned to a specific execution position.

[0035] A sequence flow is a directed connection used to connect two process components, defining the order in which the components are executed. A sequence flow means that the next component is automatically triggered after the previous one completes; it is the core element for constructing the basic execution order of a process.

[0036] A Parallel Gateway (AND) is a control node used to create concurrent execution branches. Parallel Gateways have two forms: Fork and Join. Fork splits a single execution path into multiple parallel paths, allowing multiple tasks to execute simultaneously; Join waits for all parallel paths to complete before merging them into a single execution path, ensuring that subsequent steps only start after all parallel tasks have finished.

[0037] An Exclusive Gateway (XOR) is a control node used for condition-based branch selection. Based on the value of the current process context variable, the Exclusive Gateway selects only the branch where the condition is met for execution, achieving intelligent process routing. For example, setting an Exclusive Gateway after the "Verify Data Integrity" component can lead to either the "Dispatch Survey Work Order" branch or the "Notify Customer to Correct" branch based on the verification result.

[0038] Full-chain logic refers to the complete business logic link from the emergence of customer needs to the fulfillment of those needs, encompassing all value stages, operational components, and the control flow relationships between them. Full-chain logic ensures that the process has no breakpoints, and any input can flow along a predefined path to the final output.

[0039] The specific operation process of this embodiment is as follows.

[0040] First, process designers identify the multiple value stages corresponding to the target business scenario. For example, for the scenario of "new low-voltage residential electricity installation", the value stages are, in order, "business acceptance, on-site survey, engineering construction, meter installation and power connection, and service evaluation".

[0041] Next, the process designers open the process modeling tool and create an independent horizontal swimlane for each value stage. For example, they create a swimlane named "Business Acceptance," a swimlane named "Site Investigation," and so on. Within each swimlane, role bands are further divided based on the operational entities involved in that value stage (i.e., the departments or positions responsible for execution). For example, in the "Business Acceptance" swimlane, since it is mainly performed by customer service representatives, a "Customer Service Representative" role band is created; in the "Site Investigation" swimlane, since it involves investigators performing on-site investigation work, a "Investigator" role band is created; if multiple different positions are involved in the same swimlane, multiple role bands are created separately to ensure clear responsibilities.

[0042] Then, the process designers select standardized process components corresponding to each value stage from the process component library. Specifically, they can use the component library's search function (by professionalism, role, keywords, etc.) to find the required components and drag them to the corresponding role area in the corresponding swimlane. For example, drag the "Receive Application Form" component to the "Customer Service Representative" role area in the "Business Acceptance" swimlane, drag the "Dispatch Survey Work Order" component to the "Customer Service Representative" role area in the "Business Acceptance" swimlane, and drag the "Execute On-site Survey" component to the "Surveyor" role area in the "On-site Survey" swimlane.

[0043] After placing all components, process designers establish control flow logic relationships between components by dragging and dropping lines with the mouse. Specifically, this includes: establishing sequential flows for components that execute sequentially, clarifying the order of steps; inserting parallel gateways (AND) at stages requiring concurrent operations, for example, after completing "site survey," if two parallel tasks, "develop power supply plan" and "prepare construction materials," are triggered simultaneously, a parallel gateway is used to branch, and then converges after both tasks are completed; inserting exclusive gateways (XOR) at stages requiring conditional judgments, for example, setting an exclusive gateway after the "verify data integrity" component, and drawing two branches based on conditional expressions (such as ${data integrity == 'pass'} and ${data integrity == 'incomplete'}), connecting to the "dispatch survey work order" component and the "notify customer to correct" component respectively, achieving intelligent routing of the process.

[0044] In addition, to address potential anomalies, process designers can add boundary events to relevant components. For example, they can attach timer events to the "On-site Construction" component and configure an abnormal flow that triggers "Construction Delay Processing" after a timeout, thereby enhancing the robustness of the process.

[0045] After dragging, connecting, and configuring all components, the process modeling tool's built-in validation engine automatically checks the model's integrity, including whether all branches have exits, whether gateways match, and whether cross-swimlane connections are correct. Once validation is successful, the process designer can publish the BPMN model, generating a machine-readable BPMNXML file. This file not only describes the control flow logic between components, such as sequence flows, gateways, and events, but also embeds the metadata association space required for subsequent steps through extended attributes, laying the foundation for the next step of feature binding and runtime-driven processing.

[0046] This embodiment uses swimlane and role-based hierarchical division to clearly decompose complex cross-departmental business processes into a structured view by stage and role, enabling process designers, business personnel, and decision-makers to understand the overall business picture from a global perspective. The introduction of parallel and exclusive gateways explicitly defines cross-departmental and cross-role collaborative relationships within the process model. Parallel gateways allow tasks that were originally executed sequentially to be executed concurrently, shortening the overall process cycle; exclusive gateways enable the process to automatically select execution paths based on business conditions, replacing the traditional implicit collaboration mode that relies on manual judgment and communication.

[0047] In some embodiments, establishing metadata associations between each process component and supporting elements in the end-to-end process model includes: obtaining each process component in the end-to-end process model; for each process component, obtaining the execution role from a unified job directory tree and establishing a first metadata association between the process component and the execution role; obtaining the interface address of the digital system from the system application programming interface address library and establishing a second metadata association between the process component and the digital system; obtaining business rules from the rule engine and establishing a third metadata association between the process component and the business rules; obtaining business forms from the form template library and establishing a fourth metadata association between the process component and the business forms; obtaining policy and standard documents from the knowledge base and establishing a fifth metadata association between the process component and the policy and standard documents; and embedding the first, second, third, fourth, and fifth metadata associations into the end-to-end process model.

[0048] Metadata relationships refer to the mapping and binding relationships established between process components and their supporting elements.

[0049] A unified job directory tree refers to an enterprise-level job management data system that stores all job information in a tree structure. This directory tree is typically maintained by a human resources system or organizational structure management system, and each job has attributes such as a unique identifier, job name, department, job description, and access permissions.

[0050] The system application programming interface address library (i.e., the system API address library) is a database that centrally stores the API (Application Programming Interface) addresses of various digital systems within an enterprise. This address library records metadata information for each system, including the interface URL, calling protocol (such as HTTP, HTTPS), authentication method (such as APIKey, OAuth), request format (such as JSON, XML), and response format.

[0051] A rules engine is a system module used to manage, store, and execute business rules. The rules engine decouples business logic (such as "trigger a special approval process if the voltage level is >10kV" or "reduce the deposit if the customer's credit rating is A") from the application code and stores it in a structured form (such as decision tables or rule flows).

[0052] The form template library is an enterprise-level repository for storing and managing various business form templates. Each form template defines the form's field structure (such as field name, data type, and length), data format (such as date format and mobile number regular expression), validation rules (such as required fields and uniqueness validation), and display style (such as layout and control type).

[0053] A knowledge base refers to an enterprise-level knowledge management platform that centrally stores documents and materials such as rules and regulations, technical standards, work instructions, and operating procedures.

[0054] The specific operation process of this embodiment is as follows.

[0055] First, the process building system obtains each process component in the end-to-end process model. The process model is composed of multiple process components connected according to control flow logic. The system parses the process model file (such as BPMNXML), traverses each component node (usually corresponding to the "activity" element in BPMN), and treats it as an object to be associated and processed.

[0056] Next, for each process component, the system sequentially establishes metadata associations with its supporting elements. When establishing the first metadata association, the system retrieves the corresponding execution role from the unified job directory tree. Specifically, based on the role identifier bound to the component during modeling or based on the business type to which the component belongs, the system queries the unified job directory tree to obtain the role's unique ID, job name, department, and other information, and establishes a mapping relationship between the component and the execution role. This relationship ensures that the process engine can accurately push tasks to the correct personnel in their positions during runtime.

[0057] The system queries the API address database based on the type of system (such as a marketing system or a GIS system) required for component execution. It retrieves complete information about the system, including its interface URL, calling protocol, authentication method, and input / output format, and establishes a mapping relationship between the component and the digital system. This relationship enables the component to automatically complete system calls and data interactions during runtime.

[0058] Then, based on the component's business scenario and functional positioning, the system queries the rule set defined in the rule engine to obtain information such as the rule ID, rule name, and rule logic (e.g., conditional expressions, action definitions) applicable to the component, and establishes a mapping relationship between the component and the business rules. This relationship enables the component to dynamically call the rule engine to perform condition judgments and logical branch selections at runtime.

[0059] Next, based on the business data types involved in the component (such as electricity application forms, survey record forms, and acceptance reports), the system queries the form template library to obtain the corresponding form template ID, template name, field structure, validation rules, and other information, and establishes a mapping relationship between the component and the business form. This relationship enables the component to dynamically render pre-filled electronic forms at runtime for users to fill out or view.

[0060] Subsequently, the system queries the knowledge base based on the business domain and operation type of the component (such as on-site survey operations or safe operating procedures) to obtain links or IDs of relevant regulations, technical standards, work instructions, and other documents, and establishes a mapping relationship between the component and the regulatory standard documents. This relationship enables the component to provide frontline employees with immediate standard guidance during execution.

[0061] Finally, the system embeds the aforementioned five types of metadata relationships into the end-to-end process model. Specifically, the system writes information such as the role ID, API address, rule ID, form template ID, and document link corresponding to each component into the process model file in a structured manner. In the technical implementation of BPMNXML, this information is typically bound to the corresponding activity element through extended attributes. After embedding, the end-to-end process model is no longer a simple description of process control logic, but an executable blueprint integrating complete execution resource information, which can be loaded and driven by the subsequent process execution platform.

[0062] This embodiment deeply binds the process model with execution roles, systems, rules, forms, and standards through metadata association, enabling precise task delivery and automatic cross-system invocation. The user terminal integrates pre-filled forms and real-time rule prompts, forming a unified task workbench. The process model is decoupled from business elements; changes to rules and standards do not require modifications to the model itself, supporting versioned management of process assets and agile business response.

[0063] In some embodiments, each atomic operation is encapsulated as a standardized component, including: obtaining each atomic operation and generating a unique identifier for the atomic operation; configuring preconditions and postconditions for the atomic operation; reserving element slots for the atomic operation, including form slots, rule slots, and knowledge slots, where form slots are used to associate business forms, rule slots are used to associate business rules, and knowledge slots are used to associate policy and standard documents; encapsulating the execution mode, timeout and alert mechanism, and transactional requirements of the atomic operation, where the execution mode includes automatic execution and manual execution, the timeout and alert mechanism includes defining the service level agreement time of the atomic operation and remedial actions after timeout, and the transactional requirements include data consistency requirements; and determining the encapsulated atomic operation as a standardized component.

[0064] A unique identifier is a globally unique code or ID generated for each atomic operation, used for unique identification, indexing, and retrieval of the component in the process component library. Preconditions refer to the data state or event conditions that must be met before an atomic operation can start. Postconditions refer to the data state or result that should be output after the atomic operation is completed. Element slots are standardized interfaces reserved within standardized components. The design of element slots decouples components from specific business content, allowing the same component to flexibly adapt to different business scenarios through "slot filling." Execution mode defines the degree of automation in which a component is called and executed in the process engine, including automatic execution and manual execution. Automatic execution means the component is completed automatically by the system without human intervention, such as automatic personnel matching or automatic notification sending; manual execution means the component requires manual operation by a designated position, such as on-site inspection or approval decision-making. The timeout and reminder mechanism is the Service Level Agreement (SLA) management rule for the process component, including both the SLA time and remedial actions after timeout. The Service Level Agreement (SLA) timeframe defines the time standard within which a component should complete its execution; post-timeout remedial actions define the automatic triggering mechanism after the SLA timeframe has expired. Transactional requirements are the guarantee of data consistency during the execution of process components. Transactional requirements ensure that all operations involved in a component either succeed completely or are completely rolled back, avoiding data inconsistencies.

[0065] The specific operation process of this embodiment is as follows.

[0066] The process building system first obtains the atomic operations to be encapsulated, which are derived from the operation-level decomposition results of key business activities. Then, the system generates a globally unique component identifier for this atomic operation.

[0067] Next, the system receives preconditions and postconditions input by the designer or extracted from historical logs. Preconditions specify the data state or event conditions that must be met before the component can start, such as "Application form has been verified," "Exploration resources are ready," and "Customer information is complete." Postconditions specify the data state or result that the component should output after execution, such as "Work order status = dispatched," "Approval result = approved," and "Customer information has been updated." Configuring preconditions and postconditions ensures that the component executes in the correct context and clearly defines the metrics for measuring execution effectiveness.

[0068] The system reserves form slots, rule slots, and knowledge slots for atomic operations. Form slots are used to mark which data fields the component needs to read or write; these can be associated with specific business form templates (such as electricity application forms or survey record forms) during workflow assembly. Rule slots are used to mark which rules might affect the component's execution logic; these can be associated with specific business rules (such as personnel matching rules or document verification rules). Knowledge slots are used to mark which institutional standards the component needs to refer to; these can be associated with specific regulatory documents (such as on-site survey operation guidelines or power safety work procedures). Element slots can be reserved by pre-defining the position and type of associated fields in the component's metadata structure, creating a fillable "empty space" without filling it with actual content.

[0069] The system also receives the execution mode configured by the designer, marking whether the component is "automatically executed" (completed automatically by the system) or "manually executed" (requiring manual operation). For "automatically executed" components, the system further encapsulates the system interfaces and automation logic it calls; for "manually executed" components, the system further encapsulates the user interface and interaction logic it needs to display to the user. Simultaneously, the system encapsulates the component's timeout and alert mechanisms, defining the component's SLA (e.g., "4 hours," "24 hours") and remedial actions after timeout (e.g., "automatically remind the handler," "transfer to the superior," "send timeout alarm"). Furthermore, the system encapsulates the component's transactional requirements, clarifying whether the component needs to guarantee data consistency during execution, such as "order dispatch and notification must succeed simultaneously or rollback simultaneously." After encapsulation, all behavioral characteristics of this atomic operation are solidified in the component definition.

[0070] Finally, the system formally defines the atomic operations after completing all the above encapsulation operations as standardized components and stores them in the process component library. When storing in the component library, the system will create multi-dimensional indexes for the component, including indexes by profession (such as "Operations and Maintenance", "Marketing"), by role (such as "Team Leader", "Operator"), by system (such as "Marketing System", "Production System"), and by keyword (such as "Dispatch", "Survey", "Approval"), so that it can be quickly retrieved and called during subsequent process assembly.

[0071] This embodiment transforms atomic operations into standardized components that can be independently stored, invoked, and reused by assigning unique identifiers and uniformly encapsulating them. By encapsulating execution modes, timeout and alert mechanisms, and transactional requirements, the components possess the capabilities for automatic execution, SLA monitoring, and data consistency assurance, upgrading them from static step descriptions to executable units. By reserving element slots, the components are decoupled from business forms, rules, and standards. The same component can be adapted to different scenarios through slot filling; changes in elements do not require modification of the component itself, improving the configurability and maintainability of the process.

[0072] In some embodiments, each standardized component is configured with an execution role corresponding to the operational entity of its associated value stage, and element slots are reserved for associating the outputs of its associated value stage, resulting in standardized process components, including:

[0073] Identify the value stage corresponding to each atomic operation, and determine the operation subject and output of the acquired value stage; retrieve the execution role corresponding to the operation subject from the unified job directory tree, and configure the execution role as the execution role of the standardized component; reserve form slots in the standardized component according to the data type and format of the output, and the form slots are used to associate business forms containing the output during process execution; reserve rule slots in the standardized component according to the usage rules of the output in the business process, and the rule slots are used to associate business rules related to the output during process execution; reserve knowledge slots in the standardized component according to the system standards on which the output is based, and the knowledge slots are used to associate system standard documents related to the output during process execution; and identify the standardized component with configured execution roles and reserved form slots, rule slots, and knowledge slots as the standardized process component.

[0074] The operation flow of this embodiment is as follows.

[0075] The process construction system first obtains the atomic operations to be processed and determines the value stage to which each atomic operation belongs. Since atomic operations are derived from the decomposition of key business activities, and key business activities belong to specific value stages, the system can obtain the value stage corresponding to the atomic operation through a pre-established mapping relationship. Subsequently, the system extracts the operating subject (e.g., "Marketing Department Customer Specialist + Operation and Maintenance Department Survey Specialist") and output (e.g., "Power Distribution Network Construction Requirements Survey Report") from the definition of that value stage.

[0076] Next, using the operation subject as the query condition, the unified job directory tree is accessed, mapping the operation subject (e.g., "Marketing Department Customer Specialist") to the specific job position stored in the directory tree (e.g., "Customer Specialist"). The system obtains complete information such as the unique identifier, job name, department, and job description of the position, and configures it as the execution role of the standardized component. This configuration operation essentially writes the execution role's ID and related information into the component's metadata, enabling the component to clearly identify "who will execute" at runtime.

[0077] Then, the system reserves slots for standardized components, and the reservation operation is as follows:

[0078] a. The system analyzes the data type (e.g., text, image, structured data) and format (e.g., PDF, JSON, table) of the output materials and reserves corresponding form slots in standardized components. Form slot reservation is achieved by pre-defining an empty space in the component's metadata structure for associating form templates, and marking the expected form type associated with that slot (e.g., "Approval Form Template" or "Survey Record Form Template"). For example, if the output material is a "Power Distribution Network Construction Needs Survey Report," which includes on-site survey photos and a customer-signed confirmation form, the system reserves a form slot that supports image uploads and signature collection. This form slot allows the component to dynamically associate the business forms containing the output materials during process execution, achieving decoupling of form content from component logic.

[0079] b. The system analyzes the usage rules of output materials within the business process, that is, the rules governing how the output materials are used, transferred, verified, or processed in subsequent stages. For example, the output material "Distribution Network Construction Requirements Survey Report" might involve usage rules such as "If the site photos in the survey report are unclear, return it for re-survey" or "If the customer's signature is missing, suspend the process." Based on the analysis results of these usage rules, the system reserves rule slots in standardized components, marking which rules might affect the component during execution. The reservation of rule slots allows components to dynamically associate with business rules related to the output materials during process execution, achieving decoupling between rule logic and component logic.

[0080] c. The system analyzes the institutional standards upon which the output is based, i.e., the regulations, technical standards, or work instructions that must be followed when generating or processing the output. For example, the output "Distribution Network Construction Needs Survey Report" may be based on institutional standards such as the "Distribution Network Construction Needs Survey Specification," "Site Survey Work Instructions," and "Power Safety Work Regulations." Based on the analysis results of these institutional standards, the system reserves knowledge slots in standardized components, marking which standard documents the component needs to refer to during execution. The reservation of knowledge slots allows components to dynamically associate with relevant institutional standard documents during process execution, providing frontline employees with immediate standard guidance.

[0081] The system will formally designate the standardized components that have completed all the above configurations and reserved operations as standardized process components. At this point, the process component differs from the previously generated general standardized components; it has been adapted to the operational entities and outputs of specific value stages, possessing clearly defined execution roles and element slots related to the outputs. The system will store the process component in the process component library as a "prefab" for subsequent process assembly, enabling direct use in specific business processes.

[0082] This embodiment maps operational subjects to specific execution roles, giving process components a clear "owner" identity and achieving seamless integration between process design and organizational structure. By reserving forms, rules, and knowledge slots based on the data type, usage rules, and standards of the outputs, a structured semantic association is established between process components and business outputs. During runtime, relevant forms, rules, and standards are automatically pushed to frontline employees, improving operational standardization and efficiency. Simultaneously, the configuration of execution roles and the reservation of element slots are independent operations, eliminating the need to repackage components when business changes occur, thus enhancing the maintainability and scalability of process components. Furthermore, in the business process management of power enterprises, after the end-to-end process model is built, it needs to be deployed to an execution platform to drive actual business operations. Currently, existing process execution platforms (such as traditional workflow engines) can typically only parse the node sequence and flow relationships of the process model, while the supporting elements involved in the model, such as execution roles, business forms, business rules, digital system interfaces, and institutional standards, are separated from the process execution logic. When tasks are pushed out, the platform can only send simple reminders to the executors. The executors must manually search for forms, review rules, and verify standards across multiple systems, a cumbersome and error-prone process. When the process reaches a certain stage, the platform lacks the ability to dynamically generate pre-filled forms based on metadata, embed rule prompts, and link knowledge documents, resulting in significant manual information processing and cross-system switching still required for frontline operations. Furthermore, contextual data (such as customer information and survey results) during process execution cannot be automatically transferred between components. After a task is completed, the next step must be manually triggered or hard-coded jumps must be used, making end-to-end automated closed-loop execution difficult to achieve.

[0083] To address the shortcomings or defects of related technologies, this application provides an end-to-end process execution method based on standardized components. This method can utilize the metadata relationships in the process model to achieve automatic assembly of task data packages, precise push, automatic transmission of context data, and intelligent advancement of the process, thereby improving the automation level of process execution and the efficiency of front-line operations.

[0084] In some exemplary embodiments of this application, such as Figure 2 As shown, the method includes steps S210-S250. This method can be applied to a process execution platform (which may be referred to as the platform, specifically a server or server cluster). The steps are described in detail below.

[0085] S210: In response to a triggering event, determine the target end-to-end process model.

[0086] A triggering event is an external or internal event that initiates a process instance, such as a customer submitting an electricity application through the online service hall, the system detecting a fault signal, or a change in the status of an approval form. Triggering events carry the raw data required to initiate the process.

[0087] The target end-to-end process model is an executable process model that matches the triggering event type, constructed according to the standardized component-based end-to-end process construction method provided in any of the above embodiments. This model is stored in BPMN XML file format and includes control flow logic, process component definitions, and metadata associations with the five supporting elements.

[0088] In this step, when an external or internal triggering event (such as a customer submitting an electricity application) arrives at the platform, the platform's event listening module captures the request and parses the event type (such as "new low-voltage installation"). Subsequently, the platform matches and determines the corresponding target end-to-end process model from the model repository based on the event type.

[0089] S220: Create a process instance based on the target end-to-end process model and its metadata associations, and initialize the context data container.

[0090] A process instance refers to a specific running copy of the target end-to-end process model. The process model is statically defined, while a process instance is a dynamically running entity, each with its own independent running state, context data, and execution path. The context data container is a structured storage space used to store all data during the execution of the process instance. This container persists throughout the entire lifecycle of the process instance, allowing various process components to read and write data, ensuring consistent data transfer between components.

[0091] In this step, after determining the target end-to-end process model, the process execution platform invokes the process engine. The process engine loads the BPMNXML definition of the model from the model repository and creates an independent process instance for it. Simultaneously, the engine initializes a context data container as the data storage space for the instance during its runtime. At this point, the process instance enters the "running" state.

[0092] S230: Write the raw data carried by the triggering event to the global variable area of ​​the context data container.

[0093] Raw data consists of business data carried by the triggering event, such as customer name, electricity address, requested capacity, and faulty equipment number. This data is the basic input for process execution and needs to be persistently stored in the process instance for use by subsequent components. The global variable area is the core storage area in the context data container, used to store globally accessible data throughout the entire process instance's lifecycle. Unlike local variables, data in the global variable area can be read and modified by any process component.

[0094] In this step, after the process instance is created, the platform writes the raw data carried by the triggering event (such as customer application information) into the global variable area of ​​the context data container. This data is stored in key-value pairs for subsequent process components to read and use when needed, avoiding repeated data transfer between components.

[0095] S240: During the process of process instance advancement, the target execution role corresponding to the current process component is determined based on the metadata association, and the task data package generated based on the metadata association is pushed to the terminal corresponding to the target execution role.

[0096] Metadata association refers to the mapping and binding relationship established between process components and the five supporting elements (execution roles, digital systems, business rules, business forms, and institutional standards), as detailed in the above embodiments. The current process component refers to the operation component currently awaiting execution, which the process engine has advanced to according to the control flow logic. The target execution role refers to the specific role responsible for executing the current process component, obtained from the unified job directory tree. This role information is bound to the component through metadata association. A task data package refers to a complete data set assembled for a pending task, containing information such as task ID, component definition, assembled form data, rule logic, document links, and system call entry points. The task data package enables the terminal to render a complete contextualized work interface.

[0097] In this step, as the process instance progresses, the engine reads the metadata relationships of the current process components to obtain the target execution role. Subsequently, the element integrator extracts context data from the global variable area based on the metadata relationships, and assembles it with the bound form templates, rules, and standard documents to generate a structured task data package. The task scheduler queries the currently on-duty personnel based on the target execution role and pushes the task data package to the corresponding personnel's terminals.

[0098] S250: Upon receiving the operation result data returned by the terminal, update the context data container based on the operation result data to proceed to the next process component.

[0099] Operation result data refers to the data returned by the user after completing the task on the terminal, including the form data filled in, the operation time, the operator information, the uploaded attachments, etc.

[0100] In this step, after the user completes and submits the task on the terminal, the platform receives the returned operation result data and writes it into the global variable area of ​​the context data container. Subsequently, the process engine determines the next step based on the control flow logic defined in the model and the updated context variables: if it is a normal sequential flow, it directly proceeds to the next component; if it is an exclusive gateway, it selects the corresponding branch based on the conditional expression; if it is a parallel gateway, it generates multiple pending tasks simultaneously. After the process is completed, the operation in S240 is repeated.

[0101] This embodiment, based on an end-to-end process model and its metadata relationships, creates process instances and initializes context data containers in response to trigger events, writing raw data to the global variable area to achieve instance-level data sharing. During process execution, the target execution role is dynamically determined based on metadata relationships, and an integrated task data package encompassing forms, rules, and knowledge is generated and pushed to the terminal based on the same metadata relationships. After the terminal sends back the result data, the context is automatically updated and the process continues, forming a closed loop of data write-back and process advancement.

[0102] In some embodiments, the process execution platform responds to a trigger event by determining the target end-to-end process model; creating a process instance based on the target end-to-end process model and its metadata associations, and initializing a context data container; writing the raw data carried by the trigger event into the global variable area of ​​the context data container; during the process instance advancement, determining the target execution role corresponding to the current process component based on the metadata associations, and pushing the task data package generated based on the metadata associations to the terminal corresponding to the target execution role; upon receiving the operation result data returned by the terminal, updating the context data container based on the operation result data to advance to the next process component, including:

[0103] (1) Capture the triggering event, determine the end-to-end process model in the model repository that corresponds to the event type of the triggering event as the target end-to-end process model, load the target end-to-end process model, create a process instance based on the target end-to-end process model and its metadata association, initialize the process context data container, write the original data carried by the triggering event into the global variable area of ​​the process context data container, and set the state of the process instance to running.

[0104] The model repository is a centralized repository for storing all published end-to-end process models (BPMN XML files). The model repository supports searching by event type, model name, version number, and other dimensions, ensuring that the process engine can quickly locate and load the target model. Event type refers to the business category to which the triggering event belongs, such as "low-voltage new installation," "high-voltage capacity expansion," and "distribution network fault repair." There is a mapping relationship between event types and end-to-end process models. The process context data container is a structured storage space used to store all data during the execution of a process instance, including a global variable area and a local variable area. The global variable area stores data shared across components, while the local variable area stores temporary data used internally by the component.

[0105] In this step, when an external triggering event (such as a customer submitting an electricity application through the online service hall) arrives at the platform, the platform's event listening module captures the request and parses its event type (e.g., "low-voltage new installation"). Subsequently, the platform performs a matching search in the model repository based on the event type, identifying the end-to-end process model corresponding to that event type as the target end-to-end process model. The platform loads the BPMNXML file of this model from the model repository and creates an independent process instance based on the model definition and its metadata relationships. Simultaneously, the platform initializes a process context data container to store all data during the instance's execution. The platform writes the raw data carried by the triggering event (such as customer name, electricity address, and applied capacity) into the global variable area of ​​the process context data container, serving as the data foundation shared by all subsequent components. Finally, the platform sets the process instance's status to "running," indicating that the process instance has officially entered the execution phase.

[0106] (2) Determine the current process component according to the target end-to-end process model, read the metadata configuration information of the current process component in the target end-to-end process model, the metadata configuration information includes the bound role identifier, form template identifier, rule identifier, system standard document link and system application programming interface address; extract the current process context data from the global variable area of ​​the process context data container, generate a pre-filled electronic form according to the current process context data and the bound form template, load the business rule corresponding to the rule identifier and compile it into verification logic or decision prompt, extract the system standard document fragment corresponding to the system standard document link; package the task identifier, component definition, pre-filled electronic form, verification logic or decision prompt, system standard document fragment and system application programming interface address into a task data package, store it in the task database, and set the status of the task data package to pending push.

[0107] Metadata configuration information comprises the complete configuration data of process components within the end-to-end process model, including bound role identifiers, form template identifiers, rule identifiers, links to policy and standard documents, and system API addresses. This configuration information is embedded into the model through metadata relationships when the process model is published and is read by the engine at runtime. The role identifier is a unique identifier for a position obtained from the unified job directory tree, used to locate the specific position responsible for executing the component. The form template identifier is a unique identifier for business form templates in the form template library, used to obtain the form's definition structure at runtime. The rule identifier is a unique identifier for business rules in the rule engine, used to obtain the logical definition of the rule at runtime. The policy and standard document link is an access link or storage path for policy and standard documents in the knowledge base, used to obtain the document content at runtime. The system API address is the call address for the digital system interface, used to achieve automatic inter-system calls at runtime. The current process context data comprises all data in the current running state of the process instance, stored in the global variable area of ​​the process context data container, including raw data carried by triggering events and intermediate data generated by executed components. Pre-filled electronic forms are dynamically generated fillable electronic forms based on the current process context data and form templates. Existing data has been extracted from the global variable area and populated into the corresponding fields, reducing repetitive user input. Validation logic or decision suggestions are front-end executable logic generated from business rules loaded from the rule engine after compilation. This is used for real-time validation (e.g., immediate reminder of "incorrect ID number format") or providing decision suggestions (e.g., "If capacity exceeds the threshold, supplementary approval is required"). Policy and standard document fragments are relevant chapters or summaries of policy and standard documents extracted from the knowledge base, used to display operational guidelines and regulatory basis to users in the task interface. A task data package is a complete data set assembled for a pending task, including task identifier, component definitions, pre-filled electronic forms, validation logic or decision suggestions, policy and standard document fragments, system API addresses, etc. The task data package is the core carrier for task push. The task database is a persistent repository for storing all pending and completed task data, supporting task status management and tracking.

[0108] In this step, the process engine begins execution according to the initial components defined in the model. When the engine progresses to a specific process component, it first reads the metadata configuration information of that component in the end-to-end process model, including the bound role identifier, form template identifier, rule identifier, policy standard document link, and system API address. Subsequently, the engine calls the element integrator to perform data assembly operations: the element integrator extracts the current process context data from the global variable area of ​​the process context data container, merges and renders it with the bound form template, generating an electronic form pre-filled with existing data; simultaneously, the element integrator loads the business rules corresponding to the rule identifier through the rule engine interface and compiles them into validation logic or decision prompts that can be embedded in the front-end interface; in addition, the element integrator extracts policy standard document fragments corresponding to the policy standard document link from the knowledge base, preparing them for front-end display. After assembly, the element integrator packages the task identifier, component definition, pre-filled electronic form, validation logic or decision prompts, policy standard document fragments, and system API address into a structured task data package, stores it in the task database, and sets the status of the task data package to "pending push".

[0109] (3) Scan the task data packets in the task database that are in the state of pending push, query the unified identity management system according to the role identifier bound in the task data packet, obtain the list of personnel with processing authority from the unified identity management system, push the task data packet to the terminal of the personnel corresponding to the personnel list, update the status of the task data packet to delivered, and record the push timestamp.

[0110] The unified identity management system is an enterprise-level identity authentication and access control system that stores basic information, job titles, on-duty status, and shift information for all personnel, and is used to determine the specific recipients of tasks.

[0111] In this step, the platform's task scheduler continuously scans the task database for task data packets with a status of "Pending Push". For each task awaiting push, the task scheduler queries the unified identity management system based on the role identifier bound to the task data packet. The unified identity management system returns a list of currently on-duty personnel with processing permissions. The task scheduler can then select one or more target personnel from this list, taking into account factors such as shift scheduling and load balancing. Subsequently, the task scheduler pushes the task data packet to the target personnel's to-do application interface in a terminal-appropriate format (e.g., JSON data packet for mobile devices, HTML fragment for desktop devices) via a message push service. Upon successful push, the task data packet's status is updated to "Delivered," and a push timestamp is recorded for subsequent response timeliness monitoring and SLA tracking.

[0112] (4) Receive the operation result data packet returned by the terminal, verify the integrity of the operation result data packet, and write the operation result data packet into the global variable area of ​​the process context data container after the verification is passed, and mark the task corresponding to the task identifier as completed; the operation result data packet is encapsulated and returned by the terminal after receiving the task data packet, rendering the task interface and obtaining the user operation data.

[0113] The operation result data packet is a complete data set returned by the terminal after the user completes a task. It includes filled-in form data, operation time, operator information, uploaded attachments, and operation result status. Integrity verification is the process of validating the returned operation result data packet, including checking whether required fields are filled, whether the data format meets requirements, and whether attachments are uploaded completely, to ensure that the received data meets business requirements.

[0114] In this step, after the user opens the task to be done on the terminal, the terminal application renders the task interface according to the received task data packet: displaying operation guidance (derived from a fragment of the system standard document), an editable business form (some fields are pre-filled), real-time rule prompts (derived from the compiled verification logic), and a button for one-click access to system functions (derived from the system API address). When the user completes the operation (such as filling in the survey record, uploading on-site photos) and clicks submit on the interface, the terminal encapsulates the filled form data, operation time, operator information, etc. into an operation result data packet and sends it back to the platform via the API. After receiving the operation result data packet, the platform's result receiving module first performs integrity verification, checking whether the required fields are filled in and whether the data format meets the requirements. After the verification is passed, the platform writes the business data in the operation result data packet into the global variable area of ​​the process context data container for use by subsequent components, and updates the task status corresponding to the task identifier to "completed". After that, the process engine determines the next step according to the control flow logic defined by the model and the updated global variables, and advances to the next process component, repeating the operations of steps (2) to (4) until the process instance is executed to the end node.

[0115] This embodiment automatically generates a task data package containing forms, rules, and standards by reading metadata configuration information and assembling it with an element integrator. This data is then precisely pushed to the terminals of on-duty personnel through a unified identity management system, achieving automated task flow. The terminal presents a contextualized work interface integrating pre-filled forms, real-time rule verification, and standard guidance, allowing users to complete tasks without switching between systems. Operation result data is dynamically updated with context after integrity verification, driving the process to automatically advance and forming a fully automated closed-loop operation. In some embodiments, after marking the task corresponding to the task identifier as completed, the method further includes:

[0116] (1) Determine the next step based on the control flow logic of the target end-to-end process model;

[0117] (2) When the control flow logic is sequential, return to the step of determining the current process component according to the target end-to-end process model;

[0118] (3) When the control flow logic is an exclusive gateway, read the variable values ​​in the global variable area of ​​the process context data container, calculate the condition expression, and select the corresponding branch to advance based on the calculation result;

[0119] (4) When the control flow logic is a parallel gateway, multiple tasks are generated at the same time, and the multiple tasks are pushed to the terminals of their respective execution roles in parallel.

[0120] (5) When the control flow logic is triggered by an event, start a timer and advance the next process component when the condition is met, or generate an exception handling task; update the global status view of the process instance in real time and push the latest progress to the terminals of all authorized process participants.

[0121] Exception handling tasks are automatically generated to handle abnormal situations such as timer timeouts, message non-delivery, or errors. Exception handling tasks may include timeout reminders, task handover, escalation processing, and rollback operations. The global status view provides a comprehensive overview of the process instance's current running status, including which component is currently being executed, the status of each pending task, completed components, and a summary of the process context data. The global status view provides process participants with a transparent view of the entire process. Authorized process participants are all personnel with permission to view this process instance, including the current executor, process owner, business manager, and monitoring personnel. Authorization information is managed through a unified identity management system.

[0122] After the process engine completes the execution of a process component and marks the task as "completed," the following steps are taken to determine the next step and advance the process:

[0123] First, the process engine reads the control flow definition of the target end-to-end process model to determine the type of control flow logic following the current component. Based on elements such as connections, gateway nodes, and boundary events in the model, the engine identifies the control logic to be executed next.

[0124] Next, when the control flow logic is sequential, the process engine determines the next process component after the current component according to the sequential relationship defined in the model, and returns to step (2) to continue execution.

[0125] When the control flow logic is an exclusive gateway, the process engine first reads the variable values ​​in the global variable area of ​​the process context data container to obtain all business data accumulated during the current process instance's execution. Then, the engine calculates the conditional expressions associated with the exclusive gateway, such as `${Data Integrity == 'Pass'}` and `${Voltage Level > 10}`. The engine selects the corresponding branch based on the calculation result (true or false) of the conditional expression. For example, if the calculation result of `${Data Integrity == 'Pass'}` is true, the "Pass" branch is selected, and the process proceeds to the "Dispatch Survey Work Order" component; if the result is false, the "Fail" branch is selected, and the process proceeds to the "Notify Customer to Make Corrections" component.

[0126] When the control flow logic is in the fork form of the parallel gateway, the process engine generates multiple pending tasks simultaneously, each corresponding to a process component on a parallel branch. The engine generates a task data packet for each pending task according to step (2), and pushes it in parallel to the terminal of its corresponding execution role according to step (3). All parallel tasks are executed independently without interference. When all tasks on all parallel branches are completed, the engine encounters the join form of the parallel gateway, waits for all parallel branches to reach the join point, merges them into a single execution path, and advances to the subsequent components.

[0127] When the control flow logic is event-triggered, the process engine identifies the event type and executes the corresponding processing. For timer events, the engine starts a timer, setting a preset time period (e.g., "24 hours") or time interval (e.g., "30 minutes"). The timer runs in the background, not blocking other operations in the process. When the time expires, the timer triggers, and the engine automatically advances to the next process component. If the expected trigger signal is not received before the timer expires, the engine generates an exception handling task, such as a timeout reminder, task handover, or escalation processing. For message events, the engine waits for the external message to arrive, and triggers process advancement upon message arrival; if no message is received within the timeout period, an exception handling task is also generated.

[0128] Throughout the entire process, the status synchronization module of the process execution platform updates the global status view of the process instance in real time. The status view records information such as which component is currently being executed, the status of each pending task (pending push, delivered, completed), a list of completed components, and an overview of the process context data. The status synchronization module uses the WebSocket protocol (which allows the server to proactively push data to the client without requiring repeated client requests) to push the latest progress to the terminals of all authorized process participants in real time, including the current executor, process owner, business manager, and monitoring personnel. Process participants can see the real-time status of the process instance on their terminals without manually refreshing, achieving transparency in the process execution.

[0129] This embodiment uses an exclusive gateway to achieve dynamic routing based on business data, replacing manual judgment and offline coordination; it uses a parallel gateway to execute independent tasks concurrently, shortening the process cycle; and it uses an event triggering mechanism to automatically handle asynchronous waiting scenarios, combined with timers and exception handling tasks, to achieve automatic timeout recovery, avoiding task backlog or forgetting, thereby improving the controllability and reliability of process execution.

[0130] In some embodiments, the method further includes: the process execution platform collecting runtime data of each process component in the current end-to-end process, the runtime data including average processing time, longest processing time, processing frequency, anomaly rate, and number of manual interventions, and forming a performance baseline for each process component based on the runtime data; the process execution platform extracting flow data between components from the logs of various professional systems through a process mining module, and constructing a component dependency graph based on the flow data; comparing the actual processing time of each process component with a preset service level agreement standard, and identifying process components with timeout frequency higher than a first preset threshold or time consumption fluctuation greater than a second preset threshold as inefficient components; the process execution platform identifying process components with queue length greater than a third preset threshold or waiting time greater than a fourth preset threshold as bottleneck nodes by analyzing the queue length and waiting time before and after the component; and calculating the price of each process component to the end customer based on the input and output data of each process component. The contribution value is used to include process components with a contribution value below the fifth preset threshold in the simplification list. The process execution platform identifies process components with duplicate content or overlapping functions through correlation analysis and marks them as candidates for merging. For process components that are manually executed and meet preset conditions, the process execution platform calls the automation potential analysis engine to make a judgment. The automation potential analysis engine generates an automation feasibility judgment result based on the degree of rule structuring of the process component, the degree of standardization of input data, and cross-system operation requirements. Process components that are judged to be automatable are marked as those that can be introduced into robotic process automation or automatic system execution. Inefficient components, bottleneck nodes, simplification list, merging candidates, and automatable process components are integrated into an optimization suggestion list. The optimization suggestions in the optimization suggestion list are simulated and verified in a sandbox environment. The simulation verification results are obtained, and the verified optimization suggestions are adopted and updated to the process component library.

[0131] This embodiment establishes a component performance baseline by collecting runtime data and constructs a dependency graph by combining process mining, enabling quantitative monitoring of process execution status. Inefficient components, bottleneck nodes, simplification items, merging items, and automation items are identified through multi-dimensional analysis and integrated into an optimization suggestion list. This list is then adopted and updated after simulation verification in a sandbox environment. This mechanism transforms process optimization from a passive response and localized patching to a data-driven model of proactive discovery, quantitative evaluation, and systematic verification, improving the accuracy and reliability of optimization.

[0132] In some embodiments, the method further includes: the process execution platform acquiring an enterprise-level process asset library; drawing an interaction relationship graph between multiple end-to-end processes based on the enterprise-level process asset library; identifying collaboration gaps by analyzing shared data entities, commonly dependent resources, or event triggering relationships between different processes; connecting with the business strategy management module, compliance requirement library, and customer feedback system; acquiring new business rules, policies and regulations, or customer complaint hotspots from the business strategy management module, compliance requirement library, and customer feedback system; and converting the new business rules, policies and regulations, or customer complaint hotspots into input conditions for new components; and generating specification definitions for new components based on the collaboration gaps and the input conditions for new components. The specification definitions include operation content, input data, output data, execution roles, and quality requirements. The task is as follows: Create a new component in the process design tool, and configure attribute definitions, element placeholders, and behavioral patterns for the new component. Attribute definitions include component name, key activity identifier, and version number. Element placeholders include form slots, rule slots, and knowledge slots. Behavioral patterns include execution mode, timeout and reminder mechanisms, and transactional requirements. Store the encapsulated new component in the process component library and add tags to the new component. Using a process modeling tool, insert the new component into the preset position of the relevant process in a visual manner, establish logical connections between the new component and the original components, run collaborative verification checks, verify the interface compatibility and role permission consistency of the new component with upstream and downstream components, obtain the verification results, and when the verification result is passed, determine the process model after inserting the new component as the enhanced process model.

[0133] This embodiment constructs an interaction relationship graph between end-to-end processes to identify collaboration gaps in shared data entities, common resource dependencies, and event triggering relationships, proactively discovering breakpoints and insufficient collaboration between processes. Simultaneously, it captures new business rules, policies and regulations, and customer complaint hotspots from the business strategy management module, compliance requirement library, and customer feedback system, transforming them into input conditions for new components. Based on collaboration gaps and requirements, new component specification definitions are generated. After component encapsulation and tagging in the process design tool, they are stored in the component library and inserted into relevant processes through visualization. After collaborative verification, an enhanced process model is formed, thereby achieving proactive identification of process gaps and agile generation of new components, supporting the rapid response and continuous optimization of the process system to business changes and collaboration needs.

[0134] In some embodiments, the method further includes: the process execution platform defining component-level value metrics for each process component, and defining process-level value metrics for the end-to-end process; the component-level value metrics include single-transaction processing time, first-time acceptance success rate, dispatch response time, automatic dispatch rate, site inspection time, first-time inspection pass rate, scheme preparation time, approval rate, construction overtime rate, and satisfaction score; the process-level value metrics include total process time, first-time pass rate, customer satisfaction, process cost, automation rate, overtime work order ratio, and resource utilization rate; runtime data and baseline data are collected from multiple data sources through application programming interfaces or direct database connection, and runtime data... Based on the start and end times, handlers, processing results, and anomaly markers of each process component, baseline data includes historical operational data of the process before optimization, preset service level agreement standard values, and industry benchmark values. The collected data is cleaned by removing test data, outliers, and incomplete records to obtain cleaned data. According to preset indicator definition formulas, the cleaned data is automatically calculated, grouped by process component identifier, to calculate the average time consumption, pass rate, and timeout rate of each process component within a specified period, obtaining component-level metrics. All process component data are associated by process instance identifier to calculate the total duration, one-time pass result, and total cost of each complete process instance, aggregating to obtain process-level metrics. The calculation results are written to the analysis data warehouse and time-stamped. Multi-dimensional comparison analysis is performed according to preset comparison rules. This multi-dimensional comparison analysis includes: vertical comparison of the current period data with the baseline data before optimization; horizontal comparison of data from different regions or different work groups; target comparison of the current data with the service level agreement target value; and trend analysis by plotting trend lines for data from multiple consecutive periods. When an anomaly is detected during the comparison, the process execution platform triggers drill-down analysis, checks the task list of the abnormal component to identify the type of task with abnormal time consumption, correlates and analyzes the input data of the abnormal component to determine the cause of the increased time consumption, retrieves the logs of the abnormal component to analyze system call failure or retry records, and performs analysis. The results are integrated into insights described in natural language; the analysis results are dynamically presented in the form of a dashboard, which includes an overview area, component heatmaps, trend charts, comparison cards, and an alert list. The overview area displays the core indicators of the end-to-end process and their month-on-month changes; the component heatmap uses color intensity to indicate the efficiency of each component; the trend chart shows the changing trends of key indicators; the comparison cards show the comparison of indicators before and after optimization; and the alert list lists indicators that have not met the standards and suggested areas for improvement. A process optimization comparison report is automatically generated according to a preset cycle. The process optimization comparison report includes a data overview for this period, a comparison of key indicators, bottleneck analysis, and optimization suggestions. The process optimization comparison report is pushed to process owners, operations managers, and relevant decision-makers.

[0135] This embodiment achieves quantitative evaluation of business processes by establishing a dual-layer value measurement indicator system at the component and process levels. Multi-source data collection and cleaning based on direct API and database connections, combined with automated indicator calculation, forms component-level and process-level metrics. Through vertical, horizontal, and target comparisons and trend analysis, abnormal indicators are identified and drill-down analysis is triggered to pinpoint root causes and generate natural language insights. Core indicators, heatmaps, trend charts, and warning lists are dynamically presented on a dashboard, and optimization comparison reports are automatically generated and pushed to relevant personnel. This mechanism transforms process management from experience-driven to data-driven, providing quantitative evidence, root cause analysis, and closed-loop decision support for process optimization.

[0136] For specific limitations on the end-to-end process construction method based on standardized components, please refer to the limitations on the end-to-end process construction method based on standardized components mentioned above, which will not be repeated here.

[0137] It should be noted that, regarding the various steps included in the end-to-end process construction method and the end-to-end process execution method based on standardized components provided in any of the above embodiments, unless explicitly stated herein, there is no strict order restriction on the execution of these steps; these steps can be executed in other orders. Moreover, at least some of these steps may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these sub-steps or stages is not necessarily sequential, but can be executed alternately or in turn with other steps or at least a portion of the sub-steps or stages of other steps.

[0138] This application also provides a computer device. In some embodiments, the computer device includes a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it can implement the end-to-end process construction method based on standardized components or the end-to-end process execution method based on standardized components provided in any of the above embodiments.

[0139] In some embodiments, the internal structure diagram of a computer device may be as follows: Figure 3As shown. The computer device includes a processor, memory, and network interface connected via a system bus. The processor provides computing and control capabilities. The memory includes a non-volatile storage medium and internal memory. The non-volatile storage medium stores an operating system, computer programs, and a database. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage medium. The database stores process design data, end-to-end process models, and their metadata relationships for end-to-end process projects; the specific stored data may also be as defined in the above method embodiments. The network interface communicates with external terminals via a network connection. When the computer program is executed by the processor, it implements an end-to-end process construction method based on standardized components, or an end-to-end process execution method based on standardized components.

[0140] Those skilled in the art will understand that Figure 3 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0141] This application also provides a computer-readable storage medium, in some embodiments of which a computer program is stored on the computer-readable storage medium. When the computer program is executed by a processor, it implements the end-to-end process construction method based on standardized components or the end-to-end process execution method based on standardized components provided in any of the above embodiments.

[0142] In the above embodiments of this application, the descriptions of each embodiment have their own emphasis. Parts not described in detail in a particular embodiment can be found in the relevant descriptions of other embodiments. Furthermore, the above embodiments only illustrate several implementation methods of this application, and their descriptions are relatively specific and detailed, but they should not be construed as limiting the scope of the invention patent. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this patent application should be determined by the appended claims.

Claims

1. A method for constructing an end-to-end process based on standardized components, characterized in that, The method includes: Acquire end-to-end process design data for a power company's process projects. This data includes multiple value stages, multiple key business activities within each value stage, atomic operation sequences corresponding to each key business activity, and the operating entity and outputs corresponding to each value stage. Each atomic operation sequence includes collaborative operations between at least two departments within the power company's marketing, operations and maintenance, infrastructure, and finance departments. Each atomic operation is encapsulated as a standardized component. Each standardized component is configured with an execution role corresponding to the operating entity of its associated value stage, and element slots are reserved for associating with the outputs of its associated value stage, resulting in standardized process components. These standardized process components are then stored in a process component library. In response to orchestration instructions, multiple process components corresponding to various value stages related to the target business scenario are selected from the process component library. Starting with the customer's needs and ending with the fulfillment of those needs, control flow logic is established between the selected process components to generate an end-to-end process model. Metadata associations are then established between each process component in the end-to-end process model and supporting elements. The end-to-end process model and the metadata associations are then deployed to the process execution platform. The supporting elements include execution roles, digital systems, business rules, business forms, and institutional standards. The step of establishing metadata associations between each process component and supporting elements in the end-to-end process model includes: Obtain each process component in the end-to-end process model; For each of the process components, the execution role is obtained from the unified job directory tree, and a first metadata association relationship is established between the process component and the execution role; Obtain the interface address of the digital system from the system application programming interface address library, and establish a second metadata association between the process component and the digital system; Obtain business rules from the rules engine and establish a third-party metadata association between the process components and the business rules; Obtain business forms from the form template library and establish a fourth metadata association between the process components and the business forms; Obtain institutional standard documents from the knowledge base and establish a fifth metadata association between the process components and the institutional standard documents; The first metadata association, the second metadata association, the third metadata association, the fourth metadata association, and the fifth metadata association are embedded in the end-to-end process model; The encapsulation of each atomic operation into a standardized component includes: Obtain each atomic operation and generate a unique identifier for each atomic operation; Configure preconditions and postconditions for the atomic operations; Element slots are reserved for the atomic operations. The element slots include form slots, rule slots, and knowledge slots. The form slots are used to associate business forms, the rule slots are used to associate business rules, and the knowledge slots are used to associate policy and standard documents. The execution mode, timeout and alert mechanism, and transaction requirements of the atomic operation are encapsulated. The execution mode includes automatic execution and manual execution. The timeout and alert mechanism includes defining the service level agreement time of the atomic operation and the remedial actions after timeout. The transaction requirements include data consistency requirements. The encapsulated atomic operations are identified as standardized components.

2. The method according to claim 1, characterized in that, The process begins with the customer's needs and ends with their fulfillment, establishing control flow logic between selected process components to generate an end-to-end process model, including: The target business scenario is identified as multiple value stages, which begin with the customer's demand and end with the customer's demand being met. A swimlane is created for each value stage using a process modeling tool, and role zones are defined within the swimlane of each value stage based on the operating entity corresponding to each value stage. Select process components corresponding to each value stage from the process component library, place the selected process components into the role bands of the corresponding swimlanes, establish sequential flow, parallel gateway and exclusive gateway logical relationships for the selected process components, and generate an end-to-end process model with full-chain logic that meets customer needs.

3. The method according to claim 1, characterized in that, The process involves configuring an execution role corresponding to the operational entity of each standardized component at its associated value stage, and reserving element slots for associating the outputs of the associated value stages, resulting in standardized process components, including: Obtain the value stage corresponding to each atomic operation, and determine the operation subject and output of the obtained value stage; Obtain the execution role corresponding to the operation subject from the unified job directory tree, and configure the execution role as the execution role of the standardized component; Based on the data type and format of the output, a form slot is reserved in the standardized component. The form slot is used to associate a business form containing the output during process execution. Based on the usage rules of the output in the business process, rule slots are reserved in the standardized components. The rule slots are used to associate business rules related to the output during process execution. Based on the institutional standards upon which the output is based, a knowledge slot is reserved in the standardization component. The knowledge slot is used to associate the institutional standard documents related to the output during process execution. The standardized components that have been configured with execution roles and have reserved form slots, rule slots, and knowledge slots are identified as standardized process components.

4. An end-to-end process execution method based on standardized components, characterized in that, The method includes: In response to a triggering event, a target end-to-end process model is determined; the target end-to-end process model is constructed according to the method of any one of claims 1-3; A process instance is created based on the target end-to-end process model and its metadata associations, and a context data container is initialized. Write the original data carried by the triggering event into the global variable area of ​​the context data container; During the process instance advancement, the target execution role corresponding to the current process component is determined based on the metadata association, and the task data package generated based on the metadata association is pushed to the terminal corresponding to the target execution role. Upon receiving the operation result data returned by the terminal, the context data container is updated according to the operation result data to advance to the next process component.

5. The method according to claim 4, characterized in that, In response to a triggering event, the process execution platform determines the target end-to-end process model; creates a process instance based on the target end-to-end process model and its metadata associations, and initializes the context data container; Write the original data carried by the triggering event into the global variable area of ​​the context data container; During the process instance advancement, the target execution role corresponding to the current process component is determined based on the metadata association, and the task data package generated based on the metadata association is pushed to the terminal corresponding to the target execution role. Upon receiving the operation result data returned by the terminal, the context data container is updated according to the operation result data to proceed to the next process component, including: Capture the triggering event, determine the end-to-end process model in the model repository that corresponds to the event type of the triggering event as the target end-to-end process model, load the target end-to-end process model, create a process instance based on the target end-to-end process model and its metadata association, initialize the process context data container, write the original data carried by the triggering event into the global variable area of ​​the process context data container, and set the state of the process instance to running. The current process component is determined according to the target end-to-end process model. The metadata configuration information of the current process component in the target end-to-end process model is read. The metadata configuration information includes the bound role identifier, form template identifier, rule identifier, system standard document link, and system application programming interface address. The current process context data is extracted from the global variable area of ​​the process context data container. A pre-filled electronic form is generated according to the current process context data and the bound form template. The business rule corresponding to the rule identifier is loaded and compiled into verification logic or decision prompt. The system standard document fragment corresponding to the system standard document link is extracted. The task identifier, component definition, pre-filled electronic form, verification logic or decision prompt, system standard document fragment, and system application programming interface address are packaged into a task data package, stored in the task database, and the status of the task data package is set to pending push. Scan the task data packets in the task database that are in the state of pending push, query the unified identity management system according to the role identifier bound in the task data packet, obtain the list of personnel with processing authority from the unified identity management system, push the task data packet to the terminal of the personnel corresponding to the personnel list, update the status of the task data packet to delivered, and record the push timestamp. The system receives the operation result data packet returned by the terminal, performs integrity verification on the operation result data packet, and writes the operation result data packet into the global variable area of ​​the process context data container after the verification is successful, and marks the task corresponding to the task identifier as completed; the operation result data packet is encapsulated and returned by the terminal after receiving the task data packet, rendering the task interface and obtaining user operation data.

6. The method according to claim 5, characterized in that, After marking the task corresponding to the task identifier as completed, the method further includes: The next step is determined based on the control flow logic of the target end-to-end process model. When the control flow logic is sequential, return to the step of determining the current process component according to the target end-to-end process model; When the control flow logic is an exclusive gateway, the variable values ​​in the global variable area of ​​the process context data container are read, the conditional expression is calculated, and the corresponding branch is selected to proceed based on the calculation result. When the control flow logic is a parallel gateway, multiple pending tasks are generated simultaneously, and the multiple pending tasks are pushed in parallel to the terminals of their respective execution roles. When the control flow logic is event-triggered, a timer is started, and the next process component is advanced when the condition is met, or an exception handling task is generated. The global status view of the process instance is updated in real time, and the latest progress is pushed to the terminals of all authorized process participants.

7. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the method of any one of claims 1 to 6.

8. A computer device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the method according to any one of claims 1 to 6.

Images