Workflow engine system and control method of microservice architecture

Abstract

The present disclosure provides a workflow engine system and control method of micro-service architecture, which adopts modular design of micro-service architecture and introduces AIGC intelligent gateway service and CDC incremental data extraction mechanism, realizes elastic expansion of workflow system, can realize independent deployment and load balancing between different service nodes, avoids single point failure, simultaneously replaces full polling by using CDC mechanism, realizes real-time capture and distribution of database change events, greatly reduces data processing delay and system resource occupation, so as to improve system stability and response efficiency while ensuring high concurrency performance.

Description

Technical Field

[0001] This disclosure relates to the field of process automation technology, and more specifically, to a workflow engine system and control method with a microservice architecture. Background Technology

[0002] As enterprises deepen their digital transformation, the demand for business process automation and collaborative management is growing rapidly. Existing workflow systems are typically based on monolithic or simple distributed architectures, using built-in process engines to model, execute, and approve business processes. However, as enterprise business scales up and system integration complexity increases, these traditional architectures are gradually revealing various technical bottlenecks.

[0003] First, the system suffers from high coupling and poor elasticity. In a monolithic architecture, process definition, task execution, data storage, and external interface calls are often concentrated in the same application. Any module failure can lead to a system-wide outage, making it difficult to achieve high availability and elastic scaling. Second, the data processing model is outdated. Most existing workflow systems rely on polling to detect changes in process status, meaning the business system periodically queries the database to obtain the latest task information. This approach has poor real-time performance, high resource consumption, and is prone to causing database performance bottlenecks in high-concurrency environments. Summary of the Invention

[0004] This disclosure provides at least one workflow engine system and control method based on a microservice architecture. It adopts a modular design of microservice architecture and introduces AIGC intelligent gateway service and CDC incremental data extraction mechanism to achieve elastic scalability of the workflow system. It can be independently deployed and load balanced among different service nodes to avoid single points of failure. At the same time, it uses the CDC mechanism to replace full polling to achieve real-time capture and distribution of database change events, which greatly reduces data processing latency and system resource consumption, thereby improving system stability and response efficiency while ensuring high concurrency performance.

[0005] This disclosure provides a workflow engine system with a microservice architecture, including: a client, an API gateway, a microservice cluster including at least an AIGC gateway service and an incremental data extraction service, a message queue, a CDC connector, a workflow database, and an external AIGC service; The client is used to provide a graphical process designer and a dynamic form designer interface, and to communicate with the API gateway; The API gateway is used to receive process creation requests sent by users through the client, and to route the process creation requests to the corresponding microservices in the microservice cluster according to the request path corresponding to the process creation request and the preset load balancing strategy. The AIGC gateway service is used to extract process variables and map them with a preset prompt word template in response to the corresponding call request when the task process is executed to the preset AIGC task node, generate an AIGC call request and call the external AIGC service to obtain the generated content. The incremental data extraction service is used to subscribe to the topics of the message queue, parse the database change events sent by the CDC connector, and distribute the changed data to downstream consumers. The CDC connector is deployed between the workflow database and the message queue to capture database change events in the binary log of the workflow database and convert the database change events into message format to send to the message queue.

[0006] In one optional implementation, the microservice cluster further includes a process definition service and a process runtime service; The process definition service is used to receive process deployment requests from the API gateway, parse the process model file uploaded by the client to obtain the process model, and persist the process model to the workflow database. The process runtime service is used to receive a process instance start request from the API gateway, load a process definition from the workflow database, create a process instance and drive the process instance to flow according to the process definition, generate runtime data and store it in the workflow database.

[0007] In one optional implementation, the AIGC gateway service is specifically used for: When the process runtime service detects that the process has reached the preset AIGC task node, it synchronously receives the call request carrying the process instance identifier and the task identifier according to the process definition; Based on the process instance identifier, call the interface of the process runtime service to obtain all process variables and context data of the process instance; According to the call interface path, the corresponding preset prompt word template is retrieved from the internally maintained prompt word template registry, the variable placeholders in the preset prompt word template are parsed, and the process variables are matched and replaced, and the variable placeholders are replaced with actual variable values. The system role settings, the context data, and the template content are assembled into a request body that meets the requirements of the target AIGC service interface. The interface of the external AIGC service is called to send the request body and wait for the return result. The response data returned by the external AIGC service is parsed, the generated content is extracted, and written into the workflow database as an update process variable.

[0008] In one optional implementation, the incremental data extraction service is specifically used for: Subscribe to the original topic in the message queue through the consumer group mechanism to receive the database change event sent by the CDC connector; Parse the changed data in the database change event, and only listen to records of preset tables or event types, including new task creation events in the process history task table and completion status update events in the process instance table for data filtering; After enriching the filtered change data with entity business information to form actual business data, multi-target routing and distribution are performed according to preset business configuration rules to distribute the actual business data corresponding to the same database change event to multiple downstream topics, so that the downstream consumers can trigger the business actions corresponding to the actual business data.

[0009] In one optional implementation, when the incremental data extraction service crashes or restarts, messages are automatically accumulated in the message queue, and consumption continues from the breakpoint after the incremental data extraction service recovers. When the amount of data changes increases, the service instances of the incremental data extraction service are automatically added to consume the same topic in the message queue in parallel.

[0010] In one optional implementation, the microservice cluster further includes a user task service and a dynamic form service; The user task service is used to generate user-related task records and store them in the workflow database; The dynamic form service is used to store form field configuration information and associate it with the process model. During task execution, it provides a form rendering interface for the user task service to call and obtain the form structure, and then dynamically renders the form interface in the client.

[0011] This disclosure also provides a workflow engine control method for a microservice architecture, applied to a workflow engine system for a microservice architecture as described in any of the above embodiments, the method comprising: In response to a process creation request sent by a user through the client, the process is routed to the process definition service via the API gateway, and the process definition is parsed and stored. When a process instance starts, the process definition is loaded from the workflow database and the instance is created. When the process reaches the AIGC service node, the AIGC gateway service is called to extract process variables and generate an AIGC call request based on the preset prompt word template. The external AIGC service is then called to obtain the generated content and return it to the workflow engine system. When a user task node is generated or its status changes, the database change event is captured in real time through the CDC connector, the database change event is converted into a message and sent to the message queue; The incremental data extraction service subscribes to the topics of the message queue, parses, filters, enriches and transforms the message content, and triggers notifications or analysis tasks.

