Method and system for automatically arranging mes micro-service interface based on production business semantics

Abstract

This application relates to a method and system for automatic orchestration of MES microservice interfaces based on production business semantics. The method includes: receiving requests from the Manufacturing Execution System (MES), extracting context information, and generating business semantic tags through a rule engine. It queries the interface metadata database to obtain associated interface addresses, state constraints, and idempotency rules. Based on the tags and metadata, it matches a basic orchestration template, dynamically calculates timeout thresholds and node priorities, and outputs an optimized template. It parses template dependencies, maps work orders to equipment parameters, and generates atomic instruction sets. It calls a centralized verification service and outputs node records with status codes. If verification fails, it performs retry or reverse compensation according to the compensation strategy in the template and generates an exception report. It aggregates semantic tags, instruction sets, node records, and reports, stores them in shards, constructs a spatiotemporal index, and outputs a structured orchestration log archive. This application improves the adaptability, reliability, and operational efficiency of the MES system in flexible manufacturing scenarios.

Description

Technical Field

[0001] This application relates to the fields of intelligent manufacturing and industrial internet technology, and in particular to a method and system for automatic orchestration of MES microservice interfaces based on production business semantics. Background Technology

[0002] As modern manufacturing accelerates its transformation towards flexible, multi-variety, small-batch production models, the business complexity of Manufacturing Execution Systems (MES) is showing a significant upward trend. To improve system scalability and maintenance convenience, existing MES generally adopt a microservice architecture, breaking down the original monolithic application into relatively independent service modules such as work order management, process routing, equipment management, material management, quality management, and warehouse management. In actual production operations, a complete production operation often cannot be completed independently by a single microservice. Instead, multiple microservices need to coordinate and call each other according to specific business logic and a strict sequence. For example, when performing a production reporting operation, the system needs to call multiple underlying service interfaces sequentially or in parallel, such as equipment status acquisition, material consumption verification, personnel permission verification, production record saving, and quality inspection task generation, to achieve cross-business domain data linkage and process flow. Currently, the industry often uses fixed code written in the business control layer, direct synchronous interface calls, or simple message queue concatenation to complete this cross-service collaborative processing.

[0003] However, this cross-microservice collaborative invocation mechanism reveals certain limitations when dealing with complex and ever-changing flexible production scenarios. Most existing cross-service invocation processes are implemented by hard-coding a fixed order of interface calls within each business service. This highly coupled approach necessitates modifying the corresponding program code and redeploying the service when product types change, process routes are altered, or workshop management rules are adjusted, resulting in extremely high system maintenance costs and slow response times. Simultaneously, due to the lack of a global perspective for control, cross-service status verification logic is fragmented and embedded within each microservice. This easily leads to inconsistencies between work order status, equipment status, and material status during cross-domain business flows, resulting in irreversible problems where business data anomalies are only discovered after the actual interface call is completed.

[0004] Furthermore, in a distributed environment, anomalies such as interface call failures and network timeouts occur frequently. However, due to the lack of a unified anomaly compensation and rollback management mechanism at the system level, it is often difficult to eliminate the intermediate state where some services execute successfully while others fail. Moreover, the messy log records lack tracing methods centered on business semantics, making subsequent problem investigation highly dependent on manual piecing together of fragmented information, resulting in low location efficiency. This restricts the reliability and traceability of the manufacturing execution system in complex production environments. Summary of the Invention

[0005] To address the aforementioned technical issues, this application provides a method and system for automatic orchestration of MES microservice interfaces based on production business semantics.

[0006] Firstly, this application provides an automatic orchestration method for MES microservice interfaces based on production business semantics, employing the following technical solution: Receive production business requests from the Manufacturing Execution System and extract the context information, including work order number, process number, product model, equipment number, and business operation type field; Based on the context information, a business semantic tag corresponding to the production business request is generated through a rule matching engine; Query the predefined interface metadata database to obtain the microservice interface metadata associated with the business semantic tag; wherein, the metadata includes interface address, state constraints and idempotency rules; Based on the business semantic tags and microservice interface metadata, a basic template is matched from the pre-configured orchestration template library, and timeout thresholds and node priority parameters are generated through dynamic calculation, and an optimized executable orchestration template is output. The node dependencies of the executable orchestration template are parsed, and the work order number and device number are mapped to the interface call parameters to generate an atomic call instruction set carrying a global tracing identifier; Call the centralized status verification service to verify whether the work order status, equipment status and material status corresponding to each node in the atomic call instruction set meet the status constraints, and output the node record with execution status code; When the execution status code in the node record indicates an abnormality, according to the compensation strategy configuration in the executable orchestration template, a retry call or reverse compensation interface operation is performed to generate an exception handling report. The system aggregates the business semantic tags, atomic call instruction sets, node records, and exception handling reports, stores them in shards according to work order numbers, constructs a spatiotemporal index, and outputs a structured and orchestrated log archive.

[0007] By adopting the above technical solutions, the pain points of traditional MES systems—such as strong coupling between interface calls and business code, scattered state verification, lack of exception handling, and difficulty in troubleshooting—are effectively addressed. This solution transforms fixed business processes into configurable and manageable digital templates through intelligent recognition and dynamic orchestration of production business semantics, reducing code maintenance costs caused by product changes and process modifications. By introducing centralized state verification and idempotent control before interface execution, the consistency and legality of cross-service business flows are ensured. A multi-layered exception compensation system, including retries, rollbacks, and manual review, eliminates data silos and intermediate state risks in a distributed environment. Finally, through the construction of structured logs and spatiotemporal indexes across the entire chain, the traceability of production anomalies is improved from tedious manual stitching to second-level accurate location, enhancing the adaptability, reliability, and operational efficiency of the MES system in flexible manufacturing scenarios.

[0008] Optionally, the step of generating a business semantic tag corresponding to the production business request through a rule matching engine based on the context information includes: The context information is standardized and cleaned, unstructured characters are deleted and the encoding format is unified to generate a standardized input vector; The normalized input vector is matched with a pre-configured rule base to determine the business scenario type and calculate the initial confidence level. Based on the product model in the context information, obtain the corresponding historical orchestration record, and calculate the scenario frequency weight value based on the historical occurrence frequency of the business scenario type under the same product model in the historical orchestration record. The initial confidence level is corrected based on the scene frequency weight value to obtain the corrected confidence level, and a main semantic label with a weight correction factor is generated. Obtain a preset confidence threshold; when the corrected confidence level is lower than the confidence threshold, generate a verification flag. The main semantic tag, the corrected confidence level, and the verification tag are encapsulated to generate a business semantic tag corresponding to the production business request.

[0009] By adopting the above technical solutions and introducing a dynamic weight correction mechanism based on historical frequency, the limitations of single rule matching are broken, enabling the system to learn and adapt to the real production habits of different product models. At the same time, combined with the time-effect decay factor, the semantic recognition model can be updated automatically with business development, avoiding interference from outdated data. Finally, by constructing a structured object containing semantics, confidence level, and verification tags, and setting a circuit breaker mechanism with a confidence threshold, the accuracy of automated processing is improved, while providing a controllable manual intervention entry point for high-risk operations, enhancing the intelligence level and operational security of the MES system in complex and ever-changing production environments.

[0010] Optionally, the steps of matching a base template from a pre-configured orchestration template library based on the business semantic tags and microservice interface metadata, and dynamically calculating timeout thresholds and node priority parameters to output an optimized executable orchestration template include: Parse the main semantic tags in the business semantic tags and filter the matching basic templates from the pre-configured orchestration template library; Read the state constraints from the microservice interface metadata and extract the device status verification rules; Call the real-time system monitoring service to obtain the current CPU load rate and memory usage, and calculate the system load impact factor; Based on the device status verification rules, the pre-configured device prediction model is queried, and the device availability probability value is output. The timeout threshold parameter for the interface call node is dynamically generated based on the product of the system load impact factor and the device availability probability value. Obtain the node dependency topology graph of the basic template, and calculate the execution priority weight based on the node hierarchy depth and the number of output parameter dependencies in the node dependency topology graph; Configure the timeout threshold parameter and execution priority weight in the corresponding node of the basic template to generate an executable orchestration template with dynamic optimization parameters.

[0011] By adopting the above technical solutions and integrating business semantic recognition with real-time system status awareness, a two-dimensional dynamic threshold calculation mechanism was constructed. This mechanism enables the orchestration process to intelligently adjust timeout strategies based on system load and equipment health, reducing the process interruption rate caused by environmental fluctuations. At the same time, priority weight calculation based on topology analysis optimized the resource allocation logic for concurrent execution of multiple nodes, ensuring the efficient advancement of critical business paths. Furthermore, the three-zone separation storage structure, which decouples and injects dynamic parameters and static templates, not only ensures standardized management of business processes but also provides flexible adaptability at the execution level, improving the robustness, adaptability, and execution efficiency of the MES microservice architecture in complex industrial environments.

[0012] Optionally, the step of parsing the node dependencies of the executable orchestration template, mapping the work order number and device number to interface call parameters, and generating an atomic call instruction set carrying a global tracing identifier includes: Read the node definition data in the executable orchestration template, identify the serial dependencies, parallel branch relationships and parameter passing chains between nodes, and output the node dependency topology; Extract predefined input parameter mapping rules from the executable orchestration template, and map the work order number and the device number to the interface call parameter fields corresponding to each node in the node dependency topology based on the input parameter mapping rules, and generate a node instruction draft after parameter binding. Obtain the current request timestamp, combine it with the work order number, and calculate a unique string identifier using a hash algorithm, which will serve as a global tracking identifier; The global tracking identifier is injected into the metadata area of ​​the node instruction draft, and the node number and target interface address corresponding to each node are obtained from the node dependency topology. The node number, the target interface address and the node instruction draft after injecting the global tracking identifier are encapsulated to generate an atomic call instruction unit. The atomic call instruction units corresponding to all nodes are aggregated and sorted according to the node dependency topology to generate the atomic call instruction set.

