A large file cross-unit transmission method based on a business collaboration scenario

Abstract

The application discloses a large file cross-unit transmission method based on a business cooperation scene, relates to the technical field of cross-organization data transmission and resource scheduling, and takes a business context as a core to map an event type, an emergency level and an SLA deadline time into a calculable priority, and is linked with real-time network measurement results, so that scheduling no longer stays in static file attributes, but can instantly improve the service share of a key request according to events such as out-of-stock early warning and promotion start, thereby reducing the probability that a high-emergency task is blocked by regular transmission. By introducing unit-level quotas, admission and interruptible preemption on the side of a bottleneck link, long-term occupation caused by first-come-first-served is avoided, basic fairness between different units is ensured, and bandwidth can be quickly transferred to more urgent flows at a business peak moment. Weighted round-robin weights are dynamically updated according to the emergency degree, the SLA urgency degree and the quota surplus degree, hysteresis and minimum interval control are superimposed, and the agility of scheduling is improved.

Description

Technical Field

[0001] This invention relates to the field of cross-organizational data transmission and resource scheduling technology, and in particular to a method for transmitting large files across units in a business collaboration scenario. Background Technology

[0002] In multi-level supply chain collaboration, suppliers, manufacturers, and distributors need to exchange data such as inventory, orders, and forecasts across organizations. In actual business, in addition to event messages, there are also large files (usually hundreds of MB to tens of GB) such as master data, batch reconciliation, and forecast packages. When multiple units initiate transmission independently and the link bandwidth is limited, concurrent requests are prone to resource contention, resulting in delays in the arrival of key data and affecting inventory visibility and collaboration efficiency.

[0003] In existing technologies, to reduce congestion and conflicts, some solutions employ strategies such as metadata-based scheduling, distributed transmission architecture, priority queues, and bandwidth allocation; there are also some workflow and data management system integration solutions in the field of scientific computing that optimize order and concurrency by matching file attributes and paths; the above methods can alleviate link congestion to a certain extent in general file distribution scenarios.

[0004] However, in inventory coordination driven by business events, the above scheduling lacks dynamic awareness of business context and is difficult to adjust priorities in a timely manner based on real-time events such as stockout warnings, emergency replenishment, or promotional activities. At the same time, the existing metadata model is insufficient in expressing cross-organizational coordination rules (such as quotas, SLAs, and arbitration strategies), resulting in limited conflict resolution capabilities between concurrent requests from multiple units, which in turn prolongs the delivery time of critical data. Summary of the Invention

[0005] In view of the aforementioned existing problems, the present invention is proposed.

[0006] This invention provides a method for large file cross-unit transmission in business collaboration scenarios to solve the problems of congestion and conflict caused by concurrent large file transmission in multiple units, and the lack of business awareness and cross-organizational coordination.

[0007] To solve the above-mentioned technical problems, the present invention provides the following technical solution:

[0008] This invention provides a method for large file cross-unit transmission in a business collaboration scenario, comprising:

[0009] Step S1: Receive transmission requests from multiple units, each request carrying business metadata. The business metadata includes at least the event type label, urgency level, SLA time limit, file size and type, source / destination identifier, and request time.

[0010] Step S2: Generate a business context model based on the business metadata and the business rules of the external business system, including ERP and / or SCM.

[0011] Step S3: Calculate the priority score of each transmission request based on the business context model and generate a priority queue;

[0012] Step S4: Collect real-time network status information, including at least one of the following: round-trip time, packet loss rate, available bandwidth, and queue length.

[0013] Step S5: A dynamic scheduling algorithm is used to schedule the large file transfer across units. The dynamic scheduling algorithm adjusts the transmission parameters online based on the priority queue and the real-time network status. The scheduling controls at least one of the following transmission parameters: number of concurrent threads, fragment size, sending rate limit, path / link selection, preemption and admission control.

[0014] Step S6: Perform large file transfer according to the scheduling result, and support breakpoint resumption and failure retry during the transfer process;

[0015] Step S7: Monitor changes in service context and network status. When the preset reordering trigger conditions are met, dynamically reorder incomplete transmission requests.

