Dynamic configuration method and device for multi-link transfer service and medium
By dynamically configuring methods and equipment, the problems of long development cycles and high costs in multi-stage business processes have been solved, enabling flexible customization of business processes and data isolation, thereby improving the stability and maintainability of the system.
Patent Information
- Application Number
- CN202511035012.2
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-07-25
- Publication Date
- 2025-11-11
AI Technical Summary
Traditional multi-stage workflow processes have long development cycles and high costs, making it difficult to achieve standardized governance and unified management. Furthermore, the fixed preset workflow processes cannot support flexible customization and rapid iteration.
By receiving business configuration information into the registry of the multi-stage business framework, reading and updating metadata, triggering permission verification, generating state change instructions, and storing the data in an independent physical storage space, dynamic configuration is achieved.
It lowers the barrier to entry for new business launches, supports flexible adjustments to business processes, ensures operational permissions and data isolation, and improves system stability and maintainability.
Smart Images
Figure CN120935245A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of computer technology, specifically to a dynamic configuration method, device, and medium for multi-stage business processes. Background Technology
[0002] As enterprises accelerate their digital transformation, the market demand for multi-stage workflow-related businesses is growing rapidly. These businesses are characterized by numerous process nodes, complex role divisions, and extremely frequent data transfers, and their development often faces many complex challenges.
[0003] In traditional development models, for multi-stage workflow businesses, it's often necessary to design the database independently for each business scenario, while simultaneously writing lengthy and tedious process logic code line by line. This model results in a lengthy development cycle, requiring a significant investment of time and manpower from the initial requirements analysis through solution design, code development, and testing to deployment. More importantly, the metadata configurations of different businesses inherently differ, making it difficult to achieve standardized governance and unified management of data in a decentralized development environment. Furthermore, traditional frameworks often use fixed, pre-defined business workflow stages, making it difficult to support flexible customization of business stages. This not only severely restricts rapid iteration and flexible expansion of the business but also keeps subsequent system maintenance costs consistently high. Summary of the Invention
[0004] To address the aforementioned issues, this application proposes a dynamic configuration method for multi-stage workflow processes, including:
[0005] Upon receiving the first access request of the target service, the service configuration information corresponding to the target service is added to the service registry of the multi-stage service framework;
[0006] Read the original metadata in the multi-stage business framework, update the parameterized variables in the original metadata based on the actual business parameters of the target business, and obtain the corresponding target adaptation metadata;
[0007] Trigger a business process flow event, and verify the operation permissions of the current triggering end based on the current adaptation metadata corresponding to the current business process in the multi-process business framework.
[0008] Once the verification is successful, a process status change instruction is generated based on the process type sequence in the global business registry and the business status corresponding to the current business process.
[0009] Execute the stage status change instruction, and based on the stage type and unique identifier of the current service, match the corresponding target physical storage space and store the stage data after the status change in the target physical storage space.
[0010] On the other hand, this application also proposes a dynamic configuration device for multi-stage workflow services, comprising:
[0011] At least one processor; and,
[0012] A memory communicatively connected to the at least one processor; wherein,
[0013] The memory stores instructions that can be executed by the at least one processor, which, when executed by the at least one processor, enables the at least one processor to perform a dynamic configuration method for a multi-stage flow service, as described in the example above.
[0014] On the other hand, this application also proposes a non-volatile computer storage medium storing computer-executable instructions, wherein the computer-executable instructions are configured as: a dynamic configuration method for a multi-stage flow service as described in the above example.
[0015] The dynamic configuration method for multi-stage business processes proposed in this application can bring the following benefits:
[0016] By integrating new businesses into a unified management framework through the business registration process, redundant work such as repetitive database design and process logic writing, as in traditional models, is avoided. Parameterized metadata adaptation, through dynamic variable replacement, enables rapid conversion from general templates to personalized configurations, meeting the differentiated needs of various businesses without modifying the underlying code. This model significantly lowers the barrier to entry for new business deployment, allowing development to focus on personalized business logic while supporting flexible adjustments to business processes as needs change, effectively addressing expansion requirements across various scenarios.
[0017] Meanwhile, a permission matching mechanism based on adaptive metadata ensures that only authorized triggers can execute corresponding operations, avoiding process chaos caused by unauthorized operations. Independent physical storage spaces allocated according to business identifiers and process types achieve strict isolation of different business data, reducing the risk of data interference and leakage. The standardized generation of state change instructions guarantees the orderly flow of business processes, making the entire process traceable and controllable, ultimately improving the system's stability, security, and maintainability, making it suitable for long-term operation in various process-oriented business scenarios. Attached Figure Description
[0018] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:
[0019] Figure 1 This is a flowchart illustrating a dynamic configuration method for multi-stage workflow services in an embodiment of this application.
[0020] Figure 2 This is a schematic diagram of the multi-stage business framework in the embodiments of this application;
[0021] Figure 3 This is a schematic diagram of a dynamic configuration device for a multi-stage workflow service in an embodiment of this application. Detailed Implementation
[0022] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions of this application 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 application, and not all of them. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.
[0023] The technical solutions provided by the various embodiments of this application are described in detail below with reference to the accompanying drawings.
[0024] like Figure 1 As shown in the figure, this application embodiment provides a dynamic configuration method for multi-stage workflow services, including:
[0025] S101: Receive the first access request of the target service and add the service configuration information corresponding to the target service to the service registry added to the multi-stage service framework.
[0026] Specifically, when receiving the first access request from a target service, the service configuration information needs to be registered through the service registration service. This involves obtaining the target service's unique identifier (biz_type), service name (biz_type_name), associated role identifier (specialist_role), and the included sequence of service stage types (node_types). The service configuration information is then added to the service registry of the multi-stage service framework in dictionary form to complete the registration of the target service within the multi-stage service framework.
[0027] It should be noted that when performing an operation or receiving an operation request, the multi-stage business framework automatically loads the business registry, thereby completing the registration of the target business in the framework, making it a business object that the framework can recognize and manage, and laying the foundation for subsequent process processing.
[0028] In this embodiment, the method further includes determining whether the target service is accessing for the first time. Specifically, the method receives the access request of the target service, parses the unique identifier of the target service from the request, performs a matching verification in the service registry based on the unique identifier, checks whether there is a record that is completely consistent with the target service's fields, and determines whether it is accessing for the first time based on the matching result. If no record matching the target service is found in the service registry, the service is determined to be accessing for the first time, and it is allowed to enter the subsequent service configuration information registration process; if a matching record is found, the service is determined to have been accessed before, and the system will trigger a duplicate access processing mechanism.
[0029] It should be noted that this application implements a multi-stage business framework for new business access through a business registration service class (EvalNodeRegistry). The business registration service class primarily relies on the __biz_type_registry__ list, which is the core data structure for storing business registration information. Each element in the list is a dictionary containing the following key fields: biz_type is a unique identifier for the business, used to distinguish different businesses in the system; biz_type_name is the name of the business, usually a descriptive name that is easy to understand, used in user interface display or log recording scenarios; specialist_role is the role identifier, which can be used for permission management, role association in business processes, etc. Different businesses may be associated with different roles; node_types is a list of workflow stages supported by the business, defining the various stages included in the business, which constitute the complete business process.
[0030] When a new service needs to be integrated into the system, specify the `biz_type`, `biz_type_name`, `specialist_role`, and `node_types` for the new service. For example, for the professional title evaluation service, `biz_type` could be set to "title", `biz_type_name` to "Professional Title Evaluation", `specialist_role` to "cm-title", and `node_types` to include stages such as "individual_declaration" (individual application) and "qualification_audit" (qualification audit). Add the dictionary containing the above information to the `__biz_type_registry__` list.
[0031] S102: Read the original metadata in the multi-stage business framework, update the parameterized variables in the original metadata based on the actual business parameters of the target business, and obtain the corresponding target adaptation metadata.
[0032] Specifically, the pre-defined raw metadata in the multi-read business framework contains parameterized variables to adapt to the differentiated needs of different businesses. Through the metadata management service, the parameterized variables of the raw metadata are dynamically updated based on the actual business parameters of the target business (such as business type, role information, etc.), replacing the parameterized variables of the raw metadata with the actual business parameters of the target business, and generating target-adaptive metadata that meets the needs of that business.
[0033] It's important to note that raw metadata is a pre-defined, general-purpose basic metadata configuration within a multi-stage workflow business framework. Its core feature is the inclusion of parameterized variables, which act as placeholders to adapt to the differentiated needs of various businesses. These variables don't specifically refer to any particular business but rather reserve expansion space, providing a basic template for the framework to support multiple business scenarios. Adaptive metadata, on the other hand, is the result of dynamic processing of the raw metadata. It is tailored to a specific business, directly matching its actual needs. It includes business-specific parameters, roles, process rules, and other information, and is a key outcome of the framework's support for personalized business configuration, ensuring that the metadata accurately serves the workflow and management of a specific business.
[0034] In this embodiment of the application, the specific process for updating parameterized variables in the original metadata is as follows: based on the unique business identifier of the target business, the corresponding actual business parameters are matched and obtained in the global business registry; the fields in the original metadata are traversed, the parameterized variables are identified, and the parameterized variables are replaced with the actual business parameters to obtain the corresponding target adaptation metadata.
[0035] Specifically, based on the unique identifier of the target business, the corresponding actual business parameters are matched and extracted from the global business registry. These actual business parameters include the business name (biz_type_name), associated role identifier (specialist_role), and supported process types (node_types). The pre-defined raw metadata in the multi-process business architecture is read, and all fields of the raw metadata are traversed. By identifying the variable format, the parameterized variables that need to be replaced are located. A mapping relationship between parameterized variables and replacement methods is pre-established. The corresponding replacement method is called, receiving the actual business parameters obtained from the registry, replacing the parameterized variables with specific values, and obtaining the target adaptation metadata.
[0036] The replaced metadata strings are scanned to check for any unreplaced business parameters, ensuring the accuracy of the metadata and eliminating any missing variables. If the check passes, the generated metadata is the target-fit metadata that meets the target business requirements; if any unreplaced variables are found, an exception is thrown indicating a configuration error, ensuring the accuracy of the adapted metadata.
[0037] It should be noted that this application utilizes the metadata management service (EvalControlEntityModel) to achieve parameterized definition and automatic replacement of metadata configurations, thereby meeting the differentiated needs of different businesses in metadata configuration. For example... Figure 2 The diagram illustrates the architecture of a multi-stage business framework. Specifically, for the metadata configuration of various business functions, specific parameter variables are pre-defined, such as #eval_param_biz_type_or_title# and #eval_param_specialist_role_or_title#. These parameter variables are embedded as placeholders in the metadata configuration, representing information that changes under different business scenarios. For example, in the metadata configuration related to organizational structure, the role field is set to "#eval_param_specialist_role_or_title#", and the business type field is set to "#eval_param_biz_type_or_title#", making the metadata configuration universal and allowing the specific values to be dynamically adjusted according to different business needs.
[0038] When the metadata management service `EvalControlEntityModel.get_meta` is called to retrieve metadata, it first calls the `get_meta` method of its parent class `BaseEntityModel` to obtain the unprocessed raw metadata `origin_meta`. Next, the `control_meta_handle` method is called to replace the raw metadata. This includes: using the `get_control_meta_info` method, comparing the metadata name (in the format "{model}.{meta_biz_type}.{state}") with the information recorded in `__eval_control_metas_registry__` to determine whether the current metadata is under management and to identify its corresponding business type. If the current metadata is under management and the business is registered, the corresponding business registration information `registry_info` is obtained; if the business is not registered, it is processed according to established rules. The mapping relationship between parameter variables defined in the raw metadata `control_meta_params` and the replacement methods is traversed. For each parameter variable in the metadata, the corresponding replacement method is called to replace it with the actual business-related value, generating the replaced metadata string `origin_meta_str`.
[0039] The replaced string origin_meta_str is converted into the metadata dictionary format origin_meta_new, and the original metadata origin_meta is updated accordingly to ensure that the obtained metadata meets the actual needs of the current business.
[0040] After the metadata replacement operation is completed, a security check is performed on the processed metadata string `origin_meta_str`. The check examines for any unreplaced `#eval_param` related variables. If such unreplaced variables are found, it indicates a potential anomaly in the metadata configuration. The system will throw an `errors.DATA_RULE_ERROR` exception with the error message "Submission and review framework metadata anomaly: Unreplaced variables exist," prompting relevant personnel to investigate and rectify the issue. This ensures the accuracy and integrity of the metadata and guarantees the stable operation of the system.
[0041] S103: Trigger a business process flow event, and verify the operation permissions of the current triggering end based on the current adaptation metadata corresponding to the current business process in the multi-process business framework.
[0042] Specifically, when a business process flow event (such as submission or rollback) is triggered, the flow scheduling service is invoked, and the operation permissions of the triggering end are verified based on the target adaptation metadata corresponding to the current business process. The current adaptation metadata contains permission-related configurations. By comparing the role permissions of the triggering end with the permission rules in the metadata, it is determined whether it has the permission to execute the current operation, ensuring the security of the business flow.
[0043] In this embodiment of the application, the specific process of verifying the operation permission of the current triggering end is as follows: the current adaptation metadata is parsed, the corresponding operation permission information is extracted, the operation permission information includes a list of executable triggering ends and a set of executable state change types, the operation context of the current triggering end is obtained, the operation context and the operation permission information are matched, and it is determined whether the current triggering end has the operation permission for the current business process.
[0044] Specifically, the current adaptation metadata corresponding to the current business process is parsed. During the parsing process, two types of key operation permission information are located and extracted: a list of executable trigger ends and a set of executable state change types. The list of executable trigger ends refers to the identity identifiers of the trigger ends allowed to perform operations on the current process; the set of executable state change types refers to the types of state change operations allowed in the current process. The operation context of the current trigger end is obtained. The operation context includes key information such as the identity information of the trigger end (e.g., the current user's role identifier and user group), the state change type of the current operation request, and the real-time status of the current business process.
[0045] Furthermore, permission matching is performed. On one hand, it checks whether the identity information of the current triggering end exists in the list of executable triggering ends to verify whether it belongs to an authorized operation subject. On the other hand, it checks whether the status change type of the current request is included in the set of executable status change types to confirm whether the operation is allowed in the current stage. Only when both triggering ends are legitimate and the operation type is allowed is the current triggering end deemed to have the operation permission for the current business stage determined; if either condition is not met, it is determined that there is no permission and the operation is refused.
[0046] It should be noted that this application utilizes a workflow scheduling service (TitleEvalProcessNodeAPIService) to automate business process flow, and employs standardized API interfaces to enable data transfer and process control between different stages. The workflow scheduling service provides key API interfaces required by the business process, including operations such as submitting review results, advancing to the next stage, and reverting to the previous stage. By calling these interfaces, the system can drive business data to flow between different stages according to predetermined rules, ensuring the orderly execution of the business process.
[0047] S104: After the verification is successful, a process status change instruction is generated based on the process type sequence in the global business registry and the business status corresponding to the current business process.
[0048] Specifically, once the operation permission verification is passed, a process status change instruction is generated through the logic of the flow scheduling service based on the process type sequence of the target business in the global business registry and the current status of the business process.
[0049] Furthermore, the flow type corresponding to the stage state change instruction is determined. When the stage state change instruction is a forward flow instruction, the next business stage is determined according to the stage type sequence, a state transition marker is generated and added to the current business stage. When the stage state change instruction is a reverse rollback instruction, the previous business stage is determined, a data rollback marker is generated and added to the current business stage, the execution context of the previous business stage is obtained, rollback reason metadata is generated, and the rollback reason metadata is written into the current adaptation metadata corresponding to the current business stage.
[0050] The rollback reason metadata includes fields such as the rejection timestamp, the role of the rejecting operator, and the description or code of the rejection reason.
[0051] It should be noted that the workflow scheduling service includes submission interfaces and rollback interfaces. The submission interfaces include `submit_from_individual_batch` and `common_complete_batch`. The `submit_from_individual_batch` interface is used to batch submit data from the individual declaration stage to subsequent stages. When this interface is called, it first obtains the data to be submitted, then, in collaboration with the factory service, obtains the data model corresponding to the individual declaration stage, completes data verification, stores it in the corresponding database table, and updates the stage status. The `common_complete_batch` interface is used to submit the data from the current stage to the next stage. Based on the process definition obtained from the business registration service, this interface determines the node type of the next stage, obtains the corresponding data model through the factory service, completes data format conversion and transmission, and updates the process instance status.
[0052] The rollback interface includes the `reject_to_previous_batch` interface, which is used to reject the business process back to the previous stage. When the interface is called, the current and previous stage data models are obtained through the factory class service, data rollback and stage status update are completed, and the reason for rejection is recorded.
[0053] S105: Execute the link status change instruction, match the corresponding target physical storage space based on the link type and the unique identifier of the current service, and store the link data after the status change in the target physical storage space.
[0054] Specifically, when executing a process state change instruction, the factory service matches the corresponding dedicated storage model based on the current business process type and unique business identifier. Each business and its process data is assigned an independent database table, achieving physical isolation between different business data. The process data after the state change is stored in the target physical storage space of the dedicated storage model, avoiding coupling with other business data and ensuring data security and stability.
[0055] In the embodiments of this application, the specific process for matching the corresponding target physical storage space is as follows: scan all subclasses of the predefined stage base class, construct a stage class information database, match the current stage's business type and corresponding current business unique identifier in the stage class information database, obtain the stage execution class, and allocate an independent target physical storage space according to the storage rules corresponding to the stage execution class.
[0056] Specifically, the `get_node_class_lib` method of the factory class service constructs a stage class information library. The `get_node_class_lib` method first imports the predefined stage base class `TitleEvalBaseNodeClass`, then iterates through all subclasses of this base class—the basic implementation classes of each business stage—and further extracts the sub-subclasses that these subclasses may contain—the stage extension classes for specific business scenarios. Matching is then performed based on the business type and corresponding unique business identifier information library of the current business stage. By calling the `get_node_class_by_node_type` method of the factory class service, passing in the `_node_type_` of the current stage, this method iterates through `__node_lib__`, searching for sub-subclass information that matches both the current business type `biz_type` and the stage type `__node_type__`, ultimately determining the corresponding stage execution class.
[0057] Independent target physical storage space is allocated based on the storage rules corresponding to the matched execution stage class. The execution stage class predefines the data storage structure specifications. For example, in the individual application stage of the professional title evaluation business, the storage rules specify that the data is stored in the `title_eval_individual_declaration` table. Based on this rule, a dedicated database table or storage model is allocated to the data of the current business stage, ensuring that the data of this business stage is completely isolated from data of other business stages and other stages at the physical level, avoiding mutual interference and ensuring data security and stability.
[0058] Before allocating an independent target physical storage space, the process includes: determining whether the target physical storage space exists based on the current business unique identifier; if not, generating a target physical storage space naming identifier based on the current business unique identifier and the corresponding process type; constructing a storage structure description file based on the data field rules in the current adaptation metadata; creating the target physical storage space; and generating the corresponding storage engine interface; if yes, binding the permissions corresponding to the current triggering end to the target physical storage space.
[0059] Specifically, based on the unique identifier (biz_type) of the current business and combined with the type of the current business process (node_type), the system queries whether the corresponding target physical storage space already exists in the storage management module. This decision relies on a storage index, which records the associations between all created storage spaces and their unique identifiers and the type of the current business process.
[0060] If the target physical storage space is determined to be non-existent, it is created. First, a named identifier is generated to ensure its uniqueness and business relevance. Second, based on the data field rules in the current adaptation metadata, a storage structure description file is constructed, clarifying the field composition and relationships of the storage space. Finally, physical storage spaces (such as database tables, independent datasets, etc.) are created according to the description file, and corresponding storage engine interfaces are automatically generated. These interfaces encapsulate standardized methods for adding, deleting, modifying, and querying data, providing a unified access point for subsequent business data operations.
[0061] If the target physical storage space already exists, the permission binding process is executed. This involves extracting the identity identifier from the current triggering endpoint's operation context and associating this identifier with the access permission rules of the target physical storage space. The binding process is completed by calling the storage permission management service, ensuring that the current triggering endpoint can only operate on the data in that storage space within its authorized scope, further enhancing the security and controllability of data access.
[0062] In the embodiments of this application, the specific process for storing the stage data after the status change into the target physical storage space is as follows: according to the data structure rules in the current adaptation metadata, the legality of the stage data after the status change is verified. When the verification is successful, the stage status change result is written into the process metadata field in the current adaptation metadata, and the stage data after the status change is stored into the target physical storage space through the storage engine interface.
[0063] It should be noted that the factory service (TitleEvalNodeClassFactory) is used to achieve independent storage of data flowing through different business stages and to provide corresponding model class support for business data operations. The core function of the factory service is to obtain the corresponding model class based on the __node_type__ defined in the model class of the flow stage, thereby supporting the creation, deletion, modification, and query operations of business data, realizing independent storage of different business data, and avoiding mutual interference between different business data.
[0064] By integrating new businesses into a unified management framework through the business registration process, redundant work such as repetitive database design and process logic writing, as in traditional models, is avoided. Parameterized metadata adaptation, through dynamic variable replacement, enables rapid conversion from general templates to personalized configurations, meeting the differentiated needs of various businesses without modifying the underlying code. This model significantly lowers the barrier to entry for new business deployment, allowing development to focus on personalized business logic while supporting flexible adjustments to business processes as needs change, effectively addressing expansion requirements across various scenarios.
[0065] Meanwhile, a permission matching mechanism based on adaptive metadata ensures that only authorized triggers can execute corresponding operations, avoiding process chaos caused by unauthorized operations. Independent physical storage spaces allocated according to business identifiers and process types achieve strict isolation of different business data, reducing the risk of data interference and leakage. The standardized generation of state change instructions guarantees the orderly flow of business processes, making the entire process traceable and controllable, ultimately improving the system's stability, security, and maintainability, making it suitable for long-term operation in various process-oriented business scenarios.
[0066] like Figure 3 As shown in the embodiments of this application, a dynamic configuration device for multi-stage workflow services is also proposed, including:
[0067] At least one processor; and,
[0068] A memory communicatively connected to the at least one processor; wherein,
[0069] The memory stores instructions that can be executed by the at least one processor, which, when executed by the at least one processor, enables the at least one processor to perform a dynamic configuration method for a multi-stage flow service as described in any of the above embodiments.
[0070] This application also provides a non-volatile computer storage medium storing computer-executable instructions, wherein the computer-executable instructions are configured as: a dynamic configuration method for multi-stage flow services as described in any of the above embodiments.
[0071] The various embodiments in this application are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the device and medium embodiments are basically similar to the method embodiments, so the description is relatively simple; relevant parts can be referred to the description of the method embodiments.
[0072] The devices and media provided in this application are one-to-one with the methods. Therefore, the devices and media also have similar beneficial technical effects as their corresponding methods. Since the beneficial technical effects of the methods have been described in detail above, the beneficial technical effects of the devices and media will not be repeated here.
[0073] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.
[0074] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.
[0075] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.
[0076] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.
[0077] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.
[0078] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.
[0079] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information using any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic magnetic disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.
[0080] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.
[0081] The above description is merely an embodiment of this application and is not intended to limit this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principle of this application should be included within the scope of the claims of this application.
Claims
1. A dynamic configuration method for multi-stage workflow processes, characterized in that, include: Upon receiving the first access request of the target service, the service configuration information corresponding to the target service is added to the service registry of the multi-stage service framework; Read the original metadata in the multi-stage business framework, update the parameterized variables in the original metadata based on the actual business parameters of the target business, and obtain the corresponding target adaptation metadata; Trigger a business process flow event, and verify the operation permissions of the current triggering end based on the current adaptation metadata corresponding to the current business process in the multi-process business framework. Once the verification is successful, a process status change instruction is generated based on the process type sequence in the global business registry and the business status corresponding to the current business process. Execute the stage status change instruction, and based on the stage type and unique identifier of the current service, match the corresponding target physical storage space and store the stage data after the status change in the target physical storage space.
2. The method for implementing multi-stage business flow according to claim 1, characterized in that, The configuration information includes a unique business identifier, business name, associated role permissions, and a sequence of business process types. The step of updating the parameterized variables in the original metadata based on the actual business parameters of the target business to obtain the corresponding target adaptation metadata specifically includes: Based on the unique business identifier of the target business, the corresponding actual business parameters are matched and obtained from the global business registry. The fields in the original metadata are traversed, parameterized variables are identified, and the parameterized variables are replaced with the actual business parameters to obtain the corresponding target adaptation metadata.
3. The method for implementing multi-stage business flow according to claim 1, characterized in that, The step of verifying the operation permissions of the current triggering end based on the current adaptation metadata corresponding to the current business link in the multi-link business framework specifically includes: The current adaptation metadata is parsed to extract the corresponding operation permission information; the operation permission information includes a list of executable trigger ends and a set of executable state change types; Obtain the operation context of the current triggering end, match the operation context with the operation permission information, and determine whether the current triggering end has the operation permission for the current business process.
4. The method for implementing multi-stage business flow according to claim 3, characterized in that, The step of matching the operation context and the operation permission information to determine whether the current triggering end has the operation permission for the current business process specifically includes: Extract the request execution state change type from the operation context; Determine whether the role identifier corresponding to the current triggering end and the request execution status change type match the operation permission information; If the user role identifier is in the list of executable triggers and the request execution status change type is in the set of executable status change types, then the current trigger has the necessary permissions and the authorization is granted.
5. The method for implementing multi-stage business flow according to claim 1, characterized in that, After generating a stage status change instruction based on the stage type sequence in the global business registry and the business status corresponding to the current business stage, the method further includes: Determine the flow type corresponding to the process status change instruction; When the state change instruction of the process is a positive flow instruction, the next business process is determined according to the process type sequence, a state transition marker is generated and added to the current business process; When the state change instruction of the process is a reverse rollback instruction, the previous business process is determined, a data rollback mark is generated and added to the current business process; Obtain the execution context of the previous business process, generate rollback reason metadata, and write the rollback reason metadata into the current adaptation metadata corresponding to the current business process.
6. The method for implementing multi-stage business flow according to claim 1, characterized in that, The step of matching the corresponding target physical storage space based on the process type and unique identifier of the current service specifically includes: Scan all subclasses of the predefined base class of stages to build a stage class information database; Based on the business type of the current stage and the corresponding unique identifier of the current business, a matching is performed in the stage class information database to obtain the stage execution class; Based on the storage rules corresponding to the execution class of the aforementioned stage, allocate independent target physical storage space.
7. The method for implementing multi-stage business flow according to claim 6, characterized in that, Before allocating independent target physical storage space according to the storage rules corresponding to the execution class of the step, the method further includes: Based on the current service unique identifier, determine whether the target physical storage space exists; If not, then generate a target physical storage space naming identifier based on the current business unique identifier and the corresponding process type of the current business; Based on the data field rules in the current adaptation metadata, construct a storage structure description file, create the target physical storage space, and generate the corresponding storage engine interface; If so, the permissions corresponding to the current triggering end will be bound to the target physical storage space.
8. The method for implementing multi-stage business flow according to claim 7, characterized in that, The step of storing the changed process data in the target physical storage space specifically includes: Based on the data structure rules in the current adapted metadata, verify the legality of the process data after the status change; Once the verification is successful, the process status change result will be written into the process metadata field of the current adaptation metadata. The changed process data is stored in the target physical storage space through the storage engine interface.
9. A dynamic configuration device for multi-stage workflow operations, characterized in that, include: At least one processor; as well as, A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor, which, when executed by the at least one processor, enables the at least one processor to perform a dynamic configuration method for a multi-stage flow service as described in any one of claims 1 to 8.
10. A non-volatile computer storage medium storing computer-executable instructions, characterized in that, The computer-executable instructions are configured as a dynamic configuration method for multi-stage flow business as described in any one of claims 1 to 8.