[0013] By adopting the above technical solutions, a node-dependent topology is constructed, making complex business processes visible and modeled, laying a mathematical foundation for automated scheduling. Predefined input parameter mapping rules enable intelligent adaptation between business contexts and heterogeneous microservice interfaces, eliminating tight coupling at the code level. The introduction of a hash-based global tracing identifier, coupled with atomic instruction units encapsulated in three zones, allows for seamless chaining of distributed calls across multiple services, improving system observability and maintainability. The resulting structured instruction set not only clarifies the execution order but also optimizes concurrent processing efficiency through mechanisms such as synchronization barriers, ensuring that the MES system maintains process accuracy while possessing high flexibility and traceability when dealing with complex production processes.

[0014] Optionally, the step of calling a centralized status verification service to verify whether the work order status, equipment status, and material status corresponding to each node in the atomic call instruction set meet the status constraints and outputting node records with execution status codes includes: Parse the node metadata in the atomic call instruction set and extract the status type identifier and associated business entity number to be verified. The status type identifier includes at least one of work order status, equipment status and material status. Obtain the status query interface corresponding to the status type identifier, and obtain the current status value of the business entity through the status query interface and the associated business entity number; wherein, when the status type identifier is a work order status, it is obtained through the work order service query interface; when the status type identifier is a device status, it is obtained through the device service real-time status interface; and when the status type identifier is a material status, it is obtained through the material service inventory verification interface. Obtain predefined state constraints from the microservice interface metadata, match the current state value with the state constraints using rules, and generate a rule matching result. An execution status code is generated based on the rule matching result. When the rule matching result indicates that the current status value meets the status constraint condition, the execution status code is marked as a pass status code; otherwise, the execution status code is marked as an exception status code. The node number is obtained from the node metadata, and the node number, the state type identifier, the current state value, the state constraint condition, and the execution status code are encapsulated to generate the node record.

[0015] By adopting the above technical solutions and using a dynamic routing mechanism based on status type identifiers, unified real-time retrieval and verification of heterogeneous statuses from multiple sources, such as work orders, equipment, and materials, are achieved, ensuring that business processes are based on the most authentic on-site data. By externalizing complex business constraints into logical expressions in metadata and performing rule matching, the verification logic and business code are completely decoupled, improving the system's flexibility and maintainability. In particular, the introduction of binary execution status codes and structured node records with three-zone separation simplifies scheduling decisions and provides a detailed, transparent, and traceable data foundation for root cause analysis of production anomalies, enhancing the business compliance and data consistency of the MES system in complex manufacturing environments.

[0016] Optionally, when the execution status code in the node record indicates an anomaly, the steps of performing a retry call or reverse compensation interface operation and generating an anomaly handling report according to the compensation strategy configuration in the executable orchestration template include: Parse the execution status code type and exception context data in the node record to identify the exception node number and the associated business entity identifier; Extract the compensation strategy configuration corresponding to the abnormal node number from the executable orchestration template, wherein the compensation strategy configuration includes at least one of a retry call strategy and a reverse compensation strategy; When the compensation strategy is configured as a retry call strategy, a preset retry rule is obtained, and the interface call operation corresponding to the abnormal node number in the atomic call instruction set is re-executed according to the preset retry rule to obtain the retry response result; When the compensation strategy is configured as a reverse compensation strategy, the pre-configured reverse compensation interface metadata is queried, the call parameters in the node record are reverse-mapped to the compensation interface input parameter field in the reverse compensation interface metadata, the state recovery operation is performed, and the state recovery execution result is obtained. Obtain the current timestamp, aggregate the abnormal node number, the policy type configured in the compensation strategy, the retry response result or the state recovery execution result, and the current timestamp to generate the abnormal handling report.

[0017] By adopting the above technical solutions and through refined exception context parsing, the fault point can be accurately located; by using templated compensation strategy configuration, the exception handling logic can be flexibly adjusted according to business needs without hard coding; by adopting a parameter reverse mapping mechanism, the reverse compensation request can be automatically constructed based on predefined metadata, ensuring the eventual consistency of business data in a complex distributed environment; the final generated structured exception handling report separates and stores the exception cause, handling action, and business impact in three dimensions, which greatly improves the system's maintainability, fault tolerance, and automated recovery level.

[0018] Optionally, after the step of outputting a structured log archive, the following may also be included: Based on the spatiotemporal index in the structured log archive, extract historical abnormal node records within a preset time window whose execution status code indicates an abnormal status code; The historical abnormal node records are parsed to extract abnormal feature vectors, and the abnormal feature vectors are classified and aggregated according to the business semantic tags contained in the abnormal feature vectors to generate an abnormal node association sequence. The abnormal feature vectors include the abnormal node number and the compensation strategy execution result in the abnormal handling report. The frequency of occurrence of the abnormal node number in the abnormal node association sequence is counted, and combined with the success rate of the state recovery operation in the compensation strategy execution result, the node failure risk index corresponding to the abnormal node number is calculated. When the node failure risk index is greater than a preset risk threshold, obtain the node dependency topology and interface call parameters corresponding to the abnormal node number; A template optimization strategy is generated based on the node dependency topology, the interface call parameters, and the node failure risk index. The basic templates corresponding to the business semantic tags in the pre-configured orchestration template library are then updated and configured according to the template optimization strategy.

[0019] By adopting the above technical solutions and utilizing the full-link spatiotemporal data in the structured orchestration log archives, through feature extraction, semantic aggregation, and risk quantification, it is possible to automatically identify deep-seated process vulnerabilities in complex and flexible production scenarios. Based on this, the orchestration template library can be dynamically corrected without human intervention, thereby eliminating the high maintenance costs and slow expansion problems caused by the traditional hard-coded calling method. This ensures that the manufacturing execution system can always maintain optimal business flow reliability and system operational robustness when facing multiple varieties, small batches, and frequent process changes.

[0020] Secondly, this application provides an automatic orchestration system for MES microservice interfaces based on production business semantics, employing the following technical solution: The business request processing module is used to receive production business requests from the manufacturing execution system and extract the context information therein, including work order number, process number, product model, equipment number and business operation type fields; The business semantic tag generation module is used to generate business semantic tags corresponding to the production business request based on the context information and through a rule matching engine. The interface metadata query and association module is used to query a predefined interface metadata database to obtain microservice interface metadata associated with the business semantic tag; wherein, the metadata includes interface address, state constraints and idempotency rules; The orchestration template dynamic optimization module is used to match basic templates from the pre-configured orchestration template library based on the business semantic tags and microservice interface metadata, and to generate timeout thresholds and node priority parameters through dynamic calculation, and output the optimized executable orchestration template. The instruction set generation module is invoked to parse the node dependencies of the executable orchestration template, map the work order number and device number to the interface call parameters, and generate an atomic call instruction set carrying a global tracing identifier. The node record generation module is used to call the centralized status verification service to verify whether the work order status, equipment status and material status corresponding to each node in the atomic call instruction set meet the status constraints, and output the node record with execution status code. The exception handling module is used to perform retry calls or reverse compensation interface operations and generate an exception handling report when the execution status code in the node record indicates an exception, according to the compensation strategy configuration in the executable orchestration template. The log generation module is used to aggregate the business semantic tags, atomic call instruction sets, node records and exception handling reports, store them in shards according to work order numbers and build a spatiotemporal index, and output structured orchestrated log archives.

[0021] Thirdly, this application provides a computer device, which adopts the following technical solution: A computer device includes a memory, a processor, and a computer program stored in the memory, the processor executing the computer program to perform the steps of the method as described in the first aspect.

[0022] Fourthly, this application provides a computer-readable storage medium, which adopts the following technical solution: A computer-readable storage medium storing a computer program that can be loaded by a processor and executed as in any of the methods in the first aspect.

[0023] In summary, this application includes at least one of the following beneficial technical effects: by utilizing semantic-driven and dynamic template technologies, maintenance costs caused by process changes are reduced; by using a pre-centralized status verification and multi-level compensation mechanism, the risk of data inconsistency in a distributed environment is eliminated; and by relying on full-link structured logs and spatiotemporal indexes, second-level accurate location of production anomalies is achieved, improving the system's flexible adaptability and operational efficiency. Attached Figure Description

[0024] Figure 1 This is a first flowchart of an embodiment of the MES microservice interface auto-orchestration method based on production business semantics, which is one of the embodiments of this application.

[0025] Figure 2 This is a second flowchart illustrating the automatic orchestration method for MES microservice interfaces based on production business semantics, according to one embodiment of this application.

[0026] Figure 3 This is a schematic diagram of the third process of an automatic orchestration method for MES microservice interfaces based on production business semantics, according to one embodiment of this application.

[0027] Figure 4 This is a schematic diagram of the fourth process of the automatic orchestration method for MES microservice interfaces based on production business semantics, which is one embodiment of this application.

[0028] Figure 5 This is a schematic diagram of the fifth process of the automatic orchestration method for MES microservice interfaces based on production business semantics, which is one embodiment of this application.

[0029] Figure 6 This is a schematic diagram of the sixth process of the automatic orchestration method for MES microservice interfaces based on production business semantics, which is one embodiment of this application.

[0030] Figure 7 This is a schematic diagram of the seventh process of the automatic orchestration method for MES microservice interfaces based on production business semantics, which is one embodiment of this application. Detailed Implementation

[0031] To make the purpose, technical solution, and advantages of this application clearer, the following description is provided in conjunction with the appendix. Figures 1-7 The present application will be further described in detail below with reference to embodiments. It should be understood that the specific embodiments described herein are for illustrative purposes only and are not intended to limit the scope of the application.

[0032] This application discloses an automatic orchestration method for MES microservice interfaces based on production business semantics.

[0033] Reference Figure 1 An automatic orchestration method for MES microservice interfaces based on production business semantics, specifically including: Step S101: Receive a production business request from the manufacturing execution system and extract the context information therein, including work order number, process number, product model, equipment number and business operation type field; Specifically, in the MES microservice architecture, production business requests are usually initiated by field terminals, barcode scanners, device gateways or upper-level systems, carrying the intent of a specific production operation, such as an operator clicking "start process" on the terminal or the equipment automatically reporting "production work report".

