A multi-platform data distribution method and system based on dynamic mapping
By establishing a unified skeleton structure and differential patch management, the problems of repetitive development and redundancy in multi-platform data distribution are solved, achieving efficient and stable cross-platform data distribution and ensuring data consistency and traceability.
Patent Information
- Application Number
- CN202511504134.1
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2025-10-21
- Publication Date
- 2026-02-13
- Estimated Expiration
- 2045-10-21
AI Technical Summary
Existing data distribution technologies, when facing multi-platform requirements, require the development of separate interfaces for each platform, leading to redundant development and complex maintenance. They cannot flexibly adapt to the differences in fields and structures across different platforms, lack a unified skeleton structure for carrying out differential patch management, resulting in low version update efficiency. Furthermore, the lack of standardization for differential patches and dependency graph construction makes it impossible to effectively select the minimum subset of patches that meet platform requirements, increasing distribution redundancy. The failure to combine quota constraints for batch partitioning easily leads to duplicate distribution and conflicts. The receipt information fails to form a closed loop with the batch strategy, making it difficult to achieve dynamic optimization and self-correction.
By establishing a unified skeleton structure, the source manuscripts are embedded into a unified carrying framework, differential patches are generated and processed in a standardized and sequential manner, a dependency graph is constructed, the smallest subset of patches that meet the data requirements of the target platform is selected, and these patches are divided into several batches with idempotent order numbers and version numbers for distribution. Receipt information is collected to update the batch strategy parameters.
It achieves high efficiency, stability and scalability in cross-platform data distribution, avoids scattered field mapping, accurately captures modification points, reduces redundancy, ensures data consistency and traceability, and optimizes the version update and distribution process.
Smart Images

