Storage business processing method and device, electronic equipment and medium

Abstract

The invention provides a storage business processing method and device, electronic equipment and a medium, which can be widely applied to the technical field of computers, and the storage business processing method comprises the following steps: deploying each of a plurality of storage businesses to a micro-service, and determining the architecture of the micro-service according to the execution logic of the storage businesses; wherein the architecture comprises one or more of an aggregator micro-service architecture, a chain micro-service architecture and a data sharing micro-service architecture; configuring a technology stack and a target function for each micro-service based on domain-driven design according to execution logic of the storage service; and if the current process node belongs to the preset process node, issuing a target event, and receiving the target event through a target micro-service corresponding to the target event to execute a target function corresponding to the target micro-service. The problem of difficulty in service deployment in related technologies can be reduced; and the maintainability and high-efficiency operation of the storage business are improved.

Description

Technical Field

[0001] This application relates to the field of computer technology, and more specifically, to a warehousing business processing method, apparatus, electronic device, and medium. Background Technology

[0002] With the rapid development of e-commerce, intelligent manufacturing, and modern logistics, enterprises are placing higher demands on the efficiency, accuracy, and flexibility of warehouse management. Among related technologies, warehouse management systems (WMS) often adopt a monolithic architecture for design and development, deploying all functional modules on a single server or cluster environment. However, as business scale expands and system complexity increases, this approach suffers from high system coupling and maintenance difficulties. The technology stack is singular, hindering iteration: the entire system is typically built on a unified technical framework, making it difficult to introduce new programming languages, databases, or middleware for local optimization, thus impeding technological innovation. Deployment is complex, and updates carry high risks: each version update requires redeploying the entire application, increasing operational complexity and production environment risks. Summary of the Invention

[0003] The main objective of this application is to provide a warehousing business processing method, apparatus, electronic equipment, and medium to at least solve the problems of maintenance and deployment difficulties in the prior art.

[0004] To achieve the above objectives, according to one aspect of this application, a warehousing business processing method is provided. The method includes: deploying each of a plurality of warehousing businesses to a microservice, and determining the architecture of the microservice based on the execution logic of each warehousing business; wherein the architecture includes one or more of an aggregator microservice architecture, a chained microservice architecture, and a data-sharing microservice architecture; configuring a technology stack and target function for each microservice based on domain-driven design according to the execution logic of the warehousing business; if the current process node belongs to a preset process node, publishing a target event, and receiving the target event through a target microservice corresponding to the target event to execute the target function corresponding to the target microservice. This application reduces the difficulty of business deployment in related technologies by deploying warehousing businesses to various microservices, determining the microservice architecture based on the execution logic of the warehousing businesses, and publishing target events based on microservices according to the current process node. Furthermore, this application configures the technology stack and target function for microservices based on domain-driven design, performs microservice delimitation on the warehousing business process, and achieves automatic execution of warehousing businesses through multiple microservices, improving the maintainability and efficient operation of warehousing businesses.

[0005] Optionally, determining the architecture of the microservice based on the execution logic of the warehousing business includes:

[0006] If the execution logic of the warehousing business is to synchronously connect to multiple first businesses in all warehousing businesses, the microservice corresponding to each first business is connected to the gateway through an aggregator so as to receive user requests through the gateway;

[0007] Alternatively, if the execution logic of the warehousing business is to sequentially connect multiple second businesses in all warehousing businesses, the microservices corresponding to the second businesses are connected sequentially according to the connection order, and the sequentially connected microservices are connected to the client through a gateway;

[0008] Alternatively, if the execution logic of the warehousing business involves data interaction between multiple third-party businesses in all warehousing businesses, then the microservice corresponding to each third-party business is connected to the database.

[0009] Optionally, deploying each of the multiple warehousing operations to a microservice includes:

[0010] Deploy the fourth business among the multiple warehousing businesses to the first microservice, and set the deployment status of the first microservice to deployed;

[0011] The fifth service among the multiple warehousing services is deployed to the second microservice, and the deployment status of the second microservice is set to deployed.

[0012] Optionally, before publishing a target event and receiving the target event through the target microservice corresponding to the target event if the current process node belongs to a preset process node, the method further includes:

[0013] If a new warehousing business exists, determine the microservice corresponding to the new warehousing business, execute the new warehousing business through the microservice corresponding to the new warehousing business, and publish the target event corresponding to the new warehousing business;

[0014] The target event is obtained through a third microservice to execute subsequent business of the new warehousing business; or, the new warehousing business is obtained through the third microservice based on a preset interface to execute subsequent business of the new warehousing business; wherein, the third microservice is a microservice other than the microservice corresponding to the new warehousing business.

[0015] Optionally, after publishing a target event and receiving the target event through the target microservice corresponding to the target event if the current process node belongs to a preset process node, the method further includes:

[0016] Obtain the business data corresponding to the warehousing business;

[0017] If the data consistency requirement of the warehousing operation is level one, it is determined that the business data corresponding to each execution stage of the warehousing operation is in a consistent state.

[0018] If the data consistency requirement of the warehousing operation is level two, it is determined that the business data corresponding to the final execution stage of the warehousing operation is in a consistent state; wherein, the data consistency requirement corresponding to the first level is higher than the data consistency requirement corresponding to the second level.

