Business state change method and device based on data dictionary, equipment and medium

Abstract

The invention provides a business state change method and device based on a data dictionary, equipment and a medium. The method comprises the following steps: creating a data dictionary for business state management; creating a business process based on the workflow tool, loading a data dictionary for nodes in the business process, configuring a corresponding business type, a state parameter and a service identifier for each node by using the data dictionary, and defining a change rule of a business state; in a workflow operation process, dynamically identifying a back-end service identifier according to the service identifier of each node, and analyzing the state parameter of the current service node and the corresponding change rule by using the data dictionary; and sending a state change request to the back-end service according to the back-end service identifier, and transmitting the analyzed state parameter to the back-end service, so that the back-end service executes a corresponding state updating operation according to the analyzed state parameter. The development cycle can be shortened, the development and maintenance cost can be reduced, and the adaptability and flexibility of the system can be improved.

Description

Technical Field

[0001] The present application relates to the field of industrial software technology, and in particular to a method, device, equipment and medium for changing business status based on a data dictionary. Background Art

[0002] In industrial software, the status management and change of production elements is one of the core functions, such as material status, product status, and production status. In traditional software design, status changes usually rely on custom-developed code implementation based on specific business needs. When business status requirements change or new states are added, secondary development or expansion of existing code is required to support actual business needs. This approach has a long development cycle, complex test logic, and poor code versatility, making it difficult to adapt to dynamically changing business needs.

[0003] In the prior art, in order to solve the problem of business status change, the interface is usually developed directly in the business core code. For example, the change of material status may involve multiple states such as "application → draft → creation → approval → release → application", and corresponding business code needs to be developed for each state change logic. Although this method can achieve state management, the code is highly coupled, resulting in high system development and maintenance costs and poor scalability.

[0004] In addition, some technical solutions attempt to introduce workflow tools to assist in state management, but existing solutions often require developers to have professional knowledge to have an in-depth understanding of workflow tools and configuration functions. At the same time, complex state change rules still need to be manually configured, which makes it difficult to meet the needs of rapid response and low-cost expansion. Summary of the invention

[0005] In view of this, the embodiments of the present application provide a business status change method, device, equipment and medium based on a data dictionary to solve the problems of long development cycle, poor versatility, high maintenance and expansion costs and complex configuration process in the prior art.

[0006] According to a first aspect of an embodiment of the present application, a method for changing a business status based on a data dictionary is provided, comprising: creating a data dictionary for business status management, wherein the data dictionary includes business types, status parameters and service identifiers; creating a business process based on a workflow tool, loading a data dictionary for nodes in the business process, configuring corresponding business types, status parameters and service identifiers for each node using the data dictionary, and defining business status change rules; during the operation of the workflow, dynamically identifying a backend service identifier based on the service identifier of each node, and parsing the status parameters and corresponding change rules of the current business node using the data dictionary; sending a status change request to the backend service based on the backend service identifier, and passing the parsed status parameters to the backend service, so that the backend service performs the corresponding status update operation based on the parsed status parameters.

[0007] According to a second aspect of an embodiment of the present application, a data dictionary-based business status change device is provided, comprising: a creation module, configured to create a data dictionary for business status management, wherein the data dictionary includes business types, status parameters and service identifiers; a configuration module, configured to create a business process based on a workflow tool, load a data dictionary for nodes in the business process, use the data dictionary to configure the corresponding business type, status parameters and service identifiers for each node, and define business status change rules; a parsing module, configured to dynamically identify a backend service identifier according to the service identifier of each node during the operation of the workflow, and use the data dictionary to parse the status parameters and corresponding change rules of the current business node; an update module, configured to send a status change request to the backend service according to the backend service identifier, and pass the parsed status parameters to the backend service, so that the backend service performs the corresponding status update operation according to the parsed status parameters.

[0008] According to a third aspect of an embodiment of the present application, an electronic device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the steps of the above method are implemented when the processor executes the computer program.

[0009] According to a fourth aspect of an embodiment of the present application, a computer-readable storage medium is provided, which stores a computer program, and when the computer program is executed by a processor, the steps of the above method are implemented.

[0010] At least one of the above technical solutions adopted in the embodiments of the present application can achieve the following beneficial effects:

[0011] By creating a data dictionary for business status management, where the data dictionary includes business type, status parameters and service identification; creating a business process based on a workflow tool, loading the data dictionary for the nodes in the business process, using the data dictionary to configure the corresponding business type, status parameters and service identification for each node, and defining the business status change rules; during the workflow operation, dynamically identify the backend service identification according to the service identification of each node, and use the data dictionary to parse the status parameters and corresponding change rules of the current business node; according to the backend service identification, send a status change request to the backend service, and pass the parsed status parameters to the backend service, so that the backend service performs the corresponding status update operation according to the parsed status parameters. This application can reduce the development cycle, reduce development and maintenance costs, and improve the adaptability and flexibility of the system. BRIEF DESCRIPTION OF THE DRAWINGS

[0012] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0013] Figure 1 It is a flowchart of a method for changing a business status based on a data dictionary provided in an embodiment of the present application;

[0014] Figure 2 It is a structural diagram of a service status changing device based on a data dictionary provided in an embodiment of the present application;

[0015] Figure 3 It is a schematic diagram of the structure of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0016] In the following description, specific details such as specific system structures, technologies, etc. are provided for the purpose of illustration rather than limitation, so as to provide a thorough understanding of the embodiments of the present application. However, it should be clear to those skilled in the art that the present application may also be implemented in other embodiments without these specific details. In other cases, detailed descriptions of well-known systems, devices, circuits, and methods are omitted to prevent unnecessary details from obstructing the description of the present application.

[0017] In the field of industrial software, managing and changing production elements (such as the status of materials, products or production) is a core requirement for achieving efficient production operations. Usually, the status of production elements will undergo multiple changes in the business process. For example, materials may gradually transition from the "application" status to the "release" or "application" status. The management of these statuses requires clear logical rules and efficient technical implementation methods.

