Intersystem integration method and device based on configured zero code

Abstract

The invention provides an inter-system integration method and device based on configured zero codes, a graphical arrangement front end is constructed by adopting frameworks such as Vue, a back-end execution engine is constructed based on Spring Boot / Cloud, and a complete nodal process configuration and execution system is formed. According to the system, JSON Schema metadata is generated by automatically collecting and analyzing a Feign interface, and a user is supported to assemble integrated logic in a zero-code mode by dragging prefabricated function nodes and connecting lines; and the background models the structured JSON into a directed acyclic graph for topological sorting and static verification based on types and rules, and finally serializes the structured JSON to configure persistent storage. According to the method, visual and configured construction of integrated logic is realized, and the development threshold and the coding quantity are greatly reduced; and through built-in verification and structured storage, the reliability, maintainability and traceability of the process are remarkably improved, so that business personnel or common developers can rapidly and flexibly arrange and reliably operate the enterprise-level integrated process.

Description

Technical Field

[0001] This invention relates to the field of software development technology, and in particular to a method and apparatus for system integration based on configurable zero-code. Background Technology

[0002] With the increasing prevalence of microservice architectures, the need for data interaction and business integration between systems via HTTP interfaces is becoming more frequent and complex. While declarative HTTP client tools like Feign simplify calls to individual interfaces, existing technologies have significant shortcomings when implementing complex integration logic involving sequential calls to multiple interfaces, conditional branching, loop processing, and data transformation. Specifically, current technologies primarily rely on developers directly writing Java code, hard-coding Feign calls, business logic, and data processing logic into the application. This model is inefficient, requiring any logical adjustments to undergo a complete process of modification, compilation, testing, and deployment, hindering agile responses to business changes. Furthermore, it has a high technical barrier, demanding developers to have in-depth knowledge of programming languages ​​and framework details, making it difficult for business personnel to participate. In addition, as logical complexity increases, code readability and maintainability drop sharply, making it prone to errors and difficult to pass on. Although some API gateways or visual testing tools support simple interface aggregation or debugging, their functionality is limited to request forwarding or single-point testing, generally lacking graphical orchestration capabilities for complex business processes, as well as the concurrency control, fault tolerance, and complete data flow management mechanisms required to ensure production-grade reliability. Therefore, how to provide a solution that can quickly build and reliably execute the integration logic between complex systems in a way that has low technical barriers and high visibility has become a technical problem that urgently needs to be solved in this field. Summary of the Invention

[0003] In view of this, embodiments of the present invention provide a system integration method and apparatus based on configuration-based zero-code, in order to eliminate or improve one or more defects existing in the prior art, and solve the problems that existing system integration development models under microservice architecture are inefficient, have high technical thresholds and complex maintenance due to their reliance on hard coding, and lack the ability to visually orchestrate and reliably execute complex business processes in a zero-code manner.

[0004] One aspect of the present invention provides a system integration method based on configuration-based zero-code, the method comprising the following steps: The front-end loads a front-end interface provided by the Vue front-end framework, which provides a graphical orchestration interface through the jsPlumb library; the back-end loads a back-end core built on the Spring Boot microservice framework and Spring Cloud microservice system, which manages the addresses and application configurations of each microservice in the service registration and discovery center management platform. Collect and validate the Feign interfaces provided by each project to provide a list of available service nodes for process orchestration and a visual management system to add, delete, modify, and query the Feign interfaces; recursively parse the Java parameter objects and return value objects corresponding to the Feign interfaces into standard JSON Schema descriptions as metadata with strong type validation; The system receives user control commands and allows users to select functional nodes via visual drag-and-drop. These functional nodes include pre-configured control nodes, data nodes, and service nodes selected from the service node list. The control nodes include branch nodes, parallel nodes, and loop nodes. The data nodes include assignment nodes and data processing nodes. The execution order of each functional node is defined by connecting them using the jsPlumb tool to form a control flow and assemble the system's inter-system integration logic. The control flow corresponding to the inter-system integration logic is configured as a directed acyclic graph (DAG) data structure, where vertices represent functional nodes and edges represent the execution order and dependencies between functional nodes. A graph theory-based topological sorting algorithm is used to determine the execution order of the DAG data structure. The integrity and logic of the DAG data structure are verified by combining the functions of the control nodes and data nodes with the JSON Schema description of the service nodes. If the integrity and logic verification pass, the control flow of the inter-system integration logic is serialized into a standardized JSON configuration, stored in the database, and a version number is generated. The JSON configuration includes a unique identifier, the type, configuration parameters, and input / output context of each functional node, as well as the start point, end point, and branch conditions of each edge.

[0005] In some embodiments, the method further includes: A visual interface is provided for users to manually enter Feign interface information and upload instance JSON messages, and the corresponding JSON Schema description is generated in reverse based on the JSON messages; Configure test parameters, dynamically build a temporary proxy instance on the backend to initiate HTTP test calls, verify whether the response data of the Feign interface conforms to the JSON Schema description, capture network service anomalies, and exclude Feign interfaces with incorrect interface configurations.