[0019] Optionally, the warehousing operation includes outbound operations, which include a resource reservation phase, a submission phase, and a rollback phase; if the data consistency requirement of the warehousing operation is level one, determining that the business data corresponding to each execution phase of the warehousing operation is in a consistent state includes:

[0020] If the outbound transaction is received and the available inventory is greater than the preset inventory, the resource reservation stage is entered. The first frozen inventory is determined based on the sum of the outbound inventory and the original frozen inventory, and the status of the outbound transaction is set to pending confirmation.

[0021] If all the business processes in the resource reservation phase are successfully executed, the process enters the submission phase. The final frozen inventory is determined based on the difference between the first frozen inventory and the outbound inventory. The final actual inventory is determined based on the difference between the original actual inventory and the outbound inventory. The outbound business status is then set to outbound.

[0022] Alternatively, if there are unexecuted business transactions during the resource reservation phase or the status of the submission phase is timed out, the rollback phase begins, and the final frozen inventory is determined based on the difference between the first frozen inventory and the outgoing inventory.

[0023] Optionally, publishing a target event and receiving the target event through a target microservice corresponding to the target event includes:

[0024] If the execution logic is that the operation results of the publisher and receiver of the target event are synchronized and the time for the receiver to obtain the operation result of the publisher is less than or equal to a preset time, the target event is published through the REST protocol interface;

[0025] Otherwise, the target event is published via a message broker.

[0026] To achieve the above objectives, according to another aspect of this application, a warehouse operation processing apparatus is provided, comprising:

[0027] An architecture design module is used to deploy each of the multiple warehousing businesses to a microservice, and to determine the architecture of the microservice based on the execution logic of each warehousing business; wherein the architecture includes one or more of an aggregator microservice architecture, a chained microservice architecture, and a data sharing microservice architecture;

[0028] The function configuration module is used to configure the technology stack and target functions for each microservice based on the execution logic of each of the warehousing businesses and domain-driven design.

[0029] The function implementation module is used to publish a target event if the current process node belongs to a preset process node, and receive the target event through the target microservice corresponding to the target event in order to execute the target function corresponding to the target microservice.

[0030] According to another aspect of this application, an electronic device is provided, including a memory and a processor, wherein the memory stores a computer program, and the processor is configured to execute the above-described warehousing business processing method through the computer program.

[0031] According to another aspect of this application, a computer-readable storage medium is provided, including a stored program, wherein, when the program is executed, it controls the device where the computer-readable storage medium is located to perform the above-described warehousing business processing method.

[0032] According to another aspect of this application, a computer program product is provided, including computer instructions that, when executed by a processor, implement the steps of the above-described warehousing business processing method.

[0033] By applying the technical solution of this application, the warehousing business is deployed to various microservices. Based on the execution logic of the warehousing business, the architecture of the microservices is determined, and target events are published based on the microservices according to the current process node, thus reducing the difficulty of business deployment in related technologies. Furthermore, this application configures the technology stack and target functions for the microservices based on domain-driven design, performs microservice delimitation on the warehousing business process, and achieves automatic execution of the warehousing business through multiple microservices, improving the maintainability and efficient operation of the warehousing business. Attached Figure Description

[0034] The accompanying drawings, which form part of this application, are used to provide a further understanding of this application. The illustrative embodiments and descriptions of this application are used to explain this application and do not constitute an undue limitation of this application. In the drawings:

[0035] Figure 1 A schematic diagram illustrating an application scenario of a warehousing business processing method provided in an embodiment of this application is shown.

[0036] Figure 2 A flowchart illustrating a warehousing business processing method provided in an embodiment of this application is shown.

[0037] Figure 3 A schematic diagram of an aggregator microservice architecture provided according to an embodiment of this application is shown;

[0038] Figure 4 A schematic diagram of a chained microservice architecture provided according to an embodiment of this application is shown;

[0039] Figure 5 A schematic diagram of the structure of a data sharing microservice provided according to an embodiment of this application is shown;

[0040] Figure 6 A schematic diagram of the structure of an asynchronous messaging microservice provided according to an embodiment of this application is shown.

[0041] The above figures include the following reference numerals:

[0042] 102, Processor; 104, Memory; 106, Transmission device; 108, Input / output device. Detailed Implementation

[0043] It should be noted that, unless otherwise specified, the embodiments and features described in this application can be combined with each other. This application will now be described in detail with reference to the accompanying drawings and embodiments.

[0044] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort should fall within the scope of protection of the present application.

[0045] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate for the embodiments of this application described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0046] As described in the background section, in related technologies:

[0047] With the rapid development of e-commerce, intelligent manufacturing, and modern logistics, enterprises have placed higher demands on the efficiency, accuracy, and flexibility of warehouse management. Traditional warehouse management systems (WMS) are mostly designed and developed using a monolithic architecture, which integrates all functional modules (such as inbound management, outbound management, inventory management, stocktaking management, and scheduling management) into a large application and deploys it on a single server or in a cluster environment.

[0048] However, with the expansion of business scale and the increase in system complexity, traditional monolithic WMS architecture has exposed many problems:

[0049] The system is highly coupled and difficult to maintain: the functional modules are highly coupled, and modifying a certain module may affect the stability of the entire system, resulting in long development, testing and deployment cycles and difficulty in responding quickly to business changes.

