Method and program product for execution control of business processes

Abstract

The present specification discloses a business process execution control method and program product. A computer system sets a candidate staging data area and a controlled submission data area. A large language model generates content and writes it to the candidate staging data area. After structured content extraction, field standardization, and instantiation and verification, if successful, the task result data is written to the corresponding task result field and the task cursor field is updated after writing is completed. If unsuccessful, error prompt data is written to the metadata field, thereby reducing the risk of non-trustworthy generated content polluting process data and causing errors to be promoted.

Description

Technical Field

[0001] This disclosure relates to the field of software engineering technology, specifically to a method and program product for controlling the execution of a business process. Background Technology

[0002] In computer systems where large language modeling technology is used for business process automation, the system typically needs to complete information collection, external data querying, candidate object generation, task result recording, and response output to downstream components within a multi-step task sequence. Such business processes are common in scenarios such as appointment scheduling, transactions, approvals, and work order processing. Different task items in the process may have different data fields, format constraints, and result delivery locations. Downstream components often rely on structurally stable data objects for page rendering, API calls, or subsequent calculations.

[0003] The content generated by large language models has probabilistic and textual characteristics. Even when prompted to output structured content, issues such as natural language descriptions, structured fragments wrapped in code blocks, inconsistent field names, missing fields, mismatched field value types, and field values ​​exceeding constraints may still occur. In a multi-task workflow environment, if the generated content of a certain task item fails to be stably converted into a data object that meets the requirements of that task item, subsequent task item location, result recording, and downstream component parsing may all be affected. Summary of the Invention

[0004] This specification provides an execution control method for a business process, applied to a computer system. The computer system includes a candidate temporary data area and a controlled submission data area. The candidate temporary data area stores the generated content returned by a large language model and intermediate processing data obtained from the generated content. The controlled submission data area includes a task cursor field, multiple task result fields, and metadata fields. The task cursor field indicates the currently pending task item in the task item sequence of the business process. The multiple task result fields correspond one-to-one with multiple task items in the task item sequence, and each task result field stores the task execution result of the corresponding task item. The metadata field stores the response data output to downstream components. The output interface of the large language model is isolated from the write interface of the controlled submission data area, preventing the content returned by the large language model from bypassing the candidate temporary processing path and directly writing to the task result field, task cursor field, or metadata field.

[0005] When a task to be completed requires invoking a large language model to determine the task execution result, the computer system invokes the large language model, retrieves the generated content returned by the model, and writes the generated content into the candidate temporary data area. Within the candidate temporary data area, the computer system performs structured content extraction on the generated content to obtain candidate structured data; it then normalizes the field names in the candidate structured data according to the field normalization rules corresponding to the current task to be completed, obtaining normalized candidate data; finally, it instantiates and validates the normalized candidate data according to the data structure requirements corresponding to the current task to be completed. Data structure requirements include at least one of the following: field structure requirements, field type requirements, required field requirements, default field definitions, and field value constraints. If instantiation and validation pass, the task result data is determined based on the structured data obtained after instantiation and validation; if instantiation and validation fail, error message data is generated according to preset error message rules. The computer system writes task result data to the task result field corresponding to the currently pending task item through the write interface of the controlled submission data area. After the task result data is written, the system updates the task cursor field so that the task cursor field indicates the next task item in the task item sequence as the currently pending task item. Alternatively, the system writes error message data to the metadata field through the write interface of the controlled submission data area.

[0006] Using the above method, the model-generated content is placed in the candidate temporary data area before entering the formal task result record. The output interface of the large language model is isolated from the write interface of the controlled submission data area, and untrusted generated content cannot directly affect the task cursor field or task result field. The extraction, field normalization, instantiation, and validation of structured content in the candidate temporary data area gradually converge uncertainties such as natural language noise, unstable field naming, missing fields, type mismatch, and out-of-bounds values ​​into submittable structured data. After successful instantiation and validation, the task result data is written to the corresponding task result field in its entirety through the controlled write interface, and the task cursor field is updated only after the writing is completed. This helps to prevent the process from prematurely entering the next task item before the task result is finalized. When instantiation and validation fail, the system generates error message data and writes it to the metadata field, so that downstream components receive a structurally stable error response instead of receiving the original generated content or underlying exceptions.

[0007] Optionally, the computer system is configured with a structured submission configuration corresponding to at least one task in the task item sequence that requires invoking a large language model. The structured submission configuration includes structured content extraction rules, field alias mapping relationships, a strongly typed data model, and task result field mapping relationships. The structured content extraction rules are used to obtain candidate structured data from the generated content; the field alias mapping relationships are used to map non-standard field names in the candidate structured data to standard field names; the strongly typed data model is used to characterize the data structure requirements matching the corresponding task item; and the task result field mapping relationships are used to determine the task result fields to be written after the task result data passes the test. Thus, different task items can have different extraction rules, field rules, model definitions, and writing targets, enabling the same business process to handle multiple types of task results with different structures.

[0008] Optionally, when performing structured content extraction on the generated content, the computer system first performs direct structured parsing on the generated content according to the structured content extraction rules. If the direct structured parsing is successful, the data object obtained from the direct structured parsing is identified as candidate structured data. If the direct structured parsing fails, noise reduction and block extraction processing are performed on the generated content to extract the structured data fragments to be parsed. The noise reduction and block extraction processing can match structured data fragments in the generated content according to preset boundary identifiers, which include at least one of code block boundary identifiers, structured data object boundary identifiers, and structured data array boundary identifiers. If a structured data fragment is matched, structured parsing is performed on the structured data fragment, and if the parsing is successful, the parsed data object is identified as candidate structured data; if no structured data fragment is matched or the parsing of the structured data fragment fails, the structured content extraction is deemed to have failed. This process ensures that explanatory text or formatting wrappers embedded in the model output will not directly enter the subsequent controlled submission path.