[0012] This disclosure also provides an electronic device, including: a processor, a memory, and a bus. The memory stores machine-readable instructions executable by the processor. When the electronic device is running, the processor communicates with the memory via the bus. When the machine-readable instructions are executed by the processor, they execute the workflow engine control method of the microservice architecture described above, or any possible implementation of the workflow engine control method of the microservice architecture described above.

[0013] This disclosure also provides a computer-readable storage medium storing a computer program that, when executed by a processor, performs the workflow engine control method of the microservice architecture described above, or any possible implementation of the workflow engine control method of the microservice architecture described above.

[0014] This disclosure also provides a computer program product, including a computer program / instruction, which, when executed by a processor, implements the workflow engine control method of the microservice architecture described above, or the steps in any possible implementation of the workflow engine control method of the microservice architecture described above.

[0015] This disclosure provides a workflow engine system and control method based on a microservice architecture. It adopts a modular design of microservice architecture and introduces AIGC intelligent gateway service and CDC incremental data extraction mechanism to achieve elastic scalability of the workflow system. It can be independently deployed and load balanced among different service nodes to avoid single points of failure. At the same time, it uses the CDC mechanism to replace full polling to achieve real-time capture and distribution of database change events, which greatly reduces data processing latency and system resource consumption, thereby improving system stability and response efficiency while ensuring high concurrency performance.

[0016] To make the above-mentioned objects, features and advantages of this disclosure more apparent and understandable, preferred embodiments are described below in detail with reference to the accompanying drawings. Attached Figure Description

[0017] To more clearly illustrate the technical solutions of the embodiments of this disclosure, the accompanying drawings used in the embodiments will be briefly described below. These drawings are incorporated in and constitute a part of this specification. They illustrate embodiments conforming to this disclosure and, together with the specification, serve to explain the technical solutions of this disclosure. It should be understood that the following drawings only show some embodiments of this disclosure and should not be considered as limiting the scope. Those skilled in the art can obtain other related drawings based on these drawings without creative effort.

[0018] Figure 1 A schematic diagram of a workflow engine system with a microservice architecture provided in an embodiment of this disclosure is shown. Figure 2 This illustration shows an interactive diagram of the workflow of a workflow engine system with a microservice architecture provided in an embodiment of the present disclosure; Figure 3 A flowchart of a workflow engine control method for a microservice architecture provided in an embodiment of this disclosure is shown; Figure 4 A schematic diagram of an electronic device provided in an embodiment of the present disclosure is shown. Detailed Implementation

[0019] To make the objectives, technical solutions, and advantages of the embodiments of this disclosure clearer, the technical solutions of the embodiments of this disclosure will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this disclosure, and not all of them. The components of the embodiments of this disclosure described and shown in the accompanying drawings can generally be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of this disclosure provided in the accompanying drawings is not intended to limit the scope of the claimed disclosure, but merely represents selected embodiments of this disclosure. All other embodiments obtained by those skilled in the art based on the embodiments of this disclosure without inventive effort are within the scope of protection of this disclosure.

[0020] It should be noted that similar labels and letters in the following figures indicate similar items. Therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures.

[0021] In this document, the term "and / or" merely describes a relationship, indicating that three relationships can exist. For example, A and / or B can represent three cases: A alone, A and B simultaneously, and B alone. Furthermore, the term "at least one" in this document means any combination of at least two of any one or more elements. For example, including at least one of A, B, and C can mean including any one or more elements selected from the set consisting of A, B, and C.

[0022] Research has revealed that as businesses expand and system integration becomes more complex, traditional architectures are increasingly exhibiting various technical bottlenecks. First, they suffer from high system coupling and poor elasticity. In monolithic architectures, process definition, task execution, data storage, and external interface calls are often concentrated in the same application. Any module failure can lead to a system-wide outage, making high availability and elastic scaling difficult. Second, their data processing models are outdated. Most existing workflow systems rely on polling to detect process status changes, meaning the business system periodically queries the database for the latest task information. This approach suffers from poor real-time performance, high resource consumption, and is prone to causing database performance bottlenecks in high-concurrency environments.

[0023] Based on the above research, this disclosure provides a workflow engine system and control method with a microservice architecture. It adopts a modular design of microservice architecture and introduces AIGC intelligent gateway service and CDC incremental data extraction mechanism to realize the elastic scalability of the workflow system. It can achieve independent deployment and load balancing among different service nodes, avoiding single points of failure. At the same time, it uses the CDC mechanism to replace full polling, realizes real-time capture and distribution of database change events, significantly reduces data processing latency and system resource consumption, thereby improving system stability and response efficiency while ensuring high concurrency performance.

[0024] To facilitate understanding of this embodiment, a workflow engine system based on a microservice architecture disclosed in this disclosure will first be described in detail.

[0025] See Figure 1 The diagram shown is a schematic of a workflow engine system based on a microservice architecture provided in an embodiment of this disclosure. Figure 1 As shown, the workflow engine system of the microservice architecture includes: a client, an API gateway, a microservice cluster including at least an AIGC gateway service and an incremental data extraction service, a message queue, a CDC connector, a workflow database, and an external AIGC service.

[0026] Specifically, the client provides a graphical workflow designer and a dynamic form designer interface and communicates with the API gateway; the API gateway receives workflow creation requests sent by users through the client, routes the request information to the corresponding microservice in the microservice cluster according to the request path corresponding to the workflow creation request and the preset load balancing strategy; the AIGC gateway service extracts workflow variables and maps them with preset prompt word templates in response to the corresponding call request when the task workflow executes to the preset AIGC task node, generates an AIGC call request, and calls the external AIGC service to obtain the generated content; the incremental data extraction service subscribes to the topic of the message queue, parses the database change events sent by the CDC connector, and distributes the changed data to downstream consumers; the CDC connector is deployed between the workflow database and the message queue, and is used to capture database change events in the binary log of the workflow database and convert the database change events into message format and send them to the message queue.

[0027] As one possible implementation, the microservice cluster also includes a process definition service, a process runtime service, a user task service, and a dynamic form service. The process definition service receives process deployment requests from the API gateway, parses the process model file uploaded by the client to obtain the process model, and persists the process model to the workflow database. The process runtime service receives process instance start requests from the API gateway, loads the process definition from the workflow database, creates a process instance, drives the process instance to flow according to the process definition, generates runtime data, and stores it in the workflow database. The user task service generates user-related task records and stores them in the workflow database. The dynamic form service stores form field configuration information and associates it with the process model. During task execution, it provides a form rendering interface for the user task service to call to obtain the form structure, and then dynamically renders the form interface on the client.

