Visualized integration method, device and equipment of cloud workflow and medium

Abstract

The application discloses a kind of cloudification workflow visual integration method, device, equipment and medium, comprising: determining the standardized calling interface corresponding to target cloudification workflow based on software development kit, and determining the engineering integration code corresponding to target cloudification workflow;Determine entity association based on business entity model and standardized calling interface, and determine process template binding result according to entity association and engineering integration code;According to process template binding result and standardized calling interface, visual integration is carried out with target cloudification workflow.Based on the above technical solution, by the adaptation logic, communication logic, data conversion logic of cloudification workflow in tool kit, the API calling interface of cloudification workflow is encapsulated, the underlying cloudification technology difference is shielded, the software development kit is universal, the reuse of integration logic is realized, the integration standardization of cloudification workflow is improved, and the maintenance cost is reduced.

Description

Technical Field

[0001] This invention relates to the field of application development technology, and in particular to a visual integration method, apparatus, device and medium for cloud-based workflows. Background Technology

[0002] In the current field of enterprise Java application development, Java continues to hold a mainstream position due to its excellent stability, mature ecosystem, and powerful cross-platform capabilities. As enterprises accelerate their digital transformation, cloud deployment and cross-system collaboration have become core requirements for business development. Cloud workflows, with their advantages of heterogeneous system compatibility, cloud elastic scaling, and high concurrency processing, have been widely used in the management of complex business processes, becoming a core carrier supporting cross-system, large-scale business flows.

[0003] However, the current integration of enterprise Java projects with cloud-based workflows relies on developers manually writing adaptation code. Due to the cloud-based nature of cloud workflows, their API interface specifications, communication protocols, and data formats are unique and complex. Developers need to manually write adaptation logic, interface call code, and data conversion code, which not only requires high technical skills and experience from developers, but also has drawbacks such as high adaptation difficulty, low efficiency, error-proneness, and disconnection between business and processes. This makes it difficult to guarantee the standardization and consistency of cloud workflow integration, while increasing development and maintenance costs and making it impossible to reuse integration logic. Summary of the Invention

[0004] This invention provides a visual integration method, apparatus, device, and medium for cloud-based workflows. By constructing a standardized and reusable software development kit (SDK), and embedding the adaptation logic, communication logic, and data conversion logic of the cloud-based workflow within the SSD, and encapsulating the API call interface of the cloud-based workflow, the underlying cloud technology differences are shielded. This enables the SSD to be universal, eliminating the need for manually writing adaptation code, achieving the reuse of integration logic, ensuring consistent integration methods and coding styles across different projects, improving integration standardization, reducing maintenance costs, and solving the problems of high adaptation difficulty and poor compatibility of cloud-based workflows.

[0005] According to one aspect of the present invention, a visual integration method for cloud-based workflows is provided, comprising:

[0006] Based on the software development kit, the standardized calling interface corresponding to the target cloud workflow is determined, and the engineering integration code corresponding to the target cloud workflow is determined. The software development kit is a layered architecture development tool that includes an adaptation layer, an interface layer, a data conversion layer, and a communication layer.

[0007] The entity relationships are determined based on the business entity model and standardized calling interfaces, and the process template binding results are determined based on the entity relationships and the engineering integration code.

[0008] Visual integration is performed with the target cloud workflow based on the process template binding results and standardized call interfaces.

[0009] According to another aspect of the present invention, a visualization integration device for cloud-based workflows is provided, comprising:

[0010] The workflow encapsulation module is used to determine the standardized calling interface corresponding to the target cloud workflow based on the software development kit, and to determine the engineering integration code corresponding to the target cloud workflow. The software development kit is a layered architecture development tool that includes an adaptation layer, an interface layer, a data conversion layer, and a communication layer.

[0011] The template binding module is used to determine entity relationships based on the business entity model and standardized calling interface, and to determine the process template binding result based on the entity relationships and the project integration code.

[0012] The visualization integration module is used to perform visual integration with the target cloud workflow based on the process template binding results and standardized call interfaces.

[0013] According to another aspect of the present invention, an electronic device is provided, the electronic device comprising:

[0014] At least one processor; and

[0015] A memory that is communicatively connected to at least one processor; wherein,

[0016] The memory stores a computer program that can be executed by at least one processor, such that the at least one processor is able to execute the cloud-based workflow visualization integration method of any embodiment of the present invention.

[0017] According to another aspect of the present invention, a computer-readable storage medium is provided, which stores computer instructions for causing a processor to execute and implement the cloud-based workflow visualization integration method of any embodiment of the present invention.

[0018] The technical solution of this invention determines the standardized calling interface corresponding to the target cloud-based workflow based on a software development kit (SDK) and the corresponding engineering integration code. It then determines entity relationships based on a business entity model and the standardized calling interface, and determines the process template binding result based on these relationships and the engineering integration code. Finally, it performs visual integration with the target cloud-based workflow based on the process template binding result and the standardized calling interface. Based on this technical solution, by constructing a standardized and reusable SSD, and embedding the cloud-based workflow's adaptation logic, communication logic, and data conversion logic within the SSD, and encapsulating the API calling interface of the cloud-based workflow, the underlying cloud technology differences are shielded. This achieves universality of the SSD, eliminating the need for manually writing adaptation code, enabling the reuse of integration logic, ensuring consistent integration methods and code styles across different projects, improving integration standardization, reducing maintenance costs, and solving the problems of high adaptation difficulty and poor compatibility of cloud-based workflows.

