Industrial product supply order logistics data processing method and system based on Java

Abstract

The invention relates to the technical field of industrial product e-commerce supply chain management, in particular to a Java-based industrial product supply order logistics data processing method and system, and the method comprises the following steps: S1, obtaining industrial product supply order logistics data packets from multiple suppliers; s2, based on an initial processing intention, injecting the logistics data packet into a pre-configured corresponding data flow pipeline; s3, in the data flow pipeline, the logistics data packet is driven to flow through at least one processing node in sequence, the current processing node executes a corresponding data processing action based on a processing intention carried by the logistics data packet, and after execution is completed, the content of the logistics data packet is updated based on a processing result, and a next processing intention is determined; according to the processing priority identification and the priority distinguishing mechanism, processing resources of high-priority services can be guaranteed preferentially, and it is ensured that when the load is high, the processing efficiency and response time of key services are met.

Description

Technical Field

[0001] This invention relates to the field of industrial e-commerce supply chain management technology, specifically to a Java-based method and system for processing industrial product supply order logistics data. Background Technology

[0002] In the industrial e-commerce and MRO (maintenance, repair, and operation) supply chain sectors, order fulfillment typically involves collaboration among multiple suppliers, and there are often complex scenarios where the same order needs to be shipped in batches due to the variety of product specifications and inventory locations. As the business grows, the logistics network needs to cover a massive number of domestic logistics providers and some cross-border logistics services, resulting in a multi-source and heterogeneous logistics data environment.

[0003] Existing order logistics data processing systems typically employ a centralized microservice architecture or modular design. Their typical processing pattern is as follows: after the supplier enters shipping information through an interface, the system processes it sequentially through a series of hard-coded business logic chains. For example, it first verifies the data, then calls a fixed logistics query interface, and finally pushes the results to downstream systems such as enterprise resource planning. This implementation method has several inherent drawbacks: Business process logic is embedded in the program code. When it is necessary to add a new logistics type (such as adding a specific cross-border route), adjust the processing order (such as adding tariff estimates before tracking), or connect to a new downstream system, the core code must be modified and tested. This results in a long development cycle, high risk, and an inability to quickly respond to business changes.

[0004] When multiple suppliers operate on the same order simultaneously, the lack of fine-grained data permissions and operational pipeline isolation mechanisms can easily lead to logistics data being accidentally overwritten or double-counted, affecting data consistency and accuracy.

[0005] For situations such as failed logistics queries, network timeouts, and abnormal status, simple retries or unified alarms are usually used. There is a lack of differentiated and automated degradation processing strategies based on failure scenarios, which leads to fault recovery relying on manual intervention and delayed response.

[0006] When handling mixed business flows that are primarily domestic and secondarily cross-border, it is difficult to dynamically and differentiate the allocation of processing resources (such as computing resources and message queue consumption speed) based on business priorities (such as the higher timeliness requirements of domestic logistics), which may result in high-priority businesses being blocked by low-priority businesses. Summary of the Invention

[0007] This invention addresses the technical problems existing in the prior art by providing a Java-based method and system for processing logistics data in industrial product supply orders.

[0008] The technical solution of this invention to solve the above-mentioned technical problems is as follows: A Java-based method for processing industrial product supply order logistics data, comprising the following steps: S1. Obtain logistics data packages for industrial product supply orders from multiple suppliers; S2. Based on the initial processing intent, inject the logistics data packet into the pre-configured corresponding data flow pipeline; S3. In the data flow pipeline, the logistics data packets are driven sequentially through at least one processing node, wherein the current processing node performs the corresponding data processing action based on the processing intent carried by the logistics data packets, and after the execution is completed, the content of the logistics data packets is updated based on the processing result and the next processing intent is determined. S4. When the processing intent indicated by the logistics data packet ends, the encapsulated processing result is output to the designated downstream business processing unit.

[0009] In a preferred embodiment, in step S1, the logistics data packet encapsulates: Data packet header: includes a globally unique identifier for the logistics data packet, a source system identifier for identifying the data source supplier, a timestamp of when the logistics data packet was received, and a processing priority identifier preset according to business rules; Data body: includes an order identifier that uniquely identifies the order, a logistics tracking number provided by the logistics service provider, a shipment batch identifier used to distinguish different shipment batches under the same order, a standardized logistics service provider code, and a logistics type identifier used to distinguish between domestic logistics and cross-border logistics; The data packet tail includes the initial processing intent determined by the source system identifier and the logistics type identifier, a sequence of processed nodes that have been processed and are initially empty, used to record the historical processing path of the logistics data packet, and an abnormal status identifier that is initially in a normal state and used to mark whether an abnormality has occurred during the processing.

