A microkernel-based business process dynamic arrangement method and system

Abstract

The application relates to the technical field of business process dynamic arrangement, and discloses a business process dynamic arrangement method and system based on a microkernel, which comprises the following steps: collecting a runtime data mode and context behavior characteristics of a component, generating a double-layer associated execution record; comparing the runtime data mode with a static interface contract, generating an implicit mode drift detection result; grouping and establishing an independent behavior baseline according to a calling context, generating a context-based behavior anomaly detection result; tracing a drift field propagation path along a component link, generating a cross-layer causal association detection result; quantifying the correlation between a drift characteristic dimension and a behavior anomaly dimension, generating a refined cross-layer causal attribution result; hot-inserting a data preprocessing plug-in node based on a key drift factor, generating a runtime cross-layer repair scheme; monitoring a repair effect, updating an interface contract runtime label, and outputting a cross-layer association detection report.

Description

Technical Field

[0001] This invention relates to the field of dynamic orchestration of business processes, and more specifically, to a microkernel-based method and system for dynamic orchestration of business processes. Background Technology

[0002] In a dynamic orchestration system for business processes based on a microkernel scheduling engine and a pluggable business component library, a visual orchestration configuration center generates process configuration files to define the logical combination and link relationships of each pluggable component. The microkernel scheduling engine dynamically parses the process configuration files at runtime and loads and executes pluggable components as needed. Each pluggable component interfaces with data from multiple heterogeneous data sources, and data flow between components is completed through a unified input and output parameter interface protocol.

[0003] In existing technologies, the static interface contracts declared during component registration in pluggable business component libraries are only validated for parameter format, type, and semantic compatibility during the orchestration and submission phase. The dynamic loading and execution monitoring module maintains a behavior baseline for each component that is a unified model across all calling scenarios.

[0004] When an upstream data source experiences data schema drift during runtime without violating formal type constraints, static interface contract validation fails to detect this implicit drift. Mixing calls from different processes and input data schemas within the same baseline causes implicit behavioral deviations of components in specific process contexts to be masked by an overly broad baseline, resulting in missed detections. Even if behavioral anomalies are detected, they can only be pinpointed to a specific input triggering the deviation, failing to trace it back to the schema drift event in the upstream data source. Data contract validation and component behavior monitoring operate at the data schema layer and component execution layer respectively, lacking cross-layer causal correlation capabilities, leading to the inability to diagnose implicit anomalies in a closed loop, creating blind spots in process stability assurance. Summary of the Invention

[0005] This invention provides a microkernel-based method and system for dynamic orchestration of business processes, which solves the technical problems in related technologies that cannot detect implicit data pattern drift between components without violating interface protocol type constraints, cannot distinguish between contextual conditional behavior anomalies and global behavior anomalies, and cannot trace the propagation path of implicit drift fields across layers and perform causal attribution.

[0006] This invention discloses a microkernel-based dynamic orchestration method for business processes, comprising: extracting runtime dynamic data pattern descriptions of each plugin component node in the execution process configuration file of the microkernel scheduling engine, collecting context-sensitive behavioral feature vectors, and associating and binding the two with execution transaction identifiers to generate a two-layer associated execution record;

[0007] The runtime dynamic data pattern description of each component node is compared with the interface contract declaration field by field. The drift amplitude value of each field is calculated, and fields whose drift amplitude value exceeds the perception threshold but does not violate the interface protocol form type constraint are selected to generate implicit pattern drift detection results.

[0008] The two-layer associated execution records are grouped according to the context label information. A behavior baseline is independently established for each call context group. The context-level deviation distance and global-level deviation distance of the current execution are calculated. When the context-level deviation distance exceeds the context anomaly threshold but the global-level deviation distance does not exceed the global anomaly threshold, it is determined to be a context-conditional behavior anomaly, and a behavior anomaly detection result for each context is generated.

[0009] The propagation path of the implicit drift field is traced along the component link defined in the process configuration file. The execution records of downstream component nodes are grouped according to whether the input data contains the implicit drift field. The difference between the average deviation distance of the two groups in the behavior fingerprint space of the corresponding call context group is compared. When the difference exceeds the causal association threshold, a cross-layer causal association detection result is generated.

[0010] For confirmed causal pairs, the drift feature dimension vector and the behavioral anomaly dimension vector are extracted, the correlation coefficient between each component of the two is calculated, key drift factors are identified, and refined cross-layer causal attribution results are generated.

[0011] Furthermore, the description of the runtime dynamic data pattern extracted from each plugin component node includes:

[0012] At the output end of each component node, the actual output data is sampled, and the name, actual value type, nesting structure depth and value range distribution statistics of each field in the sampled data are extracted. The dynamic data mode description at runtime is accumulated in a sliding window manner.

[0013] The sliding window is a fixed-length time window or a sampling number window. Whenever new sampled data arrives, the oldest sampled data is moved out of the window and the new sampled data is included in the window. The value range distribution statistics of each field are recalculated based on all sampled data in the window. The context-sensitive behavior feature vector is composed of the execution time, memory usage, and output data quality indicators of each plug-in component node, combined with context label information. The context label information includes the caller process identifier, the node's position identifier in the process, and the input data feature summary. The input data feature summary is a fixed-length summary string generated by hashing the combination of value types and value range intervals of each field in the input data of each call.

[0014] Furthermore, the value range distribution statistics include: minimum, maximum, mean, standard deviation and quantile set calculated for numeric fields, length distribution and enumeration value frequency distribution calculated for string fields, and subfield quantity distribution and nesting depth frequency distribution for nested structure field records;

[0015] The sampling of the actual output data adopts a hierarchical sampling strategy. First, the output data is divided into layers according to the field type, and then data records are randomly extracted from each layer according to a preset sampling ratio.

[0016] Furthermore, the calculation of the drift magnitude values ​​for each field includes:

[0017] For numerical fields, the value range constraints declared in the interface contract are represented as the reference distribution, and the runtime value range distribution statistics are represented as the observed distribution. The first-order Wasserstein distance between the reference distribution and the observed distribution is calculated as the drift magnitude value. The first-order Wasserstein distance is the minimum cost of the shift probability quality required to transform the reference distribution into the observed distribution. The shift cost is measured by the absolute distance between two points on the numerical axis.

[0018] For string-type fields and nested structure-type fields, after discretizing their respective frequency distributions or structure distributions, the Jensen-Shannon divergence between the reference distribution and the observed distribution is calculated as the drift amplitude value. The Jensen-Shannon divergence is obtained by averaging the two Kullback-Leibler divergences by introducing the mean distributions of the reference distribution and the observed distribution. The Kullback-Leibler divergence is the information gain of one distribution relative to the reference distribution when one distribution is used as a reference. It is calculated by summing the product of the probability of the reference distribution at each discrete value and the logarithm of the ratio of the probabilities of the two distributions.

[0019] When generating latent pattern drift detection results, the drift field is divided into two levels, mild drift and severe drift, according to the magnitude of the drift amplitude value: when the drift amplitude value exceeds the perception threshold but does not exceed a preset multiple of the perception threshold, it is marked as mild drift; when it exceeds the preset multiple, it is marked as severe drift.

[0020] Furthermore, the grouping of the two-level associated execution records according to context label information includes:

[0021] Grouping is done according to the process identifier and input data feature summary in the context label information. Under the same process identifier, the Hamming distance between the input data feature summaries of each execution record is calculated. When the Hamming distance is less than the preset summary similarity threshold, they are grouped into the same call context group.

[0022] The Hamming distance is the number of characters that differ at corresponding positions between two fixed-length summary strings, and the summary similarity threshold is a pre-set maximum allowed number of different digits.

[0023] When the number of execution records under a certain process identifier is less than the preset minimum number of samples, the execution records under that process identifier are included in the global unified behavior fingerprint space for anomaly detection. After a sufficient number of execution records are accumulated, a call context group is established independently.

[0024] Furthermore, establishing a behavioral baseline independently for each invocation context group includes:

[0025] After Z-score standardization of all context-bound behavioral feature vectors in each call context group, the mean vector and covariance matrix are calculated to form the normal behavior fingerprint spatial parameters.

[0026] The context-level deviation distance is calculated using Mahalanobis distance, which is the difference between the standardized behavior feature vector of the current execution and the mean vector of the corresponding calling context group, weighted by the inverse of the covariance matrix, and then the square root of the quadratic form. The global-level deviation distance is calculated in the same way in the global unified behavior fingerprint space obtained by the execution records of all calling context groups.

[0027] The mean vector and covariance matrix of historical execution records are calculated using an exponentially decaying weighted method, with execution records closer to the current time being assigned higher weights. The weight of each execution record is the product of the negative decay coefficient of the natural constant and the time difference raised to the power of the product. The weighted mean vector is the sum of the corresponding behavioral feature vectors with each weight as a coefficient, divided by the sum of all weights. The weighted covariance matrix is ​​the sum of the outer products of the differences between each behavioral feature vector and the weighted mean vector with each weight as a coefficient, divided by the sum of all weights. The decay coefficient is preset based on the historical call frequency of the call context group and the expected stable period of the component's normal behavior.