[0028] In one embodiment of the present invention, the microservice cluster includes a process definition service, a process runtime service, a user task service, and a dynamic form service. Each service is deployed independently in a containerized manner and interacts with each other through lightweight communication mechanisms (such as HTTP REST, RPC, or message queues), thereby ensuring the high scalability and high reliability of the system architecture. Each service has a single responsibility and clear boundaries, and collaboratively completes core functions such as workflow modeling, execution, task management, and form interaction.

[0029] The process definition service receives process deployment requests from the API gateway. After a user completes process modeling on the client, the client uploads the generated process model file (e.g., BPMN 2.0 format) to the API gateway. The API gateway parses the request path and routes the deployment request to the process definition service. This service parses the process model file, extracting information such as process nodes, connectors, task types, form bindings, and conditional expressions, and generates a standardized process model object. After parsing, the process definition service persistently stores this process model object in the workflow database for subsequent process instance loading and execution. Preferably, the process definition service also supports a version management mechanism, allowing multiple historical versions of the same process to be stored in the database for process version backtracking and compatibility.

[0030] The Runtime Service receives process instance start requests from the API Gateway and is responsible for creating and running process instances. When a user triggers a process start operation through the client, the API Gateway forwards the request to the Runtime Service. The Runtime Service first loads the corresponding process definition from the workflow database, creates a new process instance object based on the definition, and initializes process variables. Subsequently, the Runtime Service drives the process instance flow according to the node order and conditional expressions in the process model. Runtime data generated during execution (including task status, execution time, variable snapshots, etc.) is written to the workflow database in real time. This service also supports interaction with the AIGC Gateway Service, automatically initiating a call when the process execution reaches an AIGC task node to achieve intelligent approval and automated content generation.

[0031] The User Task Service manages user-related task information. When a process instance reaches a user task node, the process runtime service sends a task generation request to the User Task Service. The User Task Service generates a pending task record based on the process context, including the task name, node identifier, associated process instance ID, responsible person, due date, and task status, and stores this record in the workflow database. After task generation, the User Task Service can send pending notifications to clients or message push modules according to configuration, enabling real-time task reminders. Furthermore, this service provides interfaces for task assignment, approval, and return, which clients can call to complete the task processing.

[0032] The dynamic form service supports the dynamic configuration and rendering of forms at process nodes. This service stores form field configuration information and establishes a relationship with the process model in the process definition service. When configuring forms during the process definition phase, the form structure data generated by the designer (including field names, types, validation rules, and display conditions) is persisted to the dynamic form service database. During the task execution phase, the user task service calls the form rendering interface provided by the dynamic form service to obtain the form structure information matching the current task node. The client then dynamically renders the form interface, allowing users to fill in and submit task data without modifying the front-end code. This mechanism decouples form logic from business logic, improving the flexibility and maintainability of process configuration.

[0033] In this way, through the above design, each service in the microservice cluster can be deployed and scaled independently, while also cooperating through standardized interfaces to achieve full-chain support for functions such as process modeling, instance execution, task management, and form display. This architecture effectively reduces the coupling between system modules, giving the workflow engine higher scalability and fault tolerance, and providing stable underlying support for the integration of intelligent modules (such as AIGC gateway service and incremental data extraction service).

[0034] In one embodiment of the present invention, the client provides a graphical process designer and a dynamic form designer interface, serving as the system's human-computer interaction entry point. It enables operations such as process modeling, form configuration, task viewing, and process monitoring. This client can be implemented as a web front-end or a desktop application, preferably using a browser-based front-end architecture to support cross-platform access and dynamic interaction.

[0035] Here, the graphical process designer provides a visual process orchestration interface, allowing users to create business process models by dragging and dropping nodes, connecting lines, configuring conditions, and setting properties. Process nodes include start events, user tasks, service tasks, AIGC intelligent task nodes, conditional branch nodes, and end events. The designer can generate process definition files conforming to the BPMN (Business Process Model and Notation) specification and send deployment requests to the API gateway via HTTP or WebSocket protocols. Upon receiving the request, the API gateway forwards the process definition file to the backend process definition service for parsing and persistence, thereby decoupling frontend design from backend execution.

[0036] The dynamic form designer is used to configure the form structure, field types, and validation rules during the process definition phase. Users can define form fields (such as text boxes, dropdown lists, date pickers, etc.) and their data constraints (such as required fields, format restrictions, numerical ranges, etc.) in the designer, and generate corresponding JSON structured form configuration files through user interface interaction. After the client submits the form configuration, the configuration file is transmitted to the dynamic form service via the API gateway for storage, so that the form interface can be dynamically loaded and rendered during process runtime.

[0037] It should be noted that the client also supports a bidirectional communication mechanism with the API gateway. In normal request scenarios, synchronous interaction is performed using the HTTP protocol for data exchange such as process deployment, task submission, and approval operations. In real-time monitoring or task reminder scenarios, the WebSocket protocol is used to implement long-connection push, so as to receive process status change notifications issued by the incremental data extraction service or message queue in a timely manner, thereby realizing real-time updates and display of task pending, process progress, and approval results.

[0038] In this way, through the above design, the client not only implements front-end interactive functions for visual process configuration and dynamic form definition, but also completes standardized communication with various backend microservices through the API gateway. This solution can effectively improve the flexibility of process modeling and form design, reduce the operational threshold for non-technical users, and at the same time, achieve security authentication, interface aggregation, and load distribution through a unified gateway, ensuring the stability and scalability of the system in high-concurrency scenarios.

[0039] In one embodiment of the present invention, the API gateway serves as the unified access layer of the system, receiving requests from users via clients for process creation, task submission, approval operations, and form configuration. Based on the request path, HTTP method, and load balancing strategy, the API gateway routes the request information to the corresponding target service in the microservice cluster. Located between the client and the backend microservices, the API gateway is a core component for the system to achieve secure access, unified authentication, protocol conversion, and traffic control.

[0040] Specifically, when a user initiates a process creation request through the graphical process designer on the client, the client packages the process definition file and metadata information into a standard HTTP request message and sends it to the API gateway. Upon receiving the request, the API gateway first parses it based on the request path, such as if the path contains identifiers like " / workflow / deploy" or " / runtime / process-instances". The API gateway pre-maintains a routing table, where each path prefix corresponds to a backend microservice module, such as a process definition service, a process runtime service, a user task service, or an AIGC gateway service. Through the path matching mechanism, the gateway can automatically determine the target service type of the request.