[0019] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of the present invention, nor is it intended to limit the scope of the invention. Other features of the invention will become readily apparent from the following description. Attached Figure Description

[0020] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0021] Figure 1 This is a flowchart of a cloud-based workflow visualization integration method provided in an embodiment of the present invention;

[0022] Figure 2 This is a schematic diagram of the backend engineering visualization integration process provided in an embodiment of the present invention;

[0023] Figure 3 This is a flowchart of a cloud-based workflow visualization integration method provided in an embodiment of the present invention;

[0024] Figure 4 An architecture diagram of the SDK components provided in this embodiment of the invention;

[0025] Figure 5 A schematic diagram of the structure of a visualization integration device for cloud-based workflow provided in an embodiment of the present invention;

[0026] Figure 6 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention. Detailed Implementation

[0027] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.

[0028] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0029] Figure 1 This is a flowchart illustrating a visualization integration method for cloud-based workflows provided in an embodiment of the present invention. This embodiment is applicable to situations where cloud-based workflows are encapsulated and visualized through software development kits. The method can be executed by a visualization integration device for cloud-based workflows, which can be implemented in hardware and / or software and can be configured in an electronic device. Figure 1 As shown, the method specifically includes the following steps:

[0030] S110. Based on the software development kit, determine the standardized calling interface corresponding to the target cloud-based workflow, and determine the engineering integration code corresponding to the target cloud-based workflow.

[0031] The Software Development Kit (SDK) is a layered architecture development tool comprising an adaptation layer, an interface layer, a data transformation layer, and a communication layer. The SSD is a general-purpose toolkit used to encapsulate cloud-based workflow APIs and support Java project integration. The target cloud-based workflow can be understood as a cloud-based deployment workflow engine used by an enterprise. The standardized calling interface can be a unified process operation entry point provided externally through the SSD. The project integration code can be the executable code for Java backend projects to interface with the cloud-based workflow. The adaptation layer is used to achieve version and interface compatibility of the cloud-based workflow. The interface layer is used to provide standardized calling capabilities. The data transformation layer is used to unify data formats. The communication layer is used to implement remote calls and process callbacks.

[0032] Specifically, based on the software development kit (SDK), standardized calling interfaces corresponding to the target cloud workflow are determined, and corresponding engineering integration code is also determined. For example, by enabling the adaptation layer and interface layer of the SSD, the target cloud workflow is matched and standardized calling interfaces are generated. Then, based on the rules of the data conversion layer and communication layer, combined with the visual configuration information, the corresponding Java engineering integration code is automatically generated.

[0033] Based on the above technical solution, the engineering integration code corresponding to the target cloud workflow is determined, including: obtaining the backend project configuration information corresponding to the backend project, and the cloud workflow connection information corresponding to the target cloud workflow; determining the configuration file and dependency declaration file based on the backend project configuration information and the cloud workflow connection information; and generating the engineering integration code based on the configuration file, dependency declaration file and standardized call interface.

[0034] The backend project configuration information includes basic attribute information and dependency information. The cloud-based workflow connection information includes address information and permission information. The backend project can be a business system project developed based on the Java technology stack. Backend project configuration information can include basic attributes and dependencies such as project name, package path, and technical components. The cloud-based workflow can be understood as a cloud-based workflow engine. Cloud-based workflow connection information can include communication and authentication information such as engine address, access token, and tenant identifier. The configuration file is an attribute file used to store connection and runtime parameters. The dependency declaration file can be a build file used to declare the software development kit's dependencies on the cloud-based workflow. The standardized calling interface is a unified process operation entry point provided by the software development kit. The project integration code is the directly compiled and runnable cloud-based workflow integration code.

[0035] Specifically, the platform collects configuration information such as basic backend project attributes and dependency versions filled in by the user through a visual integration interface. At the same time, it enters connection and permission information such as cloud workflow engine address, call token, and tenant ID. The platform automatically fills in the above information and generates an application configuration file and Gradle or Maven dependency declaration file that conform to Java project specifications. It also introduces software development kit components and cloud workflow client dependencies. Based on the configuration file and dependency declaration file, and combined with the calling specifications of standardized call interfaces, it automatically generates complete project integration code that includes engine initialization, process call, data transformation, and callback processing.

[0036] The technical solution of this invention automatically generates configuration, dependency and integration code through visual configuration, which is entirely code-free and has a low threshold, greatly reducing the difficulty of cloud workflow integration, avoiding manual coding errors, and improving integration efficiency and standardization.

[0037] S120. Determine the entity association based on the business entity model and standardized call interface, and determine the process template binding result based on the entity association and the engineering integration code.

[0038] The business entity model can be a business data structure defined through visual modeling, including entity attributes and relationships. The standardized calling interface can be understood as the unified process call entry point for cloud-based workflows provided by the software development kit. Entity associations can be the binding relationships between business entities and cloud-based workflow process nodes or instances. The project integration code is the automatically generated Java project and the cloud-based workflow interface code. The process template binding result is the executable integration configuration after the business entity and the cloud-based workflow process template are linked online.

[0039] Specifically, entity relationships are determined based on business entity models and standardized calling interfaces. The process template binding results are then determined based on these entity relationships and the engineering integration code. For example, a defined business entity model is loaded through a visual modeling platform, and information such as entity attributes, primary keys, and associated fields is read. Combined with the parameter specifications and data format requirements of the standardized calling interface, a mapping relationship is established between business entities and cloud-based workflow process parameters, process variables, and task nodes. This entity relationship is then injected into the generated engineering integration code. The code generation engine automatically completes the association configuration between the entity layer, service layer, control layer, and cloud-based workflow process template, automatically generating binding code that inherits from the unified parent class of the software development kit and implements process callbacks and data transfer. Finally, a process template binding result that can be directly deployed and run is output, realizing the linkage between business entities and cloud-based workflow processes.