[0009] Optionally, the field alias mapping relationship includes a correspondence between at least one non-standard field name and a standard field name. The non-standard field name includes at least one of the following: camelCase, case-varying, abbreviated, and synonymous field names. The standard field name is the field name in the strongly typed data model. Field normalization can iterate through the field names in the candidate structured data. If a traversed field name matches a field alias mapping relationship, the corresponding field value is written to the standard field name indicated by the field alias mapping relationship. If a traversed field name does not match a field alias mapping relationship, the field name and its value are retained. Based on the field value written to the standard field name and the retained field name and value, normalized candidate data is generated. In this way, the differences in field naming in the model output are converged to the field system of the strongly typed data model, and subsequent instantiation processes can be performed based on stable field names.

[0010] Optionally, the strongly typed data model includes at least one of the following: required field definition, field type definition, default field definition, and field value constraint definition corresponding to the current task item to be completed. The required field definition is used to limit the fields that must exist in the normalized candidate data; the field type definition is used to limit the data type of the field value in memory; the default field definition is used to limit the default value written when a field is missing; and the field value constraint definition is used to limit at least one of the following: the numerical range, the enumeration range, and the format condition of the field value. During instantiation and validation, the normalized candidate data can be input into the strongly typed data model so that the strongly typed data model performs instantiation processing on the normalized candidate data. During instantiation, type conversion is performed on field values, default value completion is performed on fields that are missing and have default field definitions, and value constraint validation is performed on field values. If type conversion fails, required fields are missing, or field values ​​do not meet the value constraint validation, instantiation and validation are determined to fail. Through this constructive processing, the system forms a structured data object that has undergone type convergence, field completion, and constraint checking, rather than merely making a superficial judgment on the text format.

[0011] Optionally, if instantiation and validation pass, the computer system serializes the type-safe structured data object obtained through the instantiation process of the strongly typed data model into task result data corresponding to the current task item to be completed. The task result data includes a set of structured fields corresponding to the field names in the strongly typed data model. Based on the correspondence between the task result fields, the computer system determines the task result field corresponding to the current task item to be completed and writes the task result data as a whole into the determined task result field through the write interface of the controlled commit data area. After receiving a write completion result indicating that the task result data has been written to the task result field, the system calls the write interface of the controlled commit data area to update the task cursor field. This order of writing the result first and then updating the cursor ensures that the process progresses only after the task result is in place, which helps reduce the risk of inconsistencies in state caused by writing only some fields or writing failures.

[0012] Optionally, in cases where structured content extraction fails, field name normalization processing fails, or the instantiation of a strongly typed data model fails, the computer system captures the corresponding parsing exception, field normalization exception, or strong type validation exception, and generates error message data based on the captured exception according to preset error message rules. The error message data includes an error status field and an error message field. The error status field indicates that the generated content has not been successfully converted into task result data that meets the data structure requirements, while the error message field is used for display or processing by downstream components. The error message data may also include at least one of the following: current task item identifier, error type field, error source field, and whether retry is allowed. After the error message data is written to the metadata field, it can be sent to the downstream components as response data. The downstream components include a front-end rendering component, which can generate an error alarm interface or a retry prompt interface based on the error status field and the error message field. In this way, the failure branch forms a stable closed loop of exception capture, error object generation, metadata field writing, and downstream response.

[0013] This specification also provides an execution control device for a business process, comprising a candidate temporary data area management module, a controlled submission data area management module, a large language model invocation module, a structured content extraction module, a field normalization module, an instantiation and validation module, a task result submission module, and an error response module. The candidate temporary data area management module stores the generated content returned by the large language model and intermediate processing data obtained from the generated content; the controlled submission data area management module maintains a task cursor field, multiple task result fields, and metadata fields, and provides a controlled write interface; the large language model invocation module retrieves the generated content when the current task to be completed requires invoking the large language model; the structured content extraction module, field normalization module, and instantiation and validation module converge the generated content into submitable structured data within the candidate temporary data area; the task result submission module writes the task result data as a whole when instantiation and validation pass and updates the task cursor field after writing; the error response module generates error message data and writes it to the metadata field when instantiation and validation fail. Each module of the device can be implemented by a software module, a hardware module, or a combination of both.

[0014] This specification also provides a computer device, including 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 execution control method for the business process described in any of the foregoing embodiments. The computer device can be a server, a cloud computing instance, an edge computing node, or a distributed business process processing node. The candidate temporary data area and the controlled submission data area can reside in the same memory state object, different memory objects, cache objects, database records, or server session objects, as long as the output interface of the large language model cannot directly call the write interface of the controlled submission data area.

[0015] This specification also provides a computer program product, including a computer program that, when executed by a processor, implements the execution control method for the business process described in any of the foregoing embodiments. This computer program product can be deployed in the form of a software package, container image, plug-in component, server-side function, or business process engine extension component, enabling existing business process systems to acquire the capabilities of candidate storage, instantiation and verification, and controlled submission of content generated from large language models.

[0016] This specification also provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the execution control method for the business process described in any of the foregoing embodiments. The computer-readable storage medium may include non-volatile storage media, such as hard disks, solid-state drives, flash memory, optical disks, etc., and may also include other readable media for deploying server-side process control programs.

