Warehouse data management method, device, equipment and medium

Abstract

The present application discloses a warehouse data management method, device, equipment and medium, which relate to the field of data processing technology. The method obtains the data to be managed from each warehouse house system of the warehouse management system; the data to be managed is data generated based on global data constraints, open annotation protocols, preset fields and telemetry data; data processing is performed on the data to be managed; data processing includes standardization processing and address configuration operations; the processed data is configured based on the address of the warehouse server in the warehouse management system, and the configured processed data is sent to the warehouse server so that the warehouse server can perform persistent storage, business entity association and visual display on the configured processed data, complete the management of the data to be managed, improve the data consistency between warehouse house systems, solve the problems of high interface coupling and strong dependence, realize the separation of business and data processing, and avoid the overall system performance degradation due to some system performance bottlenecks in extreme scenarios.

Description

Technical Field

[0001] The present invention relates to the field of data processing technology, and in particular to a warehouse data management method, device, equipment and medium. Background Art

[0002] Warehouse management is a comprehensive management activity that uses a systematic approach to plan, control, and optimize storage space, material flow, inventory status, and operational processes. Currently, there are two methods for warehouse data management: one is to split warehouse management functions into independent subsystems, such as inventory management, process approval, and material tracking. Each module uses a differentiated technology stack and achieves final data consistency through an event-driven architecture. However, this method has a long cross-system data synchronization link. For example, inventory changes need to be synchronized to the approval system and the warehouse system in sequence, which results in data delays, and concurrent operations are prone to conflicts. In addition, there are problems with high interface coupling and strong dependencies. The other method uses a single core system as the hub to build an integrated platform through vertical integration of functional modules. However, this method has rigid business adaptation and customized functions are difficult to support extremely differentiated needs. This leads to a decline in the overall system performance due to performance bottlenecks in some systems in extreme scenarios. In addition, the monolithic architecture is difficult to expand horizontally, which limits the scale of the system; the ecological compatibility is limited, which restricts technological innovation.

[0003] It can be seen that how to improve data consistency between different library systems, solve the problems of high interface coupling and strong dependence, realize the separation of business and data processing, reduce the overall hardware pressure of the system, avoid the overall system performance degradation caused by performance bottlenecks of some systems in extreme scenarios, and effectively improve business development efficiency are problems that technical personnel in this field need to solve. Summary of the Invention

[0004] The purpose of the embodiments of the present invention is to provide a warehouse data management method, device, equipment, and medium that can improve data consistency between different warehouse systems, solve the problems of high interface coupling and strong dependence, realize the separation of business and data processing, reduce the overall hardware pressure of the system, avoid the overall system performance degradation caused by performance bottlenecks of some systems in extreme scenarios, and effectively improve business development efficiency. The specific solution is as follows:

[0005] In a first aspect, the present application discloses a warehouse data management method, which is applied to a data aggregation center in a warehouse management system. The warehouse management system adopts a layered system architecture mode. The method includes:

[0006] Obtain the data to be managed from each warehouse system in the warehouse management system; the data to be managed is data generated based on global data constraints, open annotation protocols, preset fields, and telemetry data;

[0007] Processing the data to be managed to obtain processed data; wherein the data processing includes standardization processing and address configuration operations;

[0008] The processed data is configured based on the address of the warehouse server in the warehouse management system, and the configured processed data is exported and sent to the warehouse server so that the warehouse server can perform persistent storage, business entity association, and visual display on the configured processed data to complete the management of the management data.

[0009] In a second aspect, the present application discloses a warehouse data management device, which is applied to a data aggregation center in a warehouse management system. The warehouse management system adopts a layered system architecture mode; wherein the device includes:

[0010] The data acquisition module is used to obtain the data to be managed from each warehouse system in the warehouse management system; the data to be managed is data generated based on global data constraints, open annotation protocols, preset fields and telemetry data;

[0011] The data processing module is used to process the management data to obtain processed data; wherein the data processing includes standardization processing and address configuration operations;

[0012] The data export module is used to configure the processed data based on the address of the warehouse server in the warehouse management system, export the configured processed data and send it to the warehouse server, so that the warehouse server can perform persistent storage, business entity association and visual display on the configured processed data to complete the management of the management data.

[0013] In a third aspect, the present application discloses an electronic device, comprising:

[0014] memory for storing computer programs;

[0015] The processor is used to implement the steps of the above-mentioned warehouse data management method when executing the computer program.

[0016] In a fourth aspect, the present application discloses a computer-readable storage medium, in which a computer program is stored, wherein the computer program implements the steps of the aforementioned warehouse data management method when executed by a processor.

