A dynamic hub line logic flow development method based on a few code scenarios

Abstract

This invention relates to the field of software development and engineering technology, and discloses a dynamic hub logic flow development method based on a low-code scenario. The method includes setting functional hub points, setting and storing scenarios, setting trigger methods, parsing and operating logic flows, error handling and data set protection, nested and hierarchical management of logic flows, and expanding functional hub points. This invention encapsulates all commonly used business functions of the platform, such as data processing, page interaction, and process control, into nodes. By dragging and dropping to configure the node order and parameters, functional flows that meet business requirements can be quickly built without writing a large amount of code. This allows non-developers to implement business functions through configuration, reducing secondary development workload. It also supports developers to register and customize nodes to further expand the tool's capabilities. This method is suitable for the rapid construction, maintenance, and expansion of enterprise-level business systems, covering the entire business process requirements, including data processing, logic control, front-end interaction, and service integration.

Description

Technical Field

[0001] This invention relates to the fields of software development and engineering technology, and in particular to a method for developing dynamic hub line logic flow based on a low-code scenario. Background Technology

[0002] As enterprises deepen their digital transformation, task management systems need to respond quickly to changing market demands. However, traditional task management system development models have significant pain points: high development barriers, the implementation of task logic relies on professional developers writing code, non-technical personnel cannot directly participate in requirement implementation, resulting in long requirement response cycles, task iteration lagging behind market changes, low functional reusability, the need for repeated development of the same or similar task functions, and the need to modify multiple code locations simultaneously during later maintenance, which not only increases maintenance costs but also easily leads to system failures due to missed modifications. Furthermore, the technology and tasks are tightly coupled, with task logic deeply bound to the underlying technology. When the technical architecture is adjusted, task functions need to be refactored on a large scale, seriously affecting task continuity. To solve these problems, no-code logic flow development technology has emerged. While existing no-code platforms and visual workflow setting technologies can achieve basic workflow setting, they have many problems, such as incomplete coverage of functional scenarios, and most platforms... Focusing on single-function scenarios makes it difficult to cover the full workflow requirements of complex enterprise-level tasks, including "data processing, logical judgment, interactive feedback, and service integration." Log tracing and troubleshooting are inefficient, with workflow operation logs mostly consisting of unstructured text and lacking detailed records at the hub point level. When workflow operations fail, developers cannot quickly locate the root cause of the problem at a specific hub point, requiring manual troubleshooting of each hub point, which is time-consuming and tedious, with an average problem location time exceeding 2 hours. Hub point encapsulation lacks granularity and reusability, remaining mostly at the basic functional level and lacking refined encapsulation for complex scenarios. Triggering methods are singular and have poor scenario adaptability. Existing platforms rely heavily on fixed methods for workflow triggering, lacking flexible triggering mechanisms and failing to support nested calls to logical flows. Complex workflows are redundantly configured. In existing technologies, logical flows typically exist as independent units, making it impossible to achieve a nested structure where "one logical flow calls another logical flow." When a task flow contains multiple recurring sub-flows, the same sub-flow hub points need to be repeatedly set in each main flow, leading to redundancy, maintenance difficulties, rigid scenario adaptability, and conflicts between personalized modifications and version upgrades. In existing technologies, the encapsulated logic flows are mostly general templates, which are difficult to adapt to the personalized needs of different projects. When project requirements are customized based on general logic flows, the modifications usually directly affect the original logic flow template. However, when the system is upgraded, the upgrade program will overwrite the modified logic flow, resulting in the loss of personalized project settings, lack of functional unit hub point expansion and encapsulation capabilities, and limited task adaptability. In existing technologies, the hub point library of logic flows is mostly a fixed functional unit pre-built by the system, lacking a standardized expansion and encapsulation mechanism.When enterprises face special circumstances, they cannot encapsulate these personalized functions as new hubs into the logical flow system. Instead, they can only modify the platform's underlying code or rely on external scripts for invocation. This leads to a disconnect between personalized functions and the logical flow framework, making them difficult to reuse and resulting in high maintenance costs. Furthermore, the lack of a data set rollback mechanism when hubs malfunction easily leads to data set inconsistencies. In existing technologies, if a hub malfunctions during the logical flow operation, the workflow can only be terminated, and the data set of completed hub operations cannot be rolled back. This results in some data sets being modified, while subsequent dependent hubs are not operated, ultimately leading to an incomplete or erroneous data set state. Therefore, there is an urgent need for a development method for dynamic hub line logic flow based on low-code scenarios. Summary of the Invention

[0003] The purpose of this invention is to overcome one or more of the above-mentioned existing technical problems and provide a dynamic hub line logic flow development method based on a low-code scenario.

[0004] To achieve the above objectives, this invention provides a method for developing dynamic hub line logic flow based on a low-code scenario, comprising: In the visual builder, multiple functional hubs can be dragged and connected from the hub library in the drawing board. The functional hubs include at least the data processing hub, logic control hub, front-end interaction hub, service integration hub, tool hub, and system hub. The operation sequence and parameters are set for each functional hub to form the logic flow to be operated. The logic flow is set as one or more of the following: front-end logic flow, server-side logic flow, and front-end and back-end linkage logic flow. The front-end and back-end linkage logic flow is divided into scenarios according to the order of front-end operation, server-side operation, and the remaining front-end operation. The set logic flow is converted into a structured set for storage. The structured set includes at least the logic flow name, front-end settings, server-side settings, and the remaining front-end settings. Connect the logic flow with at least one triggering method, which includes at least one of the following: event triggering generated by user operation, verification interface triggering issued by external system, and platform-preset timed task triggering. When the logic flow is triggered, pass the call parameters containing the logic flow settings and context set to the front end or server end. When the front end is triggered, the front end hub is parsed and operated according to the front end settings, forming a set of data containing the content to be operated on the server side and related parameter identifiers. The set of data is then passed to the server side. The server side queries the corresponding server-side settings according to the parameter identifiers, parses and operates the server-side hubs in sequence. The operation process is recorded when the hubs are modified by adding, updating or deleting the set of data. After the server side completes the operation, it returns the operation result and continues to operate the remaining front end hubs according to the remaining front end settings. During server-side operation, the results of hub point operation are processed in stages based on a preset multi-stage transaction control mechanism. In the initial operation stage, the key data set of the hub point is recorded and modified. In the confirmation stage, the data set is confirmed to be effective when all hub points are successful. In the error stage, rollback processing for the addition, update or deletion operation is triggered to restore the data set to the state before the error occurred. The logical flow operation process records the operation log of each hub point. By referencing other logical flows as sub-flows in the main flow through the sub-flow hub point, the main flow passes initial parameters to the sub-flows, and the sub-flows return the operation results to the main flow. Based on the layered mechanism that combines the basic template and project customization, the project customization content and the basic template are connected through a unique identifier set. Based on standardized verification of the connection interface, register the self-defined function hub point, set the hub point parameters, and add the verified self-defined hub point to the hub point library for use in logic flow settings.

[0005] According to one aspect of the present invention, the data set processing hub includes at least adding a hub, updating a hub, acquiring a single hub, acquiring multiple hubs, and statistically analyzing hubs; When setting up a new hub, the process includes setting the source of the primary data set, selecting the addition method, determining the range of duplicate data sets, determining the duplicate data set identifier item, and the processing method for duplicate data sets. When the source of the primary data set is multiple records and multiple additions are selected, records are added to the target data set table in batch mode. When setting the sub-table data set, if the master-sub-table relationship is one-to-many, both the master data set source and the sub-table data set source are set simultaneously; if the master-sub-table relationship is one-to-one, only the master data set source is set. The duplicate data set identifier is one or more data set items in the target data set table. The data set is determined to be duplicated by comparing the data set item with the corresponding data set item in the existing records in the table.

[0006] According to one aspect of the invention, the logic control hub includes at least a branch hub, a decision hub, and a loop hub; A branch hub is set to have at least two branches, and the conditions within each branch are combined in an AND relationship. When any branch is deleted, all sub-hubs under that branch are automatically deleted. If the conditions are met, the hub point will continue to run along the first operating path; if the conditions are not met, it will continue to run along the second operating path or terminate the movement. After selecting multiple data sets as the primary data set source, the loop hub repeatedly operates the internal flow of the hub. When the number of loops exceeds a preset threshold, an optimization prompt is issued.