[0017] Through the above technical solutions, the business process execution control method provided in this specification can bring the following beneficial effects. Regarding the instability of output format, fields, types, and structures when a large language model participates in the generation of business process data, this method uses a candidate temporary data area to accept untrusted generated content and performs structured content extraction, field normalization, instantiation, and verification before formal writing, ensuring that the task result data has a stable set of fields and type constraints. Regarding the problem of unreliable process advancement basis, this method updates the task cursor field only after the task result data is written, creating a sequential dependency between process advancement and task result placement. Regarding the problem of unstable downstream responses when conversion fails, this method captures exceptions and converts them into error message data, writing them to the metadata field, enabling downstream components to obtain parsable, displayable, or processable error responses. Therefore, while utilizing a large language model to generate task-related content, it can reduce the risk of untrusted output polluting the formal data area, causing downstream parsing anomalies, or leading to erroneous business process advancement. Attached Figure Description

[0018] The accompanying drawings are provided to better understand this solution and do not constitute a limitation of this disclosure. Wherein:

[0019] Figure 1 This is a flowchart illustrating the execution control method for a business process provided in some embodiments of this specification.

[0020] Figure 2 This is a schematic diagram illustrating the relationship between the data area and interface of a computer system provided in some embodiments of this specification.

[0021] Figure 3 This is a schematic diagram of the processing flow within the candidate temporary data area provided for some embodiments of this specification.

[0022] Figure 4 This diagram illustrates successful submission and failure response branches for some embodiments of this specification.

[0023] Figure 5 This document provides schematic diagrams illustrating complete embodiments of business process execution control for some examples of this specification. Detailed Implementation

[0024] To make the objectives, technical solutions, and advantages of this specification clearer, the technical solutions of this specification will be clearly and completely described below in conjunction with specific embodiments and corresponding drawings. Obviously, the described embodiments are only a part of the embodiments of this specification, and not all of them. Based on the embodiments in this specification, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this specification.

[0025] The embodiments in this specification can be applied to scenarios where a large language model is needed to generate task execution results, and the computer system advances the business process according to the sequence of task items. For example, in appointment, transaction, approval, candidate selection, or work order processing systems, the business process may include multiple sequentially arranged task items, each with a corresponding set of fields and a result storage location. Some task items may need to call the large language model to organize the results returned by external tools, or generate structured candidate data based on local business parameters. Since the generated content returned by the large language model may contain natural language descriptions, code block wrapping, inconsistent field names, mismatched field types, or missing fields, directly writing it into the formal task result fields or affecting the task cursor fields can easily lead to parsing errors in downstream components, task results being contaminated by dirty data, or incorrect advancement of the business process.

[0026] In some processing methods, the prompt can instruct the large language model to directly output some structured text, which the system then writes directly into the task result field or metadata field. This method is highly dependent on the stability of the model output. If explanatory text, field name changes, or field values ​​exceed constraints are mixed into the generated content, downstream components may fail to parse it, or the anomaly may only be detected at a later stage. Other processing methods can perform simple format checks before writing, but if this check only checks the existence of a certain field without forming a runtime structured object, performing type conversion, default value completion, and value constraint checks, it is still difficult to guarantee that the written data can be stably used by the task item sequence and downstream components.

[0027] The execution control method for the business process provided in the embodiments of this specification treats the generated content returned by the large language model as untrusted candidate data. The computer system sets up a candidate temporary data area and a controlled submission data area between the model output and the formal submission: the candidate temporary data area carries the generated content and intermediate processing data obtained from the generated content; the controlled submission data area carries the task cursor field, multiple task result fields, and metadata fields. The output interface of the large language model is not directly connected to the write interface of the controlled submission data area; the generated content can only enter the candidate temporary data area first, where structured content extraction, field name normalization, instantiation, and validation are completed. Only after instantiation and validation pass, the system determines the task result data based on the obtained structured data and writes it to the task result field corresponding to the current task item through the write interface of the controlled submission data area; after confirming that the task result data has been written, the system updates the task cursor field, allowing the process to proceed to the next task item. If instantiation and validation fail, the system generates error message data and writes it to the metadata field, without executing the cursor update operation after the task result field in the successful branch has been written. In this way, the instability of the model output is limited to the candidate processing path, and the recording of formal task results and process advancement are both managed by the controlled write interface.

[0028] Figure 1 This is a flowchart illustrating a business process execution control method provided in some embodiments of this specification. Figure 1 The method shown may include the following steps:

[0029] Step S110: If the task to be completed requires calling the large language model to determine the task execution result, call the large language model, obtain the generated content returned by the large language model, and write the generated content into the candidate temporary data area.

[0030] In step S110, the computer system can determine the current task to be completed in the task item sequence based on the task cursor field. The task cursor field can be an index, cursor, program count field, or other equivalent field used to indicate the current position in the task item sequence. Multiple task items in the task item sequence can correspond to different business sub-tasks, such as candidate object query, order information completion, approval opinion generation, or pre-payment data verification. For task items that require calling the large language model, the computer system can call the large language model based on the local business parameters of the current task item, the results returned by external tools, or other contextual data to obtain the generated content. The generated content can be a string, a text field in a message object, text processed by the large language model after the tool call result, or mixed content containing structured data fragments.

[0031] After obtaining the generated content, the computer system does not write it to the task result field, metadata field, or task cursor field. Instead, it writes it to the candidate temporary data area. The candidate temporary data area can be a temporary object in memory, a processing context within a node, a cached data structure, a candidate data field, or another path capable of carrying intermediate processing data. Its key function is to receive untrusted content generated by the large language model's output interface and isolate it from the controlled submission data area before it undergoes subsequent processing. For example, in a tour guide booking scenario, the large language model might return "The following tour guide information has been found for you" along with an array of objects wrapped in a code block; in this case, the system can temporarily store the entire generated content as candidate content instead of immediately writing seemingly valid fields into the formal task result field.

