Method, device, equipment and medium for changing business status based on data dictionary

Abstract

The present application provides a method, apparatus, device and medium for changing business status based on a data dictionary. The method includes: creating a data dictionary for business status management; creating a business process based on a workflow tool, loading a data dictionary for the nodes in the business process, configuring the corresponding business type, status parameters and service identifier for each node using the data dictionary, and defining business status change rules; during the workflow operation, dynamically identifying the 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. The present application can reduce the development cycle, reduce development and maintenance costs, and improve the adaptability and flexibility of the system.

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, managing and changing the status of production elements, such as material status, product status, and production status, is a core function. In traditional software design, state changes typically rely on custom code developed based on specific business needs. When business state requirements change or new states are added, secondary development or expansion of existing code is required to support the actual business needs. This approach results in long development cycles, complex testing logic, and poor code versatility, making it difficult to adapt to dynamically changing business needs.

[0003] Existing technologies typically address business state changes by directly developing interfaces within the core business code. For example, a material state change may involve multiple states, such as "apply → draft → create → approve → publish → apply," requiring the development of corresponding business code for each state change logic. While this approach 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. However, existing solutions often require developers to have professional knowledge and 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 existing technology.

[0006] In 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 a business type, status parameters, and a service identifier; 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 corresponding status update operations based on the parsed status parameters.

[0007] According to a second aspect of an embodiment of the present application, a business status change device based on a data dictionary 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, configure corresponding business types, status parameters and service identifiers for each node using the data dictionary, 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 parse the status parameters and corresponding change rules of the current business node using the data dictionary; 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, comprising 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 the embodiments of the present application, a computer-readable storage medium is provided, which stores a computer program. 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 types, status parameters and service identifiers; 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 identifiers for each node, and defining business status change rules; during the workflow operation, dynamically identifying the backend service identifier based on the service identifier of each node, and using the data dictionary to parse the status parameters of the current business node and the corresponding change rules; 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. This application can shorten 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 following briefly introduces the drawings required for use in the embodiments or descriptions of the prior art. 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 any creative work.

[0013] Figure 1 This is a flow chart of a method for changing a service state based on a data dictionary provided in an embodiment of the present application;

[0014] Figure 2 This 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 structural diagram 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 and techniques are provided for purposes of illustration rather than limitation to facilitate a thorough understanding of the embodiments of the present application. However, it will be apparent to those skilled in the art that the present application may 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 avoid obscuring the description of the present application with unnecessary detail.

[0017] In the industrial software sector, managing and changing production elements (such as the status of materials, products, or production) is a core requirement for achieving efficient production operations. Typically, the status of production elements undergoes multiple changes during the business process. For example, a material may gradually transition from the "request" status to the "release" or "applied" status. Managing these statuses requires clear logical rules and efficient technical implementation methods.

[0018] To manage and change these states, traditional software development models tend to rely on writing custom code based on specific business requirements. This means that whenever a new requirement arises, such as adding a new state or adjusting state change logic, secondary development of the existing software is often necessary. This approach not only prolongs development cycles but also increases code complexity, potentially impacting system stability due to frequent changes.

[0019] Currently, a common technical solution is to develop interfaces directly within the core business code to implement state management and changes. This existing approach requires development teams to manually write code to implement state logic for each business requirement (such as a material status change). For example, a material status change may involve multiple stages, such as "apply → draft → create → approve → publish → apply." Each stage of state transition requires corresponding business logic code.

[0020] This approach relies on direct development of the core software code. Each time a new state is added or the state logic is adjusted, the code needs to be rewritten and thoroughly tested. The state logic is highly coupled and has poor versatility. While existing technical methods can meet the business needs of specific scenarios, they still have the following significant shortcomings:

[0021] 1. Long development cycle: Because customized development is required for each specific requirement, 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, resulting in a lack of 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 with existing technical solutions are: First, although workflow tools are introduced in some cases, developers still need to have certain professional knowledge to configure the state change process and functions. Second, the current solution is slow to respond to the expansion needs of business states and does not support fast and flexible adaptation to different business scenarios. Finally, each new state or change logic requires redevelopment of code, which consumes a lot of manpower and time.

[0026] In view of the problems existing in the existing technology, 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 the implementation of business status changes 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 a workflow state configuration tool developed based on the workflow tool (flowable+bpmnjs+vue) and the dictionary configuration function of the platform, with the front-end vue language and the back-end java language as the software development language. 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. This makes the change and expansion of the business state more flexible. At the same time, by adopting the process management control method and a richer process design, more complex and flexible state changes can be made during the operation of the workflow tool, for example: according to different process parameters, different processes are controlled to change different states. The workflow changes the business state through 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: Integrates BPMNJS to support graphical workflow design and build business process logic in the form of intuitive flowcharts.

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