[0007] According to one aspect of the present invention, the front-end interaction hub includes at least a dialog box hub, a prompt box hub, a loading process hub, and a close loading process hub; The dialog box hub is used to pop up a confirmation dialog box on the interface with configurable prompts. When the user selects OK, the logic flow continues to operate; when the user selects Cancel, the logic flow terminates. The tooltip hub is used to display only the set of tooltips on the interface without changing the logical flow path. When multiple tooltip hubs are operated at once, only the last set of tooltips is retained for display. Loading process hubs are used to display a loading state that cannot be actively closed during the operation of the logical flow and to restrict page click operations; The load closure hub is used to close the loading state and resume page operations after the logical flow has completed or been interrupted.

[0008] According to one aspect of the present invention, during the page initialization or logic flow loading phase, the server converts the complete server settings into an intermediate description set containing only the operation names and parameter identifiers that the front end needs to recognize, and provides the intermediate description set to the front end. During operation, the front end only transmits operation requests and parameter identifiers related to the server-side operation to the server based on the intermediate description set and the actual generated parameters. After receiving the operation request and parameter identifier, the server searches for the corresponding server settings in the storage medium based on the parameter identifier, parses and executes the corresponding task processing hub.

[0009] According to one aspect of the present invention, in an event triggering method, at least one of the following is preset as triggering a target logic flow: user click operation on the page, modification of the set of interface controls, and change of the flow state; External system triggering method: The external system sends a call request to the server through the verification interface format agreed with the platform, and the server triggers the corresponding logical flow operation after receiving the request; The scheduled task triggering method allows the logic flow to operate automatically at regular intervals, on an hourly, daily, weekly, or monthly basis, by setting the operation cycle and operation time. This is used to complete the data set aggregation and clean up expired data sets.

[0010] According to one aspect of the present invention, the data sets of the data set modification hub points that are added, updated or deleted in the data set are recorded in the transaction log during the operation process. The transaction log is stored in a relational data set database. The transaction log records at least the identifier data set of the corresponding logical flow, the hub point type, the operation time and the key data sets related to the data set modification. When an error occurs, the corresponding set modification operation is reversed according to the transaction log, including deleting the records added before the error, restoring the values ​​of the modified set items before the modification, and restoring the deleted records. Record hub-level operation logs. Hub-level operation logs should include at least the logical flow input parameters, the input parameters and output results of each hub, the start and end times of the operation, the operation status, and the cause of the error. They should also provide query conditions based on time, logical flow name, hub type, and operation status.

[0011] According to one aspect of the present invention, by setting a sub-flow hub point in the main flow, other logic flows are called as sub-flows. When the main flow calls the sub-flow, it passes parameters related to the matter. After the sub-flow completes its operation, it returns the corresponding result to the main flow. The parameter transfer between the main line and the sub-line is set according to a preset correspondence, so that the parameters input by the main line correspond one-to-one with the parameters received by the sub-line, and the output results of the sub-line correspond one-to-one with the results received by the main line. When an error occurs during the operation of a sub-flow, the main flow triggers a rollback operation on itself and the completed data set modification hub points in the sub-flow, so as to maintain transaction consistency between the main flow and the sub-flow.

[0012] According to one aspect of the invention, a logic flow setting applicable to general event scenarios is preset as a basic template; During project implementation, a customized logic flow is generated based on the basic template. Customized project content is formed by adding hub points or adjusting hub point parameters on the basic template. The basic template and each project's customized logic flow are assigned the same set of unique identifiers to represent the connection between the two; During system upgrades, only the basic template is updated, and the unique identifier set is used to maintain the correspondence with the project's customized logic flow, thus preserving the project's customized content from being overwritten during the upgrade process.

[0013] According to one aspect of the present invention, when registering a self-defined hub point, parameters such as hub point type name, unique code, hub point location, application to which it belongs, and whether a setting interface needs to be displayed are set. For self-defined hub points that have been registered, their processing procedures on the front end and the server end are determined according to the preset unified specifications. These procedures should at least include supporting the setting and reading of the hub point's event parameters on the front end, completing the corresponding front end display or interactive processing based on the event parameters during the operation of the workflow, and operating the corresponding event operations on the server end according to the meaning of the hub point's events. In the event of an error, the procedures should support rollback processing based on the transaction control mechanism, so that self-defined hub points and platform-built-in hub points can be set and operated in a unified manner.

[0014] Based on this, the beneficial effects of the present invention are as follows: This application provides a logical flow framework with comprehensive functions, strong scalability and traceable logs, realizes zero-code setting and efficient operation of complex event logic, reduces the development and maintenance costs of enterprise-level event systems, solves the shortcomings of existing public technologies in terms of incomplete functional scenario coverage, integrates composite event functions into a single reusable hub point, and ensures low coupling between the internal logic and the external logic of the hub point, thereby improving the efficiency of modification and reuse. Complete scenario operation logs record the operation status, operation time, start and end time, error cause, and complete context data of the current operation scenario for each hub point, solving the inefficiency of log tracing and problem investigation in existing public technologies. It has refined and distilled many common functional unit hub points, adapting to various scenarios, such as adding a new data set, adding multiple records based on the above hub points, whether to update the operation when adding duplicate data sets, setting the procedure for duplicate data sets, judging the range of duplicate data sets, and whether to update when certain data set items are null. It solves the shortcomings of existing public technologies, such as insufficient granularity of hub point encapsulation and low reusability. In low-code platforms, logic flows can be integrated into any interface and any function, supporting multiple triggering methods such as events, external signals, and scheduled tasks, enhancing the adaptability of logic flows to event scenarios, and solving the shortcomings of existing public technologies, such as single triggering methods and poor scenario adaptability. It allows referencing another logical flow as a sub-flow through a hub point in a logical flow, and supports parameter passing between the main flow and the sub-flow. At the same time, it ensures the operation order and transaction consistency under the nested level, and solves the shortcomings of existing public technologies that do not support nested calls of logical flows and set redundancy in complex flows. The logic flow uses a layered mechanism of "basic template - project customization". During project runtime, personalized logic is superimposed in a customized way to operate the project's personalized logic flow. At the same time, an upgrade compatibility strategy is designed so that when the system is upgraded, only the basic template is updated, while the personalized settings of the project are retained, avoiding overwrite conflicts and solving the rigidity of scenario adaptability of existing public technologies, and the conflict between personalized modifications and version upgrades. It supports dynamic registration of functional unit hub points, sets the parameter setting interface of hub points according to hub point functions, and sets the functional content of hub points according to demand scenarios, thus solving the shortcomings of existing public technologies, such as the lack of functional unit hub point expansion and encapsulation capabilities and limited item adaptation. The data set rollback mechanism based on TCC transaction management records the operation trajectory of hub points involving data set modifications in the logical flow. When an error occurs at a hub point, a reverse operation is automatically triggered to roll back the impact of the already operated hub point to the initial state before the flow started. This solves the problem of the lack of a data set rollback mechanism when hub point errors occur in existing publicly available technologies, which can easily lead to data set inconsistencies. Attached Figure Description

[0015] Figure 1 This is a flowchart illustrating a dynamic hub line logic flow development method based on a low-code scenario, according to an exemplary embodiment. Figure 2 This is a schematic diagram of the logic flow of a dynamic hub line logic flow development method based on a low-code scenario, according to an exemplary embodiment. Figure 3 This is a flowchart illustrating a dynamic hub line logic flow development system based on a low-code scenario, according to an exemplary embodiment. Detailed Implementation

[0016] The invention will now be discussed with reference to exemplary embodiments. It should be understood that the described embodiments are merely intended to enable those skilled in the art to better understand and thus implement the invention, and are not intended to imply any limitation on the scope of the invention.

[0017] As used herein, the term “comprising” and its variations are to be interpreted as open-ended terms meaning “including but not limited to”. The term “based on” is to be interpreted as “at least partially based on”, and the terms “one embodiment” and “an embodiment” are to be interpreted as “at least one embodiment”.