[0018] In order to manage and change these states, the traditional software development model tends to write custom code based on specific business needs. In other words, whenever a new requirement emerges, such as adding a new state or adjusting the logic of state change, secondary development is usually required in the existing software. This method not only takes a long time, but may also increase code complexity and affect system stability due to frequent changes.

[0019] The most commonly used technical solution is to develop interfaces directly in the core business code to implement state management and changes. The existing technology works in such a way that for each business requirement (such as material state change), the development team needs to manually write code to implement the state logic processing. For example, the state change of a material may include multiple stages, such as "apply → draft → create → approve → publish → apply". The state transfer of each stage requires the support of the corresponding business logic code.

[0020] This method relies on the direct development of the core software code. Every time a new state is added or the state logic is adjusted, the code needs to be re-modified and fully tested. The state logic is highly coupled and has poor versatility. Although the existing technical methods can meet the business needs of specific scenarios, they still have the following obvious disadvantages:

[0021] 1. Long development cycle: Because customized development is required for each specific demand, it involves multiple links such as demand analysis, design, coding and testing.

[0022] 2. Poor versatility: The state logic is embedded in the core code and cannot be directly reused in other similar scenarios, which lacks flexibility.

[0023] 3. Complex maintenance: Due to the complex logic and high degree of customization, the maintenance cost is high, and any slight change may cause chain problems.

[0024] 4. High expansion cost: New requirements require secondary development and testing, which increases expansion costs.

[0025] Therefore, the main problems of the existing technical solutions are: First, although workflow tools are introduced in some cases, developers are still required to have certain professional knowledge to configure the process and functions of state changes. Second, the current solution responds slowly to the expansion needs of business states and does not support fast and flexible adaptation to different business scenarios. Finally, every time a new state is added or the logic is changed, the code needs to be redeveloped, which consumes a lot of manpower and time.

[0026] In view of the problems existing in the prior art, this application proposes a new method for updating business status through workflow approval. By supporting business customization of business status and triggering status changes through process approval, it supports changes in business status through configuration, thereby improving the flexibility and adaptability of business status expansion and reducing the secondary development cost of business expansion.

[0027] The technical solution of this application is based on the workflow tool (flowable+bpmnjs+vue) and the dictionary configuration function of the platform, and uses the front-end vue language and the back-end java language as the software development language to develop a workflow state configuration tool. By providing a set of general business state processing solutions, the business state configuration is managed by the data dictionary configuration, and the state change is combined with the workflow tool. Thereby, the change and expansion of the business state can be made more flexible, and at the same time, the process management control method is adopted, and through a richer process design, more complex and flexible state changes can be made during the operation of the workflow tool, for example: different processes are controlled to run according to different process parameters to change different states. The workflow changes the business state by means of task callbacks, so that the business party can only focus on the functional expansion of different business states without having to pay attention to the change logic, decoupling the two, and greatly improving the compatibility and scalability of the system.

[0028] This application uses the following technical frameworks and tools to build a flexible and efficient business status management solution:

[0029] Workflow engine: Use Flowable as the workflow engine to provide scalable process management capabilities for defining and executing business processes.

[0030] Workflow design tool: Integrate BPMNJS to support graphical workflow design and build business process logic in the form of intuitive flowcharts.

[0031] Front-end framework: Vue.js is used to implement the front-end interface, providing a user interaction interface for data dictionary configuration and workflow design, and supporting dynamic loading and real-time configuration.

[0032] Backend framework: Use Java to implement the backend service logic, including the management of data dictionaries, parsing of state change rules, and implementation of service callbacks.

[0033] The core idea of ​​the technical solution of this application is to separate the management logic of the business status from the core business code, and to achieve the decoupling of state changes through workflow tools and data dictionary configuration. The data dictionary is used to support dynamic business status extension, business type extension and interface binding. Through the identification of configuration content during the workflow operation phase, the process control of state changes is achieved, and the state update is completed in combination with service callbacks.

[0034] The contents of the technical solution of the present application are described in detail below in conjunction with the accompanying drawings and specific embodiments.

[0035] Figure 1 Schematic diagram of the process of changing the service status based on the data dictionary provided in the embodiment of the present application. Figure 1 As shown, the data dictionary-based service status change method may specifically include:

[0036] S101, creating a data dictionary for service status management, wherein the data dictionary includes service type, status parameter and service identifier;

[0037] S102, creating a business process based on a workflow tool, loading a data dictionary for nodes in the business process, configuring a corresponding business type, state parameter and service identifier for each node using the data dictionary, and defining a change rule for the business state;

[0038] S103, during the workflow operation, dynamically identifying the backend service identifier according to the service identifier of each node, and parsing the state parameters of the current business node and the corresponding change rules using the data dictionary;

[0039] S104, sending a state change request to the backend service according to the backend service identifier, and passing the parsed state parameters to the backend service, so that the backend service performs a corresponding state update operation according to the parsed state parameters.

[0040] In some embodiments, creating a data dictionary for business status management includes:

[0041] Define the structure of the data dictionary, where the business type in the data dictionary is used to classify and identify different business processes, the state parameter is used to define the state and change rules of each node in the business process, and the service identifier is used to identify the backend service;

[0042] The data dictionary is stored in the platform configuration module so that the data dictionary can be dynamically loaded during the workflow operation.

[0043] Specifically, in the platform configuration module, the structure of the data dictionary is defined, which may include the following fields, for example:

[0044] Business Type: used to identify different business process categories. For example, the business type corresponding to "File Review Process" is QMS_FILE_WORK_FLOW_MANGEMENT.

[0045] Status parameter: used to describe the status and value of each node in the business process. For example, the status in the file review process can include:

[0046] QFAAS0001: Not submitted;

