Workflow SOP saves and calling method, device, equipment, medium and product

Abstract

The application discloses a workflow SOP saving and calling method, device, equipment, medium and product, relates to the technical field of industrial data analysis and process automation, and comprises the following steps: carrying out structural analysis on a historical session, extracting a candidate step set, screening the candidate step set based on a preset condition, structurally packaging a standard step set according to an execution sequence, generating an SOP definition object, storing the SOP definition object, forming a callable SOP asset, loading a target SOP asset, obtaining an initial data set requirement in the target SOP asset, carrying out integrity checking and existence checking on a data mapping relationship, generating an independent controlled execution context and a running identifier, generating a structured event stream and a step-level execution result set, generating a business-readable calling summary text, and forming a traceable audit link. The application can convert a temporary analysis session into a manageable, identifiable and callable standardized process asset.

Description

Technical Field

[0001] This application relates to the field of industrial data analysis and process automation technology, and in particular to a method, apparatus, equipment, medium and product for saving and recalling workflow standard operating procedures (SOPs). Background Technology

[0002] With the development of industrial internet and artificial intelligence technologies, industrial data analytics platforms are widely used in scenarios such as production monitoring, quality traceability, and predictive maintenance of equipment. Users typically complete specific data analysis tasks through interactive sessions (including natural language queries, drag-and-drop analysis, script execution, etc.).

[0003] Existing technologies mainly focus on the following areas: natural language to SQL or natural language-driven data retrieval; automatic chart generation, automatic report writing and automatic insight output; industry question answering and semantic understanding combining large models with knowledge bases; and intelligent analysis and result generation for single tasks.

[0004] Most of the above solutions focus on "letting the system answer questions" or "letting the system generate results," while paying less attention to "how to transform an effective analysis process into a reusable, traceable, and standardized process asset." Therefore, existing technologies suffer from the following problems: (1) The process is difficult to be captured and reused by the system: In the existing technology, the analysis process usually exists in the mind of the operator or is scattered in chat records and script fragments. There is a lack of means to perform structured analysis of historical sessions, and it is impossible to transform unstructured temporary operations into structured data that can be identified and processed by the system. As a result, successful analysis experience is difficult to be captured and reused by the system.

[0005] (2) Lack of a screening mechanism for the reusability of steps: The existing solution lacks a screening mechanism for whether historical steps are recoverable, reusable and traceable. Usually, all successfully executed operations are saved, resulting in a large number of temporary and non-replayable steps that depend on uncontrollable external environments, have incomplete parameters or untraceable side effects being incorrectly saved as reusable processes. These steps frequently fail when called, seriously affecting the reliability of reuse.

[0006] (3) The storage method is rudimentary and it is difficult to support automated reuse: The existing technology has a relatively primitive way of storing the analysis process, either only saving the script text (lacking step status and dependency relationship) or only saving the dialogue record (which cannot be automatically executed), making it difficult to standardize and structure the analysis process and save it as an asset that can be directly called by the system, thus failing to achieve the goal of "save once and reuse many times".

[0007] (4) Lack of data verification mechanism when migrating across scenarios: When the old process is migrated to the new dataset for execution, the existing solution lacks explicit data mapping and verification mechanism. Users can only manually replace the new dataset from memory, which is very easy to cause missing or wrong mapping, resulting in incorrect or missing data or execution errors, and it is difficult to troubleshoot.

[0008] (5) Poor execution environment isolation: Existing solutions usually replay the old process directly in the original session environment, which leads to the mixing of historical running state and current state, resulting in data pollution and unreliable results. It is impossible to guarantee the consistency and stability of the same process in different calling scenarios.

[0009] (6) The process is not observable and the result is not interpretable: When the existing system executes the reuse process, it usually only tells "execution successful" or "execution failed", or only outputs the final result, without outputting the execution status, products and abnormal information of the intermediate steps. Business personnel cannot understand what happened in the process, nor can they understand how the result was generated.

[0010] (7) Lack of complete audit traceability: Most systems only save the final result, without saving the complete step chain, parameter changes, data mapping relationship and execution process. This makes it difficult to meet the requirements of review, compliance and responsibility definition in industrial scenarios. When the analysis results have problems, it is impossible to locate which step or which data mapping link has deviated. Summary of the Invention

[0011] The purpose of this application is to provide a method, apparatus, device, medium, and product for saving and recalling workflow Standard Operating Procedures (SOPs). This method can transform unstructured, non-reproducible, temporary operations into standardized candidate step data that can be parsed and processed by a computer; eliminate non-reusable steps at the source, significantly reducing replay failure rates and ensuring that every step entering the SOP definition object is a standardized work unit that can be stably executed in a controlled environment; transform one-off, temporary analysis sessions into manageable, identifiable, and recallable standardized process assets; achieve secure migration across data instances and an explicit, verifiable data mapping mechanism; achieve a unified approach to execution environment isolation and result reproducibility; enable step-by-step observability of the process and interpretable execution results, allowing non-technical users to understand the complete execution of the call without having to check each underlying event; and achieve complete traceability, meeting the requirements of industrial scenarios for process review, responsibility definition, process compliance, and problem localization.

[0012] To achieve the above objectives, this application provides the following solution: Firstly, this application provides a method for saving and recalling workflow SOPs, including: The historical sessions are structured and parsed to extract a set of candidate steps, which includes at least a step sequence, execution status, input parameters, and data dependencies. The candidate step set is filtered based on preset conditions to obtain a standard step set. The preset conditions include execution success, operation recoverability, parameter integrity, side effect traceability, and data dependency defineability. The set of standard steps is structured and encapsulated in the order of execution to generate an SOP definition object. The SOP definition object includes an SOP identifier, initial dataset requirements, a sequence of standard steps, and inter-step dependency constraints. The SOP definition object is stored to form an SOP asset that can be called. Load the target SOP asset based on the SOP identifier in the call request, and obtain the session identifier of the current session; The initial dataset requirements in the target SOP asset are obtained as a baseline requirement set, and the data mapping relationship in the call request is received. The integrity and existence of the data mapping relationship are verified based on the baseline requirement set. When the verification passes, the mapped running data view is established. The data mapping relationship is used to map the original dataset identifier to the current session dataset identifier. An independent controlled execution context and a run identifier are generated based on the current session environment, and the run identifier is associated with this call; Using the controlled execution context as the execution carrier, the standard steps in the target SOP asset are executed one by one, and a structured event flow and a set of step-level execution results are generated during the execution process. Based on the step-level execution result set and the structured event stream, generate a business-readable call summary text; The session identifier, SOP identifier, run identifier, data mapping relationship, step-level execution result and call summary text are associated and stored to form a traceable audit link.