[0006] In some embodiments, the method further includes: By setting a context manager, the functional nodes are specified to be able to read only the data output by the directly preceding functional nodes to ensure the sequential visibility of the data flow; the data generated inside the parallel branches constructed by the branch nodes is specified to be invisible to other parallel branches to ensure branch isolation; and the operation of the amplitude nodes is specified to be applied to the final output object of the process to ensure output constraints. Each functional node maintains an independent data dictionary, and data is accessed through a unique key of node ID and parameter path.

[0007] In some embodiments, the method further includes: A fault handling strategy is pre-configured for each functional node. When a call fails, it is retried a set number of times. After the set number of retry failures, the functional node that failed to call is skipped and a prompt message is generated.

[0008] In some embodiments, the method further includes: It provides a synchronous call mode, configuring each process with a unique identifier and exposing it as a RESTful API. External callers trigger execution via HTTP requests and synchronously obtain the results. Alternatively, an asynchronous call mode can be provided, integrating all processes with message queues. The external caller sends a message to a specified message queue, listens to the specified message queue, and executes the process asynchronously. After execution, the external caller can be notified via callback or by sending a result message.

[0009] In some embodiments, the integrity and logical verification of the directed acyclic graph data structure is performed by combining the functions of the control node and the data node with the JSON Schema description of the service node, including: Check for open branches, isolated nodes, and directed cycles. Verify the input and output data types based on the JSON Schema description of each functional node; The SpEL expressions of the branch nodes and the assignment nodes are parsed and their variable existence is checked to ensure that the referenced field paths exist in the JSON Schema description of the preceding functional nodes. Using a graph reachability algorithm, all abnormal functional nodes that are unreachable from the starting functional node are marked, and dead path hints are generated.

[0010] In some embodiments, the method further includes: during the integrity and logic verification process, pushing the start time, end time, input / output size, and exception information of each functional node to a monitoring system based on Prometheus and Grafana to achieve process-level visual monitoring.

[0011] On the other hand, the present invention also provides a system integration apparatus based on configurable zero-code, including a processor, a memory, and a computer program or instructions stored in the memory, wherein the processor is used to execute the computer program or instructions, and when the computer program or instructions are executed, the apparatus implements the steps of the above method.

[0012] On the other hand, the present invention also provides a computer-readable storage medium having a computer program or instructions stored thereon, which, when executed by a processor, implement the steps of the above-described method.

[0013] On the other hand, the present invention also provides a computer program product, including a computer program or instructions that, when executed by a processor, implement the steps of the above-described method.

[0014] The system integration method and apparatus based on configuration-based zero-code described in this invention constructs a graphical orchestration interface based on Vue and jsPlumb on the front end and a core engine based on Spring Boot / Cloud on the back end, and designs a complete node-based process configuration and execution system. First, it automatically collects and standardizes the Feign interface to generate JSON Schema metadata for strong type validation. Then, it allows users to drag and drop pre-built control nodes, data nodes, and service nodes, and define the execution order between nodes by connecting them, assembling complete system integration logic in a zero-code manner. This logic is modeled as a directed acyclic graph in the back end, and after topological sorting and integrity validation based on node type and JSON Schema, it is serialized into structured JSON configuration and persistently stored. This achieves the visualization and configuration-based construction of complex integration logic, significantly reducing the development threshold and coding workload. Through built-in type validation, process validation, and structured storage, it significantly improves the reliability, maintainability, and traceability of the process. Ultimately, it enables business personnel or ordinary developers to quickly and flexibly orchestrate and iterate enterprise-level system integration processes, while ensuring the execution efficiency and stability required for the production environment.

[0015] Additional advantages, objects, and features of the invention will be set forth in part in the description which follows, and will also become apparent in part to those skilled in the art upon studying the text, or may be learned by practice of the invention. The objects and other advantages of the invention can be realized and obtained by means of the structures specifically pointed out in the description and drawings.

[0016] Those skilled in the art will understand that the objectives and advantages achievable with the present invention are not limited to those specifically described above, and that the above and other objectives achievable with the present invention will become clearer from the following detailed description. Attached Figure Description

[0017] The accompanying drawings, which are included to provide a further understanding of the invention and form part of this application, are not intended to limit the scope of the invention. In the drawings: Figure 1This is a flowchart illustrating a system integration method based on configuration-based zero-code according to an embodiment of the present invention.

[0018] Figure 2 This is a logical schematic diagram of a system integration method based on configuration-based zero-code according to another embodiment of the present invention. Detailed Implementation

[0019] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the embodiments and accompanying drawings. Here, the illustrative embodiments and descriptions of this invention are used to explain the invention, but are not intended to limit the invention.