[0034] Next, the system receives these requests through the business request access module and extracts key context fields: the work order number uniquely identifies the current production task, the process number locates the specific step in the process flow, the product model distinguishes the process routes and control rules for different products, the equipment number binds to the physical equipment performing this operation, and the business operation type directly indicates the nature of this request (such as work order issuance, work reporting, quality inspection, etc.). These fields together constitute the foundational facts for subsequent semantic recognition and orchestration decisions. Their accuracy directly determines the correctness of the entire automated process, avoiding the blindness of traditional methods that rely solely on interface addresses or fixed parameters for invocation.

[0035] Step S102: Based on the context information, generate business semantic tags corresponding to the production business requests through the rule matching engine; The rule matching engine has a built-in mapping table between business operation types and semantic tags, which can map specific operations such as "process reporting" to standard semantic tags such as "PRODUCTION_REPORT".

[0036] Based on this, the system will combine the historical process routes associated with the work order number and the BOM structure of the product model to calculate the weight of the associated business. For example, in the "process reporting" scenario, the system will automatically calculate the associated weight values ​​of "material deduction" and "quality inspection trigger". If the weight exceeds the preset threshold, secondary semantic tags such as "AUTO_QUALITY_CHECK" will be generated and injected into the business semantic tags.

[0037] At the same time, the engine outputs a confidence score based on the completeness of the fields and the historical matching success rate, which is used to arbitrate in the event of multiple semantic conflicts. This ensures that the system can not only identify "what to do", but also understand "what needs to be done in conjunction", thus achieving a high-fidelity conversion from physical operations to business logic.

[0038] Step S103: Query the predefined interface metadata database to obtain the microservice interface metadata associated with the business semantic tags; wherein, the metadata includes the interface address, state constraints and idempotency rules; Specifically, the interface metadata database is the system's static knowledge base, which stores digital descriptions of all MES microservice interfaces. Once the business semantic tags are generated, the system will retrieve the relevant set of interfaces based on the main semantic tags.

[0039] In this embodiment, the acquired metadata includes not only the interface address, request method, and input / output parameter definitions, but more importantly, it includes state constraints and idempotency rules. For example, for the semantic "work process commencement," the associated work order service interface metadata explicitly stipulates that "it can only be called when the work order status is RELEASED," which is a state constraint. At the same time, idempotency key rules are defined, such as the unique combination of "same work order number + work process number + equipment number," to prevent duplicate commencement due to network retransmission.

[0040] In addition, metadata will incorporate dynamically calculated parameters, such as the device availability probability value predicted by the ARIMA algorithm, which will be used as a dynamic constraint parameter to ensure that interface calls conform to the actual operating status of the device.

[0041] Step S104: Based on business semantic tags and microservice interface metadata, match basic templates from the pre-configured orchestration template library, and generate timeout thresholds and node priority parameters through dynamic calculation, and output the optimized executable orchestration template. The pre-configured orchestration template library stores standard process skeletons for various business scenarios, such as serial nodes, parallel nodes, and conditional branches.

[0042] In this embodiment of the application, the system first matches the corresponding basic template based on the business semantic tags, but does not execute it directly. Instead, it collects the current system load indicators in real time and combines them with the device availability probability value obtained in the previous steps to instantiate and optimize the template through a dynamic calculation model.

[0043] For example, when the system load is high or the probability of device availability fluctuates greatly, the system will dynamically extend the timeout threshold through a specific algorithm to avoid misjudgment caused by short delays. At the same time, based on the depth priority value of node dependencies, the system will adjust the execution priority of parallel nodes to ensure that tasks on the critical path get resources first, thereby outputting an executable orchestration template that conforms to business logic and adapts to the current environment.

[0044] Step S105: parse the node dependencies of the executable orchestration template, map the work order number and device number to the interface call parameters, and generate an atomic call instruction set carrying a global tracing identifier; The system iterates through the optimized orchestration template, parses the topological dependencies between nodes, and identifies which interfaces need to wait for the completion of the preceding interfaces and which can be initiated in parallel. Subsequently, the system performs parameter mapping, accurately filling the context information such as the work order number and device number in the initial request into the input parameter fields required by each microservice interface, and establishes a parameter passing chain to ensure that the output parameters of the upstream node (such as the generated work order ID) can be automatically mapped to the input parameters of the downstream node (such as the quality inspection task generation).

[0045] During this process, the system concatenates the request timestamp with the node number to generate a global trace identifier, which is then injected into each instruction. The resulting atomic call instruction set is a set of indivisible minimum execution units. Each instruction contains the target address, parameters, timeout settings, and a unique trace identifier, ensuring accuracy and traceability at the execution level.

[0046] Step S106: Call the centralized status verification service to verify whether the work order status, equipment status and material status corresponding to each node in the atomic call instruction set meet the status constraints, and output the node record with execution status code. Before executing an API call, the system does not blindly initiate a request. Instead, it calls a separate, centralized status verification service. This service proactively initiates queries to source services such as work order service, material service, and equipment service based on the status constraints in the metadata.

[0047] For example, for a start order, the service sends a query request to the work order service to verify whether the status corresponding to the work order number is "RUNNING"; and sends a kitting check request to the materials service to verify whether the materials for that product model are sufficient in the current process. Only when all status checks return signals that the constraints are met will the node be marked as "ready" and an execution record be output; if the work order status is unexpected or the material kitting check is false, the system will immediately freeze the execution of the current node and output a node record with a "BLOCKED" status, thereby blocking the erroneous business process at its source.

[0048] Step S107: When the execution status code in the node record indicates an abnormality, according to the compensation strategy configuration in the executable orchestration template, perform a retry call or reverse compensation interface operation and generate an abnormality handling report. For different types of anomalies, the system implements differentiated recovery strategies. For example, for momentary network timeouts or service unavailability, the system uses an exponential backoff algorithm for retries, initiating retries at intervals of 2^n milliseconds (where n is the current retrieval count) to prevent a retry storm from overwhelming the system. For state conflicts or business logic failures, the system calls a pre-registered reverse compensation interface, passing in the hash value of the original request parameters to ensure the uniqueness of the operation object, and performs rollback operations such as "cancel commencement" or "restore inventory". If the number of retries exceeds the limit or involves serious errors that cannot be automatically handled, the system generates a mobile review task and suspends the process, notifying manual intervention.

[0049] Ultimately, the exception handling report generated throughout the process records the exception type, stack information, retry trajectory, and compensation results in detail, ensuring that the system will not leave an intermediate state of "partial success and partial failure" under any failure scenario.

[0050] Step S108: Aggregate business semantic tags, atomic call instruction sets, node records and exception handling reports, store them in shards according to work order number and build a spatiotemporal index, and output a structured log archive.

[0051] Specifically, the system no longer records logs piecemeal, but instead aggregates and encapsulates all data entities throughout an orchestration lifecycle. This data is stored in shards by work order number, ensuring data continuity for the same business entity. Simultaneously, the system constructs a spatiotemporal index, establishing a sliding window storage area (such as hot data from the last 24 hours) in the time dimension and associating equipment and process locations in the spatial dimension. To balance data security and analytical value, the system also anonymizes sensitive fields in business semantic tags.

[0052] In addition, the system will analyze the co-occurrence frequency of abnormal node records through association rule algorithms (such as the Apriori algorithm), discover configuration combinations that frequently lead to failure, generate template optimization parameters and feed them back to the orchestration template library, thereby realizing the system's self-evolution.

[0053] The above implementation effectively addresses the technical pain points of traditional MES systems, such as strong coupling between interface calls and business code, scattered state verification, lack of exception handling, and difficulty in troubleshooting. This solution transforms fixed business processes into configurable and manageable digital templates through intelligent recognition and dynamic orchestration of production business semantics, reducing code maintenance costs caused by product changes and process modifications. By introducing centralized state verification and idempotent control before interface execution, it ensures the consistency and legality of cross-service business flows. By constructing a multi-layered exception compensation system including retries, rollbacks, and manual review, it eliminates data silos and intermediate state risks in a distributed environment. Finally, through the construction of structured logs and spatiotemporal indexes across the entire chain, the traceability of production anomalies is improved from tedious manual splicing to second-level accurate location, enhancing the adaptability, reliability, and operational efficiency of the MES system in flexible manufacturing scenarios.

[0054] For example, the specific implementation process of this application will be described in detail using the "production reporting" scenario as an example: Upon receiving a work order request, the system identifies the business semantics as "work order reporting." It matches a work order arrangement template based on the product model and process route, automatically generating a call plan. This plan first verifies the work order status and process sequence, then concurrently calls the equipment service to obtain equipment operating status, the material service to verify material consumption, and the personnel service to verify operation permissions. After successful verification, the system calls the production execution service to save the work order record. Based on the work order quantity and quality inspection rules, it then decides whether to call the quality service to generate a quality inspection task. Finally, it calls the log audit service to record the business chain. If the quality service call fails, the system can retry according to a strategy. If the retry still fails, a quality inspection compensation task is generated, and the process status is marked as "pending quality inspection compensation," effectively preventing data gaps between work order records and quality inspection tasks.

[0055] Compared with the existing fixed-code interface calling method, this application has the following technical advantages: It reduces the coupling between cross-service business processes and program code. By managing interface metadata and orchestration templates, business processes are extracted from fixed code, allowing different workshops, products, and process routes to generate different interface call plans through configuration, reducing program modifications and service re-issuance due to business changes. It improves the consistency of MES microservice business processing. The system performs multi-dimensional state verification before each interface node is executed, which can detect problems such as inconsistent states, unmet preconditions and illegal flow before business execution, and avoids discovering business data anomalies only after the interface call is successful. It improves exception handling capabilities by implementing differentiated recovery strategies for various exceptions through a unified exception compensation module, thereby reducing the risk of partial success and partial failure in cross-service calls. It improves the efficiency of business expansion. When adding new product types, processes or business rules, only business semantic rules, interface metadata and orchestration templates need to be maintained, which is conducive to the MES system adapting to multi-variety, small-batch and flexible manufacturing scenarios. It improves the efficiency of problem tracking and operation and maintenance. By recording data across the entire chain through the orchestration log module, operation and maintenance personnel can quickly locate abnormal nodes based on key identifiers. It improves interface governance capabilities by uniformly maintaining interface attributes and rules through the interface metadata management module, standardizing the management of interface calls, and reducing runtime errors caused by inconsistent interface parameters.

