A dynamic orchestration method based on field-level declarative dependency and related equipment

Abstract

This invention discloses a dynamic orchestration method and related equipment based on field-level declarative dependencies, relating to the field of business data processing technology. The method includes: receiving a business change message; parsing the business change message and extracting the changed fields where data updates have occurred; determining at least one target business node affected by the changed fields based on the predefined declaration information of multiple business nodes; performing topological sorting on all target business nodes to generate an execution sequence; and sequentially executing each target business node in the execution sequence to output updated data. This invention can identify the target business nodes affected by the changed fields, avoiding calls to irrelevant nodes and changing the original full-process calculation mode to a dynamic orchestration mode triggered by changed fields. This directly reduces unnecessary calculation steps and external interface calls, lowers load and resource consumption, and enhances adaptability to complex business scenarios while ensuring timely data output.

Description

Technical Field

[0001] This invention relates to the field of business data processing technology, and in particular to a dynamic orchestration method and related equipment based on field-level declarative dependencies. Background Technology

[0002] As the company's business continues to expand, the number of waybills has increased significantly, and the scenarios involving changes in waybill attributes have become increasingly complex. This has led to frequent daily repetitive calculations required for the single-way cost module. The current real-time calculation process for single-way costs is complex, with high coupling between various business metrics. This results in any attribute change triggering a recalculation of all metrics across the entire process, causing significant redundant computations and resource waste. The existing real-time calculation process suffers from complex logical layers and frequent calls to multiple external interfaces, resulting in an extremely high daily computational load. The excessive number and volume of calls to external system interfaces not only affect the stability of other related systems but also easily lead to data backlogs during concurrent triggering in multiple scenarios. This, in turn, causes delays in data processing within this module, preventing timely delivery of results to downstream systems and severely impacting data output efficiency and analysis timeliness.

[0003] To address these issues, the industry typically seeks program frameworks or solutions capable of dynamic orchestration at the field level. These frameworks aim to automatically identify dependencies and orchestrate execution nodes based on changes in upstream attributes, reducing unnecessary dependencies and API calls. Within the Java ecosystem, existing mainstream technologies offer varying degrees of support for this. For example, workflow engines organize task execution through predefined complete processes; rule engines organize business logic through specific syntax rules; and orchestration frameworks like LiteFlow attempt to support field-level declarative dependency management.

[0004] However, the existing technical solutions mentioned above all have obvious limitations and cannot completely solve the problems of accurate orchestration and redundant calculation. They still face many challenges in real-time computing scenarios with high coupling, high redundancy, and high load. Therefore, there is an urgent need for an innovative method that can perform accurate and dynamic orchestration based on field changes. Summary of the Invention

[0005] The technical problem to be solved by this invention is to address the shortcomings of existing technologies. Specifically, it provides a dynamic orchestration method and related equipment based on field-level declarative dependencies, as detailed below: 1) In a first aspect, the present invention provides a dynamic orchestration method based on field-level declarative dependencies, the specific technical solution of which is as follows: Receive business change messages; parse the business change messages and extract the changed fields where data updates have occurred; determine at least one target business node affected by the changed fields based on the declaration information of multiple predefined business nodes; the declaration information of each business node includes the dependency fields that the business node depends on and the output fields that the business node will produce after execution; perform topological sorting on all target business nodes to generate an execution sequence; execute each target business node in the execution sequence in sequence and output the updated data.

[0006] The beneficial effects of the dynamic orchestration method based on field-level declarative dependencies provided by this invention are as follows: By receiving and parsing business change messages to extract change fields, the system can directly respond to specific changes in upstream data, thereby enabling dynamic construction of the execution chain. This overcomes the limitation of workflow engines requiring predefined, fixed processes, giving the orchestration process the flexibility to adapt to changing business scenarios. Target business nodes are determined based on predefined node declaration information, achieving declarative dependency management. The relationship between dependency fields and output fields is automatically parsed, and affected nodes are deduced, eliminating the need for additional coding of dependency resolution logic, reducing development complexity and the barrier to entry, and making it easier to develop and maintain compared to rule engine solutions. By filtering target business nodes based on change fields and performing topological sorting to generate an execution sequence, it ensures that only nodes truly affected by data updates are executed. This differs from mechanisms that trigger nodes solely based on the existence of fields, eliminating redundant calculations at the source and improving processing efficiency and resource utilization. Nodes in the sequence are executed sequentially, and updated data is output, forming a precise and streamlined data processing path. The entire process reduces unnecessary business node executions and external interface calls, directly reducing system load and pressure on external systems, effectively alleviating data backlog and output delays, and improving overall stability and data processing timeliness.

[0007] Based on the above scheme, the dynamic orchestration method based on field-level declarative dependencies of the present invention can be further improved as follows.

[0008] Furthermore, based on the predefined declaration information of multiple business nodes, at least one target business node affected by the changed field is determined, including: selecting business nodes from all business nodes whose dependent field has a direct dependency relationship with the changed field as first-type target business nodes; selecting business nodes that depend on the output field of each first-type target business node as second-type target business nodes; all target business nodes include first-type target business nodes and second-type target business nodes.

[0009] The beneficial effects of adopting the above-mentioned further solution are as follows: by classifying the business nodes affected by the changed fields into first-class and second-class target business nodes, the scope of the change's impact can be identified more systematically. The first-class nodes ensure that nodes directly affected by the source change are captured, while the second-class nodes, through dependency output fields, include nodes further upstream and downstream in the change's impact chain. This hierarchical and progressive identification method makes the final determined execution chain more complete, effectively avoiding data update omissions due to broken dependency chains, and improving the accuracy of dynamic orchestration results.

[0010] Furthermore, from all business nodes, business nodes with direct dependencies between dependent fields and change fields are selected as the first type of target business nodes, including: determining the business node to which the target dependent field belongs as a business node with a direct dependency relationship, and the target dependent field being a dependent field that contains the change field.

[0011] The beneficial effects of adopting the above-mentioned further solution are: by identifying the target dependency fields, the direct impact points of the change are accurately found, ensuring that business nodes that have a direct dependency relationship with the changed fields are effectively captured, laying the foundation for building an accurate execution sequence.

[0012] Furthermore, the process of filtering and identifying business nodes that depend on the output fields of each first-type target business node as second-type target business nodes includes: obtaining the output fields of all first-type target business nodes to form a first set of output fields; determining whether the dependent fields of each business node other than the first-type target business nodes contain at least one output field in the first set of output fields; and identifying business nodes whose dependent fields contain output fields in the first set of output fields as second-type target business nodes.

[0013] The beneficial effect of adopting the above-mentioned further solution is that when an upstream node executes due to a change and generates new output fields, all downstream nodes that depend on these new fields can also be automatically included in the execution sequence. This achieves the automatic propagation and aggregation of the impact of changes in the node network, avoiding the complexity of manually managing multi-layered dependencies and ensuring the integrity and consistency of data update logic.

[0014] Furthermore, a topological sort is performed on all target business nodes to generate an execution sequence, including: determining the dependency relationships between target business nodes based on the output fields and dependency fields of each target business node; and performing a topological sort on all target business nodes associated with the dependency relationships to generate a linear execution sequence.

[0015] The beneficial effects of adopting the above-mentioned further solution are: it ensures that all business nodes with sequential constraints can be linearly arranged according to their logical dependencies. The execution order of nodes strictly matches the business logic, fundamentally preventing data calculation errors or inconsistencies caused by disordered node execution order, and guaranteeing the correctness of the final data update result.

[0016] Furthermore, it also includes: during the topology sorting process, placing target business nodes that have no dependencies at the front of the execution sequence.

[0017] The beneficial effects of adopting the above-mentioned further approach are: placing target business nodes with no dependencies at the front of the execution sequence optimizes the overall execution flow. These independent nodes can execute immediately without waiting for other nodes to complete, thereby freeing up computing resources in advance and potentially preparing data for subsequent nodes. This process optimizes the structure of the execution sequence, helps reduce the idle waiting time of some nodes, and improves the overall execution efficiency and resource utilization of the orchestration process.

[0018] Furthermore, the business change message is parsed to extract the changed fields that have been updated, including: deserializing the business change message to obtain structured data; validating the structured data; and extracting the fields associated with the business scenario corresponding to the business change message from the valid structured data as the changed fields.

[0019] The beneficial effects of adopting the above-mentioned further solution are: after deserializing and validating the business change message, the change fields are extracted, providing a high-quality and reliable input foundation for subsequent processes. Deserialization ensures the structured and readable nature of the message data; validity verification filters out invalid messages with format errors or missing key information, preventing abnormal data from interfering with the orchestration process. This step enhances the robustness of the input end, ensuring that the dynamic orchestration process begins with accurate and complete change information, and improving the stability and reliability of the entire method.

[0020] 2) In a second aspect, the present invention also provides a dynamic orchestration system based on field-level declarative dependencies, the specific technical solution of which is as follows: It includes a receiving module, a parsing module, a determining module, a generating module, and an execution module. The receiving module receives business change messages. The parsing module parses the business change messages and extracts the changed fields that have been updated. The determining module determines at least one target business node affected by the changed fields based on the declaration information of multiple predefined business nodes. The declaration information of each business node includes the dependency fields that the business node depends on and the output fields that the business node will produce after execution. The generating module performs topological sorting on all target business nodes to generate an execution sequence. The execution module executes each target business node in the execution sequence sequentially and outputs the updated data.

[0021] 3) In a third aspect, the present invention also provides an electronic device, the electronic device including a processor coupled to a memory, the memory storing at least one computer program, the at least one computer program being loaded and executed by the processor, so that the electronic device implements any of the above-mentioned dynamic orchestration methods based on field-level declarative dependencies.

[0022] 4) In a fourth aspect, the present invention also provides a computer-readable storage medium on which a computer program is stored, and when the computer program is executed by a processor, it implements any of the above-mentioned dynamic orchestration methods based on field-level declarative dependencies.

[0023] It should be noted that the beneficial effects of the technical solutions of the second to fourth aspects of the present invention and their corresponding possible implementations can be found in the above description of the technical effects of the first aspect and its corresponding possible implementations, and will not be repeated here. Attached Figure Description

[0024] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments of the present invention will be briefly introduced below: Figure 1 This is a flowchart illustrating a dynamic orchestration method based on field-level declarative dependencies according to an embodiment of the present invention. Figure 2 This is a diagram of the real-time computing architecture of dynamic orchestration nodes corresponding to a dynamic orchestration method based on field-level declarative dependencies according to an embodiment of the present invention. Figure 3 Example diagram of business nodes; Figure 4 Real-time calculation of timing diagrams for business nodes; Figure 5 This is a schematic diagram of the business message data processing flow; Figure 6 A schematic diagram illustrating data interaction for a single business node; Figure 7This is a schematic diagram of the structure of a dynamic orchestration system based on field-level declarative dependencies according to an embodiment of the present invention; Figure 8 This is a schematic diagram of the structure of an electronic device according to an embodiment of the present invention; Detailed Implementation