[0032] Figure 2 This is a schematic diagram illustrating the relationship between the data area and the interface of a computer system, provided for some embodiments of this specification. Figure 2 The system shown may include a large language model output interface, a candidate temporary data area, a candidate processing module, a controlled submission data area write interface, and a controlled submission data area. The large language model output interface only provides generated content to the candidate temporary data area; the candidate processing module reads the generated content from the candidate temporary data area and generates candidate structured data, normalized candidate data, instantiated and validated structured data, or error message data; the controlled submission data area write interface is called by the computer system to write data to the task result field, task cursor field, and metadata field. Because the large language model output interface and the controlled submission data area write interface are isolated, the model generated content cannot bypass the candidate processing module to directly change the fields in the formal data area. This isolation relationship can be achieved through different function interfaces, different module call permissions, different data object references, write permission control, or server-side state management rules; the specific implementation method is not limited.

[0033] Step S120: In the candidate temporary data area, perform structured content extraction on the generated content to obtain candidate structured data; according to the field normalization rules corresponding to the current task item to be completed, normalize the field names in the candidate structured data to obtain normalized candidate data; according to the data structure requirements corresponding to the current task item to be completed, instantiate and verify the normalized candidate data.

[0034] In step S120, the processing within the candidate temporary data area can be viewed as a structured convergence process for untrusted generated content. The generated content, as the original output of the model, may be pure structured text, or it may contain natural language prefixes and suffixes, code block boundaries, array fragments, or object fragments. The system first performs structured content extraction to obtain data objects that can be used for subsequent field processing. After obtaining the candidate structured data, the system processes the field names according to the field normalization rules corresponding to the current task item, ensuring that fields with different naming styles are mapped as closely as possible to the expected standard field names of the current task item. Subsequently, the system instantiates and validates the normalized candidate data according to the data structure requirements corresponding to the current task item. This instantiation and validation is not simply judging whether the text appears to conform to the format; rather, it involves constructing structured data objects that conform to field structure, field type, required fields, default fields, and field value constraints at runtime, and performing type conversion, default value completion, required field checks, and constraint checks during the construction process.

[0035] In some embodiments, the computer system can set a structured submission configuration corresponding to at least one task item in the task item sequence that needs to call a large language model. The structured submission configuration includes structured content extraction rules, field alias mapping relationships, a strongly typed data model, and the correspondence between task result fields. Different task items can be bound to different structured submission configurations. For example, one task item is used to generate a list of tour guides; the strongly typed data model can define fields such as candidate tour guide identifier, name, rating, number of services, and availability. Another task item is used to generate order verification results; the strongly typed data model can define fields such as order number, amount, verification status, and reason for exception. Through the correspondence between task items and structured submission configurations, the system can avoid using the same set of fields to process all model outputs, thereby adapting to the differences in data structure between different task items in the business process.

[0036] Figure 3 This specification provides a schematic diagram of a processing flow within a candidate temporary data area, based on some embodiments of the present invention. Figure 3The process described may include direct structured parsing, noise reduction and block extraction, field name normalization, strong-typed data model instantiation, and exception handling. When performing structured content extraction on the generated content, the system can first perform direct structured parsing according to the structured content extraction rules. If the generated content itself is a parsable structured object or structured text, the direct structured parsing is successful, and the parsed data object is identified as candidate structured data. If the direct structured parsing fails, the system can perform noise reduction and block extraction on the generated content, matching structured data fragments according to preset boundary identifiers. Preset boundary identifiers may include at least one of code block boundary identifiers, structured data object boundary identifiers, and structured data array boundary identifiers. For example, when the generated content contains an array of objects wrapped by a code block identifier, the system can extract the fragments inside the code block and perform structured parsing again; when the generated content only contains natural language and no parsable fragments are matched, the system determines that the structured content extraction has failed. Failure of structured content extraction is not a form of successfully obtaining candidate structured data, but rather one of the abnormal sources for subsequent error message data generation.

[0037] In field normalization, the system can iterate through the field names in the candidate structured data and determine whether each field name corresponds to a standard field name based on the field alias mapping relationship. The field alias mapping relationship can include mappings from camelCase field names, case-varying field names, abbreviated field names, and synonymous field names to standard field names. For example, the model output might use different field names such as "serviceCount," "Service_Count," "serviceNum," or "service count," while the corresponding standard field name in a strongly typed data model is "service_count." If the system matches the mapping relationship, it writes the field value corresponding to that field name to the standard field name. For fields where no mapping relationship is matched, the system can retain the field name and its value, with subsequent data structure requirements determining whether retention, ignoring, or triggering an exception is permissible. This process primarily converges field names without changing the business meaning expressed by the field values.

[0038] In some embodiments, a strongly typed data model may include at least one of required field definitions, field type definitions, default field definitions, and field value constraint definitions. Required field definitions are used to define fields that must exist in the normalized candidate data and cannot be filled in with default values; field type definitions are used to define the data type of field values ​​in memory, such as strings, integers, floating-point numbers, booleans, objects, arrays, or enumeration types; default field definitions are used to define default values ​​to be written when a field is missing; and field value constraint definitions are used to define the range of values, enumeration ranges, string formats, or other conditions. Data structure requirements can be represented by a strongly typed data model, or implemented by an executable data structure definition, schema, set of field rules, or type constraint rules; a strongly typed data model is just one specific implementation method.

[0039] After the normalized candidate data is input into the strongly typed data model, the model performs instantiation processing on it. During instantiation, if a field value is expressed as a string and the field type definition allows conversion, the system can convert the string to a numeric type. If a field is missing but has a default field definition, the system can write the corresponding default value during instantiation. If a required field is missing and there is no available default value, the system can determine that instantiation and validation fail. If a field value does not meet the value constraints—for example, a rating field exceeding the allowed range, a status field not belonging to the enumeration range, or a date field not meeting the format conditions—the system can also determine that instantiation and validation fail. Through this instantiation process, the structured data object formed by the system differs from the original generated content, candidate structured data, and normalized candidate data; it has undergone field name convergence, type convergence, default value completion, and constraint checks, making it suitable for further determining the task result data.