[0056] Reference Figure 2 As one implementation of step S102, the step of generating business semantic tags corresponding to production business requests through a rule matching engine based on context information includes: Step S201: Standardize and clean the context information, delete unstructured characters and unify the encoding format to generate a standardized input vector; Specifically, in the actual operating environment of the MES system, the original request data from field terminals, barcode scanning devices or external systems often have inconsistent formats. For example, the work order number may be a mixture of letters, numbers, hyphens or even invisible control characters, and the product model may have mixed uppercase and lowercase letters or differences between simplified and traditional characters due to different input habits.

[0057] Therefore, the standardized cleaning process aims to remove all unstructured noise using regular expressions or character filtering algorithms, and to uniformly convert the remaining characters into a preset encoding format (such as UTF-8) and standard naming conventions (such as all uppercase and fixed length). The cleaned data is then integrated into a normalized input vector of numerical or structured text. This vector not only eliminates data ambiguity but also provides a clean and reliable input source for subsequent rule matching, fundamentally avoiding semantic misjudgments caused by chaotic data formats.

[0058] Step S202: Match the normalized input vector with the pre-configured rule base to determine the business scenario type and calculate the initial confidence level; The pre-configured rule base is a set of deterministic mapping tables built into the system, which defines the correspondence between business operation types and semantic tags. When the normalized input vector enters the rule base, the system parses the business operation type field (such as "START_PROCESS") and associates the corresponding equipment verification tag and process route version tag according to the mapping rule table.

[0059] For example, when a business operation type of "process commencement" is detected, the rule base not only outputs the main tag "PROCESS_START," but also forcibly associates auxiliary tags such as "DEVICE_CHECK_REQUIRED" and "ROUTE_VERSION_VALIDATION" to fully express the intent of the operation. The initial confidence level is a cardinality calculated based on the number of successful tag matches or the strength of rule hits. It represents the certainty of semantic recognition at the static rule level, providing a benchmark value for subsequent dynamic corrections.

[0060] Step S203: Obtain the corresponding historical orchestration record based on the product model in the context information, and calculate the scenario frequency weight value based on the historical occurrence frequency of the business scenario type under the same product model in the historical orchestration record. The historical orchestration record database stores the log data of all successfully executed production processes in the past. The system uses the product model as the index key to retrieve all past orchestration records for that product and categorizes them by business scenario type. For example, for product model "MODEL_X", the system records 500 instances of "process start", 480 instances of "production report", and 490 instances of "completion and warehousing" in its history.

[0061] Next, by calculating the ratio of the number of successful executions in a specific scenario (such as the start of a work process) to the total number of business operations, a scenario frequency weight value is obtained. This weight value quantifies the historical behavior pattern of this product model in a specific business scenario. If a product rarely performs a certain operation, then the rationality of requesting that operation now is questionable; otherwise, it proves that it conforms to the normal production pattern.

[0062] Step S204: Correct the initial confidence level according to the scene frequency weight value to obtain the corrected confidence level, and generate the main semantic label with weight correction factor; Simple rule matching may not cover all special cases, while historical data often reflects the actual business inertia. Therefore, the system adopts a specific confidence correction algorithm, which multiplies the initial confidence base value by the scene frequency weight value, and further introduces a timeliness attenuation coefficient. The specific correction algorithm formula is: initial confidence base value × scene frequency weight value × timeliness attenuation coefficient.

[0063] It should be noted that the timeliness decay coefficient calculates the difference between the timestamp of the historical record and the current time. If a historical record is too old, its contribution to the current judgment will be reduced proportionally, thus solving the problem of the staleness of historical data.

[0064] Through this dynamic correction, the static confidence level, which was originally derived solely from rules, is given a dynamic attribute that reflects the actual business activity. The final generated main semantic label not only carries business meaning but also comes with a data-enhanced, more persuasive corrected confidence level.

[0065] Step S205: Obtain a preset confidence threshold. When the corrected confidence level is lower than the confidence threshold, generate a review flag. The preset confidence threshold is typically a safety margin set based on the fault tolerance of the production environment. If the confidence level remains low after correction using historical data, it indicates that the current request either does not conform to the normal business model or poses a risk of data anomalies.

[0066] At this point, the system will not blindly enter the automatic orchestration process, but will trigger a manual review process, automatically generating a pending task and pushing it to the relevant management personnel's terminals. Simultaneously, the system will inject a review flag (such as a boolean flag) into the current semantic object context. This flag itself does not interrupt system operation, but as a high-priority signal, it tells subsequent processing modules: "This request has not been confirmed and should be handled with caution or await manual approval in subsequent stages," thus achieving a balance between automation efficiency and safe production.

[0067] Step S206: Encapsulate the main semantic tag, the corrected confidence level, and the verification mark to generate a business semantic tag corresponding to the production business request.

[0068] The system integrates all the heterogeneous data generated in the above steps and encapsulates it into a standard, machine-readable structured data unit (such as JSON or Protocol Buffers format). This object contains three core fields: the main label field is responsible for carrying the specific business semantic encoding (such as "PROCESS_START_V1"), the confidence field stores the corrected floating-point value (such as 0.95), and the review flag stores a boolean value (True / False) to indicate whether manual intervention is required.

[0069] Understandably, this ternary encapsulation structure achieves decoupled storage of business semantics, reliability assessment, and anomaly handling status. This allows the structured business semantic tags to serve as both an accurate index of query interface metadata and an important decision-making basis for subsequent orchestration template matching, ensuring the integrity and consistency of data when it flows between different system modules.

[0070] In the above implementation, a dynamic weight correction mechanism based on historical frequency is introduced, breaking the limitations of single rule matching and enabling the system to learn and adapt to the real production habits of different product models. At the same time, combined with the time-effect decay factor, the semantic recognition model can be updated with business development, avoiding interference from outdated data. Finally, by constructing a structured object containing semantics, confidence level and verification mark, and setting a circuit breaker mechanism with confidence threshold, the accuracy of automated processing is improved, while providing a controllable manual intervention entry for high-risk operations, enhancing the intelligence level and operational security of the MES system in complex and ever-changing production environments.

[0071] Reference Figure 3 As one implementation of step S104, the steps of matching a basic template from a pre-configured orchestration template library based on business semantic tags and microservice interface metadata, and generating timeout thresholds and node priority parameters through dynamic calculation, and outputting an optimized executable orchestration template include: Step S301: Parse the main semantic tags in the business semantic tags and filter the matching basic templates from the pre-configured orchestration template library; Among them, the main semantic tags in the business semantic tags are highly abstracted from the original production requests, such as "PROCESS_START" or "PRODUCTION_REPORT". These tags serve as index keys for fast retrieval in the pre-built orchestration template library.

[0072] In this embodiment, the orchestration template library pre-stores standard process skeletons for various production scenarios. Each template establishes a mapping index table with a unique template ID and specific semantic tags. During the screening process, the system not only performs precise matching but also calculates the matching degree of tags. When the main semantic tag is "process reporting," the system automatically associates a composite template containing quality inspection trigger nodes and material deduction nodes to ensure the integrity of the business process. Finally, the system outputs a basic template set that meets the preset tag matching degree threshold, providing a structured process framework for subsequent dynamic optimization.

[0073] Step S302: Read the state constraints in the microservice interface metadata and extract the device status verification rules; The microservice interface metadata not only defines how the interface is called, but more importantly, it specifies the states in which the interface can be legally called, i.e., state constraints. The system will deeply analyze this metadata to extract specific verification rules: device status verification rules may involve whether the device is in "running", "faulty" or "under maintenance" status, and only devices that meet specific status requirements are allowed to perform start-up or reporting operations.

[0074] In addition, material availability verification rules may be extracted. These rules, based on the bill of materials corresponding to the product model, check whether the inventory quantity of materials required for the current work order meets the minimum production batch size. These rules will be compiled into executable verification statements and embedded before specific nodes in the orchestration process, serving as pre-gates for API calls.

[0075] Step S303: Call the real-time system monitoring service to obtain the current CPU load rate and memory usage rate, and calculate the system load impact factor; Among them, the real-time system monitoring service continuously collects the operating indicators of the underlying infrastructure. After the system reads the current CPU load rate and memory usage, it does not directly use these raw values, but integrates them into a comprehensive system load impact factor through a specific weighting algorithm.

[0076] In this embodiment, the specific calculation formula is: System load impact factor = (1 - current CPU idle rate) × 0.6 + (1 - current memory idle rate) × 0.4; the value of this factor directly reflects the busyness of system resources. The higher the value, the greater the system pressure, and the higher the probability of interface response delays. This mechanism enables the orchestration system to sense the external environment, avoiding the expectation of excessively short response times under high system load, which would lead to a large number of unnecessary timeout interrupts.

[0077] Step S304: Query the pre-configured device prediction model based on the device status verification rules, and output the device availability probability value; Among them, the equipment prediction model is an analysis model trained based on historical equipment runtime sequence data. It can predict the health status of the equipment in the future based on the equipment's past operating modes, fault records and maintenance cycles.

[0078] Specifically, based on the device status verification rules read from metadata, the system inputs the current device's operating parameters and historical data into the model. After calculation, the model outputs a device availability probability value between 0 and 1. For example, a device that has been frequently alarming recently and has not undergone maintenance will be rated as having a low availability probability value. This directly affects the subsequent calling strategy for the device's related interfaces, reflecting a shift from passive response management to proactive predictive management.