[0016] As a preferred embodiment of the large file cross-unit transmission method based on business collaboration scenarios described in this invention, the business context model includes: mapping of event type and urgency level to SLA weight, collaboration constraints at the SKU / store / channel level, and unit-level quota and fairness constraints.

[0017] As a preferred embodiment of the method for large file cross-unit transmission in a business collaboration scenario described in this invention, the priority scoring is determined from at least three of the following items based on a configurable weighting function: urgency level, remaining time until SLA deadline, request waiting time, file size, number of historical failures, and source / target unit quota occupancy rate, and a hysteresis threshold is set.

[0018] As a preferred embodiment of the large file cross-unit transmission method based on business collaboration scenario described in this invention, the real-time network status information is obtained by a combination of active detection and passive collection. Active detection sends detection messages at fixed or adaptive intervals, while passive collection is based on the ACK interval, retransmission count, and queue occupancy statistics of the transmission end.

[0019] As a preferred embodiment of the large file cross-unit transmission method based on business collaboration scenario described in this invention, the cross-unit large file transmission scheduling includes a conflict resolution mechanism, which includes: unit-level quota constraints, admission control and preemption strategy. When multiple high-priority requests compete for the same bottleneck link, admission is first performed according to quota, then the service order is executed according to weight, and interruptible preemption is performed on the low-weight ongoing transmission.

[0020] As a preferred embodiment of the large file cross-unit transmission method based on business collaboration scenario described in this invention, the service order adopts a weighted round-robin strategy, the weight of which is determined by the urgency level, SLA weight and unit-level quota occupancy rate, and is dynamically adjusted according to changes in network status during the round-robin period.

[0021] As a preferred embodiment of the large file cross-unit transmission method based on business collaboration scenario described in this invention, the scheduling maps different sets of transmission parameters to different priorities: high priority is mapped to higher number of concurrent threads, smaller fragment size and more stringent rate limit relaxation, and low priority is mapped to rate limiting and delayed start.

[0022] As a preferred embodiment of the large file cross-unit transmission method based on business collaboration scenario described in this invention, the triggering conditions for dynamic reordering include at least one of the following: predicting that a request has an SLA default risk under the current configuration, detecting an increase in the event urgency level, a decrease in available bandwidth of the bottleneck link exceeding a threshold, or quota release of the target unit.

[0023] As a preferred embodiment of the large file cross-unit transmission method based on business collaboration scenario described in this invention, the dynamic scheduling algorithm includes a reinforcement learning model. The state of the reinforcement learning model includes priority distribution and network state. The actions include joint adjustment of the number of concurrent threads / rate / queue order. The reward is based on a combination of business latency cost and resource utilization. The algorithm uses an offline pre-training and online fine-tuning update strategy.

[0024] As a preferred embodiment of the method for large file cross-unit transmission in a business collaboration scenario described in this invention, the method generates an audit log, which records the triggering reason for each reordering, the transmission identifier of being preempted and newly started, the adjusted parameters and the completion time, for the cross-unit collaboration protocol to perform post-event verification and traceability.

[0025] The beneficial effects of this invention are as follows: This invention uses business context as its core, mapping event type, urgency level, and SLA deadline to calculable priorities, and linking this with real-time network measurement results. This allows scheduling to move beyond static file attributes and instantly increase the service share of critical requests based on events such as stockout warnings and promotional launches, thereby reducing the probability of high-urgency tasks being blocked by regular transmissions. By introducing unit-level quotas, admission criteria, and interruptible preemption on the bottleneck link side, it avoids long-term occupation caused by first-come, first-served, and ensures basic fairness between different units, while quickly allocating bandwidth to more urgent flows during peak business hours. The weighted polling weights are dynamically updated based on urgency, SLA urgency, and quota surplus, combined with hysteresis and minimum interval control, improving scheduling agility and suppressing jitter caused by frequent reordering. The optional reinforcement learning model internalizes the trade-off between latency cost and resource utilization into policy learning, adapting to different network and business loads. Simultaneously, audit logs record the reasons and effects of each reordering and preemption, providing cross-unit traceability and collaborative governance capabilities.

[0026] In summary, this invention tightly couples business-driven processes with network control, enabling faster arrival of critical data, more stable timeliness, and fairer cross-organizational resource sharing. Attached Figure Description