[0047] QFAAS0002: Under review;

[0048] QFAAS0004: Approved;

[0049] QFAAS0005: Revoked.

[0050] Service ID: used to locate the backend service instance to support dynamic service calls when the state changes. For example, the service ID is configured as hollycon-mes-biz-back-end, which is used to represent the backend service related to the document review process.

[0051] Through the above field definitions, the data dictionary can fully describe the state management requirements in the business process and dynamically associate with the back-end services.

[0052] Furthermore, the defined data dictionary is stored in the configuration module of the platform, so that it has the following functions: supporting centralized management of business status, business type and service identification; being able to dynamically load the configuration content of the data dictionary during the workflow running phase to avoid repeated development and configuration; providing extensibility, allowing users to dynamically modify or add data dictionary content through the front-end interface.

[0053] The following takes the file review process as an example to explain the specific configuration of the data dictionary. For example, the following is the specific configuration content of the data dictionary in the file review process:

[0054] Service ID: hollycon-mes-biz-back-end, used to locate the backend service responsible for document review.

[0055] Dictionary name: QMS_FILE_WORK_FLOW_MANGEMENT, which indicates the business type dictionary related to the file review process.

[0056] Dictionary item parameters:

[0057] QFAAS0001: Not submitted;

[0058] QFAAS0002: Under review;

[0059] QFAAS0004: Approved;

[0060] QFAAS0005: Revoked.

[0061] Through the above configuration and dynamically loaded data dictionary, this embodiment can add or adjust business process status and type without modifying the core code. For example, to add status QFAAS0006 (archived), it only needs to update the data dictionary. The dynamic loading capability of the data dictionary enables workflow tools to identify and apply configuration content in real time, reducing development time. Separating business status management from workflow tools and dynamically calling backend services through service identifiers improves the adaptability and scalability of the system.

[0062] In some embodiments, creating a business process based on a workflow tool and loading a data dictionary for a node in the business process include:

[0063] Create business processes based on workflow tools and define the flow relationships between nodes in the business process; load data dictionaries for each node in the business process and configure the corresponding business type, status parameters and service identifiers for each node according to business needs;

[0064] Among them, the business type is used to associate the business logic of the current business node, the state parameter is used to define the target state and change rules of the current business node, and the service identifier is used to bind the current business node and the backend service to support dynamic service calls.

[0065] Specifically, workflow tools (such as BPMNJS) are used to design business processes, create and define the flow relationship between nodes. Taking the document review process as an example, the process includes multiple nodes, such as "document submission", "department review", "quality review", and "document release".

[0066] The sequential transition of states is represented by the flow relationship between each node. For example, after "document submission" is completed, it enters "department review", and after "department review" is passed, it enters "quality review".

[0067] Each node has clear inflow and outflow conditions. For example, when the file status is "Not Submitted", it flows into the "Department Review" node; when the file status is "Under Approval", it flows into the "Quality Review" node.

[0068] The overall description of the process includes: the process starts at the "File Submission" node and ends at the "File Release" node. After the process design is completed, the process model is saved and published through the graphical interface of the workflow tool.

[0069] Furthermore, a data dictionary is loaded for each business node, and the following functions are implemented through configuration:

[0070] 1) Association of business types:

[0071] According to the business type defined in the data dictionary, a specific business logic module is bound to the node. For example, the "File Review Process" defines the processing rules of the review node, including approval logic and status change rules.

[0072] 2) Definition of state parameters:

[0073] Load the state parameters corresponding to the node from the data dictionary to specify the target state and change conditions of the node. For example, if the state parameter of the "Department Review" node is configured as "Approving", it means that after the node is executed, the state will be changed to "Approving".

[0074] 3) Binding of service identifier:

[0075] Use the service identifier defined in the data dictionary to bind the current node to the backend service. For example, the service identifier hollycon-mes-biz-back-end points to the backend service instance responsible for file review and supports dynamic interface calls.

[0076] The following takes the "Department Review" and "Quality Review" nodes in the file review process as an example to illustrate the specific implementation process of data dictionary loading and node configuration. The specific contents are as follows:

[0077] 1. Department review nodes:

[0078] Business type: Document review flow business (QMS_FILE_WORK_FLOW_MANGEMENT). Status parameter: Under review (QFAAS0002). Service identifier: hollycon-mes-biz-back-end.

[0079] 2. Configuration process:

[0080] Use the BPMNJS tool to select the "Department Review" node; load the business type "Document Review Process Business" from the data dictionary; configure the status parameter to "Under Approval" and bind the service identifier "holly con-mes-biz-back-end"; save the node configuration.

[0081] 3. Quality audit nodes:

[0082] Business type: Document review flow business (QMS_FILE_WORK_FLOW_MANGEMENT). Status parameter: Approved (QFAAS0004). Service ID: hollycon-mes-biz-back-end.

[0083] 4. Configuration process:

[0084] Use the BPMNJS tool to select the "Quality Review" node; load the data dictionary and configure the business type to "Document Review Process Business"; set the status parameter to "Approved" and bind the service identifier "hollycon-mes-biz-back-end"; save the configuration.

[0085] Furthermore, in the implementation of business type association, the node is associated with a specific business logic module by loading the business type of the data dictionary. For example, in the "Department Review" node, the business type "Document Review Process Business" loads the approval rule module, allowing the system to automatically identify and execute the processing logic related to document review.

[0086] The status parameter is used to indicate the target status of the node, which serves as the basis for the process flow. For example, when the status parameter of the "Department Review" node is configured as "Under Approval", the workflow tool will update the file status to "Under Approval" after the node is executed.

[0087] The service identifier is bound to the node through the data dictionary to realize dynamic service call. For example, in the "Quality Review" node, the service identifier hollycon-mes-biz-back-end points to the back-end interface, which receives the state change request and completes the state update.