[0020] It should also be noted that, in order to avoid obscuring the invention with unnecessary details, only the structures and / or processing steps closely related to the solution according to the invention are shown in the accompanying drawings, while other details that are not closely related to the invention are omitted.

[0021] It should be emphasized that the term "including / comprises" as used herein refers to the presence of a feature, element, step, or component, but does not exclude the presence or addition of one or more other features, elements, steps, or components.

[0022] In current microservice architecture practices, system integration primarily relies on three technical paths: First, hard-coding development based on frameworks like Feign, requiring developers to manually write all call, logic judgment, and data transformation code, resulting in long development cycles, high maintenance costs, and a high susceptibility to errors; second, using basic API gateways or simple orchestration tools, which can only achieve linear aggregation and routing of interfaces, lacking visual support and fine-grained control over complex business logic such as conditional branching, parallel execution, and loop processing; and third, using interface testing tools like Postman for single-point debugging and simulation, the output of which cannot be directly transformed into a deployable, fault-tolerant, and high-performance production-grade process. These existing solutions generally suffer from core flaws: they heavily rely on professional coding skills, making it difficult for business personnel to participate; logic changes involve full-link code modification and redeployment, resulting in slow response times; they lack standardized and visual control over data flow, scope, and exception handling; and they cannot simultaneously meet the dual goals of complex logic orchestration and enterprise-level reliability requirements, severely restricting system integration efficiency and business agility.

[0023] In view of this, the present invention provides a system integration method based on configuration-based zero-code, such as... Figure 1 and Figure 2 As shown, the method includes the following steps S101~S105: Step S101: Load the front-end interface provided by the Vue front-end framework on the front end. The front-end interface provides a graphical orchestration interface through the jsPlumb library. Load the back-end core built on the Spring Boot microservice framework and Spring Cloud microservice system on the back end. The back-end core manages the addresses and application configurations of each microservice in the platform through the service registration and discovery center.

[0024] Step S102: Collect and verify the Feign interfaces provided by each project to provide a list of available service nodes for process orchestration and a visual management system for adding, deleting, modifying, and querying Feign interfaces; recursively parse the Java parameter objects and return value objects corresponding to the Feign interfaces into a standard JSON Schema description as metadata with strong type validation.

[0025] Step S103: Receive the user's control command to select a functional node in a visual drag-and-drop manner. The functional nodes include pre-configured control nodes, data nodes, and service nodes selected from the service node list. Control nodes include branch nodes, parallel nodes, and loop nodes; data nodes include assignment nodes and data processing nodes; use the jsPlumb tool to connect and define the execution order of each functional node to form a control flow and assemble the system integration logic.

[0026] For example, the branch node, i.e., the IF / ELSE node, allows users to configure conditional expressions. The system supports SpEL (Spring Expression Language) as the expression engine, and users can write conditions such as ${input.user.age}>18. The engine will dynamically calculate the expression result to determine the branch to execute.

[0027] Parallel nodes (WHEN) enable concurrent execution of multi-branch tasks. When the engine encounters a parallel node, it uses Java's CompletableFuture framework to submit each branch to an independent thread for simultaneous execution, and finally aggregates the execution results of all branches. The system uses thread isolation technology to ensure that data between parallel branches does not interfere with each other.

[0028] The Forwarding Node (FOR) is used to iterate over collection data. Users can specify a collection (such as a list) as the loop source and define the variable name of the element being iterated over. The engine then drives subsequent nodes to repeat this process for each element in the collection.

[0029] Assignment nodes implement field mapping and transformation. Users can specify the paths to source and target fields using expressions similar to JSONPath, such as mapping source.data.userName to target.user.name. The engine extracts and assigns values ​​at runtime based on the path expressions.

[0030] Data processing nodes are used to generate temporary variables or perform calculations on data. Users can configure expressions, such as performing operations on numbers (${input.amount} * 0.1) or calling built-in functions (such as date formatting), and the calculation results can be referenced by subsequent nodes.

[0031] The Feign API call node serves as a bridge between the process and external microservices. Based on JDK dynamic proxy technology, the engine dynamically generates Feign client instances at runtime according to configuration information, completing the encapsulation, sending, and response parsing of HTTP requests.

[0032] Step S104: Configure the control flow corresponding to the inter-system integration logic as a directed acyclic graph data structure. The vertices in the graph represent functional nodes, and the edges represent the execution order and dependencies between functional nodes. Use graph theory's topological sorting algorithm to determine the execution order of the directed acyclic graph data structure. Combine the functions of control nodes and data nodes with the JSON Schema description of service nodes to perform integrity and logical verification on the directed acyclic graph data structure.

[0033] Step S105: If the integrity and logic verification pass, serialize the control flow of the inter-system integration logic into a standardized JSON configuration, store it in the database, and generate a version number; the JSON configuration includes a unique identifier, the type, configuration parameters, and input / output context of each functional node, as well as the start point, end point, and branch conditions of each edge.