[0027] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments will be briefly described below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation on the scope of this application.

[0028] Figure 1 This is a flowchart illustrating the method for transmitting large files across units in a business collaboration scenario, as shown in the embodiment. Detailed Implementation

[0029] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0030] All terms used in this application (including technical and scientific terms) have the meanings commonly understood by those skilled in the art, unless otherwise defined. It should be noted that the terms used herein should be interpreted in a manner consistent with the context of this specification, and not in an idealized or overly rigid way.

[0031] For example, the terms “first” and “second” used in this application are only used to distinguish and describe similar objects, to differentiate the first object from another object, and are not used to describe a specific order or sequence, nor should they be interpreted as indicating or implying relative importance.

[0032] This application proposes a method for large file cross-unit transmission in a business collaboration scenario, combining... Figure 1 As shown, the method includes:

[0033] Step S1: Receive transmission requests from multiple units. The requests carry business metadata, which includes at least the event type label, urgency level, SLA time limit, file size and type, source / destination identifier, and request time.

[0034] In this embodiment, the transmission request is a single or batch submission form for large files, which includes at least file location information, size and type, source and target identifiers, and request time. The source and target identifiers can be a combination of organization code and node address. Event type tags and urgency levels are derived from existing business systems or standard dictionaries of the scheduling end. The default request time is taken from the system clock and kept on the order of hundreds of milliseconds consistent with the existing time synchronization mechanism. It is recommended that the urgency level adopt a discrete hierarchical approach and be aligned with the business rule base. To ensure consistency, business metadata undergoes integrity and dictionary validity checks before entering the scheduling process. If any key field is missing or invalid, it enters the supplementation area with the lowest priority, waiting for upstream supplementation or backfilling mapping by the interface adaptation layer. In abnormal situations (such as a large difference between the timestamp and the system time or the organization code not being registered), the default configuration of the most recently verified organization is used, and a downgraded reception flag is recorded in the audit log.

[0035] Step S2: Generate a business context model based on business metadata and the business rules of external business systems, including ERP and / or SCM.

[0036] Specifically, the business context model is based on event type, urgency level, and SLA deadline, merging constraints such as category, channel, and unit quota from source systems, and forming a queryable key-value structure at the scheduling end. Business rules are primarily retrieved via event callbacks; for systems where callbacks are not possible, interval polling and version number comparison are used, with hot updates implemented upon changes. The default rule refresh interval is in the minute range, with a recommended range of 5 to 15 minutes, set according to the frequency of business changes and interface rate limiting strategies. When an external system is temporarily unreachable, the most recently successfully retrieved rule snapshot is used with an expiration time marker; if the snapshot expires and the system remains unreachable, a built-in minimum fallback rule is used, retaining only the mapping related to urgency level and SLA deadline, until the external system recovers.

[0037] Step S3: Calculate the priority score of each transmission request based on the business context model and generate a priority queue;

[0038] Step S4: Collect real-time network status information, including at least one of the following: round-trip time, packet loss rate, available bandwidth, and queue length.

[0039] Step S5: Use a dynamic scheduling algorithm to schedule cross-unit large file transfers. The dynamic scheduling algorithm adjusts the transmission parameters online based on the priority queue and real-time network status. The scheduling controls at least one of the following transmission parameters: number of concurrent threads, fragment size, sending rate limit, path / link selection, preemption and admission control.

[0040] Step S6: Perform large file transfer according to the scheduling result, and support breakpoint resumption and failure retry during the transfer process;

[0041] Step S7: Monitor changes in service context and network status, and dynamically rearrange incomplete transmission requests when the preset rearrangement trigger conditions are met.

[0042] In one embodiment, the business context model includes: a mapping of event type and urgency level to SLA weights, collaborative constraints at the SKU / store / channel level, and unit-level quota and fairness constraints;

[0043] In one embodiment, the priority score is determined based on a configurable weighting function from at least three of the following: urgency level, remaining time until the SLA deadline, request wait time, file size, historical failure count, and source / target unit quota utilization, with a hysteresis threshold set to suppress frequent reordering.

[0044] The priority scoring and hysteresis threshold are set as follows:

[0045] Step S31: Before scoring, perform saturation normalization on the input features to unify the dimensions and maintain a monotonic relationship.