[0050] Poor scalability: When a certain business module (such as order processing) faces high concurrency pressure, the entire system must be expanded, resulting in a waste of resources; while other low-load modules cannot scale independently, limiting the system's elasticity.

[0051] The technology stack is singular and difficult to iterate: The entire system is usually built on a unified technology framework, making it difficult to introduce new programming languages, databases or middleware for local optimization, which hinders technological innovation.

[0052] Low availability and fault tolerance: If a module fails, the entire system may become unavailable, lacking service-level isolation and fault tolerance mechanisms.

[0053] Complex deployment and high update risk: Each version update requires redeploying the entire application, increasing operational complexity and production environment risks.

[0054] In recent years, microservices architecture, as an emerging distributed system design pattern, has been widely adopted in enterprise applications. This architecture breaks down a large application into multiple small, loosely coupled services with single responsibilities. These services interact with each other through lightweight communication mechanisms (such as HTTP / REST and message queues) and can be independently developed, tested, deployed, and scaled.

[0055] To address the aforementioned issues, embodiments of this application provide a warehouse operation processing method. This method deploys warehouse operations to various microservices, determines the microservice architecture based on the execution logic of the warehouse operations, and publishes target events based on the microservices according to the current process node, thus reducing the difficulties in business deployment in related technologies. Furthermore, this application configures the technology stack and target functions for microservices based on domain-driven design, performs microservice delimitation on the warehouse operation process, and achieves automatic execution of warehouse operations through multiple microservices, improving the maintainability and efficient operation of the warehouse operations.

[0056] The technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings in the embodiments of the present invention.

[0057] The methods and embodiments provided in this application can be executed on a mobile terminal, a computer terminal, or a similar computing device. Taking running on a mobile terminal as an example, Figure 1 This is a hardware structure block diagram of a mobile terminal for a warehousing business processing method according to an embodiment of the present invention. For example... Figure 1 As shown, a mobile terminal may include one or more ( Figure 1 Only one is shown in the diagram. A processor 102 (which may include, but is not limited to, a microprocessor MCU or a programmable logic device FPGA, etc.) and a memory 104 for storing data are also shown. The mobile terminal may further include a transmission device 106 for communication functions and an input / output device 108. Those skilled in the art will understand that... Figure 1 The structure shown is for illustrative purposes only and does not limit the structure of the mobile terminal described above. For example, the mobile terminal may also include components that are more... Figure 1 The more or fewer components shown, or having the same Figure 1 The different configurations shown.

[0058] The memory 104 can be used to store computer programs, such as application software programs and modules, like the computer program corresponding to the warehousing business processing method in this embodiment of the invention. The processor 102 executes various functional applications and data processing by running the computer program stored in the memory 104, thereby implementing the above-described method. The memory 104 may include high-speed random access memory and non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 104 may further include memory remotely located relative to the processor 102, and these remote memories can be connected to the mobile terminal via a network. Examples of the aforementioned networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof. The transmission device 106 is used to receive or send data via a network. Specific examples of the aforementioned networks may include wireless networks provided by the mobile terminal's communication provider. In one instance, the transmission device 106 includes a network interface controller (NIC), which can be connected to other network devices via a base station to communicate with the Internet. In one instance, the transmission device 106 may be a radio frequency (RF) module, which is used to communicate with the Internet wirelessly.

[0059] This embodiment provides a warehouse business processing method that runs on a mobile terminal, computer terminal or similar computing device. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Also, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0060] It should be noted that the information collected in this application is information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, storage, use, processing, transmission, provision, disclosure, and application of this data all comply with the relevant laws, regulations, and standards of the relevant countries and regions, and necessary confidentiality measures have been taken. This process does not violate public order and good morals, and corresponding access points are provided for users to choose whether to authorize or refuse. The automated decision-making involved in this application provides users with corresponding access points to choose whether to agree to or refuse the automated decision-making results; if the user chooses to refuse, the process proceeds to the expert decision-making stage.

[0061] Figure 2 This is a flowchart illustrating a warehousing business processing method according to an embodiment of this application. The warehousing business processing method includes:

[0062] Step S100: Deploy each of the multiple warehousing services to a microservice, and determine the architecture of the microservice based on the execution logic of each warehousing service; wherein the architecture includes one or more of an aggregator microservice architecture, a chained microservice architecture, and a data sharing microservice architecture;

[0063] Step S200: Based on the execution logic of each of the warehousing operations, configure the technology stack and target functions for each microservice according to domain-driven design;

[0064] Step S300: If the current process node belongs to a preset process node, publish a target event and receive the target event through the target microservice corresponding to the target event to execute the target function corresponding to the target microservice.

[0065] In this application, warehousing operations can be any operation within a warehousing scenario, such as inbound / outbound, order verification, material handling, storage location allocation, inventory management, and scheduling management. This application deploys warehousing operations to microservices. Specifically, each microservice receives one warehousing operation, and the microservice architecture is determined based on the execution logic of the corresponding warehousing operation. The execution logic includes the execution order and conditions of the warehousing operations. An aggregator microservice architecture is used to execute multiple warehousing operations synchronously, a chained microservice architecture executes multiple warehousing operations sequentially, and a data-sharing microservice architecture allows data sharing between warehousing operations. Domain-driven design is used to delineate the boundaries of microservices, facilitating subsequent warehousing operation processes. The preset process nodes in this application can be set according to actual needs. In some embodiments, based on the domain to which warehousing belongs, nodes corresponding to key operations are set as preset process nodes. For example, inbound shelving completion. This application publishes target events through microservices, and the target microservice receives the target events, executes the target function, and realizes the functionality of the warehousing operation. This application reduces the difficulty of business deployment in related technologies by deploying warehousing operations to various microservices, determining the microservice architecture based on the execution logic of the warehousing operations, and publishing target events based on the microservices according to the current process node. Furthermore, this application configures the technology stack and target functions for the microservices based on domain-driven design, performs microservice delimitation on the warehousing business process, and achieves automatic execution of warehousing operations through multiple microservices, improving the maintainability and efficient operation of the warehousing business.