[0017] It can be seen that the present application provides a warehouse data management method, which is applied to the data aggregation center in the warehouse management system, and the warehouse management system adopts a hierarchical system architecture model; the method includes obtaining the data to be managed from each warehouse house system in the warehouse management system; the data to be managed is data generated based on global data constraints, open annotation protocols, preset fields and telemetry data; data processing is performed on the data to be managed to obtain processed data; wherein, data processing includes standardization processing and address configuration operations; the processed data is configured based on the address of the warehouse server in the warehouse management system, and the configured processed data is exported and sent to the warehouse server, so that the warehouse server can perform persistent storage, business entity association and visual display on the configured processed data to complete the management of the data to be managed. This application obtains the data to be managed from each warehouse house system in the warehouse management system; the data to be managed is data generated based on global data constraints, open annotation protocols, preset fields and telemetry data, which improves the data consistency between different warehouse house systems, can greatly reduce data cleaning costs, and solve the problems of high interface coupling and strong dependence. The data to be managed is processed to obtain processed data, and the processed data is configured. The configured processed data is exported and sent to the warehouse server, so as to realize the separation of business and data processing, reduce the overall hardware pressure of the system, and avoid the overall system performance degradation caused by the performance bottleneck of some systems in extreme scenarios. The warehouse server is used to perform persistent storage, business entity association, and visualization of the configured processed data, which can effectively improve the agility and efficiency of business development. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] In order to more clearly illustrate the embodiments of the present application, the following is a brief introduction to the drawings required for use in the embodiments. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0019] Figure 1 A flow chart of a warehouse data management method disclosed in this application;

[0020] Figure 2 This is a structural diagram of a warehouse management system disclosed in this application;

[0021] Figure 3 This is a structural diagram of a data aggregation center disclosed in this application;

[0022] Figure 4 This is a structural diagram of a warehouse data management device disclosed in this application. DETAILED DESCRIPTION

[0023] The following will be combined with the accompanying drawings in the embodiments of this application to clearly and completely describe the technical solutions in the embodiments of this application. Obviously, the embodiments described are only part of the embodiments of this application, not all of them. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.

[0024] Warehouse management is a comprehensive management activity that uses a systematic approach to plan, control, and optimize storage space, material flow, inventory status, and operational processes. Currently, there are two methods for warehouse data management: one is to split warehouse management functions into independent subsystems, such as inventory management, process approval, and material tracking. Each module uses a differentiated technology stack and achieves final data consistency through an event-driven architecture. However, this method has a long cross-system data synchronization link. For example, inventory changes need to be synchronized to the approval system and the warehouse system in sequence, which results in data delays, and concurrent operations are prone to conflicts. In addition, there are problems with high interface coupling and strong dependencies. The other method uses a single core system as the hub to build an integrated platform through vertical integration of functional modules. However, this method has rigid business adaptation and customized functions are difficult to support extremely differentiated needs. This leads to a decline in the overall system performance due to performance bottlenecks in some systems in extreme scenarios. In addition, the monolithic architecture is difficult to expand horizontally, which limits the scale of the system; the ecological compatibility is limited, which restricts technological innovation. It can be seen that how to improve data consistency between different library systems, solve the problems of high interface coupling and strong dependence, realize the separation of business and data processing, reduce the overall hardware pressure of the system, avoid the overall system performance degradation caused by performance bottlenecks of some systems in extreme scenarios, and effectively improve business development efficiency are problems that technical personnel in this field need to solve.

[0025] See also Figure 1 As shown, an embodiment of the present invention discloses a warehouse data management method, which is applied to a data aggregation center in a warehouse management system. The warehouse management system adopts a layered system architecture mode; wherein the method includes:

[0026] Step S11: Acquire the data to be managed from each warehouse house system in the warehouse management system; the data to be managed is data generated based on global data constraints, open annotation protocols, preset fields and telemetry data.

[0027] This application uses a preset layered construction method to construct a warehouse management system including a data collection layer, a data transmission layer, and a service layer; wherein the data collection layer includes the systems of each warehouse; the data transmission layer includes the data aggregation center; and the service layer includes the warehouse server. The specific warehouse management system structure is as follows Figure 2As shown in the figure, at the data collection layer, data reporting and reverse calling of business interfaces of each library system are realized through OTLP (OpenTelemetry Protocol, an open annotation protocol) and grpc (remote procedure call) interfaces. At the data transmission layer, a data aggregation center is provided for data reported by the OTLP protocol, and a data processing mechanism is introduced to perform preliminary data cleaning and data mapping. At the service layer, data persistence and data query interfaces for different businesses are realized.

[0028] In this embodiment, the open annotation protocol client is called to obtain the data to be managed generated based on global data constraints, open annotation protocols, preset fields and telemetry data from each warehouse house system in the warehouse management system; wherein, the generation process of the data to be managed includes: constructing global data constraints including version constraints, basic field constraints and extended rule constraints; determining the initial data to be managed based on the global data constraints and the open annotation protocol; and processing the initial data to be managed using preset fields and telemetry data to obtain the data to be managed.