[0034] Step S101 defines the construction and initialization of the front-end and back-end technology stacks, establishing the technical foundation for platform operation. The front-end uses the Vue framework combined with the jsPlumb library to build a graphical orchestration interface. Its principle lies in leveraging Vue's data-driven view characteristics to achieve efficient interface responsiveness, and relying on the underlying capabilities of jsPlumb such as connections and drag-and-drop to render abstract programming logic such as conditional judgments and API calls into interactive graphical nodes and connections. The back-end is built on the Spring Boot and Spring Cloud ecosystem, integrating service governance components such as Nacos. Its principle is to achieve unified management of service registration, discovery, and configuration within the platform itself, ensuring the platform runs as a reliable component in a microservice architecture. The technical effect of this step is to form a stable, scalable technical foundation that seamlessly integrates with the target microservice environment (Feign API ecosystem), providing the necessary runtime environment and infrastructure support for subsequent zero-code orchestration.

[0035] Step S102 is used for the automated collection and metadata standardization of Feign interfaces, solving the problem of how external service capabilities can be identified and standardized by the platform. Its implementation involves automatically extracting metadata such as method signatures, parameters, and return types of the interface through annotation scanning of @FeignClient and Java reflection. The core principle is to recursively parse complex Java object structures into language-independent JSON schema descriptions using libraries such as Jackson. For example, a Feign interface that returns a UserDTO object will automatically deduce and generate corresponding JSON schema definitions for its nested id (Long type), name (String type), and other fields. This achieves strongly typed registration of the interface, transforming the interface contracts originally scattered in the code into structured metadata that the platform can understand and verify. This provides a precise basis for parameter binding, type safety verification, and data mapping during subsequent graphical configuration, fundamentally avoiding data structure mismatch errors that are easily caused by manual configuration.

[0036] In some embodiments, the method further includes steps S1021-S1022: Step S1021: Provide a visual interface for users to manually enter Feign interface information and upload instance JSON messages, and generate the corresponding JSON Schema description based on the JSON messages.

[0037] Step S1022: Configure test parameters, dynamically build a temporary proxy instance on the backend to initiate an HTTP test call, verify whether the response data of the Feign interface conforms to the JSON Schema description, capture network business anomalies, and exclude Feign interfaces with incorrect interface configurations.

[0038] Step S1021 is used for manual registration of Feign interfaces and message-driven modeling, providing a supplementary and backup registration channel for the automated scanning mechanism. In the visual interface management interface of the platform, users can manually fill in basic information such as the name, URL, and HTTP method of the interface, and directly paste a real request or response JSON message instance. After receiving this JSON message, the system will start a reverse derivation engine. Its core principle is to recursively traverse the structure of the JSON message, analyze the key names of each field and the data type of the value (such as string, number, boolean, nested object, array, etc.), and automatically infer and generate a standard JSON Schema description accordingly. For example, when the user uploads a response message {"code":0,"data": {"userName":"张三","age": 25}}, the system will automatically generate a complete Schema including code (integer type), data (object type), and its internal userName (string type) and age (integer type). This greatly improves the compatibility and flexibility of the platform. It effectively solves the problem that third-party interfaces, legacy system interfaces, or interface prototypes that have not been completed coding and are not developed based on Spring Cloud Feign cannot be registered through automatic scanning. By the way of reverse-inferring the contract from the instance, any HTTP interface with a JSON example can be quickly and accurately managed by the platform and become an orchestratable node, expanding the applicable scope of the platform.

[0039] Step S1022 involves online testing and verification of the interface based on dynamic proxies. After interface configuration, this step provides a trial environment to ensure the reliability of each service node before delivery. Users input specific test parameter values ​​for the configured interface nodes on the interface. Upon receiving the test command, the platform backend uses JDK dynamic proxy technology to dynamically generate a temporary Feign client proxy instance based on the interface's configuration information (URL, request headers, parameter structure). In principle, this proxy instance simulates the complete behavior of the process execution engine calling the interface in the future: encapsulating the request, sending the HTTP call, and receiving the response. The system not only checks network connectivity (capturing network anomalies such as timeouts and connection rejections), but more importantly, it uses the JSON Schema generated in step S102 or S1021 to perform structural validation on the response body, verifying the existence of fields, type matching, and compliance with mandatory field constraints. For example, if the Schema defines age as an integer, but the actual return value is "twenty-five", the test will fail with a clear type error message. The technical effect of this step is to achieve high-quality assurance during the configuration period. It advances and standardizes common integration testing steps in integrated development, enabling timely detection and repair of issues such as incorrect interface addresses, inconsistent parameter structures, and changes in response formats before the process is deployed and launched. This avoids defective interface nodes being incorporated into the business process, thereby significantly reducing the failure rate after the process goes live and improving the delivery quality and development efficiency of the entire integration project.