[0013] Optionally, the workflow SOP saving and calling method further includes: versioning the SOP definition object and recording version information and historical copies.

[0014] Optionally, the step of performing integrity and existence checks on the data mapping relationship based on the baseline demand set specifically includes: Based on the aforementioned baseline requirement set, verify whether each original dataset has been mapped to the current session dataset identifier through the aforementioned data mapping relationship; if any are not mapped, the verification fails. Verify whether the current session dataset identifier pointed to by the data mapping relationship is valid; if invalid, the verification fails. A mapped runtime data view is constructed based on the verified mapping relationship. The runtime data view uses the original dataset identifier for access and is bound to the data corresponding to the current session dataset identifier pointed to by the data mapping relationship.

[0015] Optionally, generating an independent controlled execution context and runtime identifier based on the current session environment specifically includes: A new runtime context is generated by copying the current session environment; In the new runtime context, the original dataset identifier is bound to the data corresponding to the current session dataset identifier through the data mapping relationship; Bind the data source generation state recorded when the SOP asset is saved to the new runtime context; Generate an independent running identifier and establish an association between the running identifier and the data mapping relationship.

[0016] Optionally, the step of executing the standard steps in the target SOP asset one by one specifically includes, for each standard step: Read the operation type and step parameters of the standard steps; The step parameters are subjected to executable filtering, retaining only the parameter fields actually required for the operation type; The standard steps are executed within the controlled execution context, and structured events corresponding to the standard steps are output during the execution process; the structured events include start events, result events, or exception events. The execution results of the standard steps are written into the execution record of this call in a structured form.

[0017] Optionally, the call summary text shall include at least: SOP name and call background, completion status of each step, key output results, new data objects or intermediate products generated during execution, exception descriptions, and an overall conclusion description based on business understanding.

[0018] Secondly, this application provides a workflow SOP saving and recall device, comprising: The session extraction module is used to perform structured parsing of historical sessions and extract a set of candidate steps. The set of candidate steps includes at least a step sequence, execution status, input parameters, and data dependencies. A standard filtering module, connected to the session extraction module, is used to filter the candidate step set based on preset conditions to obtain a standard step set. The preset conditions include execution success, operation recoverability, parameter integrity, side effect traceability, and data dependency defineability. The SOP definition building module, connected to the standard filtering module, is used to structurally encapsulate the set of standard steps in the execution order to generate an SOP definition object. The SOP definition object includes an SOP identifier, initial dataset requirements, a sequence of standard steps, and inter-step dependency constraints. The persistence and version management module is connected to the SOP definition construction module and is used to store the SOP definition object to form an SOP asset that can be called. The call control module, connected to the persistence and version management module, is used to receive call requests, load the target SOP asset according to the SOP identifier in the call request, and obtain the session identifier of the current session; The data mapping module, connected to the call control module, is used to obtain the initial dataset requirements in the target SOP asset as a baseline requirement set; and to receive the data mapping relationship in the call request, and to perform integrity and existence checks on the data mapping relationship based on the baseline requirement set; when the checks pass, a mapped runtime data view is established, and the data mapping relationship is used to map the original dataset identifier to the current session dataset identifier. The context management module, connected to the data mapping module, is used to generate an independent controlled execution context and a run identifier based on the current session environment, and associate the run identifier with the current call; The sequential replay module, connected to the context management module and the call control module, is used to execute the standard steps in the target SOP asset one by one, using the controlled execution context as the execution carrier, and to generate a structured event stream and a set of step-level execution results during the execution process. The summary generation module, connected to the sequential replay module, is used to generate a business-readable call summary text based on the step-level execution result set and the structured event stream. The traceability management module is connected to the call control module, the data mapping module, the sequential replay module, and the summary generation module. It is used to associate and store the session identifier, SOP identifier, run identifier, data mapping relationship, step-level execution result, and call summary text of this call to form a traceable audit link.

[0019] Thirdly, 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 steps of the workflow SOP saving and recall method described in any one of the above.

[0020] Fourthly, this application provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the workflow SOP saving and recall method described above.

[0021] Fifthly, this application provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the workflow SOP saving and recall method described above.

[0022] According to the specific embodiments provided in this application, the following technical effects are disclosed: This application provides a method, apparatus, device, medium, and product for saving and recalling workflow SOPs. By performing a step of "structural parsing of historical sessions and extracting a set of candidate steps," it solves the problem of "process black boxes" in existing technologies where the analysis process is scattered in the operator's mind or chat logs and cannot be recognized and processed by the system. It transforms unstructured, non-reproducible temporary operations into standardized candidate step data that can be parsed and processed by the computer. By performing a step of "filtering the set of candidate steps based on preset conditions to obtain a set of standard steps," it solves the problem in existing technologies where the lack of a screening mechanism to determine whether historical steps are recoverable, reusable, and traceable leads to temporary, non-replayable operations being mistakenly included in the reuse process. This eliminates non-reusable steps at the source, significantly reduces the replay failure rate, and ensures that every step entering the SOP definition object is a standardized work unit that can be stably executed in a controlled environment. By employing the steps of "structurally encapsulating the standard step set according to the execution order to generate SOP definition objects" and "storing the SOP definition objects to form callable SOP assets," the problem of difficulty in standardizing and structurally saving the analysis process as a reusable asset in existing technologies is solved. This transforms one-off, temporary analysis sessions into manageable, identifiable, and callable standardized process assets. Furthermore, by employing the steps of "obtaining the initial dataset requirements from the target SOP asset as a baseline requirement set, receiving the data mapping relationships from the call request, and performing integrity and existence checks on the data mapping relationships based on the baseline requirement set; when the checks pass, establishing a mapped running data view," the problem of errors and omissions caused by directly executing old processes when the dataset changes is solved in existing technologies. This achieves secure migration across data instances and an explicit, verifiable data mapping mechanism. By using the steps "generating an independent controlled execution context and a run identifier based on the current session environment, and associating the run identifier with this call" and "using the controlled execution context as the execution carrier, executing each step in the standard sequence of steps in the target SOP asset," the problem of existing technologies directly replaying old processes in the current session environment, leading to a mixture of historical and current states and unreliable results, is solved. This achieves a unified approach of execution environment isolation and result reproducibility. By using the steps "generating a structured event stream and a set of step-level execution results during execution" and "generating a business-readable call summary text based on the set of step-level execution results and the structured event stream," the problem of existing technologies only outputting the final result, making the process unobservable, and preventing business personnel from understanding the execution details is solved. This achieves a process that is progressively observable and the execution results that are interpretable, allowing non-technical users to understand the complete execution of this call without having to check each underlying event.By linking and storing session identifiers, SOP identifiers, run identifiers, data mapping relationships, step-level execution results, and call summary texts to form a traceable audit link, the problem of existing technologies that only save the final result and cannot meet the review and compliance requirements in industrial scenarios is solved. It realizes complete link traceability from "session initiation → SOP selection → data mapping → execution of each step → final result", which meets the requirements of industrial scenarios for process review, responsibility definition, process compliance, and problem location. Attached Figure Description