[0018] According to one embodiment of the present invention, Figure 1 This is a flowchart illustrating a dynamic hub line logic flow development method based on a low-code scenario, according to an exemplary embodiment. Figure 2 This is a schematic diagram of the logic flow of a dynamic hub line logic flow development method based on a low-code scenario, as illustrated in an exemplary embodiment. Figures 1-2 As shown, to achieve the above objectives, this invention provides a dynamic hub line logic flow development method based on a low-code scenario, comprising: In the visual builder, multiple functional hubs can be dragged and connected from the hub library in the drawing board. The functional hubs include at least the data processing hub, logic control hub, front-end interaction hub, service integration hub, tool hub, and system hub. The operation sequence and parameters are set for each functional hub to form the logic flow to be operated. Specifically, logical flows can be built by dragging and dropping functional hubs in the visual builder. There are 122 functional hubs in total, covering data set processing, logic control, front-end interaction, service integration, tools, and system categories. Among them, the "Add Hub" of the data set processing category supports setting the main data set source, addition method (single / multiple records), range of duplicate data sets (full table / specified conditions), duplicate data set identifier data set item, and operation type (update / filter). When the main data set source is multiple records and the addition method is "Add Multiple Records", data sets are added to the target worksheet in batches. The "Branch Hub" of the logic control category requires setting at least two branches. The conditions within the branches are "AND" relationships, and the else mode is supported. Deleting a branch automatically deletes all its sub-hubs. The logic flow is set as one or more of the following: front-end logic flow, server-side logic flow, and front-end and back-end linkage logic flow. The front-end and back-end linkage logic flow is divided into scenarios according to the order of front-end operation, server-side operation, and the remaining front-end operation. The set logic flow is converted into a structured set for storage. The structured set includes at least the logic flow name, front-end settings, server-side settings, and the remaining front-end settings. Specifically, three scenarios are defined: front-end logic flow, back-end logic flow, and front-end / back-end linkage logic flow. In the front-end / back-end linkage scenario, the operation follows the sequence of "front-end operation → back-end operation → operation of the remaining front-end parts". The back-end configuration set (serverCnfig) is not transmitted to the front-end; only a cnfig structure containing the front-end method name (name) and parameters (param) is passed. The back-end queries the complete serverCnfig through the parameter index in param. The configured logic flow is converted into JSN format for storage. The JSN structure includes name (logic flow name), frntCnfig (front-end hub point configuration), serverCnfig (back-end hub point configuration), and rearCnfig (remaining front-end hub point configuration). Connect the logic flow with at least one triggering method, which includes at least one of the following: event triggering generated by user operation, verification interface triggering issued by external system, and platform-preset timed task triggering. When the logic flow is triggered, pass the call parameters containing the logic flow settings and context set to the front end or server end. Specifically, it supports multi-dimensional triggering methods, including event triggering, external API triggering, and scheduled task triggering. Event triggering includes user click events, UI control modification events, and workflow state transition events. Front-end calls are implemented by including the ` / webapp / app / cpb / cmmn / pc / js / cmmn.js` file and running the `cmmn.penlink()` method. The method parameters must include at least `link_type` (call type, with values ​​of `cpbeventmethd`), `cnfigjsn` (logic flow JSN setting), and `urlcde` (link point encoding). Back-end calls are implemented through the `CpbLgicFlwServiceBridge.lgicFlwParser(StringsurceAppCde, CpbLgicFlwBcpbLgicFlw)` method, and integration with third-party system APIs is supported. When the front end is triggered, the front end hub is parsed and operated according to the front end settings, forming a set of data containing the content to be operated on the server side and related parameter identifiers. The set of data is then passed to the server side. The server side queries the corresponding server-side settings according to the parameter identifiers, parses and operates the server-side hubs in sequence. The operation process is recorded when the hubs are modified by adding, updating or deleting the set of data. After the server side completes the operation, it returns the operation result and continues to operate the remaining front end hubs according to the remaining front end settings. Specifically, the frontend parses frntCnfig to operate the frontend hub point and passes the operation context set to the backend through the parameter index; the backend queries the complete serverCnfig according to the parameter index, parses and operates the backend hub point, and records the operation trajectory of the hub point modified in the set (added / updated / deleted) during the operation; after the operation is completed, the backend returns the operation result (success / failure) to the frontend, and the frontend parses rearCnfig to operate the remaining hub points. During server-side operation, the results of hub point operation are processed in stages based on a preset multi-stage transaction control mechanism. In the initial operation stage, the key data set of the hub point is recorded and modified. In the confirmation stage, the data set is confirmed to be effective when all hub points are successful. In the error stage, rollback processing for the addition, update or deletion operation is triggered to restore the data set to the state before the error occurred. The logical flow operation process records the operation log of each hub point. Specifically, pivot point errors are handled based on the TCC (Try-Cnfirm-Cancel) transaction mechanism. In the Try phase, the operation trajectory of pivot points that modify sets (including the newly added set ID and the set item value before modification) is recorded to the transaction log. In the Cnfirm phase, the transaction log is deleted. In the Cancel phase, the reverse operation is triggered based on the transaction log (deleting the newly added record and restoring the set item value before modification). The operation log of each pivot point is recorded. The log includes at least the logical flow input parameters, pivot point input parameters, output results, operation start and end time, operation status (success / failure), and error reason. By referencing other logical flows as sub-flows in the main flow through the sub-flow hub point, the main flow passes initial parameters to the sub-flows, and the sub-flows return the operation results to the main flow. Based on the layered mechanism that combines the basic template and project customization, the project customization content and the basic template are connected through a unique identifier set. Specifically, nested logical flow calls are achieved through "sub-flow hub points." The main flow passes initial parameters (such as user ID) to the sub-flow, and the sub-flow returns the operation result (such as permission verification result) to the main flow. When the sub-flow fails, the main flow triggers a Cancel operation for itself and the sub-flow. A layered mechanism of "basic template - project customization" is adopted. The basic template is a pre-built general logical flow for the platform. Project customization adds hub points or adjusts parameters based on the basic template. The project customization content is connected to the basic template through a unique identifier (uniqueid). When the system is upgraded, only the basic template is updated, while the project customization content is retained. Based on standardized verification of the connection interface, register the self-defined function hub point, set the hub point parameters, and add the verified self-defined hub point to the hub point library for use in logic flow settings.

[0019] Specifically, a self-defined hub point is registered through a standardized verification interface. This includes setting the hub point type name, unique code, hub point location (frontend / backend / hybrid), application, whether to display the setting box, JS class name, backend implementation class, and hub point implementation JS path. The frontend implementation needs to inherit the `base` verification interface from `app\cpb\cmmn\pc\js\tls\lgicflw\nde\base.js` and implement the `getCnfigure()` (get settings), `save()` (save hub point settings), and `implement()` (operate hub point logic) methods. The backend implementation needs to inherit the `TccTransactinTask` abstract class and override the `tryEx()` (hub point operation), `cnfirm()` (hub point confirmation), and `cancel()` (hub point rollback) methods.

[0020] According to one embodiment of the present invention, the data set processing hub includes at least adding a hub, updating a hub, acquiring a single hub, acquiring multiple hubs, and statistically analyzing hubs; When setting up a new hub, the process includes setting the source of the primary data set, selecting the addition method, determining the range of duplicate data sets, determining the duplicate data set identifier item, and the processing method for duplicate data sets. When the source of the primary data set is multiple records and multiple additions are selected, records are added to the target data set table in batch mode. When setting the sub-table data set, if the master-sub-table relationship is one-to-many, both the master data set source and the sub-table data set source are set simultaneously; if the master-sub-table relationship is one-to-one, only the master data set source is set. The duplicate data set identifier is one or more data set items in the target data set table. The data set is determined to be duplicated by comparing the data set item with the corresponding data set item in the existing records in the table.

[0021] According to one embodiment of the present invention, the logic control hub point includes at least a branch hub point, a decision hub point, and a loop hub point; A branch hub is set to have at least two branches, and the conditions within each branch are combined in an AND relationship. When any branch is deleted, all sub-hubs under that branch are automatically deleted. If the conditions are met, the hub point will continue to run along the first operating path; if the conditions are not met, it will continue to run along the second operating path or terminate the movement. After selecting multiple data sets as the primary data set source, the loop hub repeatedly operates the internal flow of the hub. When the number of loops exceeds a preset threshold, an optimization prompt is issued.

[0022] According to one embodiment of the present invention, the front-end interaction hub includes at least a dialog box hub, a prompt box hub, a loading process hub, and a close loading process hub; The dialog box hub is used to pop up a confirmation dialog box on the interface with configurable prompts. When the user selects OK, the logic flow continues to operate; when the user selects Cancel, the logic flow terminates. The tooltip hub is used to display only the set of tooltips on the interface without changing the logical flow path. When multiple tooltip hubs are operated at once, only the last set of tooltips is retained for display. Loading process hubs are used to display a loading state that cannot be actively closed during the operation of the logical flow and to restrict page click operations; The load closure hub is used to close the loading state and resume page operations after the logical flow has completed or been interrupted.

[0023] According to one embodiment of the present invention, during the page initialization or logic flow loading stage, the server converts the complete server settings into an intermediate description set containing only the operation names and parameter identifiers that the front end needs to recognize, and provides the intermediate description set to the front end. During operation, the front end only transmits operation requests and parameter identifiers related to the server-side operation to the server based on the intermediate description set and the actual generated parameters. After receiving the operation request and parameter identifier, the server searches for the corresponding server settings in the storage medium based on the parameter identifier, parses and executes the corresponding task processing hub.

