WCS System Overview

Operation

As can be seen from the diagram, Calidus 3pl runs on a UNIX server, while Calidus 3pl-Mobile runs on a Windows Server in this implementation.

In the diagram, Calidus 3pl has been split into three areas.

The non-shaded area is the manual Calidus 3pl system, being the screens and methods currently used to enter and confirm tasks.

The wavy shaded area shows the portion of Calidus 3pl that sends messages to the WMS interface. These are covered in great detail in following sections.

The dotted area contains Calidus 3pl RDT update programs that automatically do the work of the confirmation processes in manual Calidus 3pl. For example, one of these processes might confirm movements; another might confirm orders as picked. They work by receiving confirmation of tasks completed from Calidus 3pl-Mobile. Those messages (of tasks to be completed, and confirmation of tasks completed) are sent by the interface.

Both systems have an interface; Calidus 3pl''s is referred to as the WMS interface, Calidus 3pl-Mobile's as the WCS interface. Both need transmitters (to send their messages) and receivers to get messages back. As can be seen from the diagram, Calidus 3pl sends messages to Calidus 3pl-Mobile's receiver program, WCS Server through an Oracle Advance Queue. When messages are being sent back to Calidus 3pl, Calidus 3pl-Mobile's transmitter program, also WCS Server, sends messages to Calidus 3pl by enqueuing messages on Oracle Advance Queues in the WMS database.

The third part of the interface consists of the Merge processes. In Calidus 3pl, these consists of many processes which we route messages to using the Queue Reader processes. These route the messages to the Merge processes (dotted area of the RDT update programs).

So, let's look at the progression of tasks through this system from start to finish. For this example, we'll use a simple housekeeping pallet movement.

When the task (move pallet 1 from A to B) is raised, the message is passed to the WMS Interface Queue. The Queue passes the information to the WCS Server. Note: Only when the message is fully processed is this removed from the queue, ensuring messages are never lost).

Once WCS's receiver has the message, merges the message to the database. This identifies the type of message (a pallet movement), and checks that everything is OK about the messages contents. When satisfied of the contents, the task is put in the main WCS database, ready for use.

When an RDT user requests a task, and they are to be allocated movement tasks, WCS will allocate the closest movement to that user's location, or in priority order. In our example, this means they are given the movement we raised on Calidus 3pl. They are told to get the pallet 1 from location A and take it to location B, there scanning the check digits of the destination for confirmation.

Once they have completed the task, Calidus 3pl-Mobile sends a completion message to the Calidus 3pl receiver queue.

The Queue Reader associated to the queue identifies the type of message, in our example, a movement completion message. The message is then routed to the correct RDT update process. Again, messages are only removed from the queue when correctly processed.

The RDT update process examines the contents of the message for validity, and then updates all the Calidus 3pl data files that you would expect if it was confirmed manually in the Pallet Move Confirmation screen.