[0025] The principles and features of the present invention are described below. The examples given are only for explaining the present invention and are not intended to limit the scope of the present invention.

[0026] The technical solution of the present invention and how the technical solution of the present invention solves the above-mentioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of the present invention will now be described with reference to the accompanying drawings.

[0027] like Figure 1 As shown, an embodiment of the present invention provides a dynamic orchestration method based on field-level declarative dependencies, comprising the following steps: S1. Receive service change messages. The specific implementation process is as follows: S10. Deploy and start one or more message listeners. These listeners continuously listen to one or more pre-configured message middleware queues or topics. The message middleware can be, for example, Apache Kafka, RabbitMQ, or RocketMQ. The listeners establish and maintain network connections with the message middleware, subscribe to specific topics related to business change events, such as topics named "financial_discount_topic" or "waybill_update_topic," and prepare to receive production messages published by external systems.

[0028] S11. When data changes or business events occur in external business systems, such as when the finance system completes a discount operation on a shipping order, the external system will publish a business change message describing the change to the corresponding message middleware topic according to the data format and protocol agreed upon by both parties. The message middleware is responsible for the persistent storage, routing, and distribution of the message, ensuring reliable message delivery.

[0029] S12. The deployed message listener detects new messages arriving in the queues or topics it is listening to in real time. The message listener then calls the consumption interface provided by the message middleware client to retrieve this new business change message from the message middleware server. This process typically involves network data transmission, transferring the message from the message middleware server to memory or a buffer.

[0030] S13. After successfully retrieving the data stream of the business change message, the message listener can immediately return a consumption confirmation response to the message middleware. This confirmation response informs the message middleware that the message has been successfully received, and the message middleware can then update the message consumption status to prevent the message from being delivered repeatedly. This mechanism ensures the reliability of message delivery and is part of the "at least once" or "exact once" semantic guarantee.

[0031] S14. The message listener encapsulates the received raw message data into an internal data object or message context. This object contains the raw byte content of the message, the message's unique identifier, the message's source subject, and possible message attributes or header information. After encapsulation, the data object is submitted or passed to the subsequent parsing step, i.e., step S2 in the technical solution, thereby triggering the subsequent extraction of modified fields and dynamic orchestration process.

[0032] In another possible implementation, the specific implementation process of S1 is as follows: ① Deploy and initialize a network service endpoint, which is specifically used to receive business change messages sent by external systems. The network service endpoint can be a RESTful API interface bound to a specific host address and port. ② After the waybill attributes are updated or a financial discount business operation is completed, the external business system immediately assembles the business change message describing the change into a complete HTTP request body according to the predefined JSON data format of both parties, and sends it over the network calling system's API interface address. ③ The network service listening component continuously monitors the endpoint. When a new HTTP request is detected, it first performs basic verification on the request, including confirming that the request method is POST and verifying identity credentials and digital signatures to ensure the legitimacy of the request source. ④ After the basic verification is passed, the listening component completely reads the byte data from the body of the HTTP request. This byte data is the original encoded content of the business change message. ⑤ The read raw byte data is temporarily stored in a thread-safe memory queue, and an HTTP response indicating successful reception is immediately sent to the external system, thereby completing the network-level interaction. ⑥ An internal message scheduler retrieves the raw data of business change messages sequentially from the memory queue, packages them into a standard-format internal event object, and retains all the information of the business change message in the event object. Then, it triggers the subsequent process of parsing the business change message.

[0033] Among them, business change messages are structured data carriers used to asynchronously notify systems of the occurrence of specific business events and accompanying data update details. They are typically generated and sent proactively by upstream external business systems after completing a business operation, such as waybill discounts, status updates, or attribute adjustments. The message content follows a predefined format and protocol, such as JSON or Protobuf, encapsulating key data fields strongly related to the specific business scenario, such as waybill number, discount type, and discount amount. This data serves as the direct basis and input source for triggering downstream dynamic orchestration calculations.

[0034] S2. Parse the business change message and extract the changed fields where data updates occurred, specifically including: S20. Deserialize the business change message to obtain structured data. The specific implementation process is as follows: S200: Obtain the input from the preceding "Receiving Service Change Message" step. This input is the raw representation of the service change message, typically a byte sequence or string with a specific encoding format. Then, specify the specific data serialization protocol followed by the service change message to be processed. This protocol is agreed upon in advance with the upstream message sender. For example, it is agreed that the payload of the service change message will be serialized in JSON format. Protocol information can be embedded in the metadata of the service change message or loaded from the local configuration based on the message source or type.

[0035] S201. Based on the identified serialization protocol, load or initialize the corresponding deserialization processor. For example, if the protocol is JSON, a JSON deserializer instance such as Jackson ObjectMapper or Fastjson Parser will be initialized. This deserialization processor is pre-configured with necessary settings, such as date format, null value handling strategy, and custom modules for mapping fields. Then, the original byte sequence or string of the business change message is taken as input and parsed and transformed according to the predetermined data serialization protocol rules. Taking JSON format as an example, the processor will parse the string, identify JSON objects, key-value pairs, arrays, and other structures, and map JSON key-value pairs to the attribute fields of the Java class based on a predefined Java class as the target type template. This process includes conversion from strings to basic data types such as numbers and booleans, and may also include the recursive construction of nested objects.

[0036] During the deserialization mapping process, strict syntax checks and type compatibility verifications are performed. If the original format of the business change message does not conform to the JSON syntax specification, or if the value of a certain field cannot be converted to the type declared by the target Java class attribute, the deserialization processor will throw a clear exception, such as JsonParseException or JsonMappingException, indicating that the deserialization process has failed and the process has terminated.

[0037] S202. If the deserialization process completes successfully, a fully instantiated Java object existing in memory will be obtained. This object is the "structured data". Its data structure is well-defined; each data item corresponds to an attribute of the object. The attribute has a name and a specific data type. The program can directly access the specific field value through the object's getter methods, such as obtaining the waybill number through the getWaybillNumber() method. This structured data object is output and handed over to the subsequent "validation of structured data" step for processing.

[0038] In another possible implementation, the specific implementation process of S20 is as follows: ① Obtain the raw binary data of the business change message from the upstream receiving component. This data is a byte array. ② Parse the fixed-length message header of the business change message. The message header contains a protocol version identifier and a message type code, which are used to indicate the serialization protocol and corresponding data structure definition used in the subsequent message body. ③ Query the local registry according to the protocol version identifier and load the matching Protocol Buffers message definition description file. This description file defines the name, type, and order of each field in the message body. ④ Call the Protocol Buffers deserialization library to decode the data of the message body part in the byte array of the business change message according to the loaded message definition description file, restore the data field by field, and fill it into a newly created Java object instance. ⑤ The deserialization library will automatically verify the syntax compliance of the data during the decoding process, such as whether the field format matches and whether the required fields exist. If an error is encountered, an InvalidProtocolBufferException exception will be thrown. ⑥ After successful decoding, a fully initialized Java object with clearly defined fields and types is obtained. This object is the required structured data, which is then passed to the step of validating the structured data.

[0039] Structured data refers to information with a predefined data model or format, organized in a way that allows computer programs to explicitly understand, access, and process each data component. In the context of this technical solution, it specifically refers to the data object formed in memory after a business change message has been deserialized, conforming to the class definition of a specific programming language. The data within this object is decomposed into multiple discrete, meaningful fields, each with a clear name and data type, such as a string representing a waybill number or a numeric representing a discount amount. Compared to unstructured raw byte streams or text strings, structured data provides a standardized, type-safe access interface for subsequent program logic.

[0040] S21. Perform legality verification on structured data. The specific implementation process is as follows: S210. Based on the business scenario type corresponding to the current structured data object, load the predefined set of validation rules for that scenario. The business scenario type can be identified from a specific field in the structured data object, such as a field named `bizType` with the value `FINANCIAL_DISCOUNT`. The set of validation rules defines the constraints for all relevant fields under this scenario. Then, iterate through the list of fields marked as "required" in the set of validation rules, such as waybill number and discount amount. Retrieve the values ​​of these fields from the structured data object using reflection or by calling getter methods, and check if each value exists. The conditions for checking existence include: not null for object references, not null and not an empty string for strings, and not null for numeric types. If the value of any required field is empty, record a validation failure error containing the specific field name.

[0041] S211. Based on the validation rules, perform format matching and logical judgment on the content of specific fields in the structured data object. For example, for the waybill number field, the rule may require it to match a specific length pattern consisting of numbers and letters, using regular expressions for matching and validation. For the discount amount field, the rule may require it to be a value greater than zero, and the value will be checked to see if it meets the condition of being greater than zero. For the discount type field, the rule may require its value to belong to a predefined enumeration set, such as "spend more than enough" or "discount", and the value will be checked to see if it is within the allowed list. Furthermore, based on the rules, check whether the logical relationships between multiple fields within the structured data object are reasonable. For example, a rule may require that if the discount type is "spend more than enough", then the "spend more than enough threshold amount" field must exist and be positive, and the "discount amount" must be less than the "spend more than enough threshold amount". These relevant field values ​​will be extracted from the structured data object and compared to verify whether the conditions are met.

[0042] S212. After all the above verification steps are completed, all generated verification error information will be collected. If the error information set is empty, it indicates that the structured data has passed all validity checks, and this structured data object will be allowed to proceed to the next step, namely, "extracting the fields associated with the business scenario corresponding to the business change message from the structured data that has passed the verification, and using them as the change fields." If the error information set is not empty, the business change message is considered invalid, and the process will be terminated. All detailed error information will be recorded, and a strategy will be used to determine whether to return a response containing an error description to the message source.