[0088] Through the above implementation method, the business logic, state parameters and service binding of each node in this embodiment are dynamically loaded and configured through the data dictionary without hard coding. By updating the data dictionary, node state parameters and change rules can be quickly added or adjusted. The dynamic binding of service identifiers decouples nodes from backend services and adapts to the deployment requirements of distributed systems. The workflow tool combined with the application of the data dictionary provides a unified process state change control and realizes efficient business process management.

[0089] In some embodiments, defining a change rule for a business status includes:

[0090] Based on the data dictionary, the input state parameters of each node are loaded from the business process. The input state parameters are used to identify the initial state of the node in the business process.

[0091] Define a state change condition for each node, and based on the state change condition, configure an output state parameter for each node. The output state parameter is used to identify the result state after the node state changes.

[0092] Storing input state parameters, state change conditions, and output state parameters in a rule module of a workflow tool;

[0093] When the workflow is running, the change rules are dynamically loaded to parse the input state parameters of the node, verify whether the state change conditions are met, and generate the corresponding output state parameters according to the state change conditions.

[0094] Specifically, the input status parameter indicates the initial status of a node in the business process and is the starting condition for the status change. The corresponding input status parameter is loaded for each node through the data dictionary. For example, the node "File Submission" corresponds to the input status parameter QFAAS0001 (unsubmitted); the node "Department Review" corresponds to the input status parameter QFAAS0002 (under review).

[0095] Furthermore, a workflow tool (such as BPMNJS) is used to load a data dictionary for a business process node; according to the business process design, input state parameters of the node are defined and configured in the data dictionary; and the configuration is saved in a rule module of the workflow tool for dynamic loading at runtime.

[0096] Furthermore, this embodiment also defines how the input status triggers changes, and what conditions must be met to transfer to the next state; for example, the node "Department Review" may have the following status change conditions: if the input status is "under review" and the approval result is "passed", the status changes to "approved".

[0097] In some examples, the configuration of the change condition is as follows:

[0098] Input status parameter: the initial status of the current node, for example, QFAAS0002 (under review).

[0099] Trigger conditions: additional conditions based on business logic, such as user actions, external events, or automatic processes;

[0100] Change logic: defines the rules for outputting status after the trigger conditions are met, such as "approved" or "rejected".

[0101] For example, in a specific configuration example, the following status change conditions are set for the node "department review":

[0102] Input status parameters: QFAAS0002 (under review);

[0103] Trigger condition: the approval result is "passed";

[0104] Output status parameter: QFAAS0004 (approved).

[0105] Furthermore, the output status parameter indicates the result status after the business process node is executed, which is the basis for the status transfer. For example, the output status parameter of the node "department review" can be QFAAS0004 (approved) or QFAAS0005 (rejected).

[0106] In the workflow tool, set the corresponding output status parameters for each node according to the business logic; the output status parameters must be consistent with the subsequent flow conditions of the node. For example, QFAAS0004 corresponds to entering the "Quality Audit" node, and QFAAS0005 corresponds to ending the process.

[0107] Furthermore, the input status parameters, change conditions and output status parameters are combined into a complete status change rule; for example, the rule definition of the node "department review" is: input status parameter: QFAAS0002 (under review); change condition: the approval result is "passed"; output status parameter: QFAAS0004 (approved).

[0108] The rules are stored in the rule module of the workflow tool for dynamic loading and parsing at runtime.

[0109] Furthermore, when the workflow is running, the system dynamically loads the change rules in the rule module; according to the configuration of the current node, the input state parameters are parsed and whether the change conditions are met are verified.

[0110] Furthermore, the system determines whether the state change condition is met based on the analysis result: if the condition is met, the corresponding output state parameter is generated; if the condition is not met, the current state is maintained or other logic is executed.

[0111] For example, in some examples, at the node "department review", if the approval result is "passed", the system analysis rule generates an output status parameter QFAAS0004 (approved) and flows to the next node "quality review".

[0112] Through the above method of this embodiment, this embodiment can support the adjustment and expansion of business needs by dynamically loading data dictionaries and change rules without hard coding. Change rules are centrally stored in the rule module, which is convenient for unified management and maintenance. Through the organic combination of input status, change conditions and output status, refined control of state changes in business processes is achieved.

[0113] In some embodiments, the state parameters of the current service node and the corresponding change rules are parsed using a data dictionary, including:

[0114] According to the status parameters and change rules of the current business node, the change conditions and target status applicable to the current business node are parsed;

[0115] Parse the service identifier of the current business node, dynamically match the backend service associated with the current business node, and determine the service interface and communication address of the backend service;

[0116] A state change instruction is generated based on the parsing result, and the state change instruction is used to drive the backend service to perform the corresponding state update operation.

[0117] Specifically, when the current business node is running, the system loads the node status parameters from the data dictionary, for example, the status parameter QFAAS0002 (under approval) indicates that the current node is in the "under approval" state.

[0118] The system matches the change rules defined in the data dictionary based on the node's status parameters and parses out the status change conditions applicable to the current node. For example:

[0119] Input status parameters: QFAAS0002 (under review);

[0120] Change conditions: Approval result is "approved";

[0121] Output target status: QFAAS0004 (approved).

[0122] Furthermore, the system verifies whether the current node meets the state change conditions. For example, check whether the approval result submitted by the user is "passed". If the conditions are met, continue to parse the target state; otherwise, keep the current state or trigger the exception handling logic.

[0123] Furthermore, the service identifier of the current business node is loaded from the data dictionary, for example: hollycon-mes-biz-back-end. The service identifier is used to locate the backend service associated with the node to ensure accurate identification of the service instance in the distributed system.

[0124] Furthermore, based on the service identifier, the system queries the platform service registration module or configuration module to obtain the communication address and interface information of the backend service, such as the service name, service address and interface name. The system dynamically parses this information for subsequent state change instruction generation and service call.