[0040] Step S103 is used to implement process assembly based on visual nodes, which is the core interactive link for users to perform zero-code programming.

[0041] In implementation, the platform encapsulates programming primitives such as if-else statements, for loops, parallel execution, field assignment, and API calls into pre-built, functionally defined graphical nodes. Users drag and drop these nodes and define their execution order with connections, essentially drawing a control flow and data flow graph. The principle is to transform the traditional text-based coding paradigm into a "node-edge" graph model paradigm. For example, a user can drag a branch node, configure the SpEL expression `${request.amount}>1000` in the properties panel, and then draw two connections from that node, one for "yes" and one for "no," pointing to different subsequent processing node chains. This significantly lowers the barrier to building complex integrated logic, enabling business analysts or ordinary developers to directly assemble complete logic including conditional routing, loop processing, service calls, and data transformation in an intuitive and business process-oriented way, achieving a revolutionary shift from writing code to drawing flowcharts.

[0042] Step S104 involves logical modeling and static validation of the process. Before the user saves the process, the visualized orchestration results are automatically analyzed and validated. The nodes and connections generated in step S103 are modeled in memory as a directed acyclic graph data structure, and a graph theory topological sorting algorithm is used to calculate the reasonable execution sequence of the nodes. Simultaneously, the validation engine combines the functional semantics of each node and the JSON Schema metadata generated in step S102 to perform static checks on the integrity, type safety, and logical correctness of the process. For example, it detects circular dependencies, dead nodes that cannot be executed due to contradictory conditions, or type conflicts such as attempting to assign string values ​​to integer fields. By exposing and intercepting a large number of potential errors during the configuration phase, rather than at runtime, the final generated process configuration is logically self-consistent and type-safe, significantly improving the reliability and generation efficiency of the process and reducing later debugging costs.

[0043] Step S105 is used to serialize and persist the process, transforming the validated, in-memory graph model into a persistent configuration that can be stored, versioned, and parsed by the engine. The entire process (including the node list, edge list, and detailed configuration parameters of each node) is serialized into a standardized, structured JSON document. This JSON document fully defines the blueprint of the process, such as the unique ID, type, and specific configuration of each node (e.g., the URL of the interface, the source and target paths of the assignment rules), as well as the execution path and conditions represented by each edge. A platform-specific domain-specific language describing the process is defined, enabling asset-based management of the process configuration: the generated JSON configuration is stored in the database and assigned a version number, making every modification traceable and rollbackable; simultaneously, this structured configuration becomes the sole source for the process execution engine to read and drive, realizing configuration as code, and laying the data foundation for reliable deployment, efficient execution, and unified management of the process.

[0044] In some embodiments, the method further includes: specifying that functional nodes can only read data output by directly preceding functional nodes by setting a context manager to ensure the sequential visibility of the data flow; specifying that data generated inside the parallel branches constructed by branch nodes is not visible to other parallel branches to ensure branch isolation; specifying that the operation of amplitude nodes is applied to the final output object of the process to ensure output constraints; and maintaining an independent data dictionary for each functional node, accessing data through the unique key of node ID and parameter path.

[0045] Specifically, during process execution, the context manager creates an independent, temporary output data container (which can be viewed as a Map) for each functional node. The rule dictates that node B can only read data from the output container of its direct predecessor node A. This means that data is strictly passed sequentially between nodes according to the connection direction. For example, in a process from node A (interface call) to node B (data processing) and then to node C (assignment), node C can only read the processed result from node B and cannot directly access the original return data from node A unless the data is explicitly passed by node B. This rule simulates the scope of local variables in code, preventing unordered and unauthorized access to data. It forces process designers to manage and pass the required data through explicit nodes, making data dependencies clear on the flowchart, greatly enhancing the readability and maintainability of the process, and avoiding logical errors caused by implicit data dependencies.

[0046] When execution reaches a parallel node (WHEN), the context manager creates a completely new, independent data scope for each branch. All node operations within a branch are performed within this isolated scope. For example, a variable `tempVar` generated in parallel branch 1 is completely invisible and inaccessible in the node of branch 2. Only after all branches have finished executing, at the merge point, typically only the predefined outputs of each branch are passed to the subsequent common node. This rule solves the most challenging data race and pollution problems in multi-threaded concurrent execution. Through physical isolation, it ensures that the execution between parallel branches does not interfere with each other, just as safely as multiple threads operating on their own local variables. This allows business users to configure parallel tasks with confidence, even without multi-threaded programming knowledge; the platform guarantees the correctness of concurrent execution from a fundamental mechanism.

[0047] During process initialization, the platform creates a final "process output object." The rules stipulate that only "assignment nodes" can modify the fields of this final output object. Intermediate results generated by other nodes are stored in the aforementioned temporary data container, used to drive the process logic, but do not directly contaminate the final output. Users need to explicitly configure the mapping relationship between the source (temporary data from a node) and the target (a field path in the final output object) on the assignment nodes. This rule ensures the stability and predictability of the process's external behavior. No matter how complex the internal logic is, the process's output structure is defined by a series of explicit assignment operations. This facilitates understanding by the caller and ensures that modifications to the process will not unexpectedly alter its external output data structure, improving system stability and testability.