[0043] In another possible implementation, the specific implementation process of S21 is as follows: ① A dynamic verification execution plan is generated for the structured data object based on a predefined verification rule base. The verification rule base stores a mapping relationship with business scenarios as keys and a set of verification functions as values; ② Based on the field value that identifies the business scenario in the structured data object, the corresponding verification function chain is retrieved from the verification rule base. Each verification function is an independent executable unit that specifically verifies a particular constraint; ③ A verification context is created, and the current structured data object is loaded into the context as input. The first verification function in the verification function chain is executed sequentially. This function is responsible for checking whether the waybill number field meets the length and character set requirements. It reads the waybill number character set in the verification context. The system performs several checks: 1) It applies logical judgments to the segment value and writes the results into the context; 2) It executes each subsequent validation function in sequence. These functions check rules such as whether the discount amount is positive, whether the discount type is in the enumeration list, and whether the logic of related field combinations is self-consistent; 3) After each validation function is executed, a success flag or a failure record containing error details is added to the validation context environment based on the check results; 4) After all the pre-defined validation functions are executed, the results summary in the validation context environment is reviewed. If there are no failure records, the structured data is determined to have passed the validity check and is allowed to enter the stage of extracting changed fields; if there are one or more failure records in the validation context environment, the validation is determined to have failed, the process is terminated, and an error report is generated based on the failure records.

[0044] S22. Extract the fields associated with the business scenario corresponding to the business change message from the validated structured data and use them as the change fields. The specific implementation process is as follows: S220. Read a specific attribute from the structured data object. This attribute is used to explicitly identify the specific business scenario to which this business change message belongs. For example, read the attribute named `businessScenario`, whose value can be "FINANCIAL_DISCOUNT" or "VEHICLE_DEDUCTION". This business scenario identifier is the logical basis for subsequent field extraction. Then, based on the identified business scenario identifier, query a predefined scenario-field mapping configuration library. This configuration library records which fields, in each business scenario, indicate that data has been updated and need to be considered by subsequent dynamic orchestration processes. For example, for the "financial discount" scenario, the mapping configuration might specify "billing discount", "total discount amount", "discount type", and "waybill number" as key fields.

[0045] S221. Obtain a list of predefined key field names for the current business scenario. Then, the program iterates through each field name in this list. For each field name, the current value is retrieved from the structured data object using reflection or by directly calling the corresponding Getter method. For example, based on the field name "totalDiscountAmount", the getTotalDiscountAmount() method is called. It is necessary to determine whether the retrieved current field value truly represents an "update". The judgment logic depends on the business convention. A common implementation is to query the original value of the corresponding field of the business object (e.g., waybill) from the database or cache based on a unique identifier such as the waybill number, and compare the current value with the original value. If they are not equal, it is determined that the field has changed. Another implementation relies on the message producer's annotation; that is, the structured data may contain an independent flag indicating which fields are the carriers of this change. Fields confirmed to have undergone data updates are collected. A standard "changed field" internal representation object is created for each such field, which at least contains the field name and its new value.

[0046] S222. After all predefined key fields have been traversed and processed, the collected internal representation objects of all "Change Fields" are assembled into a set. This set is the final output of this step, namely the "Change Fields" set. This set will serve as the core input for the subsequent step of "determining at least one target business node affected by the Change Fields based on the declaration information of multiple predefined business nodes," driving the initiation of the entire dynamic orchestration process.

[0047] The phrase "fields associated with the business scenario corresponding to the business change message" refers to data items whose numerical changes directly reflect the core content of the current business operation and potentially trigger a series of downstream chain calculations within the business operation context. Each business scenario, such as "financial discount business" or "vehicle offset business," has its own set of such fields. These are subsets filtered and identified from the complete business change message load, serving as a crucial bridge connecting upstream business events with downstream on-demand calculations. For example, in the "financial discount business" scenario, changes in the "discount amount" field are directly related to the recalculation of costs and profits, thus making it a field associated with this business scenario. The purpose of extracting these fields is to accurately capture the source of data changes, avoid including unchanged data in the processing flow, and thereby achieve incremental and precise dynamic orchestration.

[0048] S3. Based on the predefined declaration information of multiple business nodes, determine at least one target business node affected by the changed fields; the declaration information of each business node includes the dependency fields that the business node depends on and the output fields that the business node will generate after execution.

[0049] The process involves extracting declaration information from multiple predefined business nodes based on business logic. The specific implementation process is as follows: 1) System architects or developers need to systematically analyze all the business processes handled by the target system. Here, business logic refers to the operations or calculation units that the system needs to complete and that have clear business value, such as "calculating waybill costs," "applying financial incentives," and "accruing sales wages." The focus of the analysis is to identify which business logics have high cohesion, meaning that their internal calculations or operations are closely related, and their inputs and outputs can be clearly described by a set of data fields.

[0050] 2) Based on the analysis results of the above steps, each identified highly cohesive business logic unit is further broken down into one or more indivisible, functionally independent execution units. Each such unit is defined as a business node. The principle of decomposition is to ensure that each business node undertakes only one clear responsibility, such as "querying the database to obtain the order details," "calling an external interface to verify customer information," or "calculating the discount rate according to the formula." A complex business logic (such as "processing financial discounts") may be broken down into multiple sequentially executed business nodes such as querying, calculating, and updating.

[0051] 3) Define declaration information for each business node. Create a structured declaration message for each business node. This declaration message is a metadata description and must contain three core parts: ① Dependency fields: Explicitly list all input data fields necessary for the business node to execute its internal logic. These fields are prerequisites for node execution; for example, a compute node might need two dependency fields: "original price" and "discount rate". ② Output fields: Explicitly list the data fields that will be generated or updated after successful execution of the business node. This represents the node's output; for example, the output field for the compute node mentioned above might be "actual payment amount". ③ Execution logic identifier: Associate or describe the implementation of the specific calculation, query, or processing logic within the business node in some form (such as pointing to a Java class name, a function name, or a script identifier).

[0052] 4) Define and save the declaration information of all business nodes in a unified and persistent format (such as JSON, XML, or stored in a specific table in the database). Upon startup or when needed, all declaration information will be loaded from these storage media, parsed, and cached in memory to form a global "business node declaration information registry," which can be queried and retrieved by subsequent dynamic orchestration processes when it is necessary to determine target business nodes and dependencies.

[0053] In another possible implementation, the process of predefined declaration information for multiple business nodes includes: ① Initializing a node declaration scanner during application startup; the scanner scans the specified Java package path according to the configuration and automatically discovers all classes that implement specific business node interfaces or are marked with specific annotations; ② For each discovered class, the scanner reads the custom annotations declared on it through Java reflection, which define the unique identifier, dependency field list, and output field list of the current business node; the scanner parses the dependency field list in the annotation, converting it into a formal dependency field set, and parses the output field list into an output field set; ③ Instantiating a business node declaration information object based on the read information, storing the dependency field set, output field set, and class references corresponding to the business node execution logic into this object; registering all instantiated business node declaration information objects into a global, in-memory business node declaration information registry; this registry indexes all declaration information, for example, creating a reverse index from output fields to business node declaration information to support fast queries; ④ When the dynamic orchestration process needs to obtain the predefined business node declaration information, it directly queries this in-memory registry. The advantages of this implementation are as follows: By leveraging the annotation and reflection mechanisms of programming languages, the declaration information of business nodes is directly embedded in the implementation code of business logic, achieving high cohesion between declaration and implementation, avoiding inconsistencies that may arise from maintaining independent configuration files, and reducing configuration management costs; a one-time scan and loading of the memory index at startup makes the query speed of declaration information extremely fast when running dynamic orchestration, improving the efficiency of orchestration decisions; at the same time, this code annotation-based approach is more in line with the programming habits of developers, making it easier to manage and find in the integrated development environment, improving the development experience and code maintainability.

[0054] The declaration information for each business node also includes the calculation formula used by that business node. For example, in the declaration information for the business node "Calculate: Total Net Receipt," in addition to explicitly stating its dependent fields as "Business Adjustment Fee," "Bill Discount," and "Enterprise Vehicle Insurance Coverage," and its output field as "Total Net Receipt," it also includes the specific calculation formula used when this business node is executed: "Total Net Receipt = Business Adjustment Fee + Bill Discount + Enterprise Vehicle Insurance Coverage." This calculation formula is stored in the declaration information in the form of a parsable expression, clearly defining the mathematical mapping relationship from dependent fields to output fields, serving as a precise description of the data processing logic within the business node.

[0055] In this context, a business node is an atomic unit with independent computational or processing capabilities, formed by decomposing elements based on domain logic. Each business node encapsulates a specific business operation, such as querying batch details of consolidated orders from a database or calculating the discount rate for waybills. In the technical solution, the business node is the basic execution unit of dynamic orchestration, and its inputs and outputs are clearly defined through fields.

[0056] In this context, a dependency field is an input data item that a business node needs to complete its internal logic. It is predefined in the business node's declaration information, specifying the data source required for the calculation. For example, the "Calculate: Total Revenue" business node might declare its dependency fields as "Business Adjustment Fee," "Bill Discount," and "Enterprise Vehicle Minimum Guarantee." It must be ensured that the values ​​of these dependency fields are ready in the global context before executing this node.

[0057] Output fields are the data items that a business node outputs after completing its internal logic processing. Each business node explicitly defines its output fields, which represent the calculation results of that node. For example, the output field of the "Calculate: Discount Rate" business node is "Discount Rate". The value of the output field is updated in the global context after the node is executed, so that other business nodes that depend on this field can use it.

[0058] Among them, all target service nodes include both type I and type II target service nodes. Specifically, S3 includes: S30. From all business nodes, select business nodes whose dependent fields and change fields have a direct dependency relationship as the first type of target business nodes.

[0059] Wherein, all first-category target business nodes include business nodes with direct dependencies, then S30 specifically includes: S300. Determine the business node to which the target dependency field belongs as a business node with a direct dependency relationship. The target dependency field is a dependency field that includes the change field. The specific implementation process is as follows: S3000: Traverse the "declaration information" of all loaded "business nodes" in memory. Each "business node's" "declaration information" explicitly lists the "dependency fields" that the "business node" depends on. While traversing each "business node," the system compares the "dependency field" list of that "business node" with the input set of "change fields." The purpose of this comparison is to identify "business nodes" whose "dependency field" list contains any one of the "change fields."

[0060] S3001. When a field is found in the "Dependency Fields" list of a "Business Node" whose name is exactly the same as a field in the "Change Fields" set, a "Target Dependency Field" is identified. For example, a "Business Node" named "Calculate: Discount Rate" has a "Dependency Fields" list containing "Shipping Time," "Discounted Shipping Cost," and "Total Discount Amount." If the "Change Fields" set contains "Total Discount Amount," then "Total Discount Amount" is the "Target Dependency Field" of this "Business Node." This "Business Node" identified as containing the "Target Dependency Field" is marked as a "Business Node" with a "Direct Dependency Relationship" to this change. This means that the calculation logic of this "Business Node" directly uses the field whose value has changed, and its calculation result will inevitably change due to this change.