[0046] , , ,

[0047] , , ,

[0048] in, Six normalized features, The emergency level (discrete positive integer). This is the maximum emergency level (default 5). This represents the remaining time (in seconds) until the SLA deadline. SLA normalized reference duration (default 4 hours). The request wait time (in seconds). Waiting time for normalization reference (default 2 hours). File size (in bytes). Size reference value (default) byte), This represents the number of historical failures (times). This is a reference value for the number of failures (default 3). Unit-level quota occupancy rate (proportion);

[0049] The saturation function is defined as:

[0050] ,

[0051] in, Input the real number to be clipped;

[0052] Step S32: Construct a configurable weighted sum model based on normalized features to obtain comparable priority scores:

[0053] ,

[0054] in, Priority scoring (dimensionless, interval) ), For the non-negative weights of the corresponding features, satisfying ,in, Default is 0.30. The default value is 0.25. The default value is 0.20. The default value is 0.10. The default value is 0.10. The default value is 0.05; the above weights can be calibrated according to business objectives during offline playback.

[0055] Step S33: To suppress queue jitter, process the requests at the head of the queue. With candidate requests The score difference is set with two thresholds: magnitude and time.

[0056] ,

[0057] in, For the request The current rating, For the request The current rating, The hysteresis amplitude threshold (default 0.05). This is the current decision timestamp (in seconds). The timestamp (in seconds) of the most recent complete rearrangement. The minimum time interval between two rearrangements (default 60 seconds, configurable from 30 to 300 seconds); the existing order is maintained if only one of the conditions is met.

[0058] Reference volume Configured according to environmental level; missing features are entered as zero values ​​into the corresponding categories. To reduce occasional fluctuations, one can... Perform sliding window midpoint processing, but do not change the trigger threshold and order determination of step S33;

[0059] Specifically, the normalization stage employs saturation pruning paired with reference values ​​to ensure variables of different dimensions are within the same scoring domain and maintain consistent monotonicity with respect to business direction. The scoring stage uses a non-negative weight structure that sums to one, facilitating interpretable decomposition of sources and enabling target-driven calibration and migration on historical data. The hysteresis design uses a combination of amplitude thresholds and minimum intervals to suppress frequent rearrangements caused by minor noise, while allowing for rapid switching when the scoring advantage is significant and exceeds the interval, balancing stability and timeliness. Boundary handling remains lightweight: missing features are entered as zero, without introducing additional dominance, and the use of window values ​​is limited to the observation layer without altering the triggering rules themselves.

[0060] Furthermore, the urgency level should be provided by the business side and limited to a few tiers. The SLA normalized reference duration, wait normalized reference duration, and size reference quantity can be set based on the median or higher percentile of recent log statistics to adapt to scale differences during different load periods. The reference quantity for historical failure counts depends on link stability and retry strategies, typically ranging from a few to several times. Quota occupancy rate is directly derived from the quota ledger at the unit dimension. The sliding median window used for scoring should cover observations ranging from tens of seconds to several minutes, with a sample size of 3 to 5. A window that is too short will cause jitter, while a window that is too long will reduce response time. The latency amplitude threshold and minimum time interval should be set to avoid frequent reordering and can be calibrated offline before deployment. If any feature is missing, it should still be entered into the scoring domain as zero, and a feature missing label should be attached to the audit log for backtracking.

[0061] In one embodiment, real-time network status information is obtained through a combination of active probing and passive acquisition. Active probing sends probe packets at fixed or adaptive intervals, while passive acquisition is based on ACK intervals, retransmission counts, and queue occupancy statistics from the transmission end.

[0062] For example, active probing uses lightweight probe messages to measure round-trip latency and available bandwidth indication at second-level intervals. Passive acquisition at the sending end statistically analyzes confirmation message intervals, retransmission counts, and sending queue depth by connection dimension, and uses a monotonic clock to mark these intervals. The default sampling period is 1 to 5 seconds, which can be adaptively shortened during congestion phases. Smoothing uses exponential or median methods, with a smoothing window covering approximately ten to tens of seconds. When probes are lost or statistical anomalies occur, the most recent valid measurement is used, and a forced refresh is performed in the next cycle. If no measurement is available for several consecutive cycles, a conservative estimate is adopted, and the aggressiveness of scheduling is reduced, while network measurement degradation events are recorded.