[0010] In a preferred embodiment, in step S2, based on the type of initial processing intent recorded at the end of the data packet in the logistics data packet, the logistics data packet is assigned to a data flow channel corresponding to the type of initial processing intent, wherein the type of initial processing intent belongs to any of the following, and each type is associated with a data flow channel with a specific processing function: The first type of intent is to associate the data flow pipeline used to perform data validation and format standardization processing. The second type of intent is associated with the data flow pipeline used to perform logistics trajectory query and status code mapping processing; The third type of intent is associated with the data flow pipeline used to perform logistics anomaly detection and early warning message triggering. The fourth type of intent is to associate data flow channels used to perform data synchronization processes with external associated systems; The fifth type of intent is associated with data flow pipelines used to indicate the end of a processing flow; Once the allocation is complete, the logistics data packet is injected into the associated data flow pipeline.

[0011] In a preferred embodiment, in step S3, in the data flow pipeline, the data packets are sequentially driven through at least one processing node, and for the current processing node, the following operations are performed: Read the current processing intent recorded in the tail of the logistics data packet and execute the data processing action corresponding to that intent type; After the data processing action is completed, the business data content of the logistics data package is updated according to the execution result status of the data processing action. The execution result status includes successful execution status, partial success status, or failed execution status. Based on the type of the current processing intent and the execution result status, the next processing intent is determined through predefined logical conditions, and the next processing intent is updated in the current processing intent record at the end of the logistics data packet. The predefined logical conditions are as follows: if the current processing intent is a type 1 intent and the execution result status is a successful execution status, then the next processing intent is determined to be a type 2 intent; if the current processing intent is a type 2 intent and the execution result status is a successful execution status, then the next processing intent is determined to be a type 3 intent. If the execution result status of the data processing action is a failure execution status, then perform the following operations: Set the abnormal status flag in the tail of the logistics data packet to the specific abnormal status value that represents the failure, and record the failure reason information in the logistics data packet. Based on the failure reason information and the type of the current processing intention, a predefined degradation intention is determined by judging the predefined degradation conditions, and the current processing intention recorded in the tail of the logistics data packet is replaced with the degradation intention. The predefined degradation conditions are as follows: if the current processing intention is a second type of intention and the failure reason information is that the logistics trajectory query interface timed out, then the degradation intention is determined to be the intention to transfer to manual handling; if the current processing intention is a first type of intention and the failure reason information is that the data format is incorrect, then the degradation intention is determined to be the intention to transfer to basic verification. Logistics data packets carrying downgrade intent and anomaly status indicators will be injected into backup data flow channels pre-associated with the downgrade intent or directly assigned to manual handling nodes.

[0012] In a preferred embodiment, in step S4, when the current processing intent carried by the logistics data packet is identified as a fifth type of intent, the final business data in the logistics data packet body is extracted, and the final business data is converted into output data that meets the corresponding interface requirements according to the interface data specification of a predetermined downstream business processing unit. The converted output data is sent to the corresponding downstream business processing unit by calling the application programming interface provided by the downstream business processing unit or by submitting it to the corresponding message queue.

[0013] This invention also provides a Java-based industrial product supply order logistics data processing system, comprising: Data receiving module: Acquires logistics data packets for industrial product supply orders from multiple suppliers; Pipeline configuration module: Based on the initial processing intent, inject the logistics data packet into the pre-configured corresponding data flow pipeline; Pipeline scheduling module: In the data flow pipeline, the logistics data packets are driven sequentially through at least one processing node, wherein the current processing node performs the corresponding data processing action based on the processing intention carried by the logistics data packet, and after the execution is completed, the content of the logistics data packet is updated based on the processing result and the next processing intention is determined. Intent Management Module: When the processing intent indication process carried by the logistics data packet ends, the encapsulated processing result is output to the designated downstream business processing unit.