[0061] S3002. Collect all the "business nodes" marked as having "direct dependencies" to form a list or set. This set is the part of the "first type of target business nodes" that belongs to the "business nodes with direct dependencies". This result will be used as an intermediate output and merged with the "business nodes with indirect dependencies" found in subsequent steps to form the complete "first type of target business nodes".

[0062] Indirect dependencies describe a non-direct influence relationship passed through one or more intermediate fields. In this technical solution, it specifically refers to the dependency relationship between a business node and a changed field, where the business node does not directly use the changed field as input, but the value of a field it depends on changes due to changes in the changed field. This relationship needs to be revealed by analyzing the computational or logical influence chain between the fields.

[0063] The fields affected by the changed fields refer to those data fields whose values ​​change accordingly in terms of data logic or calculation relationships as the values ​​of one or more changed fields change. These relationships are based on predefined business rules or calculation formulas. For example, in waybill cost calculation, changes in the discount amount will affect the total revenue received, and thus the gross profit. The set of these fields is determined by traversing the field dependency graph, and they serve as the basis for identifying indirectly dependent business nodes.

[0064] In another possible implementation, the specific implementation process of S30 is as follows: ① During the initialization phase, load the declaration information of all predefined business nodes and construct a global field dependency transitive closure matrix. The rows of this matrix represent all business nodes, and the columns represent all possible fields. The values ​​in the matrix indicate whether there is a direct or transitive dependency relationship between the business node and the field. The construction process analyzes the dependent fields of each business node and recursively searches which other business nodes produce these dependent fields until no further transitivity is possible, thereby calculating the complete indirect dependency chain. ② When the process reaches the filtering step, obtain the set of changed fields of the current input. Then, map this set of changed fields to the column dimension of the global field dependency transitive closure matrix. Perform column filtering on the matrix to select all columns corresponding to changed fields. ③ Perform a logical OR operation on these selected columns, merge all column vectors, and generate a new row vector. Each element in this new row vector corresponds to a business node, and an element value of true indicates that the business node is at least directly or indirectly dependent on a field in the set of changed fields. ④ Traverse this new row vector and extract all business nodes marked as true. These extracted business nodes are formally identified as the first type of target business nodes, and this set of nodes is passed as output to subsequent steps for further screening of the second type of target business nodes.

[0065] S31. Filter and designate business nodes that depend on the output fields of each first-category target business node as second-category target business nodes, specifically including: S310. Obtain the output fields of all first-type target business nodes to form a first output field set. Determine whether the dependency fields of each business node other than the first-type target business nodes contain at least one output field in the first output field set. Select business nodes whose dependency fields contain output fields from the first output field set as the second-type target business nodes. The specific implementation process is as follows: S3100. Initialize an empty collection data structure to hold the output fields to be collected. This data structure will be named "First Output Field Set". This collection data structure is typically a HashSet to ensure element uniqueness and efficient inclusion checks. Then, begin iterating through each business node in the "First Type Target Business Node" set. For each business node encountered, access its declaration information. From the current business node's declaration information, read the list of "output fields to be generated after the business node is executed". This list explicitly lists all field names that will be generated after the node's calculation.

[0066] S3101. Add each field name from the read output field list to the previously initialized "First Output Field Set". Because a HashSet is used, duplicate field names are automatically removed, ensuring that each field appears only once in the set. After the iteration is complete, the "First Output Field Set" is constructed, containing all unique field names that will be produced by the first type of target business nodes.

[0067] S3102. From all predefined business nodes, it is necessary to exclude those nodes that already belong to the "first category of target business nodes" to obtain a set of "remaining business nodes". This set contains all other business nodes in the system that are not directly or indirectly affected by the changed fields. Begin traversing each business node in the "remaining business node" set. For each remaining business node encountered, its declaration information is also accessed. From the declaration information of the current remaining business node, read the list of "dependency fields" declared by the node. This list indicates the input fields required for the execution of this node.

[0068] S3103. Check if there is any intersection between the elements in the "Dependency Fields" list of the current remaining business nodes and the elements in the "First Output Fields Set". Specifically, the "Dependency Fields" list is also converted into a temporary set. Then, a set operation (such as `retainAll`) is called or the "Dependency Fields" list is traversed to determine if each dependency field exists in the "First Output Fields Set". If the result is that there is at least one intersection, meaning that at least one dependency field of the current remaining business node is included in the "First Output Fields Set", then this remaining business node is marked as a "Second Type Target Business Node". All nodes marked as "Second Type Target Business Nodes" are collected to form an independent set. This set is the final output of this step. Then, the "First Type Target Business Node" set and the "Second Type Target Business Node" set are merged to form a complete "Target Business Node" set. This complete set will be used as the input for subsequent topology sorting steps.

[0069] The first output field set is a temporary data container built in memory to uniquely store the names of all output fields declared to be generated by all first-type target business nodes. Its core function is to act as a lookup table to quickly determine whether the dependency requirements of other business nodes can be satisfied by the execution results of the first-type nodes. Constructing this set is a crucial step in connecting the influence of the first-type nodes with the discovery of the second-type nodes.

[0070] In another possible implementation, the specific implementation process of S31 is as follows: ① At startup, precompile the declaration information of all business nodes to build a global reverse dependency index table. This index table uses each possible output field as the key, and the corresponding value is a list recording all business nodes whose dependent fields contain this output field. When the process reaches the current step, obtain the determined first-type target business node set. ② Traverse each business node in the first-type target business node set and extract all its output fields from the declaration information of each business node. Merge these extracted output fields into a temporary working set to form the first output field set. ③ Initialize an empty result container to store the second-type target business nodes, and then traverse each output field in the first output field set, using the output field as the query key to search the previously built global reverse dependency index table. ④ Obtain the list of all business nodes that depend on the current output field from the reverse dependency index table. Then, traverse this obtained list of business nodes and determine whether each business node in the list already exists in the first-type target business node set. If the business node does not exist in the first type of target business node set, it is added to the result container used to store the second type of target business nodes. ⑤ After traversing all output fields in the first output field set, deduplication is performed on the business nodes in the result container to ensure that each business node appears only once. At this point, all business nodes stored in the result container are determined to be second type target business nodes, and this container is used as the output of this step.

[0071] S4. Perform topological sorting on all target business nodes to generate an execution sequence, specifically including: S40. Based on the output fields and dependency fields of each target business node, determine the dependency relationships between each target business node. The specific implementation process is as follows: S400. Initialize an empty "dependency graph" data structure, which is represented by a directed graph, where each vertex represents a target business node. Then, traverse the set of target business nodes and create a corresponding vertex for each target business node in the graph.

[0072] S401. Construct a temporary field mapping table. Specifically, iterate through all target business nodes again. For each node, read the list of "output fields that will be generated after the target business node is executed" from its declaration information. Then, use each output field in the list as the key and the current target business node as the value, and record it in the field mapping table. It should be noted that an output field is typically produced by only one node to ensure determinism. This mapping table records this output relationship.

[0073] S402. Begin determining dependencies, i.e., establishing the edges of the directed graph. Traverse each target business node. For the currently traversed target business node A, read its "dependency field" list from its declaration information. For each dependency field X in the "dependency field" list of target business node A, use the field mapping table to check if any other target business node produces field X. If the query of the field mapping table finds a target business node B, and the output field list of target business node B contains dependency field X, add a directed edge from target business node B to target business node A in the dependency graph. This edge indicates that target business node A depends on target business node B, because target business node A needs field X produced by target business node B as input. Repeat this process until all dependency fields of target business node A have been processed. Then continue traversing the next target business node.

[0074] S403. Once all target business nodes have been traversed and processed, the dependency graph is complete. All directed edges in the graph collectively define the dependencies between the target business nodes. This graph will serve as the input for the next step, topology sorting.

[0075] S41. Based on dependencies, perform topological sorting on all target business nodes associated with the dependencies to generate a linear execution sequence. During the topological sorting process, target business nodes without dependencies are placed at the beginning of the execution sequence. The specific implementation process is as follows: S410. Receive the constructed dependency graph. First, calculate the in-degree of each vertex in the graph, that is, calculate how many edges point to the target business node represented by that vertex. The in-degree calculation is completed by traversing all edges in the graph and incrementing the in-degree count of the target vertex pointed to by each edge.

[0076] S411. Initialize an empty queue and an empty list. The queue is used to store vertices with an in-degree of zero, and the list is used to store the sorted results in order. This result list will eventually become a "linear execution sequence". S412. Traverse all vertices in the dependency graph, adding all vertices with an in-degree of zero to the initialized queue. Then, enter a loop processing phase, provided the queue is not empty. In each loop, remove a vertex (representing a target business node) from the head of the queue and add it to the end of the result list. Traverse all directed edges originating from the current vertex, i.e., find all downstream vertices directly dependent on the current vertex. For each such downstream vertex, decrement its in-degree by one. After decrementing the in-degree of a downstream vertex, immediately check if its in-degree has become zero. If the in-degree has become zero, add this downstream vertex to the tail of the queue. Repeat this process until the queue is empty.

[0077] In this process, nodes are retrieved from the head of the queue for processing and added to the results list. This means that nodes with an in-degree of zero that were initially added to the queue are retrieved and added to the results list first. Therefore, these "target business nodes with no dependencies" are naturally placed at the forefront of the "linear execution sequence." Their order in the sequence depends on their initial discovery order or the implementation characteristics of the queue.

[0078] S413. When the loop ends, check if the number of vertices in the result list is equal to the total number of vertices in the dependency graph. If they are equal, the topology sorting was successful, and all vertices have been included in the result list, which is the generated "linear execution sequence". If the numbers are not equal, it indicates that a cycle exists in the graph, and a circular dependency error needs to be reported and the process terminated.

[0079] S42. The implementation of this step is deeply integrated into the topological sorting algorithm process in S41. Its key operation lies in S41, specifically: before starting the loop processing, add all vertices with an in-degree of zero to the queue.

[0080] The dependency relationships between target business nodes are an abstract model describing the constraints on the execution order of these nodes. It consists of directional connections between nodes in the set of target business nodes, based on the supply and demand of fields. Specifically, if a dependent field of target business node A happens to be an output field of another target business node B, then there exists a dependency relationship from target business node B to target business node A. This relationship indicates that target business node B must execute before target business node A to ensure that target business node A receives the correct input data. All such relationships constitute a directed acyclic graph, which is the fundamental basis for topological sorting to determine the correct execution order.

