Data processing method, system and equipment based on business process management and medium
By constructing an abstraction-driven business process model and multi-protocol standardized interfaces, the problems of code redundancy and high maintenance costs in the business process management system under the SaaS model are solved, achieving efficient and flexible business process management, adapting to diverse customer needs and heterogeneous systems, and improving user experience and operational efficiency.
Patent Information
- Application Number
- CN202510753434.7
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-06-06
- Publication Date
- 2025-10-28
AI Technical Summary
Under the existing SaaS model, the business process management system needs to be customized for each subsystem, resulting in a surge in code volume and high maintenance costs. It is difficult to quickly adapt to diverse customer needs, and the process direction cannot be dynamically adjusted. It has poor compatibility and is difficult to adapt to the diverse interfaces of heterogeneous systems.
Construct an abstraction layer-driven business process model, configure multi-protocol standardized interfaces, shield the business logic of subsystems through the abstraction layer, generate process instances that match business scenarios, use a task control engine to manage form status transitions and node jumps, use a rule engine to parse dynamic variables to adjust process branch paths, and deploy event listeners at key nodes to trigger external service calls, forming an end-to-end automated closed loop.
It achieves high flexibility and automation in business process management, avoids duplicate code development, ensures communication compatibility between heterogeneous systems, quickly responds to business needs, and improves user experience consistency and operational efficiency.
Smart Images