[0063] In one embodiment, cross-unit large file transfer scheduling includes a conflict resolution mechanism, which includes: unit-level quota constraints, admission control and preemption strategy. When multiple high-priority requests compete for the same bottleneck link, admission is first granted according to quota, then the service order is executed according to weight, and interruptible preemption is performed on low-weight ongoing transmissions.

[0064] Similarly, preemption is executed at fragment boundaries or safe pause points, prioritizing low-weight transmissions with enabled resumeable functionality. Admission control determines the number of requests entering the service queue based on unit quota and weight; requests not admitted enter a waiting area and are periodically re-evaluated. Preemption decisions follow minimum intervals to avoid jitter, and after service order changes, the preempted party is returned with the reason, remaining capacity, and recovery suggestions. If a bottleneck link's identity is uncertain or there is a temporary inconsistency in the quota ledger, the initiation of new disputed requests is frozen, pending transmissions are held until the ledger is consistent, and then regular arbitration is resumed.

[0065] In one embodiment, the service order adopts a weighted round-robin strategy, with the weights determined by the urgency level, SLA weight, and unit-level quota utilization rate, and dynamically adjusted according to changes in network status during the round-robin period;

[0066] The weights for weighted round-robin polling are determined and adjusted as follows:

[0067] Step S51, obtain , , Network measurement acquisition (Available bandwidth estimate) and (RTT estimation);

[0068] Step S52, define the calculation function for the weighted round-robin weights:

[0069] ,

[0070] in, For the request The scheduling weight (measured in units of quota share) in the current polling cycle. For range clipping, These are the lower and upper limits of the weight (default). , ), Weighted benchmark scale (default) ), The coefficients are three factors and (default ), Curvature index (default) ), , , respectively requests Emergency level, SLA urgency and affiliated unit Normalized characteristics of quota surplus (values ​​are all in) );

[0071] Step S53, the cycle length, online update rules (bandwidth / RTT adaptive), and preemption threshold are set as follows:

[0072] ,

[0073] ,

[0074] like This will trigger a preemption.

[0075] in, The period length for weighted polling (unit: number of time slots). Upper and lower bounds (default) ), To round up, The periodic benchmark coefficient (default) ), For the current RTT estimate, For reference RTT (default) ), For the current available bandwidth estimate, Reference bandwidth (default) ), For a moment The weight, For the moment after online update, The instantaneous weights are recalculated using the latest features according to step S52. Online smoothing coefficient (default) ), The current bottleneck link is currently serving requests. The weight, To seize the weight difference threshold (default) ), For the last rearrangement / preemption timestamp, Reuse the aforementioned minimum interval (default) );

[0076] Step S54, in conjunction with quotas / access, defines the minimum service share and debt compensation:

[0077] ,

[0078] ,

[0079] in, as a unit The amount of outstanding debt, Forgetting factor (default) ), as a unit Minimum service share (default) ), as a unit The actual share in the most recent period, , To compensate for the intensity (default) ), The effective weight after compensation is replaced by... Participate in polling, For the request Index of the unit to which it belongs; if the quota is determined to be exceeded during the admission phase, the corresponding request will not be included in the weight calculation for this round;

[0080] Detachable link configuration, It can be estimated using the exponentially smoothed mean, when When the upper limit is reached, it enters the peak shaving queue and is compensated in the next cycle.

[0081] Specifically, the weights are based on normalized urgency, SLA urgency, and quota surplus, using a linear combination with an exponential form and setting upper and lower limits and scales to retain sorting sensitivity while suppressing extreme skewness. The cycle length scales inversely with RTT and available bandwidth and is updated online with a smoothing coefficient to prevent short-term fluctuations from excessively affecting service order. The preemption rule uses weight difference and minimum interval as trigger thresholds, maintaining the same judgment logic as the aforementioned hysteresis mechanism. The connection with quota / admission is achieved through minimum service share and accumulated debt. When the historical share is insufficient, subsequent weights are gradually increased through multiplicative compensation, forming a balanced closed loop of first owing and then making up.