[0066] Optionally, determining the architecture of the microservice based on the execution logic of the warehousing business includes:

[0067] If the execution logic of the warehousing business is to synchronously connect to multiple first businesses in all warehousing businesses, the microservice corresponding to each first business is connected to the gateway through an aggregator so as to receive user requests through the gateway;

[0068] Alternatively, if the execution logic of the warehousing business is to sequentially connect multiple second businesses in all warehousing businesses, the microservices corresponding to the second businesses are connected sequentially according to the connection order, and the sequentially connected microservices are connected to the client through a gateway;

[0069] Alternatively, if the execution logic of the warehousing business involves data interaction between multiple third-party businesses in all warehousing businesses, then the microservice corresponding to each third-party business is connected to the database.

[0070] If the first business in all warehousing operations needs to be synchronized, the microservices corresponding to the first business are connected through an aggregator and then connected to the client through a gateway, receiving user requests through the client. Specifically, in response to access instructions for multiple warehousing operations received by the front-end interface, a JSON response is generated, allowing the front-end interface to connect to the microservices of multiple warehousing operations via the JSON response. For example... Figure 3 As shown, the user issues a command through the client, the gateway forwards the command, and then the aggregator transmits it to each microservice. The access command in this application can be either a data retrieval command or a data writing command.

[0071] If the second business in the warehousing operation occurs sequentially, the microservices corresponding to the second business are connected sequentially and accessed to the client through the gateway. Similarly, the client is used to issue user commands, such as... Figure 4 As shown. If there is interaction between the third-party services corresponding to the warehousing business, connect the microservices corresponding to the third-party services to the database respectively, such as... Figure 5 As shown. Alternatively, microservices corresponding to various third-party services can be connected via message queues, such as... Figure 6 As shown. Based on the execution logic of warehousing operations, this application establishes a suitable architecture for the microservices corresponding to each business, so as to realize the automatic execution of warehousing operations and improve the execution efficiency of warehousing operations.

[0072] Optionally, deploying each of the multiple warehousing operations to a microservice includes:

[0073] Deploy the fourth business among the multiple warehousing businesses to the first microservice, and set the deployment status of the first microservice to deployed;

[0074] The fifth service among the multiple warehousing services is deployed to the second microservice, and the deployment status of the second microservice is set to deployed.

[0075] This application deploys the fourth service to an idle first microservice and sets the deployment status of the first microservice to "deployed" to avoid redeployment of the first microservice by other services. Similarly, the fifth service is deployed to an idle second microservice. This application uses this method to ensure that each service is responsible for only one service, performing only the functions and issuing only one service's events, thus ensuring the effective execution of the warehousing business process and improving the accuracy of warehousing business processing.

[0076] Optionally, before publishing a target event and receiving the target event through the target microservice corresponding to the target event if the current process node belongs to a preset process node, the method further includes:

[0077] If a new warehousing business exists, determine the microservice corresponding to the new warehousing business, execute the new warehousing business through the microservice corresponding to the new warehousing business, and publish the target event corresponding to the new warehousing business;

[0078] The target event is obtained through a third microservice to execute subsequent business of the new warehousing business; or, the new warehousing business is obtained through the third microservice based on a preset interface to execute subsequent business of the new warehousing business; wherein, the third microservice is a microservice other than the microservice corresponding to the new warehousing business.

[0079] New warehousing operations are executed through corresponding microservices, and similarly, each warehousing operation is executed through a corresponding microservice. The third microservice is a microservice other than the one that issues the target event. The third microservice can execute subsequent operations by obtaining the target event, or it can obtain new warehousing operations through a pre-defined interface (such as an API). This application provides a streamlined interface for each warehousing operation through either an interface or event-triggered method, enabling self-service workflow for warehousing operations.

[0080] Optionally, after publishing a target event and receiving the target event through the target microservice corresponding to the target event if the current process node belongs to a preset process node, the method further includes:

[0081] Obtain the business data corresponding to the warehousing business;

[0082] If the data consistency requirement of the warehousing operation is level one, it is determined that the business data corresponding to each execution stage of the warehousing operation is in a consistent state.

[0083] If the data consistency requirement of the warehousing operation is level two, it is determined that the business data corresponding to the final execution stage of the warehousing operation is in a consistent state; wherein, the data consistency requirement corresponding to the first level is higher than the data consistency requirement corresponding to the second level.