[0028] Furthermore, the propagation path of the implicit drift field tracing along the component link defined in the process configuration file includes:

[0029] Based on the parameter mapping relationship between each component node in the process configuration file, determine whether the drift field is mapped to the input parameter field of the downstream component node. If so, include the corresponding downstream component node in the drift propagation path.

[0030] The execution records of the two-layer association of downstream component nodes are grouped according to whether the input data contains a hidden drift field, and the execution record group containing the drift field and the execution record group not containing the drift field are obtained. The average Mahalanobis distance of the two groups is calculated in the independent behavior fingerprint space of the corresponding call context group as the average deviation distance. The difference between the average deviation distances of the two groups is compared with the causal association threshold.

[0031] When tracing the propagation path of drifting fields, record the field mapping transformation information of each level of propagation. The field mapping transformation information includes field name changes, data type conversions, and aggregation operations. Based on the field mapping transformation information, adjust the causal association threshold of each level of downstream component nodes step by step: when passing through a level of field mapping containing aggregation operations or type conversions, multiply the causal association threshold corresponding to the level of field mapping containing aggregation operations or type conversions by a preset adjustment coefficient less than 1 based on the threshold of the previous level.

[0032] After the difference in average deviation distance exceeds the causal association threshold, a two-sample statistical test is performed on the deviation distance distribution of the two groups. The p-value obtained from the test is compared with the preset significance level. When the p-value is lower than the significance level, the causal association is confirmed.

[0033] Furthermore, the calculation of the correlation coefficient between the components of the two includes:

[0034] For confirmed causal pairs, the drift feature dimension values ​​of the drift field are extracted from the execution record group containing the drift field to form a drift feature dimension vector. The drift feature dimension values ​​include the value range offset, the distribution skew change, and the extreme value ratio change. At the same time, the behavior anomaly dimension values ​​of the downstream components are extracted to form a behavior anomaly dimension vector. The behavior anomaly dimension values ​​include the execution time deviation, the memory usage deviation, and the output data quality deviation.

[0035] After Z-score standardization is applied to each dimension of the drift feature dimension vector and the behavior anomaly dimension vector, the correlation coefficient between each component of the drift feature dimension vector and each component of the behavior anomaly dimension vector is calculated using the Pearson correlation coefficient. The Pearson correlation coefficient is the product of the covariance of the two components across all execution records and the standard deviation of each component.

[0036] The absolute values ​​of the corresponding rows of each drift feature dimension in the correlation coefficient matrix are summed and sorted, and the drift feature dimension with the highest ranking is selected as the key drift factor.

[0037] Furthermore, after generating refined cross-level causal attribution results, the process also includes:

[0038] Based on the characteristics of key drift factors, and through the dynamic loading capability of the microkernel scheduling engine, data preprocessing plugin nodes are hot-inserted into the parameter mapping link where the implicit drift field flows into the downstream component. Hot insertion means that the data preprocessing plugin, which is pre-registered in the pluggable business component library, is instantiated and inserted into the specified parameter mapping link without interrupting the execution of the current process.

[0039] For cases where the key drift factor is of the range offset type, the data preprocessing plugin node performs range pruning or linear scaling on the drift field value; for cases where the key drift factor is of the distribution skew type, the data preprocessing plugin node performs quantile normalization on the drift field value; for cases where the key drift factor is of the nested structure variation type, the data preprocessing plugin node performs structure mapping or default value filling on the nested structure of the drift field.

[0040] After performing data normalization, the normalized data is re-validated for interface protocol constraints. If the re-validation fails, the preprocessing operation is rolled back and an alarm message is generated.

[0041] Within a preset observation period after the data preprocessing plugin node is hot-inserted, the context-aware behavior feature vectors of downstream component nodes are continuously collected and the context-level deviation distance is calculated. It is then determined whether the context-level deviation distance has fallen below the context anomaly threshold to determine whether the repair has taken effect. The drift trend information of the implicit drift field and the associated behavior anomaly record are written into the runtime supplementary annotation of the corresponding component interface contract. When the drift amplitude value of the same field shows an increasing trend in multiple consecutive preset observation periods, an interface contract revision suggestion is generated. The output is a dynamically orchestrated runtime cross-layer association detection report containing details of implicit drift fields, cross-layer causal attribution paths, key drift factors, and verification of repair effects.

[0042] This invention provides a microkernel-based dynamic business process orchestration system, comprising:

[0043] The dual-layer associated execution record generation module is used to extract the runtime dynamic data pattern description of each plugin component node in the microkernel scheduling engine execution process configuration file, collect the behavior feature vector with context, and associate and bind the two with the execution transaction identifier to generate a dual-layer associated execution record.

[0044] The implicit pattern drift detection module is used to compare the runtime dynamic data pattern description of each component node with the interface contract declaration field by field, calculate the drift magnitude value of each field, filter out fields whose drift magnitude value exceeds the perception threshold but does not violate the interface protocol form type constraint, and generate implicit pattern drift detection results.

[0045] The context-based behavior anomaly detection module is used to group the two-layer associated execution records according to context label information, establish a behavior baseline independently for each call context group, calculate the context-level deviation distance and global-level deviation distance of the current execution, and generate context-based behavior anomaly detection results when the context-level deviation distance exceeds the context anomaly threshold but the global-level deviation distance does not exceed the global anomaly threshold.

[0046] The cross-layer causal association detection module is used to trace the propagation path of implicit drift fields along the component links defined in the process configuration file. It groups the execution records of downstream component nodes according to whether the input data contains implicit drift fields, compares the difference of the average deviation distance between the two groups in the behavior fingerprint space of the corresponding call context group, and generates cross-layer causal association detection results when the difference exceeds the causal association threshold.

[0047] The refined cross-layer causal attribution module is used to extract the drift feature dimension vector and the behavioral anomaly dimension vector from the confirmed causal relationship pairs, calculate the correlation coefficient between each component of the two, identify key drift factors, and generate refined cross-layer causal attribution results.

[0048] This invention establishes a correspondence between the data pattern layer and the component execution layer by generating a two-layer associated execution record through associating runtime dynamic data pattern descriptions with contextualized behavioral feature vectors using execution transaction identifiers. By grouping execution records according to process identifiers and input data feature summaries and independently establishing behavioral baselines for each call context group, implicit behavioral deviations in specific process contexts can be detected. By tracing the propagation path of drift fields along component links and comparing behavioral deviation distances by grouping input data according to whether it contains drift fields, a quantifiable causal relationship is established between downstream component behavioral anomalies and upstream data pattern drift. By quantifying the correlation coefficient between drift feature dimensions and behavioral anomaly dimensions to identify key drift factors and hot-inserting them into data preprocessing plugin nodes, runtime repair is achieved. This invention solves the technical problems of the lack of cross-layer causal association capabilities between the data pattern layer and the component execution layer in existing technologies, and the inability to perform closed-loop diagnosis of implicit anomalies. It achieves the technical effect of completing a complete closed-loop process from implicit drift detection to causal attribution to runtime repair without interrupting process execution. Attached Figure Description

[0049] Figure 1 This is a flowchart of the microkernel-based dynamic orchestration method for business processes provided in this embodiment of the invention;

[0050] Figure 2 This is a schematic diagram comparing the field drift amplitude of the supplier qualification verification component provided in this embodiment of the invention;

[0051] Figure 3This is a schematic diagram of the Z-score distribution of the execution behavior characteristics of the supplier qualification verification component provided in this embodiment of the invention;

[0052] Figure 4 This is a schematic diagram comparing the execution time of the budget check component before and after an anomaly provided in an embodiment of the present invention;

[0053] Figure 5 This is a schematic diagram of the comparison of resource usage in the execution record group of the budget check component provided in this embodiment of the invention;

[0054] Figure 6 This is a schematic diagram of the correlation heatmap between drift feature dimension and behavior anomaly dimension provided in an embodiment of the present invention;

[0055] Figure 7 This is a schematic diagram illustrating the trend of the change in the context-level deviation distance of the budget check component before and after repair, provided in an embodiment of the present invention.

[0056] Figure 8 This is a schematic diagram comparing the distribution of the credit score field value range before and after normalization, as provided in an embodiment of the present invention. Detailed Implementation