[0079] Step S305: Dynamically generate the timeout threshold parameter for the interface call node based on the product of the system load impact factor and the device availability probability value; Traditional fixed timeout settings cannot cope with complex and ever-changing production environments and system states. This step, however, combines the system load impact factor, which reflects the system hardware load, with the equipment availability probability value, which reflects the equipment's own health status, to dynamically calculate a reasonable timeout threshold.

[0080] For example, when the system load is light and the equipment is in good condition, the timeout threshold is set to a shorter optimized value to improve process execution efficiency; conversely, when the system is busy or the equipment status is questionable, the threshold is automatically widened to give the interface more response time. This two-dimensional dynamic calculation mechanism ensures that the orchestration process will neither slow down the production cycle due to being too conservative, nor cause frequent call failures due to being too aggressive.

[0081] Step S306: Obtain the node dependency topology graph of the basic template, and calculate the execution priority weight based on the node hierarchy depth and the number of output parameter dependencies in the node dependency topology graph. This step addresses the issues of resource contention and execution order optimization in a multi-node concurrent environment. The basic template is essentially a directed acyclic graph that describes the dependencies between various interface call nodes.

[0082] In this embodiment, the system analyzes the topology graph to first determine the maximum level depth of each node. A deeper node typically indicates it is at the end of the critical path and is more crucial to achieving the final result. Secondly, the system counts how many downstream nodes depend on the output parameters of each node; the more dependencies a node has, the greater its influence. For example, priority weight values ​​can be generated using the following formula: Weight = Depth value × 0.7 + Number of dependencies × 0.3.

[0083] Understandably, the system calculates a quantified execution priority weight for each node by comprehensively considering these two dimensions—vertical hierarchical depth and horizontal dependency breadth. This allows the scheduler to prioritize the execution of nodes that are crucial to the overall process, thereby optimizing global execution efficiency.

[0084] Step S307: Configure the timeout threshold parameter and execution priority weight in the corresponding node of the basic template to generate an executable orchestration template with dynamic optimization parameters.

[0085] The system iterates through each interface call node in the basic template and accurately fills the personalized parameters calculated in the previous steps into the node's configuration items.

[0086] Specifically, dynamically generated timeout threshold parameters are written to the node's timeout control field, while the calculated execution priority weights are assigned to the node's scheduling attributes. The final executable orchestration template is a structured configuration file containing a node metadata area (storing interface addresses and input parameter mapping rules), a dynamic parameter area (storing timeout threshold fields and priority weight fields), and a compensation strategy area (storing predefined retry rules and reverse compensation interface addresses). It preserves the integrity of business logic while incorporating optimization decisions based on real-time environment and predictive data, enabling the MES system to respond optimally to every specific production business request.

[0087] In the above implementation, a dual-dimensional dynamic threshold calculation mechanism is constructed by integrating business semantic recognition and real-time system status awareness. This enables the orchestration process to intelligently adjust timeout strategies based on system load and device health, reducing the process interruption rate caused by environmental fluctuations. At the same time, priority weight calculation based on topology analysis optimizes the resource allocation logic for concurrent execution of multiple nodes, ensuring the efficient advancement of critical business paths. In addition, the three-zone separation storage structure, which decouples and injects dynamic parameters and static templates, not only ensures standardized management of business processes but also provides flexible adaptability at the execution level, improving the robustness, adaptability, and execution efficiency of the MES microservice architecture in complex industrial environments.

[0088] Reference Figure 4 As one implementation of step S105, the steps of parsing the node dependencies of the executable orchestration template, mapping the work order number and device number to the interface call parameters, and generating an atomic call instruction set carrying a global tracing identifier include: Step S401: Read the node definition data in the executable orchestration template, identify the serial dependency relationship, parallel branch relationship and parameter passing chain between nodes, and output the node dependency topology structure; The executable orchestration template contains a complete blueprint of the business process. The system first needs to parse the node definition data to identify which nodes must be executed sequentially (serial dependency), which can be performed simultaneously (parallel branch), and how data flows between nodes (parameter passing chain). For example, in the "process commencement" scenario, the system recognizes that the "equipment verification node" must be completed before the "work order status update node" can be started, while "material pre-positioning" and "personnel qualification verification" can be processed in parallel.

[0089] These relationships are modeled using graph theory algorithms, and the system constructs a node dependency topology in the form of a directed acyclic graph. Each node represents a specific interface call task, and edges represent dependencies. This topology not only serves as the basis for subsequent scheduling and execution but also provides a visual logical framework for resource allocation and exception handling.

[0090] Step S402: Extract predefined input parameter mapping rules from the executable orchestration template, map the work order number and device number to the interface call parameter fields corresponding to each node in the node dependency topology based on the input parameter mapping rules, and generate a node instruction draft after parameter binding. Different microservice interfaces have their own specific parameter format requirements. For example, the work order service may require a "workOrderNo" field, while the device service requires an "equipmentId" field. The system extracts the pre-configured input parameter mapping rules based on the definition of each node in the topology. These rules are essentially conversion logic between fields. For example, a rule might specify that "work order number" in the global context is mapped to "order_id" in the target interface parameter, and "device number" is mapped to "device_code".

[0091] The system automatically executes these mapping rules, accurately filling common business request fields into specific parameter slots for each interface, thereby generating a draft of the node instructions after parameter binding. This process completely eliminates hard-coded parameter assignments, allowing orchestration templates to flexibly adapt to different versions of interface definitions.

[0092] Step S403: Obtain the current request timestamp, combine it with the work order number, and calculate a unique string identifier using a hash algorithm, which will serve as the global tracking identifier; In a distributed microservice architecture, a single business request may trigger dozens of API calls, which may be handled by different servers. To ensure that these scattered logs can be aggregated into a complete business story, the system needs to generate a globally unique tracking identifier. This identifier is generated by concatenating the current request timestamp (accurate to milliseconds), a unique work order number, and a random seed value as input, and then calculating a fixed-length, theoretically unique string using a cryptographic hash algorithm (such as SHA-256). Injecting this identifier into every subsequent call instruction is like attaching a unique "ID card" to this specific production business request, allowing for accurate identification and tracking regardless of how the request flows within the system.

[0093] Step S404: Inject the global tracking identifier into the metadata area of ​​the node instruction draft, and obtain the node number and target interface address corresponding to each node from the node dependency topology. Encapsulate the node number, target interface address and the node instruction draft after injecting the global tracking identifier to generate an atomic call instruction unit. The atomic call instruction unit is the smallest unit of system scheduling. It contains not only the information required for calling the interface, but also metadata needed for management and tracing. The system places the global tracing identifier in the header metadata area of ​​the instruction unit to ensure that it is read and transmitted with priority.

[0094] Meanwhile, the instruction unit encapsulates the node's unique identifier, the target microservice's specific interface address (URL), and the mapped parameter values. This encapsulation method integrates business logic, technical routing, and tracing information, allowing the scheduler to focus solely on executing this standardized instruction unit without needing to concern itself with the specific implementation details of the interface, thus greatly simplifying the complexity of the execution engine.

[0095] Step S405: Aggregate the atomic call instruction units corresponding to all nodes, sort them according to the node dependency topology, and generate an atomic call instruction set.

[0096] The system collects all generated atomic call instruction units and sorts them according to the previously constructed node dependency topology. For serial nodes, they are strictly arranged in depth-first order of dependencies to ensure that subsequent operations are executed only after the preconditions are met. For parallel branch nodes, a synchronization barrier marker is added to the instruction set to indicate to the execution engine that these tasks can be processed concurrently, but the next stage can only be entered after all concurrent tasks are completed.

[0097] Ultimately, the output structured atomic call instruction set is essentially a topologically sorted task queue. It clearly defines "what to do first, what to do next, and what can be done together" in a machine-readable format (such as a JSON array), providing a precise and unambiguous action guide for the interface call execution module.

[0098] In the above implementation, a node-dependent topology is constructed to visualize and model complex business processes, laying a mathematical foundation for automated scheduling. Predefined input parameter mapping rules enable intelligent adaptation between business contexts and heterogeneous microservice interfaces, eliminating tight coupling at the code level. The introduction of a hash-based global tracking identifier, coupled with atomic instruction units encapsulated in three zones, allows for seamless chaining of distributed calls across multiple services, improving system observability and maintainability. The resulting structured instruction set not only clarifies the execution order but also optimizes concurrent processing efficiency through mechanisms such as synchronization barriers, ensuring that the MES system maintains process accuracy while possessing high flexibility and traceability when dealing with complex production processes.

[0099] Reference Figure 5As one implementation of step S106, the steps of calling the centralized status verification service to verify whether the work order status, equipment status, and material status corresponding to each node in the atomic call instruction set meet the status constraints and outputting node records with execution status codes include: Step S501: Parse the node metadata in the atomic call instruction set and extract the status type identifier and associated business entity number to be verified. The status type identifier includes at least one of work order status, equipment status and material status. Specifically, the atomic call instruction set, as the smallest execution unit of the orchestration process, encapsulates all the pre-verification information required before executing the interface call in its header metadata area. The system first reads this metadata and identifies the status type identifiers that need to be verified in this call. These identifiers are predefined enumerated values ​​used to distinguish different dimensions of business constraints such as work order status, equipment status, and material status.

[0100] Subsequently, based on the status type identifier, the system extracts the corresponding associated business entity number from the node parameters: for example, when the identifier is "work order status," the system will accurately retrieve the "work order number" field from the parameter list; when the identifier is "equipment status," it will extract the "equipment number"; and when material verification is involved, it will extract the "material batch number." This process achieves precise binding between verification requirements and specific business entities, providing clear addressing coordinates for subsequent real-time status queries.