[0024] According to one embodiment of the present invention, in the event triggering method, at least one of the following is preset as triggering the target logic flow: user click operation on the page, modification of the set of interface controls, and change of the flow state; External system triggering method: The external system sends a call request to the server through the verification interface format agreed with the platform, and the server triggers the corresponding logical flow operation after receiving the request; The scheduled task triggering method allows the logic flow to operate automatically at regular intervals, on an hourly, daily, weekly, or monthly basis, by setting the operation cycle and operation time. This is used to complete the data set aggregation and clean up expired data sets.

[0025] According to one embodiment of the present invention, the data sets of the data set modification hub points added, updated or deleted in the data set are recorded in the transaction log during the operation process. The transaction log is stored in a relational data set database. The transaction log records at least the identifier data set of the corresponding logical flow, the hub point type, the operation time, and the key data sets related to the data set modification. When an error occurs, the corresponding set modification operation is reversed according to the transaction log, including deleting the records added before the error, restoring the values ​​of the modified set items before the modification, and restoring the deleted records. Record hub-level operation logs. Hub-level operation logs should include at least the logical flow input parameters, the input parameters and output results of each hub, the start and end times of the operation, the operation status, and the cause of the error. They should also provide query conditions based on time, logical flow name, hub type, and operation status.

[0026] According to one embodiment of the present invention, by setting a sub-flow hub point in the main flow, other logic flows are called as sub-flows. When the main flow calls the sub-flow, it passes parameters related to the event. After the sub-flow completes its operation, it returns the corresponding result to the main flow. The parameter transfer between the main line and the sub-line is set according to a preset correspondence, so that the parameters input by the main line correspond one-to-one with the parameters received by the sub-line, and the output results of the sub-line correspond one-to-one with the results received by the main line. When an error occurs during the operation of a sub-flow, the main flow triggers a rollback operation on itself and the completed data set modification hub points in the sub-flow, so as to maintain transaction consistency between the main flow and the sub-flow.

[0027] According to one embodiment of the present invention, a logic flow setting applicable to general event scenarios is preset as a basic template; During project implementation, a customized logic flow is generated based on the basic template. Customized project content is formed by adding hub points or adjusting hub point parameters on the basic template. The basic template and each project's customized logic flow are assigned the same set of unique identifiers to represent the connection between the two; During system upgrades, only the basic template is updated, and the unique identifier set is used to maintain the correspondence with the project's customized logic flow, thus preserving the project's customized content from being overwritten during the upgrade process.

[0028] According to one embodiment of the present invention, when registering a self-defined hub point, parameters such as hub point type name, unique code, hub point location, application to which it belongs, and whether a setting interface needs to be displayed are set. For self-defined hub points that have been registered, their processing procedures on the front end and the server end are determined according to the preset unified specifications. These procedures should at least include supporting the setting and reading of the hub point's event parameters on the front end, completing the corresponding front end display or interactive processing based on the event parameters during the operation of the workflow, and operating the corresponding event operations on the server end according to the meaning of the hub point's events. In the event of an error, the procedures should support rollback processing based on the transaction control mechanism, so that self-defined hub points and platform-built-in hub points can be set and operated in a unified manner.

[0029] According to one embodiment of the present invention, all commonly used functions of the platform (such as data set processing, page interaction, and workflow control) are encapsulated as "hub points." By dragging and dropping to set the order and parameters of the hub points, functional workflows that meet the needs of the tasks can be quickly built without writing a large amount of code. The logic flow can be understood as a "visual method." Each hub point corresponds to an encapsulated "functional unit" (such as "add data set," "page jump," and "conditional judgment"), supports inputting parameters, performing specific operations (such as adding, deleting, modifying, and querying data sets, uploading and downloading files, and initiating workflow processing), and generates return values ​​for subsequent hub points to call. During runtime, the logic flow operates according to the order set by the hub points. If a backend hub encounters an error, it will automatically roll back the already operated datasets (frontend hubs do not have rollback capabilities). If the operation does not meet expectations, the input parameters, hub running status, and error datasets can be viewed through the "Logs" to quickly locate the problem. The logic flow covers all scenario-based task requirements, supporting basic dataset operations (single / multiple dataset queries, statistics, and calculations), logic control (branching, judgment, and looping hubs to implement complex conditions), and integration with frontend interactions (dialog boxes, prompts, loading animations, and showing / hiding), service integration (file services, workflow services, and message services). It can also meet personalized and complex needs through custom JS methods and backend functional hub extensions. Its core value lies in allowing non-developers to implement task functions through configuration, reducing secondary development workload, while supporting developers to register and customize hubs to further expand the tool's capabilities, balancing "configuration efficiency" and "functional flexibility."

[0030] According to one embodiment of the present invention, the transaction log is stored in a relational dataset, and the dataset item includes at least lg_id (log unique identifier), flw_id (logical flow unique identifier), nde_type (hub point type, with values ​​of add / update / delete), execute_time (operation time), and data_id (new dataset unique identifier).

[0031] According to one embodiment of the present invention, the visual constructor includes a drawing board area, a hub point library, a setting panel, and an operation toolbar; the drawing board area is used to drag and drop hub points to build a logical flow, supporting automatic alignment and automatic connection; the hub point library displays 122 functional unit hub points categorized by function, supporting search and filtering; the setting panel is used to set hub point parameters, supporting parameter linkage (e.g., after selecting the "Add Multiple" addition method, the "Batch Data Source" setting item is automatically displayed); the operation toolbar provides functions for saving, copying, zooming in, zooming out, and exporting images (PNG / JPG format); The call triggering mechanism includes a front-end call verification interface unit, a back-end call verification interface unit, and a scheduled task unit. The front-end call verification interface unit provides an implementation of the cmmn.penlink() method to receive front-end trigger requests. The back-end call verification interface unit provides an implementation of the CpbLgicFlwServiceBridge.lgicFlwParser() method to receive trigger requests from the back-end and third-party systems. The scheduled task unit supports setting the operating cycle (by hour / day / week / month) and automatically triggers the logical flow operation. The parsing operation includes a front-end parser, a back-end parser, and a parameter passing unit. The front-end parser parses frntCnfig and rearCnfig, and operates the front-end hub. The back-end parser queries serverCnfig based on the parameter index and operates the back-end hub. The parameter passing unit realizes the secure transmission of the front-end and back-end operation context sets, and avoids serverCnfig being exposed to the front-end. Error handling includes a transaction log unit and a rollback operation unit; the transaction log unit stores the operation trajectory of a set of modified pivot points and supports querying by flw_id; the rollback operation unit triggers reverse operations based on the transaction log when a pivot point error occurs. The logs include a log collection unit and a log query unit; the log collection unit collects hub point operation logs in real time; the log query unit provides a log query interface that supports filtering logs by logical flow name, operation time, hub point type, and operation status. Nested adaptation includes nested management units and hierarchical management units; nested management units maintain the parameter mapping relationship between the main and child circulation paths; hierarchical management units store the uniqueid connection relationship between the basic template and the customized content of the project, and only the basic template set is updated when the system is upgraded; The hub point extension includes a hub point registration unit; the hub point registration unit provides a self-defined hub point parameter setting interface; and implements the verification unit to verify the front-end JS implementation (whether to implement the base verification interface) and the back-end code implementation (whether to inherit TccTransactinTask) to ensure compliance.

[0032] According to one embodiment of the present invention, the visual design can be integrated into any page of the platform. The integration method is to import the file / webapp / app / cpb / cmmn / pc / js / cmmn.js and call the CpbLgicFlwServiceBridge.lgicFlwParser() method. The callback parameter of the method returns the logic flow setting JSN.

[0033] According to one embodiment of the present invention, the log query interface supports exporting logs to Excel format, and the log data set items displayed include logical flow name, trigger time, hub point name, input parameters, output results, operation duration, operation status, and error reason.