[0082] Optionally, weighted round-robin mapping maps weights to discrete service shares and expands them into a round-robin table, with the expansion frequency consistent with the period length. When an online update arrives, requests for the current service are not immediately interrupted; instead, the update is applied at the next switchable point to reduce short-term fluctuations. When the weights reach their upper or lower limits and are pruned, they enter either a peak-shaving or fallback path: peak-shaving requests remain in the service table but actual concurrency is reduced, while fallback requests retain at least a single quota to avoid starvation; the amount of debt per unit decays in each period to avoid long-term rigid compensation. If the accumulated debt abnormally expands, an audit is triggered, and the number of new startups is temporarily limited until the ledger is restored.

[0083] In one embodiment, the scheduler maps different sets of transmission parameters to different priorities: high priority is mapped to higher concurrent thread count, smaller fragment size and more stringent rate cap relaxation, while low priority is mapped to rate limiting and delayed startup;

[0084] In this embodiment, parameter mapping uses discrete tiers for rapid switching. High priority defaults to medium-high concurrent threads, low fragment size, and a relaxed rate cap; medium priority uses medium concurrency and medium fragmentation; low priority uses low concurrency and a low rate cap, allowing for delayed startup. Tier boundaries are set based on equipment capabilities and empirical link bandwidth values, and differentiated tables can be maintained for different bottleneck links. When resources are insufficient, high-priority requests currently in progress are prioritized, and newly arriving low-priority requests are postponed to the next round of evaluation; if tier switching occurs too frequently, parameter changes are temporarily frozen until the next minimum interval.

[0085] In one embodiment, the triggering conditions for dynamic reordering include at least one of the following: predicting that a request has an SLA default risk under the current configuration, detecting an increase in the urgency level of an event, a decrease in available bandwidth of a bottleneck link exceeding a threshold, or the release of quota for the target unit.

[0086] Specifically, default risk prediction is based on a comparison between the estimated completion time and the deadline. The estimated completion time is inferred from the remaining data volume, the measured available bandwidth indication, and the current queue waiting time. When the estimated result exceeds the deadline with a significant advantage, and the minimum interval is met, a reordering is triggered. The threshold for reducing available bandwidth is set as a percentage decrease based on the average of the recent stable period, maintaining robustness to short-term spikes. When a target unit releases its quota, the corresponding unit's pending requests can be prioritized and participate in the next round of scheduling. When unavailability or unreliability is predicted, the reordering decision degenerates into a rule set based solely on the urgency level and SLA urgency.

[0087] In one embodiment, the dynamic scheduling algorithm includes a reinforcement learning model, the state of which includes priority distribution and network state, the action includes joint adjustment of concurrent thread number / rate / queue order, the reward is based on a combination of business latency cost and resource utilization, and an offline pre-training and online fine-tuning update strategy is used.

[0088] Furthermore, offline pre-training generates state-action-effect samples by replaying historical scheduling logs. The effect is approximated by a weighted index consisting of task completion time, SLA default, and resource consumption. Online fine-tuning is performed within guaranteed boundaries, with actions being minor adjustments to concurrency, rate, or queue order. All actions are constrained by the hard constraints and safety thresholds of the rule set, and the reward is monitored in each evaluation window. If the reward significantly deteriorates or violates hard constraints in multiple consecutive evaluation windows, the system immediately reverts to the rule set-driven baseline strategy, and the reason for the model revert and the trigger time are recorded. When the model update fails or becomes unavailable, scheduling is entirely dominated by the rule set.

[0089] In one embodiment, the method generates an audit log that records the triggering reason for each reordering, the transmission identifier of the preempted and newly started transmission, the adjusted parameters and the completion time, for cross-unit collaboration protocols to perform post-event verification and traceability.

[0090] Optionally, the audit log uses an append-only, immutable structure to record critical events. The time field is generated using a monotonically increasing clock and synchronized with the system clock. The log must at least store the event type, associated request and unit identifier, original priority and adjusted parameters, trigger criterion summary, and processing result. The default retention period is monthly, and important events can be retained for longer periods. When log writing fails or storage is insufficient, compression and tiered retention strategies are enabled, prioritizing the retention of rearranged and preemptive events, while the system health record indicates audit degradation for maintenance purposes.

[0091] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features therein. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.