[0084] This application determines the consistency requirements for business data at each stage of warehousing operations based on the sensitivity of warehousing operations to data consistency. Data consistency is defined as identical data. In the first-level requirement scenario, an alert is issued if inconsistencies occur in the business data. In the second-level requirement scenario, inconsistencies in business data are allowed at certain execution stages, but the data at the final execution stage must be consistent. This application, through different levels of data processing, meets the varying data consistency requirements of warehousing scenarios, provides customers with diverse data processing logic, and ensures data processing accuracy.

[0085] Optionally, the warehousing operation includes outbound operations, which include a resource reservation phase, a submission phase, and a rollback phase; if the data consistency requirement of the warehousing operation is level one, determining that the business data corresponding to each execution phase of the warehousing operation is in a consistent state includes:

[0086] If the outbound transaction is received and the available inventory is greater than the preset inventory, the resource reservation stage is entered. The first frozen inventory is determined based on the sum of the outbound inventory and the original frozen inventory, and the status of the outbound transaction is set to pending confirmation.

[0087] If all the business processes in the resource reservation phase are successfully executed, the process enters the submission phase. The final frozen inventory is determined based on the difference between the first frozen inventory and the outbound inventory. The final actual inventory is determined based on the difference between the original actual inventory and the outbound inventory. The outbound business status is then set to outbound.

[0088] Alternatively, if there are unexecuted business transactions during the resource reservation phase or the status of the submission phase is timed out, the rollback phase begins, and the final frozen inventory is determined based on the difference between the first frozen inventory and the outgoing inventory.

[0089] Preset inventory is used to indicate sufficient inventory, which can be the amount of inventory required to meet the minimum inventory requirement. This application achieves inventory consistency by freezing inventory, reserving inventory logically. Records in the pending confirmation status are used to record outbound tasks. If all business operations are successfully executed, the actual inventory is determined based on the reserved inventory, and the frozen inventory is released. Conversely, if any business operation fails to execute or the submission stage fails, the frozen inventory is rolled back, and the business status is set to canceled or pending. This application links inventory records with the actual business execution stage by freezing inventory, avoiding a disconnect between data records and the business execution stage, and improving data accuracy.

[0090] Optionally, publishing a target event and receiving the target event through a target microservice corresponding to the target event includes:

[0091] If the execution logic is that the operation results of the publisher and receiver of the target event are synchronized and the time for the receiver to obtain the operation result of the publisher is less than or equal to a preset time, the target event is published through the REST protocol interface;

[0092] Otherwise, the target event is published via a message broker.

[0093] The preset time can be the lifecycle of the target event or target request. If the execution logic synchronizes the operation results of the publisher and receiver of the target event, the business is strongly dependent. If the execution logic requires the receiver to obtain the operation result from the publisher in a time less than or equal to the preset time, the business needs timely feedback. In this case, if both conditions are met, the target event is published through the protocol interface to achieve synchronous business calls. If the two conditions cannot be met simultaneously, the target event is published through a message middleware to achieve asynchronous decoupling. Different network settings are configured for different business needs, providing satisfactory service to users while enabling diverse network deployments.

[0094] To enable those skilled in the art to better understand the technical solution of this application, the implementation process of the warehousing business processing method of this application will be described in detail below with reference to specific embodiments.

[0095] The method provided in this application can solve the problems of how to reasonably divide the boundaries of microservices in the warehousing business domain (such as inventory service, task scheduling service, and location allocation service); how to ensure data consistency in a distributed environment (such as inventory deduction and order status synchronization); and how to achieve efficient communication and fault isolation between services.

[0096] like Figure 3 As shown, the aggregator microservice model scheme is as follows:

[0097] Function Description: The homepage seen by warehouse administrators after logging in displays a summary of pending tasks, such as: quantity of goods to be received, number of tasks to be put on the shelf, number of orders to be picked, number of items with inventory warnings. Aggregator Function: Calls multiple microservices to obtain various task statistics; merges them into a single JSON response and returns it to the front end; avoids the front end calling 4 to 5 interfaces separately.

[0098] like Figure 4 As shown, the chained microservice model solution:

[0099] Execute according to business logic processes, such as receiving goods first, then shelving, quality inspection, and outbound sorting.

[0100] Reference Figure 5 Data sharing microservice model solution:

[0101] Data is retrieved via API. When service A needs data from service B, it actively queries through B's REST API. Suitable scenarios: High real-time requirements; small data volume, low call frequency. WMS example: The product listing service calls the product service API to obtain basic SKU information; the outbound service calls the inventory service API to verify available inventory. Disadvantages: Increased call chain latency; strong dependencies between services.

[0102] Regarding how to reasonably define the boundaries of microservices in the warehousing business domain.

[0103] Domain-Driven Design (DDD) methodology is used to perform bounded context partitioning in conjunction with warehouse business processes.

[0104] 1. Service division list and responsibility definition.

[0105] The microservices in Table 1 are different services within the program responsible for different functions. Specifically, they include: inventory management service, inbound management service, outbound management service, task management service, warehouse location monitoring service, status feedback service, customer data management service, and warehouse zoning management service.

[0106] Table 1

[0107]

[0108] 2. Taking inbound and shelving as an example, in a microservice architecture, "inbound and shelving" is a typical cross-service collaborative business process. When the warehouse receives goods from the supplier, the system needs to coordinate multiple microservices to ensure that the product information is accurate, the quantity is compliant, the inventory is updated correctly, and to complete the physical or logical shelving operation.