[0040] The technical solution of this invention automatically establishes associations and completes process template binding through entity model-driven approach, breaking down barriers between business and processes. It eliminates the need for manual coding of association logic, significantly reducing integration complexity and improving the stability and standardization of process and business linkage.

[0041] Based on the above technical solution, entity relationships are determined based on the business entity model and standardized calling interface, including: constructing a business entity model based on the entity relationship table, and obtaining standard entity objects by inheriting the basic entity class in the software development kit from the business entity model; and establishing entity relationships based on the standard entity objects and the standardized calling interface.

[0042] The entity relationship table can be a data structure used to describe the attributes, primary keys, and relationships between business entities. The business entity model can be understood as a Java entity structure defined through a visual interface and corresponding to business data. The basic entity class is an abstract parent class provided by the software development kit (SDK) adaptation layer for cloud-based workflow integration. Standard entity objects are entity instances that have undergone inheritance and standardization. The standardized calling interface is the unified process operation entry point for cloud-based workflows provided externally by the SSD. Entity relationships can be the mapping and binding relationships between standard entity objects and process variables, node parameters, and callback data.

[0043] Specifically, the entity relationship table is read and parsed through a visual modeling platform, automatically extracting information such as entity name, attribute fields, data type, and association constraints to construct a business entity model that conforms to business semantics. This business entity model inherits the predefined basic entity class in the software development kit's adaptation layer and undergoes standardization processing such as data format adaptation, process callback method rewriting, and cloud workflow parameter mapping to obtain a standard entity object that can interface with the software development kit. Based on the attribute structure and data format of the standard entity object, it is matched with the input and output parameter rules of the standardized calling interface to establish a mapping relationship between entity fields and process variables, task nodes, and process instance identifiers.

[0044] The technical solution of this invention constructs entity associations through three steps: entity relationship table modeling, standardization of basic classes inherited from software development kits, and automatic interface mapping. This achieves standardized connection between entities and processes, eliminating the need for manual coding adaptation, significantly improving integration consistency, lowering the development threshold, and enhancing the stability and reusability of cloud-based workflow integration.

[0045] Based on the above technical solution, the process template binding result is determined according to the entity association relationship and the engineering integration code, including: obtaining the process template identifier corresponding to the target cloud workflow, establishing a mapping relationship between the business entity model and the process template identifier according to the entity association relationship; generating template binding code based on the mapping relationship, and writing the template binding code into the engineering integration code to obtain the process template binding result.

[0046] The target cloud-based workflow can be a cloud-based workflow engine that requires visual integration. The process template identifier is a unique identifier for deployed processes within the cloud-based workflow, used to locate the process template. The business entity model can be a business data structure generated through visual modeling. The mapping relationship can be understood as the correspondence between business entity fields and attributes and process template variables, nodes, and instances. The template binding code is the code used to automatically associate entities with processes. The project integration code can be automatically generated code for connecting a Java project to the cloud-based workflow. The process template binding result is a runnable integration program after the entities and processes are successfully bound.

[0047] Specifically, the visualization integration platform pulls a list of published processes from the cloud-based workflow engine, obtaining process template identifiers such as process name, process definition ID, and process nodes. Then, based on established entity relationships, it automatically matches the attributes and data structures of the business entity model with the corresponding process variables, task nodes, and callback parameters of the process template identifiers, establishing a stable field-level mapping relationship. Subsequently, the code generation engine automatically generates template binding code, including process identifier assignment, entity data injection, process startup invocation, and relative data settings, according to software development kit specifications and Java engineering coding standards. Finally, the template binding code is automatically injected into the corresponding level of the engineering integration code, such as facade classes, control classes, and service classes, completing code fusion and compilation verification, and generating the process template binding result.

[0048] For example, the entity modeling module: This module is primarily used for defining and modeling business entity models, as well as the general binding of business entities to CBPM business processes. It provides technical support for the visual integration of business processes, effectively solving the core technical problem of the disconnect between business and CBPM processes in existing technologies. Entity model definition: Developers define business entity models through the backend visual modeling interface by importing database tables, specifying entity names, entity attributes (such as order number, amount, and process status for an order entity), and entity relationships (such as one-to-one or one-to-many relationships). The platform automatically generates standard-compliant process entities and adapts them to the SDK process parent class, providing a foundation for subsequent binding of entities to CBPM processes. Entity binding to CBPM business processes: This is crucial for resolving the disconnect between business and CBPM. Developers select pre-deployed business processes in the visual interface to bind business processes to entities online, generating executable business code through a code generation engine.

[0049] The technical solution of this invention automatically obtains process identifiers, automatically constructs mapping relationships, and automatically injects binding code, making the entire process visual and coding-free. This completely solves the problem of disconnect between business and processes, significantly improves integration efficiency and standardization, and reduces maintenance costs and technical barriers.

[0050] S130. Visually integrate with the target cloud workflow based on the process template binding results and standardized call interfaces.