[0023] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0024] Figure 1 This is an application environment diagram of a workflow SOP saving and recall method in one embodiment of this application; Figure 2 A flowchart illustrating a workflow SOP saving and recall method provided in an embodiment of this application; Figure 3 A schematic diagram of the functional modules of a workflow SOP saving and recall device provided in an embodiment of this application; Figure 4 This is a schematic diagram of the structure of a computer device provided in an embodiment of this application. Detailed Implementation

[0025] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0026] To make the above-mentioned objectives, features and advantages of this application more apparent and understandable, the application will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0027] The workflow SOP saving and recall method provided in this application embodiment can be applied to, for example... Figure 1In the application environment shown, terminal 102 communicates with server 104 via a network. A data storage system can store the data that server 104 needs to process. The data storage system can be set up independently, integrated into server 104, or placed in the cloud or on other servers. Terminal 102 can send historical analysis sessions to server 104. After receiving the historical analysis sessions, server 104 performs structured parsing of the sessions and extracts a set of candidate steps containing step sequences, execution states, input parameters, and data dependencies. Based on preset conditions, the set of candidate steps is filtered to obtain a set of standard steps. The set of standard steps is then structured and encapsulated according to the execution order to generate and store SOP definition objects, forming a callable SOP asset. When terminal 102 initiates an SOP call request, server 104 loads the target SOP asset based on the SOP identifier in the call request and obtains the session identifier of the current session; it obtains the initial dataset requirements in the target SOP asset as a baseline requirement set, receives the data mapping relationship in the call request, and performs integrity and existence checks on the data mapping relationship based on the baseline requirement set; when the checks pass, it establishes a mapped runtime data view; it generates an independent controlled execution context and runtime identifier based on the current session environment, and associates the runtime identifier with this call; using the controlled execution context as the execution carrier, it executes the standard step sequence in the target SOP asset one by one, and generates a structured event stream and a step-level execution result set during the execution process; based on the step-level execution result set and the structured event stream, it generates a business-readable call summary text; it associates and stores the session identifier, SOP identifier, runtime identifier, data mapping relationship, step-level execution result, and call summary text to form a traceable audit link. Server 104 can feed back the obtained call summary text and / or audit link to terminal 102. In addition, in some embodiments, the workflow SOP saving and calling method can also be implemented by the server 104 or the terminal 102 separately. For example, the terminal 102 can directly save the SOP for the historical analysis session, or the terminal 102 can directly initiate the SOP call and execute all calling steps; or the server 104 can obtain the historical analysis session or SOP asset from the data storage system and perform the corresponding saving and calling process.

[0028] The terminal 102 can be, but is not limited to, various desktop computers, laptops, industrial computers, workstations, smartphones, and tablets. The server 104 can be implemented using a standalone server or a server cluster consisting of multiple servers, or it can be a cloud server.

[0029] In one exemplary embodiment, such as Figure 2As shown, a method for saving and recalling a workflow SOP is provided. This method is executed by a computer device, specifically by a terminal or server alone, or by both a terminal and a server. In this embodiment, the method is applied to... Figure 1 Taking server 104 as an example, the explanation includes the following steps 201 to 210. Wherein: Step 201: Perform structured parsing on the historical sessions and extract a set of candidate steps. The set of candidate steps shall at least include the step sequence, execution status, input parameters and data dependencies. Specifically, a historical session refers to a complete record of operations performed by a user during a specific analysis task (such as equipment fault diagnosis, quality anomaly tracing, process parameter optimization, etc.) within an industrial data analysis platform. The historical session records a series of operations performed by the user during the analysis process and their contextual information. Since historical sessions are typically in unstructured form (such as natural language interaction records, operation logs, script execution records, etc.), they need to be parsed and converted into structured, processable data.

[0030] For each operation step in the historical session, extract the candidate step set: Step sequence: The execution order of each operation step in the historical session. Each step is assigned a step number according to the time sequence in which the operation occurred, forming an ordered step sequence.

[0031] Execution status: The execution result status of each step, such as "success", "failure" or "abnormal interruption", which can be used to determine the success of subsequent execution.

[0032] Input parameters: The parameter information used during the execution of each step, including parameter name, parameter value, and parameter type. For example, for the "clean null values" operation, input parameters may include a threshold (e.g., 0.1), the name of the column to be processed, etc.; for the "train model" operation, input parameters may include the algorithm type (e.g., random forest), hyperparameters (e.g., number of trees 100, maximum depth 10), etc.

[0033] Data Dependencies: The identifiers of the datasets that a step depends on and their flow relationships. Specifically, this includes which previous step's output the input dataset for each step comes from, and which new datasets this step outputs. For example, step 2 depends on the "cleaned logs" dataset output by step 1, and step 3 depends on the "feature table" dataset output by step 2.

[0034] Results information: The results generated after each step is executed, such as newly generated dataset identifiers, model object identifiers, visualization charts, etc.