[0092] Furthermore, those skilled in the art will understand that although some embodiments herein include certain features included in other embodiments but not others, combinations of features from different embodiments are meant to be within the scope of this application and form different embodiments. For example, all the embodiments above can be used in any combination. The information disclosed in this background section is intended only to enhance the understanding of the general background of this application and should not be construed as an admission or in any way implying that such information constitutes prior art known to those skilled in the art.

Claims

1. A method for transmitting large files across units in a business collaboration scenario, characterized in that, include: Step S1: Receive transmission requests from multiple units. The transmission requests carry service metadata, which includes at least event type label, urgency level, SLA time limit, file size and type, source / target identifier, and request time. Step S2: Generate a business context model based on the business metadata and the business rules of the external business system, including ERP and / or SCM. The business context model includes: mapping of event type and urgency level to SLA weight, collaborative constraints at the SKU / store / channel level, and unit-level quota and fairness constraints; Step S3: Calculate the priority score of each transmission request based on the business context model and generate a priority queue; Step S4: Collect real-time network status information, including at least one of the following: round-trip time, packet loss rate, available bandwidth, and queue length; Step S5: A dynamic scheduling algorithm is used to schedule the large file transfer across units. The dynamic scheduling algorithm adjusts the transmission parameters online based on the priority queue and the real-time network status. The scheduling controls at least one of the following transmission parameters: number of concurrent threads, fragment size, sending rate limit, path / link selection, preemption and admission control. Step S6: Perform large file transfer according to the scheduling result, and support breakpoint resumption and failure retry during the transfer process; Step S7: Monitor changes in service context and network status, and dynamically rearrange incomplete transmission requests when the preset rearrangement trigger conditions are met. The priority score is determined based on a configurable weighting function from at least three of the following: urgency level, remaining time until the SLA deadline, request wait time, file size, number of historical failures, and source / target unit quota utilization, with a hysteresis threshold set. The real-time network status information is obtained through a combination of active detection and passive acquisition. Active detection sends probe messages at fixed or adaptive intervals, while passive acquisition is based on the ACK interval, retransmission count, and queue occupancy statistics from the transmission end.

2. The method for large file cross-unit transmission in a business collaboration scenario as described in claim 1, characterized in that, The cross-unit large file transfer scheduling includes a conflict resolution mechanism, which includes: unit-level quota constraints, admission control and preemption strategy. When multiple high-priority transfer requests compete for the same bottleneck link, admission is first granted according to the quota, then the service order is executed according to the weight, and interruptible preemption is performed on the low-weight transfers that are in progress.

3. The method for large file cross-unit transmission in a business collaboration scenario as described in claim 2, characterized in that, The service order adopts a weighted round-robin strategy, with the weights determined by the urgency level, SLA weight, and unit-level quota utilization rate, and dynamically adjusted according to changes in network status during the round-robin period.

4. The method for large file cross-unit transmission in a business collaboration scenario as described in claim 1, characterized in that, The scheduling maps different sets of transmission parameters to different priorities: high priority is mapped to a higher number of concurrent threads, a smaller fragment size, and a looser rate cap, while low priority is mapped to rate limiting and delayed startup.

5. The method for large file cross-unit transmission in a business collaboration scenario as described in claim 1, characterized in that, The triggering conditions for the dynamic reordering include at least one of the following: predicting that a transmission request has an SLA default risk under the current configuration, detecting an increase in the urgency level of an event, a decrease in available bandwidth of a bottleneck link exceeding a threshold, or the release of quota for the target unit.

6. The method for large file cross-unit transmission in a business collaboration scenario as described in claim 1, characterized in that, The dynamic scheduling algorithm includes a reinforcement learning model. The state of the reinforcement learning model includes priority distribution and network state. The actions include joint adjustments of the number of concurrent threads / rate / queue order. The reward is based on a combination of business latency cost and resource utilization. It uses an offline pre-training and online fine-tuning update strategy.

7. The method for large file cross-unit transmission in a business collaboration scenario as described in claim 1, characterized in that, This method generates audit logs that record the triggering reason for each reordering, the transmission identifiers of preemption and new initiation, the adjusted parameters, and the completion time, for cross-unit collaboration protocols to perform post-event verification and traceability.

Images