[0051] The process template binding result can be understood as an executable integrated program after the business entity model and the cloud-based workflow process template have been linked at the code level. The standardized calling interface is a unified process operation entry point provided by the software development kit. The target cloud-based workflow is the cloud-based workflow engine used by the enterprise. Visual integration is a non-coding integration method that completes process association, parameter injection, interface calls, and interface rendering through a front-end configuration interface.

[0052] Specifically, the platform loads the generated process template binding results through a visual integration platform, reading the entity mapping relationships, process template identifiers, and code configuration information. The front-end interface automatically renders visual controls such as process node display, entity attribute configuration, and process status preview. Developers can directly view the binding relationship between entities and processes on the interface and perform parameter verification and logic adjustment. The platform automatically connects to the cloud-based workflow engine through standardized call interfaces to complete integration operations such as process instance creation, entity data injection, process status query, and callback listening. At the same time, the integration results are fed back to the front-end interface in real time, realizing visual verification of functions such as process startup, approval, trajectory query, and data write-back. The entire process can be fully integrated with the Java back-end project and the cloud-based workflow without writing code or restarting the service.

[0053] For example, such as Figure 2 As shown, the backend engineering visual integration module, relying on the standardized APIs of general SDK components, allows developers to integrate Java backend projects with CBPM in a non-coding manner by configuring SDK integration parameters and CBPM processes. This eliminates the need for manually writing integration code, lowering the technical threshold, improving integration efficiency, and solving the problems of cumbersome and inefficient integration of existing technologies. Java backend project information configuration: Developers fill in the basic information of the Java backend project (such as project name, project code, package path, and selected technology components) in the platform's visual interface, and configure the CBPM connection information (such as engine address and cloud service interface call token) to ensure normal communication with CBPM. Automatic integration logic generation: The platform automatically generates the integration code between the Java backend project and CBPM based on the project configuration information and SDK component version. The generated code conforms to the coding standards of Java backend projects and requires no manual modification.

[0054] Based on the above technical solution, the visualization integration with the target cloud workflow is performed according to the process template binding result and standardized call interface. This includes: obtaining the business triggering instruction triggered by the backend project and calling the standardized call interface based on the business triggering instruction; performing data conversion, protocol encapsulation and calling the target cloud workflow interface based on the software development kit; receiving the callback data returned by the target cloud workflow and writing the callback data back to the business entity model to complete the visualization integration.

[0055] The system comprises several components: business trigger commands (such as reporting, approval, querying, and withdrawal of requests initiated by the backend project); standardized call interfaces (such as a unified cloud-based workflow call entry point provided by the software development kit); data transformation (converting Java business entity data into a cloud-based workflow-recognizable format); protocol encapsulation (assembling request messages according to HTTP / RPC and other specifications); target cloud-based workflow interfaces (native APIs provided by the cloud-based workflow engine); callback data (process status, node information, processing results, etc. returned by the cloud-based workflow engine); business entity models (standard entity objects generated by visual modeling); and visual integration (fully graphical, zero-code workflow integration and data linkage).

[0056] Specifically, business trigger commands such as process reporting and approval are initiated through backend engineering or a visual interface. After the platform intercepts and parses the command type, it automatically calls the standardized calling interface provided by the software development kit (SDK). Subsequently, the data conversion layer of the SSD converts the business entity model data into a cloud workflow compatible format, the communication layer completes message encapsulation according to the cloud protocol, and the adaptation layer automatically matches the cloud workflow version and calls the corresponding native interface. After the cloud workflow engine completes execution, the SSD receives callback data such as process status, task nodes, and processing results in real time. After being standardized again by the data conversion layer, the data is automatically written back to the corresponding attributes of the business entity model and the process trajectory, current node, and processing status are rendered and displayed in real time on the visual interface. End-to-end visual integration can be completed without manual coding or configuration modification.

[0057] The technical solution of this invention determines the standardized calling interface corresponding to the target cloud-based workflow based on a software development kit (SDK) and the corresponding engineering integration code. It then determines entity relationships based on a business entity model and the standardized calling interface, and determines the process template binding result based on these relationships and the engineering integration code. Finally, it performs visual integration with the target cloud-based workflow based on the process template binding result and the standardized calling interface. Based on this technical solution, by constructing a standardized and reusable SSD, and embedding the cloud-based workflow's adaptation logic, communication logic, and data conversion logic within the SSD, and encapsulating the API calling interface of the cloud-based workflow, the underlying cloud technology differences are shielded. This achieves universality of the SSD, eliminating the need for manually writing adaptation code, enabling the reuse of integration logic, ensuring consistent integration methods and code styles across different projects, improving integration standardization, reducing maintenance costs, and solving the problems of high adaptation difficulty and poor compatibility of cloud-based workflows.

[0058] In one possible implementation of the present invention Figure 3This invention provides a flowchart of a workflow management method based on a front-end view framework. The invention further describes a technical solution for determining standardized calling interfaces corresponding to the target cloud-based workflow based on a software development kit (SDK). Figure 3 As shown, the method includes:

[0059] S310. Determine the workflow operation logic corresponding to the cloud-based workflow, and encapsulate the workflow operation logic based on the software development kit to obtain the encapsulation processing result.

[0060] The workflow execution logic includes interface call logic, data format conversion logic, and communication logic. The workflow execution logic comprises the core processing rules required for interaction with the cloud-based workflow engine. The interface call logic consists of the call rules and parameter assembly methods used to adapt to different versions of the cloud-based workflow API. The data format conversion logic can be understood as the format mapping rules between Java project data and cloud-based workflow data. The communication logic can include interaction rules such as remote calls, timeout retries, and process callbacks between the software development kit and the cloud-based workflow. The encapsulated processing results are standardized cloud-based workflow call capabilities that can be directly reused and shield underlying differences.