[0035] Relationship between steps and sessions: Record the session identifier to which each step belongs, as well as the successor-successor relationship between steps.

[0036] Running status information related to the data source generation, such as random seeds and data partitioning information, is used to ensure the reproducibility of results during subsequent replays.

[0037] Step 202: Filter the candidate step set based on preset conditions to obtain a standard step set. The preset conditions include execution success, operation recoverability, parameter integrity, side effect traceability, and data dependency defineability. Specifically, each candidate step in the candidate step set is standardized one by one, and only steps that simultaneously meet all preset conditions are retained as standard steps. The preset conditions include: (1) Execution success determination Read the "Execution Status" field in the candidate steps. Only if the value of this field is "Success", the step will pass the execution success determination. For steps with execution status of "Failure", "Abnormal Interruption", or "Incomplete", they will be directly removed and will not enter the subsequent determination process.

[0038] (2) Operational recoverability determination A set of recoverable operations is maintained in advance, which records all standard operation types that can be re-executed in a controlled environment. For candidate steps that pass the execution success determination, the operation type of the step is extracted, and it is checked whether the operation type belongs to the set of recoverable operations. Only if the operation type corresponding to a step belongs to this set is it allowed to pass the operation recoverability determination.

[0039] (3) Parameter integrity judgment For candidate steps that pass the recoverability test, further examine the integrity and parsability of their input parameters. Read the input parameter fields of this step and check the following aspects: Structural integrity: Whether the parameter structure is complete, i.e., whether all required parameters for this step exist. A list of required parameters can be predefined for each operation type, and then each candidate step can be checked to ensure that all required parameters are provided.

[0040] Field parsability: Whether parameter values ​​can be correctly parsed. For example, whether numeric parameters are indeed numeric, whether date parameters conform to date format, and whether the dataset identifier points to a valid dataset.

[0041] Parameter semantic clarity: Whether the meaning of the parameter is clear and there are no ambiguities or unrecognizable placeholders.

[0042] If a candidate step has missing, structurally corrupted, or relies on irrecoverable temporary content (such as referencing temporary variables or session-level cached data that are only valid in the original session), its parameter integrity check is deemed to have failed and it will not be included in the standard step set.

[0043] (4) Determination of the traceability of side effects For candidate steps that pass the parameter integrity test, it is further determined whether their execution impact can be clearly tracked and expressed internally. The so-called "side effect" refers to the observable changes to the state after the step is executed, including but not limited to: generating a new dataset based on an existing dataset, renaming a dataset, constructing derived features, merging datasets, updating dataset metadata, etc.

[0044] The traceability of side effects is determined by analyzing the output information and operation type of each step. Specifically: The side effects of a step are considered traceable if the execution of a step produces one or more new datasets that have clear dataset identifiers and accessible storage locations.

[0045] If the execution of a step modifies the structure or content of an existing dataset (such as adding a new column or updating values), and these modifications can be logged and rolled back, then the side effects of that step are considered traceable.

[0046] If the execution of a step only produces instantaneous results (such as generating temporary variables in memory or outputting visual charts but not saving them), depends on an uncontrollable external environment (such as calling external web services), or has unverifiable side effects (such as sending emails or writing to external systems), then its side effects are deemed untraceable and it will not be included in the standard step set.

[0047] (5) Determination of data dependency boundability For candidate steps that pass the side effect traceability assessment, it is further determined whether the data input on which the step depends can clearly point to a specific dataset identifier or dataset set. Specifically, the source of the input data for the step is examined to confirm whether it can be clearly traced back to an existing dataset.

[0048] If the data input for a step comes from a data source that cannot be explicitly identified (e.g., from an external temporary file, manually pasted data, or real-time query results that depend on external states), then that step cannot pass the data dependency definability test. Only steps with clear data dependencies that can be explicitly identified by a specific dataset are allowed to be included in the standard step set.

[0049] It should be noted that the execution order of the above five judgment conditions is not limited to the order described above. The order of the judgments can be adjusted according to actual needs. For example, the operation recoverability judgment and parameter integrity judgment, which have lower computational costs, can be performed first, followed by the side effect traceability judgment and data dependency definability judgment, which have higher computational costs, to improve screening efficiency.

[0050] Step 203: The standard steps set is structurally encapsulated according to the execution order to generate an SOP definition object. The SOP definition object includes the SOP identifier, initial dataset requirements, standard step sequence and inter-step dependency constraints. Specifically, the SOP definition object is a structured data object, and the specific generation process is as follows: (1) Generate basic attribute information Assign a globally unique SOP identifier to the SOP definition object to be generated, which is used to uniquely identify the SOP asset. This identifier can be an auto-incrementing numeric number, a UUID, or generated according to a preset encoding rule (such as "SOP_YYYYMMDD_Serial Number"). At the same time, a job name and job description are automatically generated based on the content of the standard procedure set or configured by the user. The job name is used to identify the purpose of the SOP, and the job description is used to describe the applicable scenarios and functional overview.

[0051] (2) Extracting the initial dataset requirements Iterate through each standard step in the set of standard steps, identify those datasets whose data dependencies point to the original input data (rather than intermediate data produced by preceding steps), and record these dataset identifiers and their corresponding descriptions as initial dataset requirements. These initial dataset requirements are used for data mapping verification during subsequent calls.

[0052] (3) Constructing the standard step sequence and dependency constraints Following the original execution order of the standard steps, organize them into an ordered sequence. For each standard step in the sequence, record its step sequence number, operation type, step parameters, input data reference (pointing to the initial dataset requirements or the output of the preceding steps), and output data definition. The step parameters must retain complete structural information (parameter name, type, default value, etc.) to ensure that the execution conditions of the steps can be correctly restored during subsequent replays.

[0053] Simultaneously, the data flow relationships between each step are analyzed to generate inter-step dependency constraints. For each standard step, the output of the preceding step is identified as the source of its input data, and the data dependency relationship between the preceding step and the current step is established; if the input of a step depends on the output of multiple preceding steps, its multi-source dependency relationship is recorded.