[0014] The beneficial effects of this invention are as follows: By encapsulating the logistics data of each order into a logistics data packet and processing it based on the source identifier and processing intent, this invention establishes a logically isolated parallel processing channel for data from different suppliers, achieving full traceability of the operation process, avoiding data conflicts and unauthorized operations, and ensuring the security of data processing in a multi-supplier environment. When a processing node fails, it can automatically switch the process to a degraded intent and backup data flow pipeline or a manual handling node based on the specific failure reason information and preset rules, ensuring that local failures do not lead to the interruption of the overall business process, improving business continuity. Based on the processing priority identifier and priority differentiation mechanism, it can prioritize the processing resources of high-priority businesses, ensuring that the processing efficiency and response time of critical businesses are met when the load is high, and realizing intelligent resource scheduling guided by business value. Attached Figure Description

[0015] Figure 1 This is a flowchart of the method of the present invention; Figure 2 This is a system block diagram of the present invention. Detailed Implementation

[0016] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0017] In the description of this application, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of the stated features. In the description of this application, "multiple" means two or more, unless otherwise explicitly specified.

[0018] In the description of this application, the term "for example" is used to mean "used as an example, illustration, or description." Any embodiment described as "for example" in this application is not necessarily to be construed as being more preferred or advantageous than other embodiments. The following description is provided to enable any person skilled in the art to make and use the invention. Details are set forth in the following description for purposes of explanation. It should be understood that those skilled in the art will recognize that the invention can be made without using these specific details. In other instances, well-known structures and processes will not be described in detail to avoid obscuring the description of the invention with unnecessary detail. Therefore, the invention is not intended to be limited to the embodiments shown, but is consistent with the broadest scope of the principles and features disclosed in this application.

[0019] like Figure 1 This embodiment provides a Java-based method for processing logistics data in industrial product supply orders, including the following steps: S1. Obtain logistics data packages for industrial product supply orders from multiple suppliers; Furthermore, in S1, the logistics data packet encapsulates: Data packet header: includes a globally unique identifier for the logistics data packet, a source system identifier for identifying the data source supplier, a timestamp of when the logistics data packet was received, and a processing priority identifier preset according to business rules; Data body: includes an order identifier that uniquely identifies the order, a logistics tracking number provided by the logistics service provider, a shipment batch identifier used to distinguish different shipment batches under the same order, a standardized logistics service provider code, and a logistics type identifier used to distinguish between domestic logistics and cross-border logistics; The data packet tail includes the initial processing intent determined by the source system identifier and the logistics type identifier, a sequence of processed nodes that have been processed and are initially empty, used to record the historical processing path of the logistics data packet, and an abnormal status identifier that is initially in a normal state and used to mark whether an abnormality has occurred during the processing.

[0020] S1 acquires raw logistics information regarding industrial product supply orders submitted by various supplier systems and encapsulates this information into a structured logistics data packet. The encapsulation process adds specific metadata and process control information, enabling the data packet to be autonomously identified, routed, and processed. The source identifier uniquely distinguishes the data provider within the system, forming the basis for multi-supplier data isolation and access control. Logistics business data is the core information carrier to be processed, and the initial processing intent serves as the initial instruction driving the data packet into a specific processing flow, determining the primary flow and processing target of the data packet within the system. The constructed logistics data packet's header provides global management and routing information for the entire data packet. The globally unique identifier is used to assign a unique identity to each data packet throughout its entire system lifecycle. The source system identifier corresponds to the step source identifier and serves as an input parameter for supplier authorization verification, data traceability, and the application of differentiated strategies. The timestamp of entering the system records the precise moment the data packet was received, providing a time reference for calculating processing timeliness, determining whether a timeout has occurred, and monitoring and early warning based on time windows. The processing priority identifier is a preset system parameter whose value is pre-set according to business rules (for example, expedited orders and domestic logistics services can be given higher priority). This identifier directly affects the scheduling order of data packets in the data flow pipeline, ensuring that critical business processes receive priority processing resources. The data packet body of the logistics data packet is the object of operation for all data processing actions. The order identifier serves as the core index, associating logistics data with specific supply orders to ensure that data processing is always carried out within the correct order context. The logistics tracking number and logistics service provider code are the core key-value pairs for querying logistics tracks, jointly and uniquely identifying a physical transportation record in a specific logistics service provider system. The shipment batch identifier is used to support business scenarios where the same order is shipped in batches, enabling the differentiation and management of different logistics batches under the same order. The logistics type identifier is used to clearly distinguish whether the data packet belongs to domestic logistics or cross-border logistics. The tail portion of the logistics data packet is the core of achieving intent-driven and process observability. The current processing intent is the state instruction of the data packet at any moment in the process. It is dynamically updated as the data packet flows through each processing node, determining the real-time flow direction of the data packet. The sequence of processing nodes that have been passed through completely records all the processing steps that the data packet has undergone from entering the system to its current state in the form of an ordered list. This sequence provides a complete path log for process tracing, performance analysis, and problem localization and rollback when anomalies occur. The anomaly status identifier is a binary or multi-valued status flag used to mark whether an anomaly has occurred in the data packet during processing (such as verification failure or interface call timeout). Setting it will trigger specific fault-tolerant processing logic. The packet tail information, together with the packet header and packet body, constitute a data unit, enabling the data packet to flow autonomously in the pipeline network and complete processing based on the information it carries, without a central controller.