[0061] Specifically, by first clarifying the interface specifications, data structure, and communication methods of the cloud-based workflow engine, the three core operational logics of interface calls, data transformation, and communication are defined. Then, the four-layer architecture of the software development kit is used for layered encapsulation. In the adaptation layer, unified adaptation of interface call logic is achieved, supporting automatic matching of different versions of cloud-based workflows. In the data transformation layer, bidirectional format conversion of entity data, process variables, and request parameters is achieved, uniformly handling different formats such as JSON and XML. In the communication layer, protocol encapsulation such as HTTP and RPC, timeout retries, exception handling, and process callback listening are implemented. In the interface layer, a unified call entry point for process initiation, approval, and query is provided. Finally, the three logics are completely encapsulated into an integrated processing result, enabling upper-layer business to complete stable calls without having to pay attention to the underlying details of the cloud-based workflow.

[0062] Based on the above technical solutions, the workflow operation logic is encapsulated using a software development kit (SDK) to obtain the encapsulation results, including: encapsulating the interface call logic using the SSD's adaptation layer, loading the corresponding adaptation plugins for the cloud workflow, and completing version matching and interface adaptation; encapsulating the data format conversion logic using the SSD's data conversion layer, and performing bidirectional conversion processing between the backend project data format and the cloud workflow data format; and encapsulating the communication logic using the SSD's communication layer, establishing a multi-protocol communication channel, and configuring process callback and exception handling rules.

[0063] The software development kit (SDK) includes the following modules: The adaptation layer is responsible for version compatibility and interface adaptation. Interface call logic can be the API call rules, parameter structure, and execution flow of the cloud workflow engine. Adaptation plugins are dedicated adaptation components for different cloud workflow versions. The data conversion layer is a processing module for unifying data formats; the backend project data format is the entity object format used by Java projects. The cloud workflow data format can be understood as the request / response format required by the cloud workflow engine. The communication layer is responsible for remote interaction. Multi-protocol communication channels support communication links using HTTP, RPC, and other methods. Process callbacks are the mechanism by which the cloud workflow engine proactively notifies the backend after execution. Exception handling rules are a unified handling strategy for issues such as timeouts, interface failures, and authentication errors.

[0064] Specifically, the software development kit (SDK) can load adaptation plugins corresponding to the current cloud workflow version through its adaptation layer. This automatically identifies the engine version and matches and adapts the interface signature, parameter structure, and calling method, shielding API differences between different versions. The data conversion layer encapsulates bidirectional conversion logic, automatically converting Java backend entity objects and business parameters into JSON or XML formats recognizable by the cloud workflow. Simultaneously, it converts the process data returned by the cloud workflow into standard Java objects, achieving seamless data interoperability. The communication layer establishes multi-protocol compatible channels such as HTTP and RPC, configuring rules for process callback listening, failure retries, timeout circuit breaking, and exception handling to ensure stable and reliable communication in the cloud environment. After these three layers of capabilities are collaboratively encapsulated, a standardized encapsulation result is formed that can be directly called by business engineering, eliminating the need for developers to concern themselves with underlying adaptation details.

[0065] It should be noted that the technical solution of this invention encapsulates the CBPM API into a unified calling interface through a general SDK component, with built-in dedicated adaptation plugins, shielding the differences in underlying cloud technologies. It supports dynamic updates of the adaptation plugins to adapt to CBPM version changes, eliminating the need for manual adaptation code writing. The SDK call success rate is increased to over 99%, completely solving the problems of high difficulty in CBPM adaptation and poor compatibility in existing technologies. The general SDK component supports on-demand import into multiple Java backend projects, enabling reuse of integration logic. With the help of a visual interface and SDK-encapsulated API, developers can complete integration without in-depth knowledge of CBPM specifications and cloud features. Simultaneously, it solidifies the adaptation specifications and integration logic, ensuring unified integration standards across different projects, reducing maintenance and knowledge transfer costs, and solving the problems of unreusable integration logic and high technical barriers.

[0066] The technical solution of this invention encapsulates the three major logics of interface, data and communication through a three-layer architecture of software development kit, thereby completely shielding the underlying differences of cloud-based workflows, improving compatibility and stability, eliminating manual coding, and significantly reducing integration threshold and maintenance costs.

[0067] S320, a standardized calling interface based on the output of encapsulated processing results and corresponding to the cloud-based workflow.

[0068] The standardized calling interface is the process operation entry point provided by the software development kit to the outside world, with unified parameter and return value formats and compatibility with multiple versions of cloud-based workflows.

[0069] Specifically, by integrating the encapsulation results of the adaptation layer, data conversion layer, and communication layer, capabilities such as interface calls, data conversion, communication links, exception handling, and process callbacks are unified and standardized methods such as process initiation, process approval, process withdrawal, process status query, and process trajectory retrieval are abstracted. Encapsulation is performed according to unified input parameters, output parameters, and exception codes to form a standardized calling interface that is independent of cloud workflow versions, deployment modes, and communication protocols. Backend projects or visualization integration platforms can directly call this interface without needing to concern themselves with underlying details such as cloud workflow engine addresses, versions, data formats, and communication methods to complete the entire process interaction, ultimately outputting a stable, universal, and reusable standardized calling interface across projects.