[0040] In this specification's embodiments, default field definitions and default value completion have different levels. Default field definitions belong to the rules within data structure requirements or strongly typed data models, used to specify the default value that can be used when a field is missing; default value completion, on the other hand, is a runtime action during instantiation, used to actually write the default value when the normalized candidate data lacks the field. Distinguishing between the two avoids judging all missing fields in the model output as failures, and also avoids arbitrarily filling in field values ​​without a rule-based basis.

[0041] In step S130, if instantiation and verification pass, the task result data is determined based on the structured data obtained after instantiation and verification; if instantiation and verification fail, error message data is generated according to the preset error message rules.

[0042] In step S130, the system enters different branches based on the results of instantiation and verification. Within each branch, the structured data obtained after instantiation and verification already meets the data structure requirements corresponding to the current task item. The computer system can serialize this structured data into task result data corresponding to the current task item. The task result data includes a set of structured fields corresponding to the field names in the strongly typed data model. Serialization can convert a strongly typed object into a dictionary, object, array, binary structure, database writable structure, or a data format agreed upon by downstream components. The source of the task result data is the structured data obtained after instantiation and verification, not the original model output without instantiation or candidate data that has only undergone field name normalization.

[0043] In branches that fail, the system generates error message data according to preset error message rules. Reasons for failure may include structured content extraction failure, field name normalization error, strong-type data model instantiation failure, type conversion failure, missing required fields, or field values ​​not meeting constraints. The system captures the corresponding parsing exceptions, field normalization exceptions, or strong-type validation exceptions and converts them into stable error message data for downstream components, rather than directly exposing the underlying exception stack, unparsed model text, or corrupted structured fragments to downstream components. Error message data may include an error status field and an error message field; the error status field indicates that the generated content has not been successfully converted into task result data that meets data structure requirements, while the error message field is for downstream components to display or process. In some embodiments, error message data may also include a current task item identifier, an error type field, an error source field, and a retry permission field, so that downstream components can determine the location of the error, the error category, and whether to guide the user to retry.

[0044] For example, in the candidate selection task, the large language model might return guide information containing a "rating" field. If this field value is the string "4.8", the strongly typed data model can convert it to a floating-point number during instantiation; if the model omits the "is_available" field, and the strongly typed data model has a default field definition for this field, the system can complete it with a default boolean value; if the model returns "rating" as "9.9", but the field value constraint requires the rating to be between 0 and 5, the system determines that instantiation and validation have failed and generates error message data. Thus, the same processing mechanism can both absorb minor format deviations that can be safely converted and block abnormal content that exceeds the requirements of the data structure.

[0045] Step S140: Write the task result data to the task result field corresponding to the current task item to be completed through the write interface of the controlled submission data area, and update the task cursor field after the task result data is written; or, write the error message data to the metadata field through the write interface of the controlled submission data area.

[0046] In step S140, both the successful and failed branches perform write operations through the write interface of the controlled commit data area, but the written objects and subsequent state changes differ. In the successful branch, the system determines the task result field corresponding to the current task item to be completed based on the task result field correspondence, and then writes the task result data as a whole to the determined task result field through the write interface of the controlled commit data area. A whole write can be understood as committing the task result data with a single interface call, a single transaction, a single state object update, or a single indivisible assignment operation, ensuring that the task result fields do not contain intermediate results where some fields have been written while others remain unverified or unwritten. After the write is complete, the system receives a write completion result indicating that the task result data has been written to the task result field, and then calls the write interface of the controlled commit data area to update the task cursor field, making the task cursor field indicate that the next task item in the task item sequence is the current task item to be completed. This sequence makes process progression dependent on the completion of task result data, reducing the risk of state inconsistency caused by missing task results but the cursor already advancing.

[0047] In a failed branch, the system writes error message data to the metadata field via the write interface of the controlled commit data area. The metadata field stores response data output to downstream components, rather than ordinary log fields or text fields for debugging purposes only. After the error message data is written to the metadata field, the system can send it as response data to downstream components. Downstream components can be front-end rendering components, business orchestration components, message push components, or other components that need to perform subsequent processing based on the process response. Taking the front-end rendering component as an example, it can generate an error alert interface or retry prompt interface based on the error status field and the error message field, and can decide whether to guide the user to re-trigger the current task item based on the current task item identifier or the retry permission field.

[0048] Figure 4 This diagram illustrates a successful submission and failure response branch for some embodiments of this specification. Figure 4In the illustrated process, after instantiation and validation pass, the system determines the task result data, locates the task result field, writes the entire task result field, receives the completion result, and updates the task cursor field. If instantiation and validation fail, the system catches the exception, generates error message data, writes it to the metadata field, and does not execute the task cursor field update operation in the successful branch. Since the failed branch does not generate a completion result for the task result data and does not enter the cursor update chain of the successful branch, subsequent processing can still locate the original currently pending task item based on the current value of the task cursor field, thus supporting downstream components in prompting the user to retry or having the system trigger the candidate processing flow again. Here, "not executing cursor update" is not an isolated effect description, but rather an actual operational result formed by failure catching, error object generation, metadata field writing, and not entering the successful submission chain.