[0021] S2. Based on the initial processing intent, inject the logistics data packet into the pre-configured corresponding data flow pipeline; In step S2, based on the type of initial processing intent recorded at the end of the data packet in the logistics data packet, the logistics data packet is assigned to a data flow channel corresponding to the type of initial processing intent. The type of initial processing intent belongs to any of the following categories, and each type is associated with a data flow channel with a specific processing function: The first type of intent is to associate the data flow pipeline used to perform data validation and format standardization processing. The second type of intent is associated with the data flow pipeline used to perform logistics trajectory query and status code mapping processing; The third type of intent is associated with the data flow pipeline used to perform logistics anomaly detection and early warning message triggering. The fourth type of intent is to associate data flow channels used to perform data synchronization processes with external associated systems; The fifth type of intent is associated with data flow pipelines used to indicate the end of a processing flow; Once the allocation is complete, the logistics data packet is injected into the associated data flow pipeline.

[0022] In S2, the first type of intent provides a standardized data foundation for all subsequent processing. When the initial processing intent of the logistics data packet is identified as the first type of intent, the primary task of the pipeline into which the logistics data packet is injected is to perform data verification and format standardization processing. Data verification targets the core business data in the data packet body, such as verifying the compliance of the logistics tracking number format, whether the shipment quantity does not exceed the remaining order quantity, and whether the HS code and declared value required for cross-border logistics are filled in according to preset rules. Format standardization converts heterogeneous data from different suppliers or logistics service providers into a unified predetermined format. The output of the processing node that executes the first type of intent is a data packet that has passed verification and has a unified format. At the same time, the successful execution of the processing node of the first type of intent will determine and update the processing intent of the data packet (e.g., change it to the second type of intent), thereby driving the data packet to flow into the next processing stage. The second type of intent is to proactively acquire the status information of physical logistics goods to achieve logistics visualization. When a data packet carries the second type of intent, it will be routed to the processing node responsible for external interface calls. The processing node initiates a query request to the corresponding third-party logistics platform application interface based on the standardized logistics service provider code and logistics tracking number in the data packet body to obtain the original logistics trajectory and status code. Subsequently, the processing node performs status code mapping processing, mapping the status code returned by the third-party platform to an internally unified predetermined status identifier. Then, based on the acquired trajectory information (such as the latest trajectory time) and the mapped status, it determines whether anomaly detection is required, thereby updating the data packet intent to the third type of intent. The third type of intent is to perform automated risk monitoring and early warning. The corresponding processing node will analyze the current logistics status based on preset anomaly judgment rules (for example, if the domestic logistics trajectory has not been updated for more than 12 hours, it is judged as a delay anomaly). Once it is determined that the anomaly conditions are met, the processing node will trigger the generation and sending of an early warning message, completing the initial response to the anomaly. The fourth type of intent is to achieve data closure and business linkage within the enterprise. When a data packet (e.g., one that has completed a trajectory query and is in normal condition or has been processed for anomalies) carries the fourth type of intent, it will be injected into the processing pipeline. The corresponding processing nodes will generate a synchronization message that conforms to the interface specification of the target (e.g., an Enterprise Resource Planning (ERP) system or a Customer Relationship Management (CRM) system) based on all the processing results in the data packet (e.g., order number, latest logistics status, and shipment quantity), and execute the sending action. This ensures that changes in logistics status can promptly drive downstream business such as inventory updates, financial settlements, or sales follow-ups. The fifth type of intent declares and completes the end of a data processing lifecycle. When all necessary processing of the data packet has been completed, the intent of the data packet is updated to the fifth type of intent. The data packet carrying the fifth type of intent is injected into the final processing pipeline. The corresponding nodes perform process archiving operations, storing it in the historical database for future reference. Then, the processing resources occupied by the data packet are released, marking the formal end of the coordination process for the logistics data packet.