[0125] Furthermore, based on the parsed status parameters, change rules and service information, the system generates a status change instruction, which may include status parameters, change conditions and service interfaces and addresses. Status parameters: input status and target status, for example, the input status is QFAAS0002 (under review); the target status is QFAAS0004 (approved). Change conditions: For example, the approval result must be "approved".

[0126] Furthermore, the system parses the change logic of the node through the rule engine, and combines the input state, condition verification result and target state to generate a complete instruction. The instruction is used to drive the backend service to execute the state update, ensuring that the state change operation of the business process is executed according to the rules.

[0127] For example, in some examples, the state change parsing process of the department review node is as follows:

[0128] The system dynamically loads the status parameter QFAAS0002 and change rules configured in the data dictionary; verifies that the approval result is "passed" and meets the change conditions; dynamically matches the backend service, parses the service address and interface; generates a status change instruction and sends it to the backend service; the backend service receives the instruction and updates the status to QFAAS0004 (approved).

[0129] Through the above method of this embodiment, the system can dynamically load state parameters and rules according to the node configuration to adapt to the needs of different business scenarios. Service identification resolution combined with the service registration mechanism ensures accurate service positioning in a multi-instance environment. The instruction generation and verification process strictly follows the rules to ensure the accuracy and consistency of business status changes.

[0130] In some embodiments, according to the backend service identifier, a state change request is sent to the backend service, and the parsed state parameters are passed to the backend service, including:

[0131] Determine the service interface of the backend service according to the backend service identifier, call the service interface, and send a state change request to the backend service. The state change request includes the parsed state parameters and related business information corresponding to the current business node; use the workflow tool to send the parsed state parameters to the backend service in the form of task callback, so that the backend service triggers the corresponding business logic according to the parsed state parameters.

[0132] Specifically, when the workflow is running, the system loads the backend service identifier of the current business node from the data dictionary. For example, the service identifier is hollycon-mes-biz-back-end, which is used to locate the backend service instance responsible for the business logic of the current node.

[0133] The system queries the service registration center or configuration module through the service identifier and parses the specific interface information of the backend service, including the communication address and method.

[0134] Combined with the extended fields in the data dictionary (such as QMS_FILE_APPLY_AUDIT_STATUS), dynamically match the interface parameters and calling rules of the current business status to ensure that the status change request complies with the specific business logic.

[0135] Furthermore, the state change request generated by the system may include the following:

[0136] Status parameters of the current node, for example: QFAAS0002 (under review);

[0137] Target status parameters, for example: QFAAS0004 (approved);

[0138] Business information, such as file number, user operation time, approval result, etc.

[0139] Furthermore, the system sends a status change request to the backend service through HTTP request according to the parsed service interface. For example, in the node "department review", a status change request is sent to the backend service, including the current status QFAAS0002 and the target status QFAAS0004, and the business information includes the file number and approval result.

[0140] Furthermore, after receiving the status change request, the backend service triggers the corresponding business logic according to the status parameters and business information. For example, if the current status is QFAAS0002 and the approval result is "passed", the backend service updates the file status to QFAAS0004 (approved).

[0141] Furthermore, after the task node is executed, the workflow tool passes the status parameters and business information of the current node to the backend service through the task callback mechanism. Task callback ensures the decoupling between the business process and the backend service logic, and supports dynamic service positioning.

[0142] Furthermore, the callback content includes the current node's state parameters, target state parameters, backend service identifier, and business information. For example:

[0143] Current status: QFAAS0002;

[0144] Target status: QFAAS0004;

[0145] Service logo: hollycon-mes-biz-back-end;

[0146] Business information: File number FILE12345, approver John Doe.

[0147] Furthermore, in the node "Quality Review", the task callback passes the status parameters to the backend service, and the backend service executes the following logic according to the callback content: verify the current status and approval conditions; update the file status to QFAAS0004 (approved); record the status change log.

[0148] For example, in some examples, taking the status update of the department review node as an example, the current node is "department review", and the file status is updated from QFAAS0001 (unsubmitted) to QFAAS0002 (under review).

[0149] First, the workflow tool loads the service identifier hollycon-mes-biz-back-end and status parameters from the data dictionary; then, it determines the backend service interface address and generates a status change request, which may include: current status, target status, and business information. Finally, the system passes the status parameters and business information to the backend service through task callback; after receiving the request, the backend service updates the file status to QFAAS0002 (under review).

[0150] It should be noted that in a multi-instance deployment scenario, the workflow tool dynamically resolves the IP and port of the service instance through the service identifier, for example, dynamically resolving from hollycon-mes-biz-back-end to the service address. The system sends requests to available service instances through the task callback mechanism and supports retry logic to ensure high reliability of state changes.

[0151] Through the method of the present embodiment described above, the state parameter transmission and state update operation are automatically completed through task callback and dynamic binding. The dynamic service positioning mechanism supports flexible expansion in a distributed deployment environment. Task callback decouples the business process from the backend service logic, improving the modularity and maintainability of the system.

[0152] In some embodiments, after the backend service performs a corresponding status update operation according to the parsed status parameter, the method further includes:

[0153] The status change information of each node is recorded in the workflow tool. The status change information includes business type, status parameters and timestamp. The status change information is used to trace the status change of the node throughout the entire process. The status change results of the node are fed back to the workflow tool so that the business logic of subsequent nodes can be processed using the status change results.

[0154] Specifically, the status change information is used to record the status change of each node in the business process, which may include the following:

[0155] Business Type: Identifies the current business process category, such as "Document Review Process".

[0156] Status parameters: record the input status and output status of the node, for example, QFAAS0002 (under review) is changed to QFAAS0004 (approved).

[0157] Timestamp: records the specific time when the status change occurs, which is used to trace the business process.

[0158] Furthermore, after the backend service completes the status update operation according to the parsed status parameters, it transmits the change information back to the workflow tool; the workflow tool stores the information in a log module or a database to form a complete status change record.