[0054] (4) Bind running status information When saving the SOP, the runtime status information related to the data source generation (such as random seed, data partition information, environment configuration parameters, etc.) is recorded in the SOP definition object. This is used to bind to the controlled execution context during subsequent calls, ensuring that the newly generated dataset identifier, step product number and related process status are consistent and reproducible during the replay process.

[0055] (5) Encapsulate as an SOP definition object The above information is assembled according to a preset data structure to generate a complete SOP definition object. This SOP definition object includes: SOP identifier, job name and description, initial dataset requirements, standard step sequence (each step includes operation type, parameter definition, input and output definition), inter-step dependency constraints, running status information, and creation timestamp.

[0056] Step 204: Store the SOP definition object to form an SOP asset that can be called. As an optional implementation, version management is performed while storing SOP definition objects, and version information and historical copies are recorded.

[0057] Specifically, when writing an SOP definition object to persistent storage, a version record is created synchronously. Upon initial storage, the current SOP definition object is written as the initial version (e.g., version number 1.0), and the creation time and version description of that version are recorded. The version description can be automatically generated by the system (e.g., "Initial Creation") or entered by the user.

[0058] When a SOP definition object is updated (e.g., step parameter adjustments, step sequence modifications, dataset requirement changes), before overwriting the current SOP definition object, the complete definition content of the current version is backed up as a historical copy, forming a version evolution record, and a new version number is generated (e.g., version number 1.1, 2.0, etc.). Each update generates a version record, recording the version number, update time, change description, and a summary of the differences before and after the change.

[0059] In terms of storage structure, each SOP definition object is associated with a version linked list, which contains all historical versions of that SOP definition object. The current version points to the latest node in the linked list, and historical versions are arranged in chronological order. Any historical version can be queried and rolled back.

[0060] Step 205: Load the target SOP asset according to the SOP identifier in the call request, and obtain the session identifier of the current session; Specifically, the SOP identifier is parsed from the call request. This SOP identifier is generated and assigned when the SOP is saved (step 203) and is used to uniquely identify an SOP asset. Using this SOP identifier as an index, the corresponding target SOP asset is loaded from storage. During loading, all definition information stored in the SOP asset is read, including initial dataset requirements, standard step sequence, parameter definitions for each step, inter-step dependencies, and runtime status information. Simultaneously, the session identifier for the current session is obtained. The session identifier is a unique identifier assigned to each analysis session to distinguish different analysis tasks and runtime environments.

[0061] Step 206: Obtain the initial dataset requirements in the target SOP asset as the baseline requirement set, and receive the data mapping relationship in the call request. Based on the baseline requirement set, perform integrity and existence checks on the data mapping relationship. When the checks pass, establish the mapped running data view. The data mapping relationship is used to map the original dataset identifier to the current session dataset identifier. As an optional implementation, the integrity and existence of the data mapping relationship are verified based on the baseline requirement set, specifically including: Based on the baseline requirement set, verify whether each original dataset has been mapped to the current session dataset identifier through the data mapping relationship. If there are any uncorresponding ones, the verification fails. Verify whether the current session dataset identifier pointed to by the data mapping relationship is valid; if invalid, the verification fails. The mapped runtime data view is constructed based on the verified mapping relationship. The runtime data view uses the original dataset identifier for access and is bound to the data corresponding to the current session dataset identifier pointed to by the data mapping relationship.

[0062] Specifically, the initial dataset requirements recorded at the time of saving are read from the target SOP asset as a baseline requirement set. This baseline requirement set contains all the original dataset identifiers required to execute the SOP. Then, the data mapping relationship in the call request is received. This data mapping relationship is used to map the original dataset identifiers at the time the SOP was saved to dataset identifiers in the current session.

[0063] Based on the baseline demand set, two checks are performed on the data mapping relationship: Integrity check: Checks whether each original dataset identifier in the baseline requirement set has been mapped to the current session dataset identifier through data mapping relationships. If any original dataset identifier is not mapped, the check fails, the call process terminates, and an error message "Missing mapping" is returned.

[0064] Existence verification: For target dataset identifiers with established mapping relationships, further verification is performed to confirm whether they actually exist in the data source set of the current session. If the mapped target dataset does not exist in the current session, the verification fails, the call process terminates, and the error message "target dataset does not exist" is returned.

[0065] Once both of the above checks pass, a mapped runtime data view is established. This view uses the original dataset identifier saved in the SOP for access, but is actually bound to the corresponding target dataset copy in the current session. In this way, standard procedures do not need to be rewritten internally during replay. If either the integrity check or the existence check fails, in addition to terminating the call process, the specific reason for the failure (such as a missing mapped dataset identifier, a non-existent target dataset identifier, etc.) is recorded in the runtime log and fed back to the calling client.

[0066] Step 207: Generate an independent controlled execution context and a run identifier based on the current session environment, and associate the run identifier with this call; As an optional implementation, an independent controlled execution context and runtime identifier are generated based on the current session environment, specifically including: A new runtime context is generated by copying the current session environment; In the new runtime context, the original dataset identifier is bound to the data corresponding to the current session dataset identifier through data mapping relationships; Bind the data source generation state recorded when the SOP asset is saved to the new runtime context; Generate an independent running identifier and establish the association between the running identifier and the data mapping relationship.

[0067] Specifically, a new runtime context is copied and generated based on the current session environment, serving as the independent execution carrier for this SOP call. This copying process is not simply opening a new session, but rather building a complete execution environment specifically for this call, including an independent data source view, runtime state binding, event chain, and call identifier.

[0068] In the newly generated runtime context, the mapped dataset from the current session is copied and loaded into the controlled context. The original data source set from the original session is replaced with the mapped data source copy set to avoid directly polluting the original data source state. Simultaneously, within the controlled context, the original dataset identifier used when the SOP was saved continues to access the data, ensuring that the step parameters and data reference relationships remain consistent during replay.

[0069] The data source generation-related runtime status (such as random seed, data partition information, etc.) recorded when saving SOP assets is bound to the current context, so that the newly generated dataset identifier, step product number and related process status in subsequent executions have consistency and reproducibility.

[0070] Simultaneously, a dedicated event channel is established for this SOP call to output step start events, execution result events, and exception events, for use by the front-end display, process summary, and traceability modules. This context is associated with runtime elements such as session identifiers, analysis tool runtime environment, model configuration, and cache information, ensuring that each standard step runs within a unified and controlled execution framework.