[0049] Figure 5 This is a schematic diagram of a complete embodiment of business process execution control provided for some embodiments of this specification. Figure 5 The illustrated embodiment can be applied to multi-round reservation processes. The computer system maintains a sequence of task items, with the task cursor field initially pointing to the first task item. When the task cursor field points to a task item for which the large language model needs to generate the task execution result, the system calls the large language model and writes the generated content into the candidate temporary data area. The structured content extraction rules in the candidate temporary data area attempt to directly parse the generated content; if this fails, they extract structured data fragments based on code block boundaries or object boundaries. Field normalization rules map non-standard field names in the model output to standard field names. The strongly typed data model performs instantiation processing on the normalized candidate data, completing field value type conversion, default value completion, and value constraint checks. Upon successful completion, the system serializes the type-safe structured data object into task result data, writes it to the task result field corresponding to the current task item according to the task result field correspondence, and advances the task cursor field after receiving the write completion result. If the process fails, the system generates error message data and writes it to the metadata field. Downstream components generate an error message interface, and the task cursor field continues to point to the current task item for subsequent retrying or manual processing.

[0050] In some embodiments, the business process can be implemented jointly by a graph workflow execution engine, execution nodes, state objects, and downstream components. The graph workflow execution engine is responsible for scheduling execution nodes. The state object sets up a candidate temporary data area and a controlled commit data area. The execution nodes are responsible for calling the large language model and executing the processing within the candidate temporary data area. Downstream components receive response data from metadata fields. This runtime environment can be used in conjunction with deterministic state machines, checkpoint persistence, or event-waiting mechanisms. For example, the task cursor field can correspond to the program counter field in the state object, the task result field can correspond to the result field in the task item, and the metadata field can correspond to the response field applied to front-end rendering. However, these specific field names and framework objects are just examples; the candidate temporary data area, controlled commit data area, and controlled write interface can also be implemented using other equivalent data structures or modules.

[0051] In some embodiments, the candidate temporary data area can simultaneously record data objects from multiple stages to facilitate auditing or debugging of the candidate processing. Generated content represents the raw content returned by the large language model; candidate structured data represents structured data objects directly parsed or extracted from the generated content; normalized candidate data represents candidate data whose field names have been normalized; structured data obtained after instantiation and validation represents structured data objects that have undergone type conversion, default completion, mandatory field checking, and value constraint checking according to data structure requirements; and task result data represents the data determined by this structured data and prepared to be written into the task result field. Distinguishing these objects facilitates the use of different processing rules at different stages and also helps prevent candidate data that has not been instantiated and validated from being mistakenly identified as formal task result data.

[0052] In some embodiments, structured content extraction rules can be configured with different parsing strategies based on the output type of the task item. For task items that are expected to output a single object, the structured content extraction rules can prioritize matching object boundaries; for task items that are expected to output a list, they can prioritize matching array boundaries; and for common large language model output formats, they can identify code block boundaries. If multiple candidate fragments exist in the generated content, the system can determine the fragment to be parsed based on fragment position, fragment length, fragment outer structure, or the degree of matching with the current task item's field set. If the selected fragment fails to be parsed, the system can try other fragments according to the configuration, or it can directly determine that the structured content extraction has failed. The above processing is still intermediate processing within the candidate temporary data area and will not be directly written to the controlled submission data area.

[0053] In some embodiments, field normalization rules can be executed according to field alias mapping relationships, or combined with case normalization, delimiter normalization, or field prefix and suffix removal. For example, the system can map "GuideId", "guideId", "guide_id", and "guideID" to the same standard field name. When a field value is written under a standard field name, the mapping record between the original field name and the standard field name can be retained to explain the field's origin when generating error message data. Fields that do not match the mapping relationship can be retained in the normalization candidate data, and the strongly typed data model decides whether to allow additional fields, ignore additional fields, or treat them as anomalies. By layering field normalization with strongly typed model instantiation, the system can first solve the problem of unstable field naming in the model output, and then the data structure requirements can solve the problems of field type, mandatory fields, and value validity.

[0054] In some embodiments, a strongly typed data model can be implemented by data classes, schema definitions, a set of type constraint rules, a runtime validator, or database write constraints. Taking a tour guide candidate object as an example, the model can define the tour guide identifier and name as required fields, the rating as a floating-point number range of 0 to 5, the number of services as an integer field with a default value of 0, and availability as a boolean field with a default value of true. If the rating field in the normalized candidate data is the string "4.5", instantiation can convert it to a floating-point number; if the number of services field is missing, it can be filled with the default value 0; if the tour guide identifier is missing, instantiation and validation will fail because this field is required; if the rating field is 9.9, instantiation and validation will fail because it exceeds the value constraints. This example illustrates that instantiation and validation simultaneously construct structured data objects and prevent abnormal data.

[0055] In some embodiments, the determination of task result data can be performed based on the type of the current task item and the correspondence between task result fields. If the current task item corresponds to a candidate object query, the task result data can be a set of candidate objects; if the current task item corresponds to order information completion, the task result data can be a set of structured order fields; if the current task item corresponds to approval opinion generation, the task result data can be an approval opinion object. The correspondence between task result fields is used to determine which task result field in the controlled submission data area should be written to. Multiple task result fields correspond one-to-one with multiple task items in the task item sequence, giving each task item's execution result a clear attribution. When the task cursor field is updated, the system can advance it to the next task item according to the order of the task item sequence, or it can determine the next task item based on the configuration of the task item sequence, as long as the updated task cursor field can indicate the new currently pending task item.

[0056] In some embodiments, the write interface of the controlled commit data area can provide a write completion result. This result can be indicated by a successful memory state update, a successful database transaction commit, a successful cache write, a successful state object merging, or other acknowledgment signals. The computer system only updates the task cursor field after receiving this write completion result. If the task result data write fails, the system may not update the task cursor field and can convert the write failure information into error message data and write it to the metadata field according to preset error message rules. In this way, a clear write order is established between the task result field and the task cursor field, rather than the process advancement being directly triggered by model output or candidate processing results.