[0023] S3. In the data flow pipeline, the logistics data packets are driven sequentially through at least one processing node, wherein the current processing node performs the corresponding data processing action based on the processing intent carried by the logistics data packets, and after the execution is completed, the content of the logistics data packets is updated based on the processing result and the next processing intent is determined. Furthermore, in step S3, in the data flow pipeline, the data packets are sequentially driven through at least one processing node, and for the current processing node, the following operations are performed: Read the current processing intent recorded in the tail of the logistics data packet and execute the data processing action corresponding to that intent type; After the data processing action is completed, the business data content of the logistics data package is updated according to the execution result status of the data processing action. The execution result status includes successful execution status, partial success status, or failed execution status. Based on the type of the current processing intent and the execution result status, the next processing intent is determined through predefined logical conditions, and the next processing intent is updated in the current processing intent record at the end of the logistics data packet. The predefined logical conditions are as follows: if the current processing intent is a type 1 intent and the execution result status is a successful execution status, then the next processing intent is determined to be a type 2 intent; if the current processing intent is a type 2 intent and the execution result status is a successful execution status, then the next processing intent is determined to be a type 3 intent. If the execution result status of the data processing action is a failure execution status, then perform the following operations: Set the abnormal status flag in the tail of the logistics data packet to the specific abnormal status value that represents the failure, and record the failure reason information in the logistics data packet. Based on the failure reason information and the type of the current processing intention, a predefined degradation intention is determined by judging the predefined degradation conditions, and the current processing intention recorded in the tail of the logistics data packet is replaced with the degradation intention. The predefined degradation conditions are as follows: if the current processing intention is a second type of intention and the failure reason information is that the logistics trajectory query interface timed out, then the degradation intention is determined to be the intention to transfer to manual handling; if the current processing intention is a first type of intention and the failure reason information is that the data format is incorrect, then the degradation intention is determined to be the intention to transfer to basic verification. Logistics data packets carrying downgrade intent and anomaly status indicators will be injected into backup data flow channels pre-associated with the downgrade intent or directly assigned to manual handling nodes.

[0024] In S3, based on the processing node sequence defined in the data flow pipeline, the logistics data packets are driven sequentially from one processing node to the next. Each processing node is the smallest execution unit encapsulating a specific function. Upon arrival at the current processing node, the node reads the current processing intent recorded at the end of the logistics data packet. The current processing intent specifies the specific task that the node should complete in this stage (e.g., verification, query, or detection). The node executes the data processing action corresponding to the type of the current processing intent. After the action is completed, the node updates the business data content in the data packet body according to the execution result status (success, partial success, or failure), such as filling in the queried logistics trajectory or marking the abnormal status. Finally, the node determines the direction of the subsequent process based on the type of the current processing intent and the execution result status through predefined logical conditions. For example, if the current processing intent is the first type of intent (data verification) and the execution result status is successful, then the next processing intent is determined to be the second type of intent. After the next processing intent is determined, it is updated to the end of the data packet, thus providing a clear instruction for the data packet to enter the next processing node in the pipeline. If the data processing action of the current processing node fails (i.e., the execution result status is a failed execution status), the process is transferred to the exception handling process. The exception status identifier in the end of the data packet is set to a specific value representing the failure (e.g., interface failure), and the failure reason information is recorded in detail (e.g., logistics trajectory query interface timeout) to complete the marking and retention of fault diagnosis information. Then, based on the recorded failure reason information and the type of the current processing intent, a predefined degradation condition judgment rule is applied to determine a preset degradation intent for handling this type of failure scenario. For example, the rule can be defined as: if the current processing intent is the second type of intent (trajectory query) and the failure reason is interface timeout, then the degradation intent is determined to be the intention to transfer to manual handling. After determination, the original current processing intent of the data packet is replaced with the degradation intent. The data packet carrying the degradation intent and exception identifier is injected into the backup data flow channel pre-associated with the degradation intent or directly assigned to the manual handling node.