[0071] Finally, an independent run identifier is generated for this SOP call, and an association relationship of "run identifier - data mapping relationship - step call identifier" is established to provide a basis for subsequent recovery, playback and auditing.

[0072] Step 208: Using the controlled execution context as the execution carrier, execute the standard step sequence in the target SOP asset one by one, and generate a structured event flow and a set of step-level execution results during the execution process; As an optional implementation, the standard steps in the target SOP asset are executed one by one, specifically including for each standard step: Read the operation type and step parameters of the standard procedure; Perform executable filtering on the step parameters, retaining only the parameter fields actually needed for the operation type; Execute standard steps in a controlled execution context and output structured events corresponding to the standard steps during execution; structured events include start events, result events, or exception events; The execution results of the standard steps are written into the execution log of this call in a structured format.

[0073] Specifically, the operation type and step parameters of the current standard procedure are read from the target SOP asset. The operation type is used to determine the specific operation to be invoked (such as "data cleaning", "feature construction", "model training", etc.), and the step parameters are used to configure the execution details of the operation.

[0074] Perform executable filtering on the step parameters, retaining only the parameter fields actually needed for the operation, and removing redundant fields left over from historical sessions to avoid affecting the execution accuracy of the current call.

[0075] The corresponding standard operation is invoked within the controlled execution context. Since the mapped dataset copy and the runtime state at the time of saving (such as a random seed) are pre-bound in the controlled execution context, the data source and state information in the context are used directly during step execution without additional configuration.

[0076] Structured events are output in real time during the execution of the steps: A start event is generated at the beginning of the step; A result event is generated upon successful completion of the step, carrying a summary of the execution result; When an exception occurs during a step, an exception event is generated, and the exception type, exception information, and stack details are recorded.

[0077] The execution results of each step are written into the runtime message chain of this call in a structured format. The execution results include information such as whether the step was successful, the output dataset identifier, key metric values, and execution time.

[0078] Step 209: Generate a business-readable call summary text based on the step-level execution result set and structured event flow; As an optional implementation, the call summary text should include at least: the SOP name and call background, the completion status of each step, key output results, new data objects or intermediate products generated during execution, exception descriptions, and an overall conclusion description based on business understanding.

[0079] Specifically, after the standard procedures are completed, a call summary text for business users is automatically generated based on the SOP execution history. This summary text includes the following: (1) Name of this SOP and background of its use Read the job name and job description of the SOP from the SOP asset and use them as the title of the summary text to explain what SOP is being executed in this call and the context in which the call was initiated.

[0080] (2) Completion status of each step Iterate through the execution result set at the step level and list the execution status of each standard step in turn, including the step name, execution status (success / failure / exception), execution time, etc.

[0081] (3) Key output results Extract key output information from each step from the step-level execution result set, such as newly generated dataset identifiers, model evaluation metrics (e.g., accuracy), and prediction result summaries.

[0082] (4) New data objects or important intermediate products generated during the execution process Summarize the newly generated datasets, model objects, or other intermediate products during this execution process, and describe their storage location or access method.

[0083] (5) Explanation of abnormalities If any abnormal events occur during execution, the abnormal event type, abnormal information, and occurrence steps recorded in the abnormal event are extracted, and a clear abnormal description is given in the summary text.

[0084] (6) Overall conclusion description based on business understanding By summarizing the results of each step, an overall conclusion description tailored to the business scenario is generated, enabling non-technical users to understand the execution results of this SOP without having to check each underlying event.

[0085] The summary text can be generated using a preset template structure. The above information is filled into the template in a fixed order to form a structured summary report. Alternatively, a large language model can be invoked to automatically generate a natural language summary text based on the step-level execution result set and event flow.

[0086] Step 210: Associate and store the session identifier, SOP identifier, run identifier, data mapping relationship, step-level execution result and call summary text to form a traceable audit link.

[0087] Specifically, all context elements related to this call are associated and written into the traceability record, including: (1) Record the session identifier and basic information of the current session for this call; (2) Record the SOP identifier and its version information that are invoked; (3) Record the SOP execution identifier for this call instance; (4) Record the data mapping relationship used this time, that is, the correspondence between the original dataset identifier at the time of saving and the current session dataset identifier; (5) Record the call identifier of each standard step and the corresponding execution result or exception information; (6) Record the call summary text generated during this run; (7) Record the running status information related to the data source generation for subsequent problem reproduction and tracing.

[0088] In terms of storage structure, the run identifier is used as the primary key for this call, and the session identifier, SOP identifier, data mapping relationship, step-level execution result, and call summary text are used as associated fields and stored together as an audit record.

[0089] Implementing steps 201 to 210 above solves the "black box" problem in existing technologies where analysis processes are scattered in the operator's mind or chat logs and cannot be recognized and processed by the system. It transforms unstructured, non-reproducible temporary operations into standardized candidate step data that can be parsed and processed by the computer. It also addresses the lack of a screening mechanism in existing technologies to determine whether historical steps are recoverable, reusable, and traceable, leading to the erroneous inclusion of temporary, non-replayable operations in reuse processes. This eliminates non-reusable steps at the source, significantly reducing replay failure rates and ensuring that every step entering the SOP definition object is a standardized work unit that can be stably executed in a controlled environment. Furthermore, it solves the problem in existing technologies where analysis processes are difficult to standardize and structure for preservation as reusable assets, transforming one-off, temporary analysis sessions into manageable, identifiable, and callable standardized process assets. Finally, it addresses the problem in existing technologies where direct execution of old processes when datasets change leads to errors and omissions, achieving secure migration across data instances and an explicit, verifiable data mapping mechanism. This technology addresses the issues of existing technologies that directly replay old processes in the current session environment, leading to a mixture of historical and current states and unreliable results. It achieves a unified approach of execution environment isolation and result reproducibility. It also solves the problems of existing technologies that only output the final result, leaving the process unobservable and incomprehensible to business users. This technology enables step-by-step observability of the process and interpretable execution results, allowing non-technical users to understand the complete execution of the call without needing to examine each underlying event. Furthermore, it addresses the issue of existing technologies that only save the final result, failing to meet the review and compliance requirements in industrial scenarios. This technology enables complete traceability from "session initiation → SOP selection → data mapping → each step execution → final result," satisfying the requirements of industrial scenarios for process review, responsibility definition, process compliance, and problem localization.