[0109] The entire process typically begins with the warehouse operator scanning the product barcode and entering the quantity to be received at the WMS (Warehouse Management System) front end. The system first invokes the product service to verify whether the product exists in the master data and is in a receiveable state based on the product barcode. If the product is invalid or deactivated, the process immediately terminates and displays an error message.

[0110] After confirming the goods are valid, the system then calls the procurement service, passing in the purchase order number and goods information, to verify whether the current receiving action matches the approved procurement plan. For example, the system will check whether the goods belong to this purchase order and whether the quantity received this time exceeds the remaining unreceived quantity in the order. If the verification fails (e.g., no corresponding purchase order or excessive receipt), the goods will be rejected from the warehouse.

[0111] Once the verification is successful, the warehousing service, as the core coordinator of the process, creates a "receiving order" record, which includes information such as product ID, actual received quantity, warehouse ID, operator, and timestamp. At this point, the product is in the "received, awaiting shelving" state.

[0112] Next, the system calls the inventory service to temporarily record the quantity of these goods in "pending shelf inventory" or "in-transit inventory" to prevent other processes from mistakenly treating them as available inventory. This step ensures the accuracy and isolation of inventory data.

[0113] Subsequently, the putaway service is triggered. It automatically or semi-automatically allocates the target storage location (e.g., row 01, floor 02, cell 03 in area A) based on warehouse strategies (such as FIFO, storage capacity, and product category). The system generates a "putaway task," guiding warehouse personnel to move the goods to the designated location. Once the operator confirms the putaway is complete on the terminal, the putaway service again calls the inventory service to transfer the inventory from the "pending putaway" state to the "available inventory" of the corresponding storage location, thus officially activating the inventory.

[0114] At key points in the process (such as upon completion of warehousing and shelving), the system publishes domain events to message brokers (such as Kafka or RabbitMQ). These events are subscribed to by notification services, product status services, or other downstream systems. For example, the notification service can send a "goods have been received" reminder to the purchasing agent; the product status service can determine whether the product is being received for the first time, and if so, automatically update its status on the e-commerce platform to "available for sale"; the ERP system can synchronize the latest inventory data for financial reconciliation. To ensure reliability, the entire process needs to have exception handling and compensation mechanisms. For example, if the storage space is full during the shelving process, the system should support reallocation or manual intervention; if a service is temporarily unavailable, rollback or compensation can be performed through retry mechanisms or the Saga distributed transaction model (such as canceling created receiving orders or releasing temporary inventory).

[0115] 2. The division principle has been implemented.

[0116] High cohesion and low coupling: Each service is responsible for only one business capability.

[0117] Data ownership: For example, inventory data is only written by the inventory-service, and other services (referring to other microservices besides the inventory-service microservice) obtain it through API or events.

[0118] Event-driven decoupling: For example, after the inbound-service completes receiving the goods, it publishes a GoodsReceivedEvent, which is consumed by the inventory-service to update the inventory.

[0119] For example, for the microservices mentioned above:

[0120] The publishing service `outbound-service` triggers the `OrderShippedEvent` event, while the consumer services `task-scheduler-service` and `location-service` publish the event after an order is shipped. The scheduling service can trigger subsequent tasks (such as logistics tracking), and the location service can update the location status of the goods. The publishing service `outbound-service` triggers the `OrderCancelledEvent` event, while the consumer services `inventory-service` and `task-scheduler-service` release reserved inventory and cancel related task scheduling when an order is cancelled, maintaining data consistency. The publishing service `task-scheduler-service` triggers the `TaskCompletedEvent` event, while the consumer services `outbound-service` and `location-service` notify downstream services to update order status or location information upon completion of a task (such as picking or packing). The publishing service `location-service` triggers the `LocationUpdatedEvent` event, while the consumer services `inventory-service` and `execution-service` notify the inventory system to update the location information and the execution system to adjust the work path after the goods' location changes.

[0121] How to ensure data consistency in a distributed environment.

[0122] Based on the business's sensitivity to data consistency, typical scenarios are divided into two categories:

[0123] Strong consistency scenario: Example: In an outbound operation, "deducting inventory" and "updating order status" must both succeed or fail simultaneously; intermediate states are not allowed to persist for extended periods. If inconsistency occurs, the system automatically reports an error. Requirements: Transactions must be atomic; users or downstream systems must not be aware of any inconsistencies.

[0124] Eventual consistency scenario: Example: Inventory increases are triggered after receiving goods, allowing for a short delay (on the order of seconds), but must ultimately accurately reflect the physical changes. Requirements: The system must reach a consistent state within a finite time, tolerating brief inconsistencies, but preventing data loss or duplication.

[0125] Specifically:

[0126] Data visibility: Strong consistency, data is immediately visible after a write (real-time consistency). Eventual consistency, data may be temporarily inconsistent after a write, but will eventually be consistent. System response: Strong consistency, all nodes are synchronously updated after a write. Eventual consistency, nodes replicate asynchronously, resulting in latency.

[0127] Strong consistency implementation: TCC (Try-Confirm-Cancel) mode.

[0128] For outbound processes with high consistency requirements, the TCC distributed transaction model is adopted, which breaks down the business operation into three stages, as shown in Table 2:

[0129] 1. Try phase (resource reservation).

[0130] Inventory service: Check if the available inventory is sufficient. If so, freeze the corresponding quantity (frozen_qty += qty), and the actual inventory remains unchanged.