[0070] For example, such as Figure 4As shown, the general SDK component module is the core carrier for implementing CBPM API encapsulation, process callback, and general SDK adaptation. Its core responsibility is to encapsulate CBPM's adaptation logic, communication logic, and data conversion logic, and provide standardized API call interfaces for direct use by Java backend projects and visualization integration modules. At the same time, this module supports cloud deployment, dynamic updates, and reusable functions, which can completely solve the technical problems of high CBPM adaptation difficulty and poor compatibility in existing technologies.

[0071] It's important to note that Cloud-based Workflow (CBPM) refers to a workflow deployed in the cloud, supporting heterogeneous system compatibility, and used to handle complex, high-concurrency processes across systems. Its API interface specifications, communication protocols, and data formats possess unique cloud-based characteristics, making it a core carrier for cross-system business workflows within enterprises. SDK (Software Development Kit) is a collection of development tools provided for developing applications on specific software frameworks, hardware platforms, and operating systems. It refers to a general-purpose toolkit adapted to Java backend projects, used to encapsulate CBPM API interfaces, including adaptation logic, communication logic, data conversion logic, and standardized unified interfaces. Model-Driven Engineering (MDE) is a methodology that uses models as core assets and automated model conversion technology to drive the entire software development process, guiding the design and implementation of entity models integrated with CBPM. Domain-Driven Design (DDD): A design methodology for handling complex business systems. Its core idea is to design software around a domain model to guide the design of entity models. REST API: An application programming interface design specification based on the HTTP protocol, using JSON format for data interaction, and widely used in communication between CBPM and SDK.

[0072] To achieve unified encapsulation of CBPM interfaces and universal adaptation of SDK components, the SDK components of this invention adopt a layered architecture design, which is divided into four major layers: interface layer, adaptation layer, data conversion layer, and communication layer. Each layer has clearly defined responsibilities and independent functions, facilitating subsequent expansion and maintenance while ensuring the universality of the SDK components, thus providing architectural support for the standardized integration of Java backend projects with CBPM.

[0073] Adaptation Layer: Built-in CBPM-specific adaptation plugins and a unified abstract parent class, encapsulating CBPM API calls, cloud communication, and version adaptation logic; can automatically match interfaces according to CBPM version, solve the problem of version update adaptation failure, support dynamic plugin upgrades, improve SDK compatibility, and provide underlying support for stable integration of CBPM with Java backend projects.

[0074] Interface Layer: Provides standardized SDK call interfaces, covering core functions such as CBPM engine calls and process status queries. The interface parameters and return values ​​are standardized, allowing Java backend projects and visual integration modules to call directly without needing to worry about the underlying CBPM technology and adaptation details. It also provides SDK configuration interfaces, supporting dynamic configuration of CBPM connection parameters, adaptation rules, etc., providing support for flexible adaptation between the two.

[0075] Data Conversion Layer: Responsible for unifying the data format between CBPM and Java backend projects, defining standardized data interaction models such as process instances, tasks, and entity associations, converting CBPM returned data into a standardized format, and converting Java business data into a CBPM-recognizable format, enabling data interoperability between the two and solving the technical problems of complex CBPM data formats and incompatibility with Java projects.

[0076] Communication Layer: Responsible for communication between SDK components and CBPM and Java backend projects. It supports multiple protocols such as HTTP, TCP, and RPC, and has built-in exception handling logic such as process callback and timeout retries. It optimizes cloud communication adaptation, achieves stable interaction with cloud-based CBPM, ensures integration stability, and adapts to its cloud deployment characteristics.

[0077] The technical solution of this invention determines the standardized calling interface corresponding to the target cloud-based workflow based on a software development kit (SDK) and the corresponding engineering integration code. It then determines entity relationships based on a business entity model and the standardized calling interface, and determines the process template binding result based on these relationships and the engineering integration code. Finally, it performs visual integration with the target cloud-based workflow based on the process template binding result and the standardized calling interface. Based on this technical solution, by constructing a standardized and reusable SSD, and embedding the cloud-based workflow's adaptation logic, communication logic, and data conversion logic within the SSD, and encapsulating the API calling interface of the cloud-based workflow, the underlying cloud technology differences are shielded. This achieves universality of the SSD, eliminating the need for manually writing adaptation code, enabling the reuse of integration logic, ensuring consistent integration methods and code styles across different projects, improving integration standardization, reducing maintenance costs, and solving the problems of high adaptation difficulty and poor compatibility of cloud-based workflows.

[0078] Figure 5 This is a schematic diagram of the structure of a cloud-based workflow visualization integration device provided in an embodiment of the present invention. Figure 5 As shown, the device includes: a workflow encapsulation module 510, a template binding module 520, and a visualization integration module 530.

[0079] Workflow encapsulation module 510 is used to determine the standardized calling interface corresponding to the target cloud-based workflow based on the software development kit, and to determine the engineering integration code corresponding to the target cloud-based workflow;

[0080] The template binding module 520 is used to determine entity relationships based on the business entity model and standardized call interface, and to determine the process template binding result based on the entity relationships and the project integration code.

[0081] The visualization integration module 530 is used to perform visual integration with the target cloud workflow based on the process template binding results and standardized call interfaces.

[0082] Based on the above technical solution, the workflow encapsulation module is used to determine the workflow operation logic corresponding to the cloud-based workflow, and encapsulate the workflow operation logic based on the software development kit to obtain the encapsulation processing result. The workflow operation logic includes interface call logic, data format conversion logic and communication logic; based on the encapsulation processing result, a standardized call interface corresponding to the cloud-based workflow is output.