[0041] Here, after identifying the target service, the API gateway further selects the specific instance address of the target microservice based on a preset load balancing strategy (such as round-robin, least connections, weighted allocation, or dynamic scheduling based on response time) and forwards the request information to the corresponding microservice node. This mechanism can effectively distribute the pressure of concurrent requests and avoid overloading a single service instance. During the forwarding process, the gateway can also attach authentication tokens, user identification, and tenant information to support secure access control in multi-user, multi-tenant environments.

[0042] In addition, the API gateway also features circuit breaking and retry mechanisms. When a backend microservice node is detected to be unavailable or has a timeout, the gateway automatically reroutes the request to other available instances to ensure uninterrupted request processing. If all instances are temporarily unavailable, the circuit breaker logic is triggered and a predefined error response is returned, while an exception log is recorded for system monitoring and recovery mechanisms.

[0043] In this way, through the above design, the API gateway achieves efficient, secure, and intelligent routing and scheduling from the client to the backend microservices. Its unified access capability avoids the complexity of the client interacting directly with multiple services and simplifies system interface management; load balancing and fault tolerance mechanisms improve the overall service's concurrency capacity and stability; combined with dynamic routing and authentication policies, the system can flexibly distribute traffic and securely isolate it according to different request types, thereby providing a highly reliable access channel for the microservice cluster.

[0044] In one embodiment of the present invention, the AIGC gateway service is used to respond to the call request of the process runtime service when the task flow execution reaches the preset AIGC task node, and complete the entire process of extracting process context variables, mapping prompt template variables, generating AIGC call requests, and sending back the generated content. This module is a key component for the system to realize intelligent process automation.

[0045] Specifically, when the process runtime service detects that the current process instance has reached the AIGC service task node, it sends a call request to the AIGC gateway service. The request body includes the process instance ID, task ID, and context parameters of the current node. After receiving the request, the AIGC gateway service first calls the interface provided by the process runtime service based on the process instance ID to obtain all process variable information of the process instance from the workflow database, including user input data, approval records, task status, and form field values.

[0046] Here, after variable extraction is complete, the AIGC gateway service retrieves the corresponding preset Prompt template from its internally maintained prompt template registry based on the node identifier in the call request. This template can predefine text prompt content and placeholder variables (such as "{applicant}", "{reason}", "{applicantHistory.totalUsedLeaveDays}", etc.) to describe the generation goal of the AIGC task. The system supports a multi-template coexistence mechanism, allowing selection of a matching template based on task type, process definition identifier, or tenant ID.

[0047] Subsequently, the AIGC gateway service performs variable mapping and replacement operations, filling the placeholder positions in the template with the extracted process variables one by one, generating prompts with complete contextual semantics. During this process, the system can perform type checking, format normalization, and sensitive information desensitization on variable values ​​to ensure transmission security and input standardization.

[0048] Furthermore, after completing the Prompt rendering, the AIGC gateway service assembles a request body that conforms to the requirements of the external AIGC service interface, based on the configured target AIGC model type (such as a large language model or a text generation model). The request body includes the system role setting (system_role), task description (instruction), and the replaced Prompt text content. Subsequently, the service sends this request to the external AIGC service via HTTP or gRPC protocol and waits for the generated result to be returned.

[0049] Here, upon receiving the JSON response from AIGC, the AIGC gateway service parses the generated text, scoring results, or structured data content and writes them as new process variables into the workflow database. Upon receiving the updated results, the process runtime service continues to drive the workflow, enabling the intelligently generated results to automatically participate in subsequent approval or data-driven decision-making processes.

[0050] Optionally, to improve system reliability, this invention also configures a structured exception handling mechanism in the AIGC gateway service. When the external AIGC service times out, experiences network interruption, or returns an exception, the system automatically performs a retry operation; if it fails multiple times consecutively, the circuit breaker logic is triggered, and the current node is downgraded to a manual approval node or the default output logic is executed according to a preset policy. Simultaneously, exception information and call logs are recorded in the system monitoring module for subsequent auditing and optimization analysis.

[0051] In one embodiment of the present invention, the incremental data extraction service is used to subscribe to specific topics in a message queue, parse database change events captured and sent by the CDC connector, and filter, enrich, and distribute the parsed incremental data according to business rules, thereby transmitting changes at the database layer to the business logic layer or external systems in real time. This module is a key component for realizing system data decoupling and real-time linkage.

[0052] Specifically, the CDC connector is deployed on the workflow database to monitor database insert, update, and delete operations (INSERT, UPDATE, DELETE) and convert them into standardized JSON format change events. The incremental data extraction service subscribes to the message queue topic of this event via a consumer group mechanism to receive change data asynchronously. Once the service starts, it continuously pulls message streams from Kafka or an equivalent message broker and parses new events upon receipt. During the parsing phase, it extracts information such as table name, operation type, primary key, and changed field values ​​from the event to identify the specific database changes.

[0053] Here, after data parsing, the incremental data extraction service performs data filtering according to preset business monitoring rules. For example, it only monitors insertion events in the process history task table (ACT_HI_TASKINST) to capture the creation of new tasks, or it monitors update events in the process instance table (ACT_HI_PROCINST) to detect changes in process status. Once a matching event is identified, the service further enters the data enrichment stage: based on the process instance ID, task ID, or handler identifier carried in the event, it calls the user center or process runtime service interface to supplement business information such as applicant name, task name, and process type, thereby transforming the original database events into structured data with business semantics.

[0054] Furthermore, after data enrichment and format conversion, the service distributes the processed messages to downstream consumers, including message push services, statistical analysis services, or real-time monitoring dashboards, according to the configured data routing rules. For example, when a new task creation event is detected, the service generates a notification message (such as "Manager Li, you have a new pending approval task") and publishes it to the Topic used for notification distribution for consumption by downstream push modules; at the same time, task count information can also be pushed to a visualization dashboard for real-time data display.

[0055] Furthermore, to ensure high availability and scalability, the incremental data extraction service supports a parallel mechanism for consumer groups. When the system's data volume surges, service instances can be dynamically added to consume the same Topic, achieving horizontal scaling. If the service is temporarily interrupted or restarted, messages will accumulate in Kafka. After the service recovers, consumption can resume from the breakpoint, ensuring no data loss, thereby achieving asynchronous decoupling and elastic scaling of the system.