[0101] Step S502: Obtain the status query interface corresponding to the status type identifier, and obtain the current status value of the business entity through the status query interface and the associated business entity number; wherein, when the status type identifier is a work order status, it is obtained through the work order service query interface; when the status type identifier is a device status, it is obtained through the device service real-time status interface; and when the status type identifier is a material status, it is obtained through the material service inventory verification interface. Unlike traditional methods that may rely on local caching or outdated data, this step emphasizes real-time performance by using a dynamic routing mechanism to distribute verification requests to the corresponding backend microservices based on the state type identifier.

[0102] Specifically, if the verification object is a work order status, the system calls the work order service's query interface, passing in the work order number to obtain the latest work order lifecycle status (such as "issued," "in production," or "paused"). If the verification object is a device status, it calls the device service's real-time status interface to obtain the device's operating condition, fault codes, and online status. If the verification object is a material status, it calls the material service's inventory verification interface to query the real-time inventory quantity or availability of materials required for the current work order. This identifier-based dynamic service call ensures that each verification is based on the latest status of the data source, eliminating business flow errors caused by data lag at the source.

[0103] Step S503: Obtain predefined state constraints from the microservice interface metadata, match the current state value with the state constraints according to rules, and generate rule matching results; Specifically, the state constraints are not hard-coded into the program logic, but rather derived from predefined logical expressions in the microservice interface metadata. These expressions describe the prerequisites for the interface to be invoked in a structured form. For example, for the work order start interface, the constraint logical expression in its metadata might be "Work order status ∈ {startable, paused} AND process sequence = current process"; for equipment verification, the expression might be "Equipment status = running AND fault code = 0"; and for material verification, it would be "Inventory quantity ≥ process quota quantity".

[0104] The system substitutes the current status value (such as "running") obtained in the previous step into these logical expressions, and the rule engine performs Boolean operations. This step transforms complex business rules into automatically executable logical judgments, achieving separation between business constraints and technical implementation. This allows rule adjustments to be made without modifying the code, requiring only an update to the metadata configuration.

[0105] Step S504: Generate an execution status code based on the rule matching result. When the rule matching result indicates that the current status value meets the status constraint conditions, the execution status code is marked as a pass status code; otherwise, the execution status code is marked as an exception status code. Although the matching result of the rule engine is a Boolean value, in order to unify management and simplify the exception handling logic, the system maps it to a concise binary execution status code. If the current status value fully satisfies the logical expression of the status constraint, the system generates a binary status code representing success (such as "1"); if it does not satisfy, it generates a binary status code representing an exception (such as "0").

[0106] Understandably, this binary representation greatly simplifies the decision-making logic of the downstream scheduling system, enabling it to decide whether to continue executing the interface call or switch to the exception compensation process with minimal computational cost. At the same time, this mechanism also reserves space for further subdivision of exception types. For example, although they belong to the same exception status code, they may correspond to specific categories such as "missing status value error," "constraint condition not met," or "service call timeout," facilitating subsequent refined operation and maintenance.

[0107] Step S505: Obtain the node number from the node metadata, encapsulate the node number, state type identifier, current state value, state constraints, and execution status code to generate a node record.

[0108] The system aggregates and encapsulates all relevant data from this verification into a structured node record, typically using JSON or a similar data exchange format. This record includes a header (stores the global tracking identifier and node number for tracing), a status data area (details the verification status type, the current status value retrieved, and the logical expressions involved in the matching), and a result area (records the final binary execution status code and the timestamp of the verification). This structured record serves not only as a basis for decision-making in subsequent processes but also as an important log archive, enabling rapid review of any business process delays to determine whether the issue stems from data, rules, or the system.

[0109] In the above implementation, the dynamic routing mechanism based on status type identifiers enables unified real-time retrieval and verification of heterogeneous statuses from multiple sources, such as work orders, equipment, and materials, ensuring that business processes are based on the most authentic on-site data. By externalizing complex business constraints into logical expressions in metadata and performing rule matching, the verification logic and business code are completely decoupled, improving the system's flexibility and maintainability. In particular, the introduction of binary execution status codes and structured node records with three-zone separation simplifies scheduling decisions and provides a detailed, transparent, and traceable data foundation for root cause analysis of production anomalies, enhancing the business compliance and data consistency of the MES system in complex manufacturing environments.

[0110] Reference Figure 6 As one implementation of step S107, when the execution status code in the node record indicates an anomaly, the step of performing a retry call or reverse compensation interface operation and generating an anomaly handling report according to the compensation strategy configuration in the executable orchestration template includes: Step S601: Parse the execution status code type and exception context data in the node record to identify the exception node number and the associated business entity identifier; The node records not only contain binary execution status codes but also encapsulate rich exception context data, which forms the basis for accurate repair. The system first parses the execution status code type to distinguish specific exception categories such as status verification failure, interface call timeout, or service unavailability.

[0111] Simultaneously, the system delves into the anomaly context data, including the specific constraints that led to the failure (such as "work order status is not RUNNING"), the interface call timeout threshold, and key related business entity identifiers (such as work order number and device number). By correlating this information, the system can accurately pinpoint which specific business entity encountered what type of error at which stage, thus providing precise coordinates for subsequent compensation strategy selection and avoiding blind retries or compensation.

[0112] Step S602: Extract the compensation strategy configuration corresponding to the abnormal node number from the executable orchestration template, wherein the compensation strategy configuration includes at least one of retry call strategy and reverse compensation strategy. Specifically, the executable orchestration template not only defines the normal execution path but also pre-configures fault tolerance mechanisms for each node. Based on the abnormal node number identified in the previous step, the system searches for the corresponding configuration item in the template's compensation strategy area. The compensation strategy configuration includes at least one of a retry call strategy and a reverse compensation strategy; the specific strategy used depends on the nature of the business being executed by the node.

[0113] For example, query-type or idempotent operations are typically configured with a retry strategy; while write operations that have modified the business status (such as material deduction) must be configured with a reverse compensation strategy. This fine-grained configuration at the node level enables the system to adopt the most appropriate recovery method for different business scenarios, avoiding the data inconsistency risk caused by a "one-size-fits-all" approach to exception handling.

[0114] Step S603: When the compensation strategy is configured as a retry call strategy, obtain the preset retry rules, and re-execute the interface call operation corresponding to the abnormal node number in the atomic call instruction set according to the preset retry rules to obtain the retry response result. In this context, retrying a call is not simply about repeatedly sending the request; rather, it follows preset retry rules to prevent a retry storm from overwhelming the system. The system extracts the original call instruction of the abnormal node from the atomic call instruction set, including the target interface address, parameters, and global tracing identifier, and re-initiates the call according to the retry rules defined in the template.

[0115] In the embodiments of this application, the preset retry rules typically include a maximum number of retries (N≥1) and an incremental algorithm for the retry interval, such as an exponential backoff strategy of interval = base interval × (2)^(retry number - 1). This design provides sufficient recovery time for downstream services and improves the success rate of retry. The result of each retry is recorded in detail, including the response status code, time consumed, and return message, as input for subsequent report generation.

[0116] Step S604: When the compensation strategy is configured as a reverse compensation strategy, query the pre-configured reverse compensation interface metadata, reverse map the call parameters in the node record to the compensation interface input parameter field in the reverse compensation interface metadata, perform the state recovery operation, and obtain the state recovery execution result. If the compensation strategy is configured as a reverse compensation strategy, the system queries the predefined reverse compensation interface metadata, reverse maps the call parameters in the node records to the input parameter fields of the compensation interface, and performs a state recovery operation. When retries are ineffective or retrying is not permitted by business logic, the system must perform a rollback operation. The system first queries the predefined reverse compensation interface metadata, which describes how to convert the parameters of the forward operation into the parameters of the reverse operation.

[0117] Subsequently, the system activates the parameter reverse mapping engine, converting the original call parameters in the node records (such as the reported output value of 100) into the input parameters required by the compensation interface (such as the deduction_amount field mapped to the output rollback interface, with a value of 100). This reverse mapping mechanism enables the system to automatically construct accurate undo requests and call the reverse compensation interface (such as the inventory recovery interface), thereby restoring the business state to the level before the operation and avoiding errors and delays that may be caused by manual intervention.

[0118] Step S605: Obtain the current timestamp, aggregate the abnormal node number, the policy type configured in the compensation strategy, the retry response result or the state recovery execution result, and the current timestamp to generate an abnormal handling report.

[0119] The system aggregates all key data throughout the entire exception handling lifecycle into a structured report document. This report typically uses a machine-readable format such as JSON and includes an exception classification section (recording whether it was a status verification failure or an interface timeout), a compensation operation section (recording the actual number of retries, the address of the compensation interface called, and the final execution status), and a business impact section (recording the changes made by this exception and its handling to the status of related work orders). This report not only provides operations and maintenance personnel with clear troubleshooting guidelines but also provides a data foundation for system self-optimization, such as optimizing status constraints or compensation strategies by analyzing high-frequency anomalies.

[0120] In the above implementation, precise fault location is achieved through refined exception context parsing; templated compensation strategy configuration enables the exception handling logic to be flexibly adjusted according to business needs without hard coding; the parameter reverse mapping mechanism can automatically construct reverse compensation requests based on predefined metadata, ensuring the eventual consistency of business data in complex distributed environments; the final generated structured exception handling report stores the exception cause, handling actions, and business impact in three dimensions, greatly improving the system's maintainability, fault tolerance, and automated recovery level.

[0121] Reference Figure 7 As a further implementation of the MES microservice interface automatic orchestration method, after the step of outputting structured orchestration log archives, the following is also included: Step S701: Based on the spatiotemporal index in the structured log archive, extract historical abnormal node records within the preset time window whose execution status code indicates an abnormal status code; The spatiotemporal indexing mechanism marks the lifecycle of data in the time dimension using techniques such as sliding windows, and associates it with the physical locations of work orders, equipment, and processes in the spatial dimension. Based on this spatiotemporal index, the system can accurately extract historical abnormal node records with explicitly indicated abnormal status codes from massive logs with extremely high retrieval efficiency.