[0029] The data collection layer in this application mainly includes three parts: global data convention: by establishing unified data semantics and format standards across systems, data conflicts and redundancies between heterogeneous systems are resolved; OTLP protocol as a unified data reporting standard: all subsystems are required to use OTLP protocol for data reporting while meeting the global data convention and the data convention of their respective extended subsystems; grpc interface definition: each subsystem exposes its business capabilities to the outside world through a standardized gRPC interface for other subsystems to call.

[0030] The core goal of the proposed global data constraints is to establish unified data semantics and format standards across systems and resolve data conflicts and redundancies between heterogeneous systems. Specifically, they include:

[0031] (1) Version constraints: Define the data model version number, such as data_schema_version: v1.2, to ensure compatibility. Under different version conventions, the higher version should be compatible with all fields under the lower version conventions. On this basis, if some fields are no longer supported in a certain version, the field and the minimum version that supports the field should be clearly identified in the version description.

[0032] (2) Basic field constraints: Basic fields are the minimum set of necessary fields required by each subsystem in warehouse management. All data descriptions in basic fields are consistent in each subsystem. In each warehouse system, if the system meets the global data convention under a certain version, then all data involved in reporting by the system should include all basic fields under the global data convention of that version; the necessary fields that all external interfaces involved in business operations of the system rely on cannot exceed the coverage of basic fields under the global data convention of that version. Basic fields can only be added when the global data convention version is updated and are fixed with the version.

[0033] (3) Extended rule constraints: Allow subsystems to add business-private fields based on global conventions, such as the department_code department code in ERP (Enterprise Resource Planning), but they must be isolated by prefixes, such as erp_department_code.

[0034] Among them, the process of processing the initial data to be managed includes: adding global agreed fields to the initial data to be managed; and, extending the subsystem private fields for the initial data to be managed; the subsystem private fields include system private attribute fields and business tag fields; determining the telemetry data under the open labeling protocol according to business needs; the telemetry data includes fields for representing the indicator name, description, unit and type, the life cycle of the traceable link, and structured log data; combining the telemetry data with the initial data to be managed after adding the fields to generate the data to be managed.

[0035] The protocol mandates that all subsystems report data via the OTLP protocol. Direct use of proprietary protocols such as HTTP (HyperText Transfer Protocol) and FTP (File Transfer Protocol) is prohibited. Furthermore, data must include both globally agreed fields and subsystem-private fields. In its implementation, the Shangku House system must add globally agreed fields to the initial OTLP data to be managed and extend subsystem-private fields based on subsystem business needs, such as status_type: in_house. These extended globally agreed fields and subsystem-private fields must meet global data constraints and the data conventions of the subsystem extensions.

[0036] Different warehouse systems can choose telemetry data under the OTLP protocol to meet the data requirements of different businesses. Telemetry data includes:

[0037] (1) Metrics: Indicates that a metric contains fields such as metric name, description, metric unit, and specific data type of metric data.

[0038] In a specific business scenario, taking the outbound delivery scenario as an example, when using metrics to report the outbound delivery quantity, you first need to supplement the "resource" field and add the necessary fields in the global specification. Secondly, supplement the "metrics" field with telemetry data such as the outbound delivery quantity. The example shown below describes the outbound delivery time statistical telemetry data (histogram) of the material outbound delivery service under the "v1.2" global specification. The "attributes" field of the telemetry data describes the material ID information as well as the "trace_id" and "span_id" associated with other subsystems / telemetry data:

[0039] {

[0040] "resource": {

[0041] "attributes": {

[0042] "service.name": "outbound-metrics",

[0043] "data_schema_version": "v1.2"

[0044] }

[0045] },

[0046] "metrics": [

[0047] {

[0048] "name": "outbound.process.duration",

[0049] "unit": "ms",

[0050] "description": "Outbound time statistics",

[0051] "histogram": {

[0052] "data_points": [

[0053] {

[0054] … / / Actual data fields

[0055] "attributes": {

[0056] "metrics_id": "SKU-2024-MBPR16",

[0057] "trace_id": "32a1b4c8d5e6f7a0", / / Key related fields

[0058] "span_id": "b4c8d5e6",

[0059] }

[0060] } ]

[0062] }

[0063] } ]

[0065] }.

[0066] In addition to the "histogram" structure in the processing example, Metrics also supports specific data as shown in Table 1:

[0067] Table 1 Specific data tables supported by Metrics

[0068]

[0069] (2) Trace: represents the complete life cycle of a traceable link. It consists of multiple spans and supports cross-service and cross-module. The link records the flow path of the request between different services and components. Span represents an independent operation or work unit, such as a process approval node. Different spans form a hierarchical structure through context (Context), forming a complete call chain. Context provides cross-service transmission of tracing information to ensure the integrity of the distributed link. Context contains a unique tracing identification field (trace id, which is shared by all spans in the same request), the unique identifier of the current span (span id) and the ID of the associated parent span. In addition, the business field can be extended in the additional information of the span to describe specific warehouse management business, such as changes in the status of warehouse materials.