[0056] In this way, through the above design, the incremental data extraction service realizes real-time capture, asynchronous transmission and intelligent distribution of database change events, which greatly improves the data processing efficiency and real-time performance of the system and avoids the database load problem caused by traditional full polling.

[0057] In one embodiment of the present invention, the CDC (Change Data Capture) connector is deployed between the workflow database and the message queue to monitor the database's binary log in real time, capture data change events such as INSERT, UPDATE, and DELETE contained therein, and convert these events into a standardized message format and send them to the message queue, thereby realizing real-time publishing of database changes and asynchronous decoupling between systems.

[0058] Specifically, the CDC connector is implemented using Debezium or an equivalent CDC framework, establishing a persistent connection with the workflow database via a JDBC driver or native database log parsing. When the database performs any data write operation, the connector listens for the generated binary log entries; once a new change event is detected, it immediately extracts the table name, primary key field, operation type, and the changed field value, and encapsulates it into a structured event object. To ensure versatility and compatibility, the connector can encode the event data in JSON or Avro format, and append the event timestamp, transaction ID, and change source information.

[0059] Here, after the event is encapsulated, the CDC connector publishes the structured event message to the corresponding topic in a message queue (such as Kafka or RabbitMQ). The data carried in the message body includes complete business context identifiers, such as process instance ID, task ID, and field differences before and after modification, ensuring that downstream services can accurately identify and consume the event. To improve performance and reliability, the CDC connector supports asynchronous sending and breakpoint resumption mechanisms. When network jitter occurs or the message queue is temporarily unavailable, the connector caches the event locally and automatically retryes sending after recovery, ensuring that events are not lost or duplicated.

[0060] In addition, the CDC connector features event filtering and whitelisting mechanisms. The system can be configured to capture only specific tables or fields related to the process, such as the process instance table (ACT_HI_PROCINST) or the historical task table (ACT_HI_TASKINST), to reduce the amount of irrelevant data transmission. For abnormal events or duplicate transactions, the connector uses transaction ID deduplication to ensure the uniqueness and sequential consistency of message publication.

[0061] In this way, through the above technical solution, the CDC connector achieves real-time, stable, and non-intrusive data synchronization from the workflow database to the message queue. This module transforms the traditional passive query mode of the database into an event-driven mechanism, providing a reliable data source for incremental data extraction services. This enables the system to respond to database changes in milliseconds, greatly improving data transmission efficiency and real-time business linkage capabilities, while reducing the polling load on the core database and ensuring that the system still has high availability and scalability in high-concurrency environments.

[0062] As one possible implementation, the AIGC gateway service is specifically used for: when the process runtime service detects that the process execution has reached a preset AIGC task node, it synchronously receives a call request carrying the process instance identifier and task identifier according to the process definition; it calls the interface of the process runtime service according to the process instance identifier to obtain all process variables and context data of the process instance; it retrieves the corresponding preset prompt word template from the internally maintained prompt word template registry according to the call interface path, parses the variable placeholders in the preset prompt word template, matches and replaces them with the actual variable values; it assembles the system role settings, context data, and template content into a request body that meets the requirements of the target AIGC service interface, calls the interface of the external AIGC service to send the request body and waits for the return result; it parses the response data returned by the external AIGC service, extracts the generated content, and writes it into the workflow database as an update process variable.

[0063] In one embodiment of the present invention, the AIGC gateway service is used to respond to a call request and complete the entire process of AIGC generation task when the service detects that the process execution has reached a preset AIGC task node during process runtime. This module realizes intelligent collaboration between the workflow system and external AIGC services through operations such as process variable extraction, template matching and variable replacement, request body assembly, external AIGC call, and result writing back.

[0064] Specifically, when the process runtime service detects that the execution node of the current process instance is a preset AIGC task node, it synchronously sends a call request to the AIGC gateway service according to the process definition. The call request includes information such as the process instance identifier and task identifier (taskId), used to uniquely identify the currently running process context. Upon receiving the call request, the AIGC gateway service calls the interface provided by the process runtime service based on the process instance identifier to retrieve all process variables and context data of the process instance from the workflow database. The process variables include user input information, historical approval records, task execution status, and node attribute information, providing a contextual basis for subsequent intelligent generation.

[0065] Here, after successfully acquiring the process variables, the AIGC gateway service retrieves the corresponding preset prompt template from its internally maintained prompt template registry based on the call interface path or task node identifier. The template registry stores various Prompt templates configured for different task types. Each template contains a text structure with variable placeholders, such as "Please generate approval suggestions based on the following application information: {applicant} requests leave for {days} days due to {reason}". After parsing the variable placeholders in the template, the system matches them with the process variables according to variable names or path rules, and replaces the placeholders in the template with the corresponding actual variable values, forming context-sensitive natural language prompt content.

[0066] Furthermore, after completing the variable replacement, the AIGC gateway service assembles the system role settings, the context data, and the template content into a request body that conforms to the requirements of the target AIGC service interface. This request body typically uses a JSON structure and includes the model type, generation parameters (such as temperature and max_tokens), and the replaced Prompt text. The service then calls the HTTP or gRPC interface of the external AIGC service (such as a large language model interface), sends the request body, and enters a synchronous waiting state until it receives the generation result response.

[0067] Here, upon receiving response data from the external AIGC service, the AIGC gateway service performs structured parsing of the returned content. For JSON-formatted responses, the service parses the generated text, content confidence level, suggestion tags, or other additional metadata, and extracts the required generated content (such as approval comments, summary text, or document fragments). This generated content, after data validation, is encapsulated into new process variables and written back to the workflow database through the process runtime service's interface. The process runtime service then updates the process context accordingly and drives the process to continue flowing to the next node.

[0068] Preferably, to improve system reliability and robustness, the AIGC gateway service also incorporates a built-in exception handling mechanism. When an external AIGC service call fails, times out, or returns an error code, the system will automatically retry a preset number of times. If multiple retries still fail, the circuit breaker logic is triggered, and degradation processing is performed, such as switching the task to a manual approval node or outputting a default result. Exception events and call logs are simultaneously written to the system monitoring module to support subsequent auditing and performance optimization.

[0069] In this way, through the above technical solution, the AIGC gateway service realizes an end-to-end automated processing chain from process triggering, context extraction, template generation to intelligent output. This module not only improves the intelligence and dynamic adaptability of process nodes, but also enables the workflow system to drive business decisions and content generation with natural language, achieving deep integration between the process engine and AIGC service, and significantly enhancing the system's automation level and business processing efficiency.