[0131] `frozen_qty += qty` is the core operation of the Try phase, used to logically reserve inventory. It must be used in conjunction with `available_qty -= qty` to maintain a constant total inventory. The Confirm phase does not deduct inventory, only releases the frozen inventory; the Cancel phase completely rolls back the inventory. This entire mechanism ensures inventory consistency under high concurrency and the reversibility of distributed transactions.

[0132] Outbound service: Set the order status to "pre-outbound" or "pending confirmation" and record the outbound task.

[0133] All operations at this stage are reversible resource reservations and do not generate actual business results.

[0134] 2. Confirm phase (submission).

[0135] If all participants successfully try, the coordinator (usually the outbound service) initiates a Confirmation:

[0136] Inventory services: Deduct actual inventory (available_qty -= qty), release frozen inventory (frozen_qty -= qty).

[0137] frozen_qty-=qty occurs during the Confirm phase, indicating that "the reservation has been successfully redeemed and no longer needs to be frozen".

[0138] It does not change the total inventory quantity, but only clears the temporary status.

[0139] The actual reduction in inventory has already been completed in the Try phase (by subtracting qty from available_qty). Do not deduct available_qty again in the Confirm phase, otherwise it will result in over-deduction.

[0140] Outbound service: Update the order status to "outbound" and generate an outbound order.

[0141] The Confirm operation must be idempotent and support repeated calls (e.g., retrying due to network timeout).

[0142] 3. Cancel phase (rollback).

[0143] If any service Try fails, or the Confirm phase times out before completion, a Cancel is triggered.

[0144] Inventory service: Release frozen inventory (frozen_qty-=qty).

[0145] Outbound service: Roll back the order status to "Pending" or "Cancelled".

[0146] Table 2

[0147]

[0148] How to achieve efficient communication and fault isolation between services.

[0149] Different communication mechanisms are set up, as shown in Table 3:

[0150] Synchronous communication: Suitable for business links with strong dependencies and requiring real-time feedback, such as the outbound service calling the inventory service to perform inventory pre-positioning operations. It adopts a lightweight interface based on the HTTP / REST protocol, combined with a service registry (such as Nacos) to achieve automatic service discovery and load balancing; for performance-sensitive core links, the gRPC protocol can be optionally configured to reduce serialization overhead and network latency.

[0151] Specifically, strong dependency: The caller's business logic must successfully complete the callee's operation before it can continue or return a result. If the callee fails, the caller must also fail (or roll back); it cannot "succeed itself first and then asynchronously process the other party." Immediate feedback: The caller must obtain a clear result (success / failure) from the callee within the current request's lifecycle to determine the subsequent process flow.

[0152] Asynchronous communication: Suitable for decoupled, non-critical path operations, such as triggering inventory updates after data entry is completed, and archiving operation logs. Event publishing and subscription are implemented through the Kafka message middleware, ensuring message persistence and high-throughput delivery, and preventing upstream services from being blocked due to downstream processing delays.

[0153] Table 3

[0154]

[0155] To achieve the above objectives, according to another aspect of this application, a warehouse operation processing apparatus is provided, comprising:

[0156] An architecture design module is used to deploy each of the multiple warehousing businesses to a microservice, and to determine the architecture of the microservice based on the execution logic of each warehousing business; wherein the architecture includes one or more of an aggregator microservice architecture, a chained microservice architecture, and a data sharing microservice architecture;

[0157] The function configuration module is used to configure the technology stack and target functions for each microservice based on the execution logic of each of the warehousing businesses and domain-driven design.

[0158] The function implementation module is used to publish a target event if the current process node belongs to a preset process node, and receive the target event through the target microservice corresponding to the target event in order to execute the target function corresponding to the target microservice.

[0159] According to another aspect of this application, an electronic device is provided, including a memory and a processor, wherein the memory stores a computer program, and the processor is configured to execute the above-described warehousing business processing method through the computer program.

[0160] According to another aspect of this application, a computer-readable storage medium is provided, including a stored program, wherein, when the program is executed, it controls the device where the computer-readable storage medium is located to perform the above-described warehousing business processing method.

[0161] According to another aspect of this application, a computer program product is provided, including computer instructions that, when executed by a processor, implement the steps of the above-described warehousing business processing method.

[0162] It should be noted that the above are merely illustrative examples and do not specifically limit the implementation logic.

[0163] It is obvious to those skilled in the art that the modules or steps of the present invention described above can be implemented using general-purpose computing devices. They can be centralized on a single computing device or distributed across a network of multiple computing devices. They can be implemented using computer-executable program code, and thus can be stored in a storage device for execution by a computing device. In some cases, the steps shown or described can be performed in a different order than those described herein, or they can be fabricated as separate integrated circuit modules, or multiple modules or steps can be fabricated as a single integrated circuit module. Thus, the present invention is not limited to any particular combination of hardware and software.

[0164] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application 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.

[0165] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. 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 processor, 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... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0166] 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.

[0167] 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.