[0070] In a specific business scenario, taking the sales order outbound scenario as an example, when using Trace to track material status, you first need to add the "resource" field, add the required fields in the global specification, and add the business description in the "spans" field. As shown in the following example, the process_sales_outbound main process, triggered after a sales order is generated, locks 10 pieces of inventory for SKU-2024-MBPR16 (reservation ID: RES-20240315-1892) at 14:25:15, creates an outbound order SO-20240315-00234, and associates it with the purchase acceptance batch (TraceId: 89f2e1a0b3c4d5e6). The packaging quality inspection subprocess then executes to verify product packaging compliance. The process completes in 4 minutes and 45 seconds, achieving a normal status and achieving a fully closed-loop system for inventory, procurement traceability, and quality control.

[0071] {

[0072] "resource": {

[0073] "attributes": {

[0074] "service.name": "outbound-metrics",

[0075] "data_schema_version": "v1.2"

[0076] }

[0077] },

[0078] "spans": [

[0079] {

[0080] "traceId": "32a1b4c8d5e6f7a0",

[0081] "spanId": "b4c8d5e6",

[0082] "name": "process_sales_outbound",

[0083] "parentSpanId": "a0b1c2d3", / / Parent Span (such as sales order generation)

[0084] "startTimeUnixNano": "2024-03-15T14:25:00Z",

[0085] "endTimeUnixNano": "2024-03-15T14:29:45Z",

[0086] "attributes": {

[0087] "item_id": "SKU-2024-MBPR16",

[0088] "outbound_order_no": "SO-20240315-00234",

[0089] "total_items": 10

[0090] },

[0091] "events":

[0092] {

[0093] "name": "inventory_lock",

[0094] "timeUnixNano": "2024-03-15T14:25:15Z",

[0095] "attributes": {

[0096] "locked_quantity": 10,

[0097] "reservation_id": "RES-20240315-1892"

[0098] }

[0099] }

[0100] ,

[0101] "links":

[0102] {

[0103] "traceId": "89f2e1a0b3c4d5e6", / / Associated purchase acceptance Trace

[0104] "spanId": "f2e1a0b3",

[0105] "attributes": {"reference_type": "purchase_validation"}

[0106] }

[0107] ],

[0108] "status": {

[0109] "code": "STATUS_CODE_OK"

[0110] }

[0111] },

[0112] / / Sub-Span: Packaging Quality Inspection

[0113] {

[0114] "traceId": "32a1b4c8d5e6f7a0",

[0115] "spanId": "c3d4e5f6",

[0116] "parentSpanId": "b4c8d5e6", / / points to the main Span

[0117] … / / Packaging quality inspection business fields ]

[0119] }.

[0120] (3) Log: Represents a structured log data. The log supports attributes in the form of key-value pairs rather than plain text, which facilitates subsequent retrieval and analysis. The fields included in the log data are shown in Table 2:

[0121] Table 2 Field table in log data

[0122]

[0123] When using Trace to track material status, you first need to add the "resource" field, add the required fields in the global specification, add the business description in the "body" field, and add the required business fields in the "attributes" field. As shown in the example, this describes a simple purchase material receipt approval business. In this business, "user-zhangsan" submits purchase receipt requisition IN-20240320-1122 for material MAT-2024-IC-001, requesting a quantity of 5,000 pieces. After going through the approval process described in the "approval_stages" field, the approval chain finally reaches the approved status, with an effective quantity of 5,000 pieces.

[0124] {

[0125] "resource": {

[0126] "attributes": {

[0127] "service.name": "inbound-approval",

[0128] "data_schema_version": "v1.2"

[0129] }

[0130] },

[0131] "body": "Material warehousing approval process completed - Final status: passed",

[0132] "attributes": {

[0133] "trace_id": "89f2e1a0b3c4d5e6", / / Full-link tracking identifier

[0134] "span_id": "d5e6f7a8", / / Current operation node identifier

[0135] "log_type": "approval_chain", / / Log classification

[0136] "log.severity": "INFO", / / Log level

[0137] / / Core business fields

[0138] "item_id": "MAT-2024-IC-001", / / Material number

[0139] "apply_no": "IN-20240320-1122", / / Warehousing application number

[0140] "apply_type": "purchase_inbound", / / Application type (purchase inbound)

[0141] "apply_quantity": 5000, / / application quantity

[0142] "applicant": "user-zhangsan", / / applicant

[0143] "approval_stages": [ … ], / / Approval process fields

[0144] "final_result": "approved", / / Approval result

[0145] "effective_quantity": 5000, / / actual effective quantity

[0146] "approval_end_time": "2024-03-20T10:30:00Z"

[0147] },

[0148] "timeUnixNano": "2024-03-20T10:30:00Z" / / Log generation time

[0149] }.

[0150] Step S12: Processing the data to be managed to obtain processed data; wherein the data processing includes standardization processing and address configuration operations.

[0151] In this embodiment, the data to be managed is standardized to obtain standardized data; the standardized data is address configured to obtain configured data; the configured data is cached and abnormal data is screened to obtain processed data.