[0032] Backend framework: Use Java to implement the backend service logic, including data dictionary management, state change rule parsing, and service callback implementation.

[0033] The core concept of this technical solution is to separate the business state management logic from the core business code, decoupling state changes through workflow tools and data dictionary configuration. The data dictionary supports dynamic business state expansion, business type expansion, and interface binding. By identifying configuration content during the workflow runtime, state changes are streamlined and controlled, and state updates are completed through service callbacks.

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

[0035] Figure 1 This is a flow chart of the method for 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 parameters and service identification;

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

[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: 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.

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

[0041] Define the structure of the data dictionary. The business type in the data dictionary is used to classify and identify different business processes. The status parameter is used to define the status and change rules of each node in the business process. 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:

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

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

[0046] QFAAS0001: Not submitted;

[0047] QFAAS0002: Under review;

[0048] QFAAS0004: Approved;

[0049] QFAAS0005: Revoked.

[0050] Service ID: Used to locate backend service instances to support dynamic service calls when state changes occur. For example, the service ID configured as hollycon-mes-biz-back-end represents 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: supports centralized management of business status, business type and service identification; can dynamically load the configuration content of the data dictionary during the workflow operation phase to avoid repeated development and configuration; provides extensibility, allowing users to dynamically modify or add data dictionary content through the front-end interface.

[0053] The following uses the file review process as an example to illustrate 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 represents 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 allows adding or adjusting business process states and types without modifying the core code. For example, adding state QFAAS0006 (Archived) can be accomplished simply by updating the data dictionary. The dynamic loading capability of the data dictionary enables workflow tools to recognize and apply configuration content in real time, reducing development time. By separating business state management from workflow tools and dynamically invoking backend services through service identifiers, the system's adaptability and scalability are improved.

[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 the data dictionary for each node in the business process and configure the corresponding business type, status parameters and service identifier 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 and create and define the flow relationships between nodes. For example, the document review process includes multiple nodes, such as "document submission," "department review," "quality review," and "document release."

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

[0067] Each node has clear flow-in and flow-out conditions. For example, if the file status is "Unsubmitted," it will flow into the "Department Review" node; if the file status is "Under Approval," it will flow 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 Publish" 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] Based on 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 for the review node, including approval logic and status change rules.

[0072] 2) Definition of state parameters:

[0073] Load the node's corresponding status parameters from the data dictionary to specify the node's target status and change conditions. For example, if the "Department Review" node's status parameter is configured as "Approving," the status will change to "Approving" after the node completes execution.

[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 uses the "Department Review" and "Quality Review" nodes in the document review process as an example to illustrate the specific implementation process of data dictionary loading and node configuration. The specific content is as follows:

[0077] 1. Department review nodes:

[0078] Business Type: Document Review Process (QMS_FILE_WORK_FLOW_MANGEMENT). Status: Under Approval (QFAAS0002). Service ID: 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 "Approval in Progress" 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 Process (QMS_FILE_WORK_FLOW_MANGEMENT). Status: 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, nodes are associated with specific business logic modules by loading business types from the data dictionary. For example, in the "Department Review" node, the business type "Document Review Process Business" is loaded with the approval rule module, allowing the system to automatically identify and execute the processing logic related to document review.

[0086] The status parameter indicates the target status of a node and serves as the basis for process flow. For example, if 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] Service identifiers are bound to nodes through the data dictionary to enable dynamic service invocation. For example, in the "Quality Review" node, the service identifier hollycon-mes-biz-back-end points to the backend interface that receives state change requests and completes the state update.

[0088] Through the above implementation method, the business logic, state parameters, and service bindings of each node in this embodiment are dynamically loaded and configured through the data dictionary, eliminating the need for hard coding. Node state parameters and change rules can be quickly added or adjusted by updating the data dictionary. Dynamic binding of service identifiers decouples nodes from backend services, adapting to the deployment requirements of distributed systems. Workflow tools, combined with the use of the data dictionary, provide unified, streamlined state change control, enabling efficient business process management.

[0089] In some embodiments, defining a change rule for a service 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 state change conditions for each node, and based on the state change conditions, configure output state parameters for each node. The output state parameters are used to identify the resulting 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 loaded dynamically 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 represents the initial state of a node in the business process and serves as the starting point for state changes. The corresponding input status parameter is loaded for each node through the data dictionary. For example, the node "Document Submission" corresponds to the input status parameter QFAAS0001 (Not Submitted); the node "Department Review" corresponds to the input status parameter QFAAS0002 (Approval in Progress).

[0095] Furthermore, a workflow tool (such as BPMNJS) is used to load a data dictionary for the business process node; according to the business process design, the input state parameters of the node are defined and configured in the data dictionary; and the configuration is saved in the 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 conditions 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 automated 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] Enter status parameters: QFAAS0002 (under review);