[0048] The context manager maintains a key-value pair store for each node instance. The data key consists of the "node ID" and the "parameter path." When subsequent nodes need to reference data, they must specify this complete key in the configuration. During engine execution, the data is precisely retrieved from the context manager based on this key. This is the technical foundation for implementing all the aforementioned scoping rules. The unique key enables precise data addressing and namespace isolation. It enforces "sequential visibility" (because the key contains the node ID, naturally limiting the data source) and makes "branch isolation" possible (node ​​IDs in parallel branches are different, even if the parameter paths are the same, there will be no conflict). This approach provides extremely high flexibility and precision, serving as a bridge connecting the visual configuration with the underlying data binding.

[0049] In some embodiments, the method further includes: pre-configuring a fault handling strategy for each functional node, retrying a set number of times when a call fails, skipping the failed functional node after the set number of failed retries, and generating a prompt message. Specifically, by providing a graphical fault handling strategy configuration interface for each functional node, the complex exception handling logic in traditional coding is transformed into configurable rules. Users can set the number of retries, intervals, and post-failure behavior in the node attributes; when a node fails, the engine automatically retryes according to the strategy. If it ultimately fails, the node is skipped, a structured alarm is generated, and a safety default value is passed, allowing the process to continue execution. For example, a payment interface node configured with "retries 3 times" will automatically retry until successful when encountering network fluctuations. If it ultimately fails due to service downtime, the node is skipped and a detailed error log is recorded, while the process can still continue to execute subsequent notification nodes, thereby ensuring the resilience and continuity of core business processes when some services fail.

[0050] In some embodiments, the method further includes: providing a synchronous call mode, configuring a unique identifier for each process and exposing it as a RESTful API, whereby external callers trigger execution via HTTP requests and synchronously obtain results; or providing an asynchronous call mode, integrating all processes with message queues, whereby external callers send a message to a specified message queue, listen to the specified message queue and execute the process asynchronously, and notify the external caller via callback or by sending a result message upon completion.

[0051] Specifically, in synchronous call mode, the platform automatically publishes each process as a standard RESTful API. External systems can trigger execution in real time and synchronously obtain structured results by passing parameters via HTTP requests. This is suitable for business scenarios requiring immediate feedback (such as real-time order verification). In asynchronous call mode, the platform is deeply integrated with message queues (such as RabbitMQ). External systems can trigger the process by sending messages to a specified topic. The engine listens and executes asynchronously. Upon completion, the caller can be notified via a preset callback URL or result topic. This is suitable for time-consuming or decoupled batch processing (such as report generation and data synchronization). These two modes together achieve process service-oriented architecture and flexible deployment, enabling configurable integration logic to seamlessly adapt to the technology stacks and real-time requirements of different callers. This ensures convenient interaction while improving system throughput and reliability.

[0052] In some embodiments, the integrity and logical verification of the directed acyclic graph data structure is performed by combining the functions of control nodes and data nodes with the JSON Schema description of service nodes. This includes: checking for unclosed branches, isolated nodes, and directed cycles; verifying the input and output data types based on the JSON Schema description of each functional node; performing syntax parsing and variable existence verification on the SpEL expressions of branch nodes and assignment nodes to ensure that the referenced field paths exist in the JSON Schema description of the preceding functional node; and marking all abnormal functional nodes that are unreachable from the starting functional node using a graph reachability algorithm and generating dead path hints.

[0053] Specifically, the process first performs graph structure validation to check for unclosed branches, isolated nodes, or directed cycles, ensuring the process is logically a complete and executable directed acyclic graph. Second, it performs type safety validation, verifying the compatibility of data fields passed between nodes in terms of name and type (e.g., string, integer) based on the JSON Schema metadata of each service node. Next, it performs expression validity validation, parsing the SpEL expressions in branch conditions and assignment rules, and verifying whether the variables they reference are explicitly defined in the output schema of the corresponding preceding node. Finally, it performs graph reachability analysis, marking dead nodes that are unreachable from the starting node and alerting the user. For example, if a user configures a branch with a condition that is always false, all nodes within it will be marked as unreachable; or if an assignment node attempts to assign "username" to "order amount," type validation will directly report an error. This mechanism intercepts many logical and type errors that traditionally only surface at runtime during development, up to the design and configuration stage, greatly improving the success rate and reliability of process configuration and reducing later debugging and maintenance costs.

[0054] In some embodiments, the method further includes: during the integrity and logic verification process, pushing the start time, end time, input / output size, and exception information of each functional node to a monitoring system based on Prometheus and Grafana to achieve process-level visual monitoring.