[0152] In this embodiment, after the warehouse-house system generates the data to be managed, it is necessary to call OTLP-SDK (OTLP client) to obtain the data to be managed from the warehouse-house system. It is also necessary to configure the reporting address of the data to be managed. The specific configuration is shown below. The "endpoint" field in the configuration is the address of the data aggregation center.

[0153] exporters:

[0154] otlp:

[0155] endpoint: "http: / / collector-center:4318 / v1 / endpoint "

[0156] headers:

[0157] Authorization: " ${API_KEY}" # Authentication token (optional)

[0158] compression: "gzip" # Enable compression

[0159] timeout: 10s # Request timeout

[0160] retry_on_failure:

[0161] max_retries: 3 # Maximum number of retries

[0162] The data aggregation center also requires configuration for data reception, data processing, and data export. You need to expand the "receivers," "processors," and "exporters" fields in the configuration. In the data reception configuration, you need to specify the OTLP receiving protocol, such as HTTP / HTTPS, and the corresponding local listening port, as shown below:

[0163] receivers:

[0164] otlp:

[0165] protocols:

[0166] https: collector-center:4319 / v1 / endpoint

[0167] http: collector-center:4318 / v1 / endpoint

[0168] Data processing configuration can be selected as needed. As shown below, you can use the "batch" configuration to cache the data uploaded by the subsystem and process it in batches according to the configuration, thereby reducing the data processing pressure; you can also use the rules in the "filter" configuration to filter out abnormal data in the data uploaded by the subsystem.

[0169] processors:

[0170] batch:

[0171] timeout: 10s

[0172] send_batch_size: 1000

[0173] filter:

[0174] rules:

[0175] - type: "metric"

[0176] condition: "current_inventory >= 0" # Filter illegal inventory values

[0177] The data export configuration is similar to the subsystem data reporting configuration. The address of the receiving end needs to be specified. The configuration format remains consistent on the server side and is determined by the customized business interface.

[0178] Step S13: Configure the processed data based on the address of the warehouse server in the warehouse management system, export the configured processed data and send it to the warehouse server, so that the warehouse server can persistently store, associate business entities and visualize the configured processed data to complete the management of the management data.

[0179] In this embodiment, after the processed data is configured based on the address of the warehouse server in the warehouse management system, the configured processed data is exported and sent to the warehouse server, so that the warehouse server stores the configured processed data according to the preset persistent storage method to obtain the stored data, and associates the stored data with the business entity based on the fields in the stored data to obtain the associated data, and visualizes the associated data according to the preset visualization method.

[0180] In addition, after the processed data is configured based on the address of the warehouse server in the warehouse management system, it also includes: exporting the configured processed data and sending it to the warehouse server, so that the warehouse server can determine whether the associated data meets the preset conditions after obtaining the associated data. If the associated data meets the preset conditions, the warehouse automation management operation corresponding to the associated data is triggered.

[0181] Through the design of the data collection and data transmission layers, this application enables the specific business systems at the service layer to obtain standard OTLP data reported by different subsystems. Therefore, complex warehouse management tasks can be completed through customized development at the service layer. The following principles should be followed: simple and basic business functions should be decentralized to the warehouse system for implementation; business development should be driven by data.

[0182] In terms of specific implementation, a complete service layer application generally includes the following three parts:

[0183] (1) Persistent storage. The data of each library system is aggregated in the form of data reporting and then forwarded to each server application. Therefore, after the server receives the configured processed data exported by the data aggregation center, it should store the configured processed data persistently. Different data persistence methods can be selected for different reported data, such as using Redis (Remote Dictionary Server, an open source in-memory database) to store reported metrics data, and using MySQL (a relational database management system) to store reported trace data.

[0184] (2) Data association analysis. After persistence, different types of reported data need to be associated according to the global data specifications described in the "Data Collection and Standardization" section. Global fields such as warehouse ID (identity document, unique identification number) and material ID are used to uniquely associate reported data with business entities. For example, the material ID field in the reported inventory capacity indicator can be associated with the reported purchase order; the trace ID field in Trace can be used to connect cross-system operations and restore the entire business chain.

[0185] (3) Visualization and automation. Through visual charts and some customized automation rules, the related data can be displayed on the page. At the same time, when the data meets certain conditions, corresponding actions are triggered to realize the automation of warehouse management. Some typical business scenarios are shown in Table 3:

[0186] Table 3 Business scenario table

[0187]

[0188] In this embodiment, the structure of the data aggregation center is as follows: Figure 3 As shown, the core goal of data transmission and aggregation is to reliably transmit the managed data (metrics, trace, and logs) generated by each warehouse management subsystem to the data aggregation center and export it to different business servers. The subsystems generate standardized data through the OTLP client. The data aggregation center listens to the OTLP port through the OTLP collector and receives the managed data from the subsystems. The data aggregation center extends the processing and export interfaces of the OTLP collector to forward the configured processed data to different servers.