[0103] Trigger condition: Approval result is "passed";

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

[0105] Furthermore, the output status parameter represents the result status after the business process node is executed and serves as the basis for state transitions. For example, the output status parameter of the "Department Review" node can be QFAAS0004 (Approved) or QFAAS0005 (Rejected).

[0106] In the workflow tool, set corresponding output status parameters for each node based on 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 for the node "department review" is: input status parameter: QFAAS0002 (under review); change condition: approval result is "passed"; output status parameter: QFAAS0004 (approved).

[0108] Store the rules 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, it parses the input state parameters and verifies whether the change conditions are met.

[0110] Furthermore, the system determines whether the state change conditions are met based on the analysis results: if the conditions are met, the corresponding output state parameters are generated; if the conditions are 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 "Pass", the system parsing rule generates the output status parameter QFAAS0004 (approval passed) and flows to the next node "Quality Review".

[0112] Through the above-described method of this embodiment, this embodiment dynamically loads data dictionaries and change rules, supporting the adjustment and expansion of business needs without hard coding. Change rules are centrally stored in the rule module, facilitating unified management and maintenance. By organically combining input states, change conditions, and output states, refined control of state changes within business processes is achieved.

[0113] In some embodiments, the data dictionary is used to parse the status parameters of the current service node and the corresponding change rules, 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] Generate state change instructions based on the parsing results, which are used to drive the backend service to perform corresponding state update operations.

[0117] Specifically, when the current business node is running, the system loads the node's 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 the status change conditions applicable to the current node. For example:

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

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

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

[0122] Furthermore, the system verifies whether the current node meets the state change conditions. For example, it checks whether the approval result submitted by the user is "passed." If the conditions are met, the system continues to resolve the target state; otherwise, the current state is maintained or exception handling logic is triggered.

[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, ensuring 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 invocation.

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

[0126] Furthermore, the system uses a rules engine to analyze the node's change logic, combining the input state, conditional validation results, and target state to generate a complete instruction. This instruction drives the backend service to execute state updates, ensuring that state changes in the business process are 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 back-end service, parses the service address and interface; generates a status change instruction and sends it to the back-end service; the back-end service receives the instruction and updates the status to QFAAS0004 (approval passed).

[0129] Through the method described in this embodiment, the system can dynamically load state parameters and rules based on node configuration, adapting to the needs of different business scenarios. Service identity resolution combined with the service registration mechanism ensures accurate service location in a multi-instance environment. The instruction generation and verification process strictly adheres to rules, ensuring the accuracy and consistency of business state changes.

[0130] In some embodiments, 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 include:

[0131] Determine the service interface of the backend service based on 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 based on the parsed state parameters.

[0132] Specifically, when the workflow runs, 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), the interface parameters and calling rules of the current business status are dynamically matched 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 parameter, 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 via HTTP based on the parsed service interface. For example, in the "Department Review" node, a status change request is sent to the backend service, including the current status QFAAS0002 and the target status QFAAS0004, as well as business information such as the document number and approval result.

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

[0141] Furthermore, after a task node is executed, the workflow tool passes the current node's status parameters and business information to the backend service through a task callback mechanism. Task callbacks ensure the decoupling of business processes from backend service logic and support 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 based on the callback content: verify the current status and approval conditions; update the file status to QFAAS0004 (approved); and 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. Next, it determines the backend service interface address and generates a status change request, which includes the current status, target status, and business information. Finally, the system passes the status parameters and business information to the backend service through a task callback. Upon receiving the request, the backend service updates the document status to QFAAS0002 (under review).

[0150] It's important to note that in multi-instance deployments, the workflow tool dynamically resolves the IP and port numbers of service instances using service identifiers, for example, from hollycon-mes-biz-back-end to the service address. The system then sends requests to available service instances through a task callback mechanism and supports retry logic to ensure high reliability of state changes.