[0090] This application also provides an application scenario in which the above-mentioned workflow SOP saving and recall method is applied. Specifically, the workflow SOP saving and recall method provided in this embodiment can be applied in industrial data analysis scenarios. Industrial data analysis enters the analysis and processing chain from the problem discovery stage, obtains corresponding analysis results through human-machine collaboration, and then enters the downstream knowledge accumulation, reuse, and distribution stage. The workflow SOP saving and recall method provided in this embodiment belongs to the core link of process asset accumulation and standardized reuse in the industrial data analysis process. Specifically, in the processing of industrial data analysis, analysts complete specific data analysis tasks (such as equipment fault diagnosis, quality anomaly tracing, process parameter optimization, predictive maintenance, etc.) through interactive sessions in the platform. This session includes a series of data processing and analysis operations (such as data cleaning, feature construction, model training, result visualization, etc.). After the analysis task is completed, the method in this application performs structured parsing of historical analysis sessions, extracting the sequence of operation steps, execution status, input parameters, and data dependencies. Based on multiple dimensions such as execution success, operation recoverability, parameter integrity, side effect traceability, and data dependency defineability, standardized filtering is performed. The filtered standard steps are encapsulated into Standard Operating Procedure (SOP) definition objects and persistently stored, forming SOP assets that can be invoked. When encountering the same or similar analysis needs in the future, analysts only need to select the corresponding SOP in the platform and initiate a call request. The method in this application loads the target SOP asset according to the SOP identifier, maps the original dataset when the SOP was saved to the dataset of the current session through a data mapping verification mechanism, and executes each step in the standard step sequence in an independent, controlled execution context. It automatically generates a business-readable call summary text and a complete audit chain, achieving standardized reuse of the analysis process. The entire process of SOP accumulation and reuse can be carried out in a collaborative manner of automatic saving and manual verification. That is, the system automatically extracts candidate steps from successful historical sessions and filters them to generate SOP definition objects. At the same time, it supports analysts to manually review, correct and manage the generated SOP definition objects to ensure the quality and accuracy of SOP assets.

[0091] Based on the same inventive concept, this application also provides a workflow SOP saving and recall apparatus for implementing the workflow SOP saving and recall method described above. The solution provided by this apparatus is similar to the implementation scheme described in the above method; therefore, the specific limitations of one or more workflow SOP saving and recall apparatus embodiments provided below can be found in the limitations of the workflow SOP saving and recall method described above, and will not be repeated here.

[0092] In one exemplary embodiment, such as Figure 3 As shown, a workflow SOP saving and recall device is provided, including: The session extraction module is used to perform structured parsing of historical sessions and extract a set of candidate steps. The set of candidate steps includes at least the step sequence, execution status, input parameters, and data dependencies. The standard filtering module, connected to the session extraction module, is used to filter the candidate step set based on preset conditions to obtain a standard step set. The preset conditions include execution success, operation recoverability, parameter integrity, side effect traceability, and data dependency defineability. The SOP definition building module, connected to the standard filtering module, is used to structurally encapsulate the set of standard steps in the execution order to generate an SOP definition object. The SOP definition object includes the SOP identifier, initial dataset requirements, standard step sequence, and inter-step dependency constraints. The persistence and version management module connects with the SOP definition building module to store SOP definition objects, forming SOP assets that can be called. The call control module connects to the persistence and version management module. It is used to receive call requests, load the target SOP asset according to the SOP identifier in the call request, and obtain the session identifier of the current session. The data mapping module, connected to the call control module, is used to obtain the initial dataset requirements in the target SOP asset as the baseline requirement set; and to receive the data mapping relationship in the call request, and to perform integrity and existence checks on the data mapping relationship based on the baseline requirement set; when the checks pass, a mapped runtime data view is established, and the data mapping relationship is used to map the original dataset identifier to the current session dataset identifier. The context management module, connected to the data mapping module, is used to generate an independent controlled execution context and a runtime identifier based on the current session environment, and associate the runtime identifier with the current call. The sequential replay module, connected to the context management module and the call control module, is used to execute the standard steps in the target SOP asset one by one, using a controlled execution context as the execution carrier, and to generate a structured event stream and a set of step-level execution results during the execution process. The summary generation module, connected to the sequential replay module, is used to generate a business-readable call summary text based on the step-level execution result set and structured event flow. The traceability management module, connected to the call control module, data mapping module, sequential replay module, and summary generation module, is used to associate and store the session identifier, SOP identifier, run identifier, data mapping relationship, step-level execution result, and call summary text of this call, forming a traceable audit link.

[0093] In one exemplary embodiment, a computer device is provided, which may be a server or a terminal, and its internal structure diagram may be as follows. Figure 4 As shown, this computer device includes a processor, memory, input / output interfaces (I / O), and a communication interface. The processor, memory, and I / O interfaces are connected via a system bus, and the communication interface is also connected to the system bus via the I / O interfaces. The processor provides computational and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and a database. The internal memory provides the environment for the operating system and computer programs stored in the non-volatile storage media. The database stores historical analysis sessions, SOP definition objects, SOP assets, data mapping relationships, step-level execution result sets, call summary texts, and audit links. The I / O interfaces are used for information exchange between the processor and external devices. The communication interface is used for communication with external terminals via a network connection. When executed by the processor, the computer program implements a workflow SOP saving and recall method.

[0094] Those skilled in the art will understand that Figure 4 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.

[0095] In one exemplary embodiment, a computer device is also provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps in the above-described method embodiments.

[0096] In one exemplary embodiment, a computer-readable storage medium is provided storing a computer program that, when executed by a processor, implements the steps in the above-described method embodiments.

[0097] In one exemplary embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps in the above-described method embodiments.

[0098] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of the relevant data must comply with relevant regulations.

[0099] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments described above. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM).

[0100] The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, etc., and are not limited to these.