[0034] According to one embodiment of the present invention, a logic flow visualization builder and hub point setting are provided. The logic flow visualization builder is the core carrier for achieving zero-code setup, supporting three scenarios (front-end, back-end, and front-end / back-end linkage). It has flexible editing, storage, and integration capabilities. Front-end logic flow: only includes front-end interaction hub points (such as dialog boxes, prompts, and form verification), operating on the browser side; Back-end logic flow: only includes back-end event hub points (such as data set addition, update, and workflow startup), operating on the server side; Front-end / back-end linkage logic flow: operates in the order of "front-end operation → back-end operation → remaining front-end operation". To ensure security, the back-end setting data set (serverCnfig) is not transmitted to the front-end. The connection between the front-end and back-end data sets is only achieved through "front-end method name + parameter index". The back-end queries the complete serverCnfig settings based on the parameter index. Editing and storage functions are provided, and hub point operations: support hub point order adjustment, position dragging, and copying and pasting, which is convenient for developers. Quickly adjust the flow structure; View control: Supports zooming in and out of the entire logic flow, facilitating overall or partial viewing of complex flow patterns; Supports exporting to PNG / JPG format images for document archiving or flow review; Data set storage: The designed logic flow is converted to JSN format and stored in the data set library. The JSN structure clearly distinguishes between front-end and back-end settings, facilitating subsequent parsing and operation; Platform integration method: Include dependency files: Include / webapp / app / cpb / cmmn / pc / js / cmmn.js in the platform page. This file contains the constructor's initialization and interaction logic; Call the open method: Run the CpbCmmn.shwLgicFlwDialg(param,callback) method to open the constructor. Param is the constructor's initialization parameters (such as the default hub point library and flow name), and callback is the save callback function. When the constructor is saved, it will return the logic flow settings in JSN format through this function; According to one embodiment of the present invention, a functional unit hub library is designed. This invention incorporates 122 functional unit hubs, covering all scenario requirements. The design and functions of key hubs are as follows: data set processing hubs... Adding a hub: Supports adding single or batch data sets, allowing you to set the primary data set source, target worksheet, and duplicate data set processing procedures (range, identifier data set item, operation type). When the master and child tables have a one-to-many relationship, both the primary data set source and the child table's primary data set source must be set simultaneously to ensure correct data set connection. Updating a hub: Updates data set item values ​​in the target worksheet based on filter conditions. To ensure data set security, the operation will fail if no filter conditions are set. Supports returning update results (single record as an object, multiple records as a list). Retrieving single / multiple hubs: Queries data sets based on WHERE filter conditions. When retrieving a single hub, if multiple data sets are found, the first one is retrieved; if not found, a new data set can be automatically added. Retrieving multiple hubs... Returns a set of numbers that meet the conditions for use by subsequent hubs (such as loop hubs); Statistical hubs: Perform statistics on the data set items in the target table, supporting count, summation, maximum, minimum, and average calculations. Non-numeric data set items only support summation. Returns 0 when the statistical result is empty; Logic control hubs: Branch hubs: Support setting multiple branch conditions (AND relationship), with nested sub-hubs under each branch; The else branch is executed when all branches are not satisfied, and all sub-hubs under a branch are automatically deleted when a branch is deleted to avoid redundancy; Judgment hubs: Used in conjunction with judgment branches, executing path A when the condition is met, and path B when the condition is not met; if no judgment branch is set, the process terminates if the condition is not met. Stop line; Loop hub: Selects the majority set as the main source, and loops the movement within the hub; when the number of loops exceeds 10, prompts for optimization logic to avoid affecting operational efficiency; Front-end interaction hub, dialog hub: Pops up an inquiry dialog, and the prompt content supports parameter concatenation (such as "Confirm submission of order ${rderId}?"); the user clicks "OK" to continue the operation, and "Cancel" to terminate the movement; Prompt box hub: Only displays the set (such as "Operation successful"), without affecting the movement operation; when multiple prompt boxes are operated at once, only the last one takes effect to optimize the user experience; Loading animation / closing loading animation hub: The loading animation hub displays a loading animation that cannot be closed (the page cannot close the loading animation). (Clicking) requires manual closing via the loading animation hub to avoid repetitive user operations; Service integration hubs, workflow initiation / backend initiation hubs: select the target workflow, pass initiation parameters, and support frontend triggering or backend automatic triggering of the workflow; File upload / download / browse hubs: file upload supports single / multiple files, setting size (MB) and type limits (multiple types are separated by "|"); file download supports adding watermarks and custom filenames; file browsing supports opening in pop-ups or new tabs; Message sending hubs: send reminders according to message templates, supporting parameter replacement (e.g., "${username} submitted for approval", message template settings refer to the platform's message management specifications); According to one embodiment of the present invention, the logic flow is invoked, parsed, and operated. The invocation, parsing, and operation of the logic flow are core components for realizing the functionality of the task, ensuring efficient and secure operation of the workflow: multi-dimensional call triggering: event triggering: automatically triggered when a user clicks a button, modifies a form control value, or changes the workflow status (e.g., approval); external signal triggering: triggered by receiving API requests from third-party systems (e.g., triggering the logic flow after an ERP system pushes a set of order data); scheduled task triggering: automatically operating periodic tasks (e.g., data set aggregation, expired order cleanup) by setting an operating cycle (e.g., 3 AM daily); front-end and back-end parsing and operation of the workflow: data set preparation: during page initialization, the back-end replaces serverConfig. The format is "Front-end method name + parameter index" to avoid exposing sensitive settings (such as database connection and verification interface key) to the front-end. Front-end operation: The front-end parses `frntCnfig`, operates front-end hubs (such as dialog boxes and form verification), and passes the context database to the back-end through the parameter index. Back-end operation: The back-end queries the complete `serverCnfig` based on the parameter index, parses and operates back-end hubs (such as database addition and inventory deduction). During operation, the operation trajectory of database modification hubs is recorded. Result feedback: After the back-end operation is completed, the result is returned to the front-end. The front-end parses `rearCnfig` and operates the remaining hubs (such as prompts). Key code implementation examples and front-end calling code are provided. javascript run / / After including the dependency files, the operation is called. cmmn.penlink({ link_type:"cpbeventmethd", cnfigjsn:'{"name":"Order Submission","frntCnfig":{...},"serverCnfig":{...},"rearCnfig":{...}}', urlcde:"RDER_SUBMIT", datarw:{"rderId":"2024001","amunt":199}, uniquetableid:"rderTable", pkid:"2024001" }); Backend call code: Java run / / Call via service bridge CpbLgicFlwBflwB=newCpbLgicFlwB(); flwB.setFlwCnfigJsn("{\"name\":\"Order Submission\",...}"); flwB.setCntextParam("{\"rderId\":\"2024001\"}"); CpbLgicFlwServiceBridge.lgicFlwParser("RDER_SYSTEM",flwB); 4. Error handling and logging To ensure the reliability of the data set and the traceability of problems, this invention designs a TCC transaction rollback mechanism and a hub-level log: TCC transaction rollback mechanism: Try phase: The core operation of modifying the pivot point of the operational set; Confirm Phase: After all hub points have successfully operated, the operation is confirmed to be effective; Cancel phase: If any pivot point fails, a reverse operation is triggered based on the transaction (such as deleting newly added order records or restoring inventory quantities). Example: In the "Order Payment → Inventory Deduction → Logistics Creation" workflow, if "Logistics Creation" fails, the Cancel stage will perform "Restore Inventory Quantity" and "Delete Order Record" operations to ensure data consistency. Hub-level log entries: Log content includes: logic flow input parameters, input parameters for each hub point, output results, operation start and end time (accurate to milliseconds), operation status (success / failure), and error reason (e.g., "logistics verification connection timeout, error code 504"). Log query: Supports filtering by logical flow name, operation time, hub type, and operation status, and can be exported to Excel format for easy problem location and review; According to one embodiment of the present invention, to reduce redundancy and ensure the security of personalized settings, the present invention designs a nested call and layered mechanism for nested logical flow adaptation. The nested call of logical flows is implemented as follows: other logical flows are referenced as sub-flows through a "sub-flow hub point," the main flow passes parameters (such as user ID) to the sub-flow, and the sub-flow returns the operation result (such as permission verification result); Transaction consistency: when a sub-flow fails, the main flow triggers a Cancel operation on itself and the sub-flow, ensuring the transaction consistency of the entire flow; Advantages: when 10 main flows require the same sub-flow, only one sub-flow needs to be set, and modifications only require adjusting the sub-flow, reducing redundant settings by more than 50%; "Basic Template - Project Customization" layered mechanism: Basic Template: the platform pre-sets general logical flows (such as "single-level approval flow"), which cannot be modified, ensuring universality; Project customization: Projects can add hub points (e.g., add the "Department Head Verification" hub point to Project A) or adjust parameters (e.g., modify the approval number set item) based on the basic template. Customized content is linked to the template through uniqueid; Upgrade compatibility: When the system is upgraded, only the basic template is updated, and the customized content of the project is retained to avoid overwriting conflicts; According to one embodiment of the present invention, the functional unit hub point extended registration supports standardized hub point extended registration to meet personalized needs. Registration parameter settings include: basic parameters: hub point type name (e.g., "Risk Rating Calculation"), unique code (non-repeatable, e.g., "RISK_RATING"), hub point location (front-end / back-end / hybrid), application, and whether to display a setting box; implementation parameters: js class name (front-end implementation object name), back-end implementation class (e.g., "cm.example.nde.RiskRatingTask"), hub point implementation js path (front-end code file address), icon color and icon (uniform color for hub points in the same group to improve recognizability); front-end and back-end implementation specifications: front-end implementation: must inherit the base verification interface of app\cpb\cmmn\pc\js\tls\lgicflw\nde\base.js, and implement the core method: getCnfi `gure()`: Sets the parameters for the hub point (e.g., the "Risk Rating Standard" checkbox); `save()`: Saves the hub point settings to the logic stream JSN; `implement(callback)`: Runs the hub point logic (e.g., calls the risk rating verification interface) and returns the result via `callback`; Backend implementation: Must inherit the `TccTransactinTask` abstract class and override the core methods: `tryEx(TccTransactinTaskCntexttaskCntext)`: Runs the core tasks of the hub point (e.g., calculates the risk rating); `cnfirm(TccTransactinTaskCntexttaskCntext)`: Confirms the operation (called when there are no errors); `cancel(TccTransactinTaskCntexttaskCntext)`: Rolls back the operation (called when there are errors, such as deleting the risk rating record); According to one embodiment of the present invention, the logic flow has the following built-in functional hubs: close, entry, branch, delete, form verification, prompt box, end logic flow, judgment, dialog box, send message, custom JS method, return value, statistics, delete, update, jump to edit page, save, workflow start, task view, procedure, broadcast, task handling, workflow view, update form control, get single item, delete schedule, loop, judgment branch, data set packaging, cell editing, workflow extended data set item update, Wrd export, get multiple items, refresh selection (check) hub, get data set package, workflow event branch, Excel import, get data set, tree list selected row, department selection box, file update, add / modify schedule, deduplication, list delete, Excel export, personnel selection box, attachment control browsing, image control browsing, workflow item data set item update, tree selected hub, circulation unread, circulation read, file upload, clear cache, file download, custom verification, message template, add, file browsing, function, multiple file browsing, list selected row, refresh. Select hub point (click), backend startup of the movement path, initialization, tree list row selection (check), logic flow return value, movement path parameter settings, calculation, refresh tree, role selection box, delete tree hub point, update hub point, add tree hub point, global refresh, list refresh, project statistics dataset, deselect list, download attachment control, form center, validity of selected row, whether row is selected, control verification, auto-encoding, send dataset, open collaboration, variable, set variable, loop end, js load, movement path print, string function, add row to list, object function, file signature preview, file signature design, list update, signature selection box, cancel logic flow, collaborators, SQL operation, copy dataset, open comment, detail dataset, get department dataset, get personnel dataset, get bank account dataset, delete hub point row dataset, movement path dataset version check, return true, loading animation, close loading animation, general selection box, add attachment dataset, permission item, list dataset, backend deletion of movement path, add row dataset to list, form print, lightweight and form print; Entry Type Hub Point: Entry Hub Point; Use case: Use this hub when you need to open a specific entry page; Description: After navigating to the selected entry point and operating the entry point hub, if the navigation method is a pop-up, the logic flow will wait for the pop-up to close before continuing to operate, and the return value of the entry page can be used; Entry Name: Select the entry point to jump to; Redirection method: Set the entry point opening method, such as opening a pop-up window, opening a new page, etc.; Data set transfer: Click to add parameters, set parameter encoding, value, etc., and the set parameters will be appended to the entry address; Return value: Set the entry return value format for use by subsequent hub points. The return value is received from the return value of the closed hub point in the second-level page, or the set of windw.returnValue in the custom js. The set format must be the same as the setting. Component type pivot point: branch pivot point; Description: Different hubs operate depending on different conditions; When using branch hubs, at least two branch hubs must be set; When the conditions set within a branch hub are met or not set, the hub under the current branch hub will operate. The conditions within the branch pivot point are AND relationships; A branch hub point under the same group can pass through multiple branch hub points; When a branch hub is deleted, all sub-hubs under the current hub are also deleted. else mode: If all branch operations fail, the else mode hub is executed. Only one else mode hub can be set under the current branch group. Determine the pivot point: Description: Can be used in conjunction with conditional branches; true executes A, false executes B.