[0151] The method of this embodiment, through task callbacks and dynamic binding, automatically completes the transfer of state parameters and state updates. The dynamic service location mechanism supports flexible expansion in distributed deployment environments. Task callbacks decouple business processes from 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 parameters, 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, state change information is used to record the state changes of each node in the business process, and 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 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 to quickly locate problematic nodes, analyze the historical trajectory of state changes, and provide audit and compliance support. Workflow tools combine 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 the status change results back to the workflow tool, including:

[0162] Change status: success or failure;

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

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

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

[0166] Furthermore, the workflow tool determines whether to execute subsequent nodes and the specific execution logic based on the status change result of the current node. For example, if the status change is successful, the next node will be executed; if the status change fails, the exception handling logic will be 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 flows to the node "Document Release"; if the status is QFAAS0005 (approval rejected), it flows to the end node or re-enters 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-described method of this embodiment, this embodiment comprehensively records node status change information, including business type, status parameters, and timestamps, supporting subsequent auditing and problem location. After the backend service completes the status update, a feedback mechanism ensures that the workflow tool promptly receives the updated results, ensuring the continuity of the business process. Based on the status change results, the workflow tool can dynamically adjust the logic of subsequent nodes, improving 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 implement the status changes 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, 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 "Unsubmitted" 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 Process Business (QMS_FILE_WORK_FLOW_MANGEMENT) and configure the node status parameter to Approving (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 Process Business" (QMS_FILE_WORK_FLOW_MANGEMENT) and configure the node status parameter 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 identifier through the data dictionary and binds it 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] Furthermore, in 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 identifier; based on the configuration content of the current node, it calls the data dictionary to parse the service identifier 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, resolving the address corresponding to the hollycon-mes-biz-back-end service; the tool generates a state change request, which includes current state parameters, target state parameters, and business information (such as document number and approver information); and sends the request to the backend service via HTTP POST, triggering 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 the 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 will determine 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 are device embodiments of the present application, which can be used to implement the method embodiments of the present application. For details not disclosed in the device embodiments of the present application, please refer to the method embodiments of the present application.

[0207] Figure 2 This is a 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 parameters and service identification;

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

[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 status parameter is used to define the status 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 the 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, status parameters and service identifier for each node according to business needs; among them, the business type is used to associate the business logic of the current business node, the status 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; a state change condition is defined for each node, and based on the state change condition, an output state parameter is configured for each node. The output state parameter is used to identify the result state after the node state is changed; the input state parameters, state change conditions and output state parameters are stored in the rule module of the 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.

[0215] In some embodiments, Figure 2 The parsing module 203 parses the change conditions and target state applicable to the current business node based on 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 back-end 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, and uses the status change information to trace the entire process of the node's status change; the node's status change result is fed back to the workflow tool to use the status change result to process the business logic of subsequent nodes.

[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 this application.

[0219] Figure 3 Schematic diagram of the electronic device 3 provided in the 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 by the processor 301. When the processor 301 executes the computer program 303, the steps of 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 understand that Figure 3 This is merely an example of the electronic device 3 and does not limit the electronic device 3 . The electronic device 3 may include more or fewer components than shown in the figure, or different components.

[0221] The processor 301 can 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 can be an internal storage unit of the electronic device 3, such as a hard disk or memory of the electronic device 3. The memory 302 can also be an external storage device of the electronic device 3, such as a plug-in hard disk, a smart media card (SMC), a secure digital (SD) card, a flash memory card, etc. equipped on the electronic device 3. The memory 302 can 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 will clearly understand that for the sake of convenience and brevity of description, only the division of the above-mentioned functional units and modules is used as an example for illustration. In actual applications, the above-mentioned functions can be distributed and completed by 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 units 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 (such as 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, etc. Computer-readable storage media may include: any entity or device capable of carrying computer program code, recording medium, U disk, mobile hard disk, magnetic 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 various embodiments of the present application, and should all be included in the scope of protection of the present application.

Claims

1. A method for changing 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 type, status parameters and service identification; Creating a business process based on a workflow tool, loading the 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 business state change rules; 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 workflow operation.

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 nodes in the business process includes: Creating a business process based on the workflow tool and defining the flow relationship between each node in the business process; loading the data dictionary for each node in the business process and configuring the corresponding business type, status parameters 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, wherein The rules for defining the change of 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 configuring an output state parameter for each node based on the state change condition, wherein the output state parameter is used to identify the 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, wherein 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 the 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, where 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 a task callback manner, 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 that the business logic of subsequent nodes can be processed using the state change result.

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 configured to create a business process based on a workflow tool, load the 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 business state change rules; A 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, wherein: 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