[0057] In some embodiments, error message data generation can utilize different error type fields based on the exception type. For example, structured content extraction failure can correspond to a parsing error type, field normalization processing failure to a field mapping error type, strongly typed data model instantiation failure to a type constraint error type, and field value out-of-range error type to a value constraint error type. The error source field can indicate whether the exception occurred during structured content extraction, field normalization, instantiation processing, or controlled submission. The retry permission field can be determined based on the error type; for example, parsing errors and model output format exceptions can allow retries, while errors lacking necessary business parameters can prompt for additional parameters. After receiving these fields, downstream components can generate different error alarm interfaces or retry prompt interfaces, thereby improving the handleability of failure responses.

[0058] In some embodiments, metadata fields can store error message data not only in failure scenarios but also in success scenarios, storing response data for downstream components. For example, after task result data is successfully written to the task result field, the system can write response data for downstream components to render the current task completion status to the metadata field; in failure scenarios, the metadata field writes error message data. Regardless of success or failure, the metadata field is directed to a response object that can be parsed by downstream components, rather than arbitrary log text. In this way, downstream components can always parse and display based on stable fields.

[0059] The above describes a business process execution control method provided by an embodiment of this specification. Based on the same technical concept, this specification also provides a business process execution control device. This device may include a candidate temporary data area management module, a controlled submission data area management module, a large language model invocation module, a structured content extraction module, a field normalization module, an instantiation and validation module, a task result submission module, and an error response module. The candidate temporary data area management module is used to establish and maintain a candidate temporary data area, and receive generated content and intermediate processing data returned by the large language model. The controlled submission data area management module is used to maintain a task cursor field, multiple task result fields, and metadata fields, and provides a controlled write interface. The large language model invocation module is used to invoke the large language model and obtain generated content when the current task item requires model participation. The structured content extraction module is used to obtain candidate structured data from the generated content. The field normalization module is used to converge non-standard field names into standard field names according to field normalization rules. The instantiation and validation module is used to form structured data objects according to data structure requirements and perform type conversion, default value completion, required field checking, and value constraint checking. The task result submission module is used to determine the task result data, write it to the corresponding task result field, and update the task cursor field after writing is completed when instantiation and validation pass. The error response module is used to generate error message data and write it to the metadata field when instantiation and validation fail or when there is an exception in the preceding processing.

[0060] Figure 2 The data area and interface relationship shown can also correspond to the above-described device embodiment. The candidate temporary data area management module is located after the large language model output interface, and the controlled submission data area management module is located before the task result field, task cursor field, and metadata field. The candidate processing module and the task result submission module jointly determine when to call the controlled submission data area write interface. Since the large language model output interface is not directly connected to the controlled submission data area write interface, the device embodiment can also prevent the direct writing of model-generated content to the formal data area. Each module can be deployed in the same service process, or it can be deployed in a distributed manner according to the business process engine, model call service, and state storage service.

[0061] This specification also provides a computer device. The computer device includes a processor, a memory, and a communication interface. The memory stores a computer program and data structures for business process execution control. When the processor executes the computer program, it can establish a candidate temporary data area and a controlled submission data area. In tasks requiring model participation, it calls a large language model and writes the generated content into the candidate temporary data area. It performs structured content extraction, field normalization, instantiation, and validation, and submits the task result or responds to errors based on whether it passes or fails. The communication interface can be used to communicate with a large language model service, downstream components, business process callers, or external tool services. This computer device can operate independently as a process control server, or as a service instance in a cloud platform or a node in a distributed system.

[0062] This specification also provides a computer program product. The computer program product includes a computer program that, when executed by a processor, causes the processor to execute the aforementioned business process execution control method. The computer program product can be deployed as a business process engine plugin, a model output interception component, server-side middleware, or a containerized service. By deploying this computer program product, systems that originally relied on large language models to generate structured content can add candidate caching, instantiation and validation, and controlled submission processing between model output and final submission, making the data structure received by downstream components more stable.

[0063] This specification also provides a computer-readable storage medium. This computer-readable storage medium stores a computer program, which, when executed by a processor, implements the aforementioned execution control method for the business process. The computer-readable storage medium can be a non-volatile storage medium or other media capable of being read and loaded by a computer device. The stored computer program may include components such as a structured content extraction program, a field normalization program, a strongly typed data model instantiation program, a controlled submission program, and an error response program. These programs work together to achieve a controlled transformation from untrusted generated content to task result data or error message data.

[0064] The above descriptions are merely some embodiments of this specification and are not intended to limit this specification. Various modifications and variations can be made to this specification by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this specification should be included within the scope of protection of this specification.

Claims

1. A method for controlling the execution of a business process, characterized in that, Applied to a computer system, the computer system is provided with a candidate temporary data area and a controlled submission data area; The candidate temporary data area is used to store the generated content returned by the large language model and the intermediate processing data obtained from the generated content. The controlled submission data area includes a task cursor field, multiple task result fields, and a metadata field. The task cursor field is used to indicate the current task item to be completed in the task item sequence of the business process. The multiple task result fields correspond one-to-one with the multiple task items in the task item sequence. Each task result field is used to store the task execution result of the corresponding task item. The metadata field is used to store the response data output to downstream components. The output interface of the large language model is isolated from the write interface of the controlled submission data area; The method includes: When a task to be completed requires calling the large language model to determine the task execution result, the large language model is called to obtain the generated content returned by the large language model and the generated content is written into the candidate temporary data area. Within the candidate temporary data area, the following steps are performed: Structured content extraction is performed on the generated content to obtain candidate structured data; the field names in the candidate structured data are normalized according to the field normalization rules corresponding to the current task item to be completed, to obtain normalized candidate data; the normalized candidate data is instantiated and validated according to the data structure requirements corresponding to the current task item to be completed, wherein the data structure requirements include at least one of field structure requirements, field type requirements, required field requirements, default field definitions, and field value constraints; if instantiation and validation pass, the task result data is determined based on the structured data obtained after instantiation and validation; if instantiation and validation fail, error message data is generated according to preset error message rules. The task result data is written to the task result field corresponding to the currently pending task item through the write interface of the controlled submission data area. After the task result data is written, the task cursor field is updated so that the task cursor field indicates the next task item in the task item sequence as the currently pending task item. Alternatively, the error message data is written to the metadata field through the write interface of the controlled submission data area.