[0081] The linear execution sequence is an ordered list generated by the topological sorting algorithm applied to the dependency graph of the target business nodes. This list contains all the target business nodes that need to be executed, and the order of the nodes in the list satisfies a key property: for every edge in the dependency graph from target business node X to target business node Y, target business node X is always ranked before target business node Y in the list. This ensures that when each target business node is executed sequentially from beginning to end according to this sequence, all other target business nodes it depends on have already been executed, and all the required input data is ready. The linear structure of the sequence provides clear and unambiguous instructions for subsequent sequential execution.

[0082] In another possible implementation, the specific implementation process of S4 is as follows: ① Initialize an empty stack and a mapping table. The mapping table records three states for each target business node: unvisited, under access, and visited. Simultaneously, an empty list of dependent nodes is created for each target business node. ② Traverse all target business nodes, constructing adjacency relationships based on the output fields and dependent fields of each target business node. Specifically: for each dependent field of the current target business node A, find node B among all target business nodes whose output field contains this dependent field, and add node B to node A's dependent node list. This indicates that the execution of node A depends on the prior completion of node B. ③ Define a depth-first search function that takes a target business node as input. When the function is called, first mark the node's state as "under access," then recursively call itself to traverse and process each upstream node in the node's dependent node list, only recursively calling when the upstream node's state is "unvisited." If a node already in the "under access" state is encountered during recursion, it indicates a circular dependency has been discovered, and an exception is immediately thrown. Once all upstream nodes of a given node have been processed, the node's state is marked as "visited," and the node is pushed onto the previously initialized empty stack. ④ Traverse all target business nodes. For nodes with a state of "unvisited," call the aforementioned depth-first search function. When all target business nodes have become "visited," pop nodes from the stack sequentially, recording the order of the popped nodes into a new list. The order of this list is the result of topological sorting, i.e., a linear execution sequence. During this process, target business nodes without dependencies (i.e., whose dependency list is empty) are immediately pushed onto the stack when their depth-first search is called, naturally placing them at the front of the popped list. This method naturally generates the execution sequence by recursively traversing the dependencies between target business nodes. Marking node states during the depth-first search not only effectively sorts nodes but also synchronously detects loops in dependencies. If a loop is detected, the process is immediately terminated and an error is reported, preventing logical errors and program infinite loops caused by cyclic dependencies. The recursive push-to-stack and final pop-to-stack order conversion ensures that all upstream dependent nodes are always arranged before downstream nodes, resulting in a logically rigorous linear execution sequence. Simultaneously, independent nodes with empty dependency lists are processed and pushed onto the stack early in the traversal, ultimately occupying a front position in the sequence, allowing them to be executed first and contributing to optimized startup efficiency of the overall execution flow. The entire implementation process is logically self-consistent and can efficiently handle complex mesh dependencies between target business nodes.

[0083] S5. Execute each target business node in the execution sequence sequentially and output updated data. The specific implementation process is as follows: S50. Initialize a global context entity, which is a thread-safe in-memory data structure used to store and pass all field data generated throughout the orchestration process. During initialization, the context entity loads the changed fields extracted from the business change message and their initial values.

[0084] S51. Obtain the linear execution sequence generated by the topology sorting step. This sequence is an ordered list containing all target business nodes that need to be executed, and the dependency order between nodes is guaranteed.

[0085] S52. Begin sequentially traversing the execution sequence. For the first target business node in the execution sequence, first determine its node type based on its declaration information. The node type can be a database query node, an interface query node, or a data processing node. Based on the type of the target business node, load and instantiate the corresponding node executor. A node executor is an executable unit that encapsulates specific business logic, such as a Java class that implements a specific interface. Before execution, the node executor reads the values ​​of all its required dependency fields from the global context entity. For example, a node executor that calculates the discount rate will read the values ​​of dependency fields such as "shipping time," "discounted shipping cost," and "total discount amount" from the context entity. The node executor uses the read dependency field values ​​to execute its internally encapsulated business logic. For example, a database query node will connect to the database and execute an SQL query; an interface query node will call the HTTP interface of an external system; a data processing node will perform numerical calculations or business rule processing. After the node executor completes its execution, it will generate values ​​for one or more output fields. The node executor updates these output field values ​​to the global context entity, overwriting or adding the corresponding fields. For example, the node executor that calculates the discount rate will write the calculated "discount rate" value into the corresponding field of the context entity. The execution result of the current node executor is checked. If execution is successful, the next target business node in the execution sequence continues. If an exception occurs during execution, the system will handle it according to predefined error handling strategies, such as logging errors, skipping the current node, or terminating the entire orchestration process.

[0086] S53. After all target business nodes in the execution sequence have been successfully executed, the final output results are extracted from the global context entity. These output results are typically a set of key-value pairs containing data generated after the execution of all target business nodes that needs to be persisted or passed to downstream systems. Then, the extracted output results are batch-updated to persistent storage using database operation components, such as updating database tables related to waybill costs. Alternatively, the output results are encapsulated into a specified message format and pushed to downstream message queues or API interfaces. After data output is complete, cleanup operations are performed to release the global context entity and all resources used in this orchestration process, such as closing database connections and clearing temporary caches. At this point, a complete dynamic orchestration process is finished.

[0087] Updated data refers to the final data set generated after the dynamic orchestration process is completed and needs to be output or persisted. It represents the final state of the business change message after being processed by a series of on-demand target business nodes. This data originates from the global context entity and is a summary of field values ​​produced by each target business node. It is typically in a structured form, such as an object containing multiple fields including waybill number, discount rate, total revenue, and gross profit, along with their new values. Outputting updated data is the ultimate goal of the dynamic orchestration method, aiming to synchronize the precisely calculated results to the database or pass them to downstream systems to drive subsequent business operations or decisions.

[0088] In another possible implementation, the specific implementation process of S5 is as follows: ① Create a dedicated data storage area for this orchestration process and obtain an iterator for the linear execution sequence. Using the iterator, access the first target business node in the execution sequence sequentially. Based on the unique identifier of the target business node, obtain the corresponding node executor instance from the node registry. ② Call the node executor's preparation method. This method accurately extracts the required data from the data storage area based on the dependency field list of the current target business node and encapsulates it into an input data object. Pass the input data object to the node executor's execution method to trigger the execution of the target business node's internal logic, such as database operations, API calls, or numerical calculations. ③ After the node executor completes execution, encapsulates the results of the output fields into an output data object and incrementally writes the fields and values ​​in the output data object to the data storage area to ensure that subsequent nodes can obtain the latest data. ④ Trigger a node execution completion event. This event carries the identifier and execution status of the current target business node, facilitating tracking by external monitoring systems. ⑤ Repeat steps ② through ④ until the iterator has traversed all target business nodes in the execution sequence. After all target business nodes have completed execution, generate a final snapshot of the entire data storage area. This snapshot contains all the updated data generated in this process. ⑥ Submit this updated data snapshot to a data persistence processor, which is responsible for writing the data to the database in batches using a transactional approach, ensuring the atomicity of the update. After confirming successful data persistence, destroy the data storage area dedicated to this process and release the iterator resources, ending the process. By creating an independent data storage area for each orchestration process, data interference between different processes is effectively isolated, enhancing the security and stability of concurrent execution of multiple processes. Using an iterator to access the execution sequence in sequence makes the control of the execution process more precise and flexible, facilitating the implementation of control logic such as pausing and skipping when necessary. The data storage area is updated immediately after each target business node is executed, ensuring the real-time nature of data transmission, so that subsequent nodes can always obtain the latest upstream output. Independent node completion events provide observability, facilitating operation and maintenance monitoring and debugging. Finally, all updated data is persisted in batches as snapshots, reducing frequent write operations to the database, ensuring eventual data consistency through transactions, and improving overall processing efficiency and reliability.

[0089] The framework corresponding to the dynamic orchestration method based on field-level declarative dependencies of this invention is as follows: Figure 2As shown, the process includes key components such as message access, function registration, orchestration implementation, personalized extensions, exception handling, and the main program. The method begins by receiving upstream data change messages through the message access component. Then, based on the field-level dependencies pre-declared during function registration (i.e., the dependent fields of each business node and the output fields generated after the business node's execution), the control center accurately identifies the set of changed fields in the message that have undergone data updates. Next, based on these changed fields and the declaration information of all business nodes, the control center dynamically derives the target business nodes that only need to be executed, and performs topological sorting of all target business nodes through the orchestration implementation stage, generating a linear execution sequence. Finally, the main program executes each target business node in the execution sequence sequentially according to this sequence. During this process, the main program will call database queries, interface queries, or perform specific logic such as data calculation and assignment based on the node type, ultimately completing the data update through the data update component. The entire process represents a fundamental shift from a "full calculation" model, where any change to any attribute triggers a recalculation of all metrics across the entire process, to an "incremental, on-demand calculation" model that only performs calculations on the changed fields and their impact chains. This significantly reduces computational redundancy and unnecessary external dependencies. This technical solution is particularly suitable for scenarios requiring high timeliness and complex business logic processing, such as real-time calculation of waybill costs. The design of personalized extensions and exception handling modules further ensures adaptability and robustness.

[0090] The method provided by this invention begins with sorting out and analyzing all business logic. Based on this analysis, it is necessary to break down the relevant business logic into independent, functionally cohesive business nodes (i.e., Figure 3 (Nodes in the process). Each business node must be declared beforehand, forming its declaration information. The declaration information needs to clearly define three key parts: first, the data result produced by the business node after performing calculations or processing, i.e., the output field; second, the input data that the business node must rely on to execute its internal logic, i.e., the dependency field; and third, the specific calculation logic or processing rules encapsulated within the business node. After completing the declaration of all business nodes, the data dependencies between all business nodes can be automatically and explicitly derived through the output and dependency fields of each business node, laying the foundation for subsequent dynamic orchestration.

[0091] like Figure 3As shown, a specific business node declaration example is as follows: A business node named "[Calculate:Discount Rate] Node" declares four specific dependency fields: "Shipping Time," "Total Discount Amount," "Marketing Cost," and "Official Shipping Fee." It also declares one output field: "Discount Rate." This example intuitively demonstrates that the calculation logic of this business node needs to calculate and output the "Discount Rate" field based on the values ​​of the four dependency fields. This clearly demonstrates how to define a business node through declaration information and how to explicitly express its data requirements and outputs through dependency and output fields.

[0092] This invention's method can handle change messages generated by various business logics, such as financial discount transactions, accrual discount transactions, and vehicle offset transactions. The following uses "financial discount transactions" as an example to detail the complete processing flow from receiving the message to completing the data update. This flow specifically embodies steps S1 to S5. Specifically, using financial discount transactions as a background: A company implements a discount promotion at the end of the month, applying a discount to each waybill for that month. Each waybill needs to have the discount amount deducted, and the actual revenue, wages, bonuses, costs, profits, and other data recalculated. The processing flow is as follows: 1) After the external financial system applies a discount to the waybill, it will generate and send a message notification describing this business change. This corresponds to the initial step, i.e., there is a business change message pending processing.

[0093] 2) Receive this business change message in real time through the message listening component (corresponding to step S1). Upon receiving the message, immediately initiate the message parsing and identification process. The message content for the financial discount business includes multiple fields such as discount type, discount method, discount amount, and waybill number.

[0094] 3) Parse the received business change message to extract the changed fields where data updates have occurred (corresponding to step S2). This step specifically includes: deserializing the message to obtain structured data (S20); validating the structured data, such as checking the data format and required fields (S21); and extracting fields related to the "financial discount business" scenario from the validated structured data as the changed fields for this processing (S22). For example, the extracted changed fields may include waybill number, bill discount, total discount amount, discount type, etc. These changed fields are used to construct an orchestration program to initialize a data object.