[0035] If the conditions set within the hub point are met or not set, operate the hub point under the current hub point; otherwise, terminate the current movement path. If no decision branch is set, the current movement will end when the decision hub fails. Dialog box pivot point: Description: To ask questions during operation.

[0036] Prompt message: The content of the pop-up dialog box on the front end, which supports parameter concatenation; The process continues if the user clicks "OK," otherwise the current navigation is terminated. When used in conjunction with determining branch hub points, click "OK" to confirm the operation through the hub point, and click "Cancel" to cancel the operation without passing through the hub point. The key point of the prompt box; Description: Note the difference from dialog boxes. This hub will only display the set set of numbers and will not affect the operation of the logical flow.

[0037] Prompt display methods: Supports prompt effects and pop-up effects, etc.

[0038] Prompt content: The content of the prompt box, which supports parameter concatenation; Note: To optimize user experience, when running multiple pop-up windows at once, only the last pop-up window's hub will be activated. Message hub; Description: Sends message notifications based on the message template.

[0039] After selecting a message template, the message is sent according to the message template. The message template parameter can be replaced. Message template settings: Please refer to the relevant documentation for message template settings; End logic flow hub point; Description: This hub does not need to be set. When the operation reaches the current hub, the logic flow will terminate.

[0040] Note: Using this pivot point within a loop will not end the current logic flow; it will only skip this loop. The key point for judgment; Description: Determines whether there are duplicate sets of numbers based on conditions. Returns true if duplicates are found, and false if no duplicates are found. Can be used in conjunction with conditional branches. Circulation hub point; Description: Selecting multiple data sets will cause the loop to iterate through the pivot points within the loop. Note that you should consider operational efficiency when setting this up. If the loop exceeds 10 times, it is recommended to use functional pivot points. For logic that is not complex inside the loop or for logic with low operational efficiency requirements, the loop count limit can be manually adjusted. The source of the principal set: The set of numbers to be iterated over must be multiple sets of numbers; Variable pivot point; Description: Declare a variable that can be used in conjunction with setting a variable pivot point to modify the return value of the current pivot point. The effect is the same as declaring another variable in the code, such as: var x={a:1,b:2}; Set the variable pivot point; Description: Used in conjunction with variable pivots to modify declared variables; String functions; Target string: The string to be manipulated; Function: position(indexf); Description: Finds the index of a substring within a string; returns -1 if not found. Function: length; Description: Gets the length of the current string; Function: Convert to uppercase; Description: Converts all English letters in the current string to uppercase and returns a new string; Function: Convert to lowercase (lwer); Description: Converts all English letters in the current string to lowercase and returns a new string; Function: Replace string; Description: Replace the string to be replaced with a new string according to the settings; Replace All: When full replacement is enabled, all characters in the target string that are to be replaced will be replaced with new characters; otherwise, only the first occurrence will be replaced. Function: substring; Description: Extract a substring from a target string based on its index; Function: parse to object; Description: Converts the JSN string into an object for use by subsequent pivot points in the logic flow; Object functions; Target object: Select the object to be manipulated; Function: Convert to string; Description: Converts the target object to a string format; Function: Concatenate strings across multiple lines; Description: Performs a loop concatenation of a set of items in a target object; Cancel logical flow; Description: When the operation reaches this hub point, the logic flow will end and all operation sets of the current logic flow will be rolled back; Loading animation; Description: When the process reaches this hub, a loading animation will be displayed, and the page will be unclickable. Note: This animation will not disappear on its own. Turn off the loading animation; Description: Turns off loading animations displayed via loading animations. Note: This hub can only turn off loading animations displayed via the "Loading Animation Hub". General service: WRD export; Data set processing hub: Add a new hub; Worksheet: Select the main table for the newly added data set; Main Data Set Source: Select the main data set source to add to the worksheet. After selection, the data set items and data set settings will be automatically matched. Description: When adding a sub-table to a table set, if the master-sub-table relationship is one-to-many, the master set source and the sub-table master set source must be set; otherwise, only sub-tables with a one-to-one relationship can be selected.

[0041] Adding methods: Add one new record or add multiple records based on multiple records. When the main data set source is multiple records and the adding method is set to add multiple records, the data set will be added to the worksheet in batches.