[0122] This step narrows the scope of investigation from a massive, unordered dataset to a high-value dataset with time boundaries and clear failure characteristics. This not only reduces the computational overhead of subsequent data analysis but also accurately captures the true fault profiles caused by recent changes in the system operating environment or business rules, avoiding interference from outdated and invalid data with the analysis results.

[0123] Step S702: parse historical abnormal node records to extract abnormal feature vectors, and classify and aggregate the abnormal feature vectors according to the business semantic tags contained in the abnormal feature vectors to generate an abnormal node association sequence. The abnormal feature vectors include the abnormal node number and the compensation strategy execution result in the abnormal handling report. Specifically, the anomaly feature vector is not a single identifier, but a multi-dimensional data set, which not only includes the specific location where the anomaly occurred, i.e., the anomaly node number, but also deeply integrates the execution results of the compensation strategy in the anomaly handling report generated in the preceding process.

[0124] Based on this, the system extracts business semantic tags carried in the abnormal feature vectors, such as tags with clear business attributes like "process reporting" or "quality inspection trigger," and uses these as a classification criterion to categorize and aggregate the disorganized abnormal feature vectors. This business semantic-based aggregation mechanism can bring together similar business faults scattered across different times and work orders into the same analysis view, and then, according to the inherent execution order of the abnormal node numbers in the original atomic call instruction set, string these isolated fault points together into a complete abnormal node association sequence.

[0125] This process restores the actual business flow context at the time of the failure, enabling the system to identify from a macro-level business process perspective whether the anomaly is an isolated random event or a systemic defect that recurs in a specific business chain.

[0126] Step S703: Count the frequency of occurrence of abnormal node numbers in the abnormal node association sequence, and calculate the node failure risk index corresponding to the abnormal node number by combining the success rate of state recovery operation in the compensation strategy execution result. The system first counts the frequency of occurrence of specific abnormal node numbers in the sequence of associated abnormal nodes. The higher the frequency, the stronger the vulnerability of the node in business operations. At the same time, the system deeply analyzes the execution results of the compensation strategy, focusing on extracting the success rate data of state recovery operations. If a node frequently reports errors but its state recovery operation success rate is extremely high, it indicates that it has good self-healing capabilities and the actual risk is controllable. Conversely, if the state recovery operation success rate is extremely low, it often means that manual review has been triggered or dirty data that cannot be automatically rolled back has been generated, posing a very high risk of business disruption.

[0127] In this embodiment of the application, by integrating the frequency of occurrence and the success rate of state recovery operation according to a specific weighting algorithm, the system generates an accurate node failure risk index for each abnormal node. This index transforms the qualitative failure phenomenon into a quantitative numerical indicator that can be used for machine decision-making.

[0128] Step S704: When the node failure risk index is greater than the preset risk threshold, obtain the node dependency topology and interface call parameters corresponding to the abnormal node number. To prevent the system from overreacting to occasional minor fluctuations, a preset risk threshold is introduced as a critical condition for triggering the intervention mechanism. When the calculated node failure risk index exceeds this preset risk threshold, the system confirms that the node has become a key bottleneck affecting the stability of the manufacturing execution system. At this point, the system will automatically trace back to the source of the anomaly and obtain the node dependency topology and interface call parameters that strictly correspond to the anomaly node number.

[0129] In this embodiment, the node-dependent topology clearly defines whether the high-risk node is on the serial trunk or in the parallel branch in the entire orchestration process, as well as its data flow relationship with upstream and downstream nodes; while the interface call parameters record the specific input parameter conditions that trigger the node's failure.

[0130] Step S705: Generate a template optimization strategy based on the node dependency topology, interface call parameters, and node failure risk index, and update the configuration of the basic templates corresponding to the business semantic tags in the pre-configured orchestration template library according to the template optimization strategy.

[0131] The generation logic of the template optimization strategy is highly dependent on the topology analysis results. For example, if a high-risk node is located in a parallel branch and its failure often leads to inconsistency in downstream data, the optimization strategy will instruct the parallel branch to be adjusted to serial execution in order to introduce strong consistency control. If a high-risk node is used as a front-end verification node and frequent timeouts are caused by specific interface call parameters, the optimization strategy will generate instructions to insert redundant verification nodes or dynamically relax the timeout threshold parameters.

[0132] Ultimately, the system feeds this template optimization strategy back to the pre-configured orchestration template library, accurately locating the basic template corresponding to the business semantic tag, and updating its node definitions, dependencies, and parameter configurations. This closed-loop logic breaks the rigid pattern of fixed code in traditional manufacturing execution systems, enabling orchestration templates to self-iterate and dynamically adapt based on feedback from real production operations.

[0133] In the above implementation, by utilizing the full-link spatiotemporal data in the structured orchestration log archive, and through feature extraction, semantic aggregation, and risk quantification, it is possible to automatically identify deep-seated process vulnerabilities in complex and flexible production scenarios, and accordingly make dynamic corrections to the orchestration template library without human intervention. This eliminates the high maintenance costs and slow expansion problems caused by the traditional hard-coded calling method, and ensures that the manufacturing execution system can always maintain optimal business flow reliability and system operation robustness when facing multiple varieties, small batches, and frequent process changes.

[0134] In addition, in some embodiments, the following alternative methods can be used to expand the scope of protection: the business semantic recognition method can adopt rule matching, or a combination of rule matching and historical sample recommendation, recommending candidate orchestration templates based on the orchestration records of similar work orders or similar process routes in the past; the interface orchestration template can be implemented by flowchart configuration, JSON configuration, database table configuration, or visual drag-and-drop configuration, and the nodes in the template can be flexibly defined; the interface call execution method can adopt synchronous REST call, or message queue asynchronous call, RPC call, or a hybrid synchronous and asynchronous call; the exception compensation method can adopt automatic compensation. The system can use a combination of compensation, manual review, or both. For exceptions involving quality conclusions or manual approval, a review task is generated and the current process is suspended. Status verification rules can be centrally configured in the status verification module, or each business microservice can provide a status verification interface for unified invocation by the orchestration process generation module. Orchestration logs can be stored in relational databases, Elasticsearch, time-series databases, object storage, or log platforms, and indexed according to multiple dimensions such as work order number and process number. The system can be deployed as an independent interface orchestration service, or implemented as a process engine module, gateway enhancement module, or business middleware module in the MES platform.

[0135] In summary, the key points of this application are: an automatic interface orchestration mechanism based on production business semantics, which identifies semantics and matches templates to generate plans based on multi-dimensional context information; a call plan generation mechanism that combines interface metadata with orchestration templates, which uniformly maintains interface attributes and generates executable plans based on templates; a production status verification mechanism before interface calls, which prevents illegal flow and cross-service status inconsistencies before interface execution; an exception compensation mechanism for MES business, which performs differentiated recovery based on exception type to avoid intermediate states; a full-process logging and tracking mechanism for orchestration, which enables rapid tracking by business dimension; and a dynamic adaptation mechanism that supports rule differences among multiple products, multiple processes, and multiple workshops, which improves the responsiveness to changes in business processes under a microservice architecture by maintaining configuration data.

[0136] This application also discloses an automatic orchestration system for MES microservice interfaces based on production business semantics.

[0137] An automatic orchestration system for MES microservice interfaces based on production business semantics, specifically including: The business request processing module is used to receive production business requests from the manufacturing execution system and extract the context information therein, including work order number, process number, product model, equipment number and business operation type fields; The business semantic tag generation module is used to generate business semantic tags corresponding to production business requests based on context information and through a rule matching engine. The interface metadata query and association module is used to query the predefined interface metadata database and obtain microservice interface metadata associated with business semantic tags; the metadata includes interface address, status constraints and idempotency rules; The orchestration template dynamic optimization module is used to match basic templates from a pre-configured orchestration template library based on business semantic tags and microservice interface metadata, and to dynamically calculate and generate timeout thresholds and node priority parameters, and output optimized executable orchestration templates. The instruction set generation module is used to parse the node dependencies of the executable orchestration template, map the work order number and device number to the interface call parameters, and generate an atomic call instruction set carrying a global tracing identifier. The node record generation module is used to call the centralized status verification service to verify whether the work order status, equipment status and material status corresponding to each node in the atomic call instruction set meet the status constraints and output node records with execution status codes. The exception handling module is used to perform retry calls or reverse compensation interface operations and generate an exception handling report when the execution status code in the node record indicates an exception, according to the compensation strategy configuration in the executable orchestration template. The orchestration log generation module is used to aggregate business semantic tags, atomic call instruction sets, node records and exception handling reports, store them in shards by work order number and build a spatiotemporal index, and output structured orchestration log archives.

[0138] An automatic orchestration system for MES microservice interfaces based on production business semantics, according to an embodiment of this application, can implement any of the above methods, and the specific working process of each module in the system can refer to the corresponding process in the above method embodiments.

[0139] In the several embodiments provided in this application, it should be understood that the provided methods and systems can be implemented in other ways. For example, the system embodiments described above are merely illustrative; for example, the division of a certain module is merely a logical functional division, and in actual implementation there may be other division methods, such as multiple modules can be combined or integrated into another system, or some features can be ignored or not executed.

[0140] This application also discloses a computer device.

[0141] Computer equipment includes memory, processor, and computer program stored in memory and executable on the processor. When the processor executes the computer program, it implements an automatic orchestration method for MES microservice interfaces based on production business semantics, as described above.

[0142] This application also discloses a computer-readable storage medium.

[0143] A computer-readable storage medium storing a computer program that can be loaded by a processor and executed as described above in any of the methods of an automatic orchestration method for MES microservice interfaces based on production business semantics.

[0144] The computer-readable storage medium can be any tangible medium that contains or stores a program that can be used by or in connection with an instruction execution system, apparatus, or device; the program code contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to wireless, wire, optical fiber, RF, etc., or any suitable combination thereof.

[0145] The above are all preferred embodiments of this application and are not intended to limit the scope of protection of this application. Any feature disclosed in this specification (including the abstract and drawings) may be replaced by other equivalent or similar features unless specifically stated otherwise. That is, unless specifically stated otherwise, each feature is only one example of a series of equivalent or similar features.

