Anw: Split into separate pages

2025-12-19T11:48:33Z

Split into separate pages

New page

[[File:WCS-Overview.png|800px]]

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

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

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

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

The dotted area contains Calidus 3''pl'' RDT update programs that automatically do the work of the confirmation processes in manual Calidus 3''pl''. 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 3''pl''-Mobile. Those messages (of tasks to be completed, and confirmation of tasks completed) are sent by the interface.

Both systems have an interface; Calidus 3''pl''''s is referred to as the WMS interface, Calidus 3''pl''-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 3''pl ''sends messages to Calidus 3''pl''-Mobile's receiver program, WCS Server through an Oracle Advance Queue. When messages are being sent back to Calidus 3''pl'', Calidus 3''pl''-Mobile's transmitter program, also WCS Server, sends messages to Calidus 3''pl ''by enqueuing messages on Oracle Advance Queues in the WMS database.

The third part of the interface consists of the Merge processes. In Calidus 3''pl'', 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 message''s 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 3''pl''. 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 3''pl''-Mobile sends a completion message to the Calidus 3''pl'' 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 3''pl'' data files that you would expect if it was confirmed manually in the Pallet Move Confirmation screen.

WCS System Overview - Revision history

Anw: Split into separate pages