[0055] This embodiment constructs an observability system for the platform. By embedding tracking points into the process execution engine, it automatically collects the start and end timestamps of each functional node's execution (for calculating time consumption), the size of input and output data packets (for monitoring data traffic), and execution status and exception information (such as "success" and "failure: connection timeout"). These metrics are then converted in real time into formats supported by Prometheus (such as Counter, Gauge, and Histogram) and pushed to its server. Subsequently, Grafana is used to configure dashboards to aggregate and visualize these metrics. For example, it can display the TPS (transactions per second) and average time consumption of each process in real time, drill down to view specific abnormal nodes in a failed process, and monitor the average data volume processed by loop nodes to provide early warnings of performance bottlenecks. This mechanism transforms the runtime state of configurable processes from a "black box" to a "white box," enabling operations personnel to perform performance analysis, root cause location, and capacity planning for zero-code orchestration business processes, just like monitoring traditional coded applications. This achieves the end-to-end observability necessary for enterprise-level applications.

[0056] On the other hand, the present invention also provides a system integration apparatus based on configurable zero-code, including a processor, a memory, and a computer program or instructions stored in the memory, wherein the processor is used to execute the computer program or instructions, and when the computer program or instructions are executed, the apparatus implements the steps of the above method.

[0057] This invention also provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the steps of the aforementioned edge computing server deployment method. The computer-readable storage medium can be a tangible storage medium, such as random access memory (RAM), main memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, floppy disks, hard disks, removable storage disks, CD-ROMs, or any other form of storage medium known in the art.

[0058] In summary, the system integration method and apparatus based on configurable zero-code described in this invention fundamentally transforms the system integration development model by constructing a complete configurable zero-code platform, resulting in significant multi-dimensional technical effects. Regarding development efficiency and lower barriers to entry, the solution encapsulates programming logic such as Feign interface calls, conditional branches, loops, and data transformations into visual nodes, allowing users to orchestrate processes by dragging and dropping connections. This reduces complex integration logic that traditionally required days of coding and debugging to hours or even minutes of configuration work, enabling business personnel or junior developers to directly participate in the construction process, greatly lowering the technical threshold and accelerating business iteration. Regarding logical reliability and maintainability, the solution ensures the clarity and security of data flow by defining strict data object scope rules (sequential visibility, branch isolation, and output constraints); it intercepts logical errors and type conflicts in advance during the configuration phase through static validation based on directed acyclic graphs and JSON Schema (including structure, type, expression, and reachability checks); and the node-level fault handling strategy configuration gives the process built-in resilience. These mechanisms collectively ensure that the configured processes possess the same or even higher robustness and readability as hard-coded processes, making the logic readily apparent and significantly reducing maintenance costs and knowledge transfer risks. In terms of production deployment and operation, the solution publishes processes as standard RESTful APIs or asynchronous message queue tasks, enabling seamless integration as enterprise-level services into existing technology systems. Process-level monitoring based on Prometheus and Grafana provides end-to-end observability from nodes to processes, achieving refined operation and maintenance through performance monitoring, fault location, and capacity analysis. This invention not only addresses the core pain points of low development efficiency, high technical barriers, and complex maintenance in existing technologies, but also transforms system integration from a highly skill-dependent "craft" activity into a standardized, industrialized, and controllable digital asset production process through an integrated design of visual orchestration, strong type validation, structured execution, and end-to-end monitoring. This provides solid technical support for agile business innovation and IT governance in enterprises.

[0059] Those skilled in the art will understand that the exemplary components, systems, and methods described in conjunction with the embodiments disclosed herein can be implemented in hardware, software, or a combination of both. Whether implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this invention. When implemented in hardware, it can be, for example, electronic circuits, application-specific integrated circuits (ASICs), appropriate firmware, plug-ins, function cards, etc. When implemented in software, the elements of this invention are programs or code segments used to perform the desired tasks. The programs or code segments can be stored in a machine-readable medium or transmitted over a transmission medium or communication link via data signals carried in a carrier wave.

[0060] It should be clarified that the present invention is not limited to the specific configurations and processes described above and shown in the figures. For the sake of brevity, detailed descriptions of known methods are omitted here. In the above embodiments, several specific steps are described and shown as examples. However, the method process of the present invention is not limited to the specific steps described and shown. Those skilled in the art can make various changes, modifications, and additions, or change the order of steps, after understanding the spirit of the present invention.

[0061] In this invention, features described and / or illustrated for one embodiment may be used in the same or similar manner in one or more other embodiments, and / or combined with or in place of features of other embodiments.