[0189] This application builds a multi-source data fusion architecture for warehouse management. By abstracting various warehouse systems (such as WMS, ERP, and IoT monitoring) into a data collection layer, it implements standardized cross-system data collection and transmission based on the OTLP protocol. At the data transmission and service layers, the OTLP protocol unifies data formats, supporting real-time reporting and structured storage of three core business data types: inventory changes, status tracking, and approval processes. This addresses the difficulty of data synchronization between different modules in a modular design, enabling centralized processing of business functions. This design, which separates data from business modules, effectively reduces business dependencies between modules.

[0190] In addition, during the reporting process from the data collection layer, encryption algorithms or transport layer security protocols can be used to encrypt the transmission of management data, such as SSL (Secure Sockets Layer) / TLS (Transport Layer Security), to ensure that data is not stolen or tampered with during transmission and storage. Furthermore, during data transmission, unexpected situations such as network congestion and signal interruption may occur. Therefore, reliable transmission mechanisms can be designed, such as breakpoint resume technology, which automatically resumes transmission of unfinished data from the last interruption point after a network interruption. At the same time, redundant transmission channels can be established so that when the main channel fails, the system can quickly switch to the backup channel to ensure uninterrupted data transmission.

[0191] This application enforces field formats and semantics through global data conventions, thereby improving data consistency between different warehouse and house systems. Compared with the modular design in which each system defines fields on its own, it greatly reduces data cleaning costs. Through standardized OTLP data formats and global data conventions, each warehouse and house system only needs to follow a unified protocol for independent development without having to worry about the internal implementation of other systems, solving the problem of high interface coupling in traditional modular design. The use of decentralized data collection and reporting and centralized aggregation not only realizes the separation of business and data processing, but also reduces the overall hardware pressure of the system, avoiding the overall system performance degradation caused by performance bottlenecks of some systems in extreme scenarios. On this basis, a data-driven approach can effectively improve the agility of business development, and standardized reported data directly drives automated services (such as inventory warnings automatically generating purchase orders). Compared with modular design, customized interface docking is required, which effectively improves business development efficiency.

[0192] In this embodiment, the data to be managed is obtained from each warehouse house system in the warehouse management system; the data to be managed is data generated based on global data constraints, open annotation protocols, preset fields and telemetry data; data processing is performed on the data to be managed to obtain processed data; wherein, the data processing includes standardization processing and address configuration operations; the processed data is configured based on the address of the warehouse server in the warehouse management system, and the configured processed data is exported and sent to the warehouse server, so that the warehouse server can perform persistent storage, business entity association and visual display on the configured processed data to complete the management of the data to be managed. This application obtains the data to be managed from each warehouse house system in the warehouse management system; the data to be managed is data generated based on global data constraints, open annotation protocols, preset fields and telemetry data, which improves the data consistency between different warehouse house systems, can greatly reduce data cleaning costs, and solve the problems of high interface coupling and strong dependence. The data to be managed is processed to obtain processed data, and the processed data is configured. The configured processed data is exported and sent to the warehouse server, so as to realize the separation of business and data processing, reduce the overall hardware pressure of the system, and avoid the overall system performance degradation caused by the performance bottleneck of some systems in extreme scenarios. The warehouse server is used to perform persistent storage, business entity association, and visualization of the configured processed data, which can effectively improve the agility and efficiency of business development.

[0193] See also Figure 4 As shown, an embodiment of the present invention discloses a warehouse data management device, which is applied to a data aggregation center in a warehouse management system. The warehouse management system adopts a layered system architecture mode; wherein the device includes:

[0194] The data acquisition module 11 is used to obtain the data to be managed from each warehouse system in the warehouse management system; the data to be managed is data generated based on global data constraints, open annotation protocols, preset fields and telemetry data;

[0195] The data processing module 12 is used to process the data to be managed to obtain processed data; wherein the data processing includes standardization processing and address configuration operations;

[0196] The data export module 13 is used to configure the processed data based on the address of the warehouse server in the warehouse management system, export the configured processed data and send it to the warehouse server, so that the warehouse server can perform persistent storage, business entity association and visual display on the configured processed data to complete the management of the management data.

[0197] In this embodiment, the data to be managed is obtained from each warehouse house system in the warehouse management system; the data to be managed is data generated based on global data constraints, open annotation protocols, preset fields and telemetry data; data processing is performed on the data to be managed to obtain processed data; wherein, the data processing includes standardization processing and address configuration operations; the processed data is configured based on the address of the warehouse server in the warehouse management system, and the configured processed data is exported and sent to the warehouse server, so that the warehouse server can perform persistent storage, business entity association and visual display on the configured processed data to complete the management of the data to be managed. This application obtains the data to be managed from each warehouse house system in the warehouse management system; the data to be managed is data generated based on global data constraints, open annotation protocols, preset fields and telemetry data, which improves the data consistency between different warehouse house systems, can greatly reduce data cleaning costs, and solve the problems of high interface coupling and strong dependence. The data to be managed is processed to obtain processed data, and the processed data is configured. The configured processed data is exported and sent to the warehouse server, so as to realize the separation of business and data processing, reduce the overall hardware pressure of the system, and avoid the overall system performance degradation caused by the performance bottleneck of some systems in extreme scenarios. The warehouse server is used to perform persistent storage, business entity association, and visualization of the configured processed data, which can effectively improve the agility and efficiency of business development.