[0057] In a dynamic orchestration system for business processes based on a microkernel scheduling engine and a pluggable business component library, a visual orchestration configuration center generates process configuration files to define the logical combination and chain relationships of each pluggable component. The microkernel scheduling engine dynamically parses the process configuration files at runtime and loads and executes pluggable components as needed. Each pluggable component interfaces with data from multiple heterogeneous data sources (including relational databases, NoSQL storage, third-party APIs, etc.), and data flow between components is completed through a unified input and output parameter interface protocol. The dynamic loading and execution monitoring module collects the execution status, data flow, and performance metrics of each node in real time.

[0058] In the above scenario, when the upstream data source experiences data schema drift during runtime (e.g., changes in field value range or nested structure), the drifted data is passed downstream along the component links defined in the process configuration file. Although the downstream plug-in components do not violate the formal type constraints of the interface protocol when processing the drifted data, their runtime behavior indicators such as execution time and memory usage show implicit deviations.

[0059] The existing solution has the following technical problems: First, the static interface contract declared during component registration in the pluggable business component library only performs parameter form type and semantic compatibility verification during the orchestration and submission phase. When the actual data pattern drifts at runtime but does not violate the form type constraints (e.g., the value range of a numeric field expands from [0, 100] to [0, 10000], but the type remains numeric), the static interface contract verification cannot detect this implicit drift and will not trigger a conflict alarm. Second, although the dynamic loading and execution monitoring module can collect the execution status and performance indicators of each node, the behavioral baseline maintained by the dynamic loading and execution monitoring module for each component is a unified model across all calling scenarios. This mixes calls from different processes and different input data patterns in the same baseline, causing implicit behavioral deviations of components in a specific process context to be masked by the overly broad baseline range and thus missed. Third, even if behavioral anomalies are detected, it can only locate a certain input that triggered the deviation and cannot trace it back to the pattern drift event of the upstream data source. The root cause of the above three problems is that data contract verification and component behavior monitoring work at the data model layer and component execution layer respectively, lacking the ability to establish cross-layer causal relationships. This results in the inability to diagnose hidden anomalies in a closed loop, and there are blind spots in ensuring process stability.

[0060] According to an embodiment of this implementation, a microkernel-based dynamic orchestration method for business processes is provided. It should be understood that the method of this implementation is executed by a computing device that has deployed a microkernel scheduling engine, a pluggable business component library, and a dynamic loading and execution monitoring module. The computing device has a runtime environment for the component links defined in the execution process configuration file and is configured with persistent storage resources for storing two-layer associated execution records.

[0061] At least one embodiment of the present invention discloses a microkernel-based dynamic orchestration method for business processes, such as... Figure 1 As shown, it includes the following steps:

[0062] Step 1: Collect component runtime data patterns and context behavior characteristics to generate a two-layer associated execution record;

[0063] When the microkernel scheduling engine executes each plugin component node in the execution flow configuration file, it samples the actual output data of each plugin component node at the output end of each node. It extracts the name, actual value type, nesting depth, and value range distribution statistics of each field in the sampled data, accumulating these statistics in a sliding window manner to generate a runtime dynamic data pattern description for each plugin component node. Simultaneously, the dynamic loading and execution monitoring module collects the execution time, memory usage, and output data quality metrics of each plugin component node, and extracts the context label information for each call. The context label information includes the caller's process identifier, the node's position in the process, and a summary of input data features. These metrics are combined with the context label information to form a context-sensitive behavioral feature vector. The runtime dynamic data pattern description and the context-sensitive behavioral feature vector are then associated and bound using the same execution transaction identifier, generating a two-layer associated execution record.

[0064] It should be noted that the above sliding window method refers to maintaining a window of fixed length. The time window or sampling number window is used to move the oldest sampling data out of the window whenever new sampling data arrives, and to add the new sampling data into the window. Based on all the sampling data within the window, the value range distribution statistics of each field are recalculated, thereby generating a runtime dynamic data pattern description reflecting the characteristics of recent data patterns. This is the preset window length parameter.

[0065] It should be noted that the above-mentioned input data feature summary refers to a fixed-length summary string generated by hashing the combination of value types and value range of each field in the input data of each call. It is used to identify the call batch of the same component under different input data modes.

[0066] It should be noted that the above value range distribution statistics refer to the minimum, maximum, mean, standard deviation and quantile set calculated for numeric fields, the length distribution and enumeration value frequency distribution calculated for string fields, and the subfield quantity distribution and nesting depth frequency distribution for nested structure field records.

[0067] In this embodiment, to reduce sampling overhead when the amount of component output data is large, a layered sampling strategy is adopted when sampling the actual output data of each plug-in component node: first, the data is layered according to the field type of the output data, and then data records are randomly extracted from each layer according to a preset sampling ratio. The layered sampling strategy reduces the total amount of sampled data that needs to be processed while maintaining the representativeness of the distribution of each field type.

[0068] Step 2: Compare the runtime data pattern with the static interface contract to generate implicit pattern drift detection results;

[0069] The runtime dynamic data pattern description of each component node is compared field by field with the interface contract declaration registered by each component node in the pluggable business component library. For each field, the drift magnitude of the runtime value range distribution of each field relative to the value range constraint of the interface contract declaration is calculated. The set of fields whose drift magnitude exceeds the set perception threshold but does not violate the interface protocol form type constraint is selected, and the implicit pattern drift detection result of each component node is generated. The implicit pattern drift detection result includes the name of the drift field, the identifier of the component node to which it belongs, the drift magnitude value, and the drift direction information.

[0070] The above drift amplitude values ​​are calculated as follows: For numeric fields, the range constraints declared in the interface contract are represented as a reference distribution. The runtime value range distribution statistics are represented as the observed distribution. The Wasserstein distance between the two is calculated as the drift amplitude value. The formula is:

[0071]

[0072] in, For field identification, The first-order Wasserstein distance. For fields The value range reference distribution in the interface contract declaration For fields The observed distribution in the runtime dynamic data pattern description.

[0073] Furthermore, the aforementioned first-order Wasserstein distance refers to the distance from the reference distribution. Transform into observed distribution The minimum cost of the required probability quality of movement, where the cost of movement is measured by the absolute distance between two points on the numerical axis; for discretized numerical field distributions, the first-order Wasserstein distance is equivalent to the integral of the absolute value of the difference between the cumulative distribution functions of the two distributions on the numerical axis, used to capture the drift magnitude caused by the overall displacement of the field value range and changes in the distribution shape.

[0074] For string-type fields and nested structured fields, after discretizing their respective frequency distributions or structure distributions, the drift amplitude is calculated using Jensen-Shannon divergence. The formula is:

[0075]

[0076] in, The mean distribution is a binary distribution. The divergence is Kullback–Leibler.

[0077] Furthermore, the above Kullback–Leibler divergence This refers to the situation where two discrete probability distributions are given. and ,by When the reference distribution is used Compared to The information gain, the Kullback–Leibler divergence is calculated as follows: The probability and corresponding value for each discrete value , The summation of the logarithmic products of probability ratios; Jensen–Shannon divergence by introducing the mean distribution. Symmetricize the Kullback–Leibler divergence, making The value of is bounded and symmetrical with respect to the two input distributions, and is suitable for measuring the drift between the frequency distribution of string enumeration values ​​or the number distribution of subfields in nested structures.

[0078] It should be noted that the aforementioned perception threshold refers to a threshold pre-set based on the distribution characteristics of the historical drift amplitude values ​​of each field. For example, the 95th percentile of the drift amplitude values ​​of each field in the historical operation records can be used as the perception threshold, or a fixed value can be preset by the operations and maintenance personnel based on the business tolerance.

[0079] It should be noted that the above-mentioned failure to violate the formal type constraints of the interface protocol means that the actual value type of the field (such as numeric, string, boolean, nested object, etc.) is consistent with the declared type of the field in the interface contract declaration, and the formal rules such as mandatory constraints and array length constraints are satisfied, with the only deviation occurring at the level of value range distribution.

[0080] In this embodiment, to distinguish between latent drifts of different severity, when generating latent pattern drift detection results, the drift field is further divided into two levels: mild drift and severe drift, based on the magnitude of the drift amplitude value. A drift amplitude value exceeding the perception threshold but not exceeding a preset multiple (e.g., 2 times) of the perception threshold is marked as mild drift, while a value exceeding this preset multiple is marked as severe drift. This classification provides a basis for differentiated processing of drifts of different severity in subsequent steps.

[0081] Step 3: Establish independent behavior baselines by calling context and generate behavior anomaly detection results for each context;

[0082] The accumulated set of two-layer associated execution records for each component node is grouped according to the process identifier and input data feature summary in the context label information. Execution records belonging to the same process and with similar input data patterns are grouped into the same calling context group. A clustering algorithm is used here to group the input data feature summaries. The input of the clustering algorithm is a vector set composed of the input data feature summaries of each execution record, and the output is the calling context group number to which each execution record belongs. Under the same process identifier, if the Hamming distance between the input data feature summaries is less than a preset summary similarity threshold, they are grouped into the same calling context group.