[0025] S4. When the processing intent indicated by the logistics data packet ends, the encapsulated processing result is output to the designated target business system.

[0026] Furthermore, in S4, when the current processing intent carried by the logistics data packet is identified as a fifth type of intent, the final business data in the logistics data packet body is extracted, and the final business data is converted into output data that meets the corresponding interface requirements according to the interface data specification of a predetermined downstream business processing unit. The interface data specification is predefined and is used to specify the set of rules for the data structure, field name, field type and encoding format that must be followed when sending data to the target business system. The converted output data is sent to the corresponding downstream business processing unit by calling the application programming interface provided by the downstream business processing unit or by submitting it to the corresponding message queue.

[0027] In the data flow pipeline, the configuration information of a data flow pipeline includes at least a unique pipeline identifier and a node sequence arranged in a pre-ordered manner, consisting of at least one processing node identifier. The node sequence defines the flow path of the logistics data packet within the data flow pipeline. Within a data flow pipeline, a predefined correspondence exists between a processing intent type and a processing node identifier. This correspondence is used to determine the next processing node identifier to be executed within the same pipeline, based on the updated processing intent type of the logistics data packet, after the current processing node has completed its task.

[0028] like Figure 2 The present invention also provides a Java-based industrial product supply order logistics data processing system, comprising: Data receiving module: Acquires logistics data packets for industrial product supply orders from multiple suppliers; Pipeline configuration module: Based on the initial processing intent, inject the logistics data packet into the pre-configured corresponding data flow pipeline; Pipeline scheduling module: In the data flow pipeline, the logistics data packets are driven sequentially through at least one processing node, wherein the current processing node performs the corresponding data processing action based on the processing intention carried by the logistics data packet, and after the execution is completed, the content of the logistics data packet is updated based on the processing result and the next processing intention is determined. Intent Management Module: When the processing intent indication process carried by the logistics data packet ends, the encapsulated processing result is output to the designated downstream business processing unit.

[0029] It should be noted that the descriptions of each embodiment in the above embodiments have different focuses. For parts that are not described in detail in a certain embodiment, please refer to the relevant descriptions in other embodiments.

[0030] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0031] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0032] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0033] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0034] Although preferred embodiments of the invention have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including both the preferred embodiments and all changes and modifications falling within the scope of the invention.

[0035] Obviously, those skilled in the art can make various modifications and variations to this invention without departing from its spirit and scope. Therefore, if these modifications and variations fall within the scope of the claims of this invention and their equivalents, this invention also intends to include these modifications and variations.

Claims

1. A Java-based industrial product supply order logistics data processing method, characterized by, The method comprises the following steps: S1, obtaining an industrial product supply order logistics data packet from a plurality of suppliers; S2, based on an initial processing intention, injecting the logistics data packet into a pre-configured corresponding data flow pipeline; S3, in the data flow pipeline, sequentially driving the logistics data packet to flow through at least one processing node, wherein the current processing node performs a corresponding data processing action based on the processing intention carried by the logistics data packet, and after the execution is completed, updates the content of the logistics data packet based on the processing result and determines the next processing intention; S4, when the processing intention carried by the logistics data packet indicates the end of the process, the processing result encapsulated is output to the designated downstream business processing unit.

2. The Java-based industrial product supply order logistics data processing method according to claim 1, characterized by, In S1, the logistics data packet is encapsulated with: a packet header including a globally unique identifier of the logistics data packet, a source system identifier for identifying the data source supplier, a timestamp when the logistics data packet is received, and a processing priority identifier preset according to business rules; a packet body including an order identifier for uniquely identifying an order, a logistics tracking number provided by a logistics service provider, a shipment batch identifier for distinguishing different shipment batches under the same order, a standardized logistics service provider code, and a logistics type identifier for distinguishing domestic logistics from cross-border logistics; a packet tail including an initial processing intention determined according to the source system identifier and the logistics type identifier, a sequence of processing nodes that has been passed and is initially empty for recording the history processing path of the logistics data packet, and an abnormal state identifier initially in a normal state for marking whether an exception occurs in the processing process.