Figure CN121000781B_ABST
Abstract
Description
TECHNICAL FIELD
[0001] The present application relates to the technical field of computer data distribution, and in particular to a multi-platform data distribution method and system based on dynamic mapping. BACKGROUND
[0002] The existing data distribution technology needs to develop interfaces for each platform separately when facing multi-platform requirements, resulting in repeated development, complex maintenance, and the inability to flexibly adapt to the field and structural differences of different platforms. The source manuscript is constantly modified during production, and the existing technology lacks a unified skeleton structure to carry and differential patch management, resulting in low version update efficiency.
[0003] At the same time, the lack of standardization and dependency graph construction of differential patches cannot effectively select the smallest patch subset that meets the platform requirements, increasing distribution redundancy. In the batch distribution link, the existing scheme does not combine quota constraints for batch division, and lacks idempotent serial number and version number mechanism, which can easily cause repeated distribution and conflicts. The feedback information cannot form a closed loop with the batch strategy, making it difficult to achieve dynamic optimization and self-correction. SUMMARY
[0004] In view of the above existing problems, the present application is proposed.
[0005] Therefore, the present application provides a multi-platform data distribution method based on dynamic mapping to solve the problems of inconsistent structure, processing redundancy and lack of closed-loop optimization in existing multi-platform data distribution technology in unified carrying, differential updating and batch feedback.
[0006] To solve the above technical problems, the present application provides the following technical solutions:
[0007] In a first aspect, the present application provides a multi-platform data distribution method based on dynamic mapping, which includes: obtaining a source manuscript, establishing a unified skeleton structure, and embedding the source manuscript into the unified skeleton structure;
[0008] Generating a differential patch when a manuscript operation node is triggered, and promoting the differential patch to the unified skeleton to form a differential patch set;
[0009] Standardizing and sequencing the differential patch set to generate a standard differential set, and constructing a dependency graph for a target platform based on the standard differential set;
[0010] Selecting the smallest patch subset that meets the data requirements of the target platform on the dependency graph, and applying the smallest patch subset to the unified skeleton structure to obtain a manuscript instance updated by the patch;
[0011] Map the patch-updated manuscript instance to the target platform data mode, divide the patch subset into several batches according to the platform receiving capacity and quota constraints, attach an idempotent single number and version number to each batch, and distribute within the quota constraints;
[0012] Collect the distribution return information returned by the target platform, and update the batch strategy parameters according to the return information.
[0013] As a preferred scheme of the multi-platform data distribution method based on dynamic mapping, wherein: the establishment of the unified skeleton structure comprises analyzing and extracting fields corresponding to the source manuscript according to the data modes of the plurality of target platforms, and forming an interface content;
[0014] Correlate the interface content to the data mode of the source manuscript and the data mode of the target platform respectively, and generate a unified skeleton structure capable of covering the source manuscript and each target platform simultaneously, for serving as a unified structure carrier;
[0015] The embedding of the source manuscript into the unified skeleton structure comprises mapping each field in the source manuscript according to the field position of the unified skeleton structure one by one, directly placing fields capable of direct correspondence, and establishing a correspondence relationship through the interface content for fields with differences, to form a complete source manuscript instance under the unified skeleton structure.
[0016] As a preferred scheme of the multi-platform data distribution method based on dynamic mapping, wherein: the generation of the differential patch comprises, when the manuscript operation node is triggered, fixing the state of the source manuscript before triggering and the state after triggering, comparing the states before and after triggering and extracting field-level difference content, and the difference content is defined as a differential patch;
[0017] In the differential patch generation process, the field type and structural integrity of the differential patch are checked, and the field path and value corresponding to the differential patch are converted to the field path and value under the unified skeleton structure;
[0018] The forming of the differential patch set comprises writing the converted differential patch into the unified skeleton structure, attaching the triggering time, source identification and context information to the differential patch under the unified skeleton structure, and forming the differential patch set according to the triggering order.
[0019] As a preferred scheme of the multi-platform data distribution method based on dynamic mapping, wherein: the generation of the standard differential set comprises performing normalization processing based on the unified skeleton structure on the differential patch set, so that the field values of the differential patch conform to the standard format defined by the unified skeleton structure, and normalizing and merging continuous repeated operations under the same path;
[0020] The normalized differential patches are subjected to dependency determination, and the execution order of the differential patches is determined according to a dependency rule set and a trigger time sequence to form a standard differential set;
[0021] The dependency rule set includes field-level dependency, timing dependency, structure dependency and obligation dependency, and each dependency rule records a preceding patch, a following patch and a dependency type in the form of a triple.
[0022] As a preferred scheme of the multi-platform data distribution method based on dynamic mapping, wherein: the dependency graph is constructed by taking the differential patches in the standard differential set as nodes of the dependency graph, taking the dependency relationship between the differential patches as edges of the dependency graph, and attaching trigger time, source information and execution priority to each differential patch; the generation value is estimated according to data size, processing complexity and distribution delay, and the generation value is bound as a node weight.
[0023] As a preferred scheme of the multi-platform data distribution method based on dynamic mapping, wherein: the selection of the minimum patch subset satisfying the data requirements of the target platform includes: analyzing the data requirements of the target platform to form an obligation set; marking the obligation set elements that can be satisfied by each differential patch in the dependency graph, and imposing a closure constraint on the differential patch set according to the dependency relationship, so that the selected differential patch set satisfies dependency consistency.
[0024] In the selection process, a genetic algorithm is used to search in the dependency graph; after individual coding, generation and mutation, dependency closure repair is performed; in the fitness evaluation, the obligation coverage completeness, the node generation value and the stability weight formed based on historical distribution receipt statistics are combined to comprehensively judge the candidate differential patch set; after multiple iterations, the differential patch set that covers all the obligation set and minimizes the sum of node weights is determined as the minimum patch subset; the minimum patch subset is executed one by one into the manuscript instance under the unified skeleton structure according to the dependency order;
[0025] The obligation set includes: mandatory field obligation, structure form obligation, timing obligation and format obligation.
[0026] As a preferred scheme of the multi-platform data distribution method based on dynamic mapping, wherein: the mapping of the patch-updated manuscript instance into the target platform data mode includes: calling the mapping rules determined during the construction of the dependency graph, and mapping the manuscript instance under the unified skeleton structure field by field to make it conform to the data mode defined by the target platform; performing obligation checking during the mapping process to ensure that the obligation set is satisfied; and outputting the mapping result satisfying the obligation set as an instance of the target platform data mode.
[0027] As a preferred scheme of the multi-platform data distribution method based on dynamic mapping, wherein: the dividing the patch subset into batches comprises, based on the instance of the target platform data mode, splitting the minimum patch subset into several differential patch sub-sequences according to the closure of the dependency relationship, each differential patch sub-sequence can be independently executed in topological order; the differential patch sub-sequences are pre-executed and verified on a copy of the unified skeleton structure, whether the differential patch sub-sequences can add new obligations and not destroy the existing obligations is verified, and the differential patch sub-sequences that pass the verification enter the candidate set; in the candidate set, according to the quota constraint of the current time window, a combination of differential patch sub-sequences that meet the quota capacity is selected, and when the new obligations reach the preset obligation subset, it is packaged into a batch; an idempotent single number and a version number are respectively attached to each batch; the idempotent single number and the version number are registered as the transaction boundary of the corresponding batch; the batches are executed in topological order according to the batch sequence, and each batch is checked again before distribution, and is submitted to the target platform after passing;
[0028] The idempotent single number is generated by the article identification, platform identification, time window and batch sequence number, and the version number includes platform contract version, unified skeleton structure configuration version, dependency graph version and obligation rule version.
[0029] As a preferred scheme of the multi-platform data distribution method based on dynamic mapping, wherein: the updating batch strategy parameters comprises receiving the return information returned by the target platform after the batch distribution is completed, and storing the return information in association with the idempotent single number and the version number; parsing the return information and extracting the field state, structure verification result, processing time consumption and error code, and mapping the parsing result to the differential patch and batch record;
[0030] The updating batch strategy parameters comprises adjusting the batch division logic, dependency order or path mapping rule according to the parsing result, and triggering rollback to the last successful state when a serious error is detected, or performing forward roll-in under the premise of ensuring dependency consistency.
[0031] In a second aspect, the application provides a multi-platform data distribution system based on dynamic mapping, comprising:
[0032] A skeleton module is configured to obtain a source article and establish a unified skeleton structure; a patch module is configured to generate a differential patch and form a differential patch set when an operation node is triggered; a processing module is configured to normalize the differential patch set and construct a dependency graph; a selection module is configured to select a minimum patch subset from the dependency graph and apply it to the unified skeleton; a mapping module is configured to map the updated article instance to a target platform data mode and divide batches for distribution under quota constraints; and an updating module is configured to collect target platform return information and update batch strategy parameters.
[0033] In a third aspect, the present application provides a computer device comprising a memory and a processor, wherein the memory stores a computer program, and wherein the computer program, when executed by the processor, implements any step of the method for multi-platform data distribution based on dynamic mapping according to the first aspect of the present application.
[0034] In a fourth aspect, the present application provides a computer readable storage medium storing a computer program, wherein the computer program, when executed by a processor, implements any step of the method for multi-platform data distribution based on dynamic mapping according to the first aspect of the present application.
[0035] The present application has the following advantages: By establishing a unified skeleton structure, the source manuscript is embedded into a unified bearing framework, avoiding the problem of scattered field mapping between multiple platforms. When the manuscript operation node is triggered, a differential patch is generated and written into the unified skeleton, which can accurately capture the modification point and form a differential patch set. Through standardization and sequential processing, the differential patch is organized into a standard differential set, and a dependency graph is constructed, with the node value reflecting the data size, processing complexity and distribution delay. The genetic algorithm is used on the dependency graph to select the smallest patch subset that meets the data requirements of the target platform, which can reduce redundancy while maintaining consistent dependencies. The updated manuscript instance is converted into the target platform data mode field by field through the mapping rule, and the mandatory check is combined to ensure that the mandatory fields, structure, timing and format meet the requirements. In the batch distribution link, the differential patch subset is split into several batches according to the quota constraint, and an idempotent single number and version number are added to each batch to realize traceability and anti-repetition. Finally, by collecting the target platform receipt information, the system can update the batch strategy parameters and trigger rollback or forward roll when an exception occurs, thereby realizing the efficiency, stability and scalability of cross-platform data distribution. BRIEF DESCRIPTION OF DRAWINGS
[0036] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the following will briefly introduce the drawings needed to be used in the embodiment description. Obviously, the drawings in the following description are only some embodiments of the present application, and for those skilled in the art, other drawings can also be obtained without creative labor.
[0037] Figure 1 Flowchart of the method for multi-platform data distribution based on dynamic mapping. DETAILED DESCRIPTION
[0038] In order to make the above-mentioned purposes, features and advantages of the present application more apparent and easy to understand, the specific embodiments of the present application will be described in detail below with reference to the drawings of the specification.
[0039] Many specific details are set forth in the following description in order to provide a full understanding of the invention. However, the invention may also be practiced in other ways different from those described herein, and those skilled in the art can make similar extensions without departing from the spirit of the invention. Therefore, the invention is not limited to the specific embodiments disclosed below.
[0040] Secondly, the term "one embodiment" or "embodiment" as used herein refers to a specific feature, structure, or characteristic that may be included in at least one implementation of the present invention. The phrase "in one embodiment" appearing in different places in this specification does not necessarily refer to the same embodiment, nor is it a single or selective embodiment that is mutually exclusive with other embodiments.
[0041] Reference Figure 1 This is one embodiment of the present invention, which provides a multi-platform data distribution method based on dynamic mapping, including the following steps:
[0042] S1: Obtain the source manuscript, establish a unified skeleton structure, and embed the source manuscript into the unified skeleton structure.
[0043] When the data distribution system starts, it retrieves source manuscripts from the manuscript production system. These manuscripts contain information such as title, body text, images, tags, and timestamps. To ensure that these manuscripts can be used for unified distribution across platforms, their structure is first defined as the source schema. The formula is expressed as:
[0044] ;
[0045] in, Indicates an instance of the source manuscript; This represents the data schema of the source manuscript, containing the original set of fields from the manuscript, such as... title, body, image, tag, timestamp Obj Representing source pattern A collection of objects.
[0046] Due to each platform Data patterns There are differences, so it needs to be addressed in the source mode. With each platform model Define the boundary content between them , is used to represent a common subset of the source manuscript and platform fields.
[0047] The formula for constructing a unified skeleton structure is:
[0048] ;
[0049] in, represents the unified skeleton structure, which is used to integrate the field requirements of all platforms; represents the intersection content, which represents the intersection of the source manuscript and the platform field; represents the mode of all platforms and the source mode on the intersection ; represents is an element in the target platform set ; represents the data mode of the platform , which contains the field set required by the platform; represents the intersection content, which is the common field abstraction between the source mode and the platform mode; represents the injection mapping from the intersection content to the source mode ; represents the injection mapping from the intersection content to the platform mode ; represents the target platform set, which is the set of all third-party platforms to which the system needs to distribute the source manuscript; represents a specific platform instance in the set .
[0050] The specific process of constructing the unified skeleton structure includes: extracting the fields related to the source manuscript for each platform, constructing the intersection ; mapping the intersection to the source mode and the platform mode respectively; performing a colimit operation on all intersections to obtain the unified skeleton .
[0051] The unified skeleton ensures that cross-platform differences can be unified in an intermediate layer, rather than writing adaptation logic one by one, solving the problem of repeated development and complex maintenance in the prior art.
[0052] After establishing the unified skeleton, each field of the source manuscript is mapped to the node of the unified skeleton , and for fields that cannot be directly mapped, the mapping relationship is defined through the intersection content , and then injected into the skeleton ; the manuscript representation on the skeleton is obtained , which is used as a reference instance for all subsequent differential patches and distribution logic.
[0053] Unified representation of the manuscript :
[0054] ;
[0055] wherein, represents the manuscript instance embedded in the uniform skeleton; represents the embedding of the mapping function.
[0056] By obtaining the source manuscript at system startup, defining its field set in the source mode, and combining multiple platform modes to extract common fields to construct the interface content, all platform requirements can be integrated under the uniform skeleton structure. The interface content forms a uniform skeleton through push and parallel operation, so that the differences between the source manuscript and the target platform are unified in the middle layer, and there is no need to develop an interface for each platform separately. In this way, not only the complexity of repeated development and maintenance is reduced, but also the adaptation efficiency of cross-platform data distribution is improved.
[0057] After establishing the uniform skeleton, the fields of the source manuscript are mapped one by one to the uniform skeleton structure, and the mapping relationship is established through the interface content for the fields that cannot be directly corresponded, and finally the manuscript instance embedded in the uniform skeleton is obtained. This instance serves as a reference representation for the subsequent differential patch generation and distribution logic, ensuring the consistency and integrity of the manuscript among multiple platforms. Through this process, the system can ensure the uniformity of field semantics and the compatibility of structure, fundamentally solving the problem of scattered fields and scattered adaptation in the prior art, and providing a stable foundation for subsequent differential processing and batch distribution.
[0058] S2: Generate a differential patch when the manuscript operation node is triggered, and promote the differential patch to the uniform skeleton to form a differential patch set.
[0059] When a manuscript operation node (such as new, modify, delete, publish) is triggered, the system synchronizes the two states of the source manuscript before and after the trigger:
[0060] ;
[0061] wherein, represents the source manuscript object before the trigger, represents the source manuscript object after the trigger.
[0062] By comparing and , extract the field-level differences and define them as differential patches:
[0063] ;
[0064] wherein, represents the operation type, taking values of add, remove, or replace; represents the source mode field paths, such as / title, / images / 0 / url; represents a set of initial delta patches; represents a delta patch; represents the field value after operation; represents the field value on path before triggering; represents the field value on path after triggering.
[0065] perform a check on each delta patch in , and if the check fails, reject the delta patch and record an exception; ensure that the field type and structure conform to the definition of the source schema :
[0066] ;
[0067] wherein, represents a field type matching predicate (for example must be of date type); true represents a logical true value, indicating that the check passes.
[0068] promote the delta patch to the unified skeleton, for the delta patch that passes the check, perform path and value promotion one by one, and map the field under the source schema to the unified skeleton structure :
[0069] ;
[0070] wherein, is a path promotion function that maps the source field path to the standard path in the unified skeleton structure, for example ; represents the promoted delta patch.
[0071] add trigger time, source identification, and context information to each delta patch to form a standard entry:
[0072] ;
[0073] wherein, represents the trigger time of the operation node, represents the source identification (such as manual editing or automatic generation), is the context (such as user ID and terminal information).
[0074] write all according to the trigger order to the unified skeleton structure, and sort them according to the trigger time to form a time-ordered set of delta patches:
[0075] ;
[0076] wherein, representing manuscript instance The difference patch set under the unified skeleton structure, n represents the total number of difference patches.
[0077] By fixing the pre-trigger and post-trigger states of the source manuscript at the same time when the manuscript operation node is triggered, and extracting field-level differences to generate difference patches, the system can accurately capture the content of each modification. In the process of generating difference patches, field type and structural integrity checking are introduced to ensure that each difference patch is consistent with the source mode, thereby avoiding the entry of incorrect data into the subsequent process. The difference patch that passes the verification is mapped to the unified skeleton structure through the path promotion function, and the trigger time, source identification and context information are attached, so that each patch has complete semantics and traceability attributes. Finally, all difference patches are written into the unified skeleton structure in the order of trigger and form an ordered set, which not only realizes accurate management of modifications across platforms, but also provides a reliable data foundation for subsequent standardized processing, dependency determination and minimum patch selection, thereby significantly improving the accuracy and consistency of distribution.
[0078] S3: Standardize and sequence the difference patch set to generate a standard difference set, and build a dependency graph for the target platform based on the standard difference set.
[0079] Read patch entries in by the unified skeleton path in the patch to locate the corresponding field.
[0080] Perform deterministic standardization operations on the field value (specific rules below), and write the standardization result back to the patch entry to replace the original value. Standardization rules include but are not limited to:
[0081] Time class field: converted to UTC format and fixed to millisecond level.
[0082] Boolean class field: unified as digital 0 / 1 (any true / false, yes / no, on / off is mapped to 1 / 0).
[0083] Text class field: unified as UTF-8 encoding, stripping control characters and whitelisting HTML / rich text filtering (residual rich text is converted to a uniform set of tags if necessary); standardize line breaks and white spaces.
[0084] Numerical value class field: integer is represented by decimal integer; floating point number is unified to two decimal places (or according to the precision constraint defined by the field).
[0085] Multimedia field: Replace local path or non-standard reference with a uniform resource URL (pointing to centralized or CDN storage), and add resource meta information (type, resolution, size) in patch.
[0086] Each patch is recorded with a canonicalized identifier after canonicalization, and written back to the patch storage area of the uniform skeleton.
[0087] In the canonicalized collection, patches are grouped by uniform skeleton path, and patches of the same path form a group; within each group, scan by trigger time order, and if multiple operations (e.g., multiple replace) on the same path are found, replace the previous multiple operations with the last valid operation, i.e., tail coverage rule, while retaining the merged metadata of the earliest trigger time and the latest source information to maintain traceability.
[0088] For scenarios where add / remove exist, determine whether they can be merged into no operation or a single replace according to semantics, e.g., add followed by immediate remove, merged into no operation, and recorded as a conflict event for auditing.
[0089] The result of merging forms an intermediate collection , which contains patches that have been canonicalized and deduplicated on the same path.
[0090] For each patch in , calculate the dependency candidate set, and the dependency rule set defines typical dependency relationships between fields, e.g.: the card field needs to exist first before the media reference field is generated; abstract generation is preferred over the delivery of the abstract reference field.
[0091] Use two deterministic principles to generate the execution sequence:
[0092] Priority is determined by dependency rules: if patch A is defined by the rules as a prerequisite event of patch B , then A has priority over B in the sequence.
[0093] Same level by trigger time order: when there is no direct dependency between patches, sort them by trigger time from early to late.
[0094] Apply the above rules to obtain a unique and replayable execution sequence, denoted as the standard delta collection .
[0095] Each canonicalized and sequenced delta patch in is taken as a node set of the dependency graph . The node identifier includes patch ID, path, operation type, trigger time, source, and necessary context.
[0096] According to the dependency rule set with explicit precedence relationship, a directed edge is established in the graph if patch A must be executed before patch B.
[0097] Dependency rule set includes:
[0098] Field dependency: when the field involved in a patch needs to depend on the value of a preceeding field, e.g. cover image field depends on picture URL field.
[0099] Timing dependency: when the execution order of a patch is affected by the trigger time, e.g. abstract generation must be executed after the body is updated.
[0100] Structure dependency: when the container or hierarchy involved in a patch must be created first, e.g. chapter container patch must be executed before directory node patch.
[0101] Obligation dependency: when the platform obligation corresponding to a patch must be satisfied first, e.g. required field obligation must be completed before format obligation is executed.
[0102] Each dependency rule is recorded in the form of a triple , where A represents the preceeding patch, B represents the succeeding patch, and T represents the dependency type, which is used to generate directed edges in the dependency graph.
[0103] In addition to the meta information of a node, a cost value is estimated for each delta patch. The cost value is calculated by considering three aspects:
[0104] Data size: the amount of data contained in a patch, the larger the size, the more it consumes in network transmission and storage.
[0105] Processing complexity: whether a patch involves complex normalization, path mapping or cross-field merging operations, the higher the complexity, the higher the cost.
[0106] Distribution latency: whether a patch is likely to trigger platform speed limit, queue waiting or bandwidth constraints during distribution, the higher the latency risk, the higher the cost.
[0107] The integrated cost value is bound to the delta patch node as the node weight, and is stored together with the trigger time, source information and execution priority. The dependency graph constructed in this way not only describes the dependency relationship between delta patches, but also quantifies the cost characteristics of each patch in distribution, providing input for subsequent minimum cut optimization.
[0108] For each difference patch node, the system respectively obtains the numerical values of the "data size factor", "processing complexity factor" and "distribution delay factor", then normalizes the three to the same value interval according to the specification under the unified skeleton structure, and then performs weighted summation according to the fixed proportion configured by the operation and maintenance, and the obtained result is used as the node weight of the node. The node weight and the basic metadata of the difference patch (including patch identification, unified skeleton path, operation type, trigger time, source identification and context information) are written into the node attribute of the dependency graph and persisted, used for subsequent minimum cut optimization and audit playback; when the operation and maintenance does not configure the proportion, the system uses the preconfigured default proportion, and records the proportion version used this time for traceability and consistency check.
[0109] By performing field-level normalization operation on the difference patch set, different types of fields such as time, Boolean, text, numerical value and multimedia can be unified into a deterministic format, and the normalization result is marked in the patch entry. This processing avoids parsing errors caused by inconsistent field formats between platforms, and eliminates redundant or contradictory operations on the same path through tail coverage and conflict merging mechanism, ensuring the simplicity and traceability of the difference patch set. The intermediate set formed by normalization and sequencing provides stable and consistent data input for the subsequent judgment of dependency relationship.
[0110] On the basis of normalization and sequencing, the dependency graph of the difference patch is constructed by using the dependency rule set, and the comprehensive generation value is bound to each patch node, so that the dependency graph can not only express the front and rear constraint relationship between patches, but also quantify the resource consumption of each patch in the distribution process. The generation value is calculated through three dimensions of data size, processing complexity and distribution delay, and combined with the weight configured by the operation and maintenance to form the node weight. The dependency graph therefore has the determinacy of execution sequence and the ability of cost evaluation, providing an operable quantitative basis for subsequent selection of minimum patch subset and minimum cut optimization, significantly improving the controllability and efficiency of cross-platform distribution.
[0111] S4: On the dependency graph, select the minimum patch subset that meets the data requirements of the target platform, and apply the minimum patch subset to the unified skeleton structure to obtain the manuscript instance updated by the patch.
[0112] Four types of obligations are read and standardized from the target platform access specification: mandatory field obligation, structure form obligation, timing obligation, and format obligation.
[0113] Mandatory field obligation: core fields required by the platform, such as title, body, timestamp, and unique identifier. If these fields are missing, the platform will reject them, so the corresponding difference patch must be selected in the set.
[0114] Structural obligation: the requirement of the platform on the organization of data, e.g. the body must be stored as an array of paragraphs, the images must be under the / images[] array and contain url and size fields, the metadata must be centralized in the / meta node. The patch set must guarantee that the final structure satisfies this form, otherwise it will cause parsing failure.
[0115] Temporal obligation: the requirement of the platform that the writing and updating of fields must satisfy the time sequence. For example, the publishing time field must appear after the body field is completed; the publishing status must be allowed to submit only after the title and body are ready; the multimedia reference must be written into the body only after the resource upload successfully returns the ID. These requirements are represented as directed edges between patches in the dependency graph, and the patch selection must comply with them.
[0116] Format obligation: the requirement of the platform on the specific representation of fields. For example, the time field must be in UTC standard format, the boolean value must be true / false, the numerical value must meet the precision requirement (such as two decimal places), and the text must be unified as UTF-8 encoding and remove unescaped symbols. The patch set must ensure that the final value is normalized and meets these format requirements.
[0117] Encode these obligations as comparable atomic elements (e.g. generate an existence obligation item for each required field; generate a form obligation item for each structure form), and the set is denoted as . The obligation set is used to determine whether the candidate patch set covers all obligations in the obligation set.
[0118] Traverse each node (patch) of the dependency graph and match it with the obligation set: if a patch can satisfy a certain obligation element, record the subset of obligations that can be satisfied in the node metadata. At the same time, record the trigger time, source information, and node generation value and stability weight of the node.
[0119] The deterministic scheme of selection (choose the best from multiple schemes) uses greedy seeding + controlled perturbation population initialization as the initial population generation strategy, and the specific process includes:
[0120] According to the obligation set, select one by one the node that can cover the current obligation that has not been covered and has the smallest unit generation value, output a greedy candidate subset as the core individual in the population; based on this greedy individual, produce several variants: randomly replace some nodes in the individual (the replacement candidates come from the same obligation coverage set but have slightly higher / lower generation values), to ensure that the initial population has both high-quality candidates and necessary diversity; the initial population size is set to 50 individuals, which balances the search space coverage and computational cost.
[0121] Determine the fitness of each candidate patch set (i.e. an individual) by the following steps and priorities:
[0122] Coverage completeness of obligations (first priority): Calculate the proportion of obligations covered by the candidate set (number of covered obligations / total number of obligation set). If the coverage is <100%, the candidate is considered not to meet the target, and the score is significantly lower (as a hard constraint priority to pass first).
[0123] Total generation cost (second priority): Sum the generation cost of each node in the candidate set as a total cost measurement item (the smaller the better). The node generation cost has been evaluated and standardized in S3 in terms of data size, processing complexity, and distribution delay.
[0124] Stability weight: Stability comes from historical distribution feedback statistics, which can be combined into a stability score by the following engineering indicators.
[0125] Success rate: The ratio of successful completion of distribution in similar scenarios in the history (number of successes / number of attempts).
[0126] Average response time: The inverse of the historical average completion delay of the node as a stability positive factor (smaller delay is more stable).
[0127] Failure severity: If the node has triggered serious errors (leading to rollback or manual intervention) multiple times in the history, the stability score should be reduced. The system will synthesize these items into a 0-1 stability coefficient according to the proportion configured by the operation and maintenance (the closer to 1, the more stable).
[0128] Each change in the candidate subset (including initialization, crossover, and mutation) must ensure the consistency of the dependency closure. The specific process includes: if a node is selected, all its predecessor dependency nodes (in the direction of ) must also be selected.
[0129] Closure repair includes: traversing the candidate set to identify the selected node set ; for any node in , if there is a predecessor dependency node (i.e. in ), and is not included in , add to ; continue to perform the same check on the newly added until no new predecessor dependency node needs to be added (i.e. take the closure); after the closure is completed, recalculate the total generation cost and coverage of the set, and continue to evaluate it as a legal candidate.
[0130] On the basis of ensuring the closure consistency, the conventional iteration strategy of genetic search is adopted, and in the present embodiment, deterministic default parameters are provided for engineering direct use:
[0131] Selection: Select several better individuals from the current population as parents in each generation, and the "tournament selection" strategy is used by default (tournament size 3, which is stable and simple to implement).
[0132] Crossover (merge): Merge the selected parents at a certain proportion (default 70% of parent pairs), and perform closure repair on the results to ensure dependency consistency. The merging strategy is set union first, and the patch set of merging two parents is the initial child set.
[0133] Mutation (perturbation): Replace one node in the child with a small probability (default 2%), and replace it with other candidate nodes in the same obligation coverage pool. After replacement, closure repair is also performed.
[0134] Generation update: Combine the new generation with elite individuals (default to retain the top 5% of individuals) to form the next generation population.
[0135] Termination condition (deterministic): terminate when the maximum number of generations (default 200 generations) is reached or the optimal solution does not improve for 20 consecutive generations.
[0136] Parameter reason: The above default parameters (population 50, crossover rate 0.7, mutation rate 0.02, tournament size 3, number of generations 200, and no improvement for 20 generations) are a balanced choice between search efficiency and effectiveness in engineering, which can ensure a certain exploration ability and will not lead to unacceptable computational cost. It can be fine-tuned by operation and maintenance when deployed.
[0137] At the end of the termination, the candidate with the smallest total generation value that meets all obligations in the current population is taken as the final minimum patch subset. If there are multiple solutions with the same total generation value, the candidate with the higher stability coefficient is preferred. The minimum patch subset is applied to the manuscript instance under the unified skeleton structure one by one in the order of dependency topology (from no pre-dependence to pre-dependence) , and the patched manuscript instance is obtained. Each step of application is verified again for closure consistency before application and the reply log is recorded for auditing.
[0138] In the present embodiment, the candidate set is represented by a Boolean vector or a node ID list in memory; closure repair is implemented by forward / inverse traversal of the graph (DFS / BFS).
[0139] In the dependency graph, each delta patch has bound the trigger time, dependency, node generation value and stability weight, which provides a complete data basis for the selection process. By extracting the mandatory fields, structure form, timing and format from the target platform access specification, and converting them into atomic obligation elements, the patch and obligation relationship can be matched one by one on the dependency graph. Combined with the closure repair mechanism, it is ensured that any selected patch must contain its pre-dependencies, thereby ensuring dependency consistency. Based on these premises, the group search of genetic algorithm can find the candidate subset with the smallest total generation value and higher stability while covering all obligations.
[0140] By decomposing the data requirements of the target platform into four types of obligations: mandatory fields, structure form, timing and format, the system can convert abstract requirements into computable elements. The candidate patch subset must cover all obligation elements during the search process, otherwise it is directly eliminated. This hard constraint ensures that the output result must meet the platform receiving specification. This design avoids the distribution failure caused by missing key fields or sequence errors in existing methods, significantly improving the reliability of cross-platform adaptation.
[0141] The generation value of each patch node is composed of data size, processing complexity and distribution delay. After normalization, the weighted sum is taken as the node weight. Genetic algorithm takes the total generation value as the optimization target in the adaptation evaluation, which can select the patch set with smaller total cost while ensuring obligation coverage, thereby reducing transmission redundancy and computational burden. This way makes the system still maintain high efficiency when facing large-scale manuscript updates, optimizing the overall resource utilization.
[0142] In the adaptation evaluation, the stability weight is introduced, and based on the historical feedback statistics, the success rate, response time and failure severity are calculated, so that the selection process not only considers the static dependencies and costs, but also considers the dynamic execution reliability. The introduction of stability weight enables the system to preferentially select patch nodes that have performed stably in historical scenarios, reducing the risk of serious errors in the distribution process and improving the robustness and adaptability of the overall distribution link.
[0143] S5: Map the manuscript instance updated by the patch to the target platform data mode, divide the patch subset into several batches according to the platform receiving capacity and quota constraints, and each batch is attached with an idempotent single number and version number, and distributed within the quota constraints.
[0144] Call the mapping rules determined in the dependency relationship establishment stage to perform field-by-field conversion on the manuscript instance updated by the patch, so that it fully meets the data mode requirements of the target platform.
[0145] The generation of the mapping rule specifically includes: when the unified skeleton structure is constructed, the source mode is compared with each target platform mode field by field, the field pairs with one-to-one correspondence are extracted, for example, the title in the source mode and the headline in the platform mode, and a field mapping table is generated; for the fields with differences, intermediate rules are established through the interface mode, for example, the timestamp field of the source mode is converted into the UTC format required by the platform, or the Boolean type field is converted into 1 / 0 identification. Secondly, the system archives these field mapping relationships as a rule set, each rule including a source field path, a target field path, a conversion operation type and a format constraint condition. For example, if the source field is / body and the target platform requires a segmented array format, the rule records “source / body → target / content[], operation: paragraph segmentation, constraint: UTF-8 encoding”. These rules are solidified in the dependency graph construction stage and are called one by one during mapping to ensure that the conversion result can meet the field definition and obligation set of the target platform.
[0146] During the mapping process, the mapping result is checked to ensure that the mandatory fields, structure form, timing and format obligations are met. If missing or illegal fields are found, the system automatically blocks the mapping process and generates a repair prompt.
[0147] The checked manuscript instance is packaged as an instance of the target platform data mode and enters the subsequent batch splitting and distribution process.
[0148] Further, under the target platform data mode instance, the minimum patch subset is split into several differential patch subsequences according to the dependency relationship closure, ensuring that each subsequence can be executed independently in topological order.
[0149] In the copy environment of the unified skeleton structure, each differential patch subsequence is pre-executed to verify whether it can add at least one obligation that is met without destroying the existing obligations.
[0150] The verified subsequence is included in the candidate set to provide alternative units for subsequent batch assembly.
[0151] In the current time window, the capacity consumption of the candidate subsequence is evaluated according to the receiving capacity and quota constraints of the target platform.
[0152] The platform receiving capacity parameters are obtained from the interface specification document or protocol information provided by the target platform when accessing, for example, the maximum number of concurrent calls, the maximum data packet size acceptable for a single request, and the daily call limit. The system parses these capacity indicators and stores them in the configuration library during the access stage, so as to be called during batch splitting.
[0153] The quota constraint parameter is set by the operation and maintenance personnel during the deployment stage according to the platform SLA agreement and operation experience, for example, to avoid triggering the platform speed limit, the upper limit of the number of requests in a single time window is set to 80% of the nominal upper limit of the platform, and dynamic adjustment is allowed. The system reads the latest quota configuration before the start of each time window as the capacity threshold for batch division.
[0154] A set of differential patch subsequences is selected from the candidate set, so that its capacity does not exceed the quota, and the new obligation coverage reaches the preset obligation subset threshold. The selected differential patch subsequences are encapsulated as a batch, and transaction boundary information is attached.
[0155] Idempotent single number: generated by splicing the manuscript identification, platform identification, time window and batch number, to ensure that repeated submission of the same batch will not cause repeated execution.
[0156] The version number contains four types of version information: platform contract version; unified skeleton structure configuration version; dependency graph version; obligation rule version. These version information together constitute the unique semantic identifier of the batch.
[0157] According to the topological order of the batch sequence, they are executed one by one, and each batch performs obligation check again before distribution, to ensure that there is no omission or violation when received by the target platform.
[0158] Before submitting to the target platform, the system serializes the patch updated manuscript instance into a request message body that meets the target platform API contract, including field mapping results, batch sequence and transaction boundary. The batch is checked and sent to the target platform through REST API, message queue or SDK call, and the idempotent number and version number are attached in the request header or transaction record. This mechanism ensures that the platform only executes once even if repeated submission occurs, ensuring the stability and consistency of distribution.
[0159] After submitting to the target platform, the return information returned by the platform will be recorded in the transaction boundary of the batch, which will be used for subsequent tracking and stability evaluation.
[0160] Based on the fact that S3 and S4 have generated a standard differential set and screened out the smallest patch subset, the system has stable input conditions. By calling the established mapping rules, it can ensure that the updated manuscript instance is converted into the required format of the target platform field by field, and the data integrity and standardization are guaranteed through obligation check. Further, the candidate differential patch subsequences complete the pre-execution verification in the replica environment, confirming that the new obligation is met and does not destroy the existing obligation, so that the subsequence can be an effective unit for batch encapsulation. Combined with the idempotent number and version number mechanism, the uniqueness and traceability of the batch can be guaranteed, and repeated execution can be avoided.
[0161] The design of field-by-field mapping and mandatory obligation check is to ensure that the patch-updated manuscript instance is fully aligned with the data schema of the target platform when output. Through this mechanism, the system not only eliminates the risk of rejection due to missing fields or format inconsistencies, but also avoids data parsing failures between platforms. This approach based on a unified skeleton and established mapping rules ensures consistency and compliance during cross-platform distribution.
[0162] Pre-verification of the differential patch subsequence in the candidate set and control of batch size through quota constraints and obligation subset threshold can effectively balance platform receiving capacity and distribution integrity. The introduction of idempotent single number avoids repeated execution, and the multi-dimensional design of version number ensures that each distribution and configuration can be traced back. This batch and transaction combined mode makes the system not only efficient in large-scale distribution, but also quickly locates and recovers when errors occur, significantly improving the efficiency and controllability of the overall operation.
[0163] S6: Collect the distribution receipt information returned by the target platform, and update the batch strategy parameters according to the receipt information.
[0164] After the batch distribution is completed, the system actively receives the return information returned by the target platform. The return information is associated with the idempotent single number and version number of the corresponding batch one by one and stored in the batch record database. This binding mechanism ensures that multiple retransmissions of the same batch can still be traced back to the same transaction boundary, avoiding data disorder.
[0165] Parse the receipt information and extract the following key indicators:
[0166] Field status: Whether the target platform successfully receives and parses each field.
[0167] Structure verification result: Target platform feedback on the integrity of the manuscript structure.
[0168] Processing time: The time difference from batch submission to receipt generation.
[0169] Error code: If processing fails or partially fails, return the specific error type.
[0170] Map the parsed indicators to the differential patch and batch record one by one, so that each differential patch has state feedback in the record. Through this mapping, the execution of any differential patch can be accurately traced back.
[0171] According to the receipt result, the batch division logic is dynamically updated. For example, if a batch timeout is frequent, the single batch capacity is reduced in the next round of distribution. If it is found that a specific differential patch sequence causes dependency conflicts, the dependency sequence is adjusted and reordered under the premise of ensuring dependency consistency. If the receipt contains path error feedback, the path mapping rules are revised to make subsequent mapping more consistent with platform requirements.
[0172] When the failure rate exceeds p% or a serious error is detected (such as the platform rejecting the entire batch or the absence of a key obligation field), the system triggers a rollback operation to restore the state to the last successful batch, ensuring global consistency. If the error is partial and does not affect overall dependency consistency, a forward roll is performed to complete the patch, i.e., additional patches are added based on the current successful state until the obligations are met. Through the cooperation of rollback and forward roll, both safety and distribution efficiency are maintained.
[0173] After the batch distribution is completed, the system can receive and analyze the receipt information returned by the target platform, and bind it one by one with the corresponding batch through the idempotent serial number and version number, ensuring that the information source is traceable. Four types of indicators, including field state, structure verification result, processing time, and error code, are extracted during the analysis process, and the results are mapped to the differential patch and batch record, so that each differential patch can be accompanied by execution feedback. This forms a closed-loop link from submission to feedback, providing a reliable basis for dynamic updating of batch strategy parameters.
[0174] By directly associating the receipt result with the batch logic, the system can automatically adjust the batch division scale, dependency sequence, and path mapping rules when an exception is detected. For example, when a batch timeout occurs, the system automatically reduces the capacity; when dependency conflicts are found, the dependency path is reordered. This adaptive mechanism based on real-time feedback enables the system to maintain stable operation in complex and variable platform environments.
[0175] The two-way mechanism of rollback and forward roll is designed to ensure that the system can immediately recover to the last successful batch when encountering serious errors, ensuring global consistency; in the case of only partial missing, it can continue to complete in the current state, avoiding overall blocking. This processing method not only ensures the safety of distribution, but also reduces the downtime caused by errors, achieving a balance between stability and efficiency.
[0176] The embodiment also provides a multi-platform data distribution system based on dynamic mapping, comprising:
[0177] The skeleton module is used to acquire a source manuscript and establish a uniform skeleton structure; the patch module is used to generate a differential patch and form a differential patch set when an operation node is triggered; the processing module is used to normalize the differential patch set and construct a dependency graph; the selection module is used to select a minimum patch subset on the dependency graph and apply to the uniform skeleton; the mapping module is used to map the updated manuscript instance to a target platform data mode and divide batches for distribution under a quota constraint; and the update module is used to collect target platform receipt information and update batch strategy parameters.
[0178] The embodiment also provides a computer device suitable for the case of the multi-platform data distribution method based on dynamic mapping, including a memory and a processor; the memory is used to store computer executable instructions, and the processor is used to execute the computer executable instructions to realize the multi-platform data distribution method based on dynamic mapping proposed in the above embodiment.
[0179] The computer device can be a terminal, and the computer device includes a processor, a memory, a communication interface, a display screen and an input device connected through a system bus. The processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system and a computer program. The internal memory provides an environment for the operating system and the computer program in the non-volatile storage medium to run. The communication interface of the computer device is used to communicate with external terminals in a wired or wireless manner. The wireless manner can be achieved through WIFI, an operator network, NFC (near field communication) or other technologies. The display screen of the computer device can be a liquid crystal display screen or an electronic ink display screen. The input device of the computer device can be a touch layer overlaid on the display screen, or a key, trackball or touchpad arranged on the shell of the computer device, or an external keyboard, touchpad or mouse, etc.
[0180] The embodiment also provides a storage medium, which stores a computer program, and the computer program is executed by a processor to implement the method for multi-platform data distribution based on dynamic mapping as proposed in the above embodiment. The storage medium can be implemented by any type of volatile or nonvolatile storage devices or a combination thereof, such as Static Random Access Memory (SRAM), Electrically Erasable Programmable Read-Only Memory (EEPROM), Erasable Programmable Read-Only Memory (EPROM), Programmable Read-Only Memory (PROM), Read-Only Memory (ROM), magnetic storage, flash memory, magnetic disk or optical disk.
[0181] It should be noted that the above embodiment is only used to illustrate the technical solutions of the present application but not limit the present application. Although the present application is described in detail with reference to the preferred embodiments, those skilled in the art should understand that the technical solutions of the present application can be modified or replaced equivalently without departing from the spirit and scope of the technical solutions of the present application, and all of them should be covered in the scope of the claims of the present application.
Claims
1. A multi-platform data distribution method based on dynamic mapping, characterized in that, include: Obtain the source manuscript, establish a unified skeleton structure, and embed the source manuscript into the unified skeleton structure; When a manuscript operation node is triggered, a differential patch is generated and the differential patch is promoted to the unified skeleton to form a differential patch set; The differential patch set is normalized and ordered to generate a standard deviation set, and a dependency graph is constructed for the target platform based on the standard deviation set. On the dependency graph, select the minimum patch subset that meets the data requirements of the target platform, and apply the minimum patch subset to the unified skeleton structure to obtain the patched manuscript instance; The patched manuscript instance is mapped to the target platform data pattern. Based on the platform's receiving capacity and quota constraints, the patch subset is divided into several batches. Each batch is given an idempotent number and a version number and distributed within the quota constraints. Collect distribution receipt information returned by the target platform, and update the batch strategy parameters based on the receipt information; The establishment of a unified skeleton structure includes analyzing and extracting fields that correspond to the source manuscript based on the data patterns of multiple target platforms, forming boundary content; The boundary content is associated with the data patterns of the source manuscript and the target platform respectively, and a unified skeleton structure that can simultaneously cover the source manuscript and each target platform is generated to serve as a unified structural carrier. The step of embedding the source manuscript into the unified skeleton structure includes mapping each field in the source manuscript to the field position of the unified skeleton structure one by one. Fields that can be directly matched are placed directly, and fields that have differences are established through the boundary content to form a corresponding relationship, thus forming a complete source manuscript instance under the unified skeleton structure. The generation of differential patches includes fixing the state of the source manuscript before and after the trigger when the manuscript operation node is triggered, comparing the states before and after the trigger and extracting the field-level differences, and the differences are defined as differential patches. During the differential patch generation process, the field types and structural integrity of the differential patch are verified, and the field paths and values corresponding to the differential patch are converted into field paths and values under a unified skeleton structure. The process of forming a differential patch set includes writing the converted differential patches into a unified skeleton structure, attaching trigger time, source identifier and context information to the differential patches under the unified skeleton structure, and forming a differential patch set according to the trigger order of the differential patches.
2. The multi-platform data distribution method based on dynamic mapping as described in claim 1, characterized in that: The process of generating the standard deviation set includes performing normalization processing on the differential patch set based on a unified skeleton structure, so that the field values of the differential patches conform to the standard format defined by the unified skeleton structure, and normalizing and merging consecutive repeated operations under the same path. Dependency determination is performed on the normalized differential patches, and the execution order of the differential patches is determined according to the dependency rule set and the trigger time order to form a standard differential set; The dependency rule set includes field-level dependencies, time-series dependencies, structural dependencies, and obligation dependencies. Each dependency rule records the preceding patch, the following patch, and the dependency type in the form of a triple.
3. The multi-platform data distribution method based on dynamic mapping as described in claim 2, characterized in that: The construction of the dependency graph includes using differential patches in the standard deviation set as nodes of the dependency graph, using the dependency relationships between differential patches as edges of the dependency graph, and attaching trigger time, source information and execution priority to each differential patch; estimating the cost value based on data size, processing complexity and distribution delay, and binding the cost value as node weight.
4. The multi-platform data distribution method based on dynamic mapping as described in claim 3, characterized in that: The selection of the minimum subset of patches that meets the data requirements of the target platform includes parsing the data requirements of the target platform to form an obligation set; Mark the set of obligations that each differential patch can satisfy in the dependency graph, and apply closure constraints to the differential patch set according to the dependency relationship to ensure that the selected differential patch set satisfies dependency consistency. In the selection process, a genetic algorithm is used to search within the dependency graph; after individual encoding, generation and mutation, dependency closure repair is performed; in fitness evaluation, the candidate differential patch set is comprehensively judged by combining the obligation coverage completeness, node value and stability weight formed based on historical distribution receipt statistics. After multiple rounds of iteration, the differential patch set that covers the entire set of obligations and minimizes the sum of node weights is determined as the minimum patch subset; In order of dependency, the smallest subset of patches is executed one by one into the manuscript instance under the unified skeleton structure; The set of obligations includes: mandatory field obligations, structural obligations, temporal obligations, and formatting obligations.
5. The multi-platform data distribution method based on dynamic mapping as described in claim 4, characterized in that: The step of mapping the patch-updated manuscript instance to the target platform data pattern includes calling the mapping rules determined during the dependency graph construction, mapping the manuscript instance under the unified skeleton structure field by field to make it conform to the data pattern defined by the target platform. During the mapping process, an obligation check is performed to ensure that the set of obligations is satisfied; the mapping result that satisfies the set of obligations is output as an instance of the target platform data pattern.
6. The multi-platform data distribution method based on dynamic mapping as described in claim 5, characterized in that: The patch subset is divided into several batches, including instances based on the target platform's data pattern. The smallest patch subset is split into several differential patch subsequences according to dependency closures. Each differential patch subsequence can be executed independently in topological order. The differential patch subsequences are pre-executed and verified on a copy with a unified skeleton structure to verify whether they can add at least one obligation without breaking existing obligations. The differential patch subsequences that pass the verification are added to the candidate set. In the candidate set, based on the quota constraints of the current time window, combinations of differential patch subsequences that meet the quota capacity are selected, and when the added obligations reach a preset subset of obligations, they are encapsulated into a batch. An idempotent number and a version number are attached to each batch. The idempotent number and version number are registered together as the transaction boundary of the corresponding batch. The batches are distributed sequentially according to the topological order of the batch sequence. Before distribution, each batch undergoes an obligation check again, and after passing the check, it is submitted to the target platform. The idempotent order number is generated from the manuscript identifier, platform identifier, time window, and batch number. The version number includes the platform contract version, unified skeleton structure configuration version, dependency graph version, and obligation rule version.
7. The multi-platform data distribution method based on dynamic mapping as described in claim 6, characterized in that: The updated batch strategy parameters include receiving the receipt information returned by the target platform after the batch distribution is completed, and storing the receipt information in association with the idempotent order number and version number; parsing the receipt information and extracting the field status, structure verification results, processing time and error code, and mapping the parsing results to differential patches and batch records; The update batch strategy parameters include adjusting the batch partitioning logic, dependency order, or path mapping rules based on the parsing results, and triggering a rollback to the previous successful state when an error is detected.
8. A multi-platform data distribution system based on dynamic mapping, based on the multi-platform data distribution method based on dynamic mapping according to any one of claims 1 to 7, characterized in that: The skeleton module is used to acquire source manuscripts and establish a unified skeleton structure; the patch module is used to generate differential patches and form a differential patch set when an operation node is triggered. The processing module is used to normalize the differential patch set and build a dependency graph; the selection module is used to select the smallest subset of patches on the dependency graph and apply it to the unified skeleton; the mapping module is used to map the updated manuscript instance to the target platform data pattern and divide it into batches for distribution under quota constraints; the update module is used to collect the target platform's receipt information and update the batch strategy parameters.
Citation Information
Patent Citations
Data distribution method, device and system and storage medium
CN110175210A
Data distribution method and device
CN114995833A