[0168] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0169] Memory may include non-persistent memory in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0170] Computer-readable media include both permanent and non-permanent, removable and non-removable media that can store information using any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0171] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0172] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0173] The above description is merely a preferred embodiment of this application and is not intended to limit this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. A method for processing warehousing operations, characterized in that, The warehousing business processing method includes: Each of the multiple warehousing operations is deployed to a microservice, and the architecture of the microservice is determined based on the execution logic of each warehousing operation; wherein the architecture includes one or more of the following: aggregator microservice architecture, chained microservice architecture, and data sharing microservice architecture; Based on the execution logic of each of the aforementioned warehousing operations, and using domain-driven design, configure the technology stack and target functions for each microservice. If the current process node belongs to a preset process node, a target event is published, and the target event is received through the target microservice corresponding to the target event in order to execute the target function corresponding to the target microservice.

2. The warehousing business processing method according to claim 1, characterized in that, Based on the execution logic of each of the aforementioned warehousing operations, the architecture of the microservices is determined, including: If the execution logic of the warehousing business is to synchronously connect to multiple first businesses in all warehousing businesses, the microservice corresponding to each first business is connected to the gateway through an aggregator so as to receive user requests through the gateway; Alternatively, if the execution logic of the warehousing business is to sequentially connect multiple second businesses in all warehousing businesses, the microservices corresponding to the second businesses are connected sequentially according to the connection order, and the sequentially connected microservices are connected to the client through a gateway; Alternatively, if the execution logic of the warehousing business involves data interaction between multiple third-party businesses in all warehousing businesses, then the microservice corresponding to each third-party business is connected to the database.

3. The warehousing business processing method according to claim 1, characterized in that, Deploying each of the multiple warehousing operations to a microservice includes: Deploy the fourth business among the multiple warehousing businesses to the first microservice, and set the deployment status of the first microservice to deployed; The fifth service among the multiple warehousing services is deployed to the second microservice, and the deployment status of the second microservice is set to deployed.

4. The warehousing business processing method according to claim 3, characterized in that, Before publishing a target event and receiving the target event through the target microservice corresponding to the target event, if the current process node belongs to a preset process node, the method further includes: If a new warehousing business exists, determine the microservice corresponding to the new warehousing business, execute the new warehousing business through the microservice corresponding to the new warehousing business, and publish the target event corresponding to the new warehousing business; The target event is obtained through a third microservice to execute subsequent business of the new warehousing business; or, the new warehousing business is obtained through the third microservice based on a preset interface to execute subsequent business of the new warehousing business; wherein, the third microservice is a microservice other than the microservice corresponding to the new warehousing business.

5. The warehousing business processing method according to claim 1, characterized in that, If the current process node belongs to a preset process node, after publishing a target event and receiving the target event through the target microservice corresponding to the target event, the method further includes: Obtain the business data corresponding to the warehousing business; If the data consistency requirement of the warehousing operation is level one, it is determined that the business data corresponding to each execution stage of the warehousing operation is in a consistent state. If the data consistency requirement of the warehousing operation is level two, it is determined that the business data corresponding to the final execution stage of the warehousing operation is in a consistent state; wherein, the data consistency requirement corresponding to the first level is higher than the data consistency requirement corresponding to the second level.

6. The warehousing business processing method according to claim 1, characterized in that, The warehousing operation includes outbound operations, which include a resource reservation phase, a submission phase, and a rollback phase. If the data consistency requirement of the warehousing operation is level one, it is determined that the business data corresponding to each execution phase of the warehousing operation is in a consistent state, including: If the outbound transaction is received and the available inventory is greater than the preset inventory, the resource reservation stage is entered. The first frozen inventory is determined based on the sum of the outbound inventory and the original frozen inventory, and the outbound transaction status is set to pending confirmation. If all the business processes in the resource reservation phase are successfully executed, the process enters the submission phase. The final frozen inventory is determined based on the difference between the first frozen inventory and the outbound inventory. The final actual inventory is determined based on the difference between the original actual inventory and the outbound inventory. The outbound business status is then set to outbound. Alternatively, if there are unexecuted business transactions during the resource reservation phase or the status of the submission phase is timed out, the rollback phase begins, and the final frozen inventory is determined based on the difference between the first frozen inventory and the outgoing inventory.

7. The warehousing business processing method according to claim 1, characterized in that, Publishing a target event and receiving the target event through the target microservice corresponding to the target event includes: If the execution logic is that the operation results of the publisher and receiver of the target event are synchronized and the time for the receiver to obtain the operation result of the publisher is less than or equal to a preset time, the target event is published through the REST protocol interface; Otherwise, the target event is published via a message broker.

8. A warehousing business processing device, characterized in that, The warehousing business processing device includes: An architecture design module is used to deploy each of the multiple warehousing businesses to a microservice, and to determine the architecture of the microservice based on the execution logic of each warehousing business; wherein the architecture includes one or more of an aggregator microservice architecture, a chained microservice architecture, and a data sharing microservice architecture; The function configuration module is used to configure the technology stack and target functions for each microservice based on the execution logic of each of the warehousing businesses and domain-driven design. The function implementation module is used to publish a target event if the current process node belongs to a preset process node, and receive the target event through the target microservice corresponding to the target event in order to execute the target function corresponding to the target microservice.

9. An electronic device, characterized in that, The electronic device includes: A memory and a processor, wherein the memory stores a computer program and the processor is configured to execute the warehousing business processing method according to any one of claims 1 to 7 via the computer program.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium includes a stored program, wherein, when the program is executed, it controls the device on which the computer-readable storage medium is located to perform the warehousing business processing method according to any one of claims 1 to 7.

Images