[0101] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0102] This document uses specific examples to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only for the purpose of helping to understand the methods and core ideas of this application. Furthermore, those skilled in the art will recognize that, based on the ideas of this application, there will be changes in the specific implementation methods and application scope. Therefore, the content of this specification should not be construed as a limitation of this application.

Claims

1. A method for saving and recalling workflow standard operating procedures (SOPs), characterized in that, The methods for saving and recalling workflow SOPs include: The historical sessions are structured and parsed to extract a set of candidate steps, which includes at least a step sequence, execution status, input parameters, and data dependencies. The candidate step set is filtered based on preset conditions to obtain a standard step set. The preset conditions include execution success, operation recoverability, parameter integrity, side effect traceability, and data dependency defineability. The set of standard steps is structured and encapsulated in the order of execution to generate an SOP definition object. The SOP definition object includes an SOP identifier, initial dataset requirements, a sequence of standard steps, and inter-step dependency constraints. The SOP definition object is stored to form an SOP asset that can be called. Load the target SOP asset based on the SOP identifier in the call request, and obtain the session identifier of the current session; The initial dataset requirements in the target SOP asset are obtained as a baseline requirement set, and the data mapping relationship in the call request is received. The integrity and existence of the data mapping relationship are verified based on the baseline requirement set. When the verification passes, the mapped running data view is established. The data mapping relationship is used to map the original dataset identifier to the current session dataset identifier. An independent controlled execution context and a run identifier are generated based on the current session environment, and the run identifier is associated with this call; Using the controlled execution context as the execution carrier, the standard steps in the target SOP asset are executed one by one, and a structured event flow and a set of step-level execution results are generated during the execution process. Based on the step-level execution result set and the structured event stream, generate a business-readable call summary text; The session identifier, SOP identifier, run identifier, data mapping relationship, step-level execution result and call summary text are associated and stored to form a traceable audit link.

2. The method for saving and recalling workflow SOPs according to claim 1, characterized in that, Also includes: The SOP definition objects are version-managed, and version information and historical copies are recorded.

3. The method for saving and recalling workflow SOPs according to claim 1, characterized in that, The process of performing integrity and existence checks on the data mapping relationship based on the baseline demand set specifically includes: Based on the aforementioned baseline requirement set, verify whether each original dataset has been mapped to the current session dataset identifier through the aforementioned data mapping relationship; if any are not mapped, the verification fails. Verify whether the current session dataset identifier pointed to by the data mapping relationship is valid; if invalid, the verification fails. A mapped runtime data view is constructed based on the verified mapping relationship. The runtime data view uses the original dataset identifier for access and is bound to the data corresponding to the current session dataset identifier pointed to by the data mapping relationship.

4. The method for saving and recalling workflow SOPs according to claim 1, characterized in that, The generation of an independent controlled execution context and runtime identifier based on the current session environment specifically includes: A new runtime context is generated by copying the current session environment; In the new runtime context, the original dataset identifier is bound to the data corresponding to the current session dataset identifier through the data mapping relationship; Bind the data source generation state recorded when the SOP asset is saved to the new runtime context; Generate an independent running identifier and establish an association between the running identifier and the data mapping relationship.

5. The method for saving and recalling workflow SOPs according to claim 1, characterized in that, The step-by-step execution according to the standard procedure sequence in the target SOP asset specifically includes, for each standard step: Read the operation type and step parameters of the standard steps; The step parameters are subjected to executable filtering, retaining only the parameter fields actually required for the operation type; The standard steps are executed in the controlled execution context, and the structured events corresponding to the standard steps are output during the execution process. The structured events include start events, result events, or exception events; The execution results of the standard steps are written into the execution record of this call in a structured form.

6. The method for saving and recalling workflow SOPs according to claim 1, characterized in that, The call summary text shall include at least: SOP name and call background, completion status of each step, key output results, new data objects or intermediate products generated during execution, exception descriptions, and an overall conclusion description based on business understanding.

7. A device for saving and recalling workflow standard operating procedures (SOPs), characterized in that, The workflow SOP saving and recall device includes: The session extraction module is used to perform structured parsing of historical sessions and extract a set of candidate steps. The set of candidate steps includes at least a step sequence, execution status, input parameters, and data dependencies. A standard filtering module, connected to the session extraction module, is used to filter the candidate step set based on preset conditions to obtain a standard step set. The preset conditions include execution success, operation recoverability, parameter integrity, side effect traceability, and data dependency defineability. The SOP definition building module, connected to the standard filtering module, is used to structurally encapsulate the set of standard steps in the execution order to generate an SOP definition object. The SOP definition object includes an SOP identifier, initial dataset requirements, a sequence of standard steps, and inter-step dependency constraints. The persistence and version management module is connected to the SOP definition construction module and is used to store the SOP definition object to form an SOP asset that can be called. The call control module, connected to the persistence and version management module, is used to receive call requests, load the target SOP asset according to the SOP identifier in the call request, and obtain the session identifier of the current session; The data mapping module, connected to the call control module, is used to obtain the initial dataset requirements in the target SOP asset as a baseline requirement set; and to receive the data mapping relationship in the call request, and to perform integrity and existence checks on the data mapping relationship based on the baseline requirement set; when the checks pass, a mapped runtime data view is established, and the data mapping relationship is used to map the original dataset identifier to the current session dataset identifier. The context management module, connected to the data mapping module, is used to generate an independent controlled execution context and a run identifier based on the current session environment, and associate the run identifier with the current call; The sequential replay module, connected to the context management module and the call control module, is used to execute the standard steps in the target SOP asset one by one, using the controlled execution context as the execution carrier, and to generate a structured event stream and a set of step-level execution results during the execution process. The summary generation module, connected to the sequential replay module, is used to generate a business-readable call summary text based on the step-level execution result set and the structured event stream. The traceability management module is connected to the call control module, the data mapping module, the sequential replay module, and the summary generation module. It is used to associate and store the session identifier, SOP identifier, run identifier, data mapping relationship, step-level execution result, and call summary text of this call to form a traceable audit link.

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 the processor executes the computer program to implement the steps of the workflow SOP saving and recall method according to any one of claims 1-6.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the steps of the workflow SOP saving and recall method as described in any one of claims 1-6.

10. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by the processor, it implements the steps of the workflow SOP saving and recall method as described in any one of claims 1-6.

Images