3. The Java-based industrial product supply order logistics data processing method according to claim 1, characterized by, In S2, based on the type of the initial processing intention recorded in the packet tail of the logistics data packet, the logistics data packet is assigned to a data flow pipeline corresponding to the type of the initial processing intention, wherein the type of the initial processing intention belongs to any one of the following types, and each type is associated with a type of data flow pipeline having a specific processing function: a first type of intention associated with a data flow pipeline for performing data verification and format standardization processing; a second type of intention associated with a data flow pipeline for performing logistics track query and state code mapping processing; a third type of intention associated with a data flow pipeline for performing logistics exception detection and early warning message triggering processing; a fourth type of intention associated with a data flow pipeline for performing data synchronization to an external associated system; a fifth type of intention associated with a data flow pipeline for indicating the termination of the processing flow; After the assignment is completed, the logistics data packet is injected into the associated data flow pipeline.

4. The Java-based industrial product supply order logistics data processing method according to claim 1, characterized by, In S3, in the data flow pipeline, the logistics data packet is sequentially driven to flow through at least one processing node, and for the current processing node, the following operations are performed: read the current processing intention recorded in the logistics data packet tail, and perform the data processing action corresponding to the intention type; after the data processing action is executed, update the business data content of the logistics data packet body according to the execution result state of the data processing action, wherein the execution result state includes a successful execution state, a partial success state or a failed execution state; According to the type of the current processing intention and the execution result state, a next processing intention is determined through a predefined logical condition judgment, and the next processing intention is updated to the current processing intention record at the tail of the logistics data packet.

5. The Java-based industrial product supply order logistics data processing method according to claim 4, characterized by, The predefined logical condition judgment is that if the current processing intention is the first type of intention and the execution result state is a successful execution state, the next processing intention is determined to be the second type of intention, and if the current processing intention is the second type of intention and the execution result state is a successful execution state, the next processing intention is determined to be the third type of intention.

6. The Java-based industrial product supply order logistics data processing method according to claim 4, characterized by, If the execution result state of the data processing action is a failed execution state, the following operations are performed: The abnormal state identifier in the tail of the logistics data packet is set to a specific abnormal state value representing failure, and failure cause information causing the failure is recorded in the logistics data packet.

7. The Java-based industrial product supply order logistics data processing method according to claim 6, characterized by, According to the failure cause information and the type of the current processing intention, a predefined downgrade intention is determined through a predefined downgrade condition judgment, and the downgrade intention is used to replace the current processing intention recorded in the tail of the logistics data packet. The logistics data packet carrying the downgrade intention and the abnormal state identifier is injected into a backup data flow pipeline associated with the downgrade intention in advance or directly allocated to a manual handling node.

8. The Java-based industrial product supply order logistics data processing method according to claim 7, characterized by, The predefined downgrade condition judgment is that if the current processing intention is the second type of intention and the failure cause information is a logistics track query interface timeout, the downgrade intention is determined to be a manual handling intention, and if the current processing intention is the first type of intention and the failure cause information is a data format error, the downgrade intention is determined to be a basic verification intention.

9. The Java-based industrial product supply order logistics data processing method according to claim 1, characterized by, In the S4, when the current processing intention carried by the logistics data packet is identified as the fifth type of intention, the final business data in the logistics data packet body is extracted, and the final business data is converted into output data conforming to the interface data specification of a predetermined downstream business processing unit according to the interface data specification of the predetermined downstream business processing unit; The converted output data is sent to the corresponding downstream business processing unit by calling an application programming interface provided by the downstream business processing unit or by delivering it to a message queue corresponding to the downstream business processing unit.

10. A Java-based industrial goods supply order logistics data processing system for use in the Java-based industrial goods supply order logistics data processing method according to any one of claims 1 to 9, characterized by, It comprises: A data receiving module that obtains industrial product supply order logistics data packets from multiple suppliers; A pipeline configuration module that injects the logistics data packet into a corresponding preconfigured data flow pipeline based on the initial processing intention; A pipeline scheduling module that drives the logistics data packet to flow through at least one processing node in sequence in the data flow pipeline, wherein the current processing node performs a corresponding data processing action based on the processing intention carried by the logistics data packet, and after the execution is completed, the content of the logistics data packet is updated based on the processing result and a next processing intention is determined; An intention management module that outputs the processing result encapsulated by the logistics data packet to a designated downstream business processing unit when the processing intention carried by the logistics data packet indicates that the process is complete.

Images