[0070] As one possible implementation, the incremental data extraction service is specifically used for: subscribing to original topics in the message queue through a consumer group mechanism to receive database change events sent by the CDC connector; parsing the changed data in the database change events and only listening to records of preset tables or event types, including new task creation events in the process history task table and completion status update events in the process instance table for data filtering; enriching the filtered change data with entity business information to form actual business data; performing multi-target routing and distribution according to preset business configuration rules to distribute the actual business data corresponding to the same database change event to multiple downstream topics so that downstream consumers can trigger the business actions corresponding to the actual business data.

[0071] In one embodiment of the present invention, the incremental data extraction service is used to build an event-driven data channel between the workflow database and downstream business services. By parsing, filtering, enriching, and distributing database change events, it enables asynchronous data processing and business linkage within the system. This service is a crucial component of the entire microservice architecture for achieving real-time data transmission and system decoupling.

[0072] Specifically, the incremental data extraction service subscribes to the original topics in the message queue through a consumer group mechanism to receive database change events sent by the CDC connector. After capturing the database's binary log, the CDC connector encapsulates data insertion, update, or deletion operations into standardized messages and pushes them to the message queue. The incremental data extraction service, acting as a consumer of the message queue, continuously listens to the original topics, pulls these change events in real time, and parses their content. During the parsing phase, it extracts table names, operation types, timestamps, transaction identifiers, and field change values ​​from the events, thereby reconstructing the actual changes to the database.

[0073] Here, after parsing the changed data, the service enters the data filtering phase. To avoid irrelevant information interfering with system performance, the incremental data extraction service only listens to tables or event types closely related to the process's running status. For example, it listens for insert events in the process history task table (ACT_HI_TASKINST) to capture new task creation behavior; and it listens for update events in the process instance table (ACT_HI_PROCINST) to detect when the process status is updated to "complete". In this way, the system can accurately filter database events closely related to changes in business processes, reducing message processing load.

[0074] Furthermore, based on the filtered valid events, the service enters the data enrichment stage. Since the original change data only contains database fields (such as process instance ID, task ID, and handler identifier) ​​and lacks complete business semantic information, the incremental data extraction service calls the user center, process definition service, or other microservice interfaces based on these key fields to supplement business entity data, such as applicant name, task type, process name, and approver information. Through this process, the system transforms the original technical change data into structured data records with business meaning, forming actual business data that can be directly used in downstream business modules.

[0075] Here, after data enrichment, the incremental data extraction service performs multi-target routing and distribution according to preset business configuration rules. Internally, the service maintains a set of message routing strategies that can copy and distribute the actual business data corresponding to the same database change event to multiple downstream topics based on business type, event source, or process node attributes. For example, a "new task creation" event can be simultaneously distributed to the "message notification topic" to trigger an instant message push service, to the "statistical analysis topic" to update real-time monitoring dashboard data, and to the "audit log topic" to record operation traces. This distribution process is based on Kafka's publish-subscribe mechanism, enabling multiple downstream consumers to process different business logics in parallel.

[0076] Preferably, to improve the reliability and resilience of the system, the incremental data extraction service supports a dynamic scaling mechanism for consumer groups. When the amount of database changes increases, concurrent consumption can be achieved by starting multiple service instances, thereby improving event processing throughput. When the service is interrupted, messages will automatically accumulate in the message queue, and after the service recovers, processing can continue from the offset position of the last consumption, ensuring data transmission integrity and consistency.

[0077] In this way, through the above technical solution, the incremental data extraction service realizes a full-link asynchronous processing mechanism from database change capture to business event distribution. This not only significantly reduces the pressure of direct access to the core database, but also enables business modules to achieve real-time response in an event-driven manner, thereby improving the system's decoupling, scalability, and overall processing efficiency.

[0078] The above solution will now be described in detail below, with reference to specific implementation scenarios. (See also...) Figure 2 As shown, Figure 2 This illustration shows an interactive diagram of the workflow of a workflow engine system with a microservice architecture provided in an embodiment of the present disclosure.

[0079] Taking the employee leave approval process as an example, the overall process steps are as follows: the process consists of a start event, submitting the leave application (user task), project manager approval (user task), and an end event.

[0080] Phase 1: Leave Application Submission: Step 1: Employee Submits Application: The employee fills out the leave application form on the client (including fields such as leave type, start time, end time, and reason), and clicks submit. Step 2: Request Reaches Gateway: The client sends an HTTP request to the API gateway (e.g., / runtime / process-instances). Step 3: Routing to Runtime Service: The API gateway routes the request based on the path and forwards it to the process runtime service. Step 4: Retrieve Form Configuration: The process runtime service calls the dynamic form service to query the form field configuration and validation rules corresponding to the process (e.g., the end time must be later than the start time). Step 5: Return Validation Rules: The dynamic form service returns the configuration information. Step 6: Perform Data Validation: The process runtime service validates the form data submitted by the employee according to the returned rules; if the validation fails, an error is returned directly. Step 7: Create Process Instance: After successful validation, the process runtime service queries the corresponding process definition from the workflow database, creates a new process instance, and stores the form data as process variables in the database. Step 8: Generate Approval Task: According to the process definition, the next node is the "Project Manager Approval" user task. The engine will automatically generate this task and specify the approver as the employee's project manager. Step 9: CDC Capture Changes: Debezium monitors for new process instances and task data insertions in the database and immediately captures this change. Step 10: Publish Incremental Event: Debezium converts the change event into a JSON message and publishes it to a specific topic in Kafka. Downstream push messaging services can consume this event in real time and immediately send a to-do notification to the project manager.

[0081] Phase Two: Project Manager Approval: Step 11: Manager Views To-Do List: The project manager logs into the system or clicks a link in a notification to view the to-do list on the client. Step 12: Requests To-Do Tasks: The client sends a request to the API gateway to query to-do tasks. Step 13: Routes to Task Service: The API gateway routes the request to the user task service. Step 14: Query Task Information: The user task service queries the user's to-do tasks from the workflow database. Step 15: Returns Tasks and Data: Task information and corresponding form data (leave application details) are returned to the client and displayed to the project manager. Step 16: Manager Approval Operation: The project manager performs the approval operation (approve / reject) and can fill in approval comments. Step 17: Submits Approval Result: The approval submission request is sent via the API gateway. Step 18: Routes to Runtime Service: The API gateway ultimately routes the request to the process runtime service for processing. Step 19: Updates Process Variables: The service updates process variables (storing approval results and comments). Step 20: Drives the Process: Based on the approval result, the process is driven to the end node. Step 21: Complete the process: During process execution, the service updates the process status to "Completed" and persists it to the database. The entire process instance ends.