[0159] Furthermore, in complex business processes, the state changes of each node need to be clearly recorded in order to quickly locate the problem node, analyze the historical trajectory of state changes, and provide audit and compliance support. The workflow tool combines the stored state change information with timestamps and node relationships to reproduce the state change path of the entire business process;

[0160] Furthermore, when a node fails to update its status, the cause of the problem can be quickly located by tracing back to the status change records of the previous nodes; when optimizing business processes, the efficiency and bottlenecks of the process can be evaluated by analyzing the status change path.

[0161] Furthermore, after the backend service completes the status update, it feeds back the status change result to the workflow tool, including:

[0162] Change status: success or failure;

[0163] Updated status parameters: for example, QFAAS0004 (approved);

[0164] Additional information: such as failure reason or business processing notes.

[0165] Furthermore, the backend service transmits the status change result back to the workflow tool through the interface; after receiving the feedback result, the workflow tool updates the status of the node according to the result and triggers subsequent business logic.

[0166] Furthermore, the workflow tool determines whether to execute subsequent nodes and the specific logic of execution based on the status change result of the current node. For example, if the status change is successful, the next node is executed; if the status change fails, the exception handling logic is triggered.

[0167] Furthermore, the workflow tool parses the feedback status parameters and processes subsequent nodes according to the configuration rules: if the status is QFAAS0004 (approval passed), it will flow to the node "document release"; if the status is QFAAS0005 (approval rejected), it will flow to the end node or re-enter the "department review".

[0168] For example, in some examples, in the document review process, after the "Quality Review" is completed, the status is QFAAS0004, which triggers the subsequent node "Document Release" and updates the document status to QFAAS0006 (released).

[0169] Through the above method of this embodiment, this embodiment comprehensively records the state change information of the node, including business type, state parameters and timestamp, to support subsequent auditing and problem location. After the back-end service completes the state update, the feedback mechanism is used to ensure that the workflow tool obtains the update results in a timely manner to ensure the continuity of the business process. Through the state change results, the workflow tool can dynamically adjust the logic of subsequent nodes to improve the flexibility and stability of the business process.

[0170] The following will combine the document review process in actual application scenarios to explain in detail how to achieve the status change of the "department review" and "quality review" links in the document review process through business configuration and data dictionary expansion based on the technical solution of this application, as well as how to use workflow tools to dynamically identify services and complete status updates.

[0171] 1. Business scenario description

[0172] In the document review process, the documents need to be reviewed and processed in multiple stages. The main processes include:

[0173] Department review: After passing the department review, the document status must be changed from "Not Submitted" to "Under Review".

[0174] Quality review: After the quality review is passed, the document status must be changed from "under review" to "approved".

[0175] Each audit node needs to be configured with status parameters, service identifiers, and business types according to business requirements so that the workflow tool can dynamically identify the configuration content and complete the status update operation at runtime.

[0176] 2. Department review node configuration

[0177] In the business configuration interface of the Department Approval node, select the business type as File Approval Flow Business (QMS_FILE_WORK_FLOW_MANGEMENT); configure the node status parameter to Under Approval (QFAAS0002).

[0178] In the "Business Configuration" module, the user selects the business type and status parameters through the drop-down menu, and clicks the "OK" button to complete the configuration.

[0179] The system loads the service identifier through the data dictionary and binds it to the "hollycon-mes-biz-back-end" service; the service identifier is used to locate the backend service responsible for processing state changes.

[0180] After the configuration is completed, the workflow tool stores the node's business configuration, status parameters, and service identification into the rule module for dynamic loading during process runtime.

[0181] 3. Configuration of quality audit nodes

[0182] In the business configuration interface of the "Quality Audit" node, select the business type as "File Audit Flow Business" (QMS_FILE_WORK_FLOW_MANGEMENT); configure the status parameter of the node to "Approved" (QFAAS0004).

[0183] In the "Business Configuration" module, users complete the binding operation of business type and status parameters through the interface.

[0184] The system loads the service ID through the data dictionary and binds to the "hollycon-mes-biz-back-end" service.

[0185] After the configuration is completed, the workflow tool stores the node's business configuration, status parameters, and service identification into the rule module for dynamic loading during process runtime.

[0186] 4. Data dictionary expansion and business configuration

[0187] To support the file review process, the following content needs to be extended in the default HSM_WORK_FLOW_APP data dictionary:

[0188] Service Identifier: Extends the QMS_FILE_WORK_FLOW_APP dictionary to identify the service list;

[0189] Status dictionary: Extends the QMS_FILE_WORK_FLOW_MANGEMENT dictionary to identify business status parameters.

[0190] Further, the specific extended configuration, the configured application list may include the following:

[0191] Service ID: hollycon-mes-biz-back-end, used to locate the backend service;

[0192] Business dictionary name: QMS_FILE_WORK_FLOW_MANGEMENT, used to identify file review related businesses;

[0193] Status dictionary parameters:

[0194] QFAAS0001 → Not submitted;

[0195] QFAAS0002 → Under review;

[0196] QFAAS0004→Approved;

[0197] QFAAS0005 → Revoked.

[0198] The system binds the status dictionary through the extended field "QMS_FILE_APPLY_AUDIT_STATUS" to dynamically load business status parameters.

[0199] 5. Operation and service callback of workflow tools

[0200] When the workflow is running, the tool dynamically loads the configured business type, status parameters and service identification; based on the configuration content of the current node, the data dictionary is called to parse the service identification and interface information.

[0201] The workflow tool dynamically identifies the IP and port of the backend service based on the configured service identifier, for example, it parses the address corresponding to the hollycon-mes-biz-back-end service; the tool generates a state change request, which includes the current state parameters, target state parameters and business information (such as file number and approver information); and sends the request to the backend service via HTTP POST to trigger the state update logic.