2. The method according to claim 1, characterized in that, The computer system is configured with a structured submission configuration corresponding to at least one task in the task item sequence that needs to call the large language model; The structured submission configuration includes structured content extraction rules, field alias mapping relationships, strongly typed data models, and task result field correspondence relationships; The structured content extraction rules are used to obtain candidate structured data from the generated content. The field alias mapping relationship is used to map non-standard field names in the candidate structured data to standard field names. The strongly typed data model is used to characterize the data structure requirements that match the corresponding task item. The task result field correspondence relationship is used to determine the task result field to be written after the task result data passes the verification.

3. The method according to claim 2, characterized in that, The generated content is subjected to structured content extraction to obtain candidate structured data, including: According to the structured content extraction rules, the generated content is subjected to direct structured parsing; If the direct structured parsing is successful, the data object obtained from the direct structured parsing will be identified as the candidate structured data. If direct structured parsing fails, a structured data fragment is matched in the generated content according to a preset boundary identifier, which includes at least one of a code block boundary identifier, a structured data object boundary identifier, and a structured data array boundary identifier. If the structured data fragment is matched, structured parsing is performed on the structured data fragment, and if the parsing is successful, the parsed data object is determined as the candidate structured data. If the structured data fragment is not matched or the parsing of the structured data fragment fails, the extraction of structured content is determined to have failed.

4. The method according to claim 2, characterized in that, The field alias mapping relationship includes at least one correspondence between a non-standard field name and a standard field name. The non-standard field name includes at least one of the following: camelCase field name, case-variant field name, abbreviated field name, and synonym field name corresponding to the standard field name. The standard field name is the field name in the strongly typed data model. According to the field normalization rules corresponding to the current task items to be completed, the field names in the candidate structured data are normalized to obtain normalized candidate data, including: Traverse the field names in the candidate structured data; if a traversed field name matches the field alias mapping relationship, write the field value corresponding to the field name to the standard field name indicated by the field alias mapping relationship; if a traversed field name does not match the field alias mapping relationship, retain the field name and its field value; generate the normalized candidate data based on the field value written to the standard field name and the retained field name and field value.

5. The method according to claim 2, characterized in that, The strongly typed data model includes at least one of the following: a required field definition, a field type definition, a default field definition, and a field value constraint definition corresponding to the current task item to be completed; the required field definition is used to limit the fields that must exist in the normalized candidate data; the field type definition is used to limit the data type of the field value in memory; the default field definition is used to limit the default value written when the field is missing; and the field value constraint definition is used to limit at least one of the following: the numerical range, the enumeration range, and the format condition of the field value. The normalized candidate data is validated according to the data structure requirements corresponding to the current task item to be completed, including: The normalized candidate data is input into the strongly typed data model so that the strongly typed data model performs instantiation processing on the normalized candidate data; In the instantiation process, type conversion is performed on field values, default value completion is performed on fields that are missing and have default field definitions, and value constraint validation is performed on field values; if type conversion fails, required fields are missing, or field values ​​do not meet the value constraint validation, the validation is determined to fail.

6. The method according to claim 2, characterized in that, If the verification passes, the task result data is determined based on the normalized candidate data, including: serializing the type-safe structured data object obtained by instantiation of the strongly typed data model into task result data corresponding to the current task item to be completed, wherein the task result data includes a set of structured fields corresponding to the field names in the strongly typed data model; The task result data is written to the task result field corresponding to the current task item to be completed through the write interface of the controlled submission data area, including: determining the task result field corresponding to the current task item to be completed according to the correspondence of the task result fields; and writing the task result data as a whole into the determined task result field through the write interface of the controlled submission data area.

7. The method according to claim 1, characterized in that, After the task result data is written, update the task cursor field, including: After receiving a write completion result indicating that the task result data has been written to the task result field, the write interface of the controlled submission data area is called to update the task cursor field.

8. The method according to claim 1, characterized in that, If the verification fails, error message data will be generated according to the preset error message rules, including: In the event that the structured content extraction fails, the field name normalization processing fails, or the instantiation processing of the strongly typed data model fails, the corresponding parsing exception, field normalization exception, or strong type validation exception is captured. The error message data is generated based on the captured anomaly according to the preset error message rules; The error message data includes an error status field and an error message field; the error status field is used to indicate that the generated content has not been successfully converted into task result data that meets the requirements of the data structure, and the error message field is used for downstream components to display or process; the error message data also includes at least one of the following: current task item identifier, error type field, error source field, and whether retry is allowed field.

9. The method according to claim 8, characterized in that, After writing the error message data to the metadata field through the write interface of the controlled submission data area, the method further includes: The error message data in the metadata field is sent to the downstream component as response data output to the downstream component; wherein, the downstream component includes a front-end rendering component, which generates an error alarm interface or a retry prompt interface based on the error status field and the error message field.

10. A computer program product, characterized in that, It stores at least one instruction, which, when executed by a processor, implements the method as described in any one of claims 1-9.

Images