[0083] Based on the above technical solutions, the workflow encapsulation module is used to encapsulate the interface call logic based on the software development kit's adaptation layer, load the corresponding adaptation plugins for the cloud workflow, and complete version matching and interface adaptation; based on the software development kit's data conversion layer, it encapsulates the data format conversion logic and performs bidirectional conversion processing between the backend project data format and the cloud workflow data format; based on the software development kit's communication layer, it encapsulates the communication logic, establishes a multi-protocol communication channel, and configures process callback and exception handling rules.

[0084] Based on the above technical solution, the workflow encapsulation module is used to obtain the backend project configuration information corresponding to the backend project, and the cloud workflow connection information corresponding to the target cloud workflow. The backend project configuration information includes basic attribute information and dependency information; the cloud workflow connection information includes address information and permission information; the configuration file and dependency declaration file are determined based on the backend project configuration information and the cloud workflow connection information; and the project integration code is generated based on the configuration file, dependency declaration file and standardized call interface.

[0085] Based on the above technical solution, the template binding module is used to construct a business entity model based on the entity relationship table, and inherit the basic entity class in the software development kit to obtain a standard entity object; and establish entity relationship based on the standard entity object and the standardized calling interface.

[0086] Based on the above technical solution, the template binding module is used to obtain the process template identifier corresponding to the target cloud workflow, establish a mapping relationship between the business entity model and the process template identifier according to the entity association relationship, generate template binding code based on the mapping relationship, and write the template binding code into the project integration code to obtain the process template binding result.

[0087] Based on the above technical solution, the visualization integration module is used to obtain business triggering instructions triggered by the backend project, and call the standardized calling interface based on the business triggering instructions; perform data conversion, protocol encapsulation and target cloud workflow interface calls based on the software development kit; receive callback data returned by the target cloud workflow, and write the callback data back to the business entity model to complete the visualization integration.

[0088] The technical solution of this invention determines the standardized calling interface corresponding to the target cloud-based workflow based on a software development kit (SDK) and the corresponding engineering integration code. It then determines entity relationships based on a business entity model and the standardized calling interface, and determines the process template binding result based on these relationships and the engineering integration code. Finally, it performs visual integration with the target cloud-based workflow based on the process template binding result and the standardized calling interface. Based on this technical solution, by constructing a standardized and reusable SSD, and embedding the cloud-based workflow's adaptation logic, communication logic, and data conversion logic within the SSD, and encapsulating the API calling interface of the cloud-based workflow, the underlying cloud technology differences are shielded. This achieves universality of the SSD, eliminating the need for manually writing adaptation code, enabling the reuse of integration logic, ensuring consistent integration methods and code styles across different projects, improving integration standardization, reducing maintenance costs, and solving the problems of high adaptation difficulty and poor compatibility of cloud-based workflows.

[0089] The cloud-based workflow visualization integration device provided in this embodiment of the invention can execute the cloud-based workflow visualization integration method provided in any embodiment of the invention, and has the corresponding functional modules and beneficial effects of the execution method.

[0090] Figure 6 A schematic diagram of an electronic device 10, which can be used to implement embodiments of the present invention, is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device can also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices (e.g., helmets, glasses, watches, etc.), and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the invention described and / or claimed herein.

[0091] like Figure 6 As shown, the electronic device 10 includes at least one processor 11 and a memory, such as a read-only memory (ROM) 12 or a random access memory (RAM) 13, communicatively connected to the at least one processor 11. The memory stores computer programs executable by the at least one processor. The processor 11 can perform various appropriate actions and processes based on the computer program stored in the ROM 12 or loaded from storage unit 18 into the RAM 13. The RAM 13 can also store various programs and data required for the operation of the electronic device 10. The processor 11, ROM 12, and RAM 13 are interconnected via a bus 14. An input / output (I / O) interface 15 is also connected to the bus 14.

[0092] Multiple components in electronic device 10 are connected to I / O interface 15, including: input unit 16, such as keyboard, mouse, etc.; output unit 17, such as various types of displays, speakers, etc.; storage unit 18, such as disk, optical disk, etc.; and communication unit 19, such as network card, modem, wireless transceiver, etc. Communication unit 19 allows electronic device 10 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0093] Processor 11 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of processor 11 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various processors running machine learning model algorithms, digital signal processors (DSPs), and any suitable processor, controller, microcontroller, etc. Processor 11 performs the various methods and processes described above, such as the visualization integration method of cloud-based workflows.

[0094] In some embodiments, the visualization integration method for cloud-based workflows can be implemented as a computer program tangibly contained in a computer-readable storage medium, such as storage unit 18. In some embodiments, part or all of the computer program can be loaded and / or installed on electronic device 10 via ROM 12 and / or communication unit 19. When the computer program is loaded into RAM 13 and executed by processor 11, one or more steps of the visualization integration method for cloud-based workflows described above can be performed. Alternatively, in other embodiments, processor 11 can be configured to perform the visualization integration method for cloud-based workflows by any other suitable means (e.g., by means of firmware).