[0095] 4) After obtaining the initialization data object, the control center determines the target business nodes affected by the aforementioned changed fields based on the predefined declaration information of all business nodes, and performs dynamic orchestration (corresponding to steps S3 and S4). Specifically, the control center iterates through all declared business nodes based on the changed fields. By comparing the changed fields with the dependency fields of each business node, all business nodes directly dependent on these changed fields are selected as the first type of target business nodes (step S30). For example, if "total discount amount" is a changed field, then business nodes whose dependency fields include "total discount amount" (such as the [Calculate: Discount Rate] node) will be identified as the first type of target business nodes.

[0096] Furthermore, business nodes that depend on fields produced by the first type of target business nodes will be selected as second type of target business nodes (step S31). For example, if a business node depends on the "discount rate" field produced by the first type of node for calculation, then that node is classified as a second type of target business node. After determining all first and second type target business nodes, the control center determines the dependency relationship between them based on the output fields and dependent fields of each target business node, and performs topological sorting to generate a linear, acyclic execution sequence. Taking financial discount business as an example, the final orchestrated execution sequence may contain the following business nodes (i.e., node list): 1) Query: consolidated batch details list; 2) Query: cancel accrual table; 3) Fill: discount type; 4) Calculate: discount rate; 5) Calculate: total actual revenue; 6) Calculate: weight / transportation / official average price; 7) Calculate: accrual actual revenue; 8) Calculate: international table accrual personnel accrual salary; 9) Calculate: main table accrual personnel accrual salary; 10) Calculate: official table accrual personnel accrual salary; 11) Calculate Calculate: International table accrual holder cancels accrual; 12) Calculate: Main table accrual holder cancels accrual; 13) Calculate: Official table accrual holder cancels accrual; 14) Calculate: Financial statement - customer referral bonus; 15) Calculate: Market expected accrual; 16) Calculate: Assessment cost profit; 17) Calculate: Operating / actual expenditure cost, cost ratio; 18) Calculate: Operating, actual cost profit; 19) Calculate: International profit margin; The order of this sequence has been guaranteed by the topological sorting algorithm, which conforms to the business logic dependency between nodes.

[0097] 5) Execute each target business node in the execution sequence sequentially and output updated data (corresponding to step S5). Specifically, the control center, following the above sequence, calls the calculation or processing program of each business node sequentially, starting from the first business node. During execution, each business node retrieves data from its dependent fields from the global context, executes its internal logic (such as database queries, numerical calculations, etc.), and updates the output field results back to the global context. After all target business nodes in the sequence have been executed, the final and complete calculation results are updated to the database, thus completing the data processing for this financial incentive business change.