Figure CN120848872A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of business process management technology, and in particular to a data processing method, system, device and medium based on business process management. Background Technology
[0002] In human resources systems, business processes are highly uncertain and volatile. Under the SaaS model, each client's business processes are unique. Faced with complex approval processes and workflow-related tasks, the ability to dynamically support all business processes with a single system becomes a key factor in enterprise development efficiency and successful client deployment.
[0003] In related technologies, the use of fixed process design and system coupling architecture, especially in the SaaS model, presents the following significant problems in the face of diverse customer needs and heterogeneous subsystems: (1) Traditional BPM (Business Process Management) systems require customized interfaces to be developed for each subsystem, resulting in a surge in code volume. For example, when a customer needs to integrate BPM functions into its pre-employment system and payroll system, the development team needs to write adaptation logic for the two systems separately, resulting in code duplication and poor compatibility. In addition, subsequent additions of subsystems require repeated development, and maintenance costs increase exponentially; (2) It usually forces all subsystems to use a unified form template, which conflicts with the interface style of the original system; (3) It relies on pre-fixed branch logic and cannot dynamically adjust the process flow according to real-time business data (such as amount, department, approval result); the business processes of different customers (tenants) are significantly different, but traditional systems lack template configuration capabilities; (4) It only supports a single communication protocol and is difficult to adapt to the diverse interfaces of heterogeneous systems. Summary of the Invention
[0004] This application provides a data processing method, system, device, and medium based on business process management to solve the problems in related technologies, such as the need for customized development for different subsystems in business process management, which leads to code redundancy, high maintenance costs, and difficulty in quickly adapting to diverse customer needs.
[0005] The first aspect of this application provides a data processing method based on business process management, comprising the following steps: constructing an abstraction layer-driven business process model and configuring a multi-protocol standardized interface; generating a process instance matching the business scenario based on the abstraction layer-driven business process model and the multi-protocol standardized interface, and distributing the task to the target client according to task requirements; managing the form state transition and node jump logic according to the task control engine, parsing dynamic variables in the business data through a rule engine, and adjusting the process branch path and node routing strategy by matching preset condition rules according to the dynamic variables; deploying event listeners to monitor the process through key process nodes, and triggering external service call operations to form an end-to-end automated closed loop when the process reaches a specified node.
[0006] Optionally, the construction of the business process model includes: generating a deployable process definition file containing process nodes, routing rules, organizational permissions, and form bindings based on the business process logic defined in the abstract layer and the business processes of the abstract layer shielded subsystems.
[0007] Optionally, the multi-protocol standardized interface includes a process initiation interface, a task approval interface, and a process termination interface, and the interface request is dynamically converted into a communication protocol supported by the target subsystem through a protocol adaptation unit.
[0008] Optionally, after deploying event listeners at key nodes in the process, the following steps are included: triggering preset actions when the process starts, ends, or when approval is granted or rejected. The preset actions include calling external system interfaces, sending email notifications, or updating business data.
[0009] Optionally, it also includes: configuring the external data interface address, parameter mapping relationship and response parsing rules; populating form controls with business data, dynamically loading drop-down options, automatically calculating fields or displaying conditional content.
[0010] Optionally, it also includes: secondary configuration of the standard process template library according to user needs, wherein the secondary configuration includes modifying node rules, adjusting form layout or redefining interface binding relationships, and the standard process template library supports template cloning, version rollback and hierarchical permission management.
[0011] A second aspect of this application provides a data processing system based on business process management, comprising: an abstraction layer module for constructing a business process model independent of the business logic of subsystems; an interface configuration module for defining standardized interfaces for each subsystem and communicating with the business process management system engine through the interfaces; a process execution engine for generating instances based on the business process model and controlling task routing and node jumps; a form rendering module, decoupled from the process execution engine, for rendering form pages independently by the subsystems; a dynamic branching module for dynamically adjusting process branching logic based on business data variables; and an event-driven module for executing preset external service calls or notification operations when a process node triggers an event.
[0012] A third aspect of this application provides an electronic device, including: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to perform the data processing method based on business process management as described in the above embodiments.
[0013] A fourth aspect of this application provides a computer-readable storage medium having a computer program stored thereon, which is executed by a processor to perform the data processing method based on business process management as described in the above embodiments.
[0014] A fifth aspect of this application provides a computer program product, including a computer program or instructions, which, when executed, implement the data processing method based on business process management as described in the above embodiments.
[0015] Therefore, this application has at least the following beneficial effects:
[0016] This application embodiment can construct an abstraction layer-driven business process model and configure multi-protocol standardized interfaces. The abstraction layer shields the specific business logic of subsystems, making the business process model independent of the underlying system implementation, thus avoiding redundant code development. Based on the abstraction layer-driven business process model and multi-protocol standardized interfaces, it generates process instances matching the business scenario and distributes tasks to target clients according to task requirements. The protocol adaptation unit dynamically converts the interface request format to ensure compatibility of communication between heterogeneous systems. Based on the abstraction layer model and interface configuration, it generates process instances matching the business scenario in real time to quickly respond to business needs. The task control engine manages the form status flow. The transition and node jump logic uses a rule engine to parse dynamic variables in business data and match preset condition rules based on these dynamic variables to adjust process branch paths and node routing strategies. The subsystem autonomously renders form pages, retaining the original interaction style and improving user experience consistency. The process engine manages form state transitions and node jumps to ensure logical continuity. Event listeners are deployed at key process nodes to monitor the process and trigger external service calls when the process reaches a specified node, forming an end-to-end automated closed loop. Through abstract layer modeling, multi-protocol interface adaptation, rule engine-driven operation, and event listening mechanism, a high degree of flexibility and automation in business process management is achieved.
[0017] Additional aspects and advantages of this application will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of this application. Attached Figure Description
[0018] The above and / or additional aspects and advantages of this application will become apparent and readily understood from the following description of the embodiments taken in conjunction with the accompanying drawings, wherein:
[0019] Figure 1 This is a flowchart illustrating a data processing method based on business process management according to an embodiment of this application;
[0020] Figure 2 This is a diagram illustrating the abstraction layer modeling and protocol adaptation architecture provided according to embodiments of this application.
[0021] Figure 3 This is a schematic diagram illustrating the dynamic generation and task distribution of a process instance provided in the embodiments of this application;
[0022] Figure 4 This is a schematic diagram illustrating form rendering and data binding according to an embodiment of this application;
[0023] Figure 5 This is a logic diagram for dynamic branch adjustment driven by a rule engine according to embodiments of this application;
[0024] Figure 6This is a schematic diagram of event listening and external service invocation according to an embodiment of this application;
[0025] Figure 7 This is a schematic diagram of the multi-tenant template library management interface provided according to an embodiment of this application;
[0026] Figure 8 This is an example diagram illustrating the dynamic linkage and condition display of forms according to embodiments of this application;
[0027] Figure 9 This is a schematic diagram of a process monitoring and data analysis panel provided according to an embodiment of this application;
[0028] Figure 10 This is a flowchart of the protocol adaptation unit provided according to an embodiment of this application;
[0029] Figure 11 This is a schematic diagram of the dynamic branch and node routing strategy provided according to an embodiment of this application;
[0030] Figure 12 This is a schematic diagram illustrating the selection of approvers according to an embodiment of this application;
[0031] Figure 13 This is an example diagram of a data processing system based on business process management provided according to an embodiment of this application;
[0032] Figure 14 This is a schematic diagram of the structure of an electronic device provided according to an embodiment of this application. Detailed Implementation
[0033] The embodiments of this application are described in detail below. Examples of these embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and intended to explain this application, and should not be construed as limiting this application.
[0034] In human resources systems, business processes are highly uncertain and volatile. In a SaaS model, each client's business processes are unique. Faced with complex approval processes and workflow-related tasks, the ability to dynamically support all business processes with a single system becomes a key factor in enterprise development efficiency and successful client deployment.
[0035] CDP developed EBMS based on BPM. While BPM is used internally within existing systems, implementing business processes on fixed modules according to customer requirements, EBMS's biggest advantage is that it allows all existing systems to have BPM functionality without developer intervention. Subsystems that previously couldn't support workflows, such as pre-employment, HR, e-commerce, social security, and payroll subsystems, now have customizable business processes through EBMS integration. This includes online editing and approval of business processes, significantly improving customer deployment speed. Regardless of the differences between customers and systems, EBMS can mask these differences through the system's external interfaces and flowchart development.
[0036] Features: EBMS requires integration with a large number of systems. Customizing the code for each system would lead to a surge in code size and maintainability issues. How can these systems be connected without development? EBMS provides high-level abstraction services. The entire framework is built on top of this abstraction layer, while the specific business processes are implemented above the interface layer. The basic architecture of EBMS does not depend on the logic of the integrated systems. Therefore, adding any business logic or integrating with any new system does not require modifying the EBMS code. Only the sub-business systems need to implement the interfaces required by EBMS.
[0037] EBMS integrates with a wide variety of systems. Some business systems have form pages, or want to continue using their own form styles, or their form styles differ significantly from EBMS's. From its inception, EBMS separated the form engine from the application engine, allowing the engine to run independently. Forms can be rendered by the business subsystems themselves, while the form flow is controlled by EBMS. This is a significant innovation compared to other BPM solutions on the market.
[0038] EBMS provides external interfaces, including interfaces for initiating a process, approving approval, rejecting approval, and ending a process. Third-party systems can interact with EBMS by calling these interfaces according to their business processes.
[0039] EBMS can act as a backend engine. As long as a subsystem has the ability to call interfaces, it can have workflow capabilities. In theory, this would allow all systems on the market to perform online approval processes.
[0040] The following description, with reference to the accompanying drawings, describes a data processing method, system, device, and medium based on business process management according to embodiments of this application.
[0041] Specifically, Figure 1 This is a flowchart illustrating a data processing method based on business process management, provided as an embodiment of this application.
[0042] like Figure 1As shown, this data processing method based on business process management includes the following steps:
[0043] In step S101, an abstraction layer-driven business process model is constructed and a multi-protocol standardized interface is configured.
[0044] The multi-protocol standardized interfaces include process initiation interfaces, task approval interfaces, and process termination interfaces, and the interface requests are dynamically converted into communication protocols supported by the target subsystem through the protocol adaptation unit.
[0045] It is understood that the embodiments of this application can construct an abstraction layer-driven business process model and configure multi-protocol standardized interfaces to facilitate subsequent implementation.
[0046] It should be noted that the abstraction layer decouples business process logic from the implementation of specific subsystems by defining unified process node types (such as approval nodes, automatic task nodes, and gateway nodes), routing rules (conditional branching, parallel execution), and interface specifications (startup, approval, and termination interfaces). For example, regardless of whether the subsystem is an HR system or a finance system, the approval logic is defined through the "approval node" of the abstraction layer, and the subsystem only needs to implement the specific logic of the "approval interface".
[0047] It provides a drag-and-drop flowchart designer, allowing business users to directly draw processes in the abstract layer and bind node types, approvers, and form relationships. For example, designing an "Employee Leave Application Process" that includes "Submit Application → Department Approval → HR Filing" nodes will automatically generate an executable process template in the abstract layer.
[0048] The abstraction layer, driven by metadata, supports dynamic loading of subsystem interface implementations at runtime. When adding a new subsystem, only the interfaces defined in the abstraction layer need to be implemented; the core process model does not need to be modified.
[0049] In this embodiment of the application, the construction of the business process model includes: generating a deployable process definition file containing process nodes, routing rules, organizational permissions, and form bindings based on the business process logic defined by the abstract layer and the business processes of the abstract layer shielded subsystems.
[0050] It is understood that, according to the embodiments of this application, the business process logic defined by the abstract layer and the business processes of the abstract layer shielded subsystems can be used to generate a deployable process definition file containing process nodes, routing rules, organizational permissions and form bindings, thereby achieving highly flexible, rapid deployment and low-cost maintenance of business processes.
[0051] It should be noted that the abstract layer design: As an intermediate layer, the abstract layer defines unified business process elements, including node types (such as approval nodes, automatic task nodes, and parallel gateways), routing rules (conditional branches and timeout handling), organizational permission models (roles and user groups), and form binding rules.
[0052] Logical isolation: Business personnel design process logic at an abstract layer using visual tools (such as drag-and-drop flowchart editors) without needing to understand the technical implementation details of the subsystems. For example, when designing a "procurement approval process," only the node sequence and condition rules of "submit application → department approval → financial review → procurement execution" need to be defined.
[0053] Standardized interface exposure: The abstraction layer exposes a unified interface to subsystems, shielding them from their internal implementations. For example, the "onboarding approval" function in the HR system and the "reimbursement approval" function in the finance system both interact with the BPM engine through the same interface specification.
[0054] Metadata-driven: The business logic of a subsystem is completed by implementing the abstraction layer interface. For example, the human resources system implements the target interface to return a list of approvers, while the finance system implements the same interface but returns the finance-related personnel.
[0055] File content structure: The generated process definition file (e.g., XML / JSON format) includes: Process nodes: node type, executor / role, timeout policy; Routing rules: conditional expressions, parallel branch configuration; Organizational permissions: the binding relationship between roles and tasks (e.g., "department manager" can approve applications from their department); Form binding: the form template and data source associated with each node (e.g., API address, parameter mapping rules). Dynamic loading mechanism: The BPM engine parses the process definition file at runtime and dynamically generates executable process instances.
[0056] In step S102, a process instance matching the business scenario is generated based on the business process model driven by the abstraction layer and the multi-protocol standardized interface, and the task is distributed to the target client according to the task requirements.
[0057] It is understood that the embodiments of this application can generate process instances that match business scenarios based on the abstraction layer-driven business process model and multi-protocol standardized interfaces, and distribute tasks to target clients according to task requirements. Through abstraction layer-driven dynamic modeling and multi-protocol intelligent task distribution, the core bottlenecks of traditional BPM systems in terms of flexibility, compatibility and efficiency are solved. It is suitable for complex scenarios of high concurrency, multi-tenancy and heterogeneous system integration, and provides efficient and reliable technical support for enterprise digital transformation.
[0058] It's important to note the model instantiation mechanism: based on the business process model (BPMN 2.0 standard) defined in the abstract layer, and combined with current business scenario parameters (such as tenant ID and business type), it dynamically generates executable process instances. Example: In a SaaS multi-tenant model, an "Employee Leave Application Process" instance is generated for tenant A, and a "Purchase Approval Process" instance is generated for tenant B. Both share the same abstract model but have different parameters.
[0059] The protocol adaptation unit converts the interaction requests of the process instance into a protocol format supported by the target subsystem (e.g., encapsulating an HTTP request into a Kafka message). Example: When a process instance needs to call the approval interface of the HR system, the protocol adaptation unit automatically generates a gRPC request based on the HR system's protocol type (e.g., RPC).
[0060] Task routing rule base: Defines multi-dimensional routing strategies, including: Business priority: High-priority tasks (such as urgent procurement) are assigned first; Execution end load: Dynamically allocated based on the current task queue length on the client; Roles and permissions: Tasks are only distributed to users or systems with processing permissions. Example: In the financial reimbursement process, tasks exceeding 10,000 yuan are automatically assigned to the CFO's client, while lower-amount tasks are assigned to the department manager's client.
[0061] Real-time feedback mechanism: After the client processes the task, it returns the result through a standardized interface, and the process instance updates the status in real time.
[0062] For example, scenario: e-commerce order risk control process
[0063] Process instance generation:
[0064] An instance of "order submission → risk detection → payment processing → logistics allocation" is generated based on the abstract layer model. The protocol adaptation unit interfaces with the payment system (HTTP), risk control system (gRPC), and logistics system (Kafka).
[0065] Task distribution logic:
[0066] Risk control detection tasks are prioritized and assigned to high-performance server clusters; payment tasks are assigned to the corresponding payment gateways according to merchant priority.
[0067] Results data:
[0068] Throughput: Order processing capacity increased from 1,000 to 5,000 per second; Risk Interception: Dynamic risk control rules improve the efficiency of intercepting fraudulent orders by 60%; Resource Costs: Server resource usage reduced by 30%; Exception Handling: If the client does not respond within a timeout period, the task is automatically upgraded or reassigned.
[0069] In step S103, according to the task control engine's management form status transition and node jump logic, the dynamic variables in the business data are parsed by the rule engine, and the process branch paths and node routing strategies are adjusted by matching preset condition rules according to the dynamic variables.
[0070] It is understood that the embodiments of this application can manage form status and node jumps through the task control engine, and combine the rule engine to parse dynamic variables and adjust process strategies, thereby realizing the intelligence, dynamism and high elasticity of business processes.
[0071] It's important to note that form lifecycle management defines the form's status at different stages (e.g., "Pending," "Submitted," "Approved," "Rejected") and monitors status changes through a task control engine. For example, in a procurement application process, when an employee submits a form, the status changes from "Pending" to "Submitted," triggering a task assignment to the department manager for approval.
[0072] Distributed transactions or optimistic locking mechanisms are used to ensure the integrity and consistency of form data when it flows across nodes. For example, when an approver modifies a form field, the system automatically detects concurrency conflicts and prompts for resolution.
[0073] Conditional redirection rules: Pre-set redirection conditions in the process definition (such as "Approval approved → Next node" or "Approval rejected → Return for modification"). Supports complex logic combinations, such as: "Amount > 10,000 and Department = Finance Department → Trigger CFO approval".
[0074] Real-time routing adjustment: The redirection path is dynamically adjusted based on runtime business data (such as approval comments and feedback from external systems). For example, if the approver reports "supplementary materials are needed," the process will automatically redirect to the "materials completion" node instead of terminating directly.
[0075] Dynamic variable types and sources: Business variables: amount, department, approval result, etc.; Environmental variables: current system load, approver availability status; External data: credit score returned by third-party system, inventory quantity.
[0076] Based on the output of the rules engine, new process branches are generated in real time. For example, when a "high-risk order" is detected, a "risk control review" node is inserted.
[0077] Based on a resource load balancing strategy, tasks are dynamically allocated to available approvers. For example, if an approver's task queue is full, the task is automatically routed to other available personnel.
[0078] In step S104, event listeners are deployed at key nodes of the process to monitor the process, and when the process reaches a specified node, external service calls are triggered to form an end-to-end automated closed loop.
[0079] It is understood that the embodiments of this application can drive external service calls through event listeners, thereby realizing end-to-end automated closed loop of business processes. Enterprises can achieve full-link management of complex businesses with "zero human intervention", significantly improving operational efficiency and customer experience.
[0080] It should be noted that key node definition involves marking key nodes (such as process initiation, approval completion, timeout handling, and process termination) in the business process model and binding event listeners. Example: In the "Procurement Approval Process," define "Financial Review Completed" as a key node, triggering subsequent contract generation and payment operations.
[0081] Event Listener Functionality: Real-time Monitoring: Monitors the status of process instances and captures node arrival events (such as node entry, departure, and exceptions). Asynchronous Triggering: Asynchronously calls external services via message queues (such as Kafka and RabbitMQ) to avoid blocking the main process. Retry and Circuit Breaking: If an external service call fails, it automatically retryes (up to 3 times) or triggers a circuit breaker mechanism (such as transferring the call to manual handling).
[0082] Service types and integrations: Notification services: sending emails, SMS messages, and WeChat messages (such as approval result notifications).
[0083] Data manipulation services: Call the database interface to update the status (e.g., change the order status to "paid").
[0084] Business-related services: Triggering third-party system interfaces (such as calling bank interfaces for payment, or generating purchase orders in ERP systems). AI-driven decision-making services: Integrating AI models for risk prediction (such as calling risk control models to assess transaction risks).
[0085] Closed-loop logic design: At the process termination node, summarize and archive the execution data (e.g., generate audit logs); optimize the process model based on the execution results (e.g., analyze bottleneck nodes through machine learning).
[0086] In this embodiment of the application, after deploying event listeners at key nodes of the process, the following actions are included: triggering preset actions when the process starts, ends, or is approved or rejected. These preset actions include calling external system interfaces, sending email notifications, or updating business data.
[0087] Among them, preset actions refer to a series of automated operations predefined at key nodes of the process (such as start, end, approval / rejection) to respond to changes in process status and achieve business closure.
[0088] It is understood that the embodiments of this application can trigger preset actions when the process starts, ends, or is approved or rejected, which can achieve automated management of complex business processes at a lower cost and higher efficiency, significantly improving competitiveness and customer satisfaction.
[0089] For example, Scenario 1: Human Resources Onboarding Process
[0090] Preset action configuration:
[0091] At the start of the process: the HR system interface is called to create employee files;
[0092] Upon approval: The IT system interface is invoked to assign an email address / account and a welcome email is sent;
[0093] At the end of the process: synchronize the data to the access control system and grant permissions.
[0094] Results data: Processing time: reduced from 3 days to 1 hour; Error rate: account duplication caused by manual operation was eliminated; Employee experience: employees received full privileges on the first day of employment, and satisfaction increased by 95%.
[0095] Scenario 2: E-commerce return and refund process
[0096] Preset action configuration:
[0097] When a return request is submitted: the inventory system interface is called to lock the product;
[0098] When the refund is approved: the payment interface is used to refund the money to the original payment method, and an SMS notification is sent to the user;
[0099] At the end of the process: Update the user after-sales records in the CRM system.
[0100] Results data: Processing speed: Refund arrival time reduced from 72 hours to 10 minutes; Customer service pressure: Automated processing reduced manual inquiries by 70%; User retention rate: Efficient after-sales service increased repurchase rate by 15%.
[0101] In this embodiment, the method further includes: configuring the external data interface address, parameter mapping relationship and response parsing rules; filling the form control with business data, dynamically loading drop-down options, automatically calculating fields or displaying conditional content.
[0102] It is understood that the embodiments of this application can configure external data interface addresses, parameter mapping relationships, and response parsing rules; populate form controls with business data, dynamically load drop-down options, automatically calculate fields, or display conditional content. This allows for the construction of intelligent form systems at lower cost and higher efficiency, significantly improving the agility of business processes and data-driven decision-making capabilities.
[0103] In this embodiment of the application, it also includes: secondary configuration of the standard process template library according to user needs, wherein the secondary configuration includes modifying node rules, adjusting form layout or redefining interface binding relationship, and the standard process template library supports template cloning, version rollback and hierarchical permission management.
[0104] It should be noted that the interface address definition is the access address for registering external data sources in the system. It defines the association between the request parameters of the external interface and form controls. For example, in the form, the "Department" dropdown box calls the HR system interface, passing the parameter `company_id = 1001`.
[0105] It is understood that the embodiments of this application can be reconfigured according to user needs. This reconfiguration includes modifying node rules, adjusting form layouts, or redefining interface binding relationships. The standard process template library supports template cloning, version rollback, and hierarchical permission management.
[0106] It should be noted that the implementation method for modifying node rules is as follows: users adjust the order, conditional branches, and execution logic of process nodes through a visual interface (such as a flowchart editor). Example: In the standard "Leave Approval Template", add a "Department Director Approval" node and set conditional rules (such as triggering when the number of leave days > 5 days).
[0107] Adjust the form layout: Use the drag-and-drop form designer to customize field arrangement, control types (input boxes, drop-down lists, file uploads), and styles (colors, fonts). Example: Change the "Expense Details" section of the expense reimbursement form from a horizontal table to a vertical list, and add an image upload area.
[0108] Redefine interface binding relationships: Reconfigure the external data interface addresses, parameters, and response parsing rules bound to form controls or process nodes. Example: Switch the original "Department List Interface" from the HR system to the HR SaaS service provider interface and update the parameter mapping logic.
[0109] According to the data processing method based on business process management proposed in this application, an abstraction layer-driven business process model is constructed and multi-protocol standardized interfaces are configured. The abstraction layer shields the specific business logic of subsystems, ensuring the business process model is implemented independently of the underlying system, thus avoiding redundant code development. Based on the abstraction layer-driven business process model and multi-protocol standardized interfaces, process instances matching the business scenario are generated, and tasks are distributed to target clients according to task requirements. A protocol adaptation unit dynamically converts the interface request format to ensure compatibility between heterogeneous systems. Based on the abstraction layer model and interface configuration, process instances matching the business scenario are generated in real time to quickly respond to business needs. Based on task control... The rule engine manages the form state transitions and node jump logic. It parses dynamic variables in business data through a rule engine and matches preset condition rules to adjust process branch paths and node routing strategies based on these dynamic variables. The subsystem autonomously renders form pages, preserving the original interaction style and improving user experience consistency. The process engine manages form state transitions and node jumps to ensure logical continuity. Event listeners are deployed at key process nodes to monitor the process and trigger external service calls when the process reaches a specified node, forming an end-to-end automated closed loop. Through abstract layer modeling, multi-protocol interface adaptation, rule engine-driven operation, and event listening mechanism, a high degree of flexibility and automation in business process management is achieved.
[0110] The following will combine the embodiments and Figures 2-12 The data processing method based on business process management in this application is described in detail below:
[0111] (1) Process Management
[0112] 1. Business Process Modeling
[0113] 1. Business Process Analysis Model (for Business Personnel)
[0114] 2. Executable business process model
[0115] 3. Organization and application models
[0116] 2. Business process automation
[0117] 1. Execute the key features of the business process model, providing an operational environment for process execution and monitoring.
[0118] 2. Routing rules for automatically delivering task executors (human / machine)
[0119] 3. An event is triggered by a specified person / machine at a specified time / action to execute business logic and EAI.
[0120] 3. Business process architecture and standards
[0121] 1. Workflow System Architecture
[0122] 2. Modeling language standards,
[0123] 3. Model-driven architecture, F specification
[0124] 4. Service-oriented architecture
[0125] 4. Business Rules
[0126] 1. The engine used to execute rules
[0127] 2. Rule design capability
[0128] Business process management (BPM) is a systematic approach centered on constructing standardized, end-to-end, high-performing business processes to continuously improve organizational business performance. Through a process manager, it supports drawing flowcharts, deploying flowcharts, designing process forms, controlling form logic, binding form variables, and binding forms to processes. Business personnel can open the process management interface to create new processes for a company, draw process flow diagrams according to business rules, bind approvers, and bind forms to each node. Forms can be drawn for each node, and form fields can be customized to bind the final business output content. After the process is defined, it can be deployed. The deployed process takes effect immediately.
[0129] (2) Form Design
[0130] Ecosaas-BPM supports all page spaces and offers flexible control layout via drag-and-drop, providing a WYSIWYG experience. Implementation personnel can easily configure the page settings and integrate it with workflows. The page supports dynamic data retrieval, and values within controls can be obtained from third-party APIs through backend configuration. This also better aligns with business scenarios, as each system requires different dropdown parameters; API configuration allows a single form to adapt to all systems and business scenarios.
[0131] Form design determines the scope of a process's application; a robust form design can support diverse business scenarios. The completeness of a form determines the number of business processes it ultimately supports, and also the amount of hard-coded data.
[0132] Form loading: The form will be automatically loaded when the workflow reaches the approval node.
[0133] Form rendering: Based on the form completed by the designer, the engine will automatically render the form and display it on the web.
[0134] Mobile form rendering: H5 rendering is used on mobile devices.
[0135] Form events: Forms support event synchronization.
[0136] (3) Highly configurable
[0137] Ecosaas-BPM supports all types of process management, advanced features such as concurrency signing and concurrency signing, and supports automatic process skipping and process intervention.
[0138] Process node event configuration. Events can be triggered and listened to at the start, end, approval, and rejection of the process. Business logic can be added to the event handlers to call third-party interfaces and email sending functionality.
[0139] It supports email template configuration, allowing users to configure template content online and the email body in a rich text box.
[0140] Add workflow parameters and clickable links to the email template. Approver and business personnel can be configured to display business data in the email template.
[0141] After configuring the email template, it can be attached to the email node. When the process reaches a certain node, the email sending system is triggered. The email sending system will find the corresponding email template and sender, and deliver the email.
[0142] The approver can click the link in the email body to complete the approval.
[0143] (4) Dynamic node configuration
[0144] Ecosaas-BPM can support determining different process branches based on business data. Adding variable judgments to process branches enables dynamic process branching.
[0145] (5) Form linkage function
[0146] The form supports dynamic linkage, dynamically loading the value of the next parameter based on the parameter selected by the previous control.
[0147] (6) Reproducibility
[0148] The system provides standard workflow templates, and each tenant can copy templates from the standard template library for secondary development as needed.
[0149] Example 1,
[0150] 1. The implementation personnel log into the OP platform and create a new tenant (the tenant may also be pushed from UUA; if pushed, this step is not necessary). The implementation personnel create a new process for the tenant.
[0151] 2. The implementers draw a flowchart for the process. Based on the business process diagram, they create branches and add transition conditions. They then handle transition events and determine transition variables.
[0152] 3. Implement personnel deployment process.
[0153] 4. Implementers design the form. Open the form designer, create a new form, drag and drop controls to complete the form element layout, and bind form element variables. Implement dropdown menu value retrieval, form element API binding, and special script binding.
[0154] 5. Open the operations and maintenance platform, design email reminder templates, and support email template notes for each node. Send email notifications to the relevant business personnel.
[0155] 6. Enable permissions in the OP operations platform. Grant the process to HR personnel with the necessary maintenance privileges.
[0156] 7. Design API interfaces in the OP operation platform. All interfaces with sub-platforms can be configured in the OP platform.
[0157] 8. Bind APIs to certain custom controls. Automatically retrieve values.
[0158] 9. Set up an approval workflow entry point in the OP operations platform, set an icon, and bind a menu URL. Set the entry point's visibility to different users.
[0159] 10. Configure the entry protocol. Used for single sign-on.
[0160] 11. Log in to the HR workflow center to monitor workflows. Pause the workflow.
[0161] 12. Employees log in to the employee self-service page and initiate an approval request.
[0162] 13. The approver logs in to the employee self-service page and approves the documents.
[0163] In summary, this application can improve efficiency and accuracy: the intelligent approval system ensures the objectivity and consistency of the approval process through predefined rules and standards, reducing the risk of human error and bias. For example, the approval system can identify suppliers and purchase types, automatically assign relevant values and attach the correct approvers, thereby reducing manual work and the risk of errors. Cost savings: It helps enterprises save costs. Reducing manual workload frees up employees from daily and repetitive approval tasks, allowing them to focus on more complex and strategic work, further improving efficiency and cost-effectiveness.
[0164] Digitalization and Standardization: Transforming traditional paper-based approval processes into electronic ones enables structured data storage, facilitating system processing and analysis. Workflow Automation: Setting up approval process templates defines the responsible person, permissions, and conditions for each node, allowing the system to automatically advance tasks to the next stage. Rule Engine: Based on business logic and policies / regulations, establishing a series of approval rules, the system automatically compares application content to ensure compliance, reducing human error.
[0165] Next, with reference to the accompanying drawings, a data processing system based on business process management proposed according to an embodiment of this application is described.
[0166] Figure 13 This is a block diagram of a data processing system based on business process management, according to an embodiment of this application.
[0167] like Figure 13 As shown, the data processing system 10 based on business process management includes: an abstraction layer module 100, an interface configuration module 200, a process execution engine 300, a form rendering module 400, a dynamic branching module 500, and an event-driven module 600.
[0168] The abstraction layer module 100 is used to construct a business process model independent of the business logic of the subsystems; the interface configuration module 200 is used to define standardized interfaces for each subsystem and communicate with the business process management system engine through the interfaces; the process execution engine 300 is used to generate instances based on the business process model and control task routing and node jumps; the form rendering module 400 is decoupled from the process execution engine and the form page is rendered independently by the subsystem; the dynamic branching module 500 is used to dynamically adjust the process branching logic based on business data variables; and the event-driven module 600 is used to execute preset external service calls or notification operations when events are triggered at process nodes.
[0169] It should be noted that the foregoing explanation of the data processing method embodiment based on business process management also applies to the data processing system based on business process management in this embodiment, and will not be repeated here.
[0170] According to the data processing based on business process management proposed in the embodiments of this application, an abstraction layer-driven business process model is constructed and multi-protocol standardized interfaces are configured. The abstraction layer shields the specific business logic of subsystems, ensuring the business process model is implemented independently of the underlying system, thus avoiding redundant code development. Based on the abstraction layer-driven business process model and multi-protocol standardized interfaces, process instances matching the business scenario are generated, and tasks are distributed to target clients according to task requirements. A protocol adaptation unit dynamically converts the interface request format to ensure compatibility of communication between heterogeneous systems. Based on the abstraction layer model and interface configuration, process instances matching the business scenario are generated in real time to quickly respond to business needs. Based on task control... The engine manages the form state transitions and node jump logic. It parses dynamic variables in business data through a rule engine and matches preset condition rules based on these dynamic variables to adjust process branch paths and node routing strategies. The subsystem autonomously renders form pages, preserving the original interaction style and improving user experience consistency. The process engine manages the form state transitions and node jumps to ensure logical continuity. Event listeners are deployed at key process nodes to monitor the process and trigger external service calls when the process reaches a specified node, forming an end-to-end automated closed loop. Through abstract layer modeling, multi-protocol interface adaptation, rule engine-driven operation, and event listening mechanism, a high degree of flexibility and automation in business process management is achieved.
[0171] Figure 14 A schematic diagram of the structure of an electronic device provided in an embodiment of this application. The electronic device may include:
[0172] The memory 1401, the processor 1402, and the computer program stored on the memory 1401 and executable on the processor 1402.
[0173] When the processor 1402 executes the program, it implements the data processing method based on business process management provided in the above embodiments.
[0174] Furthermore, electronic devices also include:
[0175] Communication interface 1403 is used for communication between memory 1401 and processor 1402.
[0176] The memory 1401 is used to store computer programs that can run on the processor 1402.
[0177] The memory 1401 may include high-speed RAM memory, and may also include non-volatile memory, such as at least one disk storage device.
[0178] If the memory 1401, processor 1402, and communication interface 1403 are implemented independently, then the communication interface 1403, memory 1401, and processor 1402 can be interconnected via a bus to complete communication between them. The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be divided into address buses, data buses, control buses, etc. For ease of representation, Figure 14 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.
[0179] Optionally, in a specific implementation, if the memory 1401, processor 1402, and communication interface 1403 are integrated on a single chip, then the memory 1401, processor 1402, and communication interface 1403 can communicate with each other through an internal interface.
[0180] The processor 1402 may be a central processing unit (CPU), an application specific integrated circuit (ASIC), or one or more integrated circuits configured to implement the embodiments of this application.
[0181] This application also provides a computer-readable storage medium storing a computer program or instructions thereon, which, when executed by a processor, implements the above-described data processing method based on business process management.
[0182] This application also provides a computer program product, including a computer program or instructions, which, when executed, implement the above-described data processing method based on business process management.
[0183] In the description of this specification, the references to terms such as "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of this application. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification, as well as the features of different embodiments or examples.
[0184] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one of that feature. In the description of this application, "N" means at least two, such as two, three, etc., unless otherwise explicitly specified.
[0185] Any process or method described in the flowchart or otherwise herein can be understood as representing a module, segment, or portion of code comprising one or N executable instructions for implementing custom logic functions or processes, and the scope of the preferred embodiments of this application includes additional implementations in which functions may be performed not in the order shown or discussed, including substantially simultaneously or in reverse order depending on the functions involved, as should be understood by those skilled in the art to which embodiments of this application pertain.
[0186] It should be understood that the various parts of this application can be implemented using hardware, software, firmware, or a combination thereof. In the above embodiments, the N steps or methods can be implemented using software or firmware stored in memory and executed by a suitable instruction execution system. For example, if implemented in hardware, as in another embodiment, it can be implemented using any one or more of the following techniques known in the art: discrete logic circuits having logic gates for implementing logical functions on data signals, application-specific integrated circuits (ASICs) having suitable combinational logic gates, programmable gate arrays (PGAs), field-programmable gate arrays (FPGAs), etc.
[0187] Those skilled in the art will understand that all or part of the steps of the methods in the above embodiments can be implemented by a program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, the program includes one or a combination of the steps of the method embodiments.
Claims
1. A data processing method based on business process management, characterized in that, Includes the following steps: Build an abstraction layer-driven business process model and configure multi-protocol standardized interfaces; Based on the business process model driven by the abstract layer and the multi-protocol standardized interface, process instances matching the business scenario are generated, and tasks are distributed to target clients according to task requirements; Based on the task control engine, the form status transition and node jump logic are managed. The dynamic variables in the business data are parsed by the rule engine. The process branch path and node routing strategy are adjusted by matching the preset condition rules according to the dynamic variables. By deploying event listeners at key nodes in the process, the process can be monitored, and when the process reaches a specified node, external service calls can be triggered to form an end-to-end automated closed loop.
2. The data processing method based on business process management according to claim 1, characterized in that, The construction of the business process model includes: Based on the business process logic defined in the abstract layer and the business processes of the subsystems shielded by the abstract layer, a deployable process definition file is generated, which includes process nodes, routing rules, organizational permissions, and form bindings.
3. The data processing method based on business process management according to claim 1, characterized in that, The multi-protocol standardized interface includes a process initiation interface, a task approval interface, and a process termination interface, and the interface requests are dynamically converted into communication protocols supported by the target subsystem through a protocol adaptation unit.
4. The data processing method based on business process management according to claim 1, characterized in that, After deploying event listeners at key nodes in the process, the following is included: Preset actions are triggered when the process starts, ends, or is approved or rejected. These preset actions include calling external system interfaces, sending email notifications, or updating business data.
5. The data processing method based on business process management according to claim 1, characterized in that, Also includes: Configure the external data interface address, parameter mapping relationship, and response parsing rules; The form controls are populated with business data, and dropdown options are dynamically loaded, fields are automatically calculated, or conditional content is displayed.
6. The data processing method based on business process management according to claim 1, characterized in that, Also includes: The standard process template library can be reconfigured according to user needs. The reconfiguration includes modifying node rules, adjusting form layout, or redefining interface binding relationships. The standard process template library supports template cloning, version rollback, and hierarchical permission management.
7. A data processing system based on business process management, characterized in that, include: The abstraction layer module is used to build a business process model that is independent of the business logic of the subsystem. The interface configuration module is used to define standardized interfaces for each subsystem and communicate with the business process management system engine through these interfaces. The process execution engine is used to generate instances based on the business process model and control task routing and node jumps; The form rendering module is decoupled from the process execution engine and the form page is rendered independently by the subsystem. The dynamic branching module is used to dynamically adjust the process branching logic based on business data variables; The event-driven module is used to execute preset external service calls or notification operations when an event is triggered at a process node.
8. An electronic device, characterized in that, include: A memory, a processor, and a computer program stored in the memory and executable on the processor, the processor executing the program to implement the data processing method based on business process management as described in any one of claims 1-6.
9. A computer-readable storage medium having a computer program stored thereon, characterized in that, The program is executed by the processor to implement the data processing method based on business process management as described in any one of claims 1-6.
10. A computer program product, characterized in that, It includes a computer program, which, when executed by a processor, is used to implement the data processing method based on business process management as described in any one of claims 1-6.
Citation Information
Cited By
End-to-end business process approval method, device and medium
CN117455415A
Business process instantiation dynamic generation method and device
CN121414307A
Process execution method and system
CN122022425A