[0095] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), payload-programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0096] Computer programs used to implement the methods of the present invention may be written in any combination of one or more programming languages. These computer programs may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device, such that when executed by the processor, the computer programs cause the functions / operations specified in the flowcharts and / or block diagrams to be performed. The computer programs may be executed entirely on a machine, partially on a machine, or as a standalone software package, partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0097] In the context of this invention, a computer-readable storage medium can be a tangible medium that may contain or store a computer program for use by or in conjunction with an instruction execution system, apparatus, or device. A computer-readable storage medium may include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination thereof. Alternatively, a computer-readable storage medium may be a machine-readable signal medium. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0098] To provide interaction with a user, the systems and techniques described herein can be implemented on an electronic device having: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user; and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the electronic device. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0099] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as data servers), or middleware components (e.g., application servers), or frontend components (e.g., user computers with graphical user interfaces or web browsers through which users can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., communication networks). Examples of communication networks include local area networks (LANs), wide area networks (WANs), blockchain networks, and the Internet.

[0100] A computing system can include clients and servers. Clients and servers are generally located far apart and typically interact through communication networks. The client-server relationship is created by computer programs running on the respective computers and having a client-server relationship with each other. The server can be a cloud server, also known as a cloud computing server or cloud host, which is a hosting product within the cloud computing service system to address the shortcomings of traditional physical hosts and VPS services, such as high management difficulty and weak business scalability.

[0101] It should be understood that the various forms of processes shown above can be used, with steps reordered, added, or deleted. For example, the steps described in this invention can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution of this invention can be achieved, and this is not limited herein.

[0102] The specific embodiments described above do not constitute a limitation on the scope of protection of this invention. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this invention should be included within the scope of protection of this invention.

Claims

1. A visual integration method for cloud-based workflows, characterized in that, include: Based on the software development kit, a standardized calling interface corresponding to the target cloud workflow is determined, and the engineering integration code corresponding to the target cloud workflow is determined. The software development kit is a layered architecture development tool that includes an adaptation layer, an interface layer, a data conversion layer, and a communication layer. The entity relationships are determined based on the business entity model and the standardized calling interface, and the process template binding result is determined based on the entity relationships and the project integration code. Visual integration is performed with the target cloud workflow based on the process template binding results and the standardized call interface.

2. The method according to claim 1, characterized in that, The standardized calling interface corresponding to the target cloud-based workflow, determined based on the software development kit, includes: The workflow operation logic corresponding to the cloud-based workflow is determined, and the workflow operation logic is encapsulated based on the software development kit to obtain the encapsulation processing result. The workflow operation logic includes interface call logic, data format conversion logic, and communication logic. Based on the encapsulation processing result, a standardized calling interface corresponding to the cloud-based workflow is output.

3. The method according to claim 2, characterized in that, The encapsulation of the workflow execution logic based on the software development kit to obtain the encapsulation processing result includes: The interface call logic is encapsulated based on the adaptation layer of the software development kit, and the adaptation plugin corresponding to the cloud workflow is loaded to complete version matching and interface adaptation. The data conversion layer based on the software development kit encapsulates the data format conversion logic and performs bidirectional conversion processing between the backend engineering data format and the cloud workflow data format. The communication logic is encapsulated based on the communication layer of the software development kit, a multi-protocol communication channel is established, and process callback and exception handling rules are configured.

4. The method according to claim 1, characterized in that, The determination of the engineering integration code corresponding to the target cloud-based workflow includes: Obtain the backend project configuration information corresponding to the backend project, and the cloud workflow connection information corresponding to the target cloud workflow, wherein the backend project configuration information includes basic attribute information and dependency information; the cloud workflow connection information includes address information and permission information; Based on the backend project configuration information and cloud workflow connection information, determine the configuration file and dependency declaration file; The project integration code is generated based on the configuration file, the dependency declaration file, and the standardized calling interface.

5. The method according to claim 1, characterized in that, The process of determining entity relationships based on the business entity model and the standardized calling interface includes: The business entity model is constructed based on the entity relationship table, and the business entity model inherits the basic entity class in the software development kit to obtain a standard entity object; The entity association is established based on the standard entity object and the standardized calling interface.

6. The method according to claim 1, characterized in that, The step of determining the process template binding result based on the entity association relationship and the project integration code includes: Obtain the process template identifier corresponding to the target cloud-based workflow, and establish a mapping relationship between the business entity model and the process template identifier based on the entity association relationship; Based on the mapping relationship, template binding code is generated, and the template binding code is written into the project integration code to obtain the process template binding result.

7. The method according to claim 1, characterized in that, The visualization integration based on the process template binding result and the standardized calling interface with the target cloud-based workflow includes: Obtain the business trigger instruction triggered by the backend project, and call the standardized call interface based on the business trigger instruction; Based on the aforementioned software development kit, data conversion, protocol encapsulation, and target cloud workflow interface calls are performed. Receive the callback data returned by the target cloud workflow, and write the callback data back to the business entity model to complete the visualization integration.

8. A visualization integration device for cloud-based workflows, characterized in that, include: The workflow encapsulation module is used to determine the standardized calling interface corresponding to the target cloud-based workflow based on the software development kit, and to determine the engineering integration code corresponding to the target cloud-based workflow; The template binding module is used to determine the entity association relationship based on the business entity model and the standardized calling interface, and to determine the process template binding result based on the entity association relationship and the project integration code; The visualization integration module is used to perform visual integration with the target cloud workflow based on the process template binding result and the standardized call interface.

9. An electronic device, characterized in that, The electronic device includes: At least one processor; and A memory communicatively connected to the at least one processor; wherein, The memory stores a computer program that can be executed by the at least one processor, the computer program being executed by the at least one processor to enable the at least one processor to perform the visualization integration method of cloud-based workflow as described in any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions that are used to cause a processor to execute the visualization integration method of the cloud workflow according to any one of claims 1-7.

Images