[0198] In some specific embodiments, the data acquisition module 11 may specifically include:

[0199] The warehouse management system construction module is used to construct a warehouse management system including a data collection layer, a data transmission layer and a service layer using a preset layered construction method; wherein the data collection layer includes the house systems of each warehouse; the data transmission layer includes the data aggregation center; and the service layer includes the warehouse server.

[0200] In some specific embodiments, the data acquisition module 11 may specifically include:

[0201] The module for generating data to be managed is used to call the open annotation protocol client to obtain the data to be managed based on global data constraints, open annotation protocols, preset fields and telemetry data from each warehouse system in the warehouse management system;

[0202] Among them, the generation process of the data to be managed includes: constructing global data constraints including version constraints, basic field constraints and extended rule constraints; determining the initial data to be managed based on the global data constraints and open annotation protocols; using preset fields and telemetry data to process the initial data to be managed to obtain the data to be managed.

[0203] In some specific embodiments, the data acquisition module 11 may specifically include:

[0204] A global agreed field adding module is used to add global agreed fields to the initial data to be managed;

[0205] The subsystem private field extension module is used to extend the subsystem private fields for the initial data to be managed; the subsystem private fields include the system private attribute fields and the business tag fields;

[0206] The telemetry data determination module is used to determine telemetry data under the open annotation protocol based on business needs. Telemetry data includes fields used to represent the indicator name, description, unit, and type, the life cycle of the traceable link, and structured log data.

[0207] The data combining module is used to combine the telemetry data with the initial data to be managed after adding fields to generate the data to be managed.

[0208] In some specific embodiments, the data processing module 12 may specifically include:

[0209] A standardization processing module is used to perform standardization processing on the management data to obtain standardized data;

[0210] An address configuration module is used to perform address configuration on the standardized data to obtain configured data;

[0211] The cache processing and abnormal data screening module is used to cache the configured data and screen the abnormal data to obtain the processed data.

[0212] In some specific embodiments, the data export module 13 may specifically include:

[0213] The data export and sending module is used to export and send the configured processed data to the warehouse server, so that the warehouse server can store the configured processed data according to the preset persistent storage method to obtain the stored data, and associate the stored data with the business entity based on the fields in the stored data to obtain the associated data, and visualize the associated data according to the preset visualization method.

[0214] In some specific embodiments, the warehouse data management device may further include:

[0215] The automation management module is used to export the configured processed data and send it to the warehouse server, so that the warehouse server can determine whether the associated data meets the preset conditions after obtaining the associated data. If the associated data meets the preset conditions, the warehouse automation management operation corresponding to the associated data is triggered.

[0216] Among them, the description of the features in the embodiment corresponding to the warehouse data management device can refer to the relevant description of the embodiment corresponding to the server communication method, and will not be repeated here.

[0217] An embodiment of the present application further provides an electronic device, comprising a memory and a processor, wherein the memory stores a computer program, and the processor is configured to run the computer program to execute the steps in any of the above-mentioned warehouse data management method embodiments.

[0218] An embodiment of the present application further provides a computer-readable storage medium, in which a computer program is stored, wherein the computer program is configured to execute the steps of any of the above-mentioned warehouse data management method embodiments when running.

[0219] In an exemplary embodiment, the computer-readable storage medium may include, but is not limited to, various media that can store computer programs, such as a USB flash drive, a read-only memory (ROM), a random access memory (RAM), a mobile hard disk, a magnetic disk, or an optical disk.

[0220] An embodiment of the present application further provides a computer program product, which includes a computer program. When the computer program is executed by a processor, the steps of any of the above-mentioned warehouse data management method embodiments are implemented.

[0221] Professionals may further appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of the two. In order to clearly illustrate the interchangeability of hardware and software, the above description has generally described the components and steps of each example according to their functions. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professionals and technicians may use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0222] The above is a detailed introduction to the warehouse data management method, device, equipment and medium provided by the present application. This article uses specific examples to illustrate the principles and implementation methods of the present application. The description of the above embodiments is only used to help understand the method and core ideas of the present application. It should be pointed out that for ordinary technicians in this technical field, without departing from the principles of the present application, several improvements and modifications can be made to the present application, and these improvements and modifications also fall within the scope of protection of the claims of the present application.

Claims