[0082] Phase 3: Process Completion and Data Synchronization: Step 22, Record the process completion event. Step 23, Publish the completion event.

[0083] This disclosure provides a workflow engine system based on a microservice architecture, comprising: a client, an API gateway, a microservice cluster including at least an AIGC gateway service and an incremental data extraction service, a message queue, a CDC connector, a workflow database, and an external AIGC service; the client is used to provide a graphical process designer and a dynamic form designer interface, and communicate with the API gateway; the API gateway is used to receive process creation requests sent by users through the client, and route the request information to the corresponding microservice in the microservice cluster according to the request path corresponding to the process creation request and a preset load balancing strategy; the AIGC gateway service is used to... When the task flow reaches the preset AIGC task node, the system responds to the corresponding call request, extracts process variables, maps them to a preset prompt word template, generates an AIGC call request, and calls the external AIGC service to obtain the generated content. The incremental data extraction service subscribes to the topic of the message queue, parses the database change events sent by the CDC connector, and distributes the changed data to downstream consumers. The CDC connector is deployed between the workflow database and the message queue, used to capture the database change events in the binary log of the workflow database, convert the database change events into message format, and send them to the message queue. By adopting a modular design based on a microservice architecture and introducing the AIGC intelligent gateway service and the CDC incremental data extraction mechanism, the workflow system achieves elastic scalability, enabling independent deployment and load balancing across different service nodes, avoiding single points of failure. Simultaneously, the CDC mechanism replaces full polling, achieving real-time capture and distribution of database change events, significantly reducing data processing latency and system resource consumption, thereby improving system stability and response efficiency while ensuring high concurrency performance.

[0084] Based on the same inventive concept, this disclosure also provides a workflow engine control method for a microservice architecture corresponding to a workflow engine system for a microservice architecture. The following is a detailed description of the workflow engine control method for a microservice architecture disclosed in this disclosure. Since the principle by which the method in this disclosure solves the problem is similar to the system described above, the implementation of the method can refer to the implementation of the system; repeated details will not be elaborated further.

[0085] The workflow engine control method for microservice architecture provided in this disclosure is applied to, for example, Figure 1The workflow engine system of the microservice architecture shown typically uses a computer device with certain computing capabilities as its execution entity. This computer device can include, for example, a terminal device, a server, or other processing equipment. The terminal device can be a user equipment (UE), mobile device, user terminal, terminal, cellular phone, cordless phone, personal digital assistant (PDA), handheld device, computing device, in-vehicle device, wearable device, etc. In some possible implementations, the workflow engine control method of this microservice architecture can be implemented by the processor calling computer-readable instructions stored in memory.

[0086] See Figure 3 The diagram shows a flowchart of a workflow engine control method for a microservice architecture provided in this embodiment of the present disclosure. The method includes steps S101 to S105, wherein: S101. In response to the process creation request sent by the user through the client, the process definition is routed to the process definition service via the API gateway, and the process definition is parsed and stored.

[0087] S102. When a process instance starts, the process definition is loaded from the workflow database and an instance is created.

[0088] S103. When the process reaches the AIGC service node, the AIGC gateway service is called to extract process variables and generate an AIGC call request based on the preset prompt word template. The external AIGC service is called to obtain the generated content and return it to the workflow engine system.

[0089] S104. When a user task node is generated or its status changes, the database change event is captured in real time through the CDC connector, the database change event is converted into a message and sent to the message queue.

[0090] S105. Subscribe to the topic of the message queue through the incremental data extraction service, parse, filter, enrich and transform the message content, and trigger notification or analysis tasks.

[0091] Those skilled in the art will understand that, in the above-described method of the specific implementation, the order in which each step is written does not imply a strict execution order and does not constitute any limitation on the implementation process. The specific execution order of each step should be determined by its function and possible internal logic.

[0092] This disclosure provides a workflow engine control method for a microservice architecture. In response to a user's workflow creation request sent via a client, the method routes the request to a workflow definition service via an API gateway, parses and stores the workflow definition. When a workflow instance starts, it loads the workflow definition from the workflow database and creates the instance. When the workflow execution reaches an AIGC service node, it calls the AIGC gateway service to extract workflow variables and generates an AIGC call request based on a preset prompt template. It then calls the external AIGC service to obtain the generated content and returns it to the workflow engine system. When a user task node is generated or its status changes, it captures database change events in real time through the CDC connector, converts the database change events into messages, and sends them to the message queue. It subscribes to topics in the message queue through the incremental data extraction service, parses, filters, enriches, and transforms the message content, and triggers notifications or analysis tasks. By adopting a modular design based on a microservice architecture and introducing AIGC intelligent gateway service and CDC incremental data extraction mechanism, the workflow system achieves elastic scalability, enabling independent deployment and load balancing across different service nodes, avoiding single points of failure. At the same time, the CDC mechanism replaces full polling, enabling real-time capture and distribution of database change events, significantly reducing data processing latency and system resource consumption, thereby improving system stability and response efficiency while ensuring high concurrency performance.

[0093] Corresponding to Figure 3 In addition to the workflow engine control method for microservice architectures, this disclosure also provides an electronic device 400, such as... Figure 4 The diagram shown is a structural schematic of an electronic device 400 provided in an embodiment of this disclosure, including: Processor 41, memory 42, and bus 43; memory 42 is used to store execution instructions, including main memory 421 and external memory 422; the main memory 421, also called internal memory, is used to temporarily store the computational data in processor 41, as well as the data exchanged with external memory 422 such as hard disk. Processor 41 exchanges data with external memory 422 through main memory 421. When the electronic device 400 is running, processor 41 and memory 42 communicate through bus 43, enabling processor 41 to execute... Figure 3 The steps of the workflow engine control method in a microservice architecture.

[0094] This disclosure also provides a computer-readable storage medium storing a computer program that, when executed by a processor, performs the steps of the workflow engine control method for a microservice architecture described in the above method embodiments. The storage medium can be a volatile or non-volatile computer-readable storage medium.

[0095] This disclosure also provides a computer program product, which includes computer instructions. When the computer instructions are executed by a processor, they can perform the steps of the workflow engine control method for the microservice architecture described in the above method embodiments. For details, please refer to the above method embodiments, which will not be repeated here.