[0098] The core processing flow of this invention is a systematic, step-by-step process, such as... Figure 4 The real-time computing sequence diagram shown depicts the complete link from message reception to final termination, specifically including: 1) Data Change Awareness and Message Parsing: Specifically, when external data sources, such as database updates or business events, experience data changes, a business change message describing the change is sent out according to a pre-agreed format. The message content includes fields such as discount type, discount method, discount amount, and tracking number. For example... Figure 4 As shown, the message listening component continuously listens to the message queue. Once a new business change message arrives, it immediately executes the operation to receive the XX message (i.e., Figure 4 1) refers to receiving business change messages. The received raw message data needs to be converted into a processable structure. First, the message data is deserialized using JSON format, transforming it into a structured data object. Next, a validity check is performed on this structured data, including but not limited to: whether the data format conforms to specifications, whether required fields are missing, and whether data is duplicated based on business rules. Figure 4 As shown, deserialization and validity verification together correspond to the operations of verification and serialization (i.e., Figure 4 (2) After validation is complete, proceed to the field initialization operation (i.e. Figure 4 (3) In this context, the fields associated with the business scenario corresponding to the business change message are extracted from the structured data that has passed the verification and used as the change fields. The orchestration program is then used to initialize the data object.

[0099] 2) The creation and node determination of dynamic orchestration instances, specifically, the process then enters the initialization phase. After obtaining the initialization data object, the control center performs the operation of creating instances and initializing them (i.e., Figure 4 (4) Create a unique orchestration instance for this processing flow. Next, the control center needs to determine at least one target business node affected by the changed fields based on the predefined declaration information of multiple business nodes. This crucial step is... Figure 4 This is manifested in two specific operations: First, the operations required for registering the instance are executed (i.e., ... Figure 4 (5) This involves iterating through all business nodes, filtering out the first type of target business nodes that directly depend on the changed fields, and the second type of target business nodes that depend on the fields produced by the first type of nodes, and registering all these target business nodes into the current orchestration instance. Next, the dependency setting operation is performed (i.e.... Figure 4 (6) That is, based on the output field and dependency field of each target business node, the dependency relationship between each target business node is determined, so as to prepare for the next step of sorting.

[0100] 3) Execute the generation and execution of the sequence. Specifically, after the dependencies are clear, perform the operation of sorting all nodes (i.e., Figure 4 (7) This involves performing a topological sort on all target business nodes to generate a linear execution sequence, ensuring that nodes with no dependencies are placed at the beginning of the sequence. At this point, the list of nodes for execution is ready. Subsequently, the process proceeds to the operation of the execution instance (i.e., Figure 4 In step 8), the instance execution phase begins, where each target business node in the execution sequence is executed sequentially. This execution process involves creating the first and last nodes (i.e.,...). Figure 4 (9) manages the execution boundary and forms a loop execution process. In each loop, an operation to determine the node type is performed (i.e., Figure 4 (10 in the middle), and then perform the operation of the execution node logic (i.e. Figure 4 11 in the middle.

[0101] The node logic is mainly divided into two paths: ① For data query nodes: a database query operation will be performed (i.e., Figure 4 (12) retrieves data from the database and performs modification operations (i.e. Figure 4 13). ② For business processing and calculation nodes: First, perform the operation of obtaining context data (i.e. Figure 4 (14) means reading dependent fields from the global context entity; if external data is needed, it is done by performing an operation to obtain data from the external source (i.e. Figure 4 15) Obtain data from external data sources or with the help of utility classes; finally, perform assembly, processing, and assignment operations (i.e. Figure 4 (16) complete the calculation and write the output field back to the context.

[0102] 4) Once all target business nodes in the execution sequence have been executed, the process reaches the end operation (i.e., Figure 4(17 in the text). The control center will perform resource cleanup and output the updated data that is finally summarized in the global context, such as persisting it to the database, thereby completing the complete dynamic orchestration and processing flow for this business change message.

[0103] like Figure 5 As shown, specifically: 1) The received business message data is: "waybillld":1570681,"waybillNumber":"KY001","feeAmount":123.25,"discountType":"40""preferentialMode":"20","remark":"Example of discount amount remarks"","marketingDiscountFee": 50,"discountDeductAmount": 123.25...". After validating the data, the message extraction operation is performed, extracting key fields related to the current business scenario from the structured data as change fields. For example, the extracted key fields include: waybillld (waybill ID), waybillNumber (waybill number), feeAmount (discount amount), discountType (discount type), marketingDiscountFee (marketing discount), and discountDeductAmount (total discount amount). These change fields are used to construct the initial data object for data or node calculations. Simultaneously, a context entity at the waybill granularity is constructed. This context entity stores the extracted change fields in its initial state, such as waybillld. Fields such as (Waybill ID), (waybill number), (feeAmount), and (discountType) and their values ​​are included. Throughout the entire orchestration lifecycle, all business nodes will read and write data through this global context entity to achieve data transfer. For example, with the execution of each business node, the results of its calculated "output fields" will be stored in the context entity, thus providing data support for subsequent business nodes that rely on these output fields.

[0104] 2) After receiving the initial data object, the control center will create a unique orchestration instance for this processing flow. The changed fields marked in this data object, for example, in financial discount transactions, might correspond to "Bill Discount," "Total Discount Amount," "Discount Type," etc. (corresponding to...) Figure 5The extracted parameters include feeAmount, discountDeductAmount, and discountType. The control center iterates through all predefined business nodes (e.g., there are currently 43 declared business nodes) and, based on the declaration information of each business node (i.e., its dependency fields and output fields), performs the operation to determine at least one target business node affected by the changed fields. Specifically, it first extracts business nodes whose declared dependency fields contain the aforementioned changed fields as the first type of target business nodes; then it filters out business nodes whose output fields depend on the first type of target business nodes as the second type of target business nodes; next, it performs topology sorting and assembly, and finally generates an orchestration instance for this financial discount business. Since the business rules and node declarations are relatively stable, the orchestration instance corresponding to each business change can be cached after its initial creation to reduce the overhead of repeated orchestration and improve system performance, until the system version update causes the cache to expire.

[0105] 3) The core responsibility of the control center is to dynamically construct a minimal execution chain containing only necessary business nodes based on the changed fields. This is specifically reflected in two aspects: ① Dependency Relationship Retrieval: Querying all pre-declared dependency and output fields of all business nodes to identify all business nodes that directly depend on the changed fields, as the first type of target business nodes. Direct dependency means that the dependency field of a business node directly contains the changed field. This retrieval process corresponds to the step in the technical solution of selecting business nodes whose dependency fields have a direct dependency relationship with the changed field as the first type of target business nodes. ② Topology Sorting and Execution Chain Generation: After determining all affected target business nodes (including the first type and the subsequently derived second type), it is necessary to perform topology sorting on all target business nodes to generate an execution sequence. Based on the output and dependency fields of each target business node, the dependency relationships between each target business node are determined. A topology sorting algorithm is used to analyze these dependencies. Based on the dependencies, a topology sorting is performed on all target business nodes associated with the dependencies to generate a linear execution sequence. In this process, target business nodes without dependencies are placed at the front of the execution sequence. This step ensures that the order in which business nodes are executed fully conforms to their business logic dependencies.

[0106] 4) After generating a linear execution sequence, the control center begins to execute each target business node in the sequence sequentially. Each business node executes only its own internally encapsulated logic. During execution, it reads the current values ​​of its dependent fields from the context entity, and after calculation or processing, updates the results of its declared output fields to the context entity. For example... Figure 5 and Figure 6As shown, the context entity dynamically adds fields during the execution of business nodes, such as shippingTime (shipping time) and actualAmount (total received). The updated data is immediately available to subsequent business nodes that depend on this field, thus achieving orderly delivery and sharing of data throughout the orchestration lifecycle.

[0107] like Figure 6 As shown, when each target business node in the execution sequence is executed sequentially, the execution of each business node strictly follows the pattern of reading data from the context entity, executing logic, and then writing data back. Before executing its calculation logic, a single business node retrieves the current values ​​of all dependent fields defined in its declaration information from the global context entity; after the calculation is completed, it updates the results of its output fields to the same context entity. For example, after the business node "Calculate: Total Actual Revenue" is executed, it updates the value of its output field "actualAmount(Total Actual Revenue)" to the context entity. When the subsequent business node "Calculate: Assessment Cost and Profit" is executed, this node needs to calculate "Gross Profit," and its formula depends on the "Total Actual Revenue" field. At this time, it can directly obtain the updated actualAmount(Total Actual Revenue) value from the context entity to complete the calculation. The context entity serves as the global data storage center, storing numerous fields including waybillld (waybill ID), waybillNumber (waybill number), feeAmount (discount amount), discountType (discount type), marketingDiscountFee (marketing discount), discountDeductAmount (total discount amount), shippingTime (shipping time), serviceType (service method), companyReceivable (company receivable), operationWeight (operating weight), and actualAmount (actual amount received), ensuring reliable data transmission between business nodes.

[0108] Based on their functional logic, business nodes are mainly divided into three types, each performing different processing: ① Database query nodes: These business nodes perform the necessary data acquisition operations, such as querying batch details of consolidated orders and canceling accrual tables. Their execution logic involves querying data from an external database and loading the results as corresponding fields into the context entity, providing data support for subsequent nodes. ② Interface query nodes: These business nodes call external system interfaces to obtain data when necessary for business logic. Through the precise on-demand orchestration based on changing fields in this invention, unnecessary external calls can be minimized, thereby reducing pressure on external systems and improving the overall stability of themselves and related systems. ③ Data processing nodes: These business nodes contain core business calculation and processing logic, such as calculating discount rates, various accrual wages, cost profits, etc. Each data processing node focuses only on its own encapsulated logic, reading data from its dependent fields in the context entity, performing calculations or processing, and then updating the resulting output fields back into the context entity. This approach achieves high cohesion of business logic and low coupling between nodes.

[0109] Once all target business nodes in the execution sequence have completed their execution, the entire dynamic orchestration process enters the final stage. At this point, all final calculation results are aggregated in the context entity. This updated data is then batch-updated to the persistent database or pushed to downstream systems, completing the data persistence process.

[0110] Throughout the entire process, a unified exception handling strategy is in place. Any data or program exceptions occurring during the execution of any business node will be captured and handled centrally by the control center. The handling strategy is configurable; for example, it can ignore the current node and continue execution, or directly terminate the entire orchestration process, balancing the fault tolerance and data consistency requirements of the business process. To ensure the accuracy and consistency of data processing, an atomicity guarantee is designed. When each waybill executes the orchestration program, for the same business change, only one complete dynamic orchestration process will be triggered and executed. Typically, message partitioning consumption is performed based on key information such as the waybill's unique ID to prevent duplicate processing from the source and ensure the atomicity of processing a single business change. After the process terminates, resource cleanup operations are performed. The context entities created for the current business processing flow, as well as all temporary data and intermediate states generated during the orchestration process, are proactively released to prevent memory leaks and ensure the effective utilization of system resources and long-term stable operation.

[0111] The dynamic orchestration method based on field-level declarative dependencies provided by this invention has a complete technical process that can be derived from... Figures 2 to 6 The system architecture and interaction diagrams are clearly linked and presented. For example... Figure 2The diagram showing the real-time computing architecture of orchestrated dynamic nodes comprises modules such as message access, control center, function registration, orchestration implementation, personalized extension, exception handling, and the main program. The main program specifically includes core functions such as database query, interface query, data calculation, assignment, and data update, providing the organizational framework for the entire process. The process begins with an external business change, starting with the message access module (corresponding to...). Figure 4 The message listener receives upstream data change messages from the message queue. Under the scheduling of the control center, the message is then parsed: first, it is deserialized and verified (corresponding to...). Figure 4 (2-check and serialization), then as Figure 5 As shown, messages are extracted from raw data (e.g., data containing fields such as waybillld and discountDeductAmount), and changed fields (e.g., waybillld (waybill ID), discountDeductAmount (total discount amount)) are identified. A context entity is then initialized based on this information. Figure 5 , Figure 6 The context entity (in the context) is the global data carrier that runs throughout the entire process. Next, the core logic of dynamic orchestration unfolds. The control center, based on the pre-declared information of all business nodes obtained from the function registration module (its format is as follows), Figure 3 The node example shown clearly defines the dependency and output fields of each business node, performing dependency inference and topology sorting. For example... Figure 4 As shown, this specifically involves initializing fields, creating and initializing instances, registering the nodes required by the instances, setting dependencies, and finally generating a linear execution sequence by sorting all nodes, thus realizing the functionality of the orchestration module. After generating the sequence, the execution phase begins. The control center drives the main program to execute each target business node in the execution sequence sequentially. For example... Figure 4 As shown, this is a looping process that determines the node type and executes the corresponding internal logic. If it's a database query node, it performs a database query; if it's an API query node, it retrieves data from an external data source; if it's a data calculation or assignment node, it retrieves data from the context for calculation. For example... Figure 6 As shown, the execution of all business nodes revolves around data interaction within the context entity: nodes read the values ​​of dependent fields from it and update them back with the calculated output fields (such as actualAmount, total actual revenue), thus achieving orderly data flow and sharing among nodes. Finally, when all nodes have completed execution, the data update module persists the complete updated data from the context entity to the database or pushes it to downstream systems. Throughout the entire process, the exception handling module ensures stability, while the personalized extension module provides flexibility to adapt to different scenarios. Thus, from message access ( Figure 2 , Figure 4 Field extraction and context construction Figure 5 ), Node dependency declaration ( Figure 3 ), dynamic orchestration ( Figure 4 From sequential execution to data transfer Figure 4 , Figure 6 Each step in the diagram is interconnected, fully illustrating the entire process from incremental change perception to precise calculation output.

[0112] In this invention, ① field-level declarative dependency management: Unlike traditional workflow engines that require pre-defining complete and fixed processes, this invention allows developers to declaratively define the dependent fields and output fields for each business node. By parsing these predefined declarations, a dependency graph between business nodes is automatically constructed at runtime, and the execution path is deduced accordingly, without the need to hard-code the specific execution flow order in the code. This approach greatly improves the system's flexibility in the face of changes in business logic, while reducing code complexity and maintenance costs. ② Minimal orchestration based on changed fields: This feature is the key difference between this invention and existing orchestration frameworks. The execution triggering and node filtering logic of this invention is not based on whether a certain field "exists" in the runtime context entity, but rather strictly based on "which fields have actually been updated" (i.e., changed fields) in the received business change message. Only business nodes that are directly or indirectly affected by these changed fields will be filtered and executed, while business nodes unrelated to the current change will not be executed at all. This principle eliminates redundant calculations and data operations at the source, achieving extreme simplification of the execution path. ③ Dynamic Topology Sorting and Execution Chain Construction: For each data processing request triggered by a business change message, a completely new dependency analysis and topology sorting operation is performed based on the currently determined set of affected target business nodes. This means that the linear execution sequence generated by each orchestration is the optimal path "tailor-made" according to the specific change scenario. This dynamic construction capability allows the system to flexibly adapt to various complex and changing business scenarios without pre-defining or modifying fixed processes, possessing high adaptability and configurability. ④ Through the above-mentioned orchestration mechanism based on the minimization of change fields, the number of unnecessary business node executions can be significantly reduced, especially the number of unnecessary external interface calls (such as calls to interface query nodes). This not only directly reduces the computational and I / O load of this system, effectively avoiding data backlog and output delays caused by excessive processing volume, but also significantly reduces the request pressure on related external systems, thereby improving the stability and processing performance of the system group from the overall architecture level.

[0113] In summary, this invention provides an efficient, stable, and flexible data processing solution by introducing field-level declarative dependency management and a dynamic topology orchestration mechanism driven by changing fields. It successfully overcomes the shortcomings of existing technologies in terms of high process coupling, high computational redundancy, and high system load. Compared with existing technologies, the technical effects include: ① Simplified process and improved efficiency: This invention innovates the traditional model where any attribute change requires triggering a full-process recalculation into an on-demand, field-driven dynamic orchestration model. By accurately identifying the scope of change impact, unnecessary computational steps and external interface calls are significantly reduced, thereby significantly improving program execution efficiency and the utilization rate of computing resources. ② Enhanced system stability: Based on the principle of minimizing orchestration, the system effectively reduces redundant data processing tasks and redundant calls to surrounding systems. This directly reduces the risk of data backlog due to excessive concurrent pressure, improves the timeliness of data processing in this system and the timeliness of results obtained by downstream systems, and enhances the overall system group's reliability and response speed by reducing interference to external systems. ③ Declarative dependency management: This invention provides an intuitive, field-level declarative dependency management mechanism. Developers only need to focus on the input-output relationships of the business nodes themselves. The system can then use an automated topology sorting algorithm to automatically resolve complex dependencies and generate optimal execution paths, reducing development difficulty and optimizing execution logic. ⑤ Excellent scalability and maintainability: During subsequent system iterations, maintenance, or new requirement development, developers can quickly respond to business changes by adding or deleting business nodes or adjusting their declared dependency and output fields. This declarative architecture significantly improves the efficiency of feature delivery and system iteration, while reducing long-term development and maintenance costs. ⑥ Adaptable to complex business scenarios: This invention is particularly suitable for business environments such as real-time waybill cost calculation where there are multiple fields undergoing cross-changes, complex business logic, and high requirements for processing timeliness. It provides a flexible, scalable, highly available, and efficient technical implementation foundation for large-scale waybill processing systems and similar scenarios.

[0114] In the above embodiments, although the steps are numbered S1, S2, etc., they are only specific embodiments given by the present invention. Those skilled in the art can adjust the execution order of S1, S2, etc. according to the actual situation. The scheme after adjusting the order is also within the protection scope of the present invention. It can be understood that in some embodiments, some or all of the above embodiments may be included.

[0115] like Figure 7 As shown, a dynamic orchestration system 200 based on field-level declarative dependencies according to an embodiment of the present invention includes a receiving module 201, a parsing module 202, a determining module 203, a generating module 204, and an execution module 205. Receiver module 201 is used to receive service change messages; Parsing module 202 is used to parse business change messages and extract the changed fields where data updates have occurred; The determination module 203 is used to determine at least one target business node affected by the changed fields based on the declaration information of multiple predefined business nodes; the declaration information of each business node includes the dependency fields that the business node depends on and the output fields that the business node will produce after execution. Generation module 204 is used to perform topological sorting on all target business nodes and generate an execution sequence; The execution module 205 is used to execute each target business node in the execution sequence in sequence and output updated data.

[0116] Optionally, in the above technical solution, the determining module 202 includes a first determining unit and a second determining unit; the first determining unit is used to: select business nodes from all business nodes whose dependent fields and change fields have a direct dependency relationship as first-type target business nodes; the second determining unit is used to: select business nodes that depend on the output fields of each first-type target business node as second-type target business nodes; all target business nodes include first-type target business nodes and second-type target business nodes.

[0117] Optionally, in the above technical solution, the first determining unit is specifically used to: determine the business node to which the target dependency field belongs as a business node with a direct dependency relationship, the target dependency field being a dependency field that includes a change field; all first-type target business nodes include business nodes with a direct dependency relationship.

[0118] Optionally, in the above technical solution, the second determining unit is specifically used to: obtain the output fields of all first-type target business nodes to form a first output field set, determine whether the dependency fields of each business node other than the first-type target business nodes contain at least one output field in the first output field set, and take the business node whose dependency fields contain the output fields in the first output field set as the second-type target business node.

[0119] Optionally, in the above technical solution, the generation module 204 is specifically used to: determine the dependency relationship between each target business node based on the output field and dependency field of each target business node; and perform topological sorting on all target business nodes associated with the dependency relationship to generate a linear execution sequence.

[0120] Optionally, in the above technical solution, the generation module 204 is further specifically used to: arrange target business nodes that have no dependency relationship at the front of the execution sequence during the topology sorting process.

[0121] Optionally, in the above technical solution, the parsing module 202 is specifically used to: deserialize the business change message to obtain structured data; perform legality verification on the structured data; and extract the fields associated with the business scenario corresponding to the business change message from the structured data that has passed the verification, as the change fields.

[0122] It should be noted that the beneficial effects of the dynamic orchestration system 200 based on field-level declarative dependencies provided in the above embodiments are the same as those of the dynamic orchestration method based on field-level declarative dependencies described above, and will not be repeated here. Furthermore, the system provided in the above embodiments is only illustrated by the division of the above functional modules. In practical applications, the above functions can be assigned to different functional modules as needed, that is, the system can be divided into different functional modules according to the actual situation to complete all or part of the functions described above. In addition, the system and method embodiments provided in the above embodiments belong to the same concept, and their specific implementation process is detailed in the method embodiments, and will not be repeated here.

[0123] An electronic device according to an embodiment of the present invention includes a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements any of the above-mentioned dynamic orchestration methods based on field-level declarative dependencies.

[0124] In one alternative embodiment, an electronic device is provided, such as Figure 8 As shown, Figure 8 The illustrated electronic device 4000 includes a processor 4001 and a memory 4003. The processor 4001 and the memory 4003 are connected, for example, via a bus 4002. Optionally, the electronic device 4000 may further include a transceiver 4004, which can be used for data interaction between the electronic device and other electronic devices, such as sending and / or receiving data. It should be noted that in practical applications, the transceiver 4004 is not limited to one type, and the structure of the electronic device 4000 does not constitute a limitation on the embodiments of the present invention.

[0125] Processor 4001 may be a CPU (Central Processing Unit), a general-purpose processor, a DSP (Digital Signal Processor), an ASIC (Application Specific Integrated Circuit), an FPGA (Field Programmable Gate Array), or other programmable logic devices, transistor logic devices, hardware components, or any combination thereof. It can implement or execute the various exemplary logic blocks, modules, and circuits described in conjunction with the disclosure of this invention. Processor 4001 may also be a combination that implements computational functions, such as including one or more microprocessor combinations, a combination of a DSP and a microprocessor, etc.

[0126] Bus 4002 may include a path for transmitting information between the aforementioned components. Bus 4002 may be a PCI (Peripheral Component Interconnect) bus or an EISA (Extended Industry Standard Architecture) bus, etc. Bus 4002 can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 8 The bus 4002 is represented by only one thick line, but this does not mean that there is only one bus or one type of bus.

[0127] The memory 4003 may be ROM (Read Only Memory) or other types of static storage devices capable of storing static information and instructions, RAM (Random Access Memory) or other types of dynamic storage devices capable of storing information and instructions, or EEPROM (Electrically Erasable Programmable Read Only Memory), CD-ROM (Compact Disc Read Only Memory) or other optical disc storage, optical disc storage (including compressed optical discs, laser discs, optical discs, digital universal optical discs, Blu-ray discs, etc.), magnetic disk storage media or other magnetic storage devices, or any other medium capable of carrying or storing desired program code in the form of instructions or data structures and accessible by a computer, but not limited thereto.

[0128] The memory 4003 stores application code (computer program) for executing the present invention, and its execution is controlled by the processor 4001. The processor 4001 executes the application code stored in the memory 4003 to implement the content shown in the foregoing method embodiments.

[0129] Among them, electronic devices can also be terminal devices, which can be any device that can install applications, including at least one of smartphones, tablets, laptops, desktop computers, smart speakers, smartwatches, smart TVs, and smart in-vehicle devices.

[0130] It should be noted that, Figure 8 The electronic device shown is merely an example and should not be construed as limiting the functionality and scope of use of the embodiments of the present invention.

[0131] An embodiment of the present invention provides a computer-readable storage medium storing a computer program, which, when executed by a processor, implements any of the above-mentioned dynamic orchestration methods based on field-level declarative dependencies.

[0132] Alternatively, the computer-readable storage medium may be a read-only memory (ROM), a random access memory (RAM), a compact disc read-only memory (CD-ROM), magnetic tape, a floppy disk, and an optical data storage device, etc.

[0133] The above description is merely a preferred embodiment of the present invention and an explanation of the technical principles employed. Those skilled in the art should understand that the scope of disclosure in this invention is not limited to technical solutions formed by specific combinations of the above-described technical features, but should also cover other technical solutions formed by arbitrary combinations of the above-described technical features or their equivalents without departing from the above-disclosed concept. For example, technical solutions formed by substituting the above features with (but not limited to) technical features with similar functions disclosed in this invention.

[0134] Although embodiments of the present invention have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting the present invention. Those skilled in the art can make changes, modifications, substitutions and variations to the above embodiments within the scope of the present invention.

Claims

1. A dynamic orchestration method based on field-level declarative dependencies, characterized in that, include: Receive service change messages; Parse the business change message and extract the changed fields where data updates occurred; Based on the declaration information of multiple predefined business nodes, determine at least one target business node affected by the changed fields; the declaration information of each business node includes the dependency fields that the business node depends on and the output fields that the business node will produce after execution; Perform topological sorting on all target business nodes to generate an execution sequence; Each target service node in the execution sequence is executed sequentially, and updated data is output.

2. The dynamic orchestration method based on field-level declarative dependencies according to claim 1, characterized in that, The step of determining at least one target business node affected by the changed field based on the declaration information of multiple predefined business nodes includes: From all business nodes, select those business nodes where the dependent field and the changed field have a direct dependency relationship, and designate them as the first type of target business nodes; Filter and select business nodes that depend on the output fields of each first-category target business node as second-category target business nodes; All target business nodes include Category I target business nodes and Category II target business nodes.

3. The dynamic orchestration method based on field-level declarative dependencies according to claim 2, characterized in that, The step of selecting business nodes from all business nodes that have a direct dependency relationship between the dependency field and the change field as the first type of target business nodes includes: The business node to which the target dependency field belongs is determined to be a business node with a direct dependency relationship, and the target dependency field is a dependency field that contains the changed field.

4. The dynamic orchestration method based on field-level declarative dependencies according to claim 2, characterized in that, The filtering process, which selects business nodes that depend on the output fields of each first-category target business node as second-category target business nodes, includes: Obtain the output fields of all first-type target business nodes to form a first output field set. Determine whether the dependency fields of each business node other than the first-type target business nodes contain at least one output field in the first output field set. Select the business nodes whose dependency fields contain the output fields in the first output field set as the second-type target business nodes.

5. The dynamic orchestration method based on field-level declarative dependencies according to claim 1, characterized in that, The step of performing topological sorting on all target service nodes to generate an execution sequence includes: The dependency relationships between the target business nodes are determined based on the output fields and dependency fields of each target business node. Based on the dependencies, a topological sort is performed on all target business nodes associated with the dependencies to generate a linear execution sequence.

6. The dynamic orchestration method based on field-level declarative dependencies according to claim 5, characterized in that, Also includes: During the topology sorting process, target business nodes that have no dependencies are placed at the front of the execution sequence.

7. A dynamic orchestration method based on field-level declarative dependencies according to any one of claims 1 to 6, characterized in that, The step of parsing the business change message and extracting the change fields where data updates have occurred includes: The business change message is deserialized to obtain structured data; Perform a validity check on the structured data; From the validated structured data, extract the fields associated with the business scenario corresponding to the business change message, and use them as the change fields.

8. A dynamic orchestration system based on field-level declarative dependencies, characterized in that, It includes a receiving module, a parsing module, a determining module, a generating module, and an execution module; The receiving module is used to receive service change messages; The parsing module is used to parse the business change message and extract the changed fields where data updates have occurred; The determining module is used to determine at least one target business node affected by the changed field based on the declaration information of multiple predefined business nodes; the declaration information of each business node includes the dependency fields that the business node depends on and the output fields that the business node will generate after execution. The generation module is used to perform topological sorting on all target business nodes and generate an execution sequence; The execution module is used to execute each target business node in the execution sequence in sequence and output updated data.

9. An electronic device, characterized in that, It includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement a dynamic orchestration method based on field-level declarative dependencies as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements a dynamic orchestration method based on field-level declarative dependencies as described in any one of claims 1 to 7.

Images