Claims

1. An MES microservice interface automatic orchestration method based on production business semantics, characterized in that, The method includes: Receive production business requests from the Manufacturing Execution System and extract the context information, including work order number, process number, product model, equipment number, and business operation type field; Based on the context information, a business semantic tag corresponding to the production business request is generated through a rule matching engine; Query the predefined interface metadata database to obtain the microservice interface metadata associated with the business semantic tag; wherein, the metadata includes interface address, state constraints and idempotency rules; Based on the business semantic tags and microservice interface metadata, a basic template is matched from the pre-configured orchestration template library, and timeout thresholds and node priority parameters are generated through dynamic calculation, and an optimized executable orchestration template is output. The node dependencies of the executable orchestration template are parsed, and the work order number and device number are mapped to the interface call parameters to generate an atomic call instruction set carrying a global tracing identifier; Call the centralized status verification service to verify whether the work order status, equipment status and material status corresponding to each node in the atomic call instruction set meet the status constraints, and output the node record with execution status code; When the execution status code in the node record indicates an abnormality, according to the compensation strategy configuration in the executable orchestration template, a retry call or reverse compensation interface operation is performed to generate an exception handling report. The system aggregates the business semantic tags, atomic call instruction sets, node records, and exception handling reports, stores them in shards according to work order numbers, constructs a spatiotemporal index, and outputs a structured and orchestrated log archive.

2. The method for automatic orchestration of MES microservice interfaces based on production business semantics as described in claim 1, characterized in that, The steps of generating business semantic tags corresponding to the production business request using a rule matching engine based on the context information include: The context information is standardized and cleaned, unstructured characters are deleted and the encoding format is unified to generate a standardized input vector; The normalized input vector is matched with a pre-configured rule base to determine the business scenario type and calculate the initial confidence level. Based on the product model in the context information, obtain the corresponding historical orchestration record, and calculate the scenario frequency weight value based on the historical occurrence frequency of the business scenario type under the same product model in the historical orchestration record. The initial confidence level is corrected based on the scene frequency weight value to obtain the corrected confidence level, and a main semantic label with a weight correction factor is generated. Obtain a preset confidence threshold; when the corrected confidence level is lower than the confidence threshold, generate a verification flag. The main semantic tag, the corrected confidence level, and the verification tag are encapsulated to generate a business semantic tag corresponding to the production business request.

3. The method for automatic orchestration of MES microservice interfaces based on production business semantics as described in claim 1, characterized in that, Based on the aforementioned business semantic tags and microservice interface metadata, the steps of matching a basic template from a pre-configured orchestration template library, dynamically calculating and generating timeout thresholds and node priority parameters, and outputting an optimized executable orchestration template include: Parse the main semantic tags in the business semantic tags and filter the matching basic templates from the pre-configured orchestration template library; Read the state constraints from the microservice interface metadata and extract the device status verification rules; Call the real-time system monitoring service to obtain the current CPU load rate and memory usage, and calculate the system load impact factor; Based on the device status verification rules, the pre-configured device prediction model is queried, and the device availability probability value is output. The timeout threshold parameter for the interface call node is dynamically generated based on the product of the system load impact factor and the device availability probability value. Obtain the node dependency topology graph of the basic template, and calculate the execution priority weight based on the node hierarchy depth and the number of output parameter dependencies in the node dependency topology graph; Configure the timeout threshold parameter and execution priority weight in the corresponding node of the basic template to generate an executable orchestration template with dynamic optimization parameters.

4. The method for automatic orchestration of MES microservice interfaces based on production business semantics according to claim 3, characterized in that, The steps of parsing the node dependencies of the executable orchestration template, mapping the work order number and device number to interface call parameters, and generating an atomic call instruction set carrying a global tracing identifier include: Read the node definition data in the executable orchestration template, identify the serial dependencies, parallel branch relationships and parameter passing chains between nodes, and output the node dependency topology; Extract predefined input parameter mapping rules from the executable orchestration template, and map the work order number and the device number to the interface call parameter fields corresponding to each node in the node dependency topology based on the input parameter mapping rules, and generate a node instruction draft after parameter binding. Obtain the current request timestamp, combine it with the work order number, and calculate a unique string identifier using a hash algorithm, which will serve as a global tracking identifier; The global tracking identifier is injected into the metadata area of ​​the node instruction draft, and the node number and target interface address corresponding to each node are obtained from the node dependency topology. The node number, the target interface address and the node instruction draft after injecting the global tracking identifier are encapsulated to generate an atomic call instruction unit. The atomic call instruction units corresponding to all nodes are aggregated and sorted according to the node dependency topology to generate the atomic call instruction set.

5. The method for automatic orchestration of MES microservice interfaces based on production business semantics according to claim 4, characterized in that, The steps of calling the centralized status verification service to verify whether the work order status, equipment status, and material status corresponding to each node in the atomic call instruction set meet the status constraints and outputting node records with execution status codes include: Parse the node metadata in the atomic call instruction set and extract the status type identifier and associated business entity number to be verified. The status type identifier includes at least one of work order status, equipment status and material status. Obtain the status query interface corresponding to the status type identifier, and obtain the current status value of the business entity through the status query interface and the associated business entity number; wherein, when the status type identifier is a work order status, it is obtained through the work order service query interface; when the status type identifier is a device status, it is obtained through the device service real-time status interface; and when the status type identifier is a material status, it is obtained through the material service inventory verification interface. Obtain predefined state constraints from the microservice interface metadata, match the current state value with the state constraints using rules, and generate a rule matching result. An execution status code is generated based on the rule matching result. When the rule matching result indicates that the current status value meets the status constraint condition, the execution status code is marked as a pass status code; otherwise, the execution status code is marked as an exception status code. The node number is obtained from the node metadata, and the node number, the state type identifier, the current state value, the state constraint condition, and the execution status code are encapsulated to generate the node record.

6. The method for automatic orchestration of MES microservice interfaces based on production business semantics according to claim 1, characterized in that, When the execution status code in the node record indicates an anomaly, the steps of performing a retry call or reverse compensation interface operation and generating an anomaly handling report according to the compensation strategy configuration in the executable orchestration template include: Parse the execution status code type and exception context data in the node record to identify the exception node number and the associated business entity identifier; Extract the compensation strategy configuration corresponding to the abnormal node number from the executable orchestration template, wherein the compensation strategy configuration includes at least one of a retry call strategy and a reverse compensation strategy; When the compensation strategy is configured as a retry call strategy, a preset retry rule is obtained, and the interface call operation corresponding to the abnormal node number in the atomic call instruction set is re-executed according to the preset retry rule to obtain the retry response result; When the compensation strategy is configured as a reverse compensation strategy, the pre-configured reverse compensation interface metadata is queried, the call parameters in the node record are reverse-mapped to the compensation interface input parameter field in the reverse compensation interface metadata, the state recovery operation is performed, and the state recovery execution result is obtained. Obtain the current timestamp, aggregate the abnormal node number, the policy type configured in the compensation strategy, the retry response result or the state recovery execution result, and the current timestamp to generate the abnormal handling report.

7. The method for automatic orchestration of MES microservice interfaces based on production business semantics according to any one of claims 1 to 6, characterized in that, Following the step of outputting a structured log archive, the following steps are also included: Based on the spatiotemporal index in the structured log archive, extract historical abnormal node records within a preset time window whose execution status code indicates an abnormal status code; The historical abnormal node records are parsed to extract abnormal feature vectors, and the abnormal feature vectors are classified and aggregated according to the business semantic tags contained in the abnormal feature vectors to generate an abnormal node association sequence. The abnormal feature vectors include the abnormal node number and the compensation strategy execution result in the abnormal handling report. The frequency of occurrence of the abnormal node number in the abnormal node association sequence is counted, and combined with the success rate of the state recovery operation in the compensation strategy execution result, the node failure risk index corresponding to the abnormal node number is calculated. When the node failure risk index is greater than a preset risk threshold, obtain the node dependency topology and interface call parameters corresponding to the abnormal node number; A template optimization strategy is generated based on the node dependency topology, the interface call parameters, and the node failure risk index. The basic templates corresponding to the business semantic tags in the pre-configured orchestration template library are then updated and configured according to the template optimization strategy.

8. An automatic orchestration system for MES microservice interfaces based on production business semantics, characterized in that, The system includes: The business request processing module is used to receive production business requests from the manufacturing execution system and extract the context information therein, including work order number, process number, product model, equipment number and business operation type fields; The business semantic tag generation module is used to generate business semantic tags corresponding to the production business request based on the context information and through a rule matching engine. The interface metadata query and association module is used to query a predefined interface metadata database to obtain microservice interface metadata associated with the business semantic tag; wherein, the metadata includes interface address, state constraints and idempotency rules; The orchestration template dynamic optimization module is used to match basic templates from the pre-configured orchestration template library based on the business semantic tags and microservice interface metadata, and to generate timeout thresholds and node priority parameters through dynamic calculation, and output the optimized executable orchestration template. The instruction set generation module is invoked to parse the node dependencies of the executable orchestration template, map the work order number and device number to the interface call parameters, and generate an atomic call instruction set carrying a global tracing identifier. The node record generation module is used to call the centralized status verification service to verify whether the work order status, equipment status and material status corresponding to each node in the atomic call instruction set meet the status constraints, and output the node record with execution status code. The exception handling module is used to perform retry calls or reverse compensation interface operations and generate an exception handling report when the execution status code in the node record indicates an exception, according to the compensation strategy configuration in the executable orchestration template. The log generation module is used to aggregate the business semantic tags, atomic call instruction sets, node records and exception handling reports, store them in shards according to work order numbers and build a spatiotemporal index, and output structured orchestrated log archives.

9. A computer device, characterized in that: The method includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor, when executing the program, implements the method as claimed in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that: The computer program is stored that can be loaded by a processor and executed as described in any one of claims 1 to 7.

Images