[0062] The above description is merely a preferred embodiment of the present invention and is not intended to limit the present invention. For those skilled in the art, various modifications and variations of the embodiments of the present invention are possible. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A system integration method based on configuration-based zero-code, characterized in that, The method includes the following steps: The front-end loads a front-end interface provided by the Vue front-end framework, which provides a graphical orchestration interface through the jsPlumb library; the back-end loads a back-end core built on the Spring Boot microservice framework and Spring Cloud microservice system, which manages the addresses and application configurations of each microservice in the service registration and discovery center management platform. Collect and validate the Feign interfaces provided by each project to provide a list of available service nodes for process orchestration and a visual management system to add, delete, modify, and query the Feign interfaces; recursively parse the Java parameter objects and return value objects corresponding to the Feign interfaces into standard JSON Schema descriptions as metadata with strong type validation; The system receives user control commands and allows users to select functional nodes via visual drag-and-drop. These functional nodes include pre-configured control nodes, data nodes, and service nodes selected from the service node list. The control nodes include branch nodes, parallel nodes, and loop nodes. The data nodes include assignment nodes and data processing nodes. The execution order of each functional node is defined by connecting them using the jsPlumb tool to form a control flow and assemble the system's inter-system integration logic. The control flow corresponding to the inter-system integration logic is configured as a directed acyclic graph (DAG) data structure, where vertices represent functional nodes and edges represent the execution order and dependencies between functional nodes. A graph theory-based topological sorting algorithm is used to determine the execution order of the DAG data structure. The integrity and logic of the DAG data structure are verified by combining the functions of the control nodes and data nodes with the JSON Schema description of the service nodes. If the integrity and logic verification pass, the control flow of the inter-system integration logic is serialized into a standardized JSON configuration, stored in the database, and a version number is generated. The JSON configuration includes a unique identifier, the type, configuration parameters, and input / output context of each functional node, as well as the start point, end point, and branch conditions of each edge.

2. The system integration method based on configurable zero-code as described in claim 1, characterized in that, The method further includes: A visual interface is provided for users to manually enter Feign interface information and upload instance JSON messages, and the corresponding JSON Schema description is generated in reverse based on the JSON messages; Configure test parameters, dynamically build a temporary proxy instance on the backend to initiate HTTP test calls, verify whether the response data of the Feign interface conforms to the JSON Schema description, capture network service anomalies, and exclude Feign interfaces with incorrect interface configurations.

3. The system integration method based on configuration-based zero-code according to claim 1, characterized in that, The method further includes: By setting a context manager, the functional nodes are specified to be able to read only the data output by the directly preceding functional nodes to ensure the sequential visibility of the data flow; the data generated inside the parallel branches constructed by the branch nodes is specified to be invisible to other parallel branches to ensure branch isolation; and the operation of the amplitude nodes is specified to be applied to the final output object of the process to ensure output constraints. Each functional node maintains an independent data dictionary, and data is accessed through a unique key of node ID and parameter path.

4. The system integration method based on configurable zero-code according to claim 1, characterized in that, The method further includes: A fault handling strategy is pre-configured for each functional node. When a call fails, it is retried a set number of times. After the set number of retry failures, the functional node that failed to call is skipped and a prompt message is generated.

5. The system integration method based on configurable zero-code according to claim 1, characterized in that, The method further includes: It provides a synchronous call mode, configuring each process with a unique identifier and exposing it as a RESTful API. External callers trigger execution via HTTP requests and synchronously obtain the results. Alternatively, an asynchronous call mode can be provided, integrating all processes with message queues. The external caller sends a message to a specified message queue, listens to the specified message queue, and executes the process asynchronously. After execution, the external caller can be notified via callback or by sending a result message.

6. The system integration method based on configurable zero-code according to claim 1, characterized in that, The integrity and logical verification of the directed acyclic graph data structure are performed by combining the functions of the control node and the data node with the JSON Schema description of the service node, including: Check for open branches, isolated nodes, and directed cycles. Verify the input and output data types based on the JSON Schema description of each functional node; The SpEL expressions of the branch nodes and the assignment nodes are parsed and their variable existence is checked to ensure that the referenced field paths exist in the JSON Schema description of the preceding functional nodes. Using a graph reachability algorithm, all abnormal functional nodes that are unreachable from the starting functional node are marked, and dead path hints are generated.

7. The system integration method based on configurable zero-code according to claim 1, characterized in that, The method further includes: during the integrity and logic verification process, pushing the start time, end time, input / output size, and exception information of each functional node to a monitoring system based on Prometheus and Grafana to achieve process-level visual monitoring.

8. A system integration device based on configurable zero-code, comprising a processor, a memory, and a computer program or instructions stored in the memory, characterized in that, The processor is configured to execute the computer program or instructions, and when the computer program or instructions are executed, the device implements the steps of the method as described in any one of claims 1 to 7.

9. A computer-readable storage medium having a computer program or instructions stored thereon, characterized in that, When the computer program or instructions are executed by a processor, they implement the steps of the method as described in any one of claims 1 to 7.

10. A computer program product, comprising a computer program or instructions, characterized in that, When the computer program or instructions are executed by a processor, they implement the steps of the method according to any one of claims 1 to 7.

Images