1. A warehouse data management method, characterized in that: A data aggregation center is used in a warehouse management system, wherein the warehouse management system adopts a layered system architecture mode; wherein the method includes: Acquire the data to be managed from each warehouse house system in the warehouse management system; the data to be managed is data generated based on global data constraints, open annotation protocols, preset fields and telemetry data; Performing data processing on the data to be managed to obtain processed data; wherein the data processing includes standardization processing and address configuration operations; The processed data is configured based on the address of the warehouse server in the warehouse management system, and the configured processed data is exported and sent to the warehouse server, so that the warehouse server can persistently store, associate business entities, and visualize the configured processed data to complete the management of the data to be managed; Obtaining data to be managed from each warehouse house system in the warehouse management system, including: calling an open annotation protocol client to obtain data to be managed generated based on global data constraints, the open annotation protocol, preset fields, and telemetry data from each warehouse house system in the warehouse management system; wherein the process of generating the data to be managed includes: constructing global data constraints including version constraints, basic field constraints, and extended rule constraints; determining initial data to be managed based on the global data constraints and the open annotation protocol; and processing the initial data to be managed using the preset fields and telemetry data to obtain the data to be managed; The initial data to be managed is processed using preset fields and telemetry data to obtain the data to be managed, including: adding a global agreed field to the initial data to be managed; and extending the subsystem private field for the initial data to be managed; the subsystem private field includes a system private attribute field and a business tag field; the telemetry data under the open labeling protocol is determined according to business needs; the telemetry data includes fields for representing the indicator name, description, unit and type, the life cycle of the traceable link, and structured log data; the telemetry data is combined with the initial data to be managed after the fields are added to generate the data to be managed.

2. The warehouse data management method according to claim 1, characterized in that: Before acquiring the data to be managed from each warehouse house system in the warehouse management system, the method further includes: A warehouse management system including a data collection layer, a data transmission layer and a service layer is constructed using a preset layered construction method; wherein the data collection layer includes the house systems of each warehouse; the data transmission layer includes a data aggregation center; and the service layer includes a warehouse service end.

3. The warehouse data management method according to claim 1, characterized in that: The processing of the data to be managed to obtain processed data includes: Performing standardization processing on the data to be managed to obtain standardized data; Performing address configuration on the standardized data to obtain configured data; The configured data is cached and abnormal data is screened to obtain processed data.

4. The warehouse data management method according to any one of claims 1 to 3, characterized in that: The configured processed data is exported and sent to the warehouse server so that the warehouse server performs persistent storage, business entity association, and visual display on the configured processed data, including: The configured processed data is exported and sent to the warehouse server, so that the warehouse server stores the configured processed data according to the preset persistent storage method to obtain stored data, and associates the stored data with the business entity based on the fields in the stored data to obtain associated data, and visualizes the associated data according to the preset visualization method.

5. The warehouse data management method according to claim 4, characterized in that: Also includes: The processed data after configuration is exported and sent to the warehouse server, so that after obtaining the associated data, the warehouse server can determine whether the associated data meets the preset conditions. If the associated data meets the preset conditions, the warehouse automation management operation corresponding to the associated data is triggered.

6. A warehouse data management device, characterized in that: The device is applied to a data aggregation center in a warehouse management system, wherein the warehouse management system adopts a layered system architecture mode; wherein the device includes: A data acquisition module is used to acquire the data to be managed from each warehouse system in the warehouse management system; the data to be managed is data generated based on global data constraints, open annotation protocols, preset fields and telemetry data; A data processing module, configured to process the data to be managed to obtain processed data; wherein the data processing includes standardization processing and address configuration operations; A data export module is used to configure the processed data based on the address of the warehouse server in the warehouse management system, export the configured processed data, and send it to the warehouse server, so that the warehouse server can perform persistent storage, business entity association, and visual display on the configured processed data to complete the management of the data to be managed; Obtaining data to be managed from each warehouse house system in the warehouse management system, including: calling an open annotation protocol client to obtain data to be managed generated based on global data constraints, the open annotation protocol, preset fields, and telemetry data from each warehouse house system in the warehouse management system; wherein the process of generating the data to be managed includes: constructing global data constraints including version constraints, basic field constraints, and extended rule constraints; determining initial data to be managed based on the global data constraints and the open annotation protocol; and processing the initial data to be managed using the preset fields and telemetry data to obtain the data to be managed; The initial data to be managed is processed using preset fields and telemetry data to obtain the data to be managed, including: adding a global agreed field to the initial data to be managed; and extending the subsystem private field for the initial data to be managed; the subsystem private field includes a system private attribute field and a business tag field; the telemetry data under the open labeling protocol is determined according to business needs; the telemetry data includes fields for representing the indicator name, description, unit and type, the life cycle of the traceable link, and structured log data; the telemetry data is combined with the initial data to be managed after the fields are added to generate the data to be managed.

7. An electronic device, characterized in that: include: memory for storing computer programs; A processor is configured to implement the steps of the warehouse data management method according to any one of claims 1 to 5 when executing the computer program.

8. A computer-readable storage medium, characterized in that The computer-readable storage medium stores a computer program, wherein the computer program, when executed by a processor, implements the steps of the warehouse data management method according to any one of claims 1 to 5.

Images