[0202] After receiving the callback request, the backend service performs a status update operation based on the parsed status parameters: after the department review is completed, the file status is updated from "Unsubmitted" (QFAAS0001) to "Under Approval" (QFAAS0002); after the quality review is completed, the file status is updated from "Under Approval" (QFAAS0002) to "Approved" (QFAAS0004).

[0203] 6. Full process traceability and status feedback

[0204] After each node is executed, the workflow tool records the status change information, for example, it may include node name, business type, input status, output status, timestamp, etc.; these records are stored in the log module for subsequent audit and traceability analysis.

[0205] After the backend service completes the status update, it will feed back the status change result (such as success or failure) to the workflow tool; the tool determines the flow logic of subsequent nodes based on the feedback result. For example, if the department review status is "under approval", it will flow to "quality review"; if the status update fails, the exception handling logic will be triggered.

[0206] The following is an embodiment of the device of the present application, which can be used to execute the embodiment of the method of the present application. For details not disclosed in the embodiment of the device of the present application, please refer to the embodiment of the method of the present application.

[0207] Figure 2 Schematic diagram of the structure of the service status change device based on the data dictionary provided in the embodiment of the present application. Figure 2 As shown, the service status changing device based on the data dictionary includes:

[0208] A creation module 201 is configured to create a data dictionary for service status management, wherein the data dictionary includes service type, status parameter and service identifier;

[0209] Configuration module 202, configured to create a business process based on a workflow tool, load a data dictionary for nodes in the business process, configure a corresponding business type, state parameter and service identifier for each node using the data dictionary, and define a change rule for the business state;

[0210] The parsing module 203 is configured to dynamically identify the backend service identifier according to the service identifier of each node during the workflow operation, and parse the state parameters of the current business node and the corresponding change rules using the data dictionary;

[0211] The updating module 204 is configured to send a state change request to the backend service according to the backend service identifier, and pass the parsed state parameters to the backend service, so that the backend service performs a corresponding state update operation according to the parsed state parameters.

[0212] In some embodiments, Figure 2 The creation module 201 defines the structure of the data dictionary, wherein the business type in the data dictionary is used to classify and identify different business processes, the state parameter is used to define the state and change rules of each node in the business process, and the service identifier is used to identify the backend service; the data dictionary is stored in the platform configuration module so that the data dictionary can be dynamically loaded during the workflow operation.

[0213] In some embodiments, Figure 2 The configuration module 202 creates a business process based on a workflow tool and defines the flow relationship between each node in the business process; loads a data dictionary for each node in the business process, and configures the corresponding business type, state parameters and service identifier for each node according to business needs; wherein, the business type is used to associate the business logic of the current business node, the state parameters are used to define the target state and change rules of the current business node, and the service identifier is used to bind the current business node to the backend service to support dynamic service calls.

[0214] In some embodiments, Figure 2The configuration module 202 is based on the data dictionary and loads the input state parameters of each node from the business process, the input state parameters are used to identify the initial state of the node in the business process; defines the state change condition for each node, and configures the output state parameter for each node based on the state change condition, the output state parameter is used to identify the result state after the node state is changed; stores the input state parameters, state change conditions and output state parameters in the rule module of the workflow tool; when the workflow is running, dynamically loads the change rules to parse the input state parameters of the node, verify whether the state change conditions are met, and generate corresponding output state parameters according to the state change conditions.

[0215] In some embodiments, Figure 2 The parsing module 203 parses the change conditions and target states applicable to the current business node according to the state parameters and change rules of the current business node; parses the service identifier of the current business node, dynamically matches the backend service associated with the current business node, and determines the service interface and communication address of the backend service; generates a state change instruction based on the parsing result, and the state change instruction is used to drive the backend service to perform the corresponding state update operation.

[0216] In some embodiments, Figure 2 The update module 204 determines the service interface of the backend service according to the backend service identifier, calls the service interface, and sends a state change request to the backend service. The state change request includes the parsed state parameters and related business information corresponding to the current business node; the workflow tool is used to send the parsed state parameters to the backend service in the form of task callback, so that the backend service triggers the corresponding business logic according to the parsed state parameters.

[0217] In some embodiments, Figure 2 After the backend service performs the corresponding status update operation according to the parsed status parameters, the update module 204 records the status change information of each node in the workflow tool. The status change information includes the business type, status parameters and timestamp. The status change information is used to trace the entire process of the node status change; the node status change result is fed back to the workflow tool so that the business logic of subsequent nodes can be processed using the status change result.

[0218] It should be understood that the size of the serial numbers of the steps in the above embodiments does not mean the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present application.

[0219] Figure 3 Schematic diagram of an electronic device 3 provided in an embodiment of the present application. Figure 3As shown, the electronic device 3 of this embodiment includes: a processor 301, a memory 302, and a computer program 303 stored in the memory 302 and executable on the processor 301. When the processor 301 executes the computer program 303, the steps in the above-mentioned method embodiments are implemented. Alternatively, when the processor 301 executes the computer program 303, the functions of the modules / units in the above-mentioned device embodiments are implemented.

[0220] The electronic device 3 may be a desktop computer, a notebook, a PDA, a cloud server, or other electronic device. The electronic device 3 may include, but is not limited to, a processor 301 and a memory 302. Those skilled in the art will appreciate that Figure 3 The electronic device 3 is merely an example and does not limit the electronic device 3 , and may include more or less components than those shown in the figure, or different components.