[0083] Furthermore, the Hamming distance mentioned above is used to measure the number of different characters at corresponding positions between two fixed-length summary strings. The summary similarity threshold is a pre-set maximum number of different characters allowed. When the Hamming distance between two summary strings is less than the summary similarity threshold, the input data patterns corresponding to the summary similarity threshold are considered to be sufficiently similar and can be classified into the same calling context group.

[0084] A behavioral baseline is calculated independently for each call context group, establishing its own independent normal behavior fingerprint space. Specifically, for a given call context group... All context-sensitive behavioral feature vectors in Calculate the mean vector of the behavioral feature vectors with context. Covariance Matrix , constitute the calling context group Normal behavioral fingerprint spatial parameters .in, For calling context group The number of behavioral feature vectors with context.

[0085] It should be noted that the contextualized behavioral feature vector consists of indicators with different dimensions, such as execution time, memory usage, and output data quality metrics. When calculating the mean vector... Covariance Matrix Previously, Z-score standardization was applied to each dimension of the index to eliminate the influence of different units on subsequent distance calculations.

[0086] The context-sensitive behavior feature vector of the current execution. Matched to the corresponding call context group In the call context group Calculate context-level offset distance in independent behavioral fingerprint space The formula is:

[0087]

[0088] in, This is the context-defined feature vector of the current execution (the value after Z-score standardization). For calling context group The mean vector of behavioral features, For calling context group The inverse of the covariance matrix, This indicates transpose. The above formula is the Mahalanobis distance formula, used to measure the degree of deviation between the characteristics of the current execution behavior and the spatial center of the normal behavior fingerprint of the corresponding context group.

[0089] Simultaneously, global-level offset distance is calculated in the globally unified behavioral fingerprint space. Parameters of the globally unified behavioral fingerprint space The formula is calculated by combining the execution records of all call context groups of this component:

[0090]

[0091] in, This is the mean vector of global behavioral features. It is the inverse of the global covariance matrix. This indicates transpose.

[0092] when Exceeding the context exception threshold and Not exceeding the global anomaly threshold When an execution is deemed to be a context-conditional behavior anomaly, a behavior anomaly detection result for each context is generated. This result includes the anomaly component node identifier, the calling context group number, the context-level deviation distance value, and the corresponding behavioral feature dimension deviation details.

[0093] It should be noted that the above-mentioned context anomaly threshold and global anomaly threshold The threshold is set based on the distribution statistics of historical deviation distances in the respective behavioral fingerprint space. For example, the mean of historical deviation distances plus a preset multiple (e.g., 3 times) of the standard deviation can be used as the threshold, or the upper bound of the confidence interval based on the chi-square distribution can be used as the threshold.

[0094] Furthermore, the aforementioned upper bound of the confidence interval based on the chi-square distribution refers to the fact that when the behavioral feature vector with context follows a multivariate normal distribution, the square of the Mahalanobis distance approximately follows a chi-square distribution with degrees of freedom equal to the dimension of the feature vector. The square root of the quantile of the chi-square distribution at a preset confidence level (e.g., 99%) is used as the upper bound of the anomaly threshold, so that the setting of the threshold has a clear statistical probability meaning.

[0095] It should be noted that in the above clustering grouping, when the number of execution records under a certain process identifier is insufficient to support the independent establishment of a behavior baseline (e.g., less than the preset minimum number of samples), the execution records under that process identifier are temporarily assigned to the global unified behavior fingerprint space for anomaly detection. After a sufficient number of execution records are accumulated, the call context group is established independently.

[0096] In this embodiment, to adapt the behavior baseline to the slow drift of normal component behavior over time, an exponentially decaying weighting method is used for historical execution records when calculating the behavior baseline for each call context group, assigning higher weights to execution records more recent than the current time. Specifically, for each call context group... The timestamp is The Each execution record, its weight Calculated as ,in For the current time, For the first The timestamp of each execution record The attenuation coefficient is... It is a natural constant. To perform record indexing. Weighted mean vector. Covariance Matrix The alternative equal-weighted calculation results are used to construct the spatial parameters of the normal behavior fingerprint. The exponential decay weighting method makes the behavior baseline closer to the recent normal behavior characteristics of the component, avoiding baseline deviation caused by interference from historical data.

[0097] Furthermore, in the above exponentially decaying weighted method, the weighted mean vector The calculation method is based on the weight of each execution record. The coefficients correspond to the behavioral feature vectors After performing a weighted summation, divide by the sum of all weights, that is... ;

[0098] Weighted covariance matrix The calculation method is based on the weight of each execution record. For coefficient pairs After performing a weighted summation, divide by the sum of all weights, that is... ,in For the first The contextualized behavioral feature vector of each execution record (values ​​standardized by Z-score). To perform record indexing, This indicates transpose.

[0099] Furthermore, the aforementioned attenuation coefficient The rate at which the weight of historical execution records decays over time is determined by: The larger the value, the lower the weight given to earlier execution records, and the more sensitive the behavioral baseline is to recent behavioral changes; The smaller the value, the slower the weight decay of historical execution records, and the smoother the behavior baseline is to recent fluctuations. Based on the invocation context group The historical call frequency and the expected stable period of normal component behavior are pre-set to ensure that the exponential decay window covers a sufficient number of historical execution records, thus guaranteeing the mean vector. Covariance Matrix The statistical estimates are well supported by the sample.

[0100] Step 4: Trace the propagation path of the drift field along the component link to generate cross-layer causal association detection results;

[0101] Following the component link data flow defined in the process configuration file, starting from the component node to which each drift field belongs in the implicit pattern drift detection results, the path of the downstream plug-in component node through which the implicit drift field flows is traced. The tracing method is as follows: based on the parameter mapping relationship between each component node in the process configuration file, it is determined whether the drift field is mapped to the input parameter field of the downstream component node. If so, the downstream component node is included in the drift propagation path.

[0102] For each downstream component node that receives a latent drift field as input, group the execution records from the two-level association of the downstream component node according to whether the input data contains the latent drift field, and obtain the execution record group containing the drift field. and execution record groups that do not contain drift fields Execution record groups are calculated in the independent behavior fingerprint space of the call context group corresponding to each downstream component node. and execution record group average deviation distance and The formula is:

[0103]

[0104]

[0105] in, and Execution record group and execution record group The number of execution records, This is the context-defined behavioral feature vector (the value after Z-score standardization) for each execution record. and For the normal behavior fingerprint space parameters of the call context group corresponding to the downstream component node, Covariance matrix The inverse matrix, This indicates transpose.

[0106] Calculation execution record group and execution record group The difference in average deviation ,when Exceeding the set causal association threshold When a downstream component node is identified as exhibiting behavioral anomalies triggered by latent pattern drift, a cross-layer causal correlation detection result is generated. This result includes the upstream drift source component node identifier, drift field name, downstream affected component node identifier, drift propagation path, and the difference in average deviation distance. .

[0107] It should be noted that the above-mentioned grouping criterion based on whether the input data contains implicit drift fields is to match the runtime dynamic data pattern description in the execution record with the drift field name recorded in the implicit pattern drift detection result: if the input data pattern description of the execution record contains a field marked as implicit drift and the drift amplitude value of that field exceeds the perception threshold, then it is classified into the execution record group. Otherwise, it will be placed in the execution record group. .

[0108] It should be noted that the above-mentioned causal association threshold It can execute record groups based on the downstream component nodes under normal operating conditions. and execution record group The historical fluctuation range of the average deviation distance can be set, for example, by taking the average of the historical fluctuation range plus a preset multiple of the standard deviation.

[0109] In this embodiment, to avoid missed detection due to weakened causal correlation signals of downstream remote nodes caused by progressive propagation attenuation when the drift propagation path is long, the field mapping transformation information (including field name changes, data type conversions, and aggregation operations) of each propagation level is recorded when tracking the drift field propagation path. Based on this field mapping transformation information, a causal correlation threshold is set for each level of downstream component nodes. Perform step-by-step adjustments: If the drift field undergoes aggregation operations or type conversion during propagation, appropriately reduce the causal correlation threshold of that level to improve the detection sensitivity of drift propagation with signal attenuation after mapping conversion.

[0110] Furthermore, the aforementioned method of adjusting the causal correlation threshold step by step refers to multiplying the corresponding causal correlation threshold of each level by a preset adjustment coefficient (which is less than 1) on the basis of the threshold of the previous level when the field mapping includes aggregation operations or type conversions. This makes the causal correlation threshold applicable to downstream nodes that are farther away from the drift source and undergo more mapping conversions lower, so that causal correlation determination can still be triggered after the signal has been attenuated step by step.