[0042] Operation type: Update or filter duplicate sets; Duplicate set range: Only the set range is checked for duplicates. If not specified, the entire table will be checked for duplicates. Duplicate set identifier: Based on the set items, compare them with the set items of the original set in the table. Sets with the same set items are considered duplicate sets. Update hub point; Description: Updates the set of data items based on the specified filtering conditions; Worksheet: Select the table to update; Filtering conditions: Set the filtering conditions for the dataset to be updated; Update data set item: Set the data set item to be updated; Returning a set of data: The return value when the first item is returned can be used as an object; otherwise, it can be used as a list. Note: If no update conditions are set, the update hub will fail to operate for data set security. Acquire multiple hub points; Description: Based on the set filtering conditions, search for a data set, and the searched data set can be used by subsequent hub points; Worksheet: Select the table to query; Filtering conditions: WHERE query conditions; Get a single hub point: Description: Based on the set filtering conditions, find a single data set. The found data set can be used by subsequent hub points. If multiple data sets are found, take the first data set as the hub point return value. Worksheet: Select the table to query; Filtering conditions: WHERE query conditions; If not found, add a new set in the object: If no set is found or multiple sets are found, add a new set to the current worksheet for use by subsequent pivot points. The setting method is the same as adding a new pivot point. Operational hub: Description: Supports calculations on time and numerical values, with the results used for subsequent pivot point numerical operations; Statistical hub; Description: Performs statistics on the data set items in the current table. The return value is a numeric type and supports counting, summation, maximum, minimum and average values. For non-numeric data set items, only the summation function is supported. If the data set is empty, it returns 0.

[0043] Update form controls: Description: Modify the value of controls on a form.

[0044] Broadcast hub: Description: After setting the broadcast type, a broadcast will be sent, and the set parameters will be transmitted. After setting the broadcast encoding, the broadcast receiver will be set in the form, and the data set will be pushed to the broadcast receiver.

[0045] Traffic flow initiation: Workflow list: Select the workflow to start; Startup parameters: The startup path consists of the parameters that are passed. View the movement route: Item primary key: The item primary key that sets the workflow; Task handling: Description: Process tasks based on the item / task key; Rear-end start of traffic flow: Workflow list: Select the workflow to start; Item primary key: Workflow item primary key; Startup parameters: The startup path consists of the parameters that are passed. Task View: Description: Based on the processing mode, set the corresponding parameters and open the task viewing page; Note: Workflow is not mandatory, but it must be specified in scenarios where the primary key of a multi-path instance item is repeated. Traffic flow event branches: It is generally used in all events of the traffic flow, and different logics are executed according to different events; Traffic flow printing: Description: Prints the movement path. After printing, the return value format is: {fileid:"ssid"}; Workflow list: Select the workflow to print; Flow instance id: The flow instance to be printed; Traffic flow data set: Inheritance, Display, Do not display; Processing opinion: Inheritance, show, do not show; List built-in pivot point: Selected row in the list: Description: No settings are required; it can be used as a dataset source. When the list is for single selection, it is in object mode; when multiple selections are selected, it is in list mode. List refresh: Description: Static refresh of the current list; List updated: Description: This feature only supports setting the pivot point on a column; no conditions need to be set. The update condition is the primary key of the current row. Cell editing: No settings are required by default. Settings are set when double-clicking to edit a list cell. Settings need to be set on the "Edit or not edit" button after the column is opened. Note: If the primary key or other settings of the main list table change, this hub point needs to be deleted and re-added. Select row: Description: If the selected set in the list is empty, the operation will fail, and a prompt will be displayed according to the prompt content.

[0046] The prompt message is displayed in the pop-up window when the selected set of numbers is in the list. Selected row validity: Description: If the selected set in the list fails the comparison based on the comparison conditions, it will be deselected from the list. The logic flow will end depending on the settings, and a prompt will be displayed according to the prompt content.

[0047] Comparison criteria: Select a row validity comparison procedure, such as, the a set item cannot be equal to 1; Prompt message: Failed. Add rows to the list: Description: Add a blank line to the list; Add a new tree hub: Description: This hub point does not operate on the data set. It is generally used in conjunction with saving or adding hub points. After adding a tree hub point data set in the data set library, set the target hub point ID and the new hub point ID, and add a sibling or child hub point to the target hub point in the general tree. If the target hub point ID is not set, the currently selected hub point will be used as the target hub point. Select the pivot point in the tree: Description: No settings are required; it can be used as a dataset source. When the tree is single-selection, it is in object mode; when multiple selections are selected, it is in list mode. File upload service: Description: Upload files and add a new item set, and the file set parameter can be used in the current hub point; Worksheet: A table that stores a set of document items; Upload modes: single file, multiple files; Single attachment mode: Attachments need to be displayed in the form using an attachment control; File size limit: Single file size limit, in MB; File type restrictions: Allowed file types, multiple types separated by |, e.g., jpg|png|txt; File download: Description: Download the file based on the selected file ID; Watermark content: Add a watermark to the downloaded file and set the watermark content; Download modes: Supports downloading multiple files and single files; File ID: The ID of the file to be downloaded. When downloading multiple files, the file ID can be a List parameter. Custom filenames are supported during download. However, when downloading multiple files, only custom file package names are supported. File browsing: Jump methods: How to jump to other pages when browsing files, such as pop-ups, opening new tabs, etc.; File ID: The ID of the file to be previewed; Multi-file browsing: Jump methods: How to jump to other pages when browsing files, such as pop-ups, opening new tabs, etc.; File ID browsing: Once enabled, no scheme needs to be set; simply pass in a set of file IDs. File browsing encoding: The file browsing encoding needs to be set in advance (it needs to be set by default). File ID: This setting needs to be set after the file ID browsing mode is enabled. Multiple file IDs can be set, or file IDs can be separated by commas. Default file ID: If this option is set, the multi-file browsing page will select the file with the current ID by default; File update: Description: Updates the original file and the corresponding dataset records in the original file; Worksheet: The table in the dataset to be updated; Filtering criteria: Find the data set records that correspond to the original file based on the filtering criteria; Original file ID: The ID of the original file to be updated; Size limit: The maximum file size for new files; File type restrictions: Restrictions on the types of files that can be created for new files; Update set items: The set items to be updated in the set records corresponding to the original file; Note: File size is limited to MB. When restricting multiple file types, use "|" as a separator, such as jpg|png|txt. When setting filter conditions, ensure that the filtered dataset contains exactly one record; otherwise, the update will fail.

[0048] According to one embodiment of the present invention, Figure 3 This is a flowchart illustrating a dynamic hub line logic flow development system based on a low-code scenario, according to an exemplary embodiment. Figure 3 As shown, to achieve the above objectives, this invention provides a dynamic hub line logic flow development system based on a low-code scenario, comprising: Functional hub setting module: Through the visual builder, multiple functional hubs can be dragged and dropped from the hub library in the drawing board and connected. The functional hubs include at least the data processing hub, logic control hub, front-end interaction hub, service integration hub, tool hub and system hub. The operation sequence and parameters are set for each functional hub to form the logic flow to be operated. Scene setting and setting storage module: The logic flow is set as one or more of the following: front-end logic flow, server-side logic flow, and front-end and back-end linkage logic flow. The front-end and back-end linkage logic flow divides the scene according to the order of front-end operation, server-side operation, and the remaining front-end operation. The set logic flow is converted into a structured set for storage. The structured set includes at least the logic flow name, front-end settings, server-side settings, and the remaining front-end settings. Triggering method setting module: Connects the logic flow with at least one triggering method. The triggering method includes at least one of the following: event triggering generated by user operation, verification interface triggering issued by external system, and timed task triggering preset by the platform. When the logic flow is triggered, it transmits call parameters containing the logic flow settings and context set to the front end or server. Logic Flow Parsing and Operation Module: In response to the front end being triggered, the module parses and operates the front end hub points according to the front end settings, forming a set of data containing the content to be operated on the server side and related parameter identifiers. This set of data is then passed to the server side. The server side queries the corresponding server-side settings according to the parameter identifiers, parses and operates the server-side hub points in sequence. The operation process is recorded when the hub points are modified by adding, updating or deleting the data set. After the server-side operation is completed, the operation result is returned. The remaining front end hub points are then operated according to the remaining front end settings. Error handling and data set protection module: During the operation on the server side, the hub point operation results are processed in stages based on the preset multi-stage transaction control mechanism. In the initial operation stage, the key data set of the hub point is recorded. In the confirmation stage, the data set is confirmed to be effective when all hub points are successful. In the error stage, the rollback processing for the addition, update or deletion operation is triggered to restore the data set to the state before the error occurred. The operation log of each hub point is recorded during the logical flow operation process. Logic Flow Nesting and Layered Management Module: By using the sub-flow hub point, other logic flows are referenced as sub-flows in the main flow. The main flow passes initial parameters to the sub-flows, and the sub-flows return the operation results to the main flow. Based on the layered mechanism that combines the basic template and project customization, the project customization content and the basic template are connected through a unique identifier set. Functional hub point extension module: Based on standardized verification interface registration, self-defined functional hub points are set, hub point parameters are set, and verified self-defined hub points are added to the hub point library for logic flow setting and calling.