[0221] The processor 301 may be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), field-programmable gate arrays (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc.

[0222] The memory 302 may be an internal storage unit of the electronic device 3, for example, a hard disk or memory of the electronic device 3. The memory 302 may also be an external storage device of the electronic device 3, for example, a plug-in hard disk, a smart media card (SMC), a secure digital (SD) card, a flash card, etc. equipped on the electronic device 3. The memory 302 may also include both an internal storage unit of the electronic device 3 and an external storage device. The memory 302 is used to store computer programs and other programs and data required by the electronic device.

[0223] Those skilled in the art can clearly understand that for the convenience and simplicity of description, only the division of the above-mentioned functional units and modules is used as an example. In actual applications, the above-mentioned functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiments can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The above-mentioned integrated unit can be implemented in the form of hardware or in the form of software functional units.

[0224] If the integrated module / unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a readable storage medium (e.g., a computer-readable storage medium). Based on this understanding, the present application implements all or part of the processes in the above-mentioned embodiment method, and can also be completed by instructing the relevant hardware through a computer program. The computer program can be stored in a computer-readable storage medium, and the computer program can implement the steps of the above-mentioned various method embodiments when executed by the processor. The computer program may include computer program code, which may be in source code form, object code form, executable file or some intermediate form. Computer-readable storage media may include: any entity or device capable of carrying computer program code, recording medium, U disk, mobile hard disk, disk, optical disk, computer memory, read-only memory (ROM), random access memory (RAM), electric carrier signal, telecommunication signal and software distribution medium, etc.

[0225] The above embodiments are only used to illustrate the technical solutions of the present application, rather than to limit them. Although the present application has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. These modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the embodiments of the present application, and should all be included in the protection scope of the present application.

Claims

1. A method for changing a business status based on a data dictionary, characterized in that: include: Creating a data dictionary for service status management, wherein the data dictionary includes service types, status parameters, and service identifiers; Create a business process based on a workflow tool, load the data dictionary for the nodes in the business process, use the data dictionary to configure the corresponding business type, state parameter and service identifier for each node, and define the change rules of the business state; During the workflow operation, the backend service identifier is dynamically identified according to the service identifier of each node, and the state parameters of the current business node and the corresponding change rules are parsed using the data dictionary; According to the backend service identifier, a state change request is sent to the backend service, and the parsed state parameters are passed to the backend service, so that the backend service performs a corresponding state update operation according to the parsed state parameters.

2. The method according to claim 1, characterized in that The step of creating a data dictionary for business status management includes: Define the structure of the data dictionary, wherein the business type in the data dictionary is used to classify and identify different business processes, the state parameter is used to define the state and change rules of each node in the business process, and the service identifier is used to identify the backend service; The data dictionary is stored in a platform configuration module so that the data dictionary can be dynamically loaded during the operation of the workflow.

3. The method according to claim 1, characterized in that The step of creating a business process based on a workflow tool and loading the data dictionary for a node in the business process includes: Create a business process based on the workflow tool and define the flow relationship between the nodes in the business process; load the data dictionary for each node in the business process and configure the corresponding business type, state parameter and service identifier for each node according to business requirements; The business type is used to associate the business logic of the current business node, the state parameter is used to define the target state and change rules of the current business node, and the service identifier is used to bind the current business node to the backend service to support dynamic service calls.

4. The method according to claim 1, characterized in that: The change rules for defining the business status include: Based on the data dictionary, load the input state parameters of each node from the business process, wherein the input state parameters are used to identify the initial state of the node in the business process; Defining a state change condition for each node, and based on the state change condition, configuring an output state parameter for each node, wherein the output state parameter is used to identify a result state after the node state is changed; storing the input state parameter, the state change condition and the output state parameter in a rule module of a workflow tool; When the workflow is running, the change rules are dynamically loaded to parse the input state parameters of the node, verify whether the state change conditions are met, and generate corresponding output state parameters according to the state change conditions.

5. The method according to claim 1, characterized in that The using the data dictionary to analyze the status parameters of the current service node and the corresponding change rules includes: According to the status parameters and change rules of the current business node, the change conditions and target status applicable to the current business node are parsed; Parse the service identifier of the current business node, dynamically match the backend service associated with the current business node, and determine the service interface and communication address of the backend service; A state change instruction is generated based on the parsing result, and the state change instruction is used to drive the backend service to perform a corresponding state update operation.

6. The method according to claim 1, characterized in that The step of sending a state change request to a backend service according to the backend service identifier and passing the parsed state parameters to the backend service includes: Determine the service interface of the backend service according to the backend service identifier, call the service interface, and send the state change request to the backend service, wherein the state change request includes the parsed state parameters and related business information corresponding to the current business node; use the workflow tool to send the parsed state parameters to the backend service in the form of task callback, so that the backend service triggers the corresponding business logic according to the parsed state parameters.

7. The method according to claim 1, characterized in that After the backend service performs a corresponding status update operation according to the parsed status parameters, the method further includes: The state change information of each node is recorded in the workflow tool, and the state change information includes business type, state parameters and timestamp. The state change information is used to trace the state change of the node throughout the entire process; the state change result of the node is fed back to the workflow tool, so as to use the state change result to process the business logic of subsequent nodes.

8. A service status changing device based on a data dictionary, characterized in that: include: A creation module, configured to create a data dictionary for service status management, wherein the data dictionary includes service type, status parameter and service identifier; A configuration module is configured to create a business process based on a workflow tool, load the data dictionary for the nodes in the business process, configure the corresponding business type, state parameter and service identifier for each node using the data dictionary, and define a change rule for the business state; The parsing module is configured to dynamically identify the backend service identifier according to the service identifier of each node during the workflow operation, and parse the state parameters of the current business node and the corresponding change rules using the data dictionary; The update module is configured to send a state change request to the backend service according to the backend service identifier, and pass the parsed state parameters to the backend service, so that the backend service performs a corresponding state update operation according to the parsed state parameters.

9. An electronic device comprising a memory, a processor and a computer program stored in the memory and executable on the processor, characterized in that: When the processor executes the computer program, the steps of the method according to any one of claims 1 to 7 are implemented.

10. A computer-readable storage medium storing a computer program, characterized in that: When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 7 are implemented.

Images