[0111] In this embodiment of the application, in order to further improve the reliability of causal relationship determination, Exceeding the causal association threshold Afterwards, the execution record group was also... and execution record group A two-sample statistical test (e.g., Welch's t-test) is performed on the deviation distance distribution. The p-value obtained from the test is compared with a pre-set significance level. A causal association is only confirmed when the p-value is below the significance level. This statistical test step is performed in... The threshold determination was supplemented with significance verification at the distribution level, which reduced misjudgments caused by sample fluctuations.

[0112] Step 5: Quantify the correlation between the drift feature dimension and the behavioral anomaly dimension to generate refined cross-layer causal attribution results;

[0113] Based on step 4, for each pair of causal relationships confirmed in the cross-layer causal relationship detection results (i.e., the pairing of upstream drift fields and downstream affected component nodes), the correlation between the specific drift feature dimensions of the latent drift fields and the specific dimensions of the abnormal behavior of downstream components is further quantified.

[0114] Specifically, for a confirmed causal relationship pair, from the execution record group Extract the drift field from the execution record The drift feature dimension vector is composed of various drift feature dimension values ​​(including range offset, distribution skewness change, extreme value ratio change, etc.). Simultaneously, extract various behavioral anomaly dimension values ​​from downstream components (including deviations in execution time, memory usage, and output data quality) to construct a behavioral anomaly dimension vector. It should be noted that the drift feature dimension vector The components and the behavioral anomaly dimension vector The components of the vector originate from measures with different physical meanings and have different dimensions. Before calculating the correlation coefficient, the drift feature dimension vector is analyzed. and behavioral anomaly dimension vector Each dimension was standardized using Z-scores to eliminate the impact of dimensional differences on the correlation coefficient calculation. The drift feature dimension vector was calculated using the Pearson correlation coefficient. Each component and the abnormal behavior dimension vector Correlation coefficients between the components The formula is:

[0115]

[0116] in, For the first Shift feature dimension vector in execution record The Each component (value after Z-score normalization) For the first The abnormal behavior dimension vector in the execution record The Each component (value after Z-score normalization) and The corresponding components are in the execution record group. The mean of all records. For the execution record group The number of execution records, index The drift feature dimension vector Component index, subscript For the abnormal behavior dimension vector Component index, For the execution record group The sample index of the execution record.

[0117] Based on each correlation coefficient The absolute value of the drift feature dimension is used to identify the drift feature dimension that contributes the most to each dimension of behavioral abnormality as the key drift factor, generating a refined cross-layer causal attribution result. The refined cross-layer causal attribution result includes the name of the key drift factor, the corresponding drift feature dimension identifier, the correlation coefficient value with each dimension of behavioral abnormality, and the ranking of contributions.

[0118] It should be noted that the above method for identifying key drift factors involves summing or sorting the absolute values ​​of each row (corresponding to each drift feature dimension) in the correlation coefficient matrix, and then selecting one or more drift feature dimensions that rank highest in the sorting. For example, the drift feature dimensions whose sum of absolute values ​​ranks in the top three can be selected as key drift factors.

[0119] Step 6: Generate a runtime cross-layer repair scheme based on the hot-insertion data preprocessing plugin node of the key drift factor;

[0120] Building upon step 5, the process further includes the following steps: Based on the characteristics of the key drift factors, and leveraging the dynamic loading capabilities of the microkernel scheduling engine, a data preprocessing plugin node is hot-plugged into the parameter mapping link where the implicit drift field flows into downstream components. The data preprocessing plugin node adheres to a unified input and output parameter interface protocol and performs targeted data normalization operations based on the type of the key drift factor.

[0121] Specifically, for key drift factors that are of the range offset type, the data preprocessing plugin node performs range pruning or linear scaling on the drift field values ​​to map the drift field's value range back to the normal value range of the interface contract declaration constraints. For key drift factors that are of the distribution skew type, the data preprocessing plugin node performs quantile normalization on the drift field values ​​to make the drift field's distribution shape approximate the reference distribution shape of the interface contract declaration constraints. For key drift factors that are of the nested structure variation type, the data preprocessing plugin node performs structural mapping or default value filling on the nested structure of the drift field to make the nested structure of the drift field conform to the nesting depth and subfield composition expected by downstream components.

[0122] Furthermore, the aforementioned structure mapping refers to reorganizing the current nested structure of the drifting field into the target structure according to the target nested structure declared in the downstream component interface contract recorded in the process configuration file, level by level, based on the field name correspondence. The aforementioned default value filling refers to filling in the corresponding position according to the type and default value definition of the subfield in the interface contract declaration when the nested structure of the drifting field lacks the expected subfield of the downstream component, so that the supplemented complete nested structure meets the input requirements of the downstream component.

[0123] The normalized data is passed to downstream component nodes via input and output parameter interface protocols for further execution, generating a runtime cross-layer repair solution for implicit pattern drift. The runtime cross-layer repair solution includes the insertion position of the hot-inserted data preprocessing plugin node, the type of normalization operation performed, and the corresponding key drift factor information.

[0124] It should be noted that the above hot-insertion operation refers to the microkernel scheduling engine instantiating and inserting a data preprocessing plugin pre-registered in the pluggable business component library into a specified parameter mapping link without interrupting the execution of the current process. Subsequently, all data passing through this parameter mapping link is processed by the data preprocessing plugin node before being passed to the downstream component node.

[0125] In this embodiment of the application, in order to avoid the introduction of additional data distortion by the preprocessing operation of hot insertion, after the data normalization operation is performed, the interface protocol formal constraints of the normalized data are re-verified to confirm that the formal constraints such as field type, mandatory content and array length of the normalized data are met. If the re-verification fails, the preprocessing operation is rolled back and an alarm message is generated.

[0126] Step 7: Monitor the repair effect and update the runtime annotations of the interface contract, and output a cross-layer association detection report;

[0127] Building upon step 6, the following steps are also included: continuously monitoring whether the behavioral deviation distance of downstream component nodes when receiving normalized data returns to the normal baseline range. Specifically, within a preset observation period after the hot insertion of the data preprocessing plugin node, context-aware behavioral feature vectors of downstream component nodes are continuously collected, and the context-level deviation distance is calculated in the independent behavioral fingerprint space of the corresponding call context group. Determine the context-level deviation distance Does it fall back to the context anomaly threshold? The following applies. If the context-level deviation distance occurs within the preset observation period... Stable and maintained at the context anomaly threshold The following indicates that the repair has taken effect.

[0128] Simultaneously, the drift trend information and associated abnormal behavior records of the implicit drift field are written into the runtime supplementary annotations of the corresponding component interface contract in the pluggable business component library, serving as update suggestions for the field's value range constraint rules. The runtime supplementary annotations include the drift field name, historical drift amplitude value change trend, a list of associated downstream affected components, and key drift factor information, providing a reference for more refined interface compatibility verification during subsequent orchestration and submission phases.

[0129] The output includes a dynamic orchestration runtime cross-layer correlation detection report containing details of implicit drift fields, cross-layer causal attribution paths, key drift factors, and verification of repair effects.

[0130] It should be noted that the aforementioned preset observation period refers to a time window set based on the average call frequency of downstream component nodes in the corresponding call context group, ensuring that a sufficient number of execution records are accumulated within the preset observation period for statistical judgment. For example, it can be set to the time required to accumulate no less than the preset minimum number of execution records.

[0131] In this embodiment of the application, in order to form a closed loop of continuous improvement, when the drift trend information of the same field continues to exist in multiple consecutive preset observation periods and the drift amplitude value shows an increasing trend, in addition to maintaining the hot-inserted data preprocessing plug-in node, an interface contract revision suggestion is also generated in the cross-layer association detection report during dynamic orchestration. It is suggested that the value range constraint range of the field be updated to the value range distribution range actually observed during the current runtime, so that the drift mode can be included in the formal interface contract verification scope during the subsequent orchestration submission stage.

[0132] This implementation establishes a two-layered associated execution record by associating runtime dynamic data pattern descriptions with context-sensitive behavioral feature vectors using execution transaction identifiers when the microkernel scheduling engine executes each plug-in component. This creates a correspondence between the data pattern layer and the component execution layer. Therefore, when implicit drift occurs in the data pattern layer, the behavioral feature changes of the component execution layer at the same point in time can be tracked through the execution transaction identifiers. This overcomes the shortcomings of existing solutions where static interface contract verification and execution monitoring modules work independently and cannot be associated across layers.

[0133] This implementation groups execution records by process identifier and input data feature summary, independently establishing a behavioral baseline for each call context group and performing a two-layer comparative detection of context-level and global-level deviation distances. Therefore, when a component deviates in behavior due to implicit drift in a specific process context, this deviation can be detected in the independent behavioral fingerprint space of the corresponding call context group, without being masked by an excessively wide global unified baseline boundary. This overcomes the problems in existing solutions where the unified behavioral baseline has an excessively wide baseline range due to the mixing of data from different call scenarios, and where implicit anomalies in specific contexts are missed.

[0134] This implementation traces the propagation path of implicit drift fields along the component links defined in the process configuration file, and compares behavioral deviation distances by grouping downstream component input data based on whether it contains implicit drift fields. This establishes a quantifiable causal relationship between downstream component behavioral anomalies and upstream data pattern drift. Therefore, when downstream component behavioral anomalies are detected, the pattern drift event of the upstream data source can be traced along the causal path, overcoming the diagnostic gap in existing solutions where monitoring can only locate a certain input triggering deviation but cannot trace the root cause of pattern drift.

[0135] Furthermore, this implementation identifies key drift factors by quantifying the correlation coefficient between drift feature dimensions and behavioral anomaly dimensions. Based on these key drift factors, it hot-inserts targeted data preprocessing plugin nodes using the dynamic loading capability of the microkernel scheduling engine, completing runtime repair without interrupting process execution. This achieves a complete closed-loop process from latent drift detection to causal attribution to runtime repair.

[0136] A large enterprise group deployed a procurement approval process system based on a microkernel scheduling engine and a pluggable business component library. This system defines multiple procurement approval processes through a visual orchestration and configuration center, including standard procurement processes, emergency procurement processes, and large-value procurement processes. Each process node corresponds to different business components, including supplier qualification verification components, budget check components, multi-level approval components, and contract generation components. These components interface with multiple heterogeneous data sources, such as the enterprise's ERP system, supplier management system, and financial system.

[0137] In March 20XX, the supplier management system adjusted its business rules, expanding the value range of supplier credit scores from [0, 100] to [0, 500] to support more granular credit rating. This adjustment maintained the numerical data type, conforming to the interface contract constraints of the supplier qualification verification component, and therefore did not trigger conflict alarms during the orchestration and submission phase. However, the expanded high-score data caused an abnormal increase in the execution time of the risk coefficient calculation logic in the downstream budget check component, resulting in fluctuations in memory usage.

[0138] like Figures 2-8 As shown, the method in this embodiment operates as follows:

[0139] Collect execution records of the two-level association;

[0140] When executing the supplier qualification verification component in the standard procurement process, the microkernel scheduling engine samples the output data of that component. A tiered sampling strategy is used: first, data is categorized into three layers based on field type: numeric, string, and nested object. 30% of records are extracted from the numeric field layer, 20% from the string field layer, and 40% from the nested object field layer. The sampling is performed using a sliding window length. Each record is used as a window to extract the runtime dynamic data pattern description of each field in the sampled data.

[0141]

[0142] Meanwhile, the dynamic loading and execution monitoring module collected behavioral characteristic data of a call executed by this component on March 15, 20XX at 14:23:07. The context label information of this call includes: process identifier as "standard procurement process", node location identifier as "node 02 - supplier qualification verification", and input data feature summary as hash value "a3f7c2d1e9b4".

[0143]

[0144] The above runtime dynamic data pattern description and the context-sensitive behavioral feature vector are associated and bound with the execution transaction identifier "TXN20XX0315142307-00234" to generate a two-layer associated execution record and store it in persistent storage resources.

[0145] Detect latent pattern drift;

[0146] The runtime dynamic data model description of the supplier qualification verification component is compared field by field with the interface contract declaration registered by the component in the pluggable business component library. The value range constraint of the "credit score" field in the interface contract declaration is referenced to the distribution. To ensure a uniform distribution within the interval [0, 100], the distribution was observed during runtime. Based on the statistical information in Table 1, an approximate normal distribution with a mean of 256.3 and a standard deviation of 128.7 is constructed.

[0147] The drift magnitude of the "Credit Score" field is calculated using the first-order Wasserstein distance:

[0148]

[0149] The drift amplitude value is calculated based on the integral of the absolute value of the difference between the cumulative distribution function of the reference distribution and the observed distribution on the numerical axis, reflecting the combined degree of drift as the center of the value range shifts from 50 to 256.3 and the distribution range expands from [0, 100] to [18, 487].

[0150]

[0151] The "Credit Score" field's drift magnitude of 206.3 far exceeds the perception threshold of 25.0, and is more than eight times the perception threshold, therefore it is marked as severely drifted. Since the actual value type of this field is still numeric, it does not violate the formal type constraints of the interface contract, and is therefore determined to be implicit pattern drift. An implicit pattern drift detection result is generated, recording the drift field name as "Credit Score," the component node identifier as "Node 02 - Supplier Qualification Verification," the drift magnitude value as 206.3, and the drift direction as an expansion of the value range towards higher values.

[0152] Establish behavioral baselines based on context and detect anomalies;

[0153] The accumulated set of two-layer associated execution records from the supplier qualification verification component is grouped according to the process identifier and the input data feature summary. Execution records with the process identifier "standard procurement process" and a Hamming distance between the input data feature summaries less than the summary similarity threshold of 3 are assigned to the call context group G1.

[0154]

[0155] The behavioral baseline is calculated using an exponentially decaying weighted average of all context-bound behavioral feature vectors in the call context group G1. The decay coefficient is then used. (Unit: per second), current time is 20XX-03-16 10:56:34. Taking the first execution record as an example, its timestamp is 20XX-03-10 09:32:45, the time difference is 518789 seconds, and the weight calculation is as follows:

[0156]

[0157] Because early records have very low weights, records with a time difference exceeding 7 days (604,800 seconds) are treated as having a weight of 0 in the actual calculation. A weighted mean vector and a weighted covariance matrix are calculated for the 60 execution records from the past 7 days.

[0158]

[0159] The context-level deviation distance is calculated using the context-defined behavioral feature vector (normalized Z-score values ​​from Table 2) of the current execution within the independent behavioral fingerprint space of the call context group G1. For simplicity, only the contributions of execution time and memory usage are calculated:

[0160]

[0161] Meanwhile, the global-level deviation distance calculated in the global unified behavior fingerprint space (containing execution records under all process identifiers) is 0.38. The context anomaly threshold is 2.5, and the global anomaly threshold is 3.2. Since the context-level deviation distance of 0.46 is less than the context anomaly threshold of 2.5, and the global-level deviation distance of 0.38 is less than the global anomaly threshold of 3.2, this execution did not trigger behavior anomaly detection.

[0162] However, on March 18, 20XX, the downstream node of the supplier qualification verification component—the budget check component—became abnormal.

[0163]

[0164] This execution belongs to the call context group G2 (Standard Procurement Process - Node 03 - Budget Check). The context-level deviation distance calculated in the independent behavior fingerprint space of the call context group G2 is 4.23, which exceeds the context anomaly threshold of 2.5, but the global deviation distance of 2.18 does not exceed the global anomaly threshold of 3.2. Therefore, it is judged as a context-conditional behavior anomaly, and a behavior anomaly detection result for the sub-context is generated.

[0165] Track the drift propagation path and correlate causality;

[0166] Following the component link data flow defined in the standard procurement process configuration file, the downstream path is traced starting from the implicit drift field "Credit Score" in "Node 02 - Supplier Qualification Verification". According to the parameter mapping relationship in the process configuration file, it is found that the "Credit Score" field is mapped to the "Supplier Credit Score" input parameter field of the "Node 03 - Budget Check" component.

[0167]

[0168] The execution records of the two-level association of the budget inspection component are grouped according to whether the input data contains the implicit drift field of "credit score". The drift value of the "supplier credit score" field is extracted from the runtime dynamic data pattern description of the execution record. If the value exceeds the perception threshold of 25.0, it is assigned to the execution record group "drift"; otherwise, it is assigned to the execution record group "clean".

[0169]

[0170] The average deviation distances of the execution record group drift and the execution record group clean in the independent behavioral fingerprint space of the call context group G2 were calculated separately. The average deviation distance of the execution record group drift was 4.18, and the average deviation distance of the execution record group clean was 1.05.

[0171] Calculate the difference in average deviation distance:

[0172]

[0173] The causal association threshold is 1.8. Since the average deviation distance difference of 3.13 is greater than the causal association threshold of 1.8, it is determined that the budget check component exhibits behavioral anomalies triggered by the implicit pattern drift of "credit scoring". Further Welch t-tests were performed on the deviation distance distributions of the execution record group drift and the execution record group clean, yielding a p-value of 0.0003, which is below the significance level of 0.01, confirming the causal association. Cross-layer causal association detection results were generated, recording the upstream drift source component node as "Node 02 - Supplier Qualification Verification" with the drift field name "Credit Scoring", and the downstream affected component node as "Node 03 - Budget Check", with an average deviation distance difference of 3.13.

[0174] Quantify correlations and generate attribution results;

[0175] For the confirmed causal relationship pairs (credit score field → budget check component), extract the drift feature dimension vector and behavior anomaly dimension vector from the 37 execution records of the execution record group drift.

[0176]

[0177] After Z-score standardization of each dimension of the drift feature dimension vector and the behavioral anomaly dimension vector, the Pearson correlation coefficient was calculated. The complete correlation coefficient matrix is ​​shown below:

[0178]

[0179] Sum and sort the absolute values ​​of each row in the correlation coefficient matrix: the sum of the absolute values ​​of the "range offset" row is... Ranked first; the sum of the absolute values ​​in the "Extreme Value Proportion" row is The second most important factor was the "value range offset". The "value range offset" was identified as the key drift factor, and its correlation coefficient with the "execution time offset" was the highest at 0.92. This indicates that the value range center offset caused by the expansion of the credit score value range from [0, 100] to [0, 500] is the main reason for the abnormal execution time of the budget check component.

[0180] Refined cross-layer causal attribution results were generated, and the key drift factor was recorded as “Credit Score - Value Range Offset”, with the corresponding drift feature dimension identified as “Value Range Center Offset + Range Expansion”. The correlation coefficient with “Execution Time Deviation” was 0.92, and the correlation coefficient with “Memory Usage Deviation” was 0.89, ranking first in contribution.

[0181] Hot-insert preprocessing plugins and generate repair solutions;

[0182] Based on the fact that the key drift factor "Credit Score - Range Offset" belongs to the range offset type, the microkernel scheduling engine loads the "Numerical Range Normalization Preprocessing Plugin" from the pluggable business component library and hot-inserts the preprocessing plugin node on the parameter mapping link from "Node 02 - Supplier Qualification Verification" to "Node 03 - Budget Check".

[0183]

[0184] The numerical range normalization preprocessing plugin performs a linear scaling operation on the values ​​of the "Credit Score" field, mapping the original value range [0, 500] back to the target value range [0, 100]. The mapping formula is as follows:

[0185]

[0186] For example, when the original "credit score" is 487, the normalized value is .

[0187] The preprocessing plugin re-validates the normalized data using interface protocol constraints, confirming that the field type remains numeric, the value range is within [0, 100], and the mandatory constraint is met; the re-validation passes. The normalized data is then passed to the budget check component via the input and output parameter interface protocol for further execution. A runtime cross-layer repair scheme is generated, recording the hot-inserted preprocessing plugin node insertion position as "node 02 to node 03 mapping link," the normalization operation type as "value range linear scaling," and the corresponding key drift factor as "credit score - value range offset."

[0188] Monitor the repair results and update the contract annotations;

[0189] After hot-plugging the data preprocessing plugin, set the preset observation period to 48 hours (ensuring a cumulative total of no less than 50 execution records). Continuously collect context-sensitive behavioral feature vectors of the budget check component and calculate the context-level deviation distance in the independent behavioral fingerprint space of the call context group G2.

[0190]

[0191] Of the 52 execution records accumulated during the 48-hour observation period, the average context-level deviation distance was 1.14, and the maximum was 1.28. All of them remained below the context anomaly threshold of 2.5, and the repair was deemed effective.

[0192] Write the drift trend information of the "credit score" field into the runtime supplementary annotation of the supplier qualification verification component interface contract in the pluggable business component library.

[0193]

[0194] Output a dynamic orchestration runtime cross-layer correlation detection report. The report includes the following: details of the implicit drift field: "Credit score field value range expanded from [0, 100] to [0, 500], drift magnitude 206.3"; cross-layer causal attribution path: "Node 02 - Supplier qualification verification (credit score) → Node 03 - Budget check (supplier credit score) → Node 04 - Multi-level approval (approval risk parameter)"; key drift factor: "Value range offset, correlation coefficient with execution time deviation 0.92"; verification of repair effect: "After hot-inserting the linear scaling preprocessing plugin, the context-level deviation distance of the budget check component decreased from 4.23 to 1.14, and the repair took effect."

[0195] Throughout the implementation process, the data flow path from the initial state through each step to the final result is as follows: The supplier management system outputs credit score data with extended value domain → The supplier qualification verification component samples and generates runtime dynamic data pattern descriptions (Table 1) → Implicit drift is detected by comparison with the interface contract (Table 3) → Drift data propagates along the process link to the budget check component → The budget check component triggers behavioral anomalies in the independent behavioral fingerprint space of the call context group (Table 6) → The average deviation distance is compared by grouping the input data according to whether it contains a drift field, and a causal relationship is established (Table 8) → The correlation between drift features and behavioral anomalies is quantified, and key drift factors are identified (Table 10) → The hot-insertion preprocessing plugin performs value domain normalization (Table 11) → The behavioral deviation distance returns to normal after continuous monitoring and repair (Table 12) → Drift trend information is written into the runtime supplementary annotation of the interface contract (Table 13). Data association between each step is achieved through execution transaction identifiers, call context group numbers, and drift field names, ensuring that all data maintains logical consistency and flow continuity in the complete closed-loop process from implicit drift detection at the data schema layer to abnormal behavior location at the component execution layer, and then to cross-layer causal attribution and runtime repair.

[0196] The embodiments of the present invention have been described above. However, the embodiments are not limited to the specific implementation methods described above. The specific implementation methods described above are merely illustrative and not restrictive. Those skilled in the art can make more equivalent embodiments under the guidance of the present embodiments, and all of them are within the protection scope of the present embodiments.

Claims

1. A microkernel-based dynamic orchestration method for business processes, characterized in that, Includes the following steps: When executing each plugin component node in the microkernel scheduling engine's execution flow configuration file, the runtime dynamic data mode description of each plugin component node is extracted, and the behavior feature vector with context is collected. The two are then associated and bound with the execution transaction identifier to generate a two-layer associated execution record. The runtime dynamic data pattern description of each component node is compared with the interface contract declaration field by field. The drift amplitude value of each field is calculated, and fields whose drift amplitude value exceeds the perception threshold but does not violate the interface protocol form type constraint are selected to generate implicit pattern drift detection results. The two-layer associated execution records are grouped according to the context label information. A behavior baseline is independently established for each call context group. The context-level deviation distance and global-level deviation distance of the current execution are calculated. When the context-level deviation distance exceeds the context anomaly threshold but the global-level deviation distance does not exceed the global anomaly threshold, it is determined to be a context-conditional behavior anomaly, and a behavior anomaly detection result for each context is generated. The propagation path of the implicit drift field is traced along the component link defined in the process configuration file. The execution records of downstream component nodes are grouped according to whether the input data contains the implicit drift field. The difference between the average deviation distance of the two groups in the behavior fingerprint space of the corresponding call context group is compared. When the difference exceeds the causal association threshold, a cross-layer causal association detection result is generated. For confirmed causal pairs, the drift feature dimension vector and the behavioral anomaly dimension vector are extracted, the correlation coefficient between each component of the two is calculated, key drift factors are identified, and refined cross-layer causal attribution results are generated.

2. The microkernel-based dynamic orchestration method for business processes according to claim 1, characterized in that, The description of the runtime dynamic data mode for extracting each plugin component node includes: At the output end of each component node, the actual output data is sampled, and the name, actual value type, nesting structure depth and value range distribution statistics of each field in the sampled data are extracted. The dynamic data mode description at runtime is accumulated in a sliding window manner. The sliding window is a fixed-length time window or a sampling number window. Whenever new sampled data arrives, the oldest sampled data is moved out of the window and the new sampled data is included in the window. The value range distribution statistics of each field are recalculated based on all sampled data in the window. The context-sensitive behavior feature vector is composed of the execution time, memory usage, and output data quality indicators of each plug-in component node, combined with context label information. The context label information includes the caller process identifier, the node's position identifier in the process, and the input data feature summary. The input data feature summary is a fixed-length summary string generated by hashing the combination of value types and value range intervals of each field in the input data of each call.

3. The microkernel-based dynamic orchestration method for business processes according to claim 2, characterized in that, The value range distribution statistics include: minimum, maximum, mean, standard deviation and quantile set calculated for numerical fields; length distribution and enumeration value frequency distribution calculated for string fields; and subfield number distribution and nesting depth frequency distribution for nested structure field records. The sampling of the actual output data adopts a hierarchical sampling strategy. First, the output data is divided into layers according to the field type, and then data records are randomly extracted from each layer according to a preset sampling ratio.

4. The microkernel-based dynamic orchestration method for business processes according to claim 1, characterized in that, The calculation of the drift magnitude values ​​for each field includes: For numerical fields, the value range constraints declared in the interface contract are represented as the reference distribution, and the runtime value range distribution statistics are represented as the observed distribution. The first-order Wasserstein distance between the reference distribution and the observed distribution is calculated as the drift magnitude value. The first-order Wasserstein distance is the minimum cost of the shift probability quality required to transform the reference distribution into the observed distribution. The shift cost is measured by the absolute distance between two points on the numerical axis. For string-type fields and nested structure-type fields, after discretizing their respective frequency distributions or structure distributions, the Jensen-Shannon divergence between the reference distribution and the observed distribution is calculated as the drift amplitude value. The Jensen-Shannon divergence is obtained by averaging the two Kullback-Leibler divergences by introducing the mean distributions of the reference distribution and the observed distribution. The Kullback-Leibler divergence is the information gain of one distribution relative to the reference distribution when one distribution is used as a reference. It is calculated by summing the product of the probability of the reference distribution at each discrete value and the logarithm of the ratio of the probabilities of the two distributions. When generating latent pattern drift detection results, the drift field is divided into two levels, mild drift and severe drift, according to the magnitude of the drift amplitude value: when the drift amplitude value exceeds the perception threshold but does not exceed a preset multiple of the perception threshold, it is marked as mild drift; when it exceeds the preset multiple, it is marked as severe drift.

5. The microkernel-based dynamic orchestration method for business processes according to claim 1, characterized in that, The grouping of the two-level associated execution records according to context label information includes: Grouping is done according to the process identifier and input data feature summary in the context label information. Under the same process identifier, the Hamming distance between the input data feature summaries of each execution record is calculated. When the Hamming distance is less than the preset summary similarity threshold, they are grouped into the same call context group. The Hamming distance is the number of characters that differ at corresponding positions between two fixed-length summary strings, and the summary similarity threshold is a pre-set maximum allowed number of different digits. When the number of execution records under a certain process identifier is less than the preset minimum number of samples, the execution records under that process identifier are included in the global unified behavior fingerprint space for anomaly detection. After a sufficient number of execution records are accumulated, a call context group is established independently.

6. The microkernel-based dynamic orchestration method for business processes according to claim 1, characterized in that, The establishment of a behavior baseline independently for each invocation context group includes: After Z-score standardization of all context-bound behavioral feature vectors in each call context group, the mean vector and covariance matrix are calculated to form the normal behavior fingerprint spatial parameters. The context-level deviation distance is calculated using Mahalanobis distance, which is the difference between the standardized behavior feature vector of the current execution and the mean vector of the corresponding calling context group, weighted by the inverse of the covariance matrix, and then the square root of the quadratic form. The global-level deviation distance is calculated in the same way in the global unified behavior fingerprint space obtained by the execution records of all calling context groups. The mean vector and covariance matrix of historical execution records are calculated using an exponentially decaying weighted method, with execution records closer to the current time being assigned higher weights. The weight of each execution record is the product of the negative decay coefficient of the natural constant and the time difference raised to the power of the product. The weighted mean vector is the sum of the corresponding behavioral feature vectors with each weight as a coefficient, divided by the sum of all weights. The weighted covariance matrix is ​​the sum of the outer products of the differences between each behavioral feature vector and the weighted mean vector with each weight as a coefficient, divided by the sum of all weights. The decay coefficient is preset based on the historical call frequency of the call context group and the expected stable period of the component's normal behavior.

7. The microkernel-based dynamic orchestration method for business processes according to claim 1, characterized in that, The propagation path of the implicit drift field in the component link tracing defined in the process configuration file includes: Based on the parameter mapping relationship between each component node in the process configuration file, determine whether the drift field is mapped to the input parameter field of the downstream component node. If so, include the corresponding downstream component node in the drift propagation path. The execution records of the two-layer association of downstream component nodes are grouped according to whether the input data contains a hidden drift field, and the execution record group containing the drift field and the execution record group not containing the drift field are obtained. The average Mahalanobis distance of the two groups is calculated in the independent behavior fingerprint space of the corresponding call context group as the average deviation distance. The difference between the average deviation distances of the two groups is compared with the causal association threshold. When tracing the propagation path of drifting fields, record the field mapping transformation information of each level of propagation. The field mapping transformation information includes field name changes, data type conversions, and aggregation operations. Based on the field mapping transformation information, adjust the causal association threshold of each level of downstream component nodes step by step: when passing through a level of field mapping containing aggregation operations or type conversions, multiply the causal association threshold corresponding to the level of field mapping containing aggregation operations or type conversions by a preset adjustment coefficient less than 1 based on the threshold of the previous level. After the difference in average deviation distance exceeds the causal association threshold, a two-sample statistical test is performed on the deviation distance distribution of the two groups. The p-value obtained from the test is compared with the preset significance level. When the p-value is lower than the significance level, the causal association is confirmed.

8. The microkernel-based dynamic orchestration method for business processes according to claim 1, characterized in that, The calculation of the correlation coefficient between the components of the two includes: For confirmed causal pairs, the drift feature dimension values ​​of the drift field are extracted from the execution record group containing the drift field to form a drift feature dimension vector. The drift feature dimension values ​​include the value range offset, the distribution skew change, and the extreme value ratio change. At the same time, the behavior anomaly dimension values ​​of the downstream components are extracted to form a behavior anomaly dimension vector. The behavior anomaly dimension values ​​include the execution time deviation, the memory usage deviation, and the output data quality deviation. After Z-score standardization is applied to each dimension of the drift feature dimension vector and the behavior anomaly dimension vector, the correlation coefficient between each component of the drift feature dimension vector and each component of the behavior anomaly dimension vector is calculated using the Pearson correlation coefficient. The Pearson correlation coefficient is the product of the covariance of the two components across all execution records and the standard deviation of each component. The absolute values ​​of the corresponding rows of each drift feature dimension in the correlation coefficient matrix are summed and sorted, and the drift feature dimension with the highest ranking is selected as the key drift factor.

9. The microkernel-based dynamic orchestration method for business processes according to claim 1, characterized in that, After generating refined cross-level causal attribution results, the following is also included: Based on the characteristics of key drift factors, and through the dynamic loading capability of the microkernel scheduling engine, data preprocessing plugin nodes are hot-inserted into the parameter mapping link where the implicit drift field flows into the downstream component. Hot insertion means that the data preprocessing plugin, which is pre-registered in the pluggable business component library, is instantiated and inserted into the specified parameter mapping link without interrupting the execution of the current process. For cases where the key drift factor is of the range offset type, the data preprocessing plugin node performs range pruning or linear scaling on the drift field value; for cases where the key drift factor is of the distribution skew type, the data preprocessing plugin node performs quantile normalization on the drift field value; for cases where the key drift factor is of the nested structure variation type, the data preprocessing plugin node performs structure mapping or default value filling on the nested structure of the drift field. After performing data normalization, the normalized data is re-validated for interface protocol constraints. If the re-validation fails, the preprocessing operation is rolled back and an alarm message is generated. Within a preset observation period after the data preprocessing plugin node is hot-inserted, the context-aware behavior feature vectors of downstream component nodes are continuously collected and the context-level deviation distance is calculated. It is then determined whether the context-level deviation distance has fallen below the context anomaly threshold to determine whether the repair has taken effect. The drift trend information of the implicit drift field and the associated behavior anomaly record are written into the runtime supplementary annotation of the corresponding component interface contract. When the drift amplitude value of the same field shows an increasing trend in multiple consecutive preset observation periods, an interface contract revision suggestion is generated. The output is a dynamically orchestrated runtime cross-layer association detection report containing details of implicit drift fields, cross-layer causal attribution paths, key drift factors, and verification of repair effects.

10. A microkernel-based dynamic business process orchestration system, used to execute the microkernel-based dynamic business process orchestration method according to any one of claims 1 to 9, characterized in that, include: The dual-layer associated execution record generation module is used to extract the runtime dynamic data pattern description of each plugin component node in the microkernel scheduling engine execution process configuration file, collect the behavior feature vector with context, and associate and bind the two with the execution transaction identifier to generate a dual-layer associated execution record. The implicit pattern drift detection module is used to compare the runtime dynamic data pattern description of each component node with the interface contract declaration field by field, calculate the drift magnitude value of each field, filter out fields whose drift magnitude value exceeds the perception threshold but does not violate the interface protocol form type constraint, and generate implicit pattern drift detection results. The context-based behavior anomaly detection module is used to group the two-layer associated execution records according to context label information, establish a behavior baseline independently for each call context group, calculate the context-level deviation distance and global-level deviation distance of the current execution, and generate context-based behavior anomaly detection results when the context-level deviation distance exceeds the context anomaly threshold but the global-level deviation distance does not exceed the global anomaly threshold. The cross-layer causal association detection module is used to trace the propagation path of implicit drift fields along the component links defined in the process configuration file. It groups the execution records of downstream component nodes according to whether the input data contains implicit drift fields, compares the difference of the average deviation distance between the two groups in the behavior fingerprint space of the corresponding call context group, and generates cross-layer causal association detection results when the difference exceeds the causal association threshold. The refined cross-layer causal attribution module is used to extract the drift feature dimension vector and the behavioral anomaly dimension vector from the confirmed causal relationship pairs, calculate the correlation coefficient between each component of the two, identify key drift factors, and generate refined cross-layer causal attribution results.

Images