Claims

1. A method for developing dynamic hub line logic flow based on a low-code scenario, characterized in that, include: In the visual builder, multiple functional hubs can be dragged and connected from the hub library in the drawing board. The functional hubs include at least the data processing hub, logic control hub, front-end interaction hub, service integration hub, tool hub, and system hub. The operation sequence and parameters are set for each functional hub to form the logic flow to be operated. The logic flow is set as one or more of the following: front-end logic flow, server-side logic flow, and front-end and back-end linkage logic flow. The front-end and back-end linkage logic flow is divided into scenarios according to the order of front-end operation, server-side operation, and the remaining front-end operation. The set logic flow is converted into a structured set for storage. The structured set includes at least the logic flow name, front-end settings, server-side settings, and the remaining front-end settings. Connect the logic flow with at least one triggering method, which includes at least one of the following: event triggering generated by user operation, verification interface triggering issued by external system, and platform-preset timed task triggering. When the logic flow is triggered, pass the call parameters containing the logic flow settings and context set to the front end or server end. When the front end is triggered, the front end hub is parsed and operated according to the front end settings, forming a set of data containing the content to be operated on the server side and related parameter identifiers. The set of data is then passed to the server side. The server side queries the corresponding server-side settings according to the parameter identifiers, parses and operates the server-side hubs in sequence. The operation process is recorded when the hubs are modified by adding, updating or deleting the set of data. After the server side completes the operation, it returns the operation result and continues to operate the remaining front end hubs according to the remaining front end settings. During server-side operation, the results of hub point operation are processed in stages based on a preset multi-stage transaction control mechanism. In the initial operation stage, the key data set of the hub point is recorded and modified. In the confirmation stage, the data set is confirmed to be effective when all hub points are successful. In the error stage, rollback processing for the addition, update or deletion operation is triggered to restore the data set to the state before the error occurred. The logical flow operation process records the operation log of each hub point. By referencing other logical flows as sub-flows in the main flow through the sub-flow hub point, the main flow passes initial parameters to the sub-flows, and the sub-flows return the operation results to the main flow. Based on the layered mechanism that combines the basic template and project customization, the project customization content and the basic template are connected through a unique identifier set. Based on standardized verification of the connection interface, register the self-defined function hub point, set the hub point parameters, and add the verified self-defined hub point to the hub point library for use in logic flow settings.

2. The method for developing dynamic hub line logic flow based on a low-code scenario as described in claim 1, characterized in that, Data set processing hubs include at least adding hubs, updating hubs, acquiring a single hub, acquiring multiple hubs, and statistically analyzing hubs; When setting up a new hub, the process includes setting the source of the primary data set, selecting the addition method, determining the range of duplicate data sets, determining the duplicate data set identifier item, and the processing method for duplicate data sets. When the source of the primary data set is multiple records and multiple additions are selected, records are added to the target data set table in batch mode. When setting the sub-table data set, if the master-sub-table relationship is one-to-many, both the master data set source and the sub-table data set source are set simultaneously; if the master-sub-table relationship is one-to-one, only the master data set source is set. The duplicate data set identifier is one or more data set items in the target data set table. The data set is determined to be duplicated by comparing the data set item with the corresponding data set item in the existing records in the table.

3. The method for developing dynamic hub line logic flow based on a low-code scenario as described in claim 2, characterized in that, A logic control hub must include at least a branch hub, a decision hub, and a loop hub. A branch hub is set to have at least two branches, and the conditions within each branch are combined in an AND relationship. When any branch is deleted, all sub-hubs under that branch are automatically deleted. If the conditions are met, the hub point will continue to run along the first operating path; if the conditions are not met, it will continue to run along the second operating path or terminate the movement. After selecting multiple data sets as the primary data set source, the loop hub repeatedly operates the internal flow of the hub. When the number of loops exceeds a preset threshold, an optimization prompt is issued.

4. The method for developing dynamic hub line logic flow based on a low-code scenario as described in claim 3, characterized in that, Front-end interaction hubs include at least dialog hubs, prompt hubs, loading process hubs, and close loading process hubs. The dialog box hub is used to pop up a confirmation dialog box on the interface with configurable prompts. When the user selects OK, the logic flow continues to operate; when the user selects Cancel, the logic flow terminates. The tooltip hub is used to display only the set of tooltips on the interface without changing the logical flow path. When multiple tooltip hubs are operated at once, only the last set of tooltips is retained for display. Loading process hubs are used to display a loading state that cannot be actively closed during the operation of the logical flow and to restrict page click operations; The load closure hub is used to close the loading state and resume page operations after the logical flow has completed or been interrupted.

5. The method for developing dynamic hub line logic flow based on a low-code scenario as described in claim 4, characterized in that, During the page initialization or logic flow loading phase, the server converts the complete server-side settings into an intermediate description set that only contains the operation names and parameter identifiers that the front-end needs to recognize, and provides the intermediate description set to the front-end. During operation, the front end only transmits operation requests and parameter identifiers related to the server-side operation to the server based on the intermediate description set and the actual generated parameters. After receiving the operation request and parameter identifier, the server searches for the corresponding server settings in the storage medium based on the parameter identifier, parses and executes the corresponding task processing hub.

6. The method for developing dynamic hub line logic flow based on a low-code scenario as described in claim 5, characterized in that, Event triggering method: at least one of the following is preset as the triggering target logic flow: user click operation on the page, modification of the set of interface controls, and change of the flow state; External system triggering method: The external system sends a call request to the server through the verification interface format agreed with the platform, and the server triggers the corresponding logical flow operation after receiving the request; The scheduled task triggering method allows the logic flow to operate automatically at regular intervals, on an hourly, daily, weekly, or monthly basis, by setting the operation cycle and operation time. This is used to complete the data set aggregation and clean up expired data sets.

7. The method for developing dynamic hub line logic flow based on a low-code scenario as described in claim 6, characterized in that, The data sets that are added, updated, or deleted in the data set modification hub are recorded in the transaction log during the operation process. The transaction log is stored in a relational data set database. The transaction log records at least the identifier data set of the corresponding logical flow, the hub point type, the operation time, and the key data sets related to the data set modification. When an error occurs, the corresponding set modification operation is reversed according to the transaction log, including deleting the records added before the error, restoring the values ​​of the modified set items before the modification, and restoring the deleted records. Record hub-level operation logs. Hub-level operation logs should include at least the logical flow input parameters, the input parameters and output results of each hub, the start and end times of the operation, the operation status, and the cause of the error. They should also provide query conditions based on time, logical flow name, hub type, and operation status.

8. The method for developing dynamic hub line logic flow based on a low-code scenario as described in claim 7, characterized in that, By setting sub-flow hubs in the main flow, other logic flows can be called as sub-flows. When calling the sub-flow, the main flow passes parameters related to the task, and the sub-flow returns the corresponding result to the main flow after the operation is completed. The parameter transfer between the main line and the sub-line is set according to a preset correspondence, so that the parameters input by the main line correspond one-to-one with the parameters received by the sub-line, and the output results of the sub-line correspond one-to-one with the results received by the main line. When an error occurs during the operation of a sub-flow, the main flow triggers a rollback operation on itself and the completed data set modification hub points in the sub-flow, so as to maintain transaction consistency between the main flow and the sub-flow.

9. The method for developing dynamic hub line logic flow based on a low-code scenario as described in claim 8, characterized in that, Set a default template for the logic flow that is applicable to general scenarios; During project implementation, a customized logic flow is generated based on the basic template. Customized project content is formed by adding hub points or adjusting hub point parameters on the basic template. The basic template and each project's customized logic flow are assigned the same set of unique identifiers to represent the connection between the two; During system upgrades, only the basic template is updated, and the unique identifier set is used to maintain the correspondence with the project's customized logic flow, thus preserving the project's customized content from being overwritten during the upgrade process.

10. The method for developing dynamic hub line logic flow based on a low-code scenario as described in claim 9, characterized in that, When registering a self-defined hub point, set parameters such as hub point type name, unique code, hub point location, application to which it belongs, and whether to display the settings interface. For self-defined hub points that have been registered, their processing procedures on the front end and the server end are determined according to the preset unified specifications. These procedures should at least include supporting the setting and reading of the hub point's event parameters on the front end, completing the corresponding front end display or interactive processing based on the event parameters during the operation of the workflow, and operating the corresponding event operations on the server end according to the meaning of the hub point's events. In the event of an error, the procedures should support rollback processing based on the transaction control mechanism, so that self-defined hub points and platform-built-in hub points can be set and operated in a unified manner.

Images