[0096] The aforementioned computer program product can be implemented through hardware, software, or a combination thereof. In one optional embodiment, the computer program product is specifically embodied in a computer storage medium; in another optional embodiment, the computer program product is specifically embodied in a software product, such as a software development kit (SDK), etc.

[0097] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working process of the device described above can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here. In the several embodiments provided in this disclosure, it should be understood that the disclosed device and method can be implemented in other ways. The device embodiments described above are merely illustrative. For example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. Furthermore, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Another point is that the displayed or discussed mutual coupling or direct coupling or communication connection may be through some communication interfaces; the indirect coupling or communication connection of devices or units may be electrical, mechanical, or other forms.

[0098] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0099] In addition, the functional units in the various embodiments of this disclosure 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.

[0100] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a processor-executable, non-volatile, computer-readable storage medium. Based on this understanding, the technical solution of this disclosure, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this disclosure. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0101] Finally, it should be noted that the above-described embodiments are merely specific implementations of this disclosure, used to illustrate the technical solutions of this disclosure, and not to limit it. The protection scope of this disclosure is not limited thereto. Although this disclosure has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that any person skilled in the art can still modify or easily conceive of changes to the technical solutions described in the foregoing embodiments, or make equivalent substitutions for some of the technical features, within the scope of the technology disclosed in this disclosure. Such modifications, changes, or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this disclosure, and should all be covered within the protection scope of this disclosure. Therefore, the protection scope of this disclosure should be determined by the protection scope of the claims.

Claims

1. A workflow engine system with a microservice architecture, characterized in that, include: Client, API gateway, microservice cluster including at least AIGC gateway service and incremental data extraction service, message queue, CDC connector, workflow database and external AIGC service; The client is used to provide a graphical process designer and a dynamic form designer interface, and to communicate with the API gateway; The API gateway is used to receive process creation requests sent by users through the client, and to route the process creation requests to the corresponding microservices in the microservice cluster according to the request path corresponding to the process creation request and the preset load balancing strategy. The AIGC gateway service is used to extract process variables and map them with a preset prompt word template in response to the corresponding call request when the task process is executed to the preset AIGC task node, generate an AIGC call request and call the external AIGC service to obtain the generated content. The incremental data extraction service is used to subscribe to the topics of the message queue, parse the database change events sent by the CDC connector, and distribute the changed data to downstream consumers. The CDC connector is deployed between the workflow database and the message queue to capture database change events in the binary log of the workflow database and convert the database change events into message format and send them to the message queue. The microservice cluster also includes process definition services and process runtime services; The process definition service is used to receive process deployment requests from the API gateway, parse the process model file uploaded by the client to obtain the process model, and persist the process model to the workflow database. The process runtime service is used to receive a process instance start request from the API gateway, load a process definition from the workflow database, create a process instance and drive the process instance to flow according to the process definition, generate runtime data and store it in the workflow database.

2. The workflow engine system for a microservice architecture according to claim 1, characterized in that, The AIGC gateway service is specifically used for: When the process runtime service detects that the process has reached the preset AIGC task node, it synchronously receives the call request carrying the process instance identifier and the task identifier according to the process definition; Call the interface of the process runtime service based on the process instance identifier to obtain all the process variables and context data of the process instance; According to the call interface path, the corresponding preset prompt word template is retrieved from the internally maintained prompt word template registry, the variable placeholders in the preset prompt word template are parsed, and the process variables are matched and replaced, and the variable placeholders are replaced with actual variable values. The system role settings, the context data, and the template content are assembled into a request body that meets the requirements of the target AIGC service interface. The interface of the external AIGC service is called to send the request body and wait for the return result. The response data returned by the external AIGC service is parsed, the generated content is extracted, and written into the workflow database as an update process variable.

3. The workflow engine system for a microservice architecture according to claim 1, characterized in that, The incremental data extraction service is specifically used for: Subscribe to the original topic in the message queue through the consumer group mechanism to receive the database change event sent by the CDC connector; Parse the changed data in the database change event, and only listen to records of preset tables or event types, including new task creation events in the process history task table and completion status update events in the process instance table for data filtering; After enriching the filtered change data with entity business information to form actual business data, multi-target routing and distribution are performed according to preset business configuration rules to distribute the actual business data corresponding to the same database change event to multiple downstream topics, so that the downstream consumers can trigger the business actions corresponding to the actual business data.

4. The workflow engine system for a microservice architecture according to claim 1, characterized in that: When the incremental data extraction service crashes or restarts, messages are automatically piled up in the message queue, and consumption will resume from the breakpoint after the incremental data extraction service recovers. When the amount of data changes increases, the service instances of the incremental data extraction service are automatically added to consume the same topic in the message queue in parallel.

5. The workflow engine system for a microservice architecture according to claim 1, characterized in that, The microservice cluster also includes user task service and dynamic form service; The user task service is used to generate user-related task records and store them in the workflow database; The dynamic form service is used to store form field configuration information and associate it with the process model. During task execution, it provides a form rendering interface for the user task service to call and obtain the form structure, and then dynamically renders the form interface in the client.

6. A workflow engine control method for a microservice architecture, characterized in that, The method, applied to a workflow engine system with a microservice architecture as described in any one of claims 1-5, comprises: In response to a process creation request sent by a user through the client, the process is routed to the process definition service via the API gateway, and the process definition is parsed and stored. When a process instance starts, the process definition is loaded from the workflow database and the instance is created. When the process reaches the AIGC service node, the AIGC gateway service is called to extract process variables and generate an AIGC call request based on the preset prompt word template. The external AIGC service is then called to obtain the generated content and return it to the workflow engine system. When a user task node is generated or its status changes, the database change event is captured in real time through the CDC connector, the database change event is converted into a message and sent to the message queue; The incremental data extraction service subscribes to the topics of the message queue, parses, filters, enriches and transforms the message content, and triggers notifications or analysis tasks.

7. An electronic device, characterized in that, include: The device includes a processor, a memory, and a bus. The memory stores machine-readable instructions executable by the processor. When the electronic device is running, the processor communicates with the memory via the bus. When the machine-readable instructions are executed by the processor, they perform the steps of the workflow engine control method for a microservice architecture as described in claim 6.

8. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, performs the steps of the workflow engine control method for a microservice architecture as described in claim 7.

9. A computer program product comprising computer instructions, characterized in that, When the computer instructions are executed by the processor, they implement the steps of the workflow engine control method